Re: gEDA-user: GPLv3 question
On 10/7/10, DJ Delorie d...@delorie.com wrote: Cross-compiler is not a component of the operating system on which the executable runs. Nearly every embedded OS comes *with* a cross compiler. It just doesn't happen to run *on* the embedded OS. One could argue that such a cross compiler is a component of the embedded OS. Most probably, yes, when somebody supplies the toolchain; do you think one also could argue when nobody does? Cheers, Ineiev ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
Most probably, yes, when somebody supplies the toolchain; do you think one also could argue when nobody does? It wouldn't be a major component of the operating system then. For gcc, though, the FSF themselves supply many embedded toolchains... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
On Wed, Oct 6, 2010 at 9:17 PM, John Griessen j...@ecosensory.com wrote: I'm looking at using libopenstm32 for ARM chips, and wonder what GPLv3 does about your ability to sell a system with code in it. Can you sell it without a complete tool chain? In other words is my compiler cross compile output a covered work when I use a GPLv3 library like libopenstm32? Write the developers to get a license other than GPLv3. I'm thinking this library makes any code you make with it GPLv3. And if you don't use a GPL library, just the GPL compiler, your output can be sold, distributed without any source code. Correct? Should be true, but I know that at work we avoid later versions of GCC and use GCC compiliers with GPLv2 licences. In otherwords if you have IP to protect, see a laywer, if you have legal questons with GPLv3 see a lawyer, see where I am going? read up here http://lwn.net/Articles/343608/ Look into LLVM, as a compilier cholce, don't know if you arm target is suppoted, but there is a good chance since it's an ARM and Apple has done a lot with LLVM and ARM chips for the iPhone and friends ;-) Steve //Soap box GPLv3 prevents comercial companies putting resuorces into GPL software. It opens leagal issues and causes them to look elsewhere. I support v2 but not v3 because it struck a good balance. Alas, now I am prohibited to work on GPLv3 code at work, I won't even submit bugs till I get home. I now can only work on it at home, so my ability and desire to help GPLv3 projects has gone down. // end Soap box ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
On Oct 6, 2010, at 9:17 AM, John Griessen wrote: On 10/06/2010 08:47 AM, Steven Michalske wrote: On Wed, Oct 6, 2010 at 9:17 PM, John Griessenj...@ecosensory.com wrote: I'm looking at using libopenstm32 for ARM chips, and wonder what GPLv3 does about your ability to sell a system with code in it. Can you sell it without a complete tool chain? What would I need to do to comply with GPLv3 for a library delivered as part of a open hardware system? I'm thinking to just include the copyright notice and the library code only might be enough. You don't need to deliver *any* source code unless it is requested by the user. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
I have never heard that you needed to supply the entire tool chain, just the source for the code that you run in your product. I'm strictly a beginner at such things, though, so take what I say with a kilo or so of salt... -Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of John Griessen Sent: Wednesday, October 06, 2010 12:21 PM To: gEDA user mailing list Subject: Re: gEDA-user: GPLv3 question On 10/06/2010 10:30 AM, John Doty wrote: You don't need to deliver *any* source code unless it is requested by the user. OK. Let me rephrase that to, What would I need to make available to comply with GPLv3 for a GPLv3 library delivered as part of an open hardware system?. I'm wanting to clarify the difference between GCC used to make the system's delivered code and libopenstm32 used to make the system's delivered code, where parts of libopenstm32 are included in the output. I'm thinking I would need to make available libopenstm32 source, but not GCC source. Eh? JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
John Griessen wrote: On 10/06/2010 10:30 AM, John Doty wrote: You don't need to deliver *any* source code unless it is requested by the user. OK. Let me rephrase that to, What would I need to make available to comply with GPLv3 for a GPLv3 library delivered as part of an open hardware system?. I'm wanting to clarify the difference between GCC used to make the system's delivered code and libopenstm32 used to make the system's delivered code, where parts of libopenstm32 are included in the output. I'm thinking I would need to make available libopenstm32 source, but not GCC source. Actually, the GPLv3 includes an exception about compilers: However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. (unmodified) GCC for sure is a generally available free program. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
I have: http://gpl-violations.org/faq/sourcecode-faq.html. And yes, Harald Welte has made some vendors to distribute their sources with entire toolchain. Unusual, since the compiler... part of the GPL was specifically added for DJGPP, which is not normally distributed... with the operating system. Even Microsoft's compiler is not normally distributed with the operating system. The ... removes too many words and changes the meaning of that clause. IMHO that part of the GPL means that if you use, for example, libc from a standard compiler, you need not include libc in your source set, unless you include the whole compiler too (i.e. a modified compiler/libc). The key wording is normally distributed with the major components, not normally distributed with the operating system. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
You don't need to deliver *any* source code unless it is requested by the user. In the case of an embedded product, with GPLv3, the *only* way to not include the source is to include the written offer, which opens you up for a DDNS. You can only use the web download option if the binary is itself web downloaded. Also - for embedded products, to comply with GPLv3 you must enable the user to change the code *in the device*. Just providing source code isn't enough unless they can use it too. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
So just to clarify - if you distribute an embedded device that runs a GPLv3 binary; to comply with the GPLv3 you must not only provide the source, but also a hardware-programmer/uploader? I suppose in most cases this isn't necessarily a huge issue - where firmware upgrade capability is built into the device (such as most routers, and development style boards). I play with the Atmel AVR range a fair bit and typically only create boards that require a separate hardware programmer to upload firmware. In this case to distribute such a board with GPLv3 firmware I would technically need to provide the in-circuit-programmer with the board and source. I could imagine in some cases the uC may be programmed *before* it is soldered in place and no mechanism provided by the circuit for firmware modification. In this case I presume you would not be able to make use of GPLv3 firmware - as no mechinism is readily available to modify the firmware... I know these are perhaps somewhat unrealistic scenarios - but if I have understood them correctly it certainly seems that GPLv3 could have been a little more embedded platform friendly. cheers, Geoff On Thu, Oct 7, 2010 at 7:01 AM, DJ Delorie d...@delorie.com wrote: You don't need to deliver *any* source code unless it is requested by the user. In the case of an embedded product, with GPLv3, the *only* way to not include the source is to include the written offer, which opens you up for a DDNS. You can only use the web download option if the binary is itself web downloaded. Also - for embedded products, to comply with GPLv3 you must enable the user to change the code *in the device*. Just providing source code isn't enough unless they can use it too. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
No. GPLv3 says that it must be _possible_ for the user to update his GPLed code, but it need not be easy. You can even ship GPLv3 code in an OTP chip. Basically, just don't use DRM to prevent the user from changing his code when he could otherwise. The intent is to prevent GPLed code from being locked down, trusted computing style. On Wed, Oct 6, 2010 at 4:20 PM, Geoff Swan shinobi.j...@gmail.com wrote: So just to clarify - if you distribute an embedded device that runs a GPLv3 binary; to comply with the GPLv3 you must not only provide the source, but also a hardware-programmer/uploader? I suppose in most cases this isn't necessarily a huge issue - where firmware upgrade capability is built into the device (such as most routers, and development style boards). I play with the Atmel AVR range a fair bit and typically only create boards that require a separate hardware programmer to upload firmware. In this case to distribute such a board with GPLv3 firmware I would technically need to provide the in-circuit-programmer with the board and source. I could imagine in some cases the uC may be programmed *before* it is soldered in place and no mechanism provided by the circuit for firmware modification. In this case I presume you would not be able to make use of GPLv3 firmware - as no mechinism is readily available to modify the firmware... I know these are perhaps somewhat unrealistic scenarios - but if I have understood them correctly it certainly seems that GPLv3 could have been a little more embedded platform friendly. cheers, Geoff On Thu, Oct 7, 2010 at 7:01 AM, DJ Delorie d...@delorie.com wrote: You don't need to deliver *any* source code unless it is requested by the user. In the case of an embedded product, with GPLv3, the *only* way to not include the source is to include the written offer, which opens you up for a DDNS. You can only use the web download option if the binary is itself web downloaded. Also - for embedded products, to comply with GPLv3 you must enable the user to change the code *in the device*. Just providing source code isn't enough unless they can use it too. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
No. GPLv3 says that it must be _possible_ for the user to update his GPLed code, but it need not be easy. Right, and if they have to buy some off-the-shelf programming device to do it, well, that's no different than buying a USB cable or PC. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
ah, cheers - really appreciate the clarification. Geof On Thu, Oct 7, 2010 at 9:30 AM, asom...@gmail.com wrote: No. GPLv3 says that it must be _possible_ for the user to update his GPLed code, but it need not be easy. You can even ship GPLv3 code in an OTP chip. Basically, just don't use DRM to prevent the user from changing his code when he could otherwise. The intent is to prevent GPLed code from being locked down, trusted computing style. On Wed, Oct 6, 2010 at 4:20 PM, Geoff Swan shinobi.j...@gmail.com wrote: So just to clarify - if you distribute an embedded device that runs a GPLv3 binary; to comply with the GPLv3 you must not only provide the source, but also a hardware-programmer/uploader? I suppose in most cases this isn't necessarily a huge issue - where firmware upgrade capability is built into the device (such as most routers, and development style boards). I play with the Atmel AVR range a fair bit and typically only create boards that require a separate hardware programmer to upload firmware. In this case to distribute such a board with GPLv3 firmware I would technically need to provide the in-circuit-programmer with the board and source. I could imagine in some cases the uC may be programmed *before* it is soldered in place and no mechanism provided by the circuit for firmware modification. In this case I presume you would not be able to make use of GPLv3 firmware - as no mechinism is readily available to modify the firmware... I know these are perhaps somewhat unrealistic scenarios - but if I have understood them correctly it certainly seems that GPLv3 could have been a little more embedded platform friendly. cheers, Geoff On Thu, Oct 7, 2010 at 7:01 AM, DJ Delorie d...@delorie.com wrote: You don't need to deliver *any* source code unless it is requested by the user. In the case of an embedded product, with GPLv3, the *only* way to not include the source is to include the written offer, which opens you up for a DDNS. You can only use the web download option if the binary is itself web downloaded. Also - for embedded products, to comply with GPLv3 you must enable the user to change the code *in the device*. Just providing source code isn't enough unless they can use it too. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
On Oct 6, 2010, at 1:01 PM, DJ Delorie wrote: You don't need to deliver *any* source code unless it is requested by the user. In the case of an embedded product, with GPLv3, the *only* way to not include the source is to include the written offer, which opens you up for a DDNS. You can only use the web download option if the binary is itself web downloaded. ?? OK, I admit I haven't read the GPLv3 that carefully yet. Is it because it ships as a physical good that the written offer must be physically realized? Does a silk screen of: For sources: ftp://foo.org/public/sources/wonderwidget.tgz; comply with the written offer clause? -dave ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
On Oct 6, 2010, at 3:20 PM, Geoff Swan wrote: So just to clarify - if you distribute an embedded device that runs a GPLv3 binary; to comply with the GPLv3 you must not only provide the source, but also a hardware-programmer/uploader? I suppose in most cases this isn't necessarily a huge issue - where firmware upgrade capability is built into the device (such as most routers, and development style boards). I play with the Atmel AVR range a fair bit and typically only create boards that require a separate hardware programmer to upload firmware. In this case to distribute such a board with GPLv3 firmware I would technically need to provide the in-circuit-programmer with the board and source. IANAL, but that is not my interpretation. Certainly, GPLv3 precludes you from making it impossible to update the software by requiring secret keys and such. But I always thought you were in compliance as long as you provided all source, and that someone with the skills and easily available tools could reprogram the device. I don't even see the necessity of providing the standard ISP or JTAG connector as long as the nets are exposed and you can clip into them with an octopus pod on a JTAG ICE, you are in compliance, although it won't win you many friends. After all, if you write an open source pcb design package, you don't have to ship a color monitor with it to be in compliance with the GPL, the user can provide his own. The user can provide his own AVRISP clone just as well. -dave I could imagine in some cases the uC may be programmed *before* it is soldered in place and no mechanism provided by the circuit for firmware modification. In this case I presume you would not be able to make use of GPLv3 firmware - as no mechinism is readily available to modify the firmware... I know these are perhaps somewhat unrealistic scenarios - but if I have understood them correctly it certainly seems that GPLv3 could have been a little more embedded platform friendly. cheers, Geoff On Thu, Oct 7, 2010 at 7:01 AM, DJ Delorie d...@delorie.com wrote: You don't need to deliver *any* source code unless it is requested by the user. In the case of an embedded product, with GPLv3, the *only* way to not include the source is to include the written offer, which opens you up for a DDNS. You can only use the web download option if the binary is itself web downloaded. Also - for embedded products, to comply with GPLv3 you must enable the user to change the code *in the device*. Just providing source code isn't enough unless they can use it too. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
?? OK, I admit I haven't read the GPLv3 that carefully yet. Is it because it ships as a physical good that the written offer must be physically realized? Does a silk screen of: For sources: ftp://foo.org/public/sources/wonderwidget.tgz; comply with the written offer clause? I suppose it could, if you added a date to the silkscreen, and made sure the ftp site stayed up the whole three years. b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge. The difference between this and the (d) clause (source and binaries on a server together) is that for (b) you have to guarantee it stays around for at least three years from the last hardware sale, or as long as you support the hardware, whichever is longer. Of course, you then have to keep track of *every* tarball for *every* release you ever made. Most devices come with a dvd anyway, putting the sources for *that* device on *its* dvd meets the GPL and ends any responsibility on your part. It would make option (c) really tricky - how do you make a copy of the offer? :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
But read the text of the exception and try to come to that same conclusion when you're talking about libgcc.so or libstdc++.so. Wouldn't the normally supplied... exception in the GPL kick in anyway? (not that I'm trying to second-guess the experts, the gcc list has been rife with licensing issues lately) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
On Oct 7, 2010, at 7:00 AM, DJ Delorie d...@delorie.com wrote: After all, if you write an open source pcb design package, you don't have to ship a color monitor with it to be in compliance with the GPL, *whew* I wanted one of those setups you were talking about! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
DJ Delorie wrote: I have: http://gpl-violations.org/faq/sourcecode-faq.html. And yes, Harald Welte has made some vendors to distribute their sources with entire toolchain. Unusual, since the compiler... part of the GPL was specifically added for DJGPP, which is not normally distributed... with the operating system. Yes, it is; because cross-compilers are unusual. Even Microsoft's compiler is not normally distributed with the operating system. The ... removes too many words and changes the meaning of that clause. IMHO that part of the GPL means that if you use, for example, libc from a standard compiler, you need not include libc in your source set, unless you include the whole compiler too (i.e. a modified compiler/libc). The key wording is normally distributed with the major components, not normally distributed with the operating system. True. the GPLv2 reads: major components (compiler, kernel, and so on) of the operating system on which the executable runs. Cross-compiler is not a component of the operating system on which the executable runs. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
Cross-compiler is not a component of the operating system on which the executable runs. Nearly every embedded OS comes *with* a cross compiler. It just doesn't happen to run *on* the embedded OS. One could argue that such a cross compiler is a component of the embedded OS. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPLv3 question
On 10/6/2010 7:45 PM, DJ Delorie wrote: But read the text of the exception and try to come to that same conclusion when you're talking about libgcc.so or libstdc++.so. Wouldn't the normally supplied... exception in the GPL kick in anyway? Maybe for your app, but not for libgcc.so itself, which means you may still have to provide Installation Information, making it impossible to build a closed device. AG (not that I'm trying to second-guess the experts, the gcc list has been rife with licensing issues lately) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
