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

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

[Karsten Merker]

Hello,

I have today read the patch by Hans de Goede to add a dts file
for the "Banana Pi" development board (see
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276339.html)
and have stumbled over the license declaration at the beginning:

> +/*
> + * Copyright 2014 Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */

The phrase "The code contained herein is licensed under the GNU
General Public License" does not make explicitly clear under
which version(s) of the GPL the code can be used.  From the
following "You may obtain a copy of the GNU General Public
License Version 2 or later at the following locations [...]" one
can deduce that the intention is most probably to license the
code unter GPL2+, but from a legal point of view this information
should be an explicit part of the license statement itself, as
strictly formally speaking the latter statement does only inform
the reader where he can find the text of GPL2 and later GPL
versions, but does not expressly apply them to the code.  This is
of course a rather formalistic view and may well be seen as
beancounting, but I have seen too many cases where formal license
ambiguities have led to problems years later, so I proposed to
Hans to change the wording in his patch to something more
explicit, similar to the dts files for other arm platforms.

A phrasing like used in the GPL appendix ("This program is
free software; you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your
option) any later version") would avoid any ambiguity.

Hans agreed that the current phrasing is not ideal and should
probably be changed to something unabiguous but pointed out that a
similar wording is used in all the other dts files for Allwinner
SOCs (arch/arm/boot/dts/sun?i-a*.dts) and proposed to refer the
issue to you as the Allwinner platform maintainer (with the
linux-arm-kernel and devicetree lists in CC).

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3109 bytes --]

Hi,

On Thu, Jul 31, 2014 at 09:20:16PM +0200, Karsten Merker wrote:
> Hello,
> 
> I have today read the patch by Hans de Goede to add a dts file
> for the "Banana Pi" development board (see
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276339.html)
> and have stumbled over the license declaration at the beginning:
> 
> > +/*
> > + * Copyright 2014 Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > + *
> > + * The code contained herein is licensed under the GNU General Public
> > + * License. You may obtain a copy of the GNU General Public License
> > + * Version 2 or later at the following locations:
> > + *
> > + * http://www.opensource.org/licenses/gpl-license.html
> > + * http://www.gnu.org/copyleft/gpl.html
> > + */
> 
> The phrase "The code contained herein is licensed under the GNU
> General Public License" does not make explicitly clear under
> which version(s) of the GPL the code can be used.  From the
> following "You may obtain a copy of the GNU General Public
> License Version 2 or later at the following locations [...]" one
> can deduce that the intention is most probably to license the
> code unter GPL2+, but from a legal point of view this information
> should be an explicit part of the license statement itself, as
> strictly formally speaking the latter statement does only inform
> the reader where he can find the text of GPL2 and later GPL
> versions, but does not expressly apply them to the code.  This is
> of course a rather formalistic view and may well be seen as
> beancounting, but I have seen too many cases where formal license
> ambiguities have led to problems years later, so I proposed to
> Hans to change the wording in his patch to something more
> explicit, similar to the dts files for other arm platforms.
> 
> A phrasing like used in the GPL appendix ("This program is
> free software; you can redistribute it and/or modify it under the
> terms of the GNU General Public License as published by the Free
> Software Foundation; either version 2 of the License, or (at your
> option) any later version") would avoid any ambiguity.
> 
> Hans agreed that the current phrasing is not ideal and should
> probably be changed to something unabiguous but pointed out that a
> similar wording is used in all the other dts files for Allwinner
> SOCs (arch/arm/boot/dts/sun?i-a*.dts) and proposed to refer the
> issue to you as the Allwinner platform maintainer (with the
> linux-arm-kernel and devicetree lists in CC).

Thanks for reporting this.

From a quick grep, the issue is actually broader than just
Allwinner. At least the following platforms seem to do the same:
  - mvebu
  - axm5516
  - bcm
  - berlin
  - ea3250
  - ecx-2000
  - highbank
  - imx / mxs
  - lpc32xx
  - phy3250
  - picoxcell
  - shmobile
  - rockchip
  - socfpga
  - spear
  - ste
  - zynq

Would you mind sending a patch to fix all these?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Arnd Bergmann]

