Formal license ambiguity in arch/arm/boot/dts/sun?i-a*.dts

[maxime.ripard@free-electrons.com (Maxime Ripard)]

Hi Russell,

On Mon, Aug 04, 2014 at 10:23:17PM +0100, Russell King - ARM Linux wrote:
> On Mon, Aug 04, 2014 at 09:25:10PM +0200, Maxime Ripard wrote:
> > On Sun, Aug 03, 2014 at 07:59:27PM +0200, Arnd Bergmann wrote:
> > > I would actually prefer if we could migrate a lot of these files to BSD license,
> > > provided the original authors agree. We want the dtb blobs to be embeddable into
> > > boot loaders of any license.
> > 
> > Even though I'd be open to having my contributions to DTBs under the
> > BSD, is this really a thing?
> > 
> > I mean, for all I know, an OS/Bootloader would just parse a documented
> > binary file, and I don't see any derivative work there.
> 
> How does the OS/Bootloader end up with that binary file?
> 
> For the sake of argument, let's say that the BSDs want to move to DT on
> ARM.  Great, they convert over to parsing our DT blobs.
> 
> However, they can't distribute the binary DT blobs to their users without
> coming up against the problems of the GPL wrt binary distribution.
> 
> They could distribute the source files, but remember that many of those
> are currently GPL licensed, so they'd probably end up having to package
> them entirely separately, if they're willing to do that at all.
> 
> Or they could decide to ignore us altogether, and do their own DT stuff,
> maybe partially implementing our properties, or maybe coming up with
> different and/or incompatible properties - which would be bad because
> we now end up with two ways to describe the same hardware in active use.
> 
> I suspect the final option is the one they'd choose, and it's in our
> interest that _that_ doesn't happen.

Ah, yes, it's not really about a fear of a GPL-spread, but rather a
concern about the source distribution. Makes sense.

How should we deal with such relicensing?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140807/0b00c1f4/attachment.sig>