practical experience with GPL IP core in commercial product

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.

Hi Marthajonese,

marthajonese@gmail.com 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.

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 licensing@gnu.org and you'll surely get the 
most relavant answer.

> 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?).

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'.

> 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.

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).

> It's a low volume product, so I guess it could be wrapped up in it's 
> own CPLD - but that seems excessive.

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.

HTH,

Al

On Tuesday, November 4, 2014 11:23:05 AM UTC-5, alb wrote:
> Just wondering if you are aware of the 'viral' property of the GPL. 

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.

Tomatoe, tomahto.

What have others done?

al.basili@gmail.com (alb) writes:
> 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.

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.

> Be sure your boss is aware of the license issue, since you may be
> forced to distribute your entire product under GPL.

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.

On Tuesday, November 4, 2014 12:59:30 PM UTC-5, DJ Delorie wrote:
> 
> Combining a GPL work and a non-GPL work causes the
> resulting work to need to be distributed under the terms of the GPL.

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.

Hi,

not a direct answer, but you have the GPL code as "executable
specification" and could have it re-coded by a freelancer.

For example, post the job here
https://www.elance.com/r/contractors/q-FPGA
and wait for offers. AFAIK, simply posting the job costs nothing.

I have never used them myself.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

marthajonese@gmail.com wrote:
> On Tuesday, November 4, 2014 12:59:30 PM UTC-5, DJ Delorie wrote:
>> Combining a GPL work and a non-GPL work causes the
>> resulting work to need to be distributed under the terms of the GPL.
> 
> 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.

-- 
Gabor

On 11/4/2014 4:24 PM, GaborSzakacs wrote:
> marthajonese@gmail.com wrote:
>> On Tuesday, November 4, 2014 12:59:30 PM UTC-5, DJ Delorie wrote:
>>> Combining a GPL work and a non-GPL work causes the
>>> resulting work to need to be distributed under the terms of the GPL.
>>
>> 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.

-- 

Rick

marthajonese@gmail.com writes:
> I guess I'd like to hear what "combining" means in the context of FPGA
> development.

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.

> 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?

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.

On Tuesday, November 4, 2014 10:53:35 AM UTC-5, martha...@gmail.com wrote:
> 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.



A few more hours of googling, and I eventually found one guy who maybe agrees with me to some extent.
http://jolt.law.harvard.edu/articles/pdf/v25/25HarvJLTech131.pdf
"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.