Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
rickman <gnuarm@gmail.com> writes: > I think you have mixed up something about this and lost the point of > the issue. If you share a software design, you still need a hardware > platform to run it on. I can't run lots of open source software > because it is for hardware that I don't have. If you share a hardware > design someone will need to build the hardware. I can't see how open > source hardware is fundamentally different from open source software. If you look at it that way, there's no difference. But if you look at it that way, you're still licensing the data and requiring [relatively] costly hardware to use it with. The difference in the FSF's case is that "pure software" needs only standard computing machines (pcs, workstations, embedded linux devices, etc) to run. One can treat the software independently of the hardware it runs on, but still fully protect it. The GPL is a license for that kind of software, where the issue of obtaining suitable hardware can be essentially ignored. The software's preferred source format and binary format are both just data, and the GPL protects the freedom of both the source and binary formats. In the case of open hardware, the hardware can't be ignored, because it's effectively the "binary form" of the design. The license can't just ignore the hardware, else it wouldn't be able to protect the freedom of the hardware's design. But, the hardware can't be trivially copied - it has to be manufactured instead. To apply to open hardware, the GPL would thus need to apply to a manufacturing scenario, where real costs are involved, which is something the FSF did not want to get involved in.Article: 157251
On 11/8/2014 1:24 PM, DJ Delorie wrote: > > rickman <gnuarm@gmail.com> writes: >> I think you have mixed up something about this and lost the point of >> the issue. If you share a software design, you still need a hardware >> platform to run it on. I can't run lots of open source software >> because it is for hardware that I don't have. If you share a hardware >> design someone will need to build the hardware. I can't see how open >> source hardware is fundamentally different from open source software. > > If you look at it that way, there's no difference. But if you look at > it that way, you're still licensing the data and requiring [relatively] > costly hardware to use it with. > > The difference in the FSF's case is that "pure software" needs only > standard computing machines (pcs, workstations, embedded linux devices, > etc) to run. One can treat the software independently of the hardware > it runs on, but still fully protect it. The GPL is a license for that > kind of software, where the issue of obtaining suitable hardware can be > essentially ignored. The software's preferred source format and binary > format are both just data, and the GPL protects the freedom of both the > source and binary formats. > > In the case of open hardware, the hardware can't be ignored, because > it's effectively the "binary form" of the design. > The license can't > just ignore the hardware, else it wouldn't be able to protect the > freedom of the hardware's design. This is not at all clear to me. Please explain. The license covers use and propagation of the design. Why is that different if it is for a PCB or for code burned into a Flash ROM? You keep saying the same things without explaining them. > But, the hardware can't be trivially > copied - it has to be manufactured instead. > > To apply to open hardware, the GPL would thus need to apply to a > manufacturing scenario, where real costs are involved, which is > something the FSF did not want to get involved in. You state that a hardware license has to "apply" to a manufacturing scenario without explaining what that means. I don't see anything in your argument that is different between hardware designs and software designs. It is the design that is licensed and the embodiment is irrelevant. -- RickArticle: 157252
On Tue, 04 Nov 2014 07:53:31 -0800, marthajonese wrote: > I was wondering if anybody has had practical experience using IP > licensed with the GNU Public License (GPL, not LGPL) within a commercial > FPGA development. > > I found some Verilog under GPL I would like to use; attempts to contact > the author have gone unanswered (abandonware?). I can't find a 3rd > party with a comparable commercial IP offering, so "plan B" is rolling > my own (four weeks labor?). > > I'm thinking I could do something like quarantine it within it's own > partition and be OK with the spirit of the license, and only have to > distribute the necessary wrapper. My boss rolled his eyes. > > It's a low volume product, so I guess it could be wrapped up in it's own > CPLD - but that seems excessive. I got this from the GNU RSS feed yesterday. Might be useful for this discussion. http://www.fsf.org/news/software-freedom-conservancy-and-free-software- foundation-announce-copyleft.org Guide and other info regarding GPL and others. I have not gone through the guide. -- Chisolm Republic of TexasArticle: 157253
I can not seem to get a decently optimized .PLA file out of the abc <http://www.eecs.berkeley.edu/~alanmi/abc/> I have: a blif of some combinatorial circuit. What I want: the SOPs for a single output bit as a .PLA file (or something equivalent with SOPs) It does not need to be perfect, but would be nice if it were not altogether wrong, and not too big. This sequence gives wrong output, I think: ``` read_blif ./1a.blif strash cone Q[1] collapse write_pla ./1a.pla ``` This seems to work... ``` read_blif ./1a.blif strash collapse cone Q[1] write_pla ./1a.pla ``` blif file is at: <http://members.aon.at/~aklamme4/scratch/1a.blif> It's an adder, I believe... Unfortunately write_pla always generates the SOPs for true output, even if it ends up larger than the list for output false(I believe they call that `phases`). Is there a way I can select the phase I get? It would be ok, if I could invert the output bit/cone, but preferrably from inside abcs interpreter, because I'd like to avoid linking against the 30 MiB libabc.a library. Anybody tried sthg like this befor eand can suggest some command sequences (I don't like to do too much trial and error myself)...Article: 157254
Hi, I would like to create a project with FPGA. You can imagine it as a debug board that need to communicate to other systems with defined protocols and standards... I would like to begin with a starter kit, not too expensive, <200$, but I would like to have the possibility to communicate using ios @ 1.2V. Which system do you suggest me? Thank you very much. I have a good experience in programming microcontrollers, but this time I would like to use FPGA.Article: 157255
On 11/8/2014 10:06 PM, stefano.in.korea@gmail.com wrote: > Hi, I would like to create a project with FPGA. > You can imagine it as a debug board that need to communicate to other systems with defined protocols and standards... > I would like to begin with a starter kit, not too expensive, <200$, but I would like to have the possibility to communicate using ios @ 1.2V. > Which system do you suggest me? > > Thank you very much. > > I have a good experience in programming microcontrollers, but this time I would like to use FPGA. Do you know how to design logic? By logic I mean using digital functional elements like registers, gates, multiplexors and the like. If not, you will have a bit more trouble learning an HDL than a hardware person. The problem most people have learning HDL who have experience with software is understanding the differences. In an HDL nearly everything runs in parallel in the real sense. Only small parts of HDL code are interpreted sequentially and even that has to be translated into logic. Before you buy any hardware, you should plan your project, download some tools and try your hand with an HDL and the simulator. It is *much* easier to debug an FPGA design in the simulator than it is on the bench, at least for most of the bugs. Everything is at your fingertips in a simulation. On the bench you have to bring out to pins any signal you want to view. You don't need to rush into the actual hardware until you have a design debugged in the simulator and you are ready to test it on the bench. -- RickArticle: 157256
Hello I appreciate your guidance in advance! I want to implement a high speed USB 2.0 host controller on FPGA for an image processing application. There are none free USB 2.0 host high speed IPs and commercial IPs are very expensive for me. I want to read some files and processing them. Now, I have a Altera FPGA and USB3300 ULPI PHY. I also find document and read that.(ULPI interface. UTMI+ Low Pin Interface (ULPI) Specification REV 1.1 oct 20 2004) . In this document only discuss about handshaking an transmit packet. I want understand how can I read some cluster from flash memory in USB mass storage device. What kind of other protocols and interfaces are required for "read file from usb mass storage"?Article: 157257
salamArticle: 157258
On Saturday, November 8, 2014 7:06:34 PM UTC-8, stefano....@gmail.com wrote: > Hi, I would like to create a project with FPGA. > You can imagine it as a debug board that need to communicate to other systems with defined protocols and standards... > I would like to begin with a starter kit, not too expensive, <200$, but I would like to have the possibility to communicate using ios @ 1.2V. > Which system do you suggest me? > > Thank you very much. > > I have a good experience in programming microcontrollers, but this time I would like to use FPGA. Thank you Ric, I can already program in Verilog. My fpga will degub "on field" an asic I developed with others. I have some years experience on it. Any suggestion for the hardware? Thank youArticle: 157259
On 11/9/2014 1:30 AM, stefano.in.korea@gmail.com wrote: > On Saturday, November 8, 2014 7:06:34 PM UTC-8, stefano....@gmail.com wrote: >> Hi, I would like to create a project with FPGA. >> You can imagine it as a debug board that need to communicate to other systems with defined protocols and standards... >> I would like to begin with a starter kit, not too expensive, <200$, but I would like to have the possibility to communicate using ios @ 1.2V. >> Which system do you suggest me? >> >> Thank you very much. >> >> I have a good experience in programming microcontrollers, but this time I would like to use FPGA. > > Thank you Ric, I can already program in Verilog. My fpga will degub "on field" an asic I developed with others. > I have some years experience on it. Any suggestion for the hardware? Ok, I see all my advice was of no value, lol. No, I don't normally buy eval boards for FPGAs. I'm not aware of any FPGAs that support 1.2 volt I/Os, but then I seldom go swimming in the shallow end of that pool. My favorite parts are from Lattice and use flash or non-volatile memory for configuration storage. The XO3 series seems to support 1.2 volt I/Os. I don't see a good board for it unless you are looking for barebones. They have a "breakout" board that provides a USB interface for programming and not a lot else other than SMA connector positions, not sure what they are for. Looks like you can run the entire chip off of a single 1.2 volt PSU if you want 1.2 volt I/O. If there is something in particular you would like from an eval board I would be interested in making one. Are you in a big hurry? -- RickArticle: 157260
Hi, I have used a "Papilio Pro" (Spartan 6 LX 9) as monitor for 1.8 V (not 1.2V) logic. Configuring inputs for lower logic level works (to my understanding) by setting it in the constraints file. To drive signals at the lower voltage, the FPGA needs a different reference voltage. An "FMC carrier S6" board (Digilent) should be able to drive 1.2 V. It's a bit more expensive, though. The number of accessible IOs is limited so you may either need to hand-solder to a FMC connector (which is cheap, < $10) or buy Xilinx' FMC debug board for $150+. The manual is here: https://www.digilentinc.com/Data/Products/FMC-CARRIER-S6/FMC_Carrier-S6_rm.pdf Note the table at the bottom of page 3. There is an analog mux on the board that selects the reference voltage for banks 0 and 1. The schematic is here: https://www.digilentinc.com/Data/Products/FMC-CARRIER-S6/FMC%20Carrier-S6_sch.PDF The voltage selector is on the last page in the botttom right corner (IC21). The built-in JTAG interface of the S6 board seemed quite clumsy (the Papilio upload takes less than a second). I'd probably go for open-source xc3sprog with an external JTAG interface if the work with the S6 board requires regular re-builds. The abovementioned boards don't require paying for a development kit license, download Xilinx ISE 14.x. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157261
an alternative is to use external level shifters http://www.adafruit.com/product/395 and any FPGA board you like. The abovementioned "Papilio Pro" is probably the first one I'd take out of the box for a "swiss army knife" type of problem, but basically any board will do. I'd avoid externally powered boards and too low reference oscillator frequencies (i.e. 12M on Spartan 6 rules out some PLL configurations, 32/50/100M simply avoid the problem). --------------------------------------- Posted through http://www.FPGARelated.comArticle: 157262
On Sunday, November 9, 2014 7:43:43 AM UTC-8, mnentwig wrote: > an alternative is to use external level shifters > > http://www.adafruit.com/product/395 > > and any FPGA board you like. The abovementioned "Papilio Pro" is probably > the first one I'd take out of the box for a "swiss army knife" type of > problem, but basically any board will do. I'd avoid externally powered > boards and too low reference oscillator frequencies (i.e. 12M on Spartan 6 > rules out some PLL configurations, 32/50/100M simply avoid the problem). > > > --------------------------------------- > Posted through http://www.FPGARelated.com Thank you to all, I like the idea of level shifter, I'll use it. So now I'll concentrate to other details ( memory needed, speed, number of Ios ... ). Thank you to all for your answers, I appreciate.Article: 157263
Hi DJ, DJ Delorie <dj@delorie.com> wrote: > > rickman <gnuarm@gmail.com> writes: >> I think you have mixed up something about this and lost the point of >> the issue. If you share a software design, you still need a hardware >> platform to run it on. I can't run lots of open source software >> because it is for hardware that I don't have. If you share a hardware >> design someone will need to build the hardware. I can't see how open >> source hardware is fundamentally different from open source software. > > If you look at it that way, there's no difference. But if you look at > it that way, you're still licensing the data and requiring [relatively] > costly hardware to use it with. IMO your statement is partially incorrect. The GPL allows you to copy, modify, distribute the 'source' code and you can do all of them without the need to manufacture anything. What the GPL states as well is the freedom to 'run' the program. Now if we want to continue with the parallelism hardware/software, than it would not be possible to 'run' the hardware unless you build it. For the specific case treated in this thread, the assumption that the underlying hardware to run the IP is /accessible/ to the user is very similar to the assumption that a computer is accessible to the software user as well. The copyright protects the 'original work of authorship', not necessarily the mean it comes with. And the license grants certain rights on the original work, not necessarily the physical mean. You can easily grab a piece of the schematics and embedded it into your design, provided you distribute under GPL. > The difference in the FSF's case is that "pure software" needs only > standard computing machines (pcs, workstations, embedded linux devices, > etc) to run. One can treat the software independently of the hardware > it runs on, but still fully protect it. The GPL is a license for that > kind of software, where the issue of obtaining suitable hardware can be > essentially ignored. The software's preferred source format and binary > format are both just data, and the GPL protects the freedom of both the > source and binary formats. There are software that runs on cluster of computers and are licensed with GPL and is certainly legitimate to do so, I doubt that John Doe will have the capability to run the software 'as is' but he can certainly read it, modify it and distribute it. > In the case of open hardware, the hardware can't be ignored, because > it's effectively the "binary form" of the design. The license can't > just ignore the hardware, else it wouldn't be able to protect the > freedom of the hardware's design. But, the hardware can't be trivially > copied - it has to be manufactured instead. GPL came to protect freedoms which are not at all linked to the cost of production. Yes you are free to produce a hardware artifact and this freedom does not contraddict any of the GPL statements. Whether it costs too much for you to produce is another story and has nothing to do with the license which remains valid. AlArticle: 157264
rickman <gnuarm@gmail.com> writes: >> The license can't just ignore the hardware, else it wouldn't be able >> to protect the freedom of the hardware's design. > > This is not at all clear to me. Please explain. The license covers > use and propagation of the design. Why is that different if it is for > a PCB or for code burned into a Flash ROM? You keep saying the same > things without explaining them. For example, you take a GPL'd schematic and make a PCB out of it. You give the PCB to someone else. Does that new person have the right to copy it? Do they have the ability to copy it? If the GPL doesn't apply to the PCB itself, how does that new person GET the right to copy? They never got a copy of the schematics... So to truly do open hardware, the hardware itself has to come with some sort of license that says "anyone who possesses this hardware, has a right to the design files". But now you have to enfoce compliance of that right across all manufacturers. *Now* you're messing with real money, since anyone who makes a copy of the PCB - and spends real money doing so - has obligations to anyone who gets those PCBs. > You state that a hardware license has to "apply" to a manufacturing > scenario without explaining what that means. The GPL requires that, in addition to the source code, you have to provide any Makefiles, build scripts or non-standard tools required to produce the binaries. If turning a schematic into a PCB, or turning a 3D model into a physical device, requires some non-standard manufacturing technique or tooling... (basically, anything that's not commonly available could be used to "lock you out" of copying by making it essentially impractical to copy it even though you have the design files; the GPL has clauses to prevent this) > I don't see anything in your argument that is different between > hardware designs and software designs. It is the design that is > licensed and the embodiment is irrelevant. The embodiment of a design is the "binary" of the design, and the GPL does apply to software binaries. Why shouldn't it apply to hardware "binaries"? Remember, the purpose of the GPL is not to provide a way to let people copy a design, it's to prevent people from hiding a design from its users. To meet that purpose, they need to control the binaries as much as the sources. The GPL equivalent here is "you may not distribute this hardware, unless you give each recipient the design files."Article: 157265
al.basili@gmail.com (alb) writes: >> If you look at it that way, there's no difference. But if you look at >> it that way, you're still licensing the data and requiring [relatively] >> costly hardware to use it with. > > IMO your statement is partially incorrect. The GPL allows you to copy, > modify, distribute the 'source' code and you can do all of them without > the need to manufacture anything. True, but it's useless to you in that form. You need to compile/manufacture it to make it usable. Heck, in the case or pure data, it can't even *exist* without some hardware to store it on. > What the GPL states as well is the freedom to 'run' the program. Now if > we want to continue with the parallelism hardware/software, than it > would not be possible to 'run' the hardware unless you build it. Yup. You can do whatever you want in the privacy of your own domain, it's just redistribution that's limited. But, we're talking about a hardware product that's being redistributed. > For the specific case treated in this thread, the assumption that the > underlying hardware to run the IP is /accessible/ to the user is very > similar to the assumption that a computer is accessible to the software > user as well. But there's a difference between commodity hardware (i.e. a PC or Mac) and custom hardware (which I think is what we're talking about). You can run Linux on *any* pc, without regard for which PC. You can't run a compiled verilog bitstream on *any* pcb, only the pcb for which the design was intended. Sadly, the line between the two cases is a legal definition (what is a combined work, vs what is a mere aggregate). > The copyright protects the 'original work of authorship', not > necessarily the mean it comes with. And the license grants certain > rights on the original work, not necessarily the physical mean. Copyright grants you *no* rights other than what the holder allows, that includes reproduction and usage rights, including derivative works. If a copyright holder chooses to require redistribution only along with the means to do so, that's their choice. > You can easily grab a piece of the schematics and embedded it into your > design, provided you distribute under GPL. Ah, but how do you distribute hardware under the GPL? The FSF declined to try to cover this case, because IIRC they didn't want to try to figure out how to apply it to things that cost real money. > There are software that runs on cluster of computers and are licensed > with GPL and is certainly legitimate to do so, I doubt that John Doe > will have the capability to run the software 'as is' but he can > certainly read it, modify it and distribute it. The GPL doesn't concern itself with hardware at all, so this is rather pointless wrt the GPL. In this thread, we're trying to apply the GPL to hardware, and I've already said that the FSF did not intend the GPL to be applied to hardware. That's why we're having problems discussing it. > GPL came to protect freedoms which are not at all linked to the cost of > production. GPL came to protect freedoms which do not have a significant cost to enforce. Copying software binaries is essentially free. The GPL was not intended to apply to hardware, which costs significant money to copy.Article: 157266
On 09/11/2014 05:12, neoo wrote: > Hello I appreciate your guidance in advance! > > I want to implement a high speed USB 2.0 host controller on FPGA for > an image processing application. There are none free USB 2.0 host > high speed IPs and commercial IPs are very expensive for me. I want > to read some files and processing them. > > Now, I have a Altera FPGA and USB3300 ULPI PHY. > > I also find document and read that.(ULPI interface. UTMI+ Low Pin > Interface (ULPI) Specification REV 1.1 oct 20 2004) . In this > document only discuss about handshaking an transmit packet. I want > understand how can I read some cluster from flash memory in USB mass > storage device. > > What kind of other protocols and interfaces are required for "read > file from usb mass storage"? The ULPI document is only helpful on the interface, and even then it has some shortcomings. You will need the USB 2.0 document and the document associated with the class of device you want to talk to. I've written just an introduction that is still work in progress, but I hope might be of some use to you. http://www.videosolutions.ltd.uk/tech-articles/ULPI%20interface.html It also provides links to the files you're likely to need. As you say USB 2.0 High Speed IP is not easily available though there are a few helpful articles. An alternative is to use SD cards that use the much simpler SPI interface. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 157267
DJ Delorie <dj@delorie.com> wrote: (snip) > For example, you take a GPL'd schematic and make a PCB out of it. You > give the PCB to someone else. Does that new person have the right to > copy it? Do they have the ability to copy it? If the GPL doesn't apply > to the PCB itself, how does that new person GET the right to copy? They > never got a copy of the schematics... How about a different question: Has anyone ever been successfully prosecuted for PCB copying? -- glenArticle: 157268
On 11/10/2014 3:20 PM, DJ Delorie wrote: > > rickman <gnuarm@gmail.com> writes: >>> The license can't just ignore the hardware, else it wouldn't be able >>> to protect the freedom of the hardware's design. >> >> This is not at all clear to me. Please explain. The license covers >> use and propagation of the design. Why is that different if it is for >> a PCB or for code burned into a Flash ROM? You keep saying the same >> things without explaining them. > > For example, you take a GPL'd schematic and make a PCB out of it. You > give the PCB to someone else. Does that new person have the right to > copy it? Do they have the ability to copy it? If the GPL doesn't apply > to the PCB itself, how does that new person GET the right to copy? They > never got a copy of the schematics... That is the equivalent of giving the embodiment of software, no? If you give someone a device with the OSS embedded in Flash you are obligated to provide the source code. If you give someone an FOSH PCB you are obligated to give them the schematic and most likely the Gerber files. > So to truly do open hardware, the hardware itself has to come with some > sort of license that says "anyone who possesses this hardware, has a > right to the design files". But now you have to enfoce compliance of > that right across all manufacturers. *Now* you're messing with real > money, since anyone who makes a copy of the PCB - and spends real money > doing so - has obligations to anyone who gets those PCBs. I can't follow this part. I don't see how it is any different than Cisco selling units with FOSS embedded. That took *real* money to enforce and *real* money made by Cisco was at stake. >> You state that a hardware license has to "apply" to a manufacturing >> scenario without explaining what that means. > > The GPL requires that, in addition to the source code, you have to > provide any Makefiles, build scripts or non-standard tools required to > produce the binaries. If turning a schematic into a PCB, or turning a > 3D model into a physical device, requires some non-standard > manufacturing technique or tooling... Wow, you are really going out on a limb. The makefile is required to be distributed if it was provided as part of the FOSS package. Likewise any essential manufacturing info would be part of the original FOSH package. But that is very uncommon. There are a small number of files ordinarily used to convey manufacturing info, assembly diagram, drill file, Gerber files, XYRS file and parts list (BOM). Not significantly different from building software from .c, .h, .rc, et. al. > (basically, anything that's not commonly available could be used to > "lock you out" of copying by making it essentially impractical to copy > it even though you have the design files; the GPL has clauses to prevent > this) Who is doing the locking out? 1st party, 2nd party??? >> I don't see anything in your argument that is different between >> hardware designs and software designs. It is the design that is >> licensed and the embodiment is irrelevant. > > The embodiment of a design is the "binary" of the design, and the GPL > does apply to software binaries. Why shouldn't it apply to hardware > "binaries"? Yes, why not? > Remember, the purpose of the GPL is not to provide a way to let people > copy a design, it's to prevent people from hiding a design from its > users. To meet that purpose, they need to control the binaries as much > as the sources. Control? How does FOSS "control" binaries? > The GPL equivalent here is "you may not distribute this hardware, unless > you give each recipient the design files." Yes! Exactly!!! Well, almost. I don't beleve FOSS requires you *give* the sources, it requires they be available such as a download. -- RickArticle: 157269
On 11/09/2014 12:38 AM, Johann Klammer wrote: [...] > > This sequence gives wrong output, I think: > > ``` > read_blif ./1a.blif > strash > cone Q[1] > collapse > write_pla ./1a.pla > ``` > Oh, seems something does not get inverted when specifying the name of the node... it works alright if I do: ``` read_blif ./1a.blif strash cone -O 1 collapse write_pla ./1a.pla ```Article: 157270
rickman <gnuarm@gmail.com> writes: >> (basically, anything that's not commonly available could be used to >> "lock you out" of copying by making it essentially impractical to copy >> it even though you have the design files; the GPL has clauses to prevent >> this) > > Who is doing the locking out? 1st party, 2nd party??? Consider that the GPLv3 now has anti-lockout clauses as the GPLv2 allowed you to distribute the sources but require that any binaries be cryptographically signed before the device would load them (*cough* Tivo *cough*). "You have the sources but they'll do you no good! HA HA HA!" - I.e. the vendor tried to lock their device to one of their binaries, taking away your right to use a modified GPL'd binary instead. >>> I don't see anything in your argument that is different between >>> hardware designs and software designs. It is the design that is >>> licensed and the embodiment is irrelevant. >> >> The embodiment of a design is the "binary" of the design, and the GPL >> does apply to software binaries. Why shouldn't it apply to hardware >> "binaries"? > > Yes, why not? As opposed to applying to the hardware design files, and not the hardware itself. >> Remember, the purpose of the GPL is not to provide a way to let people >> copy a design, it's to prevent people from hiding a design from its >> users. To meet that purpose, they need to control the binaries as much >> as the sources. > > Control? How does FOSS "control" binaries? By preventing you from legally redistributing them except under the license terms. >> The GPL equivalent here is "you may not distribute this hardware, unless >> you give each recipient the design files." > > Yes! Exactly!!! Well, almost. I don't beleve FOSS requires you > *give* the sources, it requires they be available such as a download. It depends on which GPL clause you choose; one option is to make them available for download, another is to include a written promise to give the source later. I include either of these in "give" above, for brevity.Article: 157271
On 11/11/2014 8:57 PM, DJ Delorie wrote: > > rickman <gnuarm@gmail.com> writes: >>> (basically, anything that's not commonly available could be used to >>> "lock you out" of copying by making it essentially impractical to copy >>> it even though you have the design files; the GPL has clauses to prevent >>> this) >> >> Who is doing the locking out? 1st party, 2nd party??? > > Consider that the GPLv3 now has anti-lockout clauses as the GPLv2 > allowed you to distribute the sources but require that any binaries be > cryptographically signed before the device would load them (*cough* Tivo > *cough*). "You have the sources but they'll do you no good! HA HA HA!" > - I.e. the vendor tried to lock their device to one of their binaries, > taking away your right to use a modified GPL'd binary instead. > >>>> I don't see anything in your argument that is different between >>>> hardware designs and software designs. It is the design that is >>>> licensed and the embodiment is irrelevant. >>> >>> The embodiment of a design is the "binary" of the design, and the GPL >>> does apply to software binaries. Why shouldn't it apply to hardware >>> "binaries"? >> >> Yes, why not? > > As opposed to applying to the hardware design files, and not the > hardware itself. > >>> Remember, the purpose of the GPL is not to provide a way to let people >>> copy a design, it's to prevent people from hiding a design from its >>> users. To meet that purpose, they need to control the binaries as much >>> as the sources. >> >> Control? How does FOSS "control" binaries? > > By preventing you from legally redistributing them except under the > license terms. > >>> The GPL equivalent here is "you may not distribute this hardware, unless >>> you give each recipient the design files." >> >> Yes! Exactly!!! Well, almost. I don't beleve FOSS requires you >> *give* the sources, it requires they be available such as a download. > > It depends on which GPL clause you choose; one option is to make them > available for download, another is to include a written promise to give > the source later. I include either of these in "give" above, for > brevity. I really have no idea what point you are trying to make with all this. You go around and around without making anything clear. Instead of discussing this in tiny paragraphs, perhaps you could make a single post that actually explains your thoughts? -- RickArticle: 157272
rickman <gnuarm@gmail.com> writes: > I really have no idea what point you are trying to make with all > this. You go around and around without making anything clear. Instead > of discussing this in tiny paragraphs, perhaps you could make a single > post that actually explains your thoughts? Because each time I make a statement, someone picks it apart from a different direction. That led to "clarifications" that weren't relevent to my original point. My point is that the FSF chose not to try to cover hardware with the GPL, because hardware is a tangible good that costs time and money to replicate, whereas software (either in source or binary format) is intangible and thus effectively cost-free to copy. A correlary to this point is that you can't say "the GPL only applies to the design files" because if the GPL doesn't apply to the physical hardware, there's no way to ensure the recipient of that hardware has the rights to its design files. But, applying a copyright license to physical hardware is both legally and philosophically difficult. As far as the OP is concerned, my only point was that the definition of "work" is a legal one, and that - in general - attempts to circumvent the GPL typically imply that the GPL does apply to the whole you're trying to split up. This is hard enough to work through for software, adding a hardware element to it makes it much harder.Article: 157273
On 11/12/2014 5:49 PM, DJ Delorie wrote: > > rickman <gnuarm@gmail.com> writes: >> I really have no idea what point you are trying to make with all >> this. You go around and around without making anything clear. Instead >> of discussing this in tiny paragraphs, perhaps you could make a single >> post that actually explains your thoughts? > > Because each time I make a statement, someone picks it apart from a > different direction. That led to "clarifications" that weren't relevent > to my original point. > > My point is that the FSF chose not to try to cover hardware with the > GPL, because hardware is a tangible good that costs time and money to > replicate, whereas software (either in source or binary format) is > intangible and thus effectively cost-free to copy. > > A correlary to this point is that you can't say "the GPL only applies to > the design files" because if the GPL doesn't apply to the physical > hardware, there's no way to ensure the recipient of that hardware has > the rights to its design files. But, applying a copyright license to > physical hardware is both legally and philosophically difficult. > > As far as the OP is concerned, my only point was that the definition of > "work" is a legal one, and that - in general - attempts to circumvent > the GPL typically imply that the GPL does apply to the whole you're > trying to split up. This is hard enough to work through for software, > adding a hardware element to it makes it much harder. Ok, this is where we started I believe. You have stated that it is "hard" to apply GPL to hardware. But I don't follow your reasoning in that regard. I don't see how it is any different from software. The fact that it costs more to replicate hardware than it does to replicate software doesn't seem relevant to me. I don't see any reason why "applying a copyright license to physical hardware is both legally and philosophically difficult." It is done all the time. All of my products are copyrighted hardware. A recipient of GPLed hardware has the same rights as a recipient of a GPLed binary with the same level of effort required to enforce the GPL on those products. -- RickArticle: 157274
rickman <gnuarm@gmail.com> wrote: (snip, someone wrote) >> As far as the OP is concerned, my only point was that the definition of >> "work" is a legal one, and that - in general - attempts to circumvent >> the GPL typically imply that the GPL does apply to the whole you're >> trying to split up. This is hard enough to work through for software, >> adding a hardware element to it makes it much harder. > Ok, this is where we started I believe. You have stated that it is > "hard" to apply GPL to hardware. But I don't follow your reasoning in > that regard. I don't see how it is any different from software. The > fact that it costs more to replicate hardware than it does to replicate > software doesn't seem relevant to me. Well, one reason relates to what copyright protects. It protects the expression of the idea. In both cases, one can make a new expression and avoid the copyright. In the case of a large software project, that isn't likely. It would take a very long time to generate a different expression of linux to get around its copyright. But in the case of hardware, reasonably often that isn't true. Consider a PC board as an example hardware. I can redo the layout, with exactly the same components wired up the same way, but with completely different placement. IANAL, but I suspect that would get around any copyright. Seems to me that if you take the netlist and run it through a different PC board router, that would probably be enough. That makes me wonder how hard it would be to write a program that would generate a new expression of a software idea. Change it in enough ways to avoid copyright, but such that the function was guaranteed (as well as software can) to be the same. That is, no human in the loop to make human errors. Not quite the same, but the usual way to get around drug patents is to modify the molecule in some way. Add a methyl group onto one ond, or hydroxyl on the other. Away from the active site, but that is usually enough to get around a patent. You can trademark the name, and often enough that will discourage any copying. People who like Coke won't necessarily switch to Pepsi, even if they did believe it was pretty much the same formula. (Well, Pepsi is doing well enough, but even so, some like Coke more.) > I don't see any reason why "applying a copyright license to physical > hardware is both legally and philosophically difficult." It is done all > the time. All of my products are copyrighted hardware. A recipient of > GPLed hardware has the same rights as a recipient of a GPLed binary with > the same level of effort required to enforce the GPL on those products. Have you tried suing anyone for illegally copying it? -- glen
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z