From mboxrd@z Thu Jan 1 00:00:00 1970 From: weigelt@melag.de (Enrico Weigelt, metux IT consult) Date: Thu, 28 May 2015 18:52:52 +0200 Subject: Device Tree Blob (DTB) licence In-Reply-To: <20150528133429.GD2067@n2100.arm.linux.org.uk> References: <1430820315.19516.26.camel@opteya.com> <1432289148.5304.58.camel@opteya.com> <1432322832.5304.63.camel@opteya.com> <55670AD4.8020705@melag.de> <20150528133429.GD2067@n2100.arm.linux.org.uk> Message-ID: <556747E4.6070403@melag.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Enrico Weigelt, metux IT consult" Subject: Re: Device Tree Blob (DTB) licence Date: Thu, 28 May 2015 18:52:52 +0200 Message-ID: <556747E4.6070403@melag.de> References: <1430820315.19516.26.camel@opteya.com> <1432289148.5304.58.camel@opteya.com> <1432322832.5304.63.camel@opteya.com> <55670AD4.8020705@melag.de> <20150528133429.GD2067@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20150528133429.GD2067-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Russell King - ARM Linux Cc: Rob Landley , Yann Droneaud , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: devicetree@vger.kernel.org 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=FCr ein= en begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist = ausschlie=DFlich f=FCr denjenigen bestimmt, an den sie gerichtet worden= ist. Wenn Sie nicht der Adressat dieser E-Mail sind, d=FCrfen Sie dies= e nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweis= e in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrt=FCmlich er= halten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf = diese Nachricht antworten. Bitte l=F6schen Sie in diesem Fall diese Nac= hricht und alle Anh=E4nge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged i= nformation. 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, forw= ard, disclose or otherwise use it or any part of it in any form whatsoe= ver. If you received this email in error please notify the sender by re= plying and delete this message and any attachments without retaining a = copy. -- To unsubscribe from this list: send the line "unsubscribe devicetree" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754267AbbE1QxG (ORCPT ); Thu, 28 May 2015 12:53:06 -0400 Received: from mail.melag.de ([217.6.74.107]:41105 "EHLO mail.melag.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753816AbbE1QxB convert rfc822-to-8bit (ORCPT ); Thu, 28 May 2015 12:53:01 -0400 Message-ID: <556747E4.6070403@melag.de> Date: Thu, 28 May 2015 18:52:52 +0200 From: "Enrico Weigelt, metux IT consult" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Russell King - ARM Linux CC: Rob Landley , Yann Droneaud , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: Device Tree Blob (DTB) licence References: <1430820315.19516.26.camel@opteya.com> <1432289148.5304.58.camel@opteya.com> <1432322832.5304.63.camel@opteya.com> <55670AD4.8020705@melag.de> <20150528133429.GD2067@n2100.arm.linux.org.uk> In-Reply-To: <20150528133429.GD2067@n2100.arm.linux.org.uk> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8BIT X-Originating-IP: [192.168.57.169] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.