Device Tree Blob (DTB) licence

Device Tree Blob (DTB) licence

[Yann Droneaud]

Hi,

I believe Device Tree Blob (.dtb file) built from kernel's Device Tree 
Sources (.dts, which #include .dtsi, which #include .h) using Device 
Tree Compiler (dtc) are covered by GNU General Public Licence v2 
(GPLv2), but cannot find any reference.

As most .dtsi in arch/arm/boot/dts/ are covered by GPLv2, and,
as most .h in include/dt-bindings/ are also covered by GPLv2,
the source code is likely covered by GPLv2.

Then this source code is translated in a different language (flattened 
device tree), so the resulting translation is also likely covered by 
GPLv2.

So, when I'm proposed to download a .dtb file from a random vendor,
can I require to get the associated source code ?

Anyway, for a .dtb file generated from kernel sources, it's rather 
painful to look after all .dts, .dtsi, .h, to find what kind of 
licences are applicables, as some are covered by BSD, dual licensed 
(any combination of X11, MIT, BSD, GPLv2).

Regards.

-- 
Yann Droneaud
OPTEYA

Device Tree Blob (DTB) licence

[Yann Droneaud]

Hi,

I believe Device Tree Blob (.dtb file) built from kernel's Device Tree 
Sources (.dts, which #include .dtsi, which #include .h) using Device 
Tree Compiler (dtc) are covered by GNU General Public Licence v2 
(GPLv2), but cannot find any reference.

As most .dtsi in arch/arm/boot/dts/ are covered by GPLv2, and,
as most .h in include/dt-bindings/ are also covered by GPLv2,
the source code is likely covered by GPLv2.

Then this source code is translated in a different language (flattened 
device tree), so the resulting translation is also likely covered by 
GPLv2.

So, when I'm proposed to download a .dtb file from a random vendor,
can I require to get the associated source code ?

Anyway, for a .dtb file generated from kernel sources, it's rather 
painful to look after all .dts, .dtsi, .h, to find what kind of 
licences are applicables, as some are covered by BSD, dual licensed 
(any combination of X11, MIT, BSD, GPLv2).

Regards.

-- 
Yann Droneaud
OPTEYA

Device Tree Blob (DTB) licence

[Yann Droneaud]

Hi,

I believe Device Tree Blob (.dtb file) built from kernel's Device Tree 
Sources (.dts, which #include .dtsi, which #include .h) using Device 
Tree Compiler (dtc) are covered by GNU General Public Licence v2 
(GPLv2), but cannot find any reference.

As most .dtsi in arch/arm/boot/dts/ are covered by GPLv2, and,
as most .h in include/dt-bindings/ are also covered by GPLv2,
the source code is likely covered by GPLv2.

Then this source code is translated in a different language (flattened 
device tree), so the resulting translation is also likely covered by 
GPLv2.

So, when I'm proposed to download a .dtb file from a random vendor,
can I require to get the associated source code ?

Anyway, for a .dtb file generated from kernel sources, it's rather 
painful to look after all .dts, .dtsi, .h, to find what kind of 
licences are applicables, as some are covered by BSD, dual licensed 
(any combination of X11, MIT, BSD, GPLv2).

Regards.

-- 
Yann Droneaud
OPTEYA


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Device Tree Blob (DTB) licence

[Rob Herring]

On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com> wrote:
> Hi,
>
> I believe Device Tree Blob (.dtb file) built from kernel's Device Tree
> Sources (.dts, which #include .dtsi, which #include .h) using Device
> Tree Compiler (dtc) are covered by GNU General Public Licence v2
> (GPLv2), but cannot find any reference.

By default yes, but we've been steering people to dual license them GPL/BSD.

> As most .dtsi in arch/arm/boot/dts/ are covered by GPLv2, and,
> as most .h in include/dt-bindings/ are also covered by GPLv2,
> the source code is likely covered by GPLv2.
>
> Then this source code is translated in a different language (flattened
> device tree), so the resulting translation is also likely covered by
> GPLv2.
>
> So, when I'm proposed to download a .dtb file from a random vendor,
> can I require to get the associated source code ?

I believe so yes. However, you already have the "source" for the most
part. Just run "dtc -I dtb -O dts <dtb file>". You loose the
preprocessing and include structure though (not necessarily a bad
thing IMO).

Then the question is what is the license on that generated dts!

> Anyway, for a .dtb file generated from kernel sources, it's rather
> painful to look after all .dts, .dtsi, .h, to find what kind of
> licences are applicables, as some are covered by BSD, dual licensed
> (any combination of X11, MIT, BSD, GPLv2).

I imagine the includes cause some licensing discrepancies if you dug into it.

Rob

Device Tree Blob (DTB) licence

[Rob Herring]

On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com> wrote:
> Hi,
>
> I believe Device Tree Blob (.dtb file) built from kernel's Device Tree
> Sources (.dts, which #include .dtsi, which #include .h) using Device
> Tree Compiler (dtc) are covered by GNU General Public Licence v2
> (GPLv2), but cannot find any reference.

By default yes, but we've been steering people to dual license them GPL/BSD.

> As most .dtsi in arch/arm/boot/dts/ are covered by GPLv2, and,
> as most .h in include/dt-bindings/ are also covered by GPLv2,
> the source code is likely covered by GPLv2.
>
> Then this source code is translated in a different language (flattened
> device tree), so the resulting translation is also likely covered by
> GPLv2.
>
> So, when I'm proposed to download a .dtb file from a random vendor,
> can I require to get the associated source code ?

I believe so yes. However, you already have the "source" for the most
part. Just run "dtc -I dtb -O dts <dtb file>". You loose the
preprocessing and include structure though (not necessarily a bad
thing IMO).

Then the question is what is the license on that generated dts!

> Anyway, for a .dtb file generated from kernel sources, it's rather
> painful to look after all .dts, .dtsi, .h, to find what kind of
> licences are applicables, as some are covered by BSD, dual licensed
> (any combination of X11, MIT, BSD, GPLv2).

I imagine the includes cause some licensing discrepancies if you dug into it.

Rob

Re: Device Tree Blob (DTB) licence

[Rob Herring]

On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com> wrote:
> Hi,
>
> I believe Device Tree Blob (.dtb file) built from kernel's Device Tree
> Sources (.dts, which #include .dtsi, which #include .h) using Device
> Tree Compiler (dtc) are covered by GNU General Public Licence v2
> (GPLv2), but cannot find any reference.

By default yes, but we've been steering people to dual license them GPL/BSD.

> As most .dtsi in arch/arm/boot/dts/ are covered by GPLv2, and,
> as most .h in include/dt-bindings/ are also covered by GPLv2,
> the source code is likely covered by GPLv2.
>
> Then this source code is translated in a different language (flattened
> device tree), so the resulting translation is also likely covered by
> GPLv2.
>
> So, when I'm proposed to download a .dtb file from a random vendor,
> can I require to get the associated source code ?

I believe so yes. However, you already have the "source" for the most
part. Just run "dtc -I dtb -O dts <dtb file>". You loose the
preprocessing and include structure though (not necessarily a bad
thing IMO).

Then the question is what is the license on that generated dts!

> Anyway, for a .dtb file generated from kernel sources, it's rather
> painful to look after all .dts, .dtsi, .h, to find what kind of
> licences are applicables, as some are covered by BSD, dual licensed
> (any combination of X11, MIT, BSD, GPLv2).

I imagine the includes cause some licensing discrepancies if you dug into it.

Rob

Re: Device Tree Blob (DTB) licence

[Yann Droneaud]

Hi,

Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit :
> On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com> 
> wrote:
> > 
> > I believe Device Tree Blob (.dtb file) built from kernel's Device 
> > Tree
> > Sources (.dts, which #include .dtsi, which #include .h) using 
> > Device
> > Tree Compiler (dtc) are covered by GNU General Public Licence v2
> > (GPLv2), but cannot find any reference.
> 
> By default yes, but we've been steering people to dual license them 
> GPL/BSD.
> 

Can you give me the rationale behind such dual licenses requirement ?

If a BSD .dts includes GPLv2 .h, the whole is covered by GPLv2,
so I cannot find a case where a BSD covered .dts file could be used
alone within BSD license rights.

> > As most .dtsi in arch/arm/boot/dts/ are covered by GPLv2, and,
> > as most .h in include/dt-bindings/ are also covered by GPLv2,
> > the source code is likely covered by GPLv2.
> > 
> > Then this source code is translated in a different language 
> > (flattened
> > device tree), so the resulting translation is also likely covered 
> > by
> > GPLv2.
> > 
> > So, when I'm proposed to download a .dtb file from a random vendor,
> > can I require to get the associated source code ?
> 
> I believe so yes. However, you already have the "source" for the most
> part. Just run "dtc -I dtb -O dts <dtb file>". You loose the
> preprocessing and include structure though (not necessarily a bad
> thing IMO).
> 
> Then the question is what is the license on that generated dts!
> 

That's also a good question.

Is this a form a "reverse engineering" with all the legalese burden ?

Anyway without a clear information attached to the DTB, it's difficult
to tell which licence cover the "decompiled" version.

> > Anyway, for a .dtb file generated from kernel sources, it's rather
> > painful to look after all .dts, .dtsi, .h, to find what kind of
> > licences are applicables, as some are covered by BSD, dual licensed
> > (any combination of X11, MIT, BSD, GPLv2).
> 
> I imagine the includes cause some licensing discrepancies if you dug 
> into it.
> 

It's a pity, and it's probably something to sort out.

DTB files produced as part of kernel compilation should have a well
known license attached by default.

Regards.

-- 
Yann Droneaud
OPTEYA

Device Tree Blob (DTB) licence

[Yann Droneaud]

Hi,

Le mardi 05 mai 2015 ? 11:41 -0500, Rob Herring a ?crit :
> On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com> 
> wrote:
> > 
> > I believe Device Tree Blob (.dtb file) built from kernel's Device 
> > Tree
> > Sources (.dts, which #include .dtsi, which #include .h) using 
> > Device
> > Tree Compiler (dtc) are covered by GNU General Public Licence v2
> > (GPLv2), but cannot find any reference.
> 
> By default yes, but we've been steering people to dual license them 
> GPL/BSD.
> 

Can you give me the rationale behind such dual licenses requirement ?

If a BSD .dts includes GPLv2 .h, the whole is covered by GPLv2,
so I cannot find a case where a BSD covered .dts file could be used
alone within BSD license rights.

> > As most .dtsi in arch/arm/boot/dts/ are covered by GPLv2, and,
> > as most .h in include/dt-bindings/ are also covered by GPLv2,
> > the source code is likely covered by GPLv2.
> > 
> > Then this source code is translated in a different language 
> > (flattened
> > device tree), so the resulting translation is also likely covered 
> > by
> > GPLv2.
> > 
> > So, when I'm proposed to download a .dtb file from a random vendor,
> > can I require to get the associated source code ?
> 
> I believe so yes. However, you already have the "source" for the most
> part. Just run "dtc -I dtb -O dts <dtb file>". You loose the
> preprocessing and include structure though (not necessarily a bad
> thing IMO).
> 
> Then the question is what is the license on that generated dts!
> 

That's also a good question.

Is this a form a "reverse engineering" with all the legalese burden ?

Anyway without a clear information attached to the DTB, it's difficult
to tell which licence cover the "decompiled" version.

> > Anyway, for a .dtb file generated from kernel sources, it's rather
> > painful to look after all .dts, .dtsi, .h, to find what kind of
> > licences are applicables, as some are covered by BSD, dual licensed
> > (any combination of X11, MIT, BSD, GPLv2).
> 
> I imagine the includes cause some licensing discrepancies if you dug 
> into it.
> 

It's a pity, and it's probably something to sort out.

DTB files produced as part of kernel compilation should have a well
known license attached by default.

Regards.

-- 
Yann Droneaud
OPTEYA

Re: Device Tree Blob (DTB) licence

[Yann Droneaud]

Hi,

Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit :
> On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com> 
> wrote:
> > 
> > I believe Device Tree Blob (.dtb file) built from kernel's Device 
> > Tree
> > Sources (.dts, which #include .dtsi, which #include .h) using 
> > Device
> > Tree Compiler (dtc) are covered by GNU General Public Licence v2
> > (GPLv2), but cannot find any reference.
> 
> By default yes, but we've been steering people to dual license them 
> GPL/BSD.
> 

Can you give me the rationale behind such dual licenses requirement ?

If a BSD .dts includes GPLv2 .h, the whole is covered by GPLv2,
so I cannot find a case where a BSD covered .dts file could be used
alone within BSD license rights.

> > As most .dtsi in arch/arm/boot/dts/ are covered by GPLv2, and,
> > as most .h in include/dt-bindings/ are also covered by GPLv2,
> > the source code is likely covered by GPLv2.
> > 
> > Then this source code is translated in a different language 
> > (flattened
> > device tree), so the resulting translation is also likely covered 
> > by
> > GPLv2.
> > 
> > So, when I'm proposed to download a .dtb file from a random vendor,
> > can I require to get the associated source code ?
> 
> I believe so yes. However, you already have the "source" for the most
> part. Just run "dtc -I dtb -O dts <dtb file>". You loose the
> preprocessing and include structure though (not necessarily a bad
> thing IMO).
> 
> Then the question is what is the license on that generated dts!
> 

That's also a good question.

Is this a form a "reverse engineering" with all the legalese burden ?

Anyway without a clear information attached to the DTB, it's difficult
to tell which licence cover the "decompiled" version.

> > Anyway, for a .dtb file generated from kernel sources, it's rather
> > painful to look after all .dts, .dtsi, .h, to find what kind of
> > licences are applicables, as some are covered by BSD, dual licensed
> > (any combination of X11, MIT, BSD, GPLv2).
> 
> I imagine the includes cause some licensing discrepancies if you dug 
> into it.
> 

It's a pity, and it's probably something to sort out.

DTB files produced as part of kernel compilation should have a well
known license attached by default.

Regards.

-- 
Yann Droneaud
OPTEYA

Re: Device Tree Blob (DTB) licence

[Rob Herring]

On Fri, May 22, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com> wrote:
> Hi,
>
> Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit :
>> On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com>
>> wrote:
>> >
>> > I believe Device Tree Blob (.dtb file) built from kernel's Device
>> > Tree
>> > Sources (.dts, which #include .dtsi, which #include .h) using
>> > Device
>> > Tree Compiler (dtc) are covered by GNU General Public Licence v2
>> > (GPLv2), but cannot find any reference.
>>
>> By default yes, but we've been steering people to dual license them
>> GPL/BSD.
>>
>
> Can you give me the rationale behind such dual licenses requirement ?

Ideally, dtb files are shipped with firmware separately from the OS.
You should be able to run multiple OS's with that dtb. There is often
desire or "requirements" to not have GPL code in firmware.

> If a BSD .dts includes GPLv2 .h, the whole is covered by GPLv2,
> so I cannot find a case where a BSD covered .dts file could be used
> alone within BSD license rights.

arch/powerpc/boot/dts

>> > As most .dtsi in arch/arm/boot/dts/ are covered by GPLv2, and,
>> > as most .h in include/dt-bindings/ are also covered by GPLv2,
>> > the source code is likely covered by GPLv2.
>> >
>> > Then this source code is translated in a different language
>> > (flattened
>> > device tree), so the resulting translation is also likely covered
>> > by
>> > GPLv2.
>> >
>> > So, when I'm proposed to download a .dtb file from a random vendor,
>> > can I require to get the associated source code ?
>>
>> I believe so yes. However, you already have the "source" for the most
>> part. Just run "dtc -I dtb -O dts <dtb file>". You loose the
>> preprocessing and include structure though (not necessarily a bad
>> thing IMO).
>>
>> Then the question is what is the license on that generated dts!
>>
>
> That's also a good question.
>
> Is this a form a "reverse engineering" with all the legalese burden ?

I am not a lawyer.

> Anyway without a clear information attached to the DTB, it's difficult
> to tell which licence cover the "decompiled" version.
>
>> > Anyway, for a .dtb file generated from kernel sources, it's rather
>> > painful to look after all .dts, .dtsi, .h, to find what kind of
>> > licences are applicables, as some are covered by BSD, dual licensed
>> > (any combination of X11, MIT, BSD, GPLv2).
>>
>> I imagine the includes cause some licensing discrepancies if you dug
>> into it.
>>
>
> It's a pity, and it's probably something to sort out.
>
> DTB files produced as part of kernel compilation should have a well
> known license attached by default.

It would be a lot of work to sort out. If people need non-GPL dts/dtb
files then it is really their problem to sort out and audit their dts
files. I mainly tell people to dual license so they (and their
company) think about the issue.

Rob

Device Tree Blob (DTB) licence

[Rob Herring]

On Fri, May 22, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com> wrote:
> Hi,
>
> Le mardi 05 mai 2015 ? 11:41 -0500, Rob Herring a ?crit :
>> On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com>
>> wrote:
>> >
>> > I believe Device Tree Blob (.dtb file) built from kernel's Device
>> > Tree
>> > Sources (.dts, which #include .dtsi, which #include .h) using
>> > Device
>> > Tree Compiler (dtc) are covered by GNU General Public Licence v2
>> > (GPLv2), but cannot find any reference.
>>
>> By default yes, but we've been steering people to dual license them
>> GPL/BSD.
>>
>
> Can you give me the rationale behind such dual licenses requirement ?

Ideally, dtb files are shipped with firmware separately from the OS.
You should be able to run multiple OS's with that dtb. There is often
desire or "requirements" to not have GPL code in firmware.

> If a BSD .dts includes GPLv2 .h, the whole is covered by GPLv2,
> so I cannot find a case where a BSD covered .dts file could be used
> alone within BSD license rights.

arch/powerpc/boot/dts

>> > As most .dtsi in arch/arm/boot/dts/ are covered by GPLv2, and,
>> > as most .h in include/dt-bindings/ are also covered by GPLv2,
>> > the source code is likely covered by GPLv2.
>> >
>> > Then this source code is translated in a different language
>> > (flattened
>> > device tree), so the resulting translation is also likely covered
>> > by
>> > GPLv2.
>> >
>> > So, when I'm proposed to download a .dtb file from a random vendor,
>> > can I require to get the associated source code ?
>>
>> I believe so yes. However, you already have the "source" for the most
>> part. Just run "dtc -I dtb -O dts <dtb file>". You loose the
>> preprocessing and include structure though (not necessarily a bad
>> thing IMO).
>>
>> Then the question is what is the license on that generated dts!
>>
>
> That's also a good question.
>
> Is this a form a "reverse engineering" with all the legalese burden ?

I am not a lawyer.

> Anyway without a clear information attached to the DTB, it's difficult
> to tell which licence cover the "decompiled" version.
>
>> > Anyway, for a .dtb file generated from kernel sources, it's rather
>> > painful to look after all .dts, .dtsi, .h, to find what kind of
>> > licences are applicables, as some are covered by BSD, dual licensed
>> > (any combination of X11, MIT, BSD, GPLv2).
>>
>> I imagine the includes cause some licensing discrepancies if you dug
>> into it.
>>
>
> It's a pity, and it's probably something to sort out.
>
> DTB files produced as part of kernel compilation should have a well
> known license attached by default.

It would be a lot of work to sort out. If people need non-GPL dts/dtb
files then it is really their problem to sort out and audit their dts
files. I mainly tell people to dual license so they (and their
company) think about the issue.

Rob

Re: Device Tree Blob (DTB) licence

[Rob Herring]

On Fri, May 22, 2015 at 5:05 AM, Yann Droneaud <ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org> wrote:
> Hi,
>
> Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit :
>> On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
>> wrote:
>> >
>> > I believe Device Tree Blob (.dtb file) built from kernel's Device
>> > Tree
>> > Sources (.dts, which #include .dtsi, which #include .h) using
>> > Device
>> > Tree Compiler (dtc) are covered by GNU General Public Licence v2
>> > (GPLv2), but cannot find any reference.
>>
>> By default yes, but we've been steering people to dual license them
>> GPL/BSD.
>>
>
> Can you give me the rationale behind such dual licenses requirement ?

Ideally, dtb files are shipped with firmware separately from the OS.
You should be able to run multiple OS's with that dtb. There is often
desire or "requirements" to not have GPL code in firmware.

> If a BSD .dts includes GPLv2 .h, the whole is covered by GPLv2,
> so I cannot find a case where a BSD covered .dts file could be used
> alone within BSD license rights.

arch/powerpc/boot/dts

>> > As most .dtsi in arch/arm/boot/dts/ are covered by GPLv2, and,
>> > as most .h in include/dt-bindings/ are also covered by GPLv2,
>> > the source code is likely covered by GPLv2.
>> >
>> > Then this source code is translated in a different language
>> > (flattened
>> > device tree), so the resulting translation is also likely covered
>> > by
>> > GPLv2.
>> >
>> > So, when I'm proposed to download a .dtb file from a random vendor,
>> > can I require to get the associated source code ?
>>
>> I believe so yes. However, you already have the "source" for the most
>> part. Just run "dtc -I dtb -O dts <dtb file>". You loose the
>> preprocessing and include structure though (not necessarily a bad
>> thing IMO).
>>
>> Then the question is what is the license on that generated dts!
>>
>
> That's also a good question.
>
> Is this a form a "reverse engineering" with all the legalese burden ?

I am not a lawyer.

> Anyway without a clear information attached to the DTB, it's difficult
> to tell which licence cover the "decompiled" version.
>
>> > Anyway, for a .dtb file generated from kernel sources, it's rather
>> > painful to look after all .dts, .dtsi, .h, to find what kind of
>> > licences are applicables, as some are covered by BSD, dual licensed
>> > (any combination of X11, MIT, BSD, GPLv2).
>>
>> I imagine the includes cause some licensing discrepancies if you dug
>> into it.
>>
>
> It's a pity, and it's probably something to sort out.
>
> DTB files produced as part of kernel compilation should have a well
> known license attached by default.

It would be a lot of work to sort out. If people need non-GPL dts/dtb
files then it is really their problem to sort out and audit their dts
files. I mainly tell people to dual license so they (and their
company) think about the issue.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Device Tree Blob (DTB) licence

[Enrico Weigelt, metux IT consult]

Am 22.05.2015 um 18:26 schrieb Rob Herring:

Hi,

 > Ideally, dtb files are shipped with firmware separately from the OS.
 > You should be able to run multiple OS's with that dtb. There is often
> desire or "requirements" to not have GPL code in firmware.

I dont see that begin shipped *with* the firmware (but still as a
separate object/file) automatically means a derived work.

And I actually wouldn't want dtb strictly so interewoven with the
firmware/bootloader, that it can be easily extracted or replaced
anymore. IMHO, we shouldn't support such vendors.
(freedom is more than just $0 price)

And there shouldn't be any proprietary firmware anyways.

cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.

Device Tree Blob (DTB) licence

[Enrico Weigelt, metux IT consult]

Am 22.05.2015 um 18:26 schrieb Rob Herring:

Hi,

 > Ideally, dtb files are shipped with firmware separately from the OS.
 > You should be able to run multiple OS's with that dtb. There is often
> desire or "requirements" to not have GPL code in firmware.

I dont see that begin shipped *with* the firmware (but still as a
separate object/file) automatically means a derived work.

And I actually wouldn't want dtb strictly so interewoven with the
firmware/bootloader, that it can be easily extracted or replaced
anymore. IMHO, we shouldn't support such vendors.
(freedom is more than just $0 price)

And there shouldn't be any proprietary firmware anyways.

cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur f?r einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschlie?lich f?r denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, d?rfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrt?mlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte l?schen Sie in diesem Fall diese Nachricht und alle Anh?nge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.

Re: Device Tree Blob (DTB) licence

[Enrico Weigelt, metux IT consult]

Am 22.05.2015 um 18:26 schrieb Rob Herring:

Hi,

 > Ideally, dtb files are shipped with firmware separately from the OS.
 > You should be able to run multiple OS's with that dtb. There is often
> desire or "requirements" to not have GPL code in firmware.

I dont see that begin shipped *with* the firmware (but still as a
separate object/file) automatically means a derived work.

And I actually wouldn't want dtb strictly so interewoven with the
firmware/bootloader, that it can be easily extracted or replaced
anymore. IMHO, we shouldn't support such vendors.
(freedom is more than just $0 price)

And there shouldn't be any proprietary firmware anyways.

cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.

Re: Device Tree Blob (DTB) licence

[Yann Droneaud]

[-- Attachment #1: Type: text/plain, Size: 2788 bytes --]

Hi,

[removing Cc: licensing@fsf.org]

Le vendredi 22 mai 2015 à 12:05 +0200, Yann Droneaud a écrit :
> Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit :
> > On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com
> > > 
> > wrote:
> > > 
> > > I believe Device Tree Blob (.dtb file) built from kernel's Device 
> > > 
> > > Tree
> > > Sources (.dts, which #include .dtsi, which #include .h) using 
> > > Device
> > > Tree Compiler (dtc) are covered by GNU General Public Licence v2
> > > (GPLv2), but cannot find any reference.
> > 
> > By default yes, but we've been steering people to dual license them 
> > 
> > GPL/BSD.
> > 
> 
> Can you give me the rationale behind such dual licenses requirement ?
> 
> If a BSD .dts includes GPLv2 .h, the whole is covered by GPLv2,
> so I cannot find a case where a BSD covered .dts file could be used
> alone within BSD license rights.
> 
> > > As most .dtsi in arch/arm/boot/dts/ are covered by GPLv2, and,
> > > as most .h in include/dt-bindings/ are also covered by GPLv2,
> > > the source code is likely covered by GPLv2.
> > > 
> > > Then this source code is translated in a different language 
> > > (flattened
> > > device tree), so the resulting translation is also likely covered 
> > > 
> > > by
> > > GPLv2.
> > > 
> > > So, when I'm proposed to download a .dtb file from a random 
> > > vendor,
> > > can I require to get the associated source code ?
> > 
> > I believe so yes. However, you already have the "source" for the 
> > most
> > part. Just run "dtc -I dtb -O dts <dtb file>". You loose the
> > preprocessing and include structure though (not necessarily a bad
> > thing IMO).
> > 
> > Then the question is what is the license on that generated dts!
> > 
> 
> That's also a good question.
> 
> Is this a form a "reverse engineering" with all the legalese burden ?
> 
> Anyway without a clear information attached to the DTB, it's 
> difficult
> to tell which licence cover the "decompiled" version.
> 
> > > Anyway, for a .dtb file generated from kernel sources, it's 
> > > rather
> > > painful to look after all .dts, .dtsi, .h, to find what kind of
> > > licences are applicables, as some are covered by BSD, dual 
> > > licensed
> > > (any combination of X11, MIT, BSD, GPLv2).
> > 
> > I imagine the includes cause some licensing discrepancies if you 
> > dug 
> > into it.
> > 
> 
> It's a pity, and it's probably something to sort out.
> 
> DTB files produced as part of kernel compilation should have a well
> known license attached by default.
> 

I've added licensing@fsf.ogrg in Cc: in my previous message to have an 
advice on this subject, but I failed to notice licensing@fsf.org 
is not a mailing list: I was assigned request ID [gnu.org #1017262].

Regards.

-- 
Yann Droneaud
OPTEYA

[-- Attachment #2: Message joint - [gnu.org #1017262] AutoReply concerning licensing question: Re: Device Tree Blob (DTB) licence --]
[-- Type: message/rfc822, Size: 3955 bytes --]

From: "FSF Licensing Questions via RT" <licensing@fsf.org>
To: ydroneaud@opteya.com
Subject: [gnu.org #1017262] AutoReply concerning licensing question: Re: Device Tree Blob (DTB) licence
Date: Fri, 22 May 2015 06:06:16 -0400
Message-ID: <rt-3.4.5-24484-1432289176-201.1017262-48-0@rt.gnu.org>

This message has been automatically generated in response to a
licensing question you sent to the Free Software Foundation, with subject:
	"Re: Device Tree Blob (DTB) licence".

There is no need to reply to this message right now.  Your request has
been assigned an ID of [gnu.org #1017262].

Please include the string:
         [gnu.org #1017262]
in the subject line of all future correspondence about this issue.  To do
so, you may reply to this message.


Thank you so much for writing to the Free Software Foundation's
Licensing and Compliance Lab. Questions sent to this address are
answered largely by volunteers, with the help of FSF staff. We have the
following licensing resources available which you might find helpful:

Licensing FAQ page: http://www.gnu.org/licenses/gpl-faq.html
Text of the GNU GPL: http://www.gnu.org/licenses/gpl.html
Text of the GNU LGPL: http://www.gnu.org/licenses/lgpl.html
Text of the GNU AGPL: http://www.gnu.org/licenses/agpl.html
Our license list page: http://www.gnu.org/licenses/license-list.html

We can always use more help in answering licensing questions (check out
our license team page on Libreplanet if you are interested in helping
out <http://libreplanet.org/wiki/Group:Free_Software_Foundation/Licensing_Volunteers>),
so we thank you for your patience as you await a response. You can also
help the licensing team by making a donation at <donate.fsf.org>. Your donations are
what enable us to offer this service to the community.

We do offer consulting services for companies who are working to develop
products that incorporate free software so that they can do so in ways
that comply with the terms of the GPL and other free software licenses.
If you are interested in this service, please write a separate message
to compliance-lab@fsf.org.

                        Sincerely,
                        FSF GPL Compliance Lab Office

Device Tree Blob (DTB) licence

[Yann Droneaud]

Hi,

[removing Cc: licensing at fsf.org]

Le vendredi 22 mai 2015 ? 12:05 +0200, Yann Droneaud a ?crit :
> Le mardi 05 mai 2015 ? 11:41 -0500, Rob Herring a ?crit :
> > On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com
> > > 
> > wrote:
> > > 
> > > I believe Device Tree Blob (.dtb file) built from kernel's Device 
> > > 
> > > Tree
> > > Sources (.dts, which #include .dtsi, which #include .h) using 
> > > Device
> > > Tree Compiler (dtc) are covered by GNU General Public Licence v2
> > > (GPLv2), but cannot find any reference.
> > 
> > By default yes, but we've been steering people to dual license them 
> > 
> > GPL/BSD.
> > 
> 
> Can you give me the rationale behind such dual licenses requirement ?
> 
> If a BSD .dts includes GPLv2 .h, the whole is covered by GPLv2,
> so I cannot find a case where a BSD covered .dts file could be used
> alone within BSD license rights.
> 
> > > As most .dtsi in arch/arm/boot/dts/ are covered by GPLv2, and,
> > > as most .h in include/dt-bindings/ are also covered by GPLv2,
> > > the source code is likely covered by GPLv2.
> > > 
> > > Then this source code is translated in a different language 
> > > (flattened
> > > device tree), so the resulting translation is also likely covered 
> > > 
> > > by
> > > GPLv2.
> > > 
> > > So, when I'm proposed to download a .dtb file from a random 
> > > vendor,
> > > can I require to get the associated source code ?
> > 
> > I believe so yes. However, you already have the "source" for the 
> > most
> > part. Just run "dtc -I dtb -O dts <dtb file>". You loose the
> > preprocessing and include structure though (not necessarily a bad
> > thing IMO).
> > 
> > Then the question is what is the license on that generated dts!
> > 
> 
> That's also a good question.
> 
> Is this a form a "reverse engineering" with all the legalese burden ?
> 
> Anyway without a clear information attached to the DTB, it's 
> difficult
> to tell which licence cover the "decompiled" version.
> 
> > > Anyway, for a .dtb file generated from kernel sources, it's 
> > > rather
> > > painful to look after all .dts, .dtsi, .h, to find what kind of
> > > licences are applicables, as some are covered by BSD, dual 
> > > licensed
> > > (any combination of X11, MIT, BSD, GPLv2).
> > 
> > I imagine the includes cause some licensing discrepancies if you 
> > dug 
> > into it.
> > 
> 
> It's a pity, and it's probably something to sort out.
> 
> DTB files produced as part of kernel compilation should have a well
> known license attached by default.
> 

I've added licensing at fsf.ogrg in Cc: in my previous message to have an 
advice on this subject, but I failed to notice licensing at fsf.org 
is not a mailing list: I was assigned request ID [gnu.org #1017262].

Regards.

-- 
Yann Droneaud
OPTEYA
-------------- next part --------------
An embedded message was scrubbed...
From: "FSF Licensing Questions via RT" <licensing@fsf.org>
Subject: [gnu.org #1017262] AutoReply concerning licensing question: Re: Device Tree Blob (DTB) licence 
Date: Fri, 22 May 2015 06:06:16 -0400
Size: 3989
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150522/11d8d5e6/attachment.mht>

Re: Device Tree Blob (DTB) licence

[Yann Droneaud]

[-- Attachment #1: Type: text/plain, Size: 2788 bytes --]

Hi,

[removing Cc: licensing@fsf.org]

Le vendredi 22 mai 2015 à 12:05 +0200, Yann Droneaud a écrit :
> Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit :
> > On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com
> > > 
> > wrote:
> > > 
> > > I believe Device Tree Blob (.dtb file) built from kernel's Device 
> > > 
> > > Tree
> > > Sources (.dts, which #include .dtsi, which #include .h) using 
> > > Device
> > > Tree Compiler (dtc) are covered by GNU General Public Licence v2
> > > (GPLv2), but cannot find any reference.
> > 
> > By default yes, but we've been steering people to dual license them 
> > 
> > GPL/BSD.
> > 
> 
> Can you give me the rationale behind such dual licenses requirement ?
> 
> If a BSD .dts includes GPLv2 .h, the whole is covered by GPLv2,
> so I cannot find a case where a BSD covered .dts file could be used
> alone within BSD license rights.
> 
> > > As most .dtsi in arch/arm/boot/dts/ are covered by GPLv2, and,
> > > as most .h in include/dt-bindings/ are also covered by GPLv2,
> > > the source code is likely covered by GPLv2.
> > > 
> > > Then this source code is translated in a different language 
> > > (flattened
> > > device tree), so the resulting translation is also likely covered 
> > > 
> > > by
> > > GPLv2.
> > > 
> > > So, when I'm proposed to download a .dtb file from a random 
> > > vendor,
> > > can I require to get the associated source code ?
> > 
> > I believe so yes. However, you already have the "source" for the 
> > most
> > part. Just run "dtc -I dtb -O dts <dtb file>". You loose the
> > preprocessing and include structure though (not necessarily a bad
> > thing IMO).
> > 
> > Then the question is what is the license on that generated dts!
> > 
> 
> That's also a good question.
> 
> Is this a form a "reverse engineering" with all the legalese burden ?
> 
> Anyway without a clear information attached to the DTB, it's 
> difficult
> to tell which licence cover the "decompiled" version.
> 
> > > Anyway, for a .dtb file generated from kernel sources, it's 
> > > rather
> > > painful to look after all .dts, .dtsi, .h, to find what kind of
> > > licences are applicables, as some are covered by BSD, dual 
> > > licensed
> > > (any combination of X11, MIT, BSD, GPLv2).
> > 
> > I imagine the includes cause some licensing discrepancies if you 
> > dug 
> > into it.
> > 
> 
> It's a pity, and it's probably something to sort out.
> 
> DTB files produced as part of kernel compilation should have a well
> known license attached by default.
> 

I've added licensing@fsf.ogrg in Cc: in my previous message to have an 
advice on this subject, but I failed to notice licensing@fsf.org 
is not a mailing list: I was assigned request ID [gnu.org #1017262].

Regards.

-- 
Yann Droneaud
OPTEYA

[-- Attachment #2: Message joint - [gnu.org #1017262] AutoReply concerning licensing question: Re: Device Tree Blob (DTB) licence --]
[-- Type: message/rfc822, Size: 3954 bytes --]

From: "FSF Licensing Questions via RT" <licensing@fsf.org>
To: ydroneaud@opteya.com
Subject: [gnu.org #1017262] AutoReply concerning licensing question: Re: Device Tree Blob (DTB) licence
Date: Fri, 22 May 2015 06:06:16 -0400
Message-ID: <rt-3.4.5-24484-1432289176-201.1017262-48-0@rt.gnu.org>

This message has been automatically generated in response to a
licensing question you sent to the Free Software Foundation, with subject:
	"Re: Device Tree Blob (DTB) licence".

There is no need to reply to this message right now.  Your request has
been assigned an ID of [gnu.org #1017262].

Please include the string:
         [gnu.org #1017262]
in the subject line of all future correspondence about this issue.  To do
so, you may reply to this message.


Thank you so much for writing to the Free Software Foundation's
Licensing and Compliance Lab. Questions sent to this address are
answered largely by volunteers, with the help of FSF staff. We have the
following licensing resources available which you might find helpful:

Licensing FAQ page: http://www.gnu.org/licenses/gpl-faq.html
Text of the GNU GPL: http://www.gnu.org/licenses/gpl.html
Text of the GNU LGPL: http://www.gnu.org/licenses/lgpl.html
Text of the GNU AGPL: http://www.gnu.org/licenses/agpl.html
Our license list page: http://www.gnu.org/licenses/license-list.html

We can always use more help in answering licensing questions (check out
our license team page on Libreplanet if you are interested in helping
out <http://libreplanet.org/wiki/Group:Free_Software_Foundation/Licensing_Volunteers>),
so we thank you for your patience as you await a response. You can also
help the licensing team by making a donation at <donate.fsf.org>. Your donations are
what enable us to offer this service to the community.

We do offer consulting services for companies who are working to develop
products that incorporate free software so that they can do so in ways
that comply with the terms of the GPL and other free software licenses.
If you are interested in this service, please write a separate message
to compliance-lab@fsf.org.

                        Sincerely,
                        FSF GPL Compliance Lab Office

Re: Device Tree Blob (DTB) licence

[Rob Landley]

On Fri, May 22, 2015 at 2:27 PM, Yann Droneaud <ydroneaud@opteya.com> wrote:
> I've added licensing@fsf.ogrg in Cc: in my previous message to have an
> advice on this subject, but I failed to notice licensing@fsf.org
> is not a mailing list: I was assigned request ID [gnu.org #1017262].
>
> Regards.

They're also not an unbiased source. Their job is to reply "you should
license it under GPLv3" without actually looking at your message.
(This is a slight oversimplification, they may instead recomend the
GFDL. They will never _not_ recommend one of their licenses.)

Personally, I'm sad we're starting to get ACPI for arm but if device
tree data files are only available under GPL, people will hold their
nose and deploy ACPI.

Rob

Device Tree Blob (DTB) licence

[Rob Landley]

On Fri, May 22, 2015 at 2:27 PM, Yann Droneaud <ydroneaud@opteya.com> wrote:
> I've added licensing at fsf.ogrg in Cc: in my previous message to have an
> advice on this subject, but I failed to notice licensing at fsf.org
> is not a mailing list: I was assigned request ID [gnu.org #1017262].
>
> Regards.

They're also not an unbiased source. Their job is to reply "you should
license it under GPLv3" without actually looking at your message.
(This is a slight oversimplification, they may instead recomend the
GFDL. They will never _not_ recommend one of their licenses.)

Personally, I'm sad we're starting to get ACPI for arm but if device
tree data files are only available under GPL, people will hold their
nose and deploy ACPI.

Rob

Re: Device Tree Blob (DTB) licence

[Rob Landley]

On Fri, May 22, 2015 at 2:27 PM, Yann Droneaud <ydroneaud@opteya.com> wrote:
> I've added licensing@fsf.ogrg in Cc: in my previous message to have an
> advice on this subject, but I failed to notice licensing@fsf.org
> is not a mailing list: I was assigned request ID [gnu.org #1017262].
>
> Regards.

They're also not an unbiased source. Their job is to reply "you should
license it under GPLv3" without actually looking at your message.
(This is a slight oversimplification, they may instead recomend the
GFDL. They will never _not_ recommend one of their licenses.)

Personally, I'm sad we're starting to get ACPI for arm but if device
tree data files are only available under GPL, people will hold their
nose and deploy ACPI.

Rob

Re: Device Tree Blob (DTB) licence

[Willy Tarreau]

On Mon, May 25, 2015 at 02:14:28AM -0500, Rob Landley wrote:
> Personally, I'm sad we're starting to get ACPI for arm

Maybe it was the only solution found to make this platform start to
misbehave like a regular PC and get it even more widely adopted :-)

Willy

Device Tree Blob (DTB) licence

[Willy Tarreau]

On Mon, May 25, 2015 at 02:14:28AM -0500, Rob Landley wrote:
> Personally, I'm sad we're starting to get ACPI for arm

Maybe it was the only solution found to make this platform start to
misbehave like a regular PC and get it even more widely adopted :-)

Willy

Re: Device Tree Blob (DTB) licence

[Willy Tarreau]

On Mon, May 25, 2015 at 02:14:28AM -0500, Rob Landley wrote:
> Personally, I'm sad we're starting to get ACPI for arm

Maybe it was the only solution found to make this platform start to
misbehave like a regular PC and get it even more widely adopted :-)

Willy

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Device Tree Blob (DTB) licence

[Enrico Weigelt, metux IT consult]

Am 25.05.2015 um 09:14 schrieb Rob Landley:

> Personally, I'm sad we're starting to get ACPI for arm but if device
> tree data files are only available under GPL, people will hold their
> nose and deploy ACPI.

What's the big deal with having DTS/DTB under GPL ?


cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.

Device Tree Blob (DTB) licence

[Enrico Weigelt, metux IT consult]

Am 25.05.2015 um 09:14 schrieb Rob Landley:

> Personally, I'm sad we're starting to get ACPI for arm but if device
> tree data files are only available under GPL, people will hold their
> nose and deploy ACPI.

What's the big deal with having DTS/DTB under GPL ?


cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur f?r einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschlie?lich f?r denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, d?rfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrt?mlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte l?schen Sie in diesem Fall diese Nachricht und alle Anh?nge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.

Re: Device Tree Blob (DTB) licence

[Enrico Weigelt, metux IT consult]

Am 25.05.2015 um 09:14 schrieb Rob Landley:

> Personally, I'm sad we're starting to get ACPI for arm but if device
> tree data files are only available under GPL, people will hold their
> nose and deploy ACPI.

What's the big deal with having DTS/DTB under GPL ?


cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Device Tree Blob (DTB) licence

[Russell King - ARM Linux]

On Thu, May 28, 2015 at 02:32:20PM +0200, Enrico Weigelt, metux IT consult wrote:
> Am 25.05.2015 um 09:14 schrieb Rob Landley:
> 
> >Personally, I'm sad we're starting to get ACPI for arm but if device
> >tree data files are only available under GPL, people will hold their
> >nose and deploy ACPI.
> 
> What's the big deal with having DTS/DTB under GPL ?

It's really quite simple.  Other open source projects won't touch
_our_ DTB with a barge pole through fear of GPL contamination.

So what we'll end up with is other projects creating their own DTB
descriptions for the same hardware, with different properties (which
they'll do in an effort to ensure that it isn't a "derived work" of
the GPL version) and the whole thing turning into a right mess - and
a poor experience for users because they then end up with OS specific
DT files.

Alternatively, as Rob points out, people will just go the ACPI route
to avoid the GPL contamination problem.

It doesn't matter what the legal issues actually are: if people think
that there is the possibility of GPL contamination - even across to
other differently licensed open source software, they won't touch the
GPL'd code/data and they'll come up with an alternative solution.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Device Tree Blob (DTB) licence

[Russell King - ARM Linux]

On Thu, May 28, 2015 at 02:32:20PM +0200, Enrico Weigelt, metux IT consult wrote:
> Am 25.05.2015 um 09:14 schrieb Rob Landley:
> 
> >Personally, I'm sad we're starting to get ACPI for arm but if device
> >tree data files are only available under GPL, people will hold their
> >nose and deploy ACPI.
> 
> What's the big deal with having DTS/DTB under GPL ?

It's really quite simple.  Other open source projects won't touch
_our_ DTB with a barge pole through fear of GPL contamination.

So what we'll end up with is other projects creating their own DTB
descriptions for the same hardware, with different properties (which
they'll do in an effort to ensure that it isn't a "derived work" of
the GPL version) and the whole thing turning into a right mess - and
a poor experience for users because they then end up with OS specific
DT files.

Alternatively, as Rob points out, people will just go the ACPI route
to avoid the GPL contamination problem.

It doesn't matter what the legal issues actually are: if people think
that there is the possibility of GPL contamination - even across to
other differently licensed open source software, they won't touch the
GPL'd code/data and they'll come up with an alternative solution.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Re: Device Tree Blob (DTB) licence

[Russell King - ARM Linux]

On Thu, May 28, 2015 at 02:32:20PM +0200, Enrico Weigelt, metux IT consult wrote:
> Am 25.05.2015 um 09:14 schrieb Rob Landley:
> 
> >Personally, I'm sad we're starting to get ACPI for arm but if device
> >tree data files are only available under GPL, people will hold their
> >nose and deploy ACPI.
> 
> What's the big deal with having DTS/DTB under GPL ?

It's really quite simple.  Other open source projects won't touch
_our_ DTB with a barge pole through fear of GPL contamination.

So what we'll end up with is other projects creating their own DTB
descriptions for the same hardware, with different properties (which
they'll do in an effort to ensure that it isn't a "derived work" of
the GPL version) and the whole thing turning into a right mess - and
a poor experience for users because they then end up with OS specific
DT files.

Alternatively, as Rob points out, people will just go the ACPI route
to avoid the GPL contamination problem.

It doesn't matter what the legal issues actually are: if people think
that there is the possibility of GPL contamination - even across to
other differently licensed open source software, they won't touch the
GPL'd code/data and they'll come up with an alternative solution.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Device Tree Blob (DTB) licence

[Enrico Weigelt, metux IT consult]

Am 28.05.2015 um 15:34 schrieb Russell King - ARM Linux:

>> What's the big deal with having DTS/DTB under GPL ?
>
> It's really quite simple.  Other open source projects won't touch
> _our_ DTB with a barge pole through fear of GPL contamination.

Which other foss projects do you have in mind ?
And why should they fear "poisoning" ?

The DTB is an entirely separate file. Just like various firmware
blobs, startup scripts, etc, etc. Just shipping that file (be it in
some source tarball or in the flash of some device) doesn't make
everything else an derived work.

Of course, the viral effect of the GPL could catch in if somebody
directly compiles-in the dtb into something else (so it cant be
easily separated / replaced) - but why should anybody wanna do that ?
Sounds to me like defeating the whole purpose of DTB.

> So what we'll end up with is other projects creating their own DTB
> descriptions for the same hardware, with different properties (which
> they'll do in an effort to ensure that it isn't a "derived work" of
> the GPL version) and the whole thing turning into a right mess - and
> a poor experience for users because they then end up with OS specific
> DT files.

Anybody is free do to everything on his own. Same as everybody is free
to write his own kernel, etc.

But I dont see a practical usecase where the GPL's viral effect could
catch in here in the first place.

> Alternatively, as Rob points out, people will just go the ACPI route
> to avoid the GPL contamination problem.

If they really wanna go that ugly route ... just let them go.
I don't see where I could care at all.

As I'm primarily concerned w/ embedded systems, I'll need full
documentation and control over the device, I won't trust vendor DTBs
anyways. And I won't help people doing crippled proprietary stuff,
not at this critical point.

Even for larger systems - except the crippled x86 world - I won't even
allow any proprietary bootloader/firmware.



cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.

Device Tree Blob (DTB) licence

[Enrico Weigelt, metux IT consult]

Am 28.05.2015 um 15:34 schrieb Russell King - ARM Linux:

>> What's the big deal with having DTS/DTB under GPL ?
>
> It's really quite simple.  Other open source projects won't touch
> _our_ DTB with a barge pole through fear of GPL contamination.

Which other foss projects do you have in mind ?
And why should they fear "poisoning" ?

The DTB is an entirely separate file. Just like various firmware
blobs, startup scripts, etc, etc. Just shipping that file (be it in
some source tarball or in the flash of some device) doesn't make
everything else an derived work.

Of course, the viral effect of the GPL could catch in if somebody
directly compiles-in the dtb into something else (so it cant be
easily separated / replaced) - but why should anybody wanna do that ?
Sounds to me like defeating the whole purpose of DTB.

> So what we'll end up with is other projects creating their own DTB
> descriptions for the same hardware, with different properties (which
> they'll do in an effort to ensure that it isn't a "derived work" of
> the GPL version) and the whole thing turning into a right mess - and
> a poor experience for users because they then end up with OS specific
> DT files.

Anybody is free do to everything on his own. Same as everybody is free
to write his own kernel, etc.

But I dont see a practical usecase where the GPL's viral effect could
catch in here in the first place.

> Alternatively, as Rob points out, people will just go the ACPI route
> to avoid the GPL contamination problem.

If they really wanna go that ugly route ... just let them go.
I don't see where I could care at all.

As I'm primarily concerned w/ embedded systems, I'll need full
documentation and control over the device, I won't trust vendor DTBs
anyways. And I won't help people doing crippled proprietary stuff,
not at this critical point.

Even for larger systems - except the crippled x86 world - I won't even
allow any proprietary bootloader/firmware.



cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur f?r einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschlie?lich f?r denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, d?rfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrt?mlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte l?schen Sie in diesem Fall diese Nachricht und alle Anh?nge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.

Re: Device Tree Blob (DTB) licence

[Enrico Weigelt, metux IT consult]

Am 28.05.2015 um 15:34 schrieb Russell King - ARM Linux:

>> What's the big deal with having DTS/DTB under GPL ?
>
> It's really quite simple.  Other open source projects won't touch
> _our_ DTB with a barge pole through fear of GPL contamination.

Which other foss projects do you have in mind ?
And why should they fear "poisoning" ?

The DTB is an entirely separate file. Just like various firmware
blobs, startup scripts, etc, etc. Just shipping that file (be it in
some source tarball or in the flash of some device) doesn't make
everything else an derived work.

Of course, the viral effect of the GPL could catch in if somebody
directly compiles-in the dtb into something else (so it cant be
easily separated / replaced) - but why should anybody wanna do that ?
Sounds to me like defeating the whole purpose of DTB.

> So what we'll end up with is other projects creating their own DTB
> descriptions for the same hardware, with different properties (which
> they'll do in an effort to ensure that it isn't a "derived work" of
> the GPL version) and the whole thing turning into a right mess - and
> a poor experience for users because they then end up with OS specific
> DT files.

Anybody is free do to everything on his own. Same as everybody is free
to write his own kernel, etc.

But I dont see a practical usecase where the GPL's viral effect could
catch in here in the first place.

> Alternatively, as Rob points out, people will just go the ACPI route
> to avoid the GPL contamination problem.

If they really wanna go that ugly route ... just let them go.
I don't see where I could care at all.

As I'm primarily concerned w/ embedded systems, I'll need full
documentation and control over the device, I won't trust vendor DTBs
anyways. And I won't help people doing crippled proprietary stuff,
not at this critical point.

Even for larger systems - except the crippled x86 world - I won't even
allow any proprietary bootloader/firmware.



cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Device Tree Blob (DTB) licence

[Willy Tarreau]

On Thu, May 28, 2015 at 06:52:52PM +0200, Enrico Weigelt, metux IT consult wrote:
> Am 28.05.2015 um 15:34 schrieb Russell King - ARM Linux:
> 
> >>What's the big deal with having DTS/DTB under GPL ?
> >
> >It's really quite simple.  Other open source projects won't touch
> >_our_ DTB with a barge pole through fear of GPL contamination.
> 
> Which other foss projects do you have in mind ?

Any other OS that's not GPL'd and that might be able to run on the
same board. For example FreeBSD (though that's just an example, some
boards might be compatible with tens of OS).

> And why should they fear "poisoning" ?

Search for "GPL contamination", the problem is quite common, GPL
can turn anything GPL-compatible into GPL. So for a non-GPL project
it's very hard to adopt GPL code.

> The DTB is an entirely separate file. Just like various firmware
> blobs, startup scripts, etc, etc.

Yes, one more reason for considering whether we need to force the
same license on it or not.

> Just shipping that file (be it in
> some source tarball or in the flash of some device) doesn't make
> everything else an derived work.

It becomes quite difficult when contributors send patches which affect
both some code and such files. Keep in mind that very often a contributor
doesn't care about the licenses of the file he proposes changes to, he
just wants to have his feature merged to fix his usecase.

> Of course, the viral effect of the GPL could catch in if somebody
> directly compiles-in the dtb into something else (so it cant be
> easily separated / replaced) - but why should anybody wanna do that ?
> Sounds to me like defeating the whole purpose of DTB.

The DTB should even not be in the kernel to start with. Since it's
supposed to describe a board in a portable way to embed it into a
boot loader, it should be OS-agnostic. It just happens that these
days Linux is where most of the work is being done and naturally
it's easier to maintain the projects together. But think of it like
a BIOS on your PC. You wouldn't want to have that BIOS project driven
by a single OS, or you would be extremely careful about the possibility
for other OS to use it without any trouble. Here people do care for the
same things by ensuring that their work on DTB can be safely used, and
even attractive to avoid competing designs that ruin the experience of
users and divide developer's work.

> >So what we'll end up with is other projects creating their own DTB
> >descriptions for the same hardware, with different properties (which
> >they'll do in an effort to ensure that it isn't a "derived work" of
> >the GPL version) and the whole thing turning into a right mess - and
> >a poor experience for users because they then end up with OS specific
> >DT files.
> 
> Anybody is free do to everything on his own. Same as everybody is free
> to write his own kernel, etc.

Yes but in practice, operating systems have become so much complex that
they're not a week-end project anymore, so everyone starts from something
that already exists nowadays. Projects coexist and they need to cooperate
to avoid seeing developers do the same work in parallel and waste their
time doing the same work, the same mistakes, fixing the same bugs etc.

> But I dont see a practical usecase where the GPL's viral effect could
> catch in here in the first place.

When you're a developer and you're scratching your head wondering if
you are taking legal risks by adopting some code, if you see that simply
writing your own code fixes your doubts, you tend to prefer that way
because most developers are not lawyers and don't have the money to
consult them. And believe me, this trouble can happen at any scale,
not just large projects.

> >Alternatively, as Rob points out, people will just go the ACPI route
> >to avoid the GPL contamination problem.
> 
> If they really wanna go that ugly route ... just let them go.
> I don't see where I could care at all.

I think you don't get it : the ugly route as you say could be seen as
still better than the trouble they're scared about. Now you can probably
understand how scary it is if they'd prefer that ugly route.

> As I'm primarily concerned w/ embedded systems, I'll need full
> documentation and control over the device, I won't trust vendor DTBs
> anyways. And I won't help people doing crippled proprietary stuff,
> not at this critical point.

Nobody's talking about making stuff proprietary, just helping friend
projects adopt our work, creating de-facto standards and avoid
fragmentation. In fact proprietary stuff is often the result of a
failure to standardize something. When you're a board vendor and
you see that everyone is using the same DTB, and you want to improve
it, you know that simply sending your update to a few projects will
be enough to make it propagate everywhere. When you see that everyone
uses their own version, at that point it's cheaper to make another
fork than trying to feed everyone with updates in their respective
formats.

> Even for larger systems - except the crippled x86 world - I won't even
> allow any proprietary bootloader/firmware.

Ah ? Have you got the source of the BootRom code of the SoC on your
board to ensure it loads your bootloader as you expect it to and that
it doesn't recognize a signature and jumps to a different address or
whatever ? It's nice to care a lot about openness, but bold statements
like this don't make you look serious nor aware of what you're using,
I'm sorry. When you buy some hardware, it comes with some interfacing
with software, and you have to trust that interface at some point, or
you build your own hardware, CPU etc. This interface can be very low
level (eg: CPU jumps to 0xffff0000 upon reset), run a little bit of
code to initialize some on-chip controllers and start a boot loader
(eg: bootrom), embed the bootloader to load your OS, or come with a
complete OS. You have to decide what's acceptable to you. We all do
that. But simply saying you won't allow *any* proprietary bl/fw doesn't
make much sense.

Cheers,
Willy

Device Tree Blob (DTB) licence

[Willy Tarreau]

On Thu, May 28, 2015 at 06:52:52PM +0200, Enrico Weigelt, metux IT consult wrote:
> Am 28.05.2015 um 15:34 schrieb Russell King - ARM Linux:
> 
> >>What's the big deal with having DTS/DTB under GPL ?
> >
> >It's really quite simple.  Other open source projects won't touch
> >_our_ DTB with a barge pole through fear of GPL contamination.
> 
> Which other foss projects do you have in mind ?

Any other OS that's not GPL'd and that might be able to run on the
same board. For example FreeBSD (though that's just an example, some
boards might be compatible with tens of OS).

> And why should they fear "poisoning" ?

Search for "GPL contamination", the problem is quite common, GPL
can turn anything GPL-compatible into GPL. So for a non-GPL project
it's very hard to adopt GPL code.

> The DTB is an entirely separate file. Just like various firmware
> blobs, startup scripts, etc, etc.

Yes, one more reason for considering whether we need to force the
same license on it or not.

> Just shipping that file (be it in
> some source tarball or in the flash of some device) doesn't make
> everything else an derived work.

It becomes quite difficult when contributors send patches which affect
both some code and such files. Keep in mind that very often a contributor
doesn't care about the licenses of the file he proposes changes to, he
just wants to have his feature merged to fix his usecase.

> Of course, the viral effect of the GPL could catch in if somebody
> directly compiles-in the dtb into something else (so it cant be
> easily separated / replaced) - but why should anybody wanna do that ?
> Sounds to me like defeating the whole purpose of DTB.

The DTB should even not be in the kernel to start with. Since it's
supposed to describe a board in a portable way to embed it into a
boot loader, it should be OS-agnostic. It just happens that these
days Linux is where most of the work is being done and naturally
it's easier to maintain the projects together. But think of it like
a BIOS on your PC. You wouldn't want to have that BIOS project driven
by a single OS, or you would be extremely careful about the possibility
for other OS to use it without any trouble. Here people do care for the
same things by ensuring that their work on DTB can be safely used, and
even attractive to avoid competing designs that ruin the experience of
users and divide developer's work.

> >So what we'll end up with is other projects creating their own DTB
> >descriptions for the same hardware, with different properties (which
> >they'll do in an effort to ensure that it isn't a "derived work" of
> >the GPL version) and the whole thing turning into a right mess - and
> >a poor experience for users because they then end up with OS specific
> >DT files.
> 
> Anybody is free do to everything on his own. Same as everybody is free
> to write his own kernel, etc.

Yes but in practice, operating systems have become so much complex that
they're not a week-end project anymore, so everyone starts from something
that already exists nowadays. Projects coexist and they need to cooperate
to avoid seeing developers do the same work in parallel and waste their
time doing the same work, the same mistakes, fixing the same bugs etc.

> But I dont see a practical usecase where the GPL's viral effect could
> catch in here in the first place.

When you're a developer and you're scratching your head wondering if
you are taking legal risks by adopting some code, if you see that simply
writing your own code fixes your doubts, you tend to prefer that way
because most developers are not lawyers and don't have the money to
consult them. And believe me, this trouble can happen at any scale,
not just large projects.

> >Alternatively, as Rob points out, people will just go the ACPI route
> >to avoid the GPL contamination problem.
> 
> If they really wanna go that ugly route ... just let them go.
> I don't see where I could care at all.

I think you don't get it : the ugly route as you say could be seen as
still better than the trouble they're scared about. Now you can probably
understand how scary it is if they'd prefer that ugly route.

> As I'm primarily concerned w/ embedded systems, I'll need full
> documentation and control over the device, I won't trust vendor DTBs
> anyways. And I won't help people doing crippled proprietary stuff,
> not at this critical point.

Nobody's talking about making stuff proprietary, just helping friend
projects adopt our work, creating de-facto standards and avoid
fragmentation. In fact proprietary stuff is often the result of a
failure to standardize something. When you're a board vendor and
you see that everyone is using the same DTB, and you want to improve
it, you know that simply sending your update to a few projects will
be enough to make it propagate everywhere. When you see that everyone
uses their own version, at that point it's cheaper to make another
fork than trying to feed everyone with updates in their respective
formats.

> Even for larger systems - except the crippled x86 world - I won't even
> allow any proprietary bootloader/firmware.

Ah ? Have you got the source of the BootRom code of the SoC on your
board to ensure it loads your bootloader as you expect it to and that
it doesn't recognize a signature and jumps to a different address or
whatever ? It's nice to care a lot about openness, but bold statements
like this don't make you look serious nor aware of what you're using,
I'm sorry. When you buy some hardware, it comes with some interfacing
with software, and you have to trust that interface at some point, or
you build your own hardware, CPU etc. This interface can be very low
level (eg: CPU jumps to 0xffff0000 upon reset), run a little bit of
code to initialize some on-chip controllers and start a boot loader
(eg: bootrom), embed the bootloader to load your OS, or come with a
complete OS. You have to decide what's acceptable to you. We all do
that. But simply saying you won't allow *any* proprietary bl/fw doesn't
make much sense.

Cheers,
Willy

Re: Device Tree Blob (DTB) licence

[Willy Tarreau]

On Thu, May 28, 2015 at 06:52:52PM +0200, Enrico Weigelt, metux IT consult wrote:
> Am 28.05.2015 um 15:34 schrieb Russell King - ARM Linux:
> 
> >>What's the big deal with having DTS/DTB under GPL ?
> >
> >It's really quite simple.  Other open source projects won't touch
> >_our_ DTB with a barge pole through fear of GPL contamination.
> 
> Which other foss projects do you have in mind ?

Any other OS that's not GPL'd and that might be able to run on the
same board. For example FreeBSD (though that's just an example, some
boards might be compatible with tens of OS).

> And why should they fear "poisoning" ?

Search for "GPL contamination", the problem is quite common, GPL
can turn anything GPL-compatible into GPL. So for a non-GPL project
it's very hard to adopt GPL code.

> The DTB is an entirely separate file. Just like various firmware
> blobs, startup scripts, etc, etc.

Yes, one more reason for considering whether we need to force the
same license on it or not.

> Just shipping that file (be it in
> some source tarball or in the flash of some device) doesn't make
> everything else an derived work.

It becomes quite difficult when contributors send patches which affect
both some code and such files. Keep in mind that very often a contributor
doesn't care about the licenses of the file he proposes changes to, he
just wants to have his feature merged to fix his usecase.

> Of course, the viral effect of the GPL could catch in if somebody
> directly compiles-in the dtb into something else (so it cant be
> easily separated / replaced) - but why should anybody wanna do that ?
> Sounds to me like defeating the whole purpose of DTB.

The DTB should even not be in the kernel to start with. Since it's
supposed to describe a board in a portable way to embed it into a
boot loader, it should be OS-agnostic. It just happens that these
days Linux is where most of the work is being done and naturally
it's easier to maintain the projects together. But think of it like
a BIOS on your PC. You wouldn't want to have that BIOS project driven
by a single OS, or you would be extremely careful about the possibility
for other OS to use it without any trouble. Here people do care for the
same things by ensuring that their work on DTB can be safely used, and
even attractive to avoid competing designs that ruin the experience of
users and divide developer's work.

> >So what we'll end up with is other projects creating their own DTB
> >descriptions for the same hardware, with different properties (which
> >they'll do in an effort to ensure that it isn't a "derived work" of
> >the GPL version) and the whole thing turning into a right mess - and
> >a poor experience for users because they then end up with OS specific
> >DT files.
> 
> Anybody is free do to everything on his own. Same as everybody is free
> to write his own kernel, etc.

Yes but in practice, operating systems have become so much complex that
they're not a week-end project anymore, so everyone starts from something
that already exists nowadays. Projects coexist and they need to cooperate
to avoid seeing developers do the same work in parallel and waste their
time doing the same work, the same mistakes, fixing the same bugs etc.

> But I dont see a practical usecase where the GPL's viral effect could
> catch in here in the first place.

When you're a developer and you're scratching your head wondering if
you are taking legal risks by adopting some code, if you see that simply
writing your own code fixes your doubts, you tend to prefer that way
because most developers are not lawyers and don't have the money to
consult them. And believe me, this trouble can happen at any scale,
not just large projects.

> >Alternatively, as Rob points out, people will just go the ACPI route
> >to avoid the GPL contamination problem.
> 
> If they really wanna go that ugly route ... just let them go.
> I don't see where I could care at all.

I think you don't get it : the ugly route as you say could be seen as
still better than the trouble they're scared about. Now you can probably
understand how scary it is if they'd prefer that ugly route.

> As I'm primarily concerned w/ embedded systems, I'll need full
> documentation and control over the device, I won't trust vendor DTBs
> anyways. And I won't help people doing crippled proprietary stuff,
> not at this critical point.

Nobody's talking about making stuff proprietary, just helping friend
projects adopt our work, creating de-facto standards and avoid
fragmentation. In fact proprietary stuff is often the result of a
failure to standardize something. When you're a board vendor and
you see that everyone is using the same DTB, and you want to improve
it, you know that simply sending your update to a few projects will
be enough to make it propagate everywhere. When you see that everyone
uses their own version, at that point it's cheaper to make another
fork than trying to feed everyone with updates in their respective
formats.

> Even for larger systems - except the crippled x86 world - I won't even
> allow any proprietary bootloader/firmware.

Ah ? Have you got the source of the BootRom code of the SoC on your
board to ensure it loads your bootloader as you expect it to and that
it doesn't recognize a signature and jumps to a different address or
whatever ? It's nice to care a lot about openness, but bold statements
like this don't make you look serious nor aware of what you're using,
I'm sorry. When you buy some hardware, it comes with some interfacing
with software, and you have to trust that interface at some point, or
you build your own hardware, CPU etc. This interface can be very low
level (eg: CPU jumps to 0xffff0000 upon reset), run a little bit of
code to initialize some on-chip controllers and start a boot loader
(eg: bootrom), embed the bootloader to load your OS, or come with a
complete OS. You have to decide what's acceptable to you. We all do
that. But simply saying you won't allow *any* proprietary bl/fw doesn't
make much sense.

Cheers,
Willy

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Device Tree Blob (DTB) licence

[Enrico Weigelt, metux IT consult]

Am 29.05.2015 um 08:47 schrieb Willy Tarreau:

Hi,

>>> It's really quite simple.  Other open source projects won't touch
>>> _our_ DTB with a barge pole through fear of GPL contamination.
>>
>> Which other foss projects do you have in mind ?
>
> Any other OS that's not GPL'd and that might be able to run on the
> same board. For example FreeBSD (though that's just an example, some
> boards might be compatible with tens of OS).

IMHO, FreeBSD also ships some GPL'ed software.

As the DTS/DTB is an entirely separate entity, I don't see any
conflict or viral effect here. Of course, if they patch something
here, these patches would fall under the GPL (as with all the other
GPL'ed packages).

>> And why should they fear "poisoning" ?
>
> Search for "GPL contamination", the problem is quite common, GPL
> can turn anything GPL-compatible into GPL. So for a non-GPL project
> it's very hard to adopt GPL code.

Yes, that's the whole purpose of the GPL. The deal is pretty simple:
if you take some GPL'ed software and change it, you'll have to publish
your changes under the same rules. For entirely separate entities
(eg. dedicated programs) that's not an big issue. And for libraries,
we have LGPL.

If the DTS license would be a problem, it would be worse w/ ACPI
and any proprietary firmware/BIOSes.

>> The DTB is an entirely separate file. Just like various firmware
>> blobs, startup scripts, etc, etc.
>
> Yes, one more reason for considering whether we need to force the
> same license on it or not.

But OTOH also no need to change the dts license now.
For the integration into other (non-GPL) OS'es, it just doesn't matter.
GPL- and non-GPL software can peacefully exist on one system, if they're
not derived works.

>> Just shipping that file (be it in
>> some source tarball or in the flash of some device) doesn't make
>> everything else an derived work.
>
> It becomes quite difficult when contributors send patches which affect
> both some code and such files.

What's the big deal here ?

The dts patches will fall under GPL, the others on whichever license
the other code has.

> Keep in mind that very often a contributor doesn't care about the licenses
 > of the file he proposes changes to, he just wants to have his feature
 > merged to fix his usecase.

In that particular case, he doesn't need to - just publish the patches
under the same license as the original was.

I see the problem from a different side: certain companies simply dont
wanna play by the rules - they wanna take the benefits of FOSS (and get
it for free - like free beer), but then refuse to give anything back.
Those folks instead should buy something proprietary.

> The DTB should even not be in the kernel to start with. Since it's
> supposed to describe a board in a portable way to embed it into a
> boot loader, it should be OS-agnostic.

Aggreed at this point.
But that's IMHO an entirely different discussion.
(quite similiar to the discussion, whether udev should be bundled
or separate from systemd)

> But think of it like a BIOS on your PC.

I'd rather not think about BIOS and PC at all :p
The situation here is so ugly that I'd rather wish an own law for
enforcing these things as FOSS.

I really wish, DTS (yes source! not just binary) would replace BIOS and
ACPI completely, so I could simply run my own bootloader (eg. barebox).
Compared with x86, the ARM world (even with its thousands of different
SoCs and boards) is quite easy ;-o

> You wouldn't want to have that BIOS project driven by a single OS,

If that project would be the official Linux kernel, I'd actually be
pretty happy about that. Way better than all the UEFI crap.

> or you would be extremely careful about the possibility for other OS to
 > use it without any trouble.

Well, more careful than all these board vendors with the broken
BIOSes ... :p

 > Here people do care for the
> same things by ensuring that their work on DTB can be safely used, and
> even attractive to avoid competing designs that ruin the experience of
> users and divide developer's work.

We're just talking about one file (per board type), which is entirely
separate from the actually running OS (besides the fact, that DT-source
traditionally ships with the linux source tree).

OS vendors dont need to care about its license, just like they dont
need to care about the dozens BIOS licenses.

But board vendors need to care. And that's exactly the are which really
needs to be freed (free like freedom), because it is so vital. The whole
UEFI/TC debacle clearly shows that we *need* free firmware, because
sooner or later the boards will simply refuse to boot alternative OSes.

YES: this whole issue has a big political dimension. And that's why the
GPL had been invented in the first place. It's not just about sharing
ideas and code, it's about freedom. Goethe has written about this over
200 years ago, and today it's more valid than ever.

> Yes but in practice, operating systems have become so much complex that
> they're not a week-end project anymore, so everyone starts from something
> that already exists nowadays. Projects coexist and they need to cooperate
> to avoid seeing developers do the same work in parallel and waste their
> time doing the same work, the same mistakes, fixing the same bugs etc.

And the Linux kernel is probably the most advanced (general-use)
kernel, scaling from tiny embedded stuff to big super clusters.
The development momentum is so huge here, that it (technically) doesn't
make any sense to roll an own projects. For the DTB stuff - anybody can
just use and ship it. Even commercial vendors like Microsoft could do
that - I don't see any problem here.

I only see one practical usecase for and BSD-licensed DTS: to allow
people (eg. board vendors) to close down their own branch. And that's
exactly what the GPL shall prevent.

> When you're a developer and you're scratching your head wondering if
> you are taking legal risks by adopting some code, if you see that simply
> writing your own code fixes your doubts,

I *am* an developer, and I know how the GPL works. And I *am* often
developing for my customers. License problems with FOSS licenses just
arise when you're going to mix code under different licenes or link
libraries. Both aren't the case for DTS.

Except for one scenario: if you want to compile-in the DTB into some
proprietary blob. I'd consider that an invalid usecase. Technically
a bad idea. One might wanna do that for just one reason: to make
hard for other people (IOW: the folks who buy the devices, therefore
then are the *owners* of them). And that's exactly GPL shall prevent.

 > you tend to prefer that way because most developers are not lawyers

I'm also not a lawyer. But, as my math teacher, back in school,
used to say: read the text.

It's really not that complicated at all, once you got used to the
language - basicly just like learning a new programming language.
In fact, legal stuff and software engineering is pretty much the same
(legal systems just tend to have a higher grade of indeterminism)
Actually, I know lots of former lawyers who're now software engineers
and vice versa. Oh, and legal hacking can be great fun ;-)

 > and don't have the money to consult them.

Not necessary. Better spend some time and study the texts yourself,
instead of just blindly trusting somebody else's oppinion. Not so
different from reading source code.

And I'd highly recommend everybody to do that - even for daily life.

(oh, and if anybody likes to have some tips here, feel free to ask.
I can't give any real legal advice, as some still practised Nazi
law forbids that, if you're not an licensed attourney)

> I think you don't get it : the ugly route as you say could be seen as
> still better than the trouble they're scared about. Now you can probably
> understand how scary it is if they'd prefer that ugly route.

I'm not scared about that at all, and I don't see why anybody should be.
If some board vendor (as already done in x86 world) goes the ACPI route,
we can either reverse engineer the stuff (and write proper DTS'es) or
simply boycott their products, let them starve.

> Nobody's talking about making stuff proprietary,

But thats the big danger with licenses that allow closing down
the source.

> just helping friend projects adopt our work, creating de-facto standards
 > and avoid fragmentation.

In case of DTS/DTB, there's no need for changing the license for
that purpose - it's an separate entity anyways.

> In fact proprietary stuff is often the result of a failure to
 > standardize something.

Sure. But often, it's just the pure unwillingness for cooperation.
BSD license easily allows that - you dont need to publish your changes.
Most of the time, such decisions are made by people, who know nothing
about software engineering. If we have an viral copyleft license, like
GPL, those people are quite easy to convince (especially regarding the
fact, that the companies in question usually aren't software vendors)

> When you're a board vendor and you see that everyone is using the same DTB,
 > and you want to improve it, you know that simply sending your update
 > to a few projects will be enough to make it propagate everywhere.

Yes, and exactly that works pretty fine. *With* GPL.
Most of my clients wouldn't do this on their own, if there wasn't
an legal requirement.

> Ah ? Have you got the source of the BootRom code of the SoC on your
> board to ensure it loads your bootloader as you expect it to and that
> it doesn't recognize a signature and jumps to a different address or
> whatever ?

There isn't anything like that on my SoC. It has some tiny logic
(in cpu microcode), which just reads a few blocks via SPI (emmc,
sd, etc, depending on some pin configurations) and directly jumps
into it. The boodloader is barebox, with some own patches, compiled
own my own.

That's how I also would like to have it on x86.

> When you buy some hardware, it comes with some interfacing with software,
 > and you have to trust that interface at some point,

Well, it obviously needs some specified interface (eg. CPU's opcodes,
register specs on perhiphals, etc, etc). If I don't get the proper specs
for that, it's pretty much useless for me.

For example, on my current mx53 system, I can't use the GPUs due to lack
of specs.

 > or you build your own hardware, CPU etc.

Actually, that's already in the pipeline. Will be an entirely
different architecture, more like a huge transputer grid ... but that's
going to be off-topic ...

> This interface can be very low level (eg: CPU jumps to 0xffff0000 upon reset),
 > run a little bit of code to initialize some on-chip controllers and

Yes, and I need to know exactly how to do that initialization, so I can
put my own firmware/bootloader in here. Maybe even an XIP kernel.

> You have to decide what's acceptable to you. We all do that.

Yes, and I made the decision, that I can't tolerate any proprietary
code - not on mission critical embedded systems.


cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.

Device Tree Blob (DTB) licence

[Enrico Weigelt, metux IT consult]

Am 29.05.2015 um 08:47 schrieb Willy Tarreau:

Hi,

>>> It's really quite simple.  Other open source projects won't touch
>>> _our_ DTB with a barge pole through fear of GPL contamination.
>>
>> Which other foss projects do you have in mind ?
>
> Any other OS that's not GPL'd and that might be able to run on the
> same board. For example FreeBSD (though that's just an example, some
> boards might be compatible with tens of OS).

IMHO, FreeBSD also ships some GPL'ed software.

As the DTS/DTB is an entirely separate entity, I don't see any
conflict or viral effect here. Of course, if they patch something
here, these patches would fall under the GPL (as with all the other
GPL'ed packages).

>> And why should they fear "poisoning" ?
>
> Search for "GPL contamination", the problem is quite common, GPL
> can turn anything GPL-compatible into GPL. So for a non-GPL project
> it's very hard to adopt GPL code.

Yes, that's the whole purpose of the GPL. The deal is pretty simple:
if you take some GPL'ed software and change it, you'll have to publish
your changes under the same rules. For entirely separate entities
(eg. dedicated programs) that's not an big issue. And for libraries,
we have LGPL.

If the DTS license would be a problem, it would be worse w/ ACPI
and any proprietary firmware/BIOSes.

>> The DTB is an entirely separate file. Just like various firmware
>> blobs, startup scripts, etc, etc.
>
> Yes, one more reason for considering whether we need to force the
> same license on it or not.

But OTOH also no need to change the dts license now.
For the integration into other (non-GPL) OS'es, it just doesn't matter.
GPL- and non-GPL software can peacefully exist on one system, if they're
not derived works.

>> Just shipping that file (be it in
>> some source tarball or in the flash of some device) doesn't make
>> everything else an derived work.
>
> It becomes quite difficult when contributors send patches which affect
> both some code and such files.

What's the big deal here ?

The dts patches will fall under GPL, the others on whichever license
the other code has.

> Keep in mind that very often a contributor doesn't care about the licenses
 > of the file he proposes changes to, he just wants to have his feature
 > merged to fix his usecase.

In that particular case, he doesn't need to - just publish the patches
under the same license as the original was.

I see the problem from a different side: certain companies simply dont
wanna play by the rules - they wanna take the benefits of FOSS (and get
it for free - like free beer), but then refuse to give anything back.
Those folks instead should buy something proprietary.

> The DTB should even not be in the kernel to start with. Since it's
> supposed to describe a board in a portable way to embed it into a
> boot loader, it should be OS-agnostic.

Aggreed at this point.
But that's IMHO an entirely different discussion.
(quite similiar to the discussion, whether udev should be bundled
or separate from systemd)

> But think of it like a BIOS on your PC.

I'd rather not think about BIOS and PC at all :p
The situation here is so ugly that I'd rather wish an own law for
enforcing these things as FOSS.

I really wish, DTS (yes source! not just binary) would replace BIOS and
ACPI completely, so I could simply run my own bootloader (eg. barebox).
Compared with x86, the ARM world (even with its thousands of different
SoCs and boards) is quite easy ;-o

> You wouldn't want to have that BIOS project driven by a single OS,

If that project would be the official Linux kernel, I'd actually be
pretty happy about that. Way better than all the UEFI crap.

> or you would be extremely careful about the possibility for other OS to
 > use it without any trouble.

Well, more careful than all these board vendors with the broken
BIOSes ... :p

 > Here people do care for the
> same things by ensuring that their work on DTB can be safely used, and
> even attractive to avoid competing designs that ruin the experience of
> users and divide developer's work.

We're just talking about one file (per board type), which is entirely
separate from the actually running OS (besides the fact, that DT-source
traditionally ships with the linux source tree).

OS vendors dont need to care about its license, just like they dont
need to care about the dozens BIOS licenses.

But board vendors need to care. And that's exactly the are which really
needs to be freed (free like freedom), because it is so vital. The whole
UEFI/TC debacle clearly shows that we *need* free firmware, because
sooner or later the boards will simply refuse to boot alternative OSes.

YES: this whole issue has a big political dimension. And that's why the
GPL had been invented in the first place. It's not just about sharing
ideas and code, it's about freedom. Goethe has written about this over
200 years ago, and today it's more valid than ever.

> Yes but in practice, operating systems have become so much complex that
> they're not a week-end project anymore, so everyone starts from something
> that already exists nowadays. Projects coexist and they need to cooperate
> to avoid seeing developers do the same work in parallel and waste their
> time doing the same work, the same mistakes, fixing the same bugs etc.

And the Linux kernel is probably the most advanced (general-use)
kernel, scaling from tiny embedded stuff to big super clusters.
The development momentum is so huge here, that it (technically) doesn't
make any sense to roll an own projects. For the DTB stuff - anybody can
just use and ship it. Even commercial vendors like Microsoft could do
that - I don't see any problem here.

I only see one practical usecase for and BSD-licensed DTS: to allow
people (eg. board vendors) to close down their own branch. And that's
exactly what the GPL shall prevent.

> When you're a developer and you're scratching your head wondering if
> you are taking legal risks by adopting some code, if you see that simply
> writing your own code fixes your doubts,

I *am* an developer, and I know how the GPL works. And I *am* often
developing for my customers. License problems with FOSS licenses just
arise when you're going to mix code under different licenes or link
libraries. Both aren't the case for DTS.

Except for one scenario: if you want to compile-in the DTB into some
proprietary blob. I'd consider that an invalid usecase. Technically
a bad idea. One might wanna do that for just one reason: to make
hard for other people (IOW: the folks who buy the devices, therefore
then are the *owners* of them). And that's exactly GPL shall prevent.

 > you tend to prefer that way because most developers are not lawyers

I'm also not a lawyer. But, as my math teacher, back in school,
used to say: read the text.

It's really not that complicated at all, once you got used to the
language - basicly just like learning a new programming language.
In fact, legal stuff and software engineering is pretty much the same
(legal systems just tend to have a higher grade of indeterminism)
Actually, I know lots of former lawyers who're now software engineers
and vice versa. Oh, and legal hacking can be great fun ;-)

 > and don't have the money to consult them.

Not necessary. Better spend some time and study the texts yourself,
instead of just blindly trusting somebody else's oppinion. Not so
different from reading source code.

And I'd highly recommend everybody to do that - even for daily life.

(oh, and if anybody likes to have some tips here, feel free to ask.
I can't give any real legal advice, as some still practised Nazi
law forbids that, if you're not an licensed attourney)

> I think you don't get it : the ugly route as you say could be seen as
> still better than the trouble they're scared about. Now you can probably
> understand how scary it is if they'd prefer that ugly route.

I'm not scared about that at all, and I don't see why anybody should be.
If some board vendor (as already done in x86 world) goes the ACPI route,
we can either reverse engineer the stuff (and write proper DTS'es) or
simply boycott their products, let them starve.

> Nobody's talking about making stuff proprietary,

But thats the big danger with licenses that allow closing down
the source.

> just helping friend projects adopt our work, creating de-facto standards
 > and avoid fragmentation.

In case of DTS/DTB, there's no need for changing the license for
that purpose - it's an separate entity anyways.

> In fact proprietary stuff is often the result of a failure to
 > standardize something.

Sure. But often, it's just the pure unwillingness for cooperation.
BSD license easily allows that - you dont need to publish your changes.
Most of the time, such decisions are made by people, who know nothing
about software engineering. If we have an viral copyleft license, like
GPL, those people are quite easy to convince (especially regarding the
fact, that the companies in question usually aren't software vendors)

> When you're a board vendor and you see that everyone is using the same DTB,
 > and you want to improve it, you know that simply sending your update
 > to a few projects will be enough to make it propagate everywhere.

Yes, and exactly that works pretty fine. *With* GPL.
Most of my clients wouldn't do this on their own, if there wasn't
an legal requirement.

> Ah ? Have you got the source of the BootRom code of the SoC on your
> board to ensure it loads your bootloader as you expect it to and that
> it doesn't recognize a signature and jumps to a different address or
> whatever ?

There isn't anything like that on my SoC. It has some tiny logic
(in cpu microcode), which just reads a few blocks via SPI (emmc,
sd, etc, depending on some pin configurations) and directly jumps
into it. The boodloader is barebox, with some own patches, compiled
own my own.

That's how I also would like to have it on x86.

> When you buy some hardware, it comes with some interfacing with software,
 > and you have to trust that interface at some point,

Well, it obviously needs some specified interface (eg. CPU's opcodes,
register specs on perhiphals, etc, etc). If I don't get the proper specs
for that, it's pretty much useless for me.

For example, on my current mx53 system, I can't use the GPUs due to lack
of specs.

 > or you build your own hardware, CPU etc.

Actually, that's already in the pipeline. Will be an entirely
different architecture, more like a huge transputer grid ... but that's
going to be off-topic ...

> This interface can be very low level (eg: CPU jumps to 0xffff0000 upon reset),
 > run a little bit of code to initialize some on-chip controllers and

Yes, and I need to know exactly how to do that initialization, so I can
put my own firmware/bootloader in here. Maybe even an XIP kernel.

> You have to decide what's acceptable to you. We all do that.

Yes, and I made the decision, that I can't tolerate any proprietary
code - not on mission critical embedded systems.


cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur f?r einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschlie?lich f?r denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, d?rfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrt?mlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte l?schen Sie in diesem Fall diese Nachricht und alle Anh?nge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.

Re: Device Tree Blob (DTB) licence

[Enrico Weigelt, metux IT consult]

Am 29.05.2015 um 08:47 schrieb Willy Tarreau:

Hi,

>>> It's really quite simple.  Other open source projects won't touch
>>> _our_ DTB with a barge pole through fear of GPL contamination.
>>
>> Which other foss projects do you have in mind ?
>
> Any other OS that's not GPL'd and that might be able to run on the
> same board. For example FreeBSD (though that's just an example, some
> boards might be compatible with tens of OS).

IMHO, FreeBSD also ships some GPL'ed software.

As the DTS/DTB is an entirely separate entity, I don't see any
conflict or viral effect here. Of course, if they patch something
here, these patches would fall under the GPL (as with all the other
GPL'ed packages).

>> And why should they fear "poisoning" ?
>
> Search for "GPL contamination", the problem is quite common, GPL
> can turn anything GPL-compatible into GPL. So for a non-GPL project
> it's very hard to adopt GPL code.

Yes, that's the whole purpose of the GPL. The deal is pretty simple:
if you take some GPL'ed software and change it, you'll have to publish
your changes under the same rules. For entirely separate entities
(eg. dedicated programs) that's not an big issue. And for libraries,
we have LGPL.

If the DTS license would be a problem, it would be worse w/ ACPI
and any proprietary firmware/BIOSes.

>> The DTB is an entirely separate file. Just like various firmware
>> blobs, startup scripts, etc, etc.
>
> Yes, one more reason for considering whether we need to force the
> same license on it or not.

But OTOH also no need to change the dts license now.
For the integration into other (non-GPL) OS'es, it just doesn't matter.
GPL- and non-GPL software can peacefully exist on one system, if they're
not derived works.

>> Just shipping that file (be it in
>> some source tarball or in the flash of some device) doesn't make
>> everything else an derived work.
>
> It becomes quite difficult when contributors send patches which affect
> both some code and such files.

What's the big deal here ?

The dts patches will fall under GPL, the others on whichever license
the other code has.

> Keep in mind that very often a contributor doesn't care about the licenses
 > of the file he proposes changes to, he just wants to have his feature
 > merged to fix his usecase.

In that particular case, he doesn't need to - just publish the patches
under the same license as the original was.

I see the problem from a different side: certain companies simply dont
wanna play by the rules - they wanna take the benefits of FOSS (and get
it for free - like free beer), but then refuse to give anything back.
Those folks instead should buy something proprietary.

> The DTB should even not be in the kernel to start with. Since it's
> supposed to describe a board in a portable way to embed it into a
> boot loader, it should be OS-agnostic.

Aggreed at this point.
But that's IMHO an entirely different discussion.
(quite similiar to the discussion, whether udev should be bundled
or separate from systemd)

> But think of it like a BIOS on your PC.

I'd rather not think about BIOS and PC at all :p
The situation here is so ugly that I'd rather wish an own law for
enforcing these things as FOSS.

I really wish, DTS (yes source! not just binary) would replace BIOS and
ACPI completely, so I could simply run my own bootloader (eg. barebox).
Compared with x86, the ARM world (even with its thousands of different
SoCs and boards) is quite easy ;-o

> You wouldn't want to have that BIOS project driven by a single OS,

If that project would be the official Linux kernel, I'd actually be
pretty happy about that. Way better than all the UEFI crap.

> or you would be extremely careful about the possibility for other OS to
 > use it without any trouble.

Well, more careful than all these board vendors with the broken
BIOSes ... :p

 > Here people do care for the
> same things by ensuring that their work on DTB can be safely used, and
> even attractive to avoid competing designs that ruin the experience of
> users and divide developer's work.

We're just talking about one file (per board type), which is entirely
separate from the actually running OS (besides the fact, that DT-source
traditionally ships with the linux source tree).

OS vendors dont need to care about its license, just like they dont
need to care about the dozens BIOS licenses.

But board vendors need to care. And that's exactly the are which really
needs to be freed (free like freedom), because it is so vital. The whole
UEFI/TC debacle clearly shows that we *need* free firmware, because
sooner or later the boards will simply refuse to boot alternative OSes.

YES: this whole issue has a big political dimension. And that's why the
GPL had been invented in the first place. It's not just about sharing
ideas and code, it's about freedom. Goethe has written about this over
200 years ago, and today it's more valid than ever.

> Yes but in practice, operating systems have become so much complex that
> they're not a week-end project anymore, so everyone starts from something
> that already exists nowadays. Projects coexist and they need to cooperate
> to avoid seeing developers do the same work in parallel and waste their
> time doing the same work, the same mistakes, fixing the same bugs etc.

And the Linux kernel is probably the most advanced (general-use)
kernel, scaling from tiny embedded stuff to big super clusters.
The development momentum is so huge here, that it (technically) doesn't
make any sense to roll an own projects. For the DTB stuff - anybody can
just use and ship it. Even commercial vendors like Microsoft could do
that - I don't see any problem here.

I only see one practical usecase for and BSD-licensed DTS: to allow
people (eg. board vendors) to close down their own branch. And that's
exactly what the GPL shall prevent.

> When you're a developer and you're scratching your head wondering if
> you are taking legal risks by adopting some code, if you see that simply
> writing your own code fixes your doubts,

I *am* an developer, and I know how the GPL works. And I *am* often
developing for my customers. License problems with FOSS licenses just
arise when you're going to mix code under different licenes or link
libraries. Both aren't the case for DTS.

Except for one scenario: if you want to compile-in the DTB into some
proprietary blob. I'd consider that an invalid usecase. Technically
a bad idea. One might wanna do that for just one reason: to make
hard for other people (IOW: the folks who buy the devices, therefore
then are the *owners* of them). And that's exactly GPL shall prevent.

 > you tend to prefer that way because most developers are not lawyers

I'm also not a lawyer. But, as my math teacher, back in school,
used to say: read the text.

It's really not that complicated at all, once you got used to the
language - basicly just like learning a new programming language.
In fact, legal stuff and software engineering is pretty much the same
(legal systems just tend to have a higher grade of indeterminism)
Actually, I know lots of former lawyers who're now software engineers
and vice versa. Oh, and legal hacking can be great fun ;-)

 > and don't have the money to consult them.

Not necessary. Better spend some time and study the texts yourself,
instead of just blindly trusting somebody else's oppinion. Not so
different from reading source code.

And I'd highly recommend everybody to do that - even for daily life.

(oh, and if anybody likes to have some tips here, feel free to ask.
I can't give any real legal advice, as some still practised Nazi
law forbids that, if you're not an licensed attourney)

> I think you don't get it : the ugly route as you say could be seen as
> still better than the trouble they're scared about. Now you can probably
> understand how scary it is if they'd prefer that ugly route.

I'm not scared about that at all, and I don't see why anybody should be.
If some board vendor (as already done in x86 world) goes the ACPI route,
we can either reverse engineer the stuff (and write proper DTS'es) or
simply boycott their products, let them starve.

> Nobody's talking about making stuff proprietary,

But thats the big danger with licenses that allow closing down
the source.

> just helping friend projects adopt our work, creating de-facto standards
 > and avoid fragmentation.

In case of DTS/DTB, there's no need for changing the license for
that purpose - it's an separate entity anyways.

> In fact proprietary stuff is often the result of a failure to
 > standardize something.

Sure. But often, it's just the pure unwillingness for cooperation.
BSD license easily allows that - you dont need to publish your changes.
Most of the time, such decisions are made by people, who know nothing
about software engineering. If we have an viral copyleft license, like
GPL, those people are quite easy to convince (especially regarding the
fact, that the companies in question usually aren't software vendors)

> When you're a board vendor and you see that everyone is using the same DTB,
 > and you want to improve it, you know that simply sending your update
 > to a few projects will be enough to make it propagate everywhere.

Yes, and exactly that works pretty fine. *With* GPL.
Most of my clients wouldn't do this on their own, if there wasn't
an legal requirement.

> Ah ? Have you got the source of the BootRom code of the SoC on your
> board to ensure it loads your bootloader as you expect it to and that
> it doesn't recognize a signature and jumps to a different address or
> whatever ?

There isn't anything like that on my SoC. It has some tiny logic
(in cpu microcode), which just reads a few blocks via SPI (emmc,
sd, etc, depending on some pin configurations) and directly jumps
into it. The boodloader is barebox, with some own patches, compiled
own my own.

That's how I also would like to have it on x86.

> When you buy some hardware, it comes with some interfacing with software,
 > and you have to trust that interface at some point,

Well, it obviously needs some specified interface (eg. CPU's opcodes,
register specs on perhiphals, etc, etc). If I don't get the proper specs
for that, it's pretty much useless for me.

For example, on my current mx53 system, I can't use the GPUs due to lack
of specs.

 > or you build your own hardware, CPU etc.

Actually, that's already in the pipeline. Will be an entirely
different architecture, more like a huge transputer grid ... but that's
going to be off-topic ...

> This interface can be very low level (eg: CPU jumps to 0xffff0000 upon reset),
 > run a little bit of code to initialize some on-chip controllers and

Yes, and I need to know exactly how to do that initialization, so I can
put my own firmware/bootloader in here. Maybe even an XIP kernel.

> You have to decide what's acceptable to you. We all do that.

Yes, and I made the decision, that I can't tolerate any proprietary
code - not on mission critical embedded systems.


cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Device Tree Blob (DTB) licence

[David Lang]

On Fri, 29 May 2015, Enrico Weigelt, metux IT consult wrote:

>>> And why should they fear "poisoning" ?
>> 
>> Search for "GPL contamination", the problem is quite common, GPL
>> can turn anything GPL-compatible into GPL. So for a non-GPL project
>> it's very hard to adopt GPL code.
>
> Yes, that's the whole purpose of the GPL. The deal is pretty simple:
> if you take some GPL'ed software and change it, you'll have to publish
> your changes under the same rules. For entirely separate entities
> (eg. dedicated programs) that's not an big issue. And for libraries,
> we have LGPL.
>
> If the DTS license would be a problem, it would be worse w/ ACPI
> and any proprietary firmware/BIOSes.

not true, with a proprietary bios it's a clear "pay this much money and don't 
worry about it" while with GPL there's a nagging fear that someone you never 
heard of may sue you a decade from now claiming you need to give them the source 
to your OS.

Is having the DTB GPL so impartant that you would rather let things fall into 
the windows trap ("well it booted windows, so it must be right") instead of 
allowing a proprietary OS to use your description of the hardware?

note, this whole discussion assumes that the DTB is even copyrightable. Since 
it's intended to be strictly a functional description of what the hardware is 
able to do, that could be questioned

David Lang

Device Tree Blob (DTB) licence

[David Lang]

On Fri, 29 May 2015, Enrico Weigelt, metux IT consult wrote:

>>> And why should they fear "poisoning" ?
>> 
>> Search for "GPL contamination", the problem is quite common, GPL
>> can turn anything GPL-compatible into GPL. So for a non-GPL project
>> it's very hard to adopt GPL code.
>
> Yes, that's the whole purpose of the GPL. The deal is pretty simple:
> if you take some GPL'ed software and change it, you'll have to publish
> your changes under the same rules. For entirely separate entities
> (eg. dedicated programs) that's not an big issue. And for libraries,
> we have LGPL.
>
> If the DTS license would be a problem, it would be worse w/ ACPI
> and any proprietary firmware/BIOSes.

not true, with a proprietary bios it's a clear "pay this much money and don't 
worry about it" while with GPL there's a nagging fear that someone you never 
heard of may sue you a decade from now claiming you need to give them the source 
to your OS.

Is having the DTB GPL so impartant that you would rather let things fall into 
the windows trap ("well it booted windows, so it must be right") instead of 
allowing a proprietary OS to use your description of the hardware?

note, this whole discussion assumes that the DTB is even copyrightable. Since 
it's intended to be strictly a functional description of what the hardware is 
able to do, that could be questioned

David Lang

Re: Device Tree Blob (DTB) licence

[David Lang]

On Fri, 29 May 2015, Enrico Weigelt, metux IT consult wrote:

>>> And why should they fear "poisoning" ?
>> 
>> Search for "GPL contamination", the problem is quite common, GPL
>> can turn anything GPL-compatible into GPL. So for a non-GPL project
>> it's very hard to adopt GPL code.
>
> Yes, that's the whole purpose of the GPL. The deal is pretty simple:
> if you take some GPL'ed software and change it, you'll have to publish
> your changes under the same rules. For entirely separate entities
> (eg. dedicated programs) that's not an big issue. And for libraries,
> we have LGPL.
>
> If the DTS license would be a problem, it would be worse w/ ACPI
> and any proprietary firmware/BIOSes.

not true, with a proprietary bios it's a clear "pay this much money and don't 
worry about it" while with GPL there's a nagging fear that someone you never 
heard of may sue you a decade from now claiming you need to give them the source 
to your OS.

Is having the DTB GPL so impartant that you would rather let things fall into 
the windows trap ("well it booted windows, so it must be right") instead of 
allowing a proprietary OS to use your description of the hardware?

note, this whole discussion assumes that the DTB is even copyrightable. Since 
it's intended to be strictly a functional description of what the hardware is 
able to do, that could be questioned

David Lang
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Device Tree Blob (DTB) licence

[Geert Uytterhoeven]

On Sat, May 30, 2015 at 12:16 AM, David Lang <david@lang.hm> wrote:
>> If the DTS license would be a problem, it would be worse w/ ACPI
>> and any proprietary firmware/BIOSes.
>
> not true, with a proprietary bios it's a clear "pay this much money and
> don't worry about it" while with GPL there's a nagging fear that someone you
> never heard of may sue you a decade from now claiming you need to give them
> the source to your OS.

That can also happen with the proprietary BIOS. You don't know what's really
inside.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Device Tree Blob (DTB) licence

[Geert Uytterhoeven]

On Sat, May 30, 2015 at 12:16 AM, David Lang <david@lang.hm> wrote:
>> If the DTS license would be a problem, it would be worse w/ ACPI
>> and any proprietary firmware/BIOSes.
>
> not true, with a proprietary bios it's a clear "pay this much money and
> don't worry about it" while with GPL there's a nagging fear that someone you
> never heard of may sue you a decade from now claiming you need to give them
> the source to your OS.

That can also happen with the proprietary BIOS. You don't know what's really
inside.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Device Tree Blob (DTB) licence

[Geert Uytterhoeven]

On Sat, May 30, 2015 at 12:16 AM, David Lang <david@lang.hm> wrote:
>> If the DTS license would be a problem, it would be worse w/ ACPI
>> and any proprietary firmware/BIOSes.
>
> not true, with a proprietary bios it's a clear "pay this much money and
> don't worry about it" while with GPL there's a nagging fear that someone you
> never heard of may sue you a decade from now claiming you need to give them
> the source to your OS.

That can also happen with the proprietary BIOS. You don't know what's really
inside.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Device Tree Blob (DTB) licence

[One Thousand Gnomes]

> not true, with a proprietary bios it's a clear "pay this much money and don't 
> worry about it" while with GPL there's a nagging fear that someone you never 
> heard of may sue you a decade from now claiming you need to give them the source 
> to your OS.

Not really no - the number of companies who bought proprietary products,
resold them and then got sued because their supplier was cavalier is
huge.

> note, this whole discussion assumes that the DTB is even copyrightable. Since 
> it's intended to be strictly a functional description of what the hardware is 
> able to do, that could be questioned

I imagine you can write a DTB that is copyrightable and one that isn't.

However this is all missing one important point. Whoever wrote their DTB
gets to decide how they license it. It's nobody else's business.

Alan

Device Tree Blob (DTB) licence

[One Thousand Gnomes]

> not true, with a proprietary bios it's a clear "pay this much money and don't 
> worry about it" while with GPL there's a nagging fear that someone you never 
> heard of may sue you a decade from now claiming you need to give them the source 
> to your OS.

Not really no - the number of companies who bought proprietary products,
resold them and then got sued because their supplier was cavalier is
huge.

> note, this whole discussion assumes that the DTB is even copyrightable. Since 
> it's intended to be strictly a functional description of what the hardware is 
> able to do, that could be questioned

I imagine you can write a DTB that is copyrightable and one that isn't.

However this is all missing one important point. Whoever wrote their DTB
gets to decide how they license it. It's nobody else's business.

Alan

Re: Device Tree Blob (DTB) licence

[One Thousand Gnomes]

> not true, with a proprietary bios it's a clear "pay this much money and don't 
> worry about it" while with GPL there's a nagging fear that someone you never 
> heard of may sue you a decade from now claiming you need to give them the source 
> to your OS.

Not really no - the number of companies who bought proprietary products,
resold them and then got sued because their supplier was cavalier is
huge.

> note, this whole discussion assumes that the DTB is even copyrightable. Since 
> it's intended to be strictly a functional description of what the hardware is 
> able to do, that could be questioned

I imagine you can write a DTB that is copyrightable and one that isn't.

However this is all missing one important point. Whoever wrote their DTB
gets to decide how they license it. It's nobody else's business.

Alan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Device Tree Blob (DTB) licence

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]


> On Jun 1, 2015, at 7:12 AM, One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote:
> 
>> not true, with a proprietary bios it's a clear "pay this much money and don't
>> worry about it" while with GPL there's a nagging fear that someone you never
>> heard of may sue you a decade from now claiming you need to give them the source
>> to your OS.
> 
> Not really no - the number of companies who bought proprietary products,
> resold them and then got sued because their supplier was cavalier is
> huge.

I follow the suits pretty closely, and the number is tiny. There’s a huge hue
and cry, sure. But the number is small compared to the offenses. And the outcomes
aren’t always what one would hope. The big guys with staying power care.
The rest are hit or miss.

>> note, this whole discussion assumes that the DTB is even copyrightable. Since
>> it's intended to be strictly a functional description of what the hardware is
>> able to do, that could be questioned
> 
> I imagine you can write a DTB that is copyrightable and one that isn't.
> 
> However this is all missing one important point. Whoever wrote their DTB
> gets to decide how they license it. It's nobody else's business.

Actually it is other people’s business. There’s no harm in asking for a license
that would help the whole ecosystem.

Warner


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Device Tree Blob (DTB) licence

[Warner Losh]

> On Jun 1, 2015, at 7:12 AM, One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote:
> 
>> not true, with a proprietary bios it's a clear "pay this much money and don't
>> worry about it" while with GPL there's a nagging fear that someone you never
>> heard of may sue you a decade from now claiming you need to give them the source
>> to your OS.
> 
> Not really no - the number of companies who bought proprietary products,
> resold them and then got sued because their supplier was cavalier is
> huge.

I follow the suits pretty closely, and the number is tiny. There?s a huge hue
and cry, sure. But the number is small compared to the offenses. And the outcomes
aren?t always what one would hope. The big guys with staying power care.
The rest are hit or miss.

>> note, this whole discussion assumes that the DTB is even copyrightable. Since
>> it's intended to be strictly a functional description of what the hardware is
>> able to do, that could be questioned
> 
> I imagine you can write a DTB that is copyrightable and one that isn't.
> 
> However this is all missing one important point. Whoever wrote their DTB
> gets to decide how they license it. It's nobody else's business.

Actually it is other people?s business. There?s no harm in asking for a license
that would help the whole ecosystem.

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150601/2165484f/attachment.sig>

Re: Device Tree Blob (DTB) licence

[Rob Landley]

2015-05-28 7:32 GMT-05:00 Enrico Weigelt, metux IT consult <weigelt@melag.de>:
> Am 25.05.2015 um 09:14 schrieb Rob Landley:
>
>> Personally, I'm sad we're starting to get ACPI for arm but if device
>> tree data files are only available under GPL, people will hold their
>> nose and deploy ACPI.
>
>
> What's the big deal with having DTS/DTB under GPL ?

One problem is that there's no such thing as "The GPL" anymore. The
Linux kernel and Samba can't share code anymore, even though they
implement two ends of the same protocol, thanks to GPLv3.

This seems to have badly damaged the long term viability of GPLv2,
which used to be synonymous with copyleft (category killer license)
and acted as a universal receiver because it was a terminal node in a
directed graph of license convertibility reducing most licensing
decisions to a simple binary "is it GPL compatible or not", which
greatly appealed to developers who aren't lawyers and don't want to
be.

But now a project that's "GPLv2 or later" can't accept code from
_either_ the kernel or samba (neither provides the implicit dual
license they need). Projects like QEMU are stuck between wanting to
turn kernel drivers inside out to make device emulations (GPLv2 code)
and grab processor definitions from gcc or binutils (GPLv3 code) and
one project cannot accept both because GPL + GPL is a license
conflict.

In the absence of a universal receiver license, new developers
entering the community are mostly either opting for universal donor
(BSD-like*) licenses, or taking a Napster approach lumping copyright
in with software patents as "too dumb to live" and refusing to specify
any license at all. (The owners of github are trying very hard to make
"no license specified" stop being the most popular license on github.)

Of course "BSD-like" would be public domain except for 20 years of
FUD, so they're mostly choosing one of the dozens of public domain
equivalent licenses like the various BSDs and MIT and ISC and Apache
that are equivalent except for "copy this license text exactly"
clauses that cause endless license bloat over time. (I asked the
Android developers why
https://github.com/android/platform_system_core/blob/master/toolbox/NOTICE
had so many concatenated copies of seemingly identical license text,
and the answer was "the date at the top changed, and a strict reading
of the license says..." And if you think that's bad, somebody showed
me the about->license pulldown on their "kindle paperwhite" with over
THREE HUNDRED PAGES of concatenated licenses.)

Personally I prefer public domain equivalent licenses like CC0 or
unlicense.org or my own "zero clause bsd", which DON'T require you to
copy specific license text verbatim into derived works. When combining
BSD with other BSD it's merely annoying, but when combining BSD with
GPL? I'm still waiting for some troll to inherit somebody's copyrights
and sue a GPL developer for incorporating BSD code into a GPL project
and ignoring the "no additional restrictions" of GPL clashing with the
"copy this license text exactly into all derived works" of BSD, and
pointing to the BSDI vs AT&T lawsuit to go "no really, this matters,
pay up now". But sure, SCO was unique, it's not like dying business
models exploding into a cloud of intellectual property litigation
happens all the time. Oh wait.

So in general, there are a lot of people out there not wanting to get
any of this crap on them. And if you try to punish them for not doing
things your way, they write a crappy new one that gets widely deployed
as a "standard" anyway, and welcome back to the unix fragmentation of
the 1980's.

Most of this can be laid at the door of GPLv3.  Android's "no gpl in
userspace" policy is why they ripped out bluez and wrote a replacement
bluedroid from scratch. The bluez developers keep going "if we just
improve the code enough people will get over the license" (no really:
https://lwn.net/Articles/597293/) but their FAQ literally doesn't
specify _which_ GPL they're under: http://www.bluez.org/faq/common/
(Is it the one you can't use with kernel code, the one you can't
combine with samba code, or the or-later version that can't accept
code from either source into its next release? Do they even know? have
they been tracking this? Have they already accepted conflictingly
licensed patches without knowing it and somebody is going to sue _you_
instead of suing the upstream the way microsoft and oratroll went
after all the android vendors for cash but refused to allow google to
step in and defend them?)

Apple's great GPL purge
(http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/) is why we
have LLVM replacing gcc, they literally stopped xcode on the last
GPLv2 releases (gcc 4.2.1 and binutils 2.17) for over five years while
they sponsored work on a replacement. When samba went gplv3, they did
http://www.osnews.com/story/24572/Apple_Ditches_SAMBA_in_Favour_of_Homegrown_Replacement
for samba and so on. But they _start_ by targeting GPLv3 code, and
then continue on to remove GPLv2 code because it's tarred with the
same brush.

The pro-gpl guys have tried various coercion tactics to get their way,
which hasn't helped. The FSF sued CISCO in 2008 over the same 2003
vendor BSP that had already been beaten out of them to produce OpenWRT
(and remember when I said you don't sue the upstream you sue the
individual customers when maximizing your payout? The BSP was from
Broadcom, so the FSF sued Cisco). Lesson: "These guys will never be
satisifed, they will come back years later for another bite at the
same apple, you only _think_ you're safe if you're using their stuff."
The FSF also retroactively deleted binutils 2.17 (the last GPLv2
version) off their ftp site and replaced it with a binutils 2.17a
containing GPLv3 code, which they symlinked from the old name. (No
really. They did the same thing with gdb 6.6 except there they didn't
put a symlink, http://ftp.gnu.org/gnu/gdb/ . Remember how I said qemu
wanted machine definitions they could get from _which_ two packages?
QEMU went GPLv2 only to stay compatible with the kernel.) The FSF's
"You _WILL_ bow down before version 3!" push included its own
sourceforge clone declaring GPLv2 only an unacceptable license (but
BSD still was, yes really, https://lwn.net/Articles/176582/) and don't
forget what the FSF did to Mepis
http://archive09.linux.com/articles/55285 (sued them for not mirroring
UNMODIFIED source tarballs readily available on the upstream website).

The moral here is that large portions of the industry are now
convinced GPL advocates can't be trusted. They desperately do not want
to get any of this _on_ them. The kernel is grandfathered in, in part
because it's always tolerated (if not enjoyed) binary modules, but do
you really think that if Android decided "time to switch to BSD" it
would take them longer than 18 months to port everything they care
about? They re-port every kernel release...

I gave a talk about this at Ohio LinuxFest in 2013:

outline: http://landley.net/talks/ohio-2013.txt
audio: https://archive.org/download/OhioLinuxfest2013/24-Rob_Landley-The_Rise_and_Fall_of_Copyleft.mp3

> Important Notice: This message may contain confidential or privileged
> information. It is intended only for the person it was addressed to. If you
> are not the intended recipient of this email you may not copy, forward,
> disclose or otherwise use it or any part of it in any form whatsoever. If
> you received this email in error please notify the sender by replying and
> delete this message and any attachments without retaining a copy.

P.S. some of us actually care about licenses being appropriate to what
they're applied to, and at least theoretically capable of being
honored. Your email footer may be very slightly undermining your
position here.

Rob

Device Tree Blob (DTB) licence

[Rob Landley]

2015-05-28 7:32 GMT-05:00 Enrico Weigelt, metux IT consult <weigelt@melag.de>:
> Am 25.05.2015 um 09:14 schrieb Rob Landley:
>
>> Personally, I'm sad we're starting to get ACPI for arm but if device
>> tree data files are only available under GPL, people will hold their
>> nose and deploy ACPI.
>
>
> What's the big deal with having DTS/DTB under GPL ?

One problem is that there's no such thing as "The GPL" anymore. The
Linux kernel and Samba can't share code anymore, even though they
implement two ends of the same protocol, thanks to GPLv3.

This seems to have badly damaged the long term viability of GPLv2,
which used to be synonymous with copyleft (category killer license)
and acted as a universal receiver because it was a terminal node in a
directed graph of license convertibility reducing most licensing
decisions to a simple binary "is it GPL compatible or not", which
greatly appealed to developers who aren't lawyers and don't want to
be.

But now a project that's "GPLv2 or later" can't accept code from
_either_ the kernel or samba (neither provides the implicit dual
license they need). Projects like QEMU are stuck between wanting to
turn kernel drivers inside out to make device emulations (GPLv2 code)
and grab processor definitions from gcc or binutils (GPLv3 code) and
one project cannot accept both because GPL + GPL is a license
conflict.

In the absence of a universal receiver license, new developers
entering the community are mostly either opting for universal donor
(BSD-like*) licenses, or taking a Napster approach lumping copyright
in with software patents as "too dumb to live" and refusing to specify
any license at all. (The owners of github are trying very hard to make
"no license specified" stop being the most popular license on github.)

Of course "BSD-like" would be public domain except for 20 years of
FUD, so they're mostly choosing one of the dozens of public domain
equivalent licenses like the various BSDs and MIT and ISC and Apache
that are equivalent except for "copy this license text exactly"
clauses that cause endless license bloat over time. (I asked the
Android developers why
https://github.com/android/platform_system_core/blob/master/toolbox/NOTICE
had so many concatenated copies of seemingly identical license text,
and the answer was "the date at the top changed, and a strict reading
of the license says..." And if you think that's bad, somebody showed
me the about->license pulldown on their "kindle paperwhite" with over
THREE HUNDRED PAGES of concatenated licenses.)

Personally I prefer public domain equivalent licenses like CC0 or
unlicense.org or my own "zero clause bsd", which DON'T require you to
copy specific license text verbatim into derived works. When combining
BSD with other BSD it's merely annoying, but when combining BSD with
GPL? I'm still waiting for some troll to inherit somebody's copyrights
and sue a GPL developer for incorporating BSD code into a GPL project
and ignoring the "no additional restrictions" of GPL clashing with the
"copy this license text exactly into all derived works" of BSD, and
pointing to the BSDI vs AT&T lawsuit to go "no really, this matters,
pay up now". But sure, SCO was unique, it's not like dying business
models exploding into a cloud of intellectual property litigation
happens all the time. Oh wait.

So in general, there are a lot of people out there not wanting to get
any of this crap on them. And if you try to punish them for not doing
things your way, they write a crappy new one that gets widely deployed
as a "standard" anyway, and welcome back to the unix fragmentation of
the 1980's.

Most of this can be laid at the door of GPLv3.  Android's "no gpl in
userspace" policy is why they ripped out bluez and wrote a replacement
bluedroid from scratch. The bluez developers keep going "if we just
improve the code enough people will get over the license" (no really:
https://lwn.net/Articles/597293/) but their FAQ literally doesn't
specify _which_ GPL they're under: http://www.bluez.org/faq/common/
(Is it the one you can't use with kernel code, the one you can't
combine with samba code, or the or-later version that can't accept
code from either source into its next release? Do they even know? have
they been tracking this? Have they already accepted conflictingly
licensed patches without knowing it and somebody is going to sue _you_
instead of suing the upstream the way microsoft and oratroll went
after all the android vendors for cash but refused to allow google to
step in and defend them?)

Apple's great GPL purge
(http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/) is why we
have LLVM replacing gcc, they literally stopped xcode on the last
GPLv2 releases (gcc 4.2.1 and binutils 2.17) for over five years while
they sponsored work on a replacement. When samba went gplv3, they did
http://www.osnews.com/story/24572/Apple_Ditches_SAMBA_in_Favour_of_Homegrown_Replacement
for samba and so on. But they _start_ by targeting GPLv3 code, and
then continue on to remove GPLv2 code because it's tarred with the
same brush.

The pro-gpl guys have tried various coercion tactics to get their way,
which hasn't helped. The FSF sued CISCO in 2008 over the same 2003
vendor BSP that had already been beaten out of them to produce OpenWRT
(and remember when I said you don't sue the upstream you sue the
individual customers when maximizing your payout? The BSP was from
Broadcom, so the FSF sued Cisco). Lesson: "These guys will never be
satisifed, they will come back years later for another bite at the
same apple, you only _think_ you're safe if you're using their stuff."
The FSF also retroactively deleted binutils 2.17 (the last GPLv2
version) off their ftp site and replaced it with a binutils 2.17a
containing GPLv3 code, which they symlinked from the old name. (No
really. They did the same thing with gdb 6.6 except there they didn't
put a symlink, http://ftp.gnu.org/gnu/gdb/ . Remember how I said qemu
wanted machine definitions they could get from _which_ two packages?
QEMU went GPLv2 only to stay compatible with the kernel.) The FSF's
"You _WILL_ bow down before version 3!" push included its own
sourceforge clone declaring GPLv2 only an unacceptable license (but
BSD still was, yes really, https://lwn.net/Articles/176582/) and don't
forget what the FSF did to Mepis
http://archive09.linux.com/articles/55285 (sued them for not mirroring
UNMODIFIED source tarballs readily available on the upstream website).

The moral here is that large portions of the industry are now
convinced GPL advocates can't be trusted. They desperately do not want
to get any of this _on_ them. The kernel is grandfathered in, in part
because it's always tolerated (if not enjoyed) binary modules, but do
you really think that if Android decided "time to switch to BSD" it
would take them longer than 18 months to port everything they care
about? They re-port every kernel release...

I gave a talk about this at Ohio LinuxFest in 2013:

outline: http://landley.net/talks/ohio-2013.txt
audio: https://archive.org/download/OhioLinuxfest2013/24-Rob_Landley-The_Rise_and_Fall_of_Copyleft.mp3

> Important Notice: This message may contain confidential or privileged
> information. It is intended only for the person it was addressed to. If you
> are not the intended recipient of this email you may not copy, forward,
> disclose or otherwise use it or any part of it in any form whatsoever. If
> you received this email in error please notify the sender by replying and
> delete this message and any attachments without retaining a copy.

P.S. some of us actually care about licenses being appropriate to what
they're applied to, and at least theoretically capable of being
honored. Your email footer may be very slightly undermining your
position here.

Rob

Re: Device Tree Blob (DTB) licence

[Rob Landley]

2015-05-28 7:32 GMT-05:00 Enrico Weigelt, metux IT consult <weigelt@melag.de>:
> Am 25.05.2015 um 09:14 schrieb Rob Landley:
>
>> Personally, I'm sad we're starting to get ACPI for arm but if device
>> tree data files are only available under GPL, people will hold their
>> nose and deploy ACPI.
>
>
> What's the big deal with having DTS/DTB under GPL ?

One problem is that there's no such thing as "The GPL" anymore. The
Linux kernel and Samba can't share code anymore, even though they
implement two ends of the same protocol, thanks to GPLv3.

This seems to have badly damaged the long term viability of GPLv2,
which used to be synonymous with copyleft (category killer license)
and acted as a universal receiver because it was a terminal node in a
directed graph of license convertibility reducing most licensing
decisions to a simple binary "is it GPL compatible or not", which
greatly appealed to developers who aren't lawyers and don't want to
be.

But now a project that's "GPLv2 or later" can't accept code from
_either_ the kernel or samba (neither provides the implicit dual
license they need). Projects like QEMU are stuck between wanting to
turn kernel drivers inside out to make device emulations (GPLv2 code)
and grab processor definitions from gcc or binutils (GPLv3 code) and
one project cannot accept both because GPL + GPL is a license
conflict.

In the absence of a universal receiver license, new developers
entering the community are mostly either opting for universal donor
(BSD-like*) licenses, or taking a Napster approach lumping copyright
in with software patents as "too dumb to live" and refusing to specify
any license at all. (The owners of github are trying very hard to make
"no license specified" stop being the most popular license on github.)

Of course "BSD-like" would be public domain except for 20 years of
FUD, so they're mostly choosing one of the dozens of public domain
equivalent licenses like the various BSDs and MIT and ISC and Apache
that are equivalent except for "copy this license text exactly"
clauses that cause endless license bloat over time. (I asked the
Android developers why
https://github.com/android/platform_system_core/blob/master/toolbox/NOTICE
had so many concatenated copies of seemingly identical license text,
and the answer was "the date at the top changed, and a strict reading
of the license says..." And if you think that's bad, somebody showed
me the about->license pulldown on their "kindle paperwhite" with over
THREE HUNDRED PAGES of concatenated licenses.)

Personally I prefer public domain equivalent licenses like CC0 or
unlicense.org or my own "zero clause bsd", which DON'T require you to
copy specific license text verbatim into derived works. When combining
BSD with other BSD it's merely annoying, but when combining BSD with
GPL? I'm still waiting for some troll to inherit somebody's copyrights
and sue a GPL developer for incorporating BSD code into a GPL project
and ignoring the "no additional restrictions" of GPL clashing with the
"copy this license text exactly into all derived works" of BSD, and
pointing to the BSDI vs AT&T lawsuit to go "no really, this matters,
pay up now". But sure, SCO was unique, it's not like dying business
models exploding into a cloud of intellectual property litigation
happens all the time. Oh wait.

So in general, there are a lot of people out there not wanting to get
any of this crap on them. And if you try to punish them for not doing
things your way, they write a crappy new one that gets widely deployed
as a "standard" anyway, and welcome back to the unix fragmentation of
the 1980's.

Most of this can be laid at the door of GPLv3.  Android's "no gpl in
userspace" policy is why they ripped out bluez and wrote a replacement
bluedroid from scratch. The bluez developers keep going "if we just
improve the code enough people will get over the license" (no really:
https://lwn.net/Articles/597293/) but their FAQ literally doesn't
specify _which_ GPL they're under: http://www.bluez.org/faq/common/
(Is it the one you can't use with kernel code, the one you can't
combine with samba code, or the or-later version that can't accept
code from either source into its next release? Do they even know? have
they been tracking this? Have they already accepted conflictingly
licensed patches without knowing it and somebody is going to sue _you_
instead of suing the upstream the way microsoft and oratroll went
after all the android vendors for cash but refused to allow google to
step in and defend them?)

Apple's great GPL purge
(http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/) is why we
have LLVM replacing gcc, they literally stopped xcode on the last
GPLv2 releases (gcc 4.2.1 and binutils 2.17) for over five years while
they sponsored work on a replacement. When samba went gplv3, they did
http://www.osnews.com/story/24572/Apple_Ditches_SAMBA_in_Favour_of_Homegrown_Replacement
for samba and so on. But they _start_ by targeting GPLv3 code, and
then continue on to remove GPLv2 code because it's tarred with the
same brush.

The pro-gpl guys have tried various coercion tactics to get their way,
which hasn't helped. The FSF sued CISCO in 2008 over the same 2003
vendor BSP that had already been beaten out of them to produce OpenWRT
(and remember when I said you don't sue the upstream you sue the
individual customers when maximizing your payout? The BSP was from
Broadcom, so the FSF sued Cisco). Lesson: "These guys will never be
satisifed, they will come back years later for another bite at the
same apple, you only _think_ you're safe if you're using their stuff."
The FSF also retroactively deleted binutils 2.17 (the last GPLv2
version) off their ftp site and replaced it with a binutils 2.17a
containing GPLv3 code, which they symlinked from the old name. (No
really. They did the same thing with gdb 6.6 except there they didn't
put a symlink, http://ftp.gnu.org/gnu/gdb/ . Remember how I said qemu
wanted machine definitions they could get from _which_ two packages?
QEMU went GPLv2 only to stay compatible with the kernel.) The FSF's
"You _WILL_ bow down before version 3!" push included its own
sourceforge clone declaring GPLv2 only an unacceptable license (but
BSD still was, yes really, https://lwn.net/Articles/176582/) and don't
forget what the FSF did to Mepis
http://archive09.linux.com/articles/55285 (sued them for not mirroring
UNMODIFIED source tarballs readily available on the upstream website).

The moral here is that large portions of the industry are now
convinced GPL advocates can't be trusted. They desperately do not want
to get any of this _on_ them. The kernel is grandfathered in, in part
because it's always tolerated (if not enjoyed) binary modules, but do
you really think that if Android decided "time to switch to BSD" it
would take them longer than 18 months to port everything they care
about? They re-port every kernel release...

I gave a talk about this at Ohio LinuxFest in 2013:

outline: http://landley.net/talks/ohio-2013.txt
audio: https://archive.org/download/OhioLinuxfest2013/24-Rob_Landley-The_Rise_and_Fall_of_Copyleft.mp3

> Important Notice: This message may contain confidential or privileged
> information. It is intended only for the person it was addressed to. If you
> are not the intended recipient of this email you may not copy, forward,
> disclose or otherwise use it or any part of it in any form whatsoever. If
> you received this email in error please notify the sender by replying and
> delete this message and any attachments without retaining a copy.

P.S. some of us actually care about licenses being appropriate to what
they're applied to, and at least theoretically capable of being
honored. Your email footer may be very slightly undermining your
position here.

Rob

Re: Device Tree Blob (DTB) licence

[Enrico Weigelt, metux IT consult]

Am 29.05.2015 um 05:31 schrieb Rob Landley:

 >> What's the big deal with having DTS/DTB under GPL ?
>
> One problem is that there's no such thing as "The GPL" anymore.

There are different versions. The kernel source clearly states
GPLv2 (I, personally, would prefer v3 to prevent Tivoization)

> The Linux kernel and Samba can't share code anymore,

Do they really need to ?
One could ask, whether smb support should belong into the kernel
at all (instead of, eg., going via FUSE or 9P), but that's an
entirely different discussion.

> even though they implement two ends of the same protocol, thanks to GPLv3.

Samba folks made the decision to prevent Tivoization of their code.
I fully agree with that decision, and I wish the same for the kernel.

> This seems to have badly damaged the long term viability of GPLv2,
> which used to be synonymous with copyleft (category killer license)
> and acted as a universal receiver because it was a terminal node in a
> directed graph of license convertibility reducing most licensing
> decisions to a simple binary "is it GPL compatible or not", which
> greatly appealed to developers who aren't lawyers and don't want to
> be.

Well, such things happen, if people have different views. In that case
those who want to prevent Tivoization on the one and those who wanna
allow it on the other side.

I rerely have the need to really copy-and-paste code from one project
to another. When patching existing ones, I just stick to the upstream's
license. And when starting new FOSS projects, I clearly choose (L)GPLv3,
because I'm strictly against Tivoization.

> But now a project that's "GPLv2 or later" can't accept code from
> _either_ the kernel or samba (neither provides the implicit dual
> license they need).

Well, that's a decision of the individual projects - everybody has
to live with his/her own decisions.

> Projects like QEMU are stuck between wanting to
> turn kernel drivers inside out to make device emulations (GPLv2 code)
> and grab processor definitions from gcc or binutils (GPLv3 code) and
> one project cannot accept both because GPL + GPL is a license
> conflict.

Seems to be a rare case to me. In general, I'd suggest making things
used by several distinct projects into their own distinct entities.

Note: the GPL's viral effect doesn't depend on whether the sources
are collected in one big repo, but on what is compiled-/linked-into
where.

> Of course "BSD-like" would be public domain except for 20 years of
> FUD, so they're mostly choosing one of the dozens of public domain
> equivalent licenses like the various BSDs and MIT and ISC and Apache
> that are equivalent except for "copy this license text exactly"
> clauses that cause endless license bloat over time.

It's not entirely FUD. The questions is NOT whether the original open
code will be wiped out of the net or people simply dont work on it
anymore. The main question here is, whether foss developers (often
working for free) want to help people producing non-free stuff. BSD
like to allow that, FSF folks dont. They just have different views on
that matter. IMHO, BSD folks are just interested in getting back
contributions, while FSF folks also have a broader political agenda. I,
personally, share that agenda (even more: I strongly believe that
software patents should be eradicated).

> Personally I prefer public domain equivalent licenses like CC0 or
> unlicense.org or my own "zero clause bsd", which DON'T require you to
> copy specific license text verbatim into derived works.

Well, I have an fundamentally different oppinion on that. If I publish
my code for free, I dont want assist anybody in producing non-free
stuff. (free like freedom, not free beer)

> Most of this can be laid at the door of GPLv3.

Because many folks don't wanna fight against Tivoization.
I'll have to accept that, but I don't need to coorporate.

 > Android's "no gpl in userspace" policy is why they ripped out bluez
 > and wrote a replacement bluedroid from scratch.

The really interesting question is: why do they have that policy ?
Maybe because they aren't interested in *free* (as freedom) software,
but just open source.

Otherwise they'd have an strict policy of nothing proprietary in
kernel space.

> The bluez developers keep going "if we just
> improve the code enough people will get over the license" (no really:
> https://lwn.net/Articles/597293/) but their FAQ literally doesn't
> specify _which_ GPL they're under: http://www.bluez.org/faq/common/
> (Is it the one you can't use with kernel code, the one you can't
> combine with samba code, or the or-later version that can't accept
> code from either source into its next release?

Why would one want to mix bluez code with the kernel or samba ?

> Apple's great GPL purge
> (http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/)

Apple belongs to the really bad guys, what Microsoft previously was.
This is the StaSi. I have no mercy for them.

> is why we have LLVM replacing gcc, they literally stopped xcode on the last
> GPLv2 releases (gcc 4.2.1 and binutils 2.17) for over five years while
> they sponsored work on a replacement.

For xcode vs gcc, I dont really see any actual license _conflict_.
This was an political action, and we should take it as that.
Apple is against freedom. The least thing, we - the people - should
do is not helping them, not giving them a single penny.

> When samba went gplv3, they did
> http://www.osnews.com/story/24572/Apple_Ditches_SAMBA_in_Favour_of_Homegrown_Replacement
> for samba and so on.

Fine. They should do so. We don't need them. We lived happily without
them, and we'll continue to do so. SMB is just old legacy anyways,
just for interfacing with Toy-OS. (actually, I haven't had any single
Windows system for about 20 years - never missed that).

> The pro-gpl guys have tried various coercion tactics to get their way,
> which hasn't helped. The FSF sued CISCO in 2008 over the same 2003
> vendor BSP that had already been beaten out of them to produce OpenWRT
> (and remember when I said you don't sue the upstream you sue the
> individual customers when maximizing your payout?

No, you sue them for the biggest policitical impact.
Yes: it is very much about politics.

 > The BSP was from Broadcom, so the FSF sued Cisco).

CISCO distributed the devices, that's why the primary infringenment
was done by them. Of course, Boardcom should have been sued, too.

> Lesson: "These guys will never be satisifed,

No. They (more precisely: we) will be satisfied, as long as you place
by the rules. And the rules are pretty clear - just read the text.
And if you don't like these rules, just pick something else.

> The FSF also retroactively deleted binutils 2.17 (the last GPLv2
> version) off their ftp site and replaced it with a binutils 2.17a
> containing GPLv3 code, which they symlinked from the old name. (No
> really. They did the same thing with gdb 6.6 except there they didn't
> put a symlink, http://ftp.gnu.org/gnu/gdb/ .

Okay, that's a bad trick. Or just a bit stupidity.
Do we have evidence that this really was on purpose ?

> Remember how I said qemu
> wanted machine definitions they could get from _which_ two packages?

Well, they still can use the old ones. And if they patch anything there,
they're free to decide whether to dual-license or not.

> QEMU went GPLv2 only to stay compatible with the kernel.)

I haven't had a deeper look into QEMU source, but I wonder at which
places exactly it would make sense to share / transfer code from
kernel to QEMU. Any example ?

 > and don't forget what the FSF did to Mepis
> http://archive09.linux.com/articles/55285 (sued them for not mirroring
> UNMODIFIED source tarballs readily available on the upstream website).

They just were asked to comply to their part of the deal.
And as they do now, no reason for whining about it anymore.

> The kernel is grandfathered in, in part because it's always tolerated (if
 > not enjoyed) binary modules,

Actually, I strongly believe, they shouldn't be tolerated at all.

> but do you really think that if Android  decided
 > "time to switch to BSD" it would take them longer than 18 months to
 > port everything they care about? They re-port every kernel release...

Maybe. Just let them do it if they wish. I don't really care.

> I gave a talk about this at Ohio LinuxFest in 2013:
>
> outline: http://landley.net/talks/ohio-2013.txt
> audio: https://archive.org/download/OhioLinuxfest2013/24-Rob_Landley-The_Rise_and_Fall_of_Copyleft.mp3

You should learn the difference between opensource and free software.
  --> free like freedom, not free beer.

>> Important Notice: This message may contain confidential or privileged
>> information. It is intended only for the person it was addressed to. If you
>> are not the intended recipient of this email you may not copy, forward,
>> disclose or otherwise use it or any part of it in any form whatsoever. If
>> you received this email in error please notify the sender by replying and
>> delete this message and any attachments without retaining a copy.
>
> P.S. some of us actually care about licenses being appropriate to what
> they're applied to, and at least theoretically capable of being
> honored. Your email footer may be very slightly undermining your
> position here.

This is just a dumb auto-generated footer, coming from my client's
mail server over here ... I'm just too lazy for setting up an own
MTA on my workstation. You can safely ignore that.

--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.

Device Tree Blob (DTB) licence

[Enrico Weigelt, metux IT consult]

Am 29.05.2015 um 05:31 schrieb Rob Landley:

 >> What's the big deal with having DTS/DTB under GPL ?
>
> One problem is that there's no such thing as "The GPL" anymore.

There are different versions. The kernel source clearly states
GPLv2 (I, personally, would prefer v3 to prevent Tivoization)

> The Linux kernel and Samba can't share code anymore,

Do they really need to ?
One could ask, whether smb support should belong into the kernel
at all (instead of, eg., going via FUSE or 9P), but that's an
entirely different discussion.

> even though they implement two ends of the same protocol, thanks to GPLv3.

Samba folks made the decision to prevent Tivoization of their code.
I fully agree with that decision, and I wish the same for the kernel.

> This seems to have badly damaged the long term viability of GPLv2,
> which used to be synonymous with copyleft (category killer license)
> and acted as a universal receiver because it was a terminal node in a
> directed graph of license convertibility reducing most licensing
> decisions to a simple binary "is it GPL compatible or not", which
> greatly appealed to developers who aren't lawyers and don't want to
> be.

Well, such things happen, if people have different views. In that case
those who want to prevent Tivoization on the one and those who wanna
allow it on the other side.

I rerely have the need to really copy-and-paste code from one project
to another. When patching existing ones, I just stick to the upstream's
license. And when starting new FOSS projects, I clearly choose (L)GPLv3,
because I'm strictly against Tivoization.

> But now a project that's "GPLv2 or later" can't accept code from
> _either_ the kernel or samba (neither provides the implicit dual
> license they need).

Well, that's a decision of the individual projects - everybody has
to live with his/her own decisions.

> Projects like QEMU are stuck between wanting to
> turn kernel drivers inside out to make device emulations (GPLv2 code)
> and grab processor definitions from gcc or binutils (GPLv3 code) and
> one project cannot accept both because GPL + GPL is a license
> conflict.

Seems to be a rare case to me. In general, I'd suggest making things
used by several distinct projects into their own distinct entities.

Note: the GPL's viral effect doesn't depend on whether the sources
are collected in one big repo, but on what is compiled-/linked-into
where.

> Of course "BSD-like" would be public domain except for 20 years of
> FUD, so they're mostly choosing one of the dozens of public domain
> equivalent licenses like the various BSDs and MIT and ISC and Apache
> that are equivalent except for "copy this license text exactly"
> clauses that cause endless license bloat over time.

It's not entirely FUD. The questions is NOT whether the original open
code will be wiped out of the net or people simply dont work on it
anymore. The main question here is, whether foss developers (often
working for free) want to help people producing non-free stuff. BSD
like to allow that, FSF folks dont. They just have different views on
that matter. IMHO, BSD folks are just interested in getting back
contributions, while FSF folks also have a broader political agenda. I,
personally, share that agenda (even more: I strongly believe that
software patents should be eradicated).

> Personally I prefer public domain equivalent licenses like CC0 or
> unlicense.org or my own "zero clause bsd", which DON'T require you to
> copy specific license text verbatim into derived works.

Well, I have an fundamentally different oppinion on that. If I publish
my code for free, I dont want assist anybody in producing non-free
stuff. (free like freedom, not free beer)

> Most of this can be laid at the door of GPLv3.

Because many folks don't wanna fight against Tivoization.
I'll have to accept that, but I don't need to coorporate.

 > Android's "no gpl in userspace" policy is why they ripped out bluez
 > and wrote a replacement bluedroid from scratch.

The really interesting question is: why do they have that policy ?
Maybe because they aren't interested in *free* (as freedom) software,
but just open source.

Otherwise they'd have an strict policy of nothing proprietary in
kernel space.

> The bluez developers keep going "if we just
> improve the code enough people will get over the license" (no really:
> https://lwn.net/Articles/597293/) but their FAQ literally doesn't
> specify _which_ GPL they're under: http://www.bluez.org/faq/common/
> (Is it the one you can't use with kernel code, the one you can't
> combine with samba code, or the or-later version that can't accept
> code from either source into its next release?

Why would one want to mix bluez code with the kernel or samba ?

> Apple's great GPL purge
> (http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/)

Apple belongs to the really bad guys, what Microsoft previously was.
This is the StaSi. I have no mercy for them.

> is why we have LLVM replacing gcc, they literally stopped xcode on the last
> GPLv2 releases (gcc 4.2.1 and binutils 2.17) for over five years while
> they sponsored work on a replacement.

For xcode vs gcc, I dont really see any actual license _conflict_.
This was an political action, and we should take it as that.
Apple is against freedom. The least thing, we - the people - should
do is not helping them, not giving them a single penny.

> When samba went gplv3, they did
> http://www.osnews.com/story/24572/Apple_Ditches_SAMBA_in_Favour_of_Homegrown_Replacement
> for samba and so on.

Fine. They should do so. We don't need them. We lived happily without
them, and we'll continue to do so. SMB is just old legacy anyways,
just for interfacing with Toy-OS. (actually, I haven't had any single
Windows system for about 20 years - never missed that).

> The pro-gpl guys have tried various coercion tactics to get their way,
> which hasn't helped. The FSF sued CISCO in 2008 over the same 2003
> vendor BSP that had already been beaten out of them to produce OpenWRT
> (and remember when I said you don't sue the upstream you sue the
> individual customers when maximizing your payout?

No, you sue them for the biggest policitical impact.
Yes: it is very much about politics.

 > The BSP was from Broadcom, so the FSF sued Cisco).

CISCO distributed the devices, that's why the primary infringenment
was done by them. Of course, Boardcom should have been sued, too.

> Lesson: "These guys will never be satisifed,

No. They (more precisely: we) will be satisfied, as long as you place
by the rules. And the rules are pretty clear - just read the text.
And if you don't like these rules, just pick something else.

> The FSF also retroactively deleted binutils 2.17 (the last GPLv2
> version) off their ftp site and replaced it with a binutils 2.17a
> containing GPLv3 code, which they symlinked from the old name. (No
> really. They did the same thing with gdb 6.6 except there they didn't
> put a symlink, http://ftp.gnu.org/gnu/gdb/ .

Okay, that's a bad trick. Or just a bit stupidity.
Do we have evidence that this really was on purpose ?

> Remember how I said qemu
> wanted machine definitions they could get from _which_ two packages?

Well, they still can use the old ones. And if they patch anything there,
they're free to decide whether to dual-license or not.

> QEMU went GPLv2 only to stay compatible with the kernel.)

I haven't had a deeper look into QEMU source, but I wonder at which
places exactly it would make sense to share / transfer code from
kernel to QEMU. Any example ?

 > and don't forget what the FSF did to Mepis
> http://archive09.linux.com/articles/55285 (sued them for not mirroring
> UNMODIFIED source tarballs readily available on the upstream website).

They just were asked to comply to their part of the deal.
And as they do now, no reason for whining about it anymore.

> The kernel is grandfathered in, in part because it's always tolerated (if
 > not enjoyed) binary modules,

Actually, I strongly believe, they shouldn't be tolerated at all.

> but do you really think that if Android  decided
 > "time to switch to BSD" it would take them longer than 18 months to
 > port everything they care about? They re-port every kernel release...

Maybe. Just let them do it if they wish. I don't really care.

> I gave a talk about this at Ohio LinuxFest in 2013:
>
> outline: http://landley.net/talks/ohio-2013.txt
> audio: https://archive.org/download/OhioLinuxfest2013/24-Rob_Landley-The_Rise_and_Fall_of_Copyleft.mp3

You should learn the difference between opensource and free software.
  --> free like freedom, not free beer.

>> Important Notice: This message may contain confidential or privileged
>> information. It is intended only for the person it was addressed to. If you
>> are not the intended recipient of this email you may not copy, forward,
>> disclose or otherwise use it or any part of it in any form whatsoever. If
>> you received this email in error please notify the sender by replying and
>> delete this message and any attachments without retaining a copy.
>
> P.S. some of us actually care about licenses being appropriate to what
> they're applied to, and at least theoretically capable of being
> honored. Your email footer may be very slightly undermining your
> position here.

This is just a dumb auto-generated footer, coming from my client's
mail server over here ... I'm just too lazy for setting up an own
MTA on my workstation. You can safely ignore that.

--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur f?r einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschlie?lich f?r denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, d?rfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrt?mlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte l?schen Sie in diesem Fall diese Nachricht und alle Anh?nge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.

Re: Device Tree Blob (DTB) licence

[Enrico Weigelt, metux IT consult]

Am 29.05.2015 um 05:31 schrieb Rob Landley:

 >> What's the big deal with having DTS/DTB under GPL ?
>
> One problem is that there's no such thing as "The GPL" anymore.

There are different versions. The kernel source clearly states
GPLv2 (I, personally, would prefer v3 to prevent Tivoization)

> The Linux kernel and Samba can't share code anymore,

Do they really need to ?
One could ask, whether smb support should belong into the kernel
at all (instead of, eg., going via FUSE or 9P), but that's an
entirely different discussion.

> even though they implement two ends of the same protocol, thanks to GPLv3.

Samba folks made the decision to prevent Tivoization of their code.
I fully agree with that decision, and I wish the same for the kernel.

> This seems to have badly damaged the long term viability of GPLv2,
> which used to be synonymous with copyleft (category killer license)
> and acted as a universal receiver because it was a terminal node in a
> directed graph of license convertibility reducing most licensing
> decisions to a simple binary "is it GPL compatible or not", which
> greatly appealed to developers who aren't lawyers and don't want to
> be.

Well, such things happen, if people have different views. In that case
those who want to prevent Tivoization on the one and those who wanna
allow it on the other side.

I rerely have the need to really copy-and-paste code from one project
to another. When patching existing ones, I just stick to the upstream's
license. And when starting new FOSS projects, I clearly choose (L)GPLv3,
because I'm strictly against Tivoization.

> But now a project that's "GPLv2 or later" can't accept code from
> _either_ the kernel or samba (neither provides the implicit dual
> license they need).

Well, that's a decision of the individual projects - everybody has
to live with his/her own decisions.

> Projects like QEMU are stuck between wanting to
> turn kernel drivers inside out to make device emulations (GPLv2 code)
> and grab processor definitions from gcc or binutils (GPLv3 code) and
> one project cannot accept both because GPL + GPL is a license
> conflict.

Seems to be a rare case to me. In general, I'd suggest making things
used by several distinct projects into their own distinct entities.

Note: the GPL's viral effect doesn't depend on whether the sources
are collected in one big repo, but on what is compiled-/linked-into
where.

> Of course "BSD-like" would be public domain except for 20 years of
> FUD, so they're mostly choosing one of the dozens of public domain
> equivalent licenses like the various BSDs and MIT and ISC and Apache
> that are equivalent except for "copy this license text exactly"
> clauses that cause endless license bloat over time.

It's not entirely FUD. The questions is NOT whether the original open
code will be wiped out of the net or people simply dont work on it
anymore. The main question here is, whether foss developers (often
working for free) want to help people producing non-free stuff. BSD
like to allow that, FSF folks dont. They just have different views on
that matter. IMHO, BSD folks are just interested in getting back
contributions, while FSF folks also have a broader political agenda. I,
personally, share that agenda (even more: I strongly believe that
software patents should be eradicated).

> Personally I prefer public domain equivalent licenses like CC0 or
> unlicense.org or my own "zero clause bsd", which DON'T require you to
> copy specific license text verbatim into derived works.

Well, I have an fundamentally different oppinion on that. If I publish
my code for free, I dont want assist anybody in producing non-free
stuff. (free like freedom, not free beer)

> Most of this can be laid at the door of GPLv3.

Because many folks don't wanna fight against Tivoization.
I'll have to accept that, but I don't need to coorporate.

 > Android's "no gpl in userspace" policy is why they ripped out bluez
 > and wrote a replacement bluedroid from scratch.

The really interesting question is: why do they have that policy ?
Maybe because they aren't interested in *free* (as freedom) software,
but just open source.

Otherwise they'd have an strict policy of nothing proprietary in
kernel space.

> The bluez developers keep going "if we just
> improve the code enough people will get over the license" (no really:
> https://lwn.net/Articles/597293/) but their FAQ literally doesn't
> specify _which_ GPL they're under: http://www.bluez.org/faq/common/
> (Is it the one you can't use with kernel code, the one you can't
> combine with samba code, or the or-later version that can't accept
> code from either source into its next release?

Why would one want to mix bluez code with the kernel or samba ?

> Apple's great GPL purge
> (http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/)

Apple belongs to the really bad guys, what Microsoft previously was.
This is the StaSi. I have no mercy for them.

> is why we have LLVM replacing gcc, they literally stopped xcode on the last
> GPLv2 releases (gcc 4.2.1 and binutils 2.17) for over five years while
> they sponsored work on a replacement.

For xcode vs gcc, I dont really see any actual license _conflict_.
This was an political action, and we should take it as that.
Apple is against freedom. The least thing, we - the people - should
do is not helping them, not giving them a single penny.

> When samba went gplv3, they did
> http://www.osnews.com/story/24572/Apple_Ditches_SAMBA_in_Favour_of_Homegrown_Replacement
> for samba and so on.

Fine. They should do so. We don't need them. We lived happily without
them, and we'll continue to do so. SMB is just old legacy anyways,
just for interfacing with Toy-OS. (actually, I haven't had any single
Windows system for about 20 years - never missed that).

> The pro-gpl guys have tried various coercion tactics to get their way,
> which hasn't helped. The FSF sued CISCO in 2008 over the same 2003
> vendor BSP that had already been beaten out of them to produce OpenWRT
> (and remember when I said you don't sue the upstream you sue the
> individual customers when maximizing your payout?

No, you sue them for the biggest policitical impact.
Yes: it is very much about politics.

 > The BSP was from Broadcom, so the FSF sued Cisco).

CISCO distributed the devices, that's why the primary infringenment
was done by them. Of course, Boardcom should have been sued, too.

> Lesson: "These guys will never be satisifed,

No. They (more precisely: we) will be satisfied, as long as you place
by the rules. And the rules are pretty clear - just read the text.
And if you don't like these rules, just pick something else.

> The FSF also retroactively deleted binutils 2.17 (the last GPLv2
> version) off their ftp site and replaced it with a binutils 2.17a
> containing GPLv3 code, which they symlinked from the old name. (No
> really. They did the same thing with gdb 6.6 except there they didn't
> put a symlink, http://ftp.gnu.org/gnu/gdb/ .

Okay, that's a bad trick. Or just a bit stupidity.
Do we have evidence that this really was on purpose ?

> Remember how I said qemu
> wanted machine definitions they could get from _which_ two packages?

Well, they still can use the old ones. And if they patch anything there,
they're free to decide whether to dual-license or not.

> QEMU went GPLv2 only to stay compatible with the kernel.)

I haven't had a deeper look into QEMU source, but I wonder at which
places exactly it would make sense to share / transfer code from
kernel to QEMU. Any example ?

 > and don't forget what the FSF did to Mepis
> http://archive09.linux.com/articles/55285 (sued them for not mirroring
> UNMODIFIED source tarballs readily available on the upstream website).

They just were asked to comply to their part of the deal.
And as they do now, no reason for whining about it anymore.

> The kernel is grandfathered in, in part because it's always tolerated (if
 > not enjoyed) binary modules,

Actually, I strongly believe, they shouldn't be tolerated at all.

> but do you really think that if Android  decided
 > "time to switch to BSD" it would take them longer than 18 months to
 > port everything they care about? They re-port every kernel release...

Maybe. Just let them do it if they wish. I don't really care.

> I gave a talk about this at Ohio LinuxFest in 2013:
>
> outline: http://landley.net/talks/ohio-2013.txt
> audio: https://archive.org/download/OhioLinuxfest2013/24-Rob_Landley-The_Rise_and_Fall_of_Copyleft.mp3

You should learn the difference between opensource and free software.
  --> free like freedom, not free beer.

>> Important Notice: This message may contain confidential or privileged
>> information. It is intended only for the person it was addressed to. If you
>> are not the intended recipient of this email you may not copy, forward,
>> disclose or otherwise use it or any part of it in any form whatsoever. If
>> you received this email in error please notify the sender by replying and
>> delete this message and any attachments without retaining a copy.
>
> P.S. some of us actually care about licenses being appropriate to what
> they're applied to, and at least theoretically capable of being
> honored. Your email footer may be very slightly undermining your
> position here.

This is just a dumb auto-generated footer, coming from my client's
mail server over here ... I'm just too lazy for setting up an own
MTA on my workstation. You can safely ignore that.

--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B

Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten.
Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Device Tree Blob (DTB) licence

[David Lang]

On Fri, 29 May 2015, Enrico Weigelt, metux IT consult wrote:

>>> Important Notice: This message may contain confidential or privileged 
>>> information. It is intended only for the person it was addressed to. If you 
>>> are not the intended recipient of this email you may not copy, forward, 
>>> disclose or otherwise use it or any part of it in any form whatsoever. If 
>>> you received this email in error please notify the sender by replying and 
>>> delete this message and any attachments without retaining a copy.
>> 
>> P.S. some of us actually care about licenses being appropriate to what
>> they're applied to, and at least theoretically capable of being
>> honored. Your email footer may be very slightly undermining your
>> position here.
>
> This is just a dumb auto-generated footer, coming from my client's
> mail server over here ... I'm just too lazy for setting up an own
> MTA on my workstation. You can safely ignore that.

Arguing license issues and at the same time claiming that you should ignore a 
legal statement like the footer is a bit odd.

David Lang

Device Tree Blob (DTB) licence

[David Lang]

On Fri, 29 May 2015, Enrico Weigelt, metux IT consult wrote:

>>> Important Notice: This message may contain confidential or privileged 
>>> information. It is intended only for the person it was addressed to. If you 
>>> are not the intended recipient of this email you may not copy, forward, 
>>> disclose or otherwise use it or any part of it in any form whatsoever. If 
>>> you received this email in error please notify the sender by replying and 
>>> delete this message and any attachments without retaining a copy.
>> 
>> P.S. some of us actually care about licenses being appropriate to what
>> they're applied to, and at least theoretically capable of being
>> honored. Your email footer may be very slightly undermining your
>> position here.
>
> This is just a dumb auto-generated footer, coming from my client's
> mail server over here ... I'm just too lazy for setting up an own
> MTA on my workstation. You can safely ignore that.

Arguing license issues and at the same time claiming that you should ignore a 
legal statement like the footer is a bit odd.

David Lang

Re: Device Tree Blob (DTB) licence

[David Lang]

On Fri, 29 May 2015, Enrico Weigelt, metux IT consult wrote:

>>> Important Notice: This message may contain confidential or privileged 
>>> information. It is intended only for the person it was addressed to. If you 
>>> are not the intended recipient of this email you may not copy, forward, 
>>> disclose or otherwise use it or any part of it in any form whatsoever. If 
>>> you received this email in error please notify the sender by replying and 
>>> delete this message and any attachments without retaining a copy.
>> 
>> P.S. some of us actually care about licenses being appropriate to what
>> they're applied to, and at least theoretically capable of being
>> honored. Your email footer may be very slightly undermining your
>> position here.
>
> This is just a dumb auto-generated footer, coming from my client's
> mail server over here ... I'm just too lazy for setting up an own
> MTA on my workstation. You can safely ignore that.

Arguing license issues and at the same time claiming that you should ignore a 
legal statement like the footer is a bit odd.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Device Tree Blob (DTB) licence

[Jean-Christophe PLAGNIOL-VILLARD]

> On May 29, 2015, at 11:10 PM, Enrico Weigelt, metux IT consult <weigelt@melag.de> wrote:
> 
> Am 29.05.2015 um 05:31 schrieb Rob Landley:
> 
> >> What's the big deal with having DTS/DTB under GPL ?
>> 
>> One problem is that there's no such thing as "The GPL" anymore.
> 
> There are different versions. The kernel source clearly states
> GPLv2 (I, personally, would prefer v3 to prevent Tivoization)
> 
>> The Linux kernel and Samba can't share code anymore,
> 
> Do they really need to ?
> One could ask, whether smb support should belong into the kernel
> at all (instead of, eg., going via FUSE or 9P), but that's an
> entirely different discussion.
> 
>> even though they implement two ends of the same protocol, thanks to GPLv3.
> 
> Samba folks made the decision to prevent Tivoization of their code.
> I fully agree with that decision, and I wish the same for the kernel.
and other think the GPLv3 is a mistake and is not commercially usable

It’s call freedom.
> 
>> This seems to have badly damaged the long term viability of GPLv2,
>> which used to be synonymous with copyleft (category killer license)
>> and acted as a universal receiver because it was a terminal node in a
>> directed graph of license convertibility reducing most licensing
>> decisions to a simple binary "is it GPL compatible or not", which
>> greatly appealed to developers who aren't lawyers and don't want to
>> be.
> 
> Well, such things happen, if people have different views. In that case
> those who want to prevent Tivoization on the one and those who wanna
> allow it on the other side.
> 
> I rerely have the need to really copy-and-paste code from one project
> to another. When patching existing ones, I just stick to the upstream's
> license. And when starting new FOSS projects, I clearly choose (L)GPLv3,
> because I'm strictly against Tivoization.
> 

This is your choice, this remove freedom too GPLv3.

>> But now a project that's "GPLv2 or later" can't accept code from
>> _either_ the kernel or samba (neither provides the implicit dual
>> license they need).
> 
> Well, that's a decision of the individual projects - everybody has
> to live with his/her own decisions.
> 
>> Projects like QEMU are stuck between wanting to
>> turn kernel drivers inside out to make device emulations (GPLv2 code)
>> and grab processor definitions from gcc or binutils (GPLv3 code) and
>> one project cannot accept both because GPL + GPL is a license
>> conflict.
> 
> Seems to be a rare case to me. In general, I'd suggest making things
> used by several distinct projects into their own distinct entities.
> 
> Note: the GPL's viral effect doesn't depend on whether the sources
> are collected in one big repo, but on what is compiled-/linked-into
> where.
> 
>> Of course "BSD-like" would be public domain except for 20 years of
>> FUD, so they're mostly choosing one of the dozens of public domain
>> equivalent licenses like the various BSDs and MIT and ISC and Apache
>> that are equivalent except for "copy this license text exactly"
>> clauses that cause endless license bloat over time.
> 
> It's not entirely FUD. The questions is NOT whether the original open
> code will be wiped out of the net or people simply dont work on it
> anymore. The main question here is, whether foss developers (often
> working for free) want to help people producing non-free stuff. BSD
> like to allow that, FSF folks dont. They just have different views on
> that matter. IMHO, BSD folks are just interested in getting back
> contributions, while FSF folks also have a broader political agenda. I,
> personally, share that agenda (even more: I strongly believe that
> software patents should be eradicated).
> 
>> Personally I prefer public domain equivalent licenses like CC0 or
>> unlicense.org or my own "zero clause bsd", which DON'T require you to
>> copy specific license text verbatim into derived works.
> 
> Well, I have an fundamentally different oppinion on that. If I publish
> my code for free, I dont want assist anybody in producing non-free
> stuff. (free like freedom, not free beer)
> 
>> Most of this can be laid at the door of GPLv3.
> 
> Because many folks don't wanna fight against Tivoization.
> I'll have to accept that, but I don't need to coorporate.
> 
> > Android's "no gpl in userspace" policy is why they ripped out bluez
> > and wrote a replacement bluedroid from scratch.
> 
> The really interesting question is: why do they have that policy ?
> Maybe because they aren't interested in *free* (as freedom) software,
> but just open source.
> 
> Otherwise they'd have an strict policy of nothing proprietary in
> kernel space.
> 
>> The bluez developers keep going "if we just
>> improve the code enough people will get over the license" (no really:
>> https://lwn.net/Articles/597293/) but their FAQ literally doesn't
>> specify _which_ GPL they're under: http://www.bluez.org/faq/common/
>> (Is it the one you can't use with kernel code, the one you can't
>> combine with samba code, or the or-later version that can't accept
>> code from either source into its next release?
> 
> Why would one want to mix bluez code with the kernel or samba ?
> 
>> Apple's great GPL purge
>> (http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/)
> 
> Apple belongs to the really bad guys, what Microsoft previously was.
> This is the StaSi. I have no mercy for them.
> 
>> is why we have LLVM replacing gcc, they literally stopped xcode on the last
>> GPLv2 releases (gcc 4.2.1 and binutils 2.17) for over five years while
>> they sponsored work on a replacement.
> 
> For xcode vs gcc, I dont really see any actual license _conflict_.
> This was an political action, and we should take it as that.
> Apple is against freedom. The least thing, we - the people - should
> do is not helping them, not giving them a single penny.

This kind of comment is not appropriate here, please keep it to your self next time.
> 
>> When samba went gplv3, they did
>> http://www.osnews.com/story/24572/Apple_Ditches_SAMBA_in_Favour_of_Homegrown_Replacement
>> for samba and so on.

…

> --> free like freedom, not free beer.
> 
>>> Important Notice: This message may contain confidential or privileged
>>> information. It is intended only for the person it was addressed to. If you
>>> are not the intended recipient of this email you may not copy, forward,
>>> disclose or otherwise use it or any part of it in any form whatsoever. If
>>> you received this email in error please notify the sender by replying and
>>> delete this message and any attachments without retaining a copy.
>> 
>> P.S. some of us actually care about licenses being appropriate to what
>> they're applied to, and at least theoretically capable of being
>> honored. Your email footer may be very slightly undermining your
>> position here.
> 
> This is just a dumb auto-generated footer, coming from my client's
> mail server over here ... I'm just too lazy for setting up an own
> MTA on my workstation. You can safely ignore that.
> 
> --
> Enrico Weigelt, metux IT consult
> +49-151-27565287
> MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B
> 
> Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten.
> Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.

Drop this for now on this is a public mailing list every one can receive the e-mail.

If you are too lazy to remove do not post on the ML

Best Regards,
J.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Device Tree Blob (DTB) licence

[Jean-Christophe PLAGNIOL-VILLARD]

> On May 29, 2015, at 11:10 PM, Enrico Weigelt, metux IT consult <weigelt@melag.de> wrote:
> 
> Am 29.05.2015 um 05:31 schrieb Rob Landley:
> 
> >> What's the big deal with having DTS/DTB under GPL ?
>> 
>> One problem is that there's no such thing as "The GPL" anymore.
> 
> There are different versions. The kernel source clearly states
> GPLv2 (I, personally, would prefer v3 to prevent Tivoization)
> 
>> The Linux kernel and Samba can't share code anymore,
> 
> Do they really need to ?
> One could ask, whether smb support should belong into the kernel
> at all (instead of, eg., going via FUSE or 9P), but that's an
> entirely different discussion.
> 
>> even though they implement two ends of the same protocol, thanks to GPLv3.
> 
> Samba folks made the decision to prevent Tivoization of their code.
> I fully agree with that decision, and I wish the same for the kernel.
and other think the GPLv3 is a mistake and is not commercially usable

It?s call freedom.
> 
>> This seems to have badly damaged the long term viability of GPLv2,
>> which used to be synonymous with copyleft (category killer license)
>> and acted as a universal receiver because it was a terminal node in a
>> directed graph of license convertibility reducing most licensing
>> decisions to a simple binary "is it GPL compatible or not", which
>> greatly appealed to developers who aren't lawyers and don't want to
>> be.
> 
> Well, such things happen, if people have different views. In that case
> those who want to prevent Tivoization on the one and those who wanna
> allow it on the other side.
> 
> I rerely have the need to really copy-and-paste code from one project
> to another. When patching existing ones, I just stick to the upstream's
> license. And when starting new FOSS projects, I clearly choose (L)GPLv3,
> because I'm strictly against Tivoization.
> 

This is your choice, this remove freedom too GPLv3.

>> But now a project that's "GPLv2 or later" can't accept code from
>> _either_ the kernel or samba (neither provides the implicit dual
>> license they need).
> 
> Well, that's a decision of the individual projects - everybody has
> to live with his/her own decisions.
> 
>> Projects like QEMU are stuck between wanting to
>> turn kernel drivers inside out to make device emulations (GPLv2 code)
>> and grab processor definitions from gcc or binutils (GPLv3 code) and
>> one project cannot accept both because GPL + GPL is a license
>> conflict.
> 
> Seems to be a rare case to me. In general, I'd suggest making things
> used by several distinct projects into their own distinct entities.
> 
> Note: the GPL's viral effect doesn't depend on whether the sources
> are collected in one big repo, but on what is compiled-/linked-into
> where.
> 
>> Of course "BSD-like" would be public domain except for 20 years of
>> FUD, so they're mostly choosing one of the dozens of public domain
>> equivalent licenses like the various BSDs and MIT and ISC and Apache
>> that are equivalent except for "copy this license text exactly"
>> clauses that cause endless license bloat over time.
> 
> It's not entirely FUD. The questions is NOT whether the original open
> code will be wiped out of the net or people simply dont work on it
> anymore. The main question here is, whether foss developers (often
> working for free) want to help people producing non-free stuff. BSD
> like to allow that, FSF folks dont. They just have different views on
> that matter. IMHO, BSD folks are just interested in getting back
> contributions, while FSF folks also have a broader political agenda. I,
> personally, share that agenda (even more: I strongly believe that
> software patents should be eradicated).
> 
>> Personally I prefer public domain equivalent licenses like CC0 or
>> unlicense.org or my own "zero clause bsd", which DON'T require you to
>> copy specific license text verbatim into derived works.
> 
> Well, I have an fundamentally different oppinion on that. If I publish
> my code for free, I dont want assist anybody in producing non-free
> stuff. (free like freedom, not free beer)
> 
>> Most of this can be laid at the door of GPLv3.
> 
> Because many folks don't wanna fight against Tivoization.
> I'll have to accept that, but I don't need to coorporate.
> 
> > Android's "no gpl in userspace" policy is why they ripped out bluez
> > and wrote a replacement bluedroid from scratch.
> 
> The really interesting question is: why do they have that policy ?
> Maybe because they aren't interested in *free* (as freedom) software,
> but just open source.
> 
> Otherwise they'd have an strict policy of nothing proprietary in
> kernel space.
> 
>> The bluez developers keep going "if we just
>> improve the code enough people will get over the license" (no really:
>> https://lwn.net/Articles/597293/) but their FAQ literally doesn't
>> specify _which_ GPL they're under: http://www.bluez.org/faq/common/
>> (Is it the one you can't use with kernel code, the one you can't
>> combine with samba code, or the or-later version that can't accept
>> code from either source into its next release?
> 
> Why would one want to mix bluez code with the kernel or samba ?
> 
>> Apple's great GPL purge
>> (http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/)
> 
> Apple belongs to the really bad guys, what Microsoft previously was.
> This is the StaSi. I have no mercy for them.
> 
>> is why we have LLVM replacing gcc, they literally stopped xcode on the last
>> GPLv2 releases (gcc 4.2.1 and binutils 2.17) for over five years while
>> they sponsored work on a replacement.
> 
> For xcode vs gcc, I dont really see any actual license _conflict_.
> This was an political action, and we should take it as that.
> Apple is against freedom. The least thing, we - the people - should
> do is not helping them, not giving them a single penny.

This kind of comment is not appropriate here, please keep it to your self next time.
> 
>> When samba went gplv3, they did
>> http://www.osnews.com/story/24572/Apple_Ditches_SAMBA_in_Favour_of_Homegrown_Replacement
>> for samba and so on.

?

> --> free like freedom, not free beer.
> 
>>> Important Notice: This message may contain confidential or privileged
>>> information. It is intended only for the person it was addressed to. If you
>>> are not the intended recipient of this email you may not copy, forward,
>>> disclose or otherwise use it or any part of it in any form whatsoever. If
>>> you received this email in error please notify the sender by replying and
>>> delete this message and any attachments without retaining a copy.
>> 
>> P.S. some of us actually care about licenses being appropriate to what
>> they're applied to, and at least theoretically capable of being
>> honored. Your email footer may be very slightly undermining your
>> position here.
> 
> This is just a dumb auto-generated footer, coming from my client's
> mail server over here ... I'm just too lazy for setting up an own
> MTA on my workstation. You can safely ignore that.
> 
> --
> Enrico Weigelt, metux IT consult
> +49-151-27565287
> MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B
> 
> Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur f?r einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschlie?lich f?r denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, d?rfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrt?mlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte l?schen Sie in diesem Fall diese Nachricht und alle Anh?nge, ohne eine Kopie zu behalten.
> Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.

Drop this for now on this is a public mailing list every one can receive the e-mail.

If you are too lazy to remove do not post on the ML

Best Regards,
J.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Device Tree Blob (DTB) licence

[Jean-Christophe PLAGNIOL-VILLARD]

> On May 29, 2015, at 11:10 PM, Enrico Weigelt, metux IT consult <weigelt@melag.de> wrote:
> 
> Am 29.05.2015 um 05:31 schrieb Rob Landley:
> 
> >> What's the big deal with having DTS/DTB under GPL ?
>> 
>> One problem is that there's no such thing as "The GPL" anymore.
> 
> There are different versions. The kernel source clearly states
> GPLv2 (I, personally, would prefer v3 to prevent Tivoization)
> 
>> The Linux kernel and Samba can't share code anymore,
> 
> Do they really need to ?
> One could ask, whether smb support should belong into the kernel
> at all (instead of, eg., going via FUSE or 9P), but that's an
> entirely different discussion.
> 
>> even though they implement two ends of the same protocol, thanks to GPLv3.
> 
> Samba folks made the decision to prevent Tivoization of their code.
> I fully agree with that decision, and I wish the same for the kernel.
and other think the GPLv3 is a mistake and is not commercially usable

It’s call freedom.
> 
>> This seems to have badly damaged the long term viability of GPLv2,
>> which used to be synonymous with copyleft (category killer license)
>> and acted as a universal receiver because it was a terminal node in a
>> directed graph of license convertibility reducing most licensing
>> decisions to a simple binary "is it GPL compatible or not", which
>> greatly appealed to developers who aren't lawyers and don't want to
>> be.
> 
> Well, such things happen, if people have different views. In that case
> those who want to prevent Tivoization on the one and those who wanna
> allow it on the other side.
> 
> I rerely have the need to really copy-and-paste code from one project
> to another. When patching existing ones, I just stick to the upstream's
> license. And when starting new FOSS projects, I clearly choose (L)GPLv3,
> because I'm strictly against Tivoization.
> 

This is your choice, this remove freedom too GPLv3.

>> But now a project that's "GPLv2 or later" can't accept code from
>> _either_ the kernel or samba (neither provides the implicit dual
>> license they need).
> 
> Well, that's a decision of the individual projects - everybody has
> to live with his/her own decisions.
> 
>> Projects like QEMU are stuck between wanting to
>> turn kernel drivers inside out to make device emulations (GPLv2 code)
>> and grab processor definitions from gcc or binutils (GPLv3 code) and
>> one project cannot accept both because GPL + GPL is a license
>> conflict.
> 
> Seems to be a rare case to me. In general, I'd suggest making things
> used by several distinct projects into their own distinct entities.
> 
> Note: the GPL's viral effect doesn't depend on whether the sources
> are collected in one big repo, but on what is compiled-/linked-into
> where.
> 
>> Of course "BSD-like" would be public domain except for 20 years of
>> FUD, so they're mostly choosing one of the dozens of public domain
>> equivalent licenses like the various BSDs and MIT and ISC and Apache
>> that are equivalent except for "copy this license text exactly"
>> clauses that cause endless license bloat over time.
> 
> It's not entirely FUD. The questions is NOT whether the original open
> code will be wiped out of the net or people simply dont work on it
> anymore. The main question here is, whether foss developers (often
> working for free) want to help people producing non-free stuff. BSD
> like to allow that, FSF folks dont. They just have different views on
> that matter. IMHO, BSD folks are just interested in getting back
> contributions, while FSF folks also have a broader political agenda. I,
> personally, share that agenda (even more: I strongly believe that
> software patents should be eradicated).
> 
>> Personally I prefer public domain equivalent licenses like CC0 or
>> unlicense.org or my own "zero clause bsd", which DON'T require you to
>> copy specific license text verbatim into derived works.
> 
> Well, I have an fundamentally different oppinion on that. If I publish
> my code for free, I dont want assist anybody in producing non-free
> stuff. (free like freedom, not free beer)
> 
>> Most of this can be laid at the door of GPLv3.
> 
> Because many folks don't wanna fight against Tivoization.
> I'll have to accept that, but I don't need to coorporate.
> 
> > Android's "no gpl in userspace" policy is why they ripped out bluez
> > and wrote a replacement bluedroid from scratch.
> 
> The really interesting question is: why do they have that policy ?
> Maybe because they aren't interested in *free* (as freedom) software,
> but just open source.
> 
> Otherwise they'd have an strict policy of nothing proprietary in
> kernel space.
> 
>> The bluez developers keep going "if we just
>> improve the code enough people will get over the license" (no really:
>> https://lwn.net/Articles/597293/) but their FAQ literally doesn't
>> specify _which_ GPL they're under: http://www.bluez.org/faq/common/
>> (Is it the one you can't use with kernel code, the one you can't
>> combine with samba code, or the or-later version that can't accept
>> code from either source into its next release?
> 
> Why would one want to mix bluez code with the kernel or samba ?
> 
>> Apple's great GPL purge
>> (http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/)
> 
> Apple belongs to the really bad guys, what Microsoft previously was.
> This is the StaSi. I have no mercy for them.
> 
>> is why we have LLVM replacing gcc, they literally stopped xcode on the last
>> GPLv2 releases (gcc 4.2.1 and binutils 2.17) for over five years while
>> they sponsored work on a replacement.
> 
> For xcode vs gcc, I dont really see any actual license _conflict_.
> This was an political action, and we should take it as that.
> Apple is against freedom. The least thing, we - the people - should
> do is not helping them, not giving them a single penny.

This kind of comment is not appropriate here, please keep it to your self next time.
> 
>> When samba went gplv3, they did
>> http://www.osnews.com/story/24572/Apple_Ditches_SAMBA_in_Favour_of_Homegrown_Replacement
>> for samba and so on.

…

> --> free like freedom, not free beer.
> 
>>> Important Notice: This message may contain confidential or privileged
>>> information. It is intended only for the person it was addressed to. If you
>>> are not the intended recipient of this email you may not copy, forward,
>>> disclose or otherwise use it or any part of it in any form whatsoever. If
>>> you received this email in error please notify the sender by replying and
>>> delete this message and any attachments without retaining a copy.
>> 
>> P.S. some of us actually care about licenses being appropriate to what
>> they're applied to, and at least theoretically capable of being
>> honored. Your email footer may be very slightly undermining your
>> position here.
> 
> This is just a dumb auto-generated footer, coming from my client's
> mail server over here ... I'm just too lazy for setting up an own
> MTA on my workstation. You can safely ignore that.
> 
> --
> Enrico Weigelt, metux IT consult
> +49-151-27565287
> MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B
> 
> Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten.
> Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy.

Drop this for now on this is a public mailing list every one can receive the e-mail.

If you are too lazy to remove do not post on the ML

Best Regards,
J.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Device Tree Blob (DTB) licence

[Pavel Machek]

On Mon 2015-05-25 02:14:28, Rob Landley wrote:
> On Fri, May 22, 2015 at 2:27 PM, Yann Droneaud <ydroneaud@opteya.com> wrote:
> > I've added licensing@fsf.ogrg in Cc: in my previous message to have an
> > advice on this subject, but I failed to notice licensing@fsf.org
> > is not a mailing list: I was assigned request ID [gnu.org #1017262].
> >
> > Regards.
> 
> They're also not an unbiased source. Their job is to reply "you should
> license it under GPLv3" without actually looking at your message.
> (This is a slight oversimplification, they may instead recomend the
> GFDL. They will never _not_ recommend one of their licenses.)

Actually, I got FSF to change license on piece of code from GPLv2 to LGPLv2
before. They are not completely evil :-).

> Personally, I'm sad we're starting to get ACPI for arm but if device
> tree data files are only available under GPL, people will hold their
> nose and deploy ACPI.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/

Device Tree Blob (DTB) licence

[Pavel Machek]

On Mon 2015-05-25 02:14:28, Rob Landley wrote:
> On Fri, May 22, 2015 at 2:27 PM, Yann Droneaud <ydroneaud@opteya.com> wrote:
> > I've added licensing at fsf.ogrg in Cc: in my previous message to have an
> > advice on this subject, but I failed to notice licensing at fsf.org
> > is not a mailing list: I was assigned request ID [gnu.org #1017262].
> >
> > Regards.
> 
> They're also not an unbiased source. Their job is to reply "you should
> license it under GPLv3" without actually looking at your message.
> (This is a slight oversimplification, they may instead recomend the
> GFDL. They will never _not_ recommend one of their licenses.)

Actually, I got FSF to change license on piece of code from GPLv2 to LGPLv2
before. They are not completely evil :-).

> Personally, I'm sad we're starting to get ACPI for arm but if device
> tree data files are only available under GPL, people will hold their
> nose and deploy ACPI.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Device Tree Blob (DTB) licence

[Pavel Machek]

On Mon 2015-05-25 02:14:28, Rob Landley wrote:
> On Fri, May 22, 2015 at 2:27 PM, Yann Droneaud <ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org> wrote:
> > I've added licensing-VjfpZJbb0kk@public.gmane.org in Cc: in my previous message to have an
> > advice on this subject, but I failed to notice licensing-dGWS0fDw8IM@public.gmane.org
> > is not a mailing list: I was assigned request ID [gnu.org #1017262].
> >
> > Regards.
> 
> They're also not an unbiased source. Their job is to reply "you should
> license it under GPLv3" without actually looking at your message.
> (This is a slight oversimplification, they may instead recomend the
> GFDL. They will never _not_ recommend one of their licenses.)

Actually, I got FSF to change license on piece of code from GPLv2 to LGPLv2
before. They are not completely evil :-).

> Personally, I'm sad we're starting to get ACPI for arm but if device
> tree data files are only available under GPL, people will hold their
> nose and deploy ACPI.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in

Re: Device Tree Blob (DTB) licence

[Jeroen Hofstee]

Hi,

On 22-05-15 12:05, Yann Droneaud wrote:
> Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit :
>> On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com>
>> wrote:
>>> I believe Device Tree Blob (.dtb file) built from kernel's Device
>>> Tree
>>> Sources (.dts, which #include .dtsi, which #include .h) using
>>> Device
>>> Tree Compiler (dtc) are covered by GNU General Public Licence v2
>>> (GPLv2), but cannot find any reference.
>> By default yes, but we've been steering people to dual license them
>> GPL/BSD.
>>
>

obviously these files should be reusable. If there is a license issue
with that it should be fixed. cc-ing freebsd-arm@freebsd.org.

I am not a lawyer,

Jeroen

Device Tree Blob (DTB) licence

[Jeroen Hofstee]

Hi,

On 22-05-15 12:05, Yann Droneaud wrote:
> Le mardi 05 mai 2015 ? 11:41 -0500, Rob Herring a ?crit :
>> On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com>
>> wrote:
>>> I believe Device Tree Blob (.dtb file) built from kernel's Device
>>> Tree
>>> Sources (.dts, which #include .dtsi, which #include .h) using
>>> Device
>>> Tree Compiler (dtc) are covered by GNU General Public Licence v2
>>> (GPLv2), but cannot find any reference.
>> By default yes, but we've been steering people to dual license them
>> GPL/BSD.
>>
>

obviously these files should be reusable. If there is a license issue
with that it should be fixed. cc-ing freebsd-arm at freebsd.org.

I am not a lawyer,

Jeroen

Re: Device Tree Blob (DTB) licence

[Jeroen Hofstee]

Hi,

On 22-05-15 12:05, Yann Droneaud wrote:
> Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit :
>> On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com>
>> wrote:
>>> I believe Device Tree Blob (.dtb file) built from kernel's Device
>>> Tree
>>> Sources (.dts, which #include .dtsi, which #include .h) using
>>> Device
>>> Tree Compiler (dtc) are covered by GNU General Public Licence v2
>>> (GPLv2), but cannot find any reference.
>> By default yes, but we've been steering people to dual license them
>> GPL/BSD.
>>
>

obviously these files should be reusable. If there is a license issue
with that it should be fixed. cc-ing freebsd-arm@freebsd.org.

I am not a lawyer,

Jeroen
_______________________________________________
freebsd-arm@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"

Re: Device Tree Blob (DTB) licence

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 2646 bytes --]


> On May 30, 2015, at 1:59 PM, Jeroen Hofstee <linux-arm@myspectrum.nl> wrote:
> 
> Hi,
> 
> On 22-05-15 12:05, Yann Droneaud wrote:
>> Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit :
>>> On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com>
>>> wrote:
>>>> I believe Device Tree Blob (.dtb file) built from kernel's Device
>>>> Tree
>>>> Sources (.dts, which #include .dtsi, which #include .h) using
>>>> Device
>>>> Tree Compiler (dtc) are covered by GNU General Public Licence v2
>>>> (GPLv2), but cannot find any reference.
>>> By default yes, but we've been steering people to dual license them
>>> GPL/BSD.
>>> 
>> 
> 
> obviously these files should be reusable. If there is a license issue
> with that it should be fixed. cc-ing freebsd-arm@freebsd.org.

FreeBSD segregates the files that its contributors have written and
are under BSDL from those that are received from upstream and
may be under BSDL+GPL or just GPL in its source tree.

The source is shipped, the binaries are not, at least by the FreeBSD
project. The FreeBSD project used to create its own custom dts
files that were incompatible with anything except FreeBSD. However,
apart from a few stragglers, we’ve converted all our supported platforms
to using the ‘vendor supplied’ dts files, which means we follow the
documented conventions found in Linux, as well as many of the
strange Linuxisms that seep into this or that .dts file. Following the
standard here and accepting some potentially GPLd code into the
tree given its limited scope and already segregated nature.

It is an open question to what extent the mere-aggregation clause
would apply to the typical use of placing the dtb into a filesystem
that u-boot then passes along applies. And if that same reasoning
applies to a binary bundle containing both the kernel and the dtb
file. It’s also an open question the extent to which copyright applies
to the dts files since they are, in theory at least, just an expression of
facts and there’s generally only one way to correctly express those
facts in a dts file. The GPL’d files aren’t stopping anybody from creating
proprietary software. People that really care will rewrite the files
from scratch anyway. People that don’t care.. well, one need look
no further than the difficulty of getting source code to different SoC
support packages for the kernel in the Android world to see how
much some people care about GPL compliance and how much
it really stops them from doing what they want.

Than again, I’m not a lawyer, and this isn’t legal advice.

Warner

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Device Tree Blob (DTB) licence

[Warner Losh]

> On May 30, 2015, at 1:59 PM, Jeroen Hofstee <linux-arm@myspectrum.nl> wrote:
> 
> Hi,
> 
> On 22-05-15 12:05, Yann Droneaud wrote:
>> Le mardi 05 mai 2015 ? 11:41 -0500, Rob Herring a ?crit :
>>> On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud@opteya.com>
>>> wrote:
>>>> I believe Device Tree Blob (.dtb file) built from kernel's Device
>>>> Tree
>>>> Sources (.dts, which #include .dtsi, which #include .h) using
>>>> Device
>>>> Tree Compiler (dtc) are covered by GNU General Public Licence v2
>>>> (GPLv2), but cannot find any reference.
>>> By default yes, but we've been steering people to dual license them
>>> GPL/BSD.
>>> 
>> 
> 
> obviously these files should be reusable. If there is a license issue
> with that it should be fixed. cc-ing freebsd-arm at freebsd.org.

FreeBSD segregates the files that its contributors have written and
are under BSDL from those that are received from upstream and
may be under BSDL+GPL or just GPL in its source tree.

The source is shipped, the binaries are not, at least by the FreeBSD
project. The FreeBSD project used to create its own custom dts
files that were incompatible with anything except FreeBSD. However,
apart from a few stragglers, we?ve converted all our supported platforms
to using the ?vendor supplied? dts files, which means we follow the
documented conventions found in Linux, as well as many of the
strange Linuxisms that seep into this or that .dts file. Following the
standard here and accepting some potentially GPLd code into the
tree given its limited scope and already segregated nature.

It is an open question to what extent the mere-aggregation clause
would apply to the typical use of placing the dtb into a filesystem
that u-boot then passes along applies. And if that same reasoning
applies to a binary bundle containing both the kernel and the dtb
file. It?s also an open question the extent to which copyright applies
to the dts files since they are, in theory at least, just an expression of
facts and there?s generally only one way to correctly express those
facts in a dts file. The GPL?d files aren?t stopping anybody from creating
proprietary software. People that really care will rewrite the files
from scratch anyway. People that don?t care.. well, one need look
no further than the difficulty of getting source code to different SoC
support packages for the kernel in the Android world to see how
much some people care about GPL compliance and how much
it really stops them from doing what they want.

Than again, I?m not a lawyer, and this isn?t legal advice.

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150531/1c054028/attachment-0001.sig>

Re: Device Tree Blob (DTB) licence

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 2728 bytes --]


> On May 30, 2015, at 1:59 PM, Jeroen Hofstee <linux-arm-D9wZyEIIrd305oU+jsXUgg@public.gmane.org> wrote:
> 
> Hi,
> 
> On 22-05-15 12:05, Yann Droneaud wrote:
>> Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit :
>>> On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
>>> wrote:
>>>> I believe Device Tree Blob (.dtb file) built from kernel's Device
>>>> Tree
>>>> Sources (.dts, which #include .dtsi, which #include .h) using
>>>> Device
>>>> Tree Compiler (dtc) are covered by GNU General Public Licence v2
>>>> (GPLv2), but cannot find any reference.
>>> By default yes, but we've been steering people to dual license them
>>> GPL/BSD.
>>> 
>> 
> 
> obviously these files should be reusable. If there is a license issue
> with that it should be fixed. cc-ing freebsd-arm-h+KGxgPPioqbup2nOX2J7Q@public.gmane.org

FreeBSD segregates the files that its contributors have written and
are under BSDL from those that are received from upstream and
may be under BSDL+GPL or just GPL in its source tree.

The source is shipped, the binaries are not, at least by the FreeBSD
project. The FreeBSD project used to create its own custom dts
files that were incompatible with anything except FreeBSD. However,
apart from a few stragglers, we’ve converted all our supported platforms
to using the ‘vendor supplied’ dts files, which means we follow the
documented conventions found in Linux, as well as many of the
strange Linuxisms that seep into this or that .dts file. Following the
standard here and accepting some potentially GPLd code into the
tree given its limited scope and already segregated nature.

It is an open question to what extent the mere-aggregation clause
would apply to the typical use of placing the dtb into a filesystem
that u-boot then passes along applies. And if that same reasoning
applies to a binary bundle containing both the kernel and the dtb
file. It’s also an open question the extent to which copyright applies
to the dts files since they are, in theory at least, just an expression of
facts and there’s generally only one way to correctly express those
facts in a dts file. The GPL’d files aren’t stopping anybody from creating
proprietary software. People that really care will rewrite the files
from scratch anyway. People that don’t care.. well, one need look
no further than the difficulty of getting source code to different SoC
support packages for the kernel in the Android world to see how
much some people care about GPL compliance and how much
it really stops them from doing what they want.

Than again, I’m not a lawyer, and this isn’t legal advice.

Warner

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: Device Tree Blob (DTB) licence

[One Thousand Gnomes]

> facts in a dts file. The GPL’d files aren’t stopping anybody from creating
> proprietary software. People that really care will rewrite the files
> from scratch anyway. People that don’t care.. well, one need look
> no further than the difficulty of getting source code to different SoC
> support packages for the kernel in the Android world to see how
> much some people care about GPL compliance and how much
> it really stops them from doing what they want.

And at how many large companies follow the GPL and do provide sources,
none of whom would probably have bothered otherwise....

Mostly effective is better than not trying in the first place.

Re: Device Tree Blob (DTB) licence

[One Thousand Gnomes]

> facts in a dts file. The GPL’d files aren’t stopping anybody from creating
> proprietary software. People that really care will rewrite the files
> from scratch anyway. People that don’t care.. well, one need look
> no further than the difficulty of getting source code to different SoC
> support packages for the kernel in the Android world to see how
> much some people care about GPL compliance and how much
> it really stops them from doing what they want.

And at how many large companies follow the GPL and do provide sources,
none of whom would probably have bothered otherwise....

Mostly effective is better than not trying in the first place.

_______________________________________________
freebsd-arm@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"