From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 08/27] ARM: mvebu: armada-370-xp: Relicense the device tree under GPLv2+/X11
Date: Tue, 16 Dec 2014 21:06:45 +0100 [thread overview]
Message-ID: <2343908.plBCRoX2ek@wuerfel> (raw)
In-Reply-To: <20141216185550.GQ967@titan.lakedaemon.net>
On Tuesday 16 December 2014 13:55:50 Jason Cooper wrote:
> On Tue, Dec 16, 2014 at 07:31:30PM +0100, Gregory CLEMENT wrote:
> > 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:
> > >>> On Tue, Dec 16, 2014 at 12:22:21AM +0100, Simon Guinot wrote:
> > >>>> 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.
>
> Agreed. We should keep in mind that once we have heard from everybody
> (big if), that is still only representative of armada and maybe mvebu
> ecosystem. I'm starting to lean even more towards #2...
Looking at the commits that Simon did, it covers all the Lacie .dts files,
and one single-line change to armada-370-xp.dtsi.
I think it's definitely best to respect Simon's view on the Lacie files
and not try to undo or rewrite those. With the one-line change, there
are other options:
- Ask Simon to agree to a license change for that file
- Argue that a one-line change cannot be covered under copyright and
change the license anyway.
- Change that line again and modify the driver accordingly
Arnd
next prev parent reply other threads:[~2014-12-16 20:06 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-15 15:38 [PATCH 00/27] ARM: mvebu: armada-*: Relicense the device tree under GPLv2+/X11 Gregory CLEMENT
2014-12-15 15:38 ` [PATCH 01/27] ARM: mvebu: armada-370-db: " Gregory CLEMENT
2014-12-15 17:57 ` Arnaud Ebalard
2014-12-15 15:38 ` [PATCH 02/27] ARM: mvebu: armada-370: " Gregory CLEMENT
2014-12-15 17:57 ` Arnaud Ebalard
2014-12-15 18:59 ` Uwe Kleine-König
2014-12-15 15:38 ` [PATCH 03/27] ARM: mvebu: armada-370-mirabox: " Gregory CLEMENT
2014-12-15 17:57 ` Arnaud Ebalard
2014-12-15 15:38 ` [PATCH 04/27] ARM: mvebu: armada-370-netgear-rn102: " Gregory CLEMENT
2014-12-15 17:57 ` Arnaud Ebalard
2014-12-16 6:58 ` Ben Peddell
2014-12-15 15:38 ` [PATCH 05/27] ARM: mvebu: armada-370-netgear-rn104: " Gregory CLEMENT
2014-12-15 17:57 ` Arnaud Ebalard
2014-12-15 15:38 ` [PATCH 06/27] ARM: mvebu: armada-370-rd: " Gregory CLEMENT
2014-12-15 16:59 ` Florian Fainelli
2014-12-15 17:08 ` Gregory CLEMENT
2014-12-15 17:57 ` Arnaud Ebalard
2014-12-15 18:32 ` Andrew Lunn
2014-12-15 15:38 ` [PATCH 07/27] ARM: mvebu: armada-370-synology-ds213j: " Gregory CLEMENT
2014-12-15 17:58 ` Arnaud Ebalard
2014-12-15 15:38 ` [PATCH 08/27] ARM: mvebu: armada-370-xp: " Gregory CLEMENT
2014-12-15 15:53 ` Willy Tarreau
2014-12-15 15:58 ` Gregory CLEMENT
2014-12-15 17:58 ` Arnaud Ebalard
2014-12-15 18:33 ` Andrew Lunn
2014-12-15 23:22 ` Simon Guinot
2014-12-16 13:03 ` Jason Cooper
2014-12-16 13:37 ` Simon Guinot
2014-12-16 14:45 ` Jason Cooper
2014-12-16 18:31 ` Gregory CLEMENT
2014-12-16 18:55 ` Jason Cooper
2014-12-16 20:03 ` Russell King - ARM Linux
2014-12-16 20:09 ` Jason Cooper
2014-12-16 20:06 ` Arnd Bergmann [this message]
2014-12-16 18:44 ` Russell King - ARM Linux
2014-12-16 20:30 ` Jason Cooper
2014-12-16 20:38 ` Russell King - ARM Linux
2014-12-18 17:56 ` Simon Guinot
2014-12-18 17:59 ` Gregory CLEMENT
2014-12-16 0:20 ` Greg Ungerer
2015-01-26 10:11 ` Lorenzo Pieralisi
2015-01-26 10:13 ` Gregory CLEMENT
2014-12-15 15:38 ` [PATCH 09/27] ARM: mvebu: armada-375-db: " Gregory CLEMENT
2014-12-15 15:38 ` [PATCH 10/27] ARM: mvebu: armada-375: " Gregory CLEMENT
2014-12-15 15:38 ` [PATCH 11/27] ARM: mvebu: armada-380: " Gregory CLEMENT
2014-12-15 15:38 ` [PATCH 12/27] ARM: mvebu: armada-385-db: " Gregory CLEMENT
2014-12-15 15:38 ` [PATCH 13/27] ARM: mvebu: armada-385: " Gregory CLEMENT
2014-12-15 15:38 ` [PATCH 14/27] ARM: mvebu: armada-385-rd: " Gregory CLEMENT
2014-12-15 15:38 ` [PATCH 15/27] ARM: mvebu: armada-38x: " Gregory CLEMENT
2014-12-15 15:38 ` [PATCH 16/27] ARM: mvebu: armada-xp-axpwifiap: " Gregory CLEMENT
2014-12-15 17:58 ` Arnaud Ebalard
2014-12-15 15:38 ` [PATCH 17/27] ARM: mvebu: armada-xp-db: " Gregory CLEMENT
2014-12-15 15:38 ` [PATCH 18/27] ARM: mvebu: armada-xp: " Gregory CLEMENT
2014-12-15 15:53 ` Willy Tarreau
2014-12-15 17:58 ` Arnaud Ebalard
2014-12-15 15:38 ` [PATCH 19/27] ARM: mvebu: armada-xp-gp: " Gregory CLEMENT
2014-12-15 15:38 ` [PATCH 20/27] ARM: mvebu: armada-xp-lenovo-ix4-300d: " Gregory CLEMENT
[not found] ` <CAGHj7OKw00-YCoekDHWrz1_eu0kfxVpqNPVcKcKY0rVJ=FhT=g@mail.gmail.com>
2014-12-15 16:32 ` Gregory CLEMENT
2014-12-15 17:58 ` Arnaud Ebalard
2014-12-15 15:38 ` [PATCH 21/27] ARM: mvebu: armada-xp-matrix: " Gregory CLEMENT
2014-12-15 15:38 ` [PATCH 22/27] ARM: mvebu: armada-xp-mv78230: " Gregory CLEMENT
2014-12-15 17:58 ` Arnaud Ebalard
2014-12-15 18:35 ` Andrew Lunn
2014-12-15 15:38 ` [PATCH 23/27] ARM: mvebu: armada-xp-mv78260: " Gregory CLEMENT
2014-12-15 15:53 ` Willy Tarreau
2014-12-15 17:59 ` Arnaud Ebalard
2014-12-15 15:38 ` [PATCH 24/27] ARM: mvebu: armada-xp-mv78460: " Gregory CLEMENT
2014-12-15 15:54 ` Willy Tarreau
2014-12-15 15:38 ` [PATCH 25/27] ARM: mvebu: armada-xp-netgear-rn2120: " Gregory CLEMENT
2014-12-15 17:59 ` Arnaud Ebalard
2014-12-15 15:38 ` [PATCH 26/27] ARM: mvebu: armada-xp-openblocks-ax3-4: " Gregory CLEMENT
2014-12-15 15:38 ` [PATCH 27/27] ARM: mvebu: armada-xp-synology-ds414: " Gregory CLEMENT
2014-12-15 17:59 ` Arnaud Ebalard
2014-12-15 16:07 ` [PATCH 00/27] ARM: mvebu: armada-*: " Jason Cooper
2014-12-15 16:27 ` Gregory CLEMENT
2014-12-15 19:10 ` Imre Kaloz
2014-12-15 17:21 ` Sebastian Hesselbarth
2014-12-15 20:56 ` Simon Baatz
2014-12-17 20:51 ` Ezequiel Garcia
2014-12-17 21:17 ` Thomas Petazzoni
2014-12-18 10:15 ` Philipp Zabel
2014-12-18 17:15 ` Gregory CLEMENT
2014-12-18 19:15 ` Jason Cooper
2014-12-19 14:36 ` Gregory CLEMENT
2014-12-19 16:02 ` Jason Cooper
2014-12-19 16:09 ` Gregory CLEMENT
2014-12-19 17:03 ` Jason Cooper
2014-12-19 17:11 ` Gregory CLEMENT
2014-12-19 17:43 ` Jason Cooper
2014-12-19 18:16 ` Simon Guinot
2014-12-21 23:50 ` Jason Cooper
2014-12-22 11:29 ` Simon Guinot
2014-12-22 11:29 ` Simon Guinot
2014-12-22 19:14 ` Andrew Lunn
2014-12-22 19:14 ` Andrew Lunn
2014-12-22 21:14 ` Arnd Bergmann
2014-12-22 21:14 ` Arnd Bergmann
2014-12-23 12:22 ` Simon Guinot
2014-12-23 12:22 ` Simon Guinot
2014-12-30 15:17 ` Jason Cooper
2014-12-30 15:17 ` Jason Cooper
2014-12-30 15:12 ` Jason Cooper
2014-12-30 15:12 ` Jason Cooper
2015-01-05 12:03 ` Gregory CLEMENT
2015-01-06 2:05 ` Ryan Press
2015-01-06 8:42 ` Gregory CLEMENT
2015-01-08 13:57 ` Ryan Press
2015-01-07 12:47 ` Heikki Krogerus
2015-01-08 13:52 ` Gregory CLEMENT
2015-01-07 12:54 ` Lorenzo Pieralisi
2015-01-08 13:56 ` Gregory CLEMENT
2015-01-21 14:00 ` Gregory CLEMENT
2015-01-23 10:54 ` Lorenzo Pieralisi
2015-01-26 10:31 ` Marcin Wojtas
2015-01-14 0:20 ` Nobuhiro Iwamatsu
2015-01-14 8:11 ` Gregory CLEMENT
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2343908.plBCRoX2ek@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.