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.
Just wondering if you are aware of the 'viral' property of the GPL. Often the license has been referred to as 'copyleft' since any derivative work of even a single line of code coverd by GPL becomes GPL as well.
Be sure your boss is aware of the license issue, since you may be forced to distribute your entire product under GPL. It would be different if the license is LGPL. You may look up on Wikipedia for a good reference, otherwise drop an email to snipped-for-privacy@gnu.org and you'll surely get the most relavant answer.
code that is not supported might be dangerous. The lack of support might be a showstopper that will force you to dig in the code yourself and, depending on the quality of the code, it might be a nightmare.
Besides, I wouldn't expect an abandoned work to be a work of art. People who release their code openly have the tendency to care a lot about it, if this is not the case than I wouldn't follow that trace. Do not underestimate the verification effort behind it as well, you'll need to prove yourself that the garbage you got works 'as expected'.
If the block is a dead known block (uart, usb, spi, I2C, ...) than just plug it in and run your simulation with it, you can toss it away at any stage. It can be a jump start in verification (if it was well done), but if you find yourself scratching your head more than needed on that 'black box' than I'll consider write it from scratch (or buy it from an IP vendor).
Low volume products may cost millions as well (High Rel applications), consider what is the effort you gain w.r.t. what you have to spend if done in house, and make your decisions on numbers (like how many days of development gained). But do pay attention to the licensing, it may simply be a not viable solution. We only use LGPL IP or proprietary.
Yes. I would like to say I know exactly what I would do with this IP if it was software written in C and the final output of my project was a JFFS2 filesystem image.
But it's written in Verilog and my flash holds an FPGA bitstream instead.
This is not true. Combining a GPL work and a non-GPL work causes the resulting work to need to be distributed under the terms of the GPL (as well as the terms of all other component licenses), but does *not* change the terms of the work itself to be GPL. If the license of the other parts are GPL-compatible, then each part retains its individual license and distribution is OK. If the other parts are not GPL-compatible, then the resulting work simply cannot be distributed.
If you use IP provided by Xilinx, you must compy with their terms as well, and distribute the result only according to their license (or not at all), but that doesn't mean your product is owned by Xilinx or must be licensed the same as their IP.
Nobody is ever forced to distribute their product. They can choose to comply with the license terms of the IP they include, or they can choose to not use that IP. Using an incompatible license in part of your work does not force you to relicense your work, it simply prevents you from distributing, since there would be no distribution terms which would comply with both sets of licenses.
The law can only force you to *not* distribute your product, but that's the case with any IP violation. If you include a GPL work in your product and do not comply with the license terms of that work, you are guilty of IP violation, just like with any other IP, but there's nothing magic about the GPL that forces anything else to happen.
I guess I'd like to hear what "combining" means in the context of FPGA development. It's pretty clear what would happen without jumping through hoops, just throwing a bunch of Verilog in a project and hitting the compile button.
But does anyone here have practical experience or know of established practices for jumping through some hoops in order to contain the GPL'd IP without impacting the remainder of the sources which eventually end up together in the resulting FPGA bitstream?
To me, the FPGA equivalent of putting a GPL'd executable in a JFFS2 image for an ARM SoC would be to place the GPL'd IP block in it's own partition within the FPGA.
I think you may be getting confused about distributing the source code and distributing the compiled (synthesized) object. As far as I know, there's no way to get the GPL Verilog code from the bitstream in the flash of your hardware product. So in this respect you're not "distributing" the Verilog source itself any more than you would be distributing a C source by supplying an executable object pre-compiled for an x86 processor that happened to have a portion of it's source under GPL.
If, on the other hand, your end product is an IP core that you offer to others to build into their end-products, that would be re-distributing the GPL source.
I don't believe there is a distinction. If you distribute a compiled form of a GPL licensed source, you are obligated to make the GPL source available.
I recall buying a PC with Lindows (a version of Linux). It had no sources on the hard drive. They had made no effort to provide the sources on their web site or by any other means. I contacted them by email and reminded them of their obligation. They ended up sending me a CD I believe, but later made the source available on the web site. But you had to download each and every file, one at a time.
Combining, and the definition of "derived work", is unfortunately a legal term, not a technical term. Is the resulting contents of your fpga one work? Or a "mere aggregate" of two completely independent things that just happen to be in one package? While the obvious cases are obvious, the rest of the cases usually require a court to decide.
IMHO, and IANAL, and ETC... Anything you do to work around a license, implies that you have not worked around the license, and that your efforts are an admission that you recognize that the license applies. The only exception in the GPL for combining, are components that "normally accompany the operating system or development tools" - the case was added for, for example, the system runtime libraries and standard C libraries. I don't think there's an equivalent for FPGAs, except perhaps for the underlying structures that the tools (xilinx, atmel, etc) use to implement the verilog/vhdl they're compiling.
A few more hours of googling, and I eventually found one guy who maybe agrees with me to some extent.
formatting link
"Open Source Semiconductor Core Licensing" by Eli Greenbaum
The link is dead at the moment, but you can read the google cached copy.
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."
So in my case, the abandonware plus any modifications to it, plus whatever wrapper I put around it and the build scripts to produce the partition would be GPL'd, but the balance of the FPGA would not necessarily be.
Of course, section "VI. Distribution of Physical Devices" has quite a bit to say about shipping hardware, but as with everything else I'm not sure how much applies to FPGA.
"Does the GPL require that source code of modified versions be posted to the public? (#GPLRequireSourcePostedPublic)
The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.
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. [...]"
This is because Xilinx licenses are not 'viral'. The peculiarity of the GPL is what makes every derivative work to be distributed as GPL.
I also would like to add that 'ownership', 'copyright' and 'license' are three different concepts. Ownerships and copyrights cover a diffent set of rights (I own the book I bought, but the publisher retains the rights to copy and distribute it) and a license *grants* a certain set of rights to the end user.
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.
That is correct, I inferred the distribution of the product by the wording used in the OP, believing (s)he wanted to sell their product and therefore distribute it.
The GPL is a license that grants the rights to the users to use, study, copy and modify the 'code'.
As a matter of fact, Verilog, VHDL or any other HDL may legitimately be considered releasable under GPL.
Why that would matter? The form of the final product does not change the principles the author want to defend and disseminate. There are harwdare projects released under GPL (Wikipedia can serve you as a starting point: open source hardware).
I do not quite understand what do you mean by 'Does GPL work for patents'. A license is different from a patent, the former granting rights to the end user and the latter granting rights to the patent holder.
Remember that GPL is neither a patent nor a copyright, is a license and it grants a certain number of rights to the end user.
A patent grants the right to the patent holder to *exclude* others from making, using, and/or selling the invention.
HTH,
Al
p.s.: IANAL either, but I like the logic behind law making.
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'.
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
"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.
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.
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.
No license is 'viral'. The terms either apply or you don't use it. If you use multiple licenses, all terms apply.
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.
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.
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.
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.
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.
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.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.