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.
On Friday 24 February 2012 13:10:36 Michael Walle wrote:
As far as i know applications can use functions defined in exports.h without being licensed under the GPL.
correct, that is what the COPYING file states
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.
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
Am Freitag 24 Februar 2012, 20:17:19 schrieb Mike Frysinger:
On Friday 24 February 2012 13:10:36 Michael Walle wrote:
As far as i know applications can use functions defined in exports.h without being licensed under the GPL.
correct, that is what the COPYING file states
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.
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
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?
On Friday 24 February 2012 14:48:51 Michael Walle wrote:
Am Freitag 24 Februar 2012, 20:17:19 schrieb Mike Frysinger:
On Friday 24 February 2012 13:10:36 Michael Walle wrote:
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.
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
Dear Michael Walle,
In message 201202242048.51624.michael@walle.cc you wrote:
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.
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
participants (3)
-
Michael Walle -
Mike Frysinger -
Wolfgang Denk