[PATCH 08/27] ARM: mvebu: armada-370-xp: Relicense the device tree under GPLv2+/X11

Gregory CLEMENT gregory.clement at free-electrons.com
Tue Dec 16 10:31:30 PST 2014


On 16/12/2014 15:45, Jason Cooper wrote:
> On Tue, Dec 16, 2014 at 02:37:19PM +0100, Simon Guinot wrote:
>> On Tue, Dec 16, 2014 at 08:03:31AM -0500, Jason Cooper wrote:
>>> Simon,
>>>
>>> On Tue, Dec 16, 2014 at 12:22:21AM +0100, Simon Guinot wrote:
>>>> On Mon, Dec 15, 2014 at 04:38:16PM +0100, Gregory CLEMENT wrote:
>>>>> The current GPL only licensing on the device tree makes it very
>>>>> impractical for other software components licensed under another
>>>>> license.
>>>>>
>>>>> In order to make it easier for them to reuse our device trees,
>>>>> relicense our device trees under a GPL/X11 dual-license.
>>>>>
>>>>> Cc: Andrew Lunn <andrew at lunn.ch>
>>>>> Cc: Arnaud Ebalard <arno at natisbad.org>
>>>>> Cc: Ezequiel Garcia <ezequiel.garcia at free-electrons.com>
>>>>> Cc: Greg Ungerer <gerg at uclinux.org>
>>>>> Cc: Heikki Krogerus <heikki.krogerus at linux.intel.com>
>>>>> Cc: Jason Cooper <jason at lakedaemon.net>
>>>>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
>>>>> Cc: Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
>>>>> Cc: Simon Baatz <gmbnomis at gmail.com>
>>>>> Cc: Simon Guinot <simon.guinot at sequanux.org>
>>>>> Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
>>>>> Cc: Willy Tarreau <w at 1wt.eu>
>>>>> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
>>>>> ---
>>>>>  arch/arm/boot/dts/armada-370-xp.dtsi | 40 +++++++++++++++++++++++++++++++++---
>>>>>  1 file changed, 37 insertions(+), 3 deletions(-)
>>>>
>>>> Hi Gregory,
>>>>
>>>> NAK for me.
>>>
>>> Well, I'm a bit surprised that this is the first one. :)  Care to
>>> explain why so that we can work towards an amenable compromise?
>>
>> Hi Jason,
>>
>> I am also a bit surprised to be the only one :)
>>
>> As I have no interest in a flame war either, I am not gonna elaborate
>> on this. But in a few words, I don't think that allowing a permissive
>> licence alternative is good for software sharing (which is important
>> to me). 
> 
> Ok, fair enough.  I just needed to know if the NAK was against the
> GPLv2+ part or the X11 part.  Clearly, it's the X11 part.
> 
> So let's look at what we have (trying to stick to facts):
> 
> - alienating contributors in bad (yes, this is first)
> - sometimes the community has to do something a minority disagrees with,
>   but it should be avoided, if at all possible.
> - devicetree is so useful, other projects are adopting it
> - if our binding docs are good, rewriting dts{i} isn't hard.
> - rewriting dts{i} can lead to fragmentation
> - maintaining two devicetree trees would be a pia (X11, GPLonly)
> - reverting/rewriting GPLonly commits is possible, but see first bullet.
> - Simon may not be the only contributor who disagrees with X11.
> - of the known consumers of dts{i}, *BSD is the only one with licensing
>   issues.
> 
> So our goal is to avoid fragmentation by allowing *BSD to use our dts{i}
> files as is.  Our secondary goal is to avoid a maintenance headache.
> 
> Options:
> 
> - Ask Simon to find an OSI-compatible license to replace X11 that:
>    - *BSD can use
>    - meets the intent of himself and other like-minded authors
> - Leave licensing as is, but make a statement that *using* the dts
>   doesn't create a derivative work under the GPL (similar to Linus'
>   statement re the Linux kernel, Wolfgang and U-Boot, etc).
> - Screw it, plow forward, and revert/rewrite GPLonly commits
> - Ignore the whole issue and hope it goes away.
> 

Thanks for sum-up the situation and to offer the different choice we have.

> Personally, I'm in favor of the second one, and think it has the highest
> chance of success.  After all, ARM-based *BSD is launched from a GPL
> bootloader in most cases, right (U-Boot, barebox)?  Thoughts?

Presently I would like to have the answer about the relicesing from all the
author in CC. Then depending the result we will see where we should go.

Gregory

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



More information about the linux-arm-kernel mailing list