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

On Tue, Sep 2, 2014 at 6:40 PM, Russell King - ARM Linux
[off-list ref] wrote:

On Tue, Sep 02, 2014 at 12:22:06PM +0200, Maxime Ripard wrote:

quoted

On Thu, Aug 07, 2014 at 03:20:23PM +0200, Maxime Ripard wrote:

quoted

Hi Russell,

On Mon, Aug 04, 2014 at 10:23:17PM +0100, Russell King - ARM Linux wrote:

quoted

On Mon, Aug 04, 2014 at 09:25:10PM +0200, Maxime Ripard wrote:

quoted

On Sun, Aug 03, 2014 at 07:59:27PM +0200, Arnd Bergmann wrote:

quoted

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.