[U-Boot] API available to standalone program

[Scott Anderson]

Thank you for the quick reply,

I have entered comments and answers in line below

>>
>> I am interested to perform some of the functions available from
>> command line calls however called from a standalone application.
>> An example would be fatload mmc .....
>
>Why would you want to do that?  Why not just compile your code as part
>of U-Boot?

Unfortunately this is not an option for me as i am creating a solution for
video processing which has IP that relates only to this solution. I am very
happy to contribute back to u-boot for any u-boot related functions however
want to retain IP for my specific product solution.

>
>> Im also interested in if there was a concious decision to exclude
>> these function calls from standalone applications IE if i am and
>> always will need to write my own code for these functions.
>
>Yes, this is an intentional decision.  Standalone applications allow
>you to run any proprietary code you may have, with sufficient glue to
>allow for an easy start.  So for example if you have your own home
>brew OS or a simple task scheduler or such, you can run it, and even
>keep it closed source.  The price for keeping your code proprietary is
>a lean, somewhat restrictive interface.
>
>When you want to actually benefit from all estimated 345 years of
>effort that went into the development of U-Boot (according to [1]),
>say by using the device drivers, file system code or scripting
>capabilitiers that come with U-Boot, then you can do so in the context
>of the GPL license which covers all that code.
>
>Trying to get all the benefits for free, and not contributing anything
>bac, is something that in my point of view is unethical, which is why
>we do not support it.
>
>[1] http://www.ohloh.net/p/u-boot
>
>> I have been attempting to role my own MMC driver for more than 4 weeks
>> now on a processor that has very poor datasheet so i would be very
>> grateful if i was able to use the functionality available in command
>> line calls from within a standalone program.
>
>You see, this is exactly what I mean: using things like the file
>system or driver code in a non-GPL standalone application is exactly
>the type of usage we want to prevent.
>
>If you want to benefit from all the work that the community is
>offeriung for free, then you are welcome to use it, but please do so
>in the context of the GPL license so that you not only take from the
>community, but also give back - no matter how small or big such
>contribution might be.

This approach is understandable, thank you for explaining the reasoning.
It appears that for my solution i will need to write my own drivers or use an
operating system which does not impose GPL in this way.

Regards,
Scott

On Sat, Jun 14, 2014 at 10:08 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Scott Anderson,
>
> In message <CAFrkK5u5cFhP=66MZ8Z8v_jfgaqap2tae4dk8GBOwPKxHgczyA at mail.gmail.com> you wrote:
>>
>> I am interested to perform some of the functions available from
>> command line calls however called from a standalone application.
>> An example would be fatload mmc .....
>
> Why would you want to do that?  Why not just compile your code as part
> of U-Boot?
>
>> Im also interested in if there was a concious decision to exclude
>> these function calls from standalone applications IE if i am and
>> always will need to write my own code for these functions.
>
> Yes, this is an intentional decision.  Standalone applications allow
> you to run any proprietary code you may have, with sufficient glue to
> allow for an easy start.  So for example if you have your own home
> brew OS or a simple task scheduler or such, you can run it, and even
> keep it closed source.  The price for keeping your code proprietary is
> a lean, somewhat restrictive interface.
>
> When you want to actually benefit from all estimated 345 years of
> effort that went into the development of U-Boot (according to [1]),
> say by using the device drivers, file system code or scripting
> capabilitiers that come with U-Boot, then you can do so in the context
> of the GPL license which covers all that code.
>
> Trying to get all the benefits for free, and not contributing anything
> bac, is something that in my point of view is unethical, which is why
> we do not support it.
>
> [1] http://www.ohloh.net/p/u-boot
>
>> I have been attempting to role my own MMC driver for more than 4 weeks
>> now on a processor that has very poor datasheet so i would be very
>> grateful if i was able to use the functionality available in command
>> line calls from within a standalone program.
>
> You see, this is exactly what I mean: using things like the file
> system or driver code in a non-GPL standalone application is exactly
> the type of usage we want to prevent.
>
> If you want to benefit from all the work that the community is
> offeriung for free, then you are welcome to use it, but please do so
> in the context of the GPL license so that you not only take from the
> community, but also give back - no matter how small or big such
> contribution might be.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Reader, suppose you were an idiot. And suppose you were a  member  of
> Congress. But I repeat myself.                           - Mark Twain