Discussion:
[U-Boot] u-boot command for standalone application
swami91
2014-07-24 01:08:40 UTC
Permalink
Hi,

We are planning to have a non-GPL standalone application which does some
basic board checks and also holds a authentication key (which we don't want
it to be published). The authentication code is in u-boot and will be
released under GPL.

1. Is it ok if we implement uboot commands that would call into the
standalone application API without violating GPL terms of u-boot? The
command returns to the command line after execution. The arguments are
passed from the uboot command line.

2. How to pass the authentication key from the standalone application to
u-boot without violating the GPL license other than hard coding the address
of the key location in the u-boot? Does this hardcoding violate the GPL
terms of u-boot?

3. Is it ok to load the application from within the uboot into RAM and then
let the u-boot commands executed on it?

Thanks.
Sudhakr



--
View this message in context: http://u-boot.10912.n7.nabble.com/u-boot-command-for-standalone-application-tp184818.html
Sent from the U-Boot mailing list archive at Nabble.com.
Wolfgang Denk
2014-07-24 06:15:57 UTC
Permalink
Dear swami91,
Post by swami91
1. Is it ok if we implement uboot commands that would call into the
standalone application API without violating GPL terms of u-boot? The
command returns to the command line after execution. The arguments are
passed from the uboot command line.
No. A standalone application can use U-Boot services only through the
exported interface (call table), which is intentionally limited.
Post by swami91
2. How to pass the authentication key from the standalone application to
u-boot without violating the GPL license other than hard coding the address
of the key location in the u-boot? Does this hardcoding violate the GPL
terms of u-boot?
Even if you hard-code addresses in the U-Boot image you would be
violating the GPL. A non-GPL standalone application must be really
what the name suggests: standalone. It gets only a very narrow,
stricltly limited set of services - just enough to ger some early
initialization and debugging done. All the rest, including drivers
and services, mut be re-implemented in your own proprietary image.
Post by swami91
3. Is it ok to load the application from within the uboot into RAM and then
let the u-boot commands executed on it?
U-Boot can start your application using the "go" command. But your
non-GPL standalone program cannot call any commands from U-Boot.
That would be a violation of the GPL.

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
"More software projects have gone awry for lack of calendar time than
for all other causes combined."
- Fred Brooks, Jr., _The Mythical Man Month_
swami91
2014-07-24 13:29:14 UTC
Permalink
Thanks Wolfgang.
Post by Wolfgang Denk
Post by swami91
1. Is it ok if we implement uboot commands that would call into the
standalone application API without violating GPL terms of u-boot? The
command returns to the command line after execution. The arguments are
passed from the uboot command line.
No. A standalone application can use U-Boot services only through the
exported interface (call table), which is intentionally limited.
Sorry the confusion. Actually my question is not standalone application
accessing the u-boot services. Its other way around. Can the go command to
execute the standalone application embedded into the u-boot? Can we call
do_go() and execute the standalone application?




--
View this message in context: http://u-boot.10912.n7.nabble.com/u-boot-command-for-standalone-application-tp184818p184870.html
Sent from the U-Boot mailing list archive at Nabble.com.
Wolfgang Denk
2014-07-24 18:10:51 UTC
Permalink
Dear swami91,
Post by swami91
Sorry the confusion. Actually my question is not standalone application
accessing the u-boot services. Its other way around. Can the go command to
execute the standalone application embedded into the u-boot? Can we call
do_go() and execute the standalone application?
You can do this, if you really think this needs to be done.

Instread of hard-cosing such stuff, it is probably way more flexible
(and does not require to write any code at all) if you use U-Boot's
scripting capabilities and store this command in the environment.

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
It's a small world, but I wouldn't want to paint it.
swami91
2014-07-24 18:54:48 UTC
Permalink
Thanks Wolfgang.

Just curious.

Why is that dynamically load proprietary library and call APIs in it from
u-boot is violating GPL when Linux allows loadable modules that can be
proprietary? Is'nt this same mechanism?





--
View this message in context: http://u-boot.10912.n7.nabble.com/u-boot-command-for-standalone-application-tp184818p184878.html
Sent from the U-Boot mailing list archive at Nabble.com.
Wolfgang Denk
2014-07-24 19:42:41 UTC
Permalink
Dear swami91,
Post by swami91
Why is that dynamically load proprietary library and call APIs in it from
u-boot is violating GPL when Linux allows loadable modules that can be
proprietary? Is'nt this same mechanism?
Who says that binary-only modules in Linux are not violating the GPL?
I think they do. And many kernel hackers have a pretty clear position
about this. It has just never been taken to court yet...

But you know: IANAL...

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
If a group of N persons implements a COBOL compiler, there will be
N-1 passes. Someone in the group has to be the manager. - T. Cheatham
Ian Campbell
2014-07-24 19:42:57 UTC
Permalink
Post by swami91
Thanks Wolfgang.
Just curious.
Why is that dynamically load proprietary library and call APIs in it from
u-boot is violating GPL when Linux allows loadable modules that can be
proprietary? Is'nt this same mechanism?
Several of the core Linux developers disagree (and do, often) that such
things are allowed.

You should be consulting a lawyer a lawyer who is familiar with the GPL,
not a bunch of programmers on a mailing list.

Ian.

swami91
2014-07-24 14:39:16 UTC
Permalink
Post by Wolfgang Denk
Even if you hard-code addresses in the U-Boot image you would be
violating the GPL. A non-GPL standalone application must be really
what the name suggests: standalone. It gets only a very narrow,
stricltly limited set of services - just enough to ger some early
initialization and debugging done. All the rest, including drivers
and services, mut be re-implemented in your own proprietary image.
Is there any way of passing some data from outside of u-boot to u-boot
without violating the GPL? Should the data be released as part of GPL? So if
u-boot accesses some memory the content of that memory outside of its
control should be released as GPL? Looks odd..



--
View this message in context: http://u-boot.10912.n7.nabble.com/u-boot-command-for-standalone-application-tp184818p184872.html
Sent from the U-Boot mailing list archive at Nabble.com.
Wolfgang Denk
2014-07-24 18:09:36 UTC
Permalink
Dear swami91,
Post by swami91
Is there any way of passing some data from outside of u-boot to u-boot
without violating the GPL? Should the data be released as part of GPL? So if
u-boot accesses some memory the content of that memory outside of its
control should be released as GPL? Looks odd..
GPL is about code, not data.

You can invent any method you like to pass data. Conventional methods
used so far ar:

- import environment settings (which can include scripts, or can be
used in scripts) from files loaded into RAM;
- extract information from device tree blobs;
- extract information from images;
- just load a blob of data and use your own code to process it (like
to load it as firmware into some peripheral);
etc.

The possibilities are only limited by your phantasy.

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
I can type faster than I can move a mouse, so I find menu-driven
drawing packages time consuming and frustrating. - W. R. Stevens
Loading...