[Buildroot] Is GPLv2 the right license for Buildroot?

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Tue Sep 17 04:17:40 UTC 2013


Dear Yann E. MORIN,

On Mon, 16 Sep 2013 22:04:20 +0200, Yann E. MORIN wrote:

> Also, I would like to reiterate my suggestion the vriable BR2_EXTERNAL
> contains a list (space- or colon-sperated, as you wish) of external
> trees to descend into, rather than containing a single entry.

Unfortunately, I don't think this is easy to do. Have you seen how the
BR2_EXTERNAL/Config.in gets included in the top-level menu? The way
we're doing this in the current implementation doesn't make it easy to
have several paths in BR2_EXTERNAL.

> A side question to this: what if any of the external tree(s) contain a
> package already in a previous external tree or in the original
> Buildroot tree?

I don't think we want to support overlay-ing packages.

> > But it isn't quite sufficient: by your definition, the
> > Buildroot .config should also be shipped, and it also contains
> > config options for the company-specific proprietary packages. So
> > the .config should be "filtered" before being released. Not simple.
> 
> I think that is relatively easy: in the Buildroot tree, just run:
>     make BR2_EXTERNAL= oldconfig
> 
> That will expunge the .config from any variable from the BR2_EXTERNAL
> tree. You can then tar up the Buildroot tree, and make that available.
> Quite easy, but requires a process that documents this simple extra
> step prior to publication.

Hum, right, makes sense.

> > Aren't companies going to be afraid of revealing too much of their
> > secret sauce if they have to disclose their Buildroot tree?
> 
> Depends on what you call "their secret sauce". If you meant "their
> prorietary apps packaged in Buildroot" then, curently, yes, since
> those would be in the Buildroot tree. But with BR2_EXTERNAL (and the
> little oldconfig trick above), that'd be straightforward.
> 
> If you meant "the fact that they actually use Buildroot", then I don;t
> think how this could be seen as a "secret sauce".

I was talking about their proprietary apps / rootfs overlay, etc. Which
indeed with BR2_EXTERNAL they can keep separate.

> > If it's considered as a derived work, then your above idea of using
> > BR2_EXTERNAL to split things between secret stuff and released
> > stuff no longer works.
> 
> Well, yes it still stands. The GPL only applies at the time of
> distribution. So if BR2_EXTERNAL only contains recipes for
> weak-copyleft or non-copyleft packages,

Yes, and this *if* is very important.

> then there is no need for the
> company to distribute it, since the "official" Buildroot tree is
> enough to reproduce the GPL program(s) on the target.
> 
> This applies, of course, only if the company decides to publish
> Buildroot to catter for section 3 of the GPL of those programs.
> 
> If the company decides for another route, then this point is moot
> anyway, since there is no distribution at all.

Sure.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


More information about the buildroot mailing list