From: arnd@arndb•de (Arnd Bergmann)
To: linux-arm-kernel@lists•infradead.org
Subject: Formal license ambiguity in arch/arm/boot/dts/sun?i-a*.dts
Date: Tue, 5 Aug 2014 10:06:03 +0200 [thread overview]
Message-ID: <201408051006.03303.arnd@arndb.de> (raw)
In-Reply-To: <20140804212317.GL30282@n2100.arm.linux.org.uk>
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
next prev parent reply other threads:[~2014-08-05 8:06 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
2014-08-03 13:04 ` Maxime Ripard
2014-08-03 17:59 ` Arnd Bergmann
2014-08-04 19:25 ` Maxime Ripard
2014-08-04 21:23 ` Russell King - ARM Linux
2014-08-05 8:06 ` Arnd Bergmann [this message]
2014-08-07 13:20 ` Maxime Ripard
2014-09-02 10:22 ` Maxime Ripard
2014-09-02 10:40 ` Russell King - ARM Linux
2014-09-02 11:54 ` Chen-Yu Tsai
2014-09-02 12:27 ` Maxime Ripard
2014-09-02 12:35 ` Hans de Goede
2014-09-02 12:51 ` Maxime Ripard
2014-09-02 13:02 ` Arnd Bergmann
2014-09-02 13:37 ` Russell King - ARM Linux
2014-09-02 16:52 ` Russell King - ARM Linux
2014-09-02 14:42 ` Hans de Goede
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=201408051006.03303.arnd@arndb.de \
--to=arnd@arndb$(echo .)de \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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