On Sunday 03 August 2014, Maxime Ripard wrote:
> Thanks for reporting this.
> 
> From a quick grep, the issue is actually broader than just
> Allwinner. At least the following platforms seem to do the same:
>   - mvebu
>   - axm5516
>   - bcm
>   - berlin
>   - ea3250
>   - ecx-2000
>   - highbank
>   - imx / mxs
>   - lpc32xx
>   - phy3250
>   - picoxcell
>   - shmobile
>   - rockchip
>   - socfpga
>   - spear
>   - ste
>   - zynq
> 
> Would you mind sending a patch to fix all these?

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.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

On Sun, Aug 03, 2014 at 07:59:27PM +0200, Arnd Bergmann wrote:
> On Sunday 03 August 2014, Maxime Ripard wrote:
> > Thanks for reporting this.
> > 
> > From a quick grep, the issue is actually broader than just
> > Allwinner. At least the following platforms seem to do the same:
> >   - mvebu
> >   - axm5516
> >   - bcm
> >   - berlin
> >   - ea3250
> >   - ecx-2000
> >   - highbank
> >   - imx / mxs
> >   - lpc32xx
> >   - phy3250
> >   - picoxcell
> >   - shmobile
> >   - rockchip
> >   - socfpga
> >   - spear
> >   - ste
> >   - zynq
> > 
> > Would you mind sending a patch to fix all these?
> 
> 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.

The same argument could be made for example for u-boot modifying a
DTB I guess.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Russell King - ARM Linux]

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.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Arnd Bergmann]

On Monday 04 August 2014, 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.

They already do, at least FreeBSD.

> 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 think this is exactly what is happening on the platforms that FreeBSD
first adopted DT on.

> I suspect the final option is the one they'd choose, and it's in our
> interest that that doesn't happen.

Right, or at least not have it spread to other platforms.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2267 bytes --]

On Thu, Aug 07, 2014 at 03:20:23PM +0200, Maxime Ripard wrote:
> 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?

Ping?

Are we doing this on a per platform basis? Should we enforce this dual
licensing for the future DTS patches? If so, starting from when?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Russell King - ARM Linux]

On Tue, Sep 02, 2014 at 12:22:06PM +0200, Maxime Ripard wrote:
> On Thu, Aug 07, 2014 at 03:20:23PM +0200, Maxime Ripard wrote:
> > 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?
> 
> Ping?
> 
> Are we doing this on a per platform basis? Should we enforce this dual
> licensing for the future DTS patches? If so, starting from when?

I have no answers to your questions - I put the question a number of
times to Grant directly, and have been totally ignored.

So, I think we just do whatever we think is the correct approach.

Remember, when you change the licensing on something which has had
multiple contributors, you need to seek the permission from everyone
how contributed to it - so it will have to be done on a per platform
and per-SoC basis.

I would also strongly suggest that future DTS files should be dual
licensed from the start, and that we require contributions for the
DTS files to be under both licenses.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

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

[Chen-Yu Tsai]

On Tue, Sep 2, 2014 at 6:40 PM, Russell King - ARM Linux
<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> On Tue, Sep 02, 2014 at 12:22:06PM +0200, Maxime Ripard wrote:
>> On Thu, Aug 07, 2014 at 03:20:23PM +0200, Maxime Ripard wrote:
>> > 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?
>>
>> Ping?
>>
>> Are we doing this on a per platform basis? Should we enforce this dual
>> licensing for the future DTS patches? If so, starting from when?
>
> I have no answers to your questions - I put the question a number of
> times to Grant directly, and have been totally ignored.
>
> So, I think we just do whatever we think is the correct approach.
>
> Remember, when you change the licensing on something which has had
> multiple contributors, you need to seek the permission from everyone
> how contributed to it - so it will have to be done on a per platform
> and per-SoC basis.

