From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: devicetree@vger.kernel.org, khilman@linaro.org,
Arnd Bergmann <arnd@arndb.de>,
Hans de Goede <hdegoede@redhat.com>,
Olof Johansson <olof@lixom.net>,
Karsten Merker <merker@debian.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: Formal license ambiguity in arch/arm/boot/dts/sun?i-a*.dts
Date: Tue, 2 Sep 2014 11:40:02 +0100 [thread overview]
Message-ID: <20140902104002.GN30401@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20140902102206.GU15297@lukather>
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.
next prev parent reply other threads:[~2014-09-02 10:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-31 19:20 Formal license ambiguity in arch/arm/boot/dts/sun?i-a*.dts Karsten Merker
[not found] ` <20140731192016.GA6869-Hlt6eto4P0pdWf7zwHaZWbNAH6kLmebB@public.gmane.org>
2014-08-03 13:04 ` Maxime Ripard
2014-08-03 17:59 ` Arnd Bergmann
[not found] ` <201408031959.27607.arnd-r2nGTMty4D4@public.gmane.org>
2014-08-04 19:25 ` Maxime Ripard
2014-08-04 21:23 ` Russell King - ARM Linux
[not found] ` <20140804212317.GL30282-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2014-08-05 8:06 ` Arnd Bergmann
2014-08-07 13:20 ` Maxime Ripard
2014-09-02 10:22 ` Maxime Ripard
2014-09-02 10:40 ` Russell King - ARM Linux [this message]
[not found] ` <20140902104002.GN30401-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2014-09-02 11:54 ` Chen-Yu Tsai
2014-09-02 12:27 ` Maxime Ripard
2014-09-02 12:35 ` Hans de Goede
[not found] ` <5405B986.2080407-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-09-02 12:51 ` Maxime Ripard
2014-09-02 13:02 ` Arnd Bergmann
2014-09-02 13:37 ` Russell King - ARM Linux
[not found] ` <20140902133713.GR30401-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2014-09-02 16:52 ` Russell King - ARM Linux
2014-09-02 14:42 ` Hans de Goede
[not found] ` <5405D74B.8090409-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-09-02 15:18 ` Maxime Ripard
2014-09-02 16:24 ` Russell King - ARM Linux
2014-08-05 8:01 ` Hans de Goede
2014-08-05 8:02 ` Hans de Goede
2014-08-03 20:41 ` Russell King - ARM Linux
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=20140902104002.GN30401@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=hdegoede@redhat.com \
--cc=khilman@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maxime.ripard@free-electrons.com \
--cc=merker@debian.org \
--cc=olof@lixom.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).