Re: Device Tree Blob (DTB) licence
On Mon 2015-05-25 02:14:28, Rob Landley wrote: > On Fri, May 22, 2015 at 2:27 PM, Yann Droneaud wrote: > > I've added licens...@fsf.ogrg in Cc: in my previous message to have an > > advice on this subject, but I failed to notice licens...@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/
Re: Device Tree Blob (DTB) licence
On Mon 2015-05-25 02:14:28, Rob Landley wrote: On Fri, May 22, 2015 at 2:27 PM, Yann Droneaud ydrone...@opteya.com wrote: I've added licens...@fsf.ogrg in Cc: in my previous message to have an advice on this subject, but I failed to notice licens...@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/
Re: Device Tree Blob (DTB) licence
> On Jun 1, 2015, at 7:12 AM, One Thousand Gnomes > 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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Device Tree Blob (DTB) licence
> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
> 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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
On Jun 1, 2015, at 7:12 AM, One Thousand Gnomes gno...@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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Device Tree Blob (DTB) licence
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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
> On May 30, 2015, at 1:59 PM, Jeroen Hofstee 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 >>> 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-...@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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Device Tree Blob (DTB) licence
On May 30, 2015, at 1:59 PM, Jeroen Hofstee linux-...@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 ydrone...@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-...@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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Device Tree Blob (DTB) licence
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 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-...@freebsd.org. I am not a lawyer, Jeroen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
On Sat, May 30, 2015 at 12:16 AM, David Lang 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 -- ge...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
> On May 29, 2015, at 11:10 PM, Enrico Weigelt, metux IT consult > 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
Re: Device Tree Blob (DTB) licence
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 ydrone...@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-...@freebsd.org. I am not a lawyer, Jeroen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
On May 29, 2015, at 11:10 PM, Enrico Weigelt, metux IT consult weig...@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 ?
Re: Device Tree Blob (DTB) licence
On Sat, May 30, 2015 at 12:16 AM, David Lang da...@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 -- ge...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
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 linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
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
Re: Device Tree Blob (DTB) licence
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
Re: Device Tree Blob (DTB) licence
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
Re: Device Tree Blob (DTB) licence
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
Re: Device Tree Blob (DTB) licence
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
Re: Device Tree Blob (DTB) licence
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)
Re: Device Tree Blob (DTB) licence
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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
2015-05-28 7:32 GMT-05:00 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 ? 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 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
Re: Device Tree Blob (DTB) licence
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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
2015-05-28 7:32 GMT-05:00 Enrico Weigelt, metux IT consult weig...@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 ATT 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
Re: Device Tree Blob (DTB) licence
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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
On Fri, May 22, 2015 at 2:27 PM, Yann Droneaud wrote: > I've added licens...@fsf.ogrg in Cc: in my previous message to have an > advice on this subject, but I failed to notice licens...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
On Fri, May 22, 2015 at 2:27 PM, Yann Droneaud ydrone...@opteya.com wrote: I've added licens...@fsf.ogrg in Cc: in my previous message to have an advice on this subject, but I failed to notice licens...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
Hi, [removing Cc: licens...@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 > > > > 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 ". 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 licens...@fsf.ogrg in Cc: in my previous message to have an advice on this subject, but I failed to notice licens...@fsf.org is not a mailing list: I was assigned request ID [gnu.org #1017262]. Regards. -- Yann Droneaud OPTEYA --- Begin Message --- 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 . 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-...@fsf.org. Sincerely, FSF GPL Compliance Lab Office --- End Message ---
Re: Device Tree Blob (DTB) licence
On Fri, May 22, 2015 at 5:05 AM, Yann Droneaud 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 >> 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 ". 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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
Hi, Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit : > On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud > 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 ". 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
Hi, Le mardi 05 mai 2015 à 11:41 -0500, Rob Herring a écrit : On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud ydrone...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
On Fri, May 22, 2015 at 5:05 AM, Yann Droneaud ydrone...@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 ydrone...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
Hi, [removing Cc: licens...@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 ydrone...@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 licens...@fsf.ogrg in Cc: in my previous message to have an advice on this subject, but I failed to notice licens...@fsf.org is not a mailing list: I was assigned request ID [gnu.org #1017262]. Regards. -- Yann Droneaud OPTEYA ---BeginMessage--- 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-...@fsf.org. Sincerely, FSF GPL Compliance Lab Office ---End Message---
Re: Device Tree Blob (DTB) licence
On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud 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 ". 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Device Tree Blob (DTB) licence
On Tue, May 5, 2015 at 5:05 AM, Yann Droneaud ydrone...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