Is there any particular order for any platform or SoC?
Maybe we have to do the dependencies (dtsi) first?

It seems skeleton.dtsi and skeleton64.dtsi don't have explicit license
headers. Do these 2 need to be addressed as well?

ChenYu

> I would also strongly suggest that future DTS files should be dual
> licensed from the start, and that we require contributions for the
> DTS files to be under both licenses.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3436 bytes --]

On Tue, Sep 02, 2014 at 11:40:02AM +0100, Russell King - ARM Linux wrote:
> On Tue, Sep 02, 2014 at 12:22:06PM +0200, Maxime Ripard wrote:
> > On Thu, Aug 07, 2014 at 03:20:23PM +0200, Maxime Ripard wrote:
> > > 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?
> > 
> > Ping?
> > 
> > Are we doing this on a per platform basis? Should we enforce this dual
> > licensing for the future DTS patches? If so, starting from when?
> 
> I have no answers to your questions - I put the question a number of
> times to Grant directly, and have been totally ignored.
> 
> So, I think we just do whatever we think is the correct approach.
> 
> Remember, when you change the licensing on something which has had
> multiple contributors, you need to seek the permission from everyone
> how contributed to it - so it will have to be done on a per platform
> and per-SoC basis.

Ack.

> I would also strongly suggest that future DTS files should be dual
> licensed from the start, and that we require contributions for the
> DTS files to be under both licenses.

So I guess like Chen-Yu suggested that we should change the license of
the DTSI first, and then the DTS. Otherwise, it wouldn't work very
well, I guess you can't really relicense a GPL-only file.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Hans de Goede]

Hi,

On 09/02/2014 02:27 PM, Maxime Ripard wrote:
> On Tue, Sep 02, 2014 at 11:40:02AM +0100, Russell King - ARM Linux wrote:
>> On Tue, Sep 02, 2014 at 12:22:06PM +0200, Maxime Ripard wrote:
>>> On Thu, Aug 07, 2014 at 03:20:23PM +0200, Maxime Ripard wrote:
>>>> 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?
>>>
>>> Ping?
>>>
>>> Are we doing this on a per platform basis? Should we enforce this dual
>>> licensing for the future DTS patches? If so, starting from when?
>>
>> I have no answers to your questions - I put the question a number of
>> times to Grant directly, and have been totally ignored.
>>
>> So, I think we just do whatever we think is the correct approach.
>>
>> Remember, when you change the licensing on something which has had
>> multiple contributors, you need to seek the permission from everyone
>> how contributed to it - so it will have to be done on a per platform
>> and per-SoC basis.
> 
> Ack.
> 
>> I would also strongly suggest that future DTS files should be dual
>> licensed from the start, and that we require contributions for the
>> DTS files to be under both licenses.
> 
> So I guess like Chen-Yu suggested that we should change the license of
> the DTSI first, and then the DTS. Otherwise, it wouldn't work very
> well, I guess you can't really relicense a GPL-only file.

IANAL, but mixing MIT (which I suggest use as the other license) and GPL
files in one binary (the generated dtb file) is fine AFAIK, this happens
all the time. The resulting binary is simple GPL licensed. So it would
make sense to start with dual licensing new boards right away even before
the dtsi has been relicensed. It won't make any practical difference
until the dtsi is relicensed, but it means less work later on.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]

On Tue, Sep 02, 2014 at 02:35:18PM +0200, Hans de Goede wrote:
> > So I guess like Chen-Yu suggested that we should change the license of
> > the DTSI first, and then the DTS. Otherwise, it wouldn't work very
> > well, I guess you can't really relicense a GPL-only file.
> 
> IANAL, but mixing MIT (which I suggest use as the other license) and GPL
> files in one binary (the generated dtb file) is fine AFAIK, this happens
> all the time. The resulting binary is simple GPL licensed. So it would
> make sense to start with dual licensing new boards right away even before
> the dtsi has been relicensed. It won't make any practical difference
> until the dtsi is relicensed, but it means less work later on.

