[U-Boot] exports.h and the GPL

[U-Boot] exports.h and the GPL

[Michael Walle]

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.

-- 
Michael

[U-Boot] exports.h and the GPL

[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
-------------- 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>

[U-Boot] exports.h and the GPL

[Michael Walle]

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?

-- 
Michael

[U-Boot] exports.h and the GPL

[Mike Frysinger]

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
-------------- 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>

[U-Boot] exports.h and the GPL

[Wolfgang Denk]

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

-- 
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_