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
On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <[email protected]> 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
Hi,
Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit :
> On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud <[email protected]>
> 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
On Fri, May 22, 2015 at 5:05 AM, Yann Droneaud <[email protected]> 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 <[email protected]>
>> 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
Hi,
[removing Cc: [email protected]]
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 <[email protected]
> > >
> > 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 [email protected] in Cc: in my previous message to have an
advice on this subject, but I failed to notice [email protected]
is not a mailing list: I was assigned request ID [gnu.org #1017262].
Regards.
--
Yann Droneaud
OPTEYA
On Fri, May 22, 2015 at 2:27 PM, Yann Droneaud <[email protected]> wrote:
> I've added [email protected] in Cc: in my previous message to have an
> advice on this subject, but I failed to notice [email protected]
> 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
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
> 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
> 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.
> On Jun 1, 2015, at 7:12 AM, One Thousand Gnomes <[email protected]> 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
On Mon 2015-05-25 02:14:28, Rob Landley wrote:
> On Fri, May 22, 2015 at 2:27 PM, Yann Droneaud <[email protected]> wrote:
> > I've added [email protected] in Cc: in my previous message to have an
> > advice on this subject, but I failed to notice [email protected]
> > 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