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

[Chen-Yu Tsai]

On Tue, Sep 2, 2014 at 6:40 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> 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.

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.