exports.h and the GPL
Hi,
As far as i know applications can use functions defined in exports.h without being licensed under the GPL.
Who is responsible to define which functions are exported? Are the currently exported functions the only ones available to closed source applications or is it possible to add further ones which are needed.
Functions may need arguments which are pointers to some structures. These structures are likely be defined in some GPL'ed header file and must not be used, i guess? So the exported functions must only use integral data types, opaque pointers and structures which are not defined in a GPL'ed header file.
I'm aware of the fact that I won't get any legal advice, I'm just asking for your opinions.
Signature · 1 line
Michael
Quoted 2 lines · On Friday 24 February 2012 13:10:36 Michael Walle wrote:
As far as i know applications can use functions defined in
exports.hwithout being licensed under the GPL.
correct, that is what the COPYING file states
Quoted 3 lines
Who is responsible to define which functions are exported? Are the currently exported functions the only ones available to closed source applications or is it possible to add further ones which are needed.
someone posts a request and the maintainers evaluate it. typically the exported funcs should be "high level" and not hooks into u-boot internals.
Quoted 5 lines
Functions may need arguments which are pointers to some structures. These structures are likely be defined in some GPL'ed header file and must not be used, i guess? So the exported functions must only use integral data types, opaque pointers and structures which are not defined in a GPL'ed header file.
which is why the exported funcs are "high level" and not ones that get into low level stuff that would necessitate passing structs. the other problem with struct passing is that they tend to break the ABI layer.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120224/e0c09f02/attachment.pgp>
Am Freitag 24 Februar 2012, 20:17:19 schrieb Mike Frysinger:
Quoted 19 lines · On Friday 24 February 2012 13:10:36 Michael Walle wrote:
Quoted 2 lines
As far as i know applications can use functions defined in
exports.hwithout being licensed under the GPL.correct, that is what the COPYING file states
Quoted 3 lines
Who is responsible to define which functions are exported? Are the currently exported functions the only ones available to closed source applications or is it possible to add further ones which are needed.
someone posts a request and the maintainers evaluate it. typically the exported funcs should be "high level" and not hooks into u-boot internals.
Quoted 5 lines
Functions may need arguments which are pointers to some structures. These structures are likely be defined in some GPL'ed header file and must not be used, i guess? So the exported functions must only use integral data types, opaque pointers and structures which are not defined in a GPL'ed header file.
Quoted 4 lines
which is why the exported funcs are "high level" and not ones that get into low level stuff that would necessitate passing structs. the other problem with struct passing is that they tend to break the ABI layer. -mike
Then i guess there is no way to support a board which has only evil closed source drivers for its networking card. That is, i can't export eth_register() to register my ops defined in the blob without violating the GPL.
Even if the headers for the "struct eth_device" were public domain, this mechanism would be sth like 'linking' against the uboot, wouldn't it?
Signature · 1 line
Michael
Quoted 6 lines · On Friday 24 February 2012 14:48:51 Michael Walle wrote:
Am Freitag 24 Februar 2012, 20:17:19 schrieb Mike Frysinger:
Quoted 5 lines · On Friday 24 February 2012 13:10:36 Michael Walle wrote:
Quoted 3 lines
Who is responsible to define which functions are exported? Are the currently exported functions the only ones available to closed source applications or is it possible to add further ones which are needed.
Quoted 8 lines
Quoted 3 lines
someone posts a request and the maintainers evaluate it. typically the exported funcs should be "high level" and not hooks into u-boot internals.
Then i guess there is no way to support a board which has only evil closed source drivers for its networking card. That is, i can't export
eth_register()to register my ops defined in the blob without violating the GPL.
that certainly goes against the spirit of the export logic (imo) so i'd be against it. the export layer isn't there to support closed sourced drivers the rest of u-boot would utilize.
you could ask Wolfgang, but i suspect he will say no.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120224/40ada51b/attachment.pgp>
Dear Michael Walle,
Quoted 9 lines · In message <[email protected]> you wrote:
Quoted 5 lines
which is why the exported funcs are "high level" and not ones that get into low level stuff that would necessitate passing structs. the other problem with struct passing is that they tend to break the ABI layer. -mike
Then i guess there is no way to support a board which has only evil closed source drivers for its networking card. That is, i can't export
eth_register()to register my ops defined in the blob without violating the GPL.
As Mike already explained, this is correct. And it is intentional.
Quoted 2 lines
Even if the headers for the "struct
eth_device" were public domain, this mechanism would be sth like 'linking' against the uboot, wouldn't it?
Yes, indeed.
You are not supposed to mix closed-source drivers with GPL code. The best approach is probably to re-write the drivers under GPL.
Best regards,
Wolfgang Denk
Signature · 5 lines
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
The price of curiosity is a terminal experience.
- Terry Pratchett, _The Dark Side of the Sun_