So you're allowed to licence derivative work of a GPL-licenced file
under both the GPL and another licence?

And as far as MIT vs BSD is concerned, I don't really have an
opinion. Arnd? Russell?

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Arnd Bergmann]

On Tuesday 02 September 2014 14:51:16 Maxime Ripard wrote:
> On Tue, Sep 02, 2014 at 02:35:18PM +0200, Hans de Goede wrote:
> > > So I guess like Chen-Yu suggested that we should change the license of
> > > the DTSI first, and then the DTS. Otherwise, it wouldn't work very
> > > well, I guess you can't really relicense a GPL-only file.
> > 
> > IANAL, but mixing MIT (which I suggest use as the other license) and GPL
> > files in one binary (the generated dtb file) is fine AFAIK, this happens
> > all the time. The resulting binary is simple GPL licensed. So it would
> > make sense to start with dual licensing new boards right away even before
> > the dtsi has been relicensed. It won't make any practical difference
> > until the dtsi is relicensed, but it means less work later on.
> 
> So you're allowed to licence derivative work of a GPL-licenced file
> under both the GPL and another licence?
> 
> And as far as MIT vs BSD is concerned, I don't really have an
> opinion. Arnd? Russell?

libfdt uses BSD license, which would be a reason to use the same for
the dts files. Other than that, I don't think it matters either way.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Russell King - ARM Linux]

On Tue, Sep 02, 2014 at 02:51:16PM +0200, Maxime Ripard wrote:
> On Tue, Sep 02, 2014 at 02:35:18PM +0200, Hans de Goede wrote:
> > > So I guess like Chen-Yu suggested that we should change the license of
> > > the DTSI first, and then the DTS. Otherwise, it wouldn't work very
> > > well, I guess you can't really relicense a GPL-only file.
> > 
> > IANAL, but mixing MIT (which I suggest use as the other license) and GPL
> > files in one binary (the generated dtb file) is fine AFAIK, this happens
> > all the time. The resulting binary is simple GPL licensed. So it would
> > make sense to start with dual licensing new boards right away even before
> > the dtsi has been relicensed. It won't make any practical difference
> > until the dtsi is relicensed, but it means less work later on.
> 
> So you're allowed to licence derivative work of a GPL-licenced file
> under both the GPL and another licence?

The copyright owners of any work are permitted to release it under
whatever license(s) they deem appropriate.  These can be many licenses,
and need not be compatible with each other.  More careful handling of
contributions is required to ensure that the contributors are happy for
their submissions to be used under all licenses to avoid unintentional
forking the work.

> And as far as MIT vs BSD is concerned, I don't really have an
> opinion. Arnd? Russell?

I decided upon the X11 license (MIT produced several licenses, so
using "MIT" is ambiguous) rather than BSD (due to confusion over
the number of clauses.)

It's worth a read through http://www.gnu.org/licenses/license-list.html
if you haven't already before making a decision.

I think we should also have a statement that this only applies to the
DT files concerned, and nothing else, to ensure that nothing is
misconstrued.

I'll also drop Linus an email to see whether he has any concerns with
this.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Russell King - ARM Linux]

On Tue, Sep 02, 2014 at 02:37:13PM +0100, Russell King - ARM Linux wrote:
> I'll also drop Linus an email to see whether he has any concerns with
> this.

Okay, we (a few others on this thread and myself) have an answer from
Linus, which is agreement with this approach.  Linus (like me, and I
hope everyone else) would only have objection with BSD 4-clause.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Hans de Goede]

Hi,

