gEDA-user: firmware and the GPL license
I've been looking at using some GPL'ed firmware code on a USB board that I've designed. The board is part of design project for one of my clients. After some reading my interpretation of the GPL is that if I compile that code into my firmware which will be conveyed to the client, then the entire firmware code now has to fall under the GPL. This effectively means that my client would have to open source their firmware if I make use of the GPL'ed code. So two questions: 1) Is the above interpretation correct? 2) What practical licenses are out there for this type of situation? -- The Art of Engineering - http://blog.engineersimplicity.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
Duncan Drennan wrote: I've been looking at using some GPL'ed firmware code on a USB board that I've designed. 2) What practical licenses are out there for this type of situation? I think of how to partition things so a GPL chunk is on one processor, and talks to a non-GPL code processor or FPGA over a bus such as I2C bus or SPI bus. No compiling together then. Analogous to reading an A2D converter... no viral influence on the ADC internal code. Is this the correct GPL interpretation? John Griessen -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
The GPL is based on the legal concept of a derived work. If you partition the code, it only isolates the GPL'd code if the two parts are not considered one work. Note that this is a legal interpretation, not a technical one, and depends on your intentions as well as your design. So, if you create some mythical interface between two pieces of co-dependent code for the sole purpose of evading the GPL, you haven't evaded it, because the two pieces of code still need each other to function and thus are not independent. A suitable API would be something that *is* intended to allow for arbitrary expansion, or if there are GPL equivalents for both sides, such as the Linux syscall ABI or GIMP plugins, or if the API follows some previously published API, such as an i2c bus. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Thursday 15 November 2007, John Griessen wrote: I think of how to partition things so a GPL chunk is on one processor, and talks to a non-GPL code processor or FPGA over a bus such as I2C bus or SPI bus. No compiling together then. Analogous to reading an A2D converter... no viral influence on the ADC internal code. Is this the correct GPL interpretation? If they are packaged separately, so a user can choose either part, without the other. RMS has claimed that GPL is not appropriate for hardware. Perhaps it is time for a new license in the spirit of GPL, specifically for hardware. It might work to use GPL with a separate document defining some terms in the new scope, but it would look rather strange. (. ... object code is the physical manifestation of .) Suppose I want to distribute a system composed of two modules .. A and B.A is GPL. B is proprietary. It doesn't work. However, I can sell you A and B separately and let you plug them together. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Thu, Nov 15, 2007 at 11:10:11AM -0500, al davis wrote: [...] RMS has claimed that GPL is not appropriate for hardware. [...] I think he said this in reference to the actual hardware design, not so much the firmware that runs on it. But the statement is really just as true of the firmware. Imagine the firmware running on your microcontroller-based refrigerator, which has no accessible user interface, and no way to get data in or out of the hardware without physically hacking it. What does it mean to make the software available to the user in this case? Even in the case of BSD-type licenses that require credit to be given in the documentation accompanying the software, what documentation? Sure, you could stick it in the manual for the appliance, but that would be confusing to the average consumer. What if the embedded device is truly embedded in such a way that the consumer doesn't even realize there's a computing device present -- maybe it's embedded into the structure of their home in the form of, say, moisture sensors that detect water leaks. The homeowner probably won't even see a manual or any documentation for something like that. Maybe it's buried inside the intelligent LED light bulbs intended to replace incandescent bulbs. Even the LGPL (which is used by uClibc, for example) isn't really appropriate for this kind of thing, since you still need to make the source of the library itself available to the users. That's just an obnoxious requirement for the manufacturer of those light bulbs, for example. The users will never take them up on it. Instead of using uClibc, they will just write their own code from scratch or purchase proprietary libraries. Admittedly, the light bulb example is a bit contrived, but I think it illustrates the point -- software is going to be increasingly embedded *everywhere*, and just for the sake of economic efficiency, it would be nice if it were largely based on free/open-source software, but the current licenses are not friendly to this sort of thing. So instead everybody reinvents the wheel, and as a result more bugs creep into your refrigerator. (And the development tools for those proprietary libraries are, of course, Windows-only, which isn't good for open-source either.) I would like to see uClibc in particular released under a more embedded-friendly license. Sorry to rant here, as it's not really relevant to gEDA. I should be ranting on the uClibc mailing list, I guess. I'm sure I wouldn't be the first. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
al davis wrote: If they are packaged separately, so a user can choose either part, without the other. Suppose I want to distribute a system composed of two modules .. A and B.A is GPL. B is proprietary. It doesn't work. However, I can sell you A and B separately and let you plug them together. DJ Delorie wrote: A suitable API would be something that *is* intended to allow for arbitrary expansion, or if there are GPL equivalents for both sides, such as the Linux syscall ABI or GIMP plugins, or if the API follows some previously published API, such as an i2c bus. Thanks. That makes me think my ideas of having a low power functioning power supply need to be very generic. No sharing of similar tasks just because the GPL-based processor is idle for a while. The power module will sell separately, and have a signal over SPI or I2C that tells the GPL-based system what power conservation mode we are in, signals can generate interrupts, GPL-based system time is available as a generic input to the power supply program, including GPL-based system awake time slots. The combination of modules may use interdependent communication between control code, but each module just switches to a less optimized, still functional mode when the communication is gone, (when they are used separately). Another kind of proprietary machine I am thinking of combining with a GPL-based system is a DSP where a datastream in results in a datastream out. That separates based on the reasoning they are physically serparated for sale, and customer does hookup, any generic processor can supply the input datastream, which flows over a prepublished bus or writing data DMA-style to one memory location decoded address, and data length to another decoded address. See any snags? Hmmm... now I see why the open hardware/software projects I am involved with, TinyOS and ConTiki, use BSD style licensing... John Griessen -- Ecosensory Austin TX tinyOS devel on: ubuntu Linux; tinyOS v2.0.2; telosb ecosens1 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
Randall Nortman wrote: On Thu, Nov 15, 2007 at 11:10:11AM -0500, al davis wrote: [...] RMS has claimed that GPL is not appropriate for hardware. [...] I think he said this in reference to the actual hardware design, not so much the firmware that runs on it. But the statement is really just as true of the firmware. Imagine the firmware running on your microcontroller-based refrigerator, which has no accessible user interface, and no way to get data in or out of the hardware without physically hacking it. What does it mean to make the software available to the user in this case? Even in the case of BSD-type licenses that require credit to be given in the documentation accompanying the software, what documentation? Sure, you could stick it in the manual for the appliance, but that would be confusing to the average consumer. What if the embedded device is truly embedded in such a way that the consumer doesn't even realize there's a computing device present -- maybe it's embedded into the structure of their home in the form of, say, moisture sensors that detect water leaks. You are acting as an advocate for the dumbing down going on everywhere by speaking/thinking so pragmatically. So instead everybody reinvents the wheel, and as a result more bugs creep into your refrigerator. (And the development tools for those proprietary libraries are, of course, Windows-only, which isn't good for open-source either.) It's not the lack of a license that keeps developers from supplying code-devel access for embedded products, it's the mindset of their bosses, and that so few engineers lead companies of any, even small, size. They mostly just go to their jobs, creating a Brave New World, and buying techie toys with the paychecks. What is really better to push for is fully open development tool access needing to be in place for every instance of free-open GPL light-bulb-driving software. The light-bulb needs a 3rd pin for devel access. John Griessen [not joking about the light bulbs, (light control systems), I'm developing some] -- Ecosensory Austin TX tinyOS devel on: ubuntu Linux; tinyOS v2.0.2; telosb ecosens1 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
Samuel A. Falvo II wrote: BTW, did you know that RMS *does* consider the Verilog/VHDL that is used to program an FPGA software? Hence, GPL *does* apply to programmable hardware. Perhaps it is time for a new license in the spirit of GPL, See http://www.tapr.org/ohl.html Hear hear! I like this one too. John Griessen -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
After some reading my interpretation of the GPL is that if I compile that code into my firmware which will be conveyed to the client, then the entire firmware code now has to fall under the GPL. This effectively means that my client would have to open source their firmware if I make use of the GPL'ed code. So two questions: 1) Is the above interpretation correct? Yup. 2) What practical licenses are out there for this type of situation? Look for software licensed under the BSD license. Wasabi Systems is a company which specializes in distributing BSD software for embedded applications. They use BSD for precisely the reason you identify above. Stuart ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Nov 15, 2007 8:34 AM, Randall Nortman [EMAIL PROTECTED] wrote: available to the user in this case? Even in the case of BSD-type licenses that require credit to be given in the documentation accompanying the software, what documentation? Sure, you could stick 1) BSD license does not any longer require this stipulation. See http://www.opensource.org for the license verbiage. 2) In the user's manual: This product uses or licenses components manufactured by the following parties: ... What is so confusing about this? This kind of text appears in plenty of documentation for plenty of products already, in some form or another. it in the manual for the appliance, but that would be confusing to the average consumer. What if the embedded device is truly embedded in Nobody ever sees (2) above because nobody ever reads the users manual anymore. The average consumer especially. to this sort of thing. So instead everybody reinvents the wheel, and as a result more bugs creep into your refrigerator. (And the Even with pure public domain software, people are going to re-invent the wheel. An example I've written on another mailing list is that, in today's industry, we have MILLIONS of kinds of wheels. A Toyota Prius wheel will not fit a shopping cart, and a wooden wagon wheel doesn't do so hot as conveyer-belt rollers. The IDEA is what is open; the physical manifestation of the said idea is as domain-specific as the domain to which it is applied. This is as true in software as it is in the physical world. If you _religiously_ re-use software, you end up with horridly unmaintainable source, and massively fat binaries. Our OSes take gigabytes of space precisely because they're so dang general-purpose that they not only include the kitchen sink, but serve as both floor wax AND a desert topping too. This would never fly on an embedded device. -- Samuel A. Falvo II ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Nov 15, 2007 8:10 AM, al davis [EMAIL PROTECTED] wrote: RMS has claimed that GPL is not appropriate for hardware. For hardware. Hardware isn't what is in question. Software running on said hardware is what is in question. BTW, did you know that RMS *does* consider the Verilog/VHDL that is used to program an FPGA software? Hence, GPL *does* apply to programmable hardware. Perhaps it is time for a new license in the spirit of GPL, See http://www.tapr.org/ohl.html -- Samuel A. Falvo II ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
BTW, did you know that RMS *does* consider the Verilog/VHDL that is used to program an FPGA software? Hence, GPL *does* apply to programmable hardware. Perhaps it is time for a new license in the spirit of GPL, See http://www.tapr.org/ohl.html From the TAPR ohl, 1.6 This Agreement does not apply to software, firmware, or code loaded into programmable devices which may be used in conjunction with Documentation or Products. Such software is subject to the license terms established by its copyright holder(s). Any code is a written document which means it falls under licensing and copyright issues. TAPR is specifically aimed at hardware (they consider schematics, gerbers etc. to be documentation of the hardware and that forms part of the license). I've been doing some reading on GPL and BSD which has been quite interesting. The GPL people are typically against BSD style licenses (so-called copycentre), as described here, http://www.gnu.org/philosophy/why-copyleft.html. They also feel that the LGPL should be applied only to cases where there are equivalent proprietary libraries (http://www.gnu.org/licenses/why-not-lgpl.html). At the end of the day, it is really dependant on your intention. If you feel that everything based on, or linking to your code should be open, then use the GPL. Obviously, you can also dual license (remember you as the copyright holder can assign other licenses as you see fit). Alternatively if you want people to be able to use your code without open sourcing their own code, maybe the LGPL, or possibly some mild variation would be suitable. I'm not really too sure about the implications of the LGPL though, so beware before diving in. The kind of license that I would want to use if I wrote a reusable library for a uC would be something like this, 1) You can use and link the code into a bigger work without having to open source the combined work. 2) Modifications to the licensed part of the work must be release under the same license (i.e. improvements modifications etc. are contributed back to the community). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Thu, 15 Nov 2007 11:34:38 -0500 Randall Nortman [EMAIL PROTECTED] wrote: The users will never take them up on it. Instead of using uClibc, they will just write their own code from scratch or purchase proprietary libraries. It's not the users that have to have access to the code. After all, 99 % of GIMP/Firefox/etc users will never consult the code. It's developers, if they want to build on a derived work. So, in terms of the GPS license, it would be enough to mention somewhere the site where the source code can be downloaded. Even on a lightbulb, it could be printed on the packing. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Nov 15, 2007 11:21 AM, DJ Delorie [EMAIL PROTECTED] wrote: So, to go on a tangent here, what about 'code' in the form of Gerbers and etc produced by PCB? Would you consider the resultant board produced by PCB to fall under a GPL license? Would I have to offer 'source' if I sold boards produced with the software? The gerbers are derived works of the *.pcb file, not of pcb itself. Gerber files are a description -- a blueprint -- that just happens to be in machine-readable form. They obviously don't need to be derived from PCB -- you could use a normal text editor if you want. PCB just automates the process of their production. Therefore, it should be covered under something like the OHL, because it serves a purpose precisely identical to that of a schematic diagram. In order for a board to be GPL'd, you'd need to have something on your board which links to (e.g., has physical interconnects with) another part on your board which ITSELF is GPL'd. As long as that requirement isn't met, there is no need to GPL your board. There is some confusion about the use of copyrighted *footprints* in your board, but all the ones we offer are licensed in such a way as to avoid this problem. I never understood the issue of footprints. All one has to do is bust out a micrometer and hand-enter the data yourself to make a footprint right inside PCB. Surely a company cannot enforce footprint protection, since they cannot tell the difference, from looking at a board, between a hand-made footprint and a re-used footprint. -- Samuel A. Falvo II ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Nov 15, 2007 11:12 AM, Steven Ball [EMAIL PROTECTED] wrote: ...what about 'code' in the form of Gerbers and etc produced by PCB? Would you consider the resultant board produced by PCB to fall under a GPL license? Absolutely and very clearly no. This is exactly the same as using the gcc compiler. Compiler output is specifically not covered by GPL. Another example is using a GPL's word processor. The papers you write are not GPL'd The test is easy. If your code (or Gerber files) can be distributed independently from the the GPL'd software then they are not GPL'd. The above test is not trivial and could conceivably fail if say PCB embedded a copy of some GPL'd file inside every output file it made. Then the GPL'd inclusion could not be independently distributed . But most developers are not going to do this or if they did the mistake would be pointed out and it would be corrected.(Yes, I've seen this error made and corrected.) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Nov 15, 2007 5:00 AM, Duncan Drennan [EMAIL PROTECTED] wrote: I've been looking at using some GPL'ed firmware code on a USB board that I've designed. The board is part of design project for one of my clients. After some reading my interpretation of the GPL is that if I compile that code into my firmware which will be conveyed to the client, then the entire firmware code now has to fall under the GPL. This effectively means that my client would have to open source their firmware if I make use of the GPL'ed code. So two questions: 1) Is the above interpretation correct? 2) What practical licenses are out there for this type of situation? In your case where you are wrinting code and you make use of GPL'd code then yes you should release your code under GPL. But there is an exception. The exception is for a GPL'd component that provides some well defined functon that could be provided by some other component. An example of this would by a Windows DLL. Just because your program calls a DLL that is GPLd your program does not have to be GPL'd. The key is the degree of separation. The DLL case is clear cut because any number of programs can call the same DLL and the DLL can be distributed independently of the programs that use it. As long as you maintain this level of independence you are not effected by GPL. If you link in the GPL'd code and make a single object that cannot be taken apart then the object you made must be covered by GPL and you need to offer the source code. But then the next person who gets your product gets to repeat this. If he re-sells your device he needs to offer to give away your source code but he may not have tied your code to his into one big executable object. Perhaps he has only put your gadget and his product in the same box in that case he is re-selling a GPL'd product and some other product. The key test again if if the final product is like the DLL, modular and in theory an end user could replace one part at a time. -- = Chris Albertson Redondo Beach, California ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: seg fault when updating footprint
Guys, Using the instructions in the wiki:(http://www.geda.seul.org/wiki/geda:pcb_tips) How do I update a footprint in my layout? I wonder if this is a new bug. Running Ubuntu Feisty, pcb20070912 There is no such InfoLibrary menu. So, I load element to paste buffer. Then it says to put new footprint over old and shift click left mouse button (LMB). Get a Segmentation fault (core dumped) every time. Thanks, Roger Traylor ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
I've been doing some reading on GPL and BSD which has been quite interesting. IMHO, in summary, there are three interested parties: 1. The developer 2. The consumer 3. The software Proprietary licenses protect the developer's rights and abilities. BSD licenses protect the consumer's rights and abilities. GPL licenses protect the software's rights and abilities. At least, that's how I like to think of it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
So, to go on a tangent here, what about 'code' in the form of Gerbers and etc produced by PCB? Would you consider the resultant board produced by PCB to fall under a GPL license? Would I have to offer 'source' if I sold boards produced with the software? The gerbers are derived works of the *.pcb file, not of pcb itself. There is some confusion about the use of copyrighted *footprints* in your board, but all the ones we offer are licensed in such a way as to avoid this problem. I realize a lot of the 'code' is stuff written by me, but what about any headers or linked-in bits of code used to produce the final result that I did not directly create? None in the gerbers, the amount in the PS/EPS code is too small to be copyrightable. It would be like trying to copyright the phrase Table of Contents in a book. On topic, what if I used a GPL'd compiler to generate firmware using my own header files or the like? At what point will I have to distribute the source to my firmware? Nope. The output of a compiler is derived from the input to the compiler, not from the compiler itself. That's why one uses a LEGAL definition of derived work, not a technical one. If you write a book, the Bic company doesn't own it because you used their pen. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
Surely a company cannot enforce footprint protection, since they cannot tell the difference, from looking at a board, between a hand-made footprint and a re-used footprint. That's why data can not be covered by copyright. For example the names and numbers in a phone book can be reproduced and re-publised but the typographical layout of space and the pagebreaks and width of the colukns and so on are covered under copyright. I think what this means for foot prints is that the size the location of the pads is not covered but the bytes in the file that describe the size and location of the pads is covered. So you could re-format the file so that the data are written differently you'd be OK. The same applies to compilations of public domain works. each work is not covered but the act of assembling a compilation is itself a creative effort that can be copyrighted. So a footprint library might be covered if it was assembled from public information. -- = Chris Albertson Redondo Beach, California ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: seg fault when updating footprint
I wonder if this is a new bug. Running Ubuntu Feisty, pcb20070912 It might be a fixed bug. Try the CVS version of pcb. There is no such InfoLibrary menu. Should be Window Library So, I load element to paste buffer. Then it says to put new footprint over old and shift click left mouse button (LMB). Get a Segmentation fault (core dumped) every time. Could you run pcb under gdb, and post a traceback (where) ? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
So, to go on a tangent here, what about 'code' in the form of Gerbers and etc produced by PCB? Gerber files are a description -- a blueprint -- that just happens to be in machine-readable form. They obviously don't need to be derived from PCB -- you could use a normal text editor if you want. They don't, but the OP specified that they were, so I answered in that context. I never understood the issue of footprints. All one has to do is bust out a micrometer and hand-enter the data yourself to make a footprint right inside PCB. Surely a company cannot enforce footprint protection, since they cannot tell the difference, from looking at a board, between a hand-made footprint and a re-used footprint. The issue of footprints is the same as the issue of maps. The information portrayed (copper layout, street location) is not copyrightable, it's a fact. The artistic representation of those facts (i.e. the text file containing the footprint, a printed map) can be copyrighted. Also, a collection thereof can be copyrighted even if the individual elements cannot. It's not legally simple. When and how one copies the footprints is a factor if it ever went to court. Remember, we're talking legal derived vs technical derived. That's why I license all my stuff so that you don't need to worry about the license :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Nov 15, 2007, at 1:01 PM, DJ Delorie wrote: That's why I license all my stuff so that you don't need to worry about the license :-) Much appreciated. I currently work for a small company doing electronic repair and design, and the gEDA suite is just the ticket for getting things done. The company has more or less standardized on using Macs, so it is nice to be able to use something that works well in that environment. I am continuously amazed at what progress is going on with the project and I hope I have time at some point to lend a hand. As I move forward using gEDA, I have been generating footprints and symbols for chips I am using that are not in the library, which I hope to contribute back to the project once I get them cleaned up and vetted. However, as we move forward, I want to make sure that any hardware that the company sells is 'legal', and that we do not need to send out source with it. Not that I wouldn't love to, but you know how it is... The issue of firmware is interesting to me for the same issues. So far, nothing that has gone out has had firmware that was generated using GPL utilities, but as I become better at using them on in-house projects invariably I will want to use them on actual products. Better to figure this out now rather than later. So, basically, as long as the final version does not pull in significant (ie, more than a few bytes of) GPL'd sources to produce the final result, even if it was generated with GPL'd tools, the final result does not have to be compliant with the GPL, correct? -Steve ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Thu, 2007-11-15 at 11:05 -0800, Chris Albertson wrote: In your case where you are wrinting code and you make use of GPL'd code then yes you should release your code under GPL. But there is an exception. The exception is for a GPL'd component that provides some well defined functon that could be provided by some other component. An example of this would by a Windows DLL. Just because your program calls a DLL that is GPLd your program does not have to be GPL'd. The key is the degree of separation. The DLL case is clear cut because any number of programs can call the same DLL and the DLL can be distributed independently of the programs that use it. As long as you maintain this level of independence you are not effected by GPL. LGPL code is the exception.. if a DLL is GPL and you dynamically link against it, your program must be GPL. No exceptions unless the author of the DLL granted it. If you link in the GPL'd code and make a single object that cannot be taken apart then the object you made must be covered by GPL and you need to offer the source code. If you link in GPL'd code, period. That includes dynamic linking, and any attempts to wrap the proprietary code in a GPL'd wrapper. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Thursday 15 November 2007, DJ Delorie wrote: IMHO, in summary, there are three interested parties: 1. The developer 2. The consumer 3. The software Proprietary licenses protect the developer's rights and abilities. BSD licenses protect the consumer's rights and abilities. GPL licenses protect the software's rights and abilities. I see... 1. The consumer 2. The developer 3. The developer's owner 4. The re-developer 5. The re-developer's owner 4. The re-re-developer 5. The re-re-developer's owner BSD licenses protect the re-developer's owner, at the expense of everyone else. GPL protects all but the owners at the expense of the owners. Proprietary licenses protect the owners at the expense of everyone else. They do not protect the developers. (People can be owned) Only GPL protects both the consumer and developer (and all re-developers). BSD licenses exist for the purpose of transferring technology to the proprietary, enabing a proprietary fork. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Questions on downloading and installing gnucap and gwave
I posted a question on the fedora forum asking how to install an app, gwave, downloaded from SourceForge. This is one of the responces: - seeing as this program has not been updated sense January 9, 2001 you might want to check out audacity.i386 --- # yum install audacity.i386 --- also i just looked at the code and seeing as it is so old it needs a full rewright to compile in gcc 4.1 it may compile in gcc 3.2 ??? but i would not hold my breath . - Where can I get gwave and how do I install it? Does anyone use audacity? Where can I get gnucap? Thanks ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Questions on downloading and installing gnucap and gwave
On Thursday 15 November 2007, Robert Butts wrote: Where can I get gwave and how do I install it? Where can I get gnucap? Have you tried: $ yum install gwave gnucap ? I thought Fedora had the latest stable gEDA related packages. For source ... gnucap Stable version: http://gnucap.org/archive/gnucap-0.35.tar.gz or... http://geda.seul.org/dist/gnucap-0.35.tar.gz gnucap Development version: http://gnucap.org/devel/gnucap-2007-11-14.tar.gz Extra plugins for development version. (Probably not needed. Use only if you need them.) http://gnucap.org/devel/gnucap-2007-11-14-models-bsim.tar.gz http://gnucap.org/devel/gnucap-2007-11-14-models-ngspice17.tar.gz http://gnucap.org/devel/gnucap-2007-11-14-models-spice3f5.tar.gz http://gnucap.org/devel/gnucap-2007-11-14-tools.tar.gz gwave http://geda.seul.org/dist/gwave-20060606.tar.gz Gnucap is usually easy to compile and install. Gwave often has issues. I'm not sure how to advise on it. Does anyone use audacity? I have used a little. Debian sid has 1.3.3. It is not a substitute for gwave. Whoever suggested it as a replacement for gwave probably doesn't understand what it does, or what gwave does. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
So if I write a proprietary program the uses the Motif widget set If your application was GPL... If the Motif widget set comes with the operating system, the GPL has an explicit exclusion for that. If, however, you ship the Motif widgets with your application, because they are both needed to use your application, the GPL applies. If you ship the Motif widgets on the same CD because shipping it is fun and your application has nothing to do with it, the GPL doesn't apply. Gtk had this problem until it got popular enough to be included with Linux by default. In your actual case, you are not distributing any GPL'd code, so the GPL doesn't apply to you anyway. The GPL is about *distribution*, not *use*. An end-user can do whatever they want with GPL'd code, until they want to share it. Now, if you shipped a proprietary application that used the Lesstif widget set, and you shipped the Lesstif libraries too, you'd be in trouble. (You'd have to imagine that Lesstif wasn't already included in most Linux distros, but say you shipped it for some OS that didn't have Lesstif or Motif already, like Windows.) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
If you link in GPL'd code, period. That includes dynamic linking, and any attempts to wrap the proprietary code in a GPL'd wrapper. It is easy to come up with counter examples... So if I write a proprietary program the uses the Motif widget set and I license it with very restrictive terms and sell it to a user. Now lets say that user one day decides to install a GPL'd Motiff library (lesstiff) on his system and my code is dynamically linked to it. I don't think my code is now GPL'd. As the author of the software I have no control over what my code is dynamically linked to. Here is the text quoted directly from the GPL: ...If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works I think this is very clear. I can distribute them both but must make clear the DLL and the main program are separate works ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Thu, 2007-11-15 at 20:36 -0500, DJ Delorie wrote: Gtk had this problem until it got popular enough to be included with Linux by default. GTK is LGPL too, what problem do you refer to? -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Thu, 2007-11-15 at 17:07 -0800, Chris Albertson wrote: If you link in GPL'd code, period. That includes dynamic linking, and any attempts to wrap the proprietary code in a GPL'd wrapper. It is easy to come up with counter examples... So if I write a proprietary program the uses the Motif widget set and I license it with very restrictive terms and sell it to a user. Now lets say that user one day decides to install a GPL'd Motiff library (lesstiff) on his system and my code is dynamically linked to it. I don't think my code is now GPL'd. As the author of the software I have no control over what my code is dynamically linked to. It works because Lesstif is LGPL, not GPL. From /usr/share/doc/lesstif2/copyright on my Ubuntu box: The libXm and libMrm libraries are copyright the Free Software Foundation, and are released under the LGPL, with the exception of VaSimple.c, portions of which are also copyright the X Consortium and freely redistributable. On Debian GNU/Linux systems, the LGPL can be found in /usr/share/common-licenses/LGPL . I see your point about the source being out of your control after distribution though. I hate legalese, and couldn't easily find the right section of the GPL - so don't really know how that works. Why is the GPL so long and complex??? Anyway.. it seems if you're not distributing the proprietary code with the library its linking against, then it seems you're ok. Quoting some of the LGPL: Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. Here is the text quoted directly from the GPL: ...If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works I think this is very clear. I can distribute them both but must make clear the DLL and the main program are separate works Just saying they are separate works doesn't make it so. If this loophole were correct, then we'd have a lot more people using it. Some programs (like ngspice) have code which could link against GNU libraries like readline. ngspice is NO WAY GPL compatilble, so no distribution's can / will ship it with that code enabled. I'm not sure anything stops the user compiling it that way, or whether it puts the user doing so in breach of the GPL license they received that linked library under by doing so. My understanding of the above section, was relating to me taking GPL library A, adding functionality B (with my own code) to that library, and then later wanting to split out B (which I wrote), then that is Ok, so long as it is demonstrable that my B doesn't derive from the original A. I'm not saying I understand the legal behind it though, so will try to avoid further speculation. Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
So if I write a proprietary program the uses the Motif widget set and I license it with very restrictive terms and sell it to a user. Now lets say that user one day decides to install a GPL'd Motiff library (lesstiff) on his system and my code is dynamically linked to it. I don't think my code is now GPL'd. As the author of the software I have no control over what my code is dynamically linked to. It works because Lesstif is LGPL, not GPL. No, it works because the person doing the linking (or even requiring the linking) is not distributing the derived work. The GPL doesn't prohibit any non-distribution uses. The libXm and libMrm libraries are copyright the Free Software Foundation, and are released under the LGPL, This means that if you wrote a proprietary program that used the Lesstif widgets, you'd have to ensure that the user could rebuild and replace the Lesstif portions and still use your application. Since the OP did NOT use Lesstif, that doesn't apply. I see your point about the source being out of your control after distribution though. I hate legalese, and couldn't easily find the right section of the GPL - so don't really know how that works. It's simple. The GPL governs how you redistribute GPL'd code. The OP didn't redistribute GPL'd code, so the GPL doesn't apply. Why is the GPL so long and complex??? Because the lawyers expect it to be so. And, it's not that complex, nor is it that long for what it does. I think this is very clear. I can distribute them both but must make clear the DLL and the main program are separate works Just saying they are separate works doesn't make it so. If this loophole were correct, then we'd have a lot more people using it. Right, it's not so. However, the GPL has an exception for libraries that are normally distributed with the operating system or its development tools, which is the case that normally applies with, for example, glibc, gtk, or lesstif (at least, for Linux systems). Also, if a program has two parts that are both GPL and talk through a well-known interface (such as a GIMP plug-in), a third party writing a proprietary plug-in does not affect the license of the original two-part software. I'm not sure anything stops the user compiling it that way, or whether it puts the user doing so in breach of the GPL license they received that linked library under by doing so. The user can do whatever they want. The GPL places NO RESTRICTIONS on use. However, such a linked program could not be legally shared with anyone else. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Nov 15, 2007 5:36 PM, DJ Delorie [EMAIL PROTECTED] wrote: Now, if you shipped a proprietary application that used the Lesstif widget set, and you shipped the Lesstif libraries too, you'd be in trouble. (You'd have to imagine that Lesstif wasn't already included in most Linux distros, but say you shipped it for some OS that didn't have Lesstif or Motif already, like Windows.) As an LGPL'ed program, Lesstif is fully capable of linking against a proprietary program, and even being shipped with it. The only thing is that source for Lesstif must accompany the distribution (by reference or by inclusion). That's how I understand LGPL. -- Samuel A. Falvo II ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
As an LGPL'ed program, Lesstif is fully capable of linking against a proprietary program, and even being shipped with it. The only thing is that source for Lesstif must accompany the distribution (by reference or by inclusion). That's how I understand LGPL. Er, right. If Lesstif were GPL (not LGPL), my example would apply. Since Lesstif is LGPL, it doesn't, if you use dynamic linking. If you used static linking, you'd have to ship object files for your application. (and I've been talking about the GPL to folks for almost 20 years now, and still get it wrong occasionally. It's not always simple.) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Thu, 2007-11-15 at 20:44 -0500, DJ Delorie wrote: The user can do whatever they want. The GPL places NO RESTRICTIONS on use. However, such a linked program could not be legally shared with anyone else. Ah.. that'd be why I couldn't see any restrictions then ;) Doesn't this allow a loophole for people to ship code linked against some non GPL proprietary stub which matches the interface of the GPL library.. then tell the users to get / replace that stub with the GPL lib? (Or provide them a shell script which did that?) (Trick probably being to come up with such a stub in a non-derivative way of course). Anyway, perhaps I'm drifting too far off topic here.. I think the original query was answered. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Nov 15, 2007 6:32 PM, Peter Clifton [EMAIL PROTECTED] wrote: Doesn't this allow a loophole for people to ship code linked against some non GPL proprietary stub which matches the interface of the GPL library.. then tell the users to get / replace that stub with the GPL Why bother distributing anything at all, and just telling the user to grab the appropriate library as a pre-requisite? :-) lib? (Or provide them a shell script which did that?) This is what most package managers do already. In some cases, like with ROX-Filer AppDirs, it'll even download and compile the prerequisite modules for you on the very first run. (Trick probably being to come up with such a stub in a non-derivative way of course). I don't think you can license an _interface_ -- only an implementation. -- Samuel A. Falvo II ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
Doesn't this allow a loophole for people to ship code linked against some non GPL proprietary stub which matches the interface of the GPL library.. then tell the users to get / replace that stub with the GPL lib? (Or provide them a shell script which did that?) I think we're back to the legal bit - if you've done it in order to bypass the GPL, you probably haven't bypassed it. In court, intention counts. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
On Thursday 15 November 2007, DJ Delorie wrote: GTK is LGPL too, what problem do you refer to? Hmmm... perhaps I'm thinking of something else. I think you might be thinking of QT. In the early days, QT was licensed QPL, an interesting GPL-incompatible license. The problem is that KDE was built around it, and released GPL. KDE apps would link (maybe dynamic) to QT, resulting in a license clash. As a result, some distros would not include it. GTK (or the big support for GTK) exists because of this problem. Many believe that gnome caught on mostly (or entirely) because of this problem. (or maybe exists because of this problem.) Eventually, the problem was solved by changing the license of QT to GPL. Note that it is GPL, not LGPL. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: firmware and the GPL license
GTK is LGPL too, what problem do you refer to? Hmmm... perhaps I'm thinking of something else. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
