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
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Just wonder, as I haven't noticed it yet in the discussion, > and also IANAL, but how well does GPL work covering hardware? The GPL doesn't work well on actual hardware (resistors, circuit boards, fabricated mechanical parts, etc), because the concept of "copying" is hugely different - software is just data, it can be copied for effectively free. Hardware has a real cost per item. IIRC this has come up in the past and the FSF just isn't interested in trying to make the GPL apply to hardware, although other groups have made attempts at "open source hardware" but that's more of a promise than a license. > Just because it looks like software, doesn't mean it is software. > Verilog describes hardware, not a program to execute on hardware. Technicalities :-) Verilog is a human-readable work which is the preferred mode for authoring [easily copied] electrical patterns which cause fixed hardware to do interesting things. In that sense it can be treated as software, much like compiled C code in flash memory can. > Also, remember that copyright protects the expression of the idea, > not the idea itself. Does GPL work for patents, too? The GPL3 has clauses for patents which cover the GPL'd works but it's mostly there to convey a patent license with the copyright license, to avoid cases where a patent license might preclude following the GPL's terms.Article: 157226
On 11/5/2014 11:35 AM, alb wrote: > Hi Ted, > > ted_buswell@yahoo.com wrote: >> The arrangement I had thought I could use is discussed beginning on >> journal page 147, with the concluding paragraph of that section >> stating: >> >> "Another possibility for commercial entities interested in integrat- >> ing open source soft cores would be to "harden" the GPL core sepa- >> rately from the remainder of the device. In other words, the layout of >> the soft core itself could be fixed in a GDSII file separately from the >> remainder of the device. This separate GDSII file could then be phys- >> ically fixed into the entire design like a hard core. This use of "virtu- >> al" hard cores is sometimes used in the industry to increase design >> efficiency.107 In this event, the problems with making use of the GPL >> soft cores would then reduce to the somewhat simpler issues dis- >> cussed above with regard to hard cores." > > I'm not sure this is really a possibility with GPL'ed code. You may make > it a black box and nobody will ever see what's inside, but you are > infringing the license terms since you are not distributing the source code > of the 'work'. I believe the terms of the GPL say you need to distribute the source in a form similar to the manner in which you distribute the binary. What if the source is included in the memory that holds the binary inside the black box? > Try to ask the FSF if that statement is correct (I doubt it is, but > IANAL) because you may seriously face the risk that someone may go as > far as convincing a court to have access to that 'source' code and > you'll be screwed > (http://en.wikipedia.org/wiki/Free_Software_Foundation_v._Cisco_Systems). > > Al > -- RickArticle: 157227
On 05/11/2014 08:32, Alexander Kane wrote: > On Wednesday, 5 November 2014 01:57:38 UTC+1, Mike Perkins wrote: >> On 04/11/2014 14:20, wrote: >>> We have used the USB3315 extensively in our products, which are >>> used with a huge number of hosts and devices. We have never had a >>> problem with this chip. >>> >>> The USB3315 was made by SMSC (which was bought up by Microchip >>> Tech). This particular chip is now hard to get hold of. I assume >>> that other chips from that series (such as the one Allan >>> mentioned above) will be just as reliable. >>> >>> Regards, Alex >> >> Many thanks for your endorsement. >> >> Microchip claim the USB3315 is still in production. >> > > Hi Mike, > > I just spoke to a colleague, and he did mention there was one problem > with the chip: When operating in Full Speed there are some features > that don't work quite correctly. Many Full Speed applications will > work fine though, and operating with High Speed or Low Speed is > bullet proof (as far as USB goes). It hasn't bothered us though as we > only use Full Speed in specific circumstances. > > Regards, Alex Many thanks for your trouble. I only intend to use High Speed though could drop down to Full Speed. Do you know what were these "features" that don't work correctly. This project is currently on hold but will restart shortly! -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 157228
rickman <gnuarm@gmail.com> writes: > I believe the terms of the GPL say you need to distribute the source > in a form similar to the manner in which you distribute the binary. > What if the source is included in the memory that holds the binary > inside the black box? The sources must be distributed using the same methods/channels as the binaries, on a medium typically used for software interchange. This was used to avoid companies putting the binaries on a fast web server and offering the sources via mail-order 8-track tapes (or encoding them in hidden flash blocks ;). Typically, that means you'd include the sources on a CD in the box with the device. Binaries you can download would have the sources available on the same web server. Etc. The idea here is that the only distribution channel you *know* the user has access to is the one they got the binaries through, so that's always a possible channel for the sources.Article: 157229
On 11/5/2014 4:50 PM, DJ Delorie wrote: > > rickman <gnuarm@gmail.com> writes: >> I believe the terms of the GPL say you need to distribute the source >> in a form similar to the manner in which you distribute the binary. >> What if the source is included in the memory that holds the binary >> inside the black box? > > The sources must be distributed using the same methods/channels as the > binaries, on a medium typically used for software interchange. This was > used to avoid companies putting the binaries on a fast web server and > offering the sources via mail-order 8-track tapes (or encoding them in > hidden flash blocks ;). > > Typically, that means you'd include the sources on a CD in the box with > the device. Binaries you can download would have the sources available > on the same web server. Etc. > > The idea here is that the only distribution channel you *know* the user > has access to is the one they got the binaries through, so that's always > a possible channel for the sources. If no one can view the flash blocks, then they won't know the IP is in there either. -- RickArticle: 157230
Hi DJ, DJ Delorie <dj@delorie.com> wrote: > > glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: >> Just wonder, as I haven't noticed it yet in the discussion, >> and also IANAL, but how well does GPL work covering hardware? > > The GPL doesn't work well on actual hardware (resistors, circuit boards, > fabricated mechanical parts, etc), because the concept of "copying" is > hugely different - software is just data, it can be copied for > effectively free. I believe you are confusing 'free speech' with 'free beer'. There's no such concept as 'free beer' and whoever is twisting the meaning of free software toward believing that is 'free of cost' not only portraits a false image (learning to use free software and maintaining it has an economical cost), but also accepts to give up his/her rights. > Hardware has a real cost per item. IIRC this has > come up in the past and the FSF just isn't interested in trying to make > the GPL apply to hardware, although other groups have made attempts at > "open source hardware" but that's more of a promise than a license. There are 'open source hardware' that are at a mature stage ready to use (see CERN OHL) and actually already used in production. I wish one of those guys can chime in here, but I'm not sure if they are frequent users of this group. AlArticle: 157231
Hi DJ, DJ Delorie <dj@delorie.com> wrote: >> http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic > > Don't read the FAQ, read the license itself: > > "Conveying under any other circumstances is permitted solely under the > conditions stated below." > > I.e. the license makes conditions, but does not change the license of > the other parts. There may be *other* conditions which you must *also* > meet, based on the *other* licenses, but those conditionsare not changed > by also using GPL'd parts. Quoting the Preamble: "To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others." and again: "...if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code." > So if you combine a GPL'd work with a proprietary work, the result is > not GPL'd - the result is that you just can't distribute it, since the > licenses have conflicts which you cannot resolve. Meaning that using GPL'ed work with proprietary work is *viable* only if proprietary work is licensed under a GPL-compatible license. >> But if you release the modified version to the public in some way, the >> GPL requires you to make the modified source code available to the >> program's users, under the GPL. [...]" > > Even this doesn't say that the license of the other parts changes, only > that the distribution must be under the terms required by the GPL, as it > applies to the GPL'd portion. I believe you are distorting my statements. The terms required by the GPL do not apply to the GPL'ed portion only, they apply to the entire work: "You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged" > >> This is because Xilinx licenses are not 'viral'. > > No license is 'viral'. The terms either apply or you don't use it. > If you use multiple licenses, all terms apply. Licenses like GPL are defined *viral* or *copyleft*, meaning that they call for distrubution under the *very same terms* for any derivative work. >> In the OP use case, if (s)he uses a piece of code GPL'ed, in the event >> of redistributing the final work, (s)he has to release the final work >> under the GPL license. This implies that any IP license used which is >> not GPL-compatible cannot be used. > > The wording makes the causality vague. I would say "The only way to > legally release a work that includes GPL'd portions, is under the terms > of the GPL." I would not say "if you... then you have to..." because > that implies that you're being forced to do something that you aren't > forced to do. Quoting RMS (http://www.gnu.org/licenses/rms-why-gplv3.html): “If you include code under this license in a larger program, the larger program must be under this license too.†The license 'enforce' the obligation to license a derived work under the same terms. And that is the reason why GPLv2 and GPLv3 are not compatible, since they both would require to have the larger program released under each of them, which is not possible. AlArticle: 157232
Hi Rick, rickman <gnuarm@gmail.com> wrote: [] > If no one can view the flash blocks, then they won't know the IP is in > there either. from Wikipedia: "In ordinary language, the term crime denotes an unlawful act punishable by a state". The simple fact that is punishable, qualifies it as a crime. And sooner or later someone may have access to those 'blocks' and legitimately sue you for license infringement. AlArticle: 157233
On 11/6/2014 4:28 AM, alb wrote: > Hi Rick, > > rickman <gnuarm@gmail.com> wrote: > [] >> If no one can view the flash blocks, then they won't know the IP is in >> there either. > > from Wikipedia: "In ordinary language, the term crime denotes an > unlawful act punishable by a state". > > The simple fact that is punishable, qualifies it as a crime. And sooner > or later someone may have access to those 'blocks' and legitimately sue > you for license infringement. Actually there is no law broken by violating the terms of the license. So no crime is committed in any event. This is a licensing issue, a civil matter. If the license says you distribute the source code in the same manner as the compiled code, you should be able to include it in the internal Flash. Very easy on a device that is very possibly running Linux anyway. -- RickArticle: 157234
Hi Rick, In article <m3fgme$jv2$1@dont-email.me> you wrote: [] >> The simple fact that is punishable, qualifies it as a crime. And sooner >> or later someone may have access to those 'blocks' and legitimately sue >> you for license infringement. > > Actually there is no law broken by violating the terms of the license. > So no crime is committed in any event. > This is a licensing issue, a civil matter. I'm not sure if license infringement can be qualified as copyright infringement, but the latter may have criminal provisions. So it's a crime. And in 2007 violations of the GPLv2 was claimed by SFLC which filed coopyright infringement lawsuits. > If the license says you > distribute the source code in the same manner as the compiled code, you > should be able to include it in the internal Flash. Very easy on a > device that is very possibly running Linux anyway. No matter how you turn it around, you should allow people to *see* the source and be able to modify, no matter which distribution mean you use. If your flash has an image of a GNU/Linux system it has to have the sources as well (not a lot practical for an embedded system with size constraints). AlArticle: 157235
On 06/11/14 11:21, alb wrote: > Hi Rick, > > In article <m3fgme$jv2$1@dont-email.me> you wrote: > [] >>> The simple fact that is punishable, qualifies it as a crime. And sooner >>> or later someone may have access to those 'blocks' and legitimately sue >>> you for license infringement. >> >> Actually there is no law broken by violating the terms of the license. >> So no crime is committed in any event. >> This is a licensing issue, a civil matter. > > I'm not sure if license infringement can be qualified as copyright > infringement, but the latter may have criminal provisions. So it's a > crime. And in 2007 violations of the GPLv2 was claimed by SFLC which > filed coopyright infringement lawsuits. The GPL builds on copyright laws, rather than licensing laws. There are various reasons for this (IANAL) - I think part of it is that a licence involves an agreement between two parties, while copyright is decided entirely by the author/owner of the work. Copyright laws are mostly civil laws - and therefore breaking them is not a crime, and can lead to fines, compensation suites, and cease-and-desist orders but not jail sentences. Copyright infringements /can/ be a crime if there is significant financial gain by breaking the terms of the copyright. (So if you copy a film and give it away, you can be sued for compensation by the copyright owner - but if you sell lots of copies, you can be jailed.) Breaking "technical restrictions to enforce copyright" can also be a crime in some countries (like the USA with the DCMA laws) - but that does not apply with the source code is easily available. Thus GPL abuses will normally be civil law violations, but might be criminal if the abuser made money while depriving the rightful owner from the market. > >> If the license says you >> distribute the source code in the same manner as the compiled code, you >> should be able to include it in the internal Flash. Very easy on a >> device that is very possibly running Linux anyway. > > No matter how you turn it around, you should allow people to *see* the > source and be able to modify, no matter which distribution mean you use. > If your flash has an image of a GNU/Linux system it has to have the > sources as well (not a lot practical for an embedded system with size > constraints). > > Al >Article: 157236
On Thursday, November 6, 2014 4:57:46 AM UTC-5, rickman wrote: > If the license says you=20 > distribute the source code in the same manner as the compiled code, you= =20 > should be able to include it in the internal Flash. The license doesn't actually say that; earlier posts in this thread were sl= ightly misleading. The license gives you some options on how to do it, but the gist is the sou= rce has to be made available and transferred to others downstream in a conv= entional manner. 8-track tapes is probably a stretch in this day and age; = buried in flash blocks only accessible via JTAG/BDM is probably out of the = question.Article: 157237
al.basili@gmail.com (alb) writes: >> The GPL doesn't work well on actual hardware (resistors, circuit boards, >> fabricated mechanical parts, etc), because the concept of "copying" is >> hugely different - software is just data, it can be copied for >> effectively free. > > I believe you are confusing 'free speech' with 'free beer'. No, I've been involved in Free Software and OSS for over 20 years now, I know the difference. The GPL is effective at protecting the freedom (as in speech) of software *because* copying source code is effectively free (as in beer). > and whoever is twisting the meaning of free software toward believing > that is 'free of cost' I didn't say software was free (as in beer), I said it can be copied for effectively free. How many man-hours of labor does it take to copy a megabyte of data? How much internet cost does it take to transfer that? These costs are typically trivial (essentially free) relative to the development and other costs of a package (which the GPL allows you to be compensated for, and rightfully so). >> Hardware has a real cost per item. IIRC this has >> come up in the past and the FSF just isn't interested in trying to make >> the GPL apply to hardware, although other groups have made attempts at >> "open source hardware" but that's more of a promise than a license. > > There are 'open source hardware' that are at a mature stage ready to use > (see CERN OHL) and actually already used in production. I wish one of > those guys can chime in here, but I'm not sure if they are frequent > users of this group. I've looked at some of them, and inevitably there's something in the EDA chain that's proprietary, which kinda ruins it. But even so, my point was, you can't just "copy" a resistor or FPGA device, you have to buy each one. The non-trivial cost of such hardware "changes the game" relative to software, which is why the FSF itself didn't get involved. Meanwhile, the Open Harware groups are doing a great job at producing hardware for which all the design files and specs are open, but design files and specs are - wait for it - just data. It's not the hardware itself that's freely copyable, it's the design of the hardware that's copyable. Each instance of the hardware still has to be made "from new parts" as it were.Article: 157238
> Meaning that using GPL'ed work with proprietary work is *viable* only if > proprietary work is licensed under a GPL-compatible license. Yup, I agree. However, there are many GPL-compatible licenses out there. My point is that combining a GPL'd part with a something-else'd part does NOT make the whole work GPL'd, it makes the whole work some hybrid that's a combination of both sets of terms. The something-else'd part might, for example, be *more* strict about freedom than the GPL. > I believe you are distorting my statements. The terms required by the > GPL do not apply to the GPL'ed portion only, they apply to the entire > work: The terms apply, just like the terms of any other licensed part apply. The result is the intersection of all the terms. One set does not override the other. >> No license is 'viral'. The terms either apply or you don't use it. >> If you use multiple licenses, all terms apply. > > Licenses like GPL are defined *viral* or *copyleft*, meaning that they > call for distrubution under the *very same terms* for any derivative > work. I see no such "definition" in the GPL. It's a license. It has terms, like any other license. You must follow them, like any other license. This is why you should have lawyers read the licenses - they know to avoid shock terms like "viral" and "copyleft" and tell you what you can actually do. > Quoting RMS (http://www.gnu.org/licenses/rms-why-gplv3.html): RMS is not the GPL. Quote the license, not people talking about it. > The license 'enforce' the obligation to license a derived work under the > same terms. No, *compatible* terms. Not the *same* terms. > And that is the reason why GPLv2 and GPLv3 are not compatible, since > they both would require to have the larger program released under each > of them, which is not possible. The GPLv2 and GPLv3 are not compatible because they have incompatible license terms within, and combining the two results in an empty intersection of terms - there are no terms under which you can distribute the result. Note that GPLv1 and GPLv2 *are* compatible.Article: 157239
On 11/6/2014 1:29 PM, DJ Delorie wrote: > >>> Hardware has a real cost per item. IIRC this has >>> come up in the past and the FSF just isn't interested in trying to make >>> the GPL apply to hardware, although other groups have made attempts at >>> "open source hardware" but that's more of a promise than a license. >> >> There are 'open source hardware' that are at a mature stage ready to use >> (see CERN OHL) and actually already used in production. I wish one of >> those guys can chime in here, but I'm not sure if they are frequent >> users of this group. > > I've looked at some of them, and inevitably there's something in the EDA > chain that's proprietary, which kinda ruins it. But even so, my point > was, you can't just "copy" a resistor or FPGA device, you have to buy > each one. The non-trivial cost of such hardware "changes the game" > relative to software, which is why the FSF itself didn't get involved. Not trying to be argumentative, but what aspect of open sourcing does the cost of hardware impact? I don't really follow what you are saying. > Meanwhile, the Open Harware groups are doing a great job at producing > hardware for which all the design files and specs are open, but design > files and specs are - wait for it - just data. It's not the hardware > itself that's freely copyable, it's the design of the hardware that's > copyable. Each instance of the hardware still has to be made "from > new parts" as it were. Yes, but why does that change anything? The purpose of open source software is to open the exchange of ideas. Open source hardware does the same thing, no? -- RickArticle: 157240
On 11/6/2014 7:33 AM, David Brown wrote: > Copyright laws are mostly civil laws - and therefore breaking them is > not a crime, and can lead to fines, compensation suites, and > cease-and-desist orders but not jail sentences. Copyright infringements > /can/ be a crime if there is significant financial gain by breaking the > terms of the copyright. (So if you copy a film and give it away, you > can be sued for compensation by the copyright owner - but if you sell > lots of copies, you can be jailed.) Breaking "technical restrictions to > enforce copyright" can also be a crime in some countries (like the USA > with the DCMA laws) - but that does not apply with the source code is > easily available. > > > Thus GPL abuses will normally be civil law violations, but might be > criminal if the abuser made money while depriving the rightful owner > from the market. Making money is not required. See section (C) below. (a) Criminal Infringement. — (1) In general. — Any person who willfully infringes a copyright shall be punished as provided under section 2319 of title 18, if the infringement was committed — (A) for purposes of commercial advantage or private financial gain; (B) by the reproduction or distribution, including by electronic means, during any 180-day period, of 1 or more copies or phonorecords of 1 or more copyrighted works, which have a total retail value of more than $1,000; or (C) by the distribution of a work being prepared for commercial distribution, by making it available on a computer network accessible to members of the public, if such person knew or should have known that the work was intended for commercial distribution. So releasing any work by "a computer network" that was intended for "commercial distribution" is committing a crime. I'm not clear on what "commercial distribution" implies, but I'm not sure it requires a profit motive. Not sure how this might apply to GPL code since the act that makes it a copyright violation (not sharing the source) means you can't be in violation of section (C)... However, section (A) is easy enough to qualify for. All you need to do is sell one copy of your derivative work without satisfying the GPL, *if* this is covered under copyright law. If a license is given and you fail to live up to the terms of the license, that is a licensing issue, not a copyright issue. -- RickArticle: 157241
rickman <gnuarm@gmail.com> writes: > Not trying to be argumentative, but what aspect of open sourcing does > the cost of hardware impact? I don't really follow what you are > saying. I don't recall the details, I just remember that it was the fundamental difference between hardware and software - software could be copied for trivial cost and effort but hardware couldn't. You can easily give a copy of a file to friends, but it's a lot harder to give a copy of a cell phone to a friend. Imagine how hard it would be if, each time you borrowed someone's cell phone, they had to give you a factory capable of making that phone! Yes, that's an extreme example, but in the Free Software world, you *can* easily give someone everything they need to build a copy of an app. That makes it a lot easier for the GPL to say you *must* give it, and still be successful as a license. > Yes, but why does that change anything? The purpose of open source > software is to open the exchange of ideas. Open source hardware does > the same thing, no? Yes, but again, it's the designs for the hardware that are shared. You can't share a resistor across two projects, but you can share the schematics that include that resistor. Still, despite how easy it is to share a schematic, and despite a license allowing you to do so, turning that into hardware is nontrivial.Article: 157242
DJ Delorie <dj@delorie.com> wrote: (snip) > Yes, but again, it's the designs for the hardware that are shared. You > can't share a resistor across two projects, but you can share the > schematics that include that resistor. Still, despite how easy it is to > share a schematic, and despite a license allowing you to do so, turning > that into hardware is nontrivial. I was not so long ago wondering about PC board design from verilog. That is, I could design a multiple FPGA, plus some other external logic all in verilog, then generate the PC boards to connect them all together. Could a verilog PC board description be GPL'ed? I presume a PC board design itself could be copyrighted, as an expression of an idea in art, but then again someone else could generate a different expression of the idea that does the same thing electrically. That might make the distinction between hardware and software a little more obvious than the FPGA case. -- glenArticle: 157243
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. If you really think this is a 4 week project you are better off doing it yourself. Your company is going to spend a lot more effort and money trying to hash this all out than your 4 weeks. Tell your boss the GPL thing is out and you need 6 weeks -- Chisolm Republic of TexasArticle: 157244
Hi DJ, DJ Delorie <dj@delorie.com> wrote: > Yup, I agree. However, there are many GPL-compatible licenses out > there. My point is that combining a GPL'd part with a something-else'd > part does NOT make the whole work GPL'd, it makes the whole work some > hybrid that's a combination of both sets of terms. The something-else'd > part might, for example, be *more* strict about freedom than the GPL. Any restriction of those freedoms is prohibited under the GPL and will prevent redistribution under the terms of GPL. >> Quoting RMS (http://www.gnu.org/licenses/rms-why-gplv3.html): > > RMS is not the GPL. Quote the license, not people talking about it. Quoting the GPLv3 text (http://www.gnu.org/copyleft/gpl.html): "5. Conveying Modified Source Versions. [...] c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it." BTW, RMS does not simply talk about the GPL (like I do), he wrote it. >> The license 'enforce' the obligation to license a derived work under the >> same terms. > > No, *compatible* terms. Not the *same* terms. Touche :-) > Note that GPLv1 and GPLv2 *are* compatible. That is because GPLv1 lacks of the obligation to convey covered work under the same terms of the license, a major change between the two versions. AlArticle: 157245
I've read much on this topic elsewhere, but I'm confused on some things, no= t to mention some of what I've read is out of date w.r.t. s/w versions, etc= . I've been frustrated on a previous attempt to get things going, but am no= w starting with a fresh OS installation and hope to resolve compatibility i= ssues up front. So, I'm running Ubuntu 14.04 and have downloaded but not yet installed Xili= nx LabTools 14.7. I also have the infamous usb-driver-HEAD.tgz from http://= rmdir.de/~michael/xilinx/ but have not yet installed it. First, my OS is 64-bit. In spite of that, do I need to install the 32-bit v= ersion of LabTools to be compatible with the usb-driver? From what I've rea= d, it doesn't sound as though there is a 64-bit version of the driver. Is t= hat true? I'm not sure what runs with what, but need to find out what to do to get th= is running. Would be nice to find a "current" list of installation instructions... Thanks, RonArticle: 157246
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Could a verilog PC board description be GPL'ed? Sure. Of course, that just passes the problem off to whoever uses that verilog to make hardware :-)Article: 157247
al.basili@gmail.com (alb) writes: > Any restriction of those freedoms is prohibited under the GPL and will > prevent redistribution under the terms of GPL. Not restrictions of freedoms, stricter about freedoms. I.e. *more* free. I can't think of a good example at the moment, though. > "5. Conveying Modified Source Versions. [...] c) You must license the > entire work, as a whole, under this License to anyone who comes into > possession of a copy. This License will therefore apply, along with any > applicable section 7 additional terms, to the whole of the work, and all > its parts, regardless of how they are packaged. This License gives no > permission to license the work in any other way, but it does not > invalidate such permission if you have separately received it." That might be the reason why so many projects, including the Linux kernel, refuse to use GPLv3, and instead use GPLv2. The OP didn't say what version of the GPL was involved. But still... "7... You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission." This is the "intersection of terms" clause. Copyright lets you do *nothing* with a work unless you're given permission by the copyright holder. The GPL gives you permission to do certain things. Other licenses may give you other permissions as per sec 7. The result is the intersection of these, where the things you are permitted to do are allowed by both licenses. > BTW, RMS does not simply talk about the GPL (like I do), he wrote it. GPLv3 was not written by RMS, but by the FSF lawyers, but that's not the point. Even if he was the sole author, he still paraphrases and generalizes when he talks about it.Article: 157248
On 11/6/2014 3:05 PM, DJ Delorie wrote: > rickman <gnuarm@gmail.com> writes: >> Not trying to be argumentative, but what aspect of open sourcing does >> the cost of hardware impact? I don't really follow what you are >> saying. > > I don't recall the details, I just remember that it was the fundamental > difference between hardware and software - software could be copied for > trivial cost and effort but hardware couldn't. You can easily give a > copy of a file to friends, but it's a lot harder to give a copy of a > cell phone to a friend. Imagine how hard it would be if, each time you > borrowed someone's cell phone, they had to give you a factory capable of > making that phone! Yes, that's an extreme example, but in the Free > Software world, you *can* easily give someone everything they need to > build a copy of an app. That makes it a lot easier for the GPL to say > you *must* give it, and still be successful as a license. > >> Yes, but why does that change anything? The purpose of open source >> software is to open the exchange of ideas. Open source hardware does >> the same thing, no? > > Yes, but again, it's the designs for the hardware that are shared. You > can't share a resistor across two projects, but you can share the > schematics that include that resistor. Still, despite how easy it is to > share a schematic, and despite a license allowing you to do so, turning > that into hardware is nontrivial. 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. -- RickArticle: 157249
Ron Aikins wrote: > I've read much on this topic elsewhere, but I'm confused on some things, > not to mention some of what I've read is out of date w.r.t. s/w versions, > etc. I've been frustrated on a previous attempt to get things going, but > am now starting with a fresh OS installation and hope to resolve > compatibility issues up front. > > So, I'm running Ubuntu 14.04 and have downloaded but not yet installed > Xilinx LabTools 14.7. I also have the infamous usb-driver-HEAD.tgz from > http://rmdir.de/~michael/xilinx/ but have not yet installed it. > > First, my OS is 64-bit. In spite of that, do I need to install the 32-bit > version of LabTools to be compatible with the usb-driver? From what I've > read, it doesn't sound as though there is a 64-bit version of the driver. > Is that true? > > I'm not sure what runs with what, but need to find out what to do to get > this running. > > Would be nice to find a "current" list of installation instructions... I went through FITS trying to get the old Parallel Cable III to work on 64 bit OS, and finally gave up. I bought a Chinese (clone??) USB cable on eBay, and it worked right away on the 64-bit OS. I'm running Ubuntu 12.04 and the full Xilinx iSE suite. (I think that is 14.04, will check on that.) I think the Digilent pod also works on 64-bit when you install their driver. Jon
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