On 09/02/2014 02:51 PM, Maxime Ripard wrote:
> On Tue, Sep 02, 2014 at 02:35:18PM +0200, Hans de Goede wrote:
>>> So I guess like Chen-Yu suggested that we should change the license of
>>> the DTSI first, and then the DTS. Otherwise, it wouldn't work very
>>> well, I guess you can't really relicense a GPL-only file.
>>
>> IANAL, but mixing MIT (which I suggest use as the other license) and GPL
>> files in one binary (the generated dtb file) is fine AFAIK, this happens
>> all the time. The resulting binary is simple GPL licensed. So it would
>> make sense to start with dual licensing new boards right away even before
>> the dtsi has been relicensed. It won't make any practical difference
>> until the dtsi is relicensed, but it means less work later on.
> 
> So you're allowed to licence derivative work of a GPL-licenced file
> under both the GPL and another licence?

Since the board files do not start as copies of the dtsi file, but
merely include it they are not derivative (IANAL), the resulting
dtb file however very much is and as such is GPL only.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]

On Tue, Sep 02, 2014 at 04:42:19PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 09/02/2014 02:51 PM, Maxime Ripard wrote:
> > On Tue, Sep 02, 2014 at 02:35:18PM +0200, Hans de Goede wrote:
> >>> So I guess like Chen-Yu suggested that we should change the license of
> >>> the DTSI first, and then the DTS. Otherwise, it wouldn't work very
> >>> well, I guess you can't really relicense a GPL-only file.
> >>
> >> IANAL, but mixing MIT (which I suggest use as the other license) and GPL
> >> files in one binary (the generated dtb file) is fine AFAIK, this happens
> >> all the time. The resulting binary is simple GPL licensed. So it would
> >> make sense to start with dual licensing new boards right away even before
> >> the dtsi has been relicensed. It won't make any practical difference
> >> until the dtsi is relicensed, but it means less work later on.
> > 
> > So you're allowed to licence derivative work of a GPL-licenced file
> > under both the GPL and another licence?
> 
> Since the board files do not start as copies of the dtsi file, but
> merely include it they are not derivative (IANAL), the resulting
> dtb file however very much is and as such is GPL only.

My understanding was that inclusion does qualify as a derivative
work. Otherwise we wouldn't need either the LGPL or the GCC licence
exception.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Russell King - ARM Linux]

On Tue, Sep 02, 2014 at 04:42:19PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 09/02/2014 02:51 PM, Maxime Ripard wrote:
> > On Tue, Sep 02, 2014 at 02:35:18PM +0200, Hans de Goede wrote:
> >>> So I guess like Chen-Yu suggested that we should change the license of
> >>> the DTSI first, and then the DTS. Otherwise, it wouldn't work very
> >>> well, I guess you can't really relicense a GPL-only file.
> >>
> >> IANAL, but mixing MIT (which I suggest use as the other license) and GPL
> >> files in one binary (the generated dtb file) is fine AFAIK, this happens
> >> all the time. The resulting binary is simple GPL licensed. So it would
> >> make sense to start with dual licensing new boards right away even before
> >> the dtsi has been relicensed. It won't make any practical difference
> >> until the dtsi is relicensed, but it means less work later on.
> > 
> > So you're allowed to licence derivative work of a GPL-licenced file
> > under both the GPL and another licence?
> 
> Since the board files do not start as copies of the dtsi file, but
> merely include it they are not derivative (IANAL), the resulting
> dtb file however very much is and as such is GPL only.

I'd also agree with the second half of what you said.

Let's take an example.  If a .dts file is licensed GPL and X11, but
a .dtsi it includes is licensed under the GPL, then the resulting
binary is definitely GPL-only - no questions asked.

If all the .dts and .dtsi files which are used to generate the .dtb
become licensed under the GPL and X11 licenses, then the resulting
.dtb itself becomes dual licensed.

If a .dtsi file is licensed under GPL and X11, but the .dts file is
only under the GPL, the result is GPL-only.

So, it's like a bitwise AND, with each license type being an
individual bit.

The first half is a more risky claim to make though - is the .dts file
itself something that could have been developed without the .dtsi?
Given that most .dts files reference things in the .dtsi files, I
believe the answer to that is no - which makes the .dts file a
derivative of the .dtsi.

What that would seem to imply is that the .dts files can't be dual
licensed until the .dtsi files it uses are dual licensed.

So, the "safe" approach here is to get the .dtsi files dual-licensed
first. :)

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Hans de Goede]

Hi,

On 08/04/2014 09:25 PM, Maxime Ripard wrote:
> On Sun, Aug 03, 2014 at 07:59:27PM +0200, Arnd Bergmann wrote:
>> On Sunday 03 August 2014, Maxime Ripard wrote:
>>> Thanks for reporting this.
>>>
>>> From a quick grep, the issue is actually broader than just
>>> Allwinner. At least the following platforms seem to do the same:
>>>   - mvebu
>>>   - axm5516
>>>   - bcm
>>>   - berlin
>>>   - ea3250
>>>   - ecx-2000
>>>   - highbank
>>>   - imx / mxs
>>>   - lpc32xx
>>>   - phy3250
>>>   - picoxcell
>>>   - shmobile
>>>   - rockchip
>>>   - socfpga
>>>   - spear
>>>   - ste
>>>   - zynq
>>>
>>> Would you mind sending a patch to fix all these?
>>
>> 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

+1 from me, I'm fine with all my dts patches being relicensed under a BSD / MIT
license.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Hans de Goede]

Hi,

On 08/04/2014 09:25 PM, Maxime Ripard wrote:
> On Sun, Aug 03, 2014 at 07:59:27PM +0200, Arnd Bergmann wrote:
>> On Sunday 03 August 2014, Maxime Ripard wrote:
>>> Thanks for reporting this.
>>>
>>> From a quick grep, the issue is actually broader than just
>>> Allwinner. At least the following platforms seem to do the same:
>>>   - mvebu
>>>   - axm5516
>>>   - bcm
>>>   - berlin
>>>   - ea3250
>>>   - ecx-2000
>>>   - highbank
>>>   - imx / mxs
>>>   - lpc32xx
>>>   - phy3250
>>>   - picoxcell
>>>   - shmobile
>>>   - rockchip
>>>   - socfpga
>>>   - spear
>>>   - ste
>>>   - zynq
>>>
>>> Would you mind sending a patch to fix all these?
>>
>> 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

p.s.

I've a patch adding a new dts file for the bananapi pending. I might as well
relicense that before submitting V2. So what shall we use 2 clause BSD or MIT ?

I've a slight preference for MIT, but both are fine.

Regards,

Hans




--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Russell King - ARM Linux]

On Sun, Aug 03, 2014 at 03:04:30PM +0200, Maxime Ripard wrote:
> From a quick grep, the issue is actually broader than just
> Allwinner. At least the following platforms seem to do the same:
>   - mvebu
>   - axm5516
>   - bcm
>   - berlin
>   - ea3250
>   - ecx-2000
>   - highbank
>   - imx / mxs
>   - lpc32xx
>   - phy3250
>   - picoxcell
>   - shmobile
>   - rockchip
>   - socfpga
>   - spear
>   - ste
>   - zynq
> 
> Would you mind sending a patch to fix all these?

A better question is whether they should even be solely under the GPL,
thereby preventing their use with other operating systems such as the
BSDs.

I feel that people haven't properly thought through the implications
with the DT files, and have just decided "the GPL is good enough for
the time being."  Well, if you have contributors to the DT files and
you later want to include them with other operating systems which are
not GPL licensed, then you have a problem.

I've tried bringing this up with Grant on a couple of occasions, and
so far I've been completely ignored.  I'm intending to place my
Cubox-i/Hummingboard DT files under the GPL and a non-GPL license
which allows their re-use elsewhere - I haven't decided what the
other license should be, but I'm considering the X11 license as that
allows the broadest re-use of the DT files.

As I see it, there is no "value" in restricting the DT files to be
GPL only and if others find them helpful to use elsewhere, then that's
what should happen.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html