practical experience with GPL IP core in commercial product

Hi DJ,

DJ Delorie <dj@delorie.com> wrote:
> 
> 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.  

from 
http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic

"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. [...]"

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

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.

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

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.

Al

alb <al.basili@gmail.com> wrote:
 

(snip)

> http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
 
> "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. [...]"

Just wonder, as I haven't noticed it yet in the discussion,
and also IANAL, but how well does GPL work covering hardware?

Just because it looks like software, doesn't mean it is software.
Verilog describes hardware, not a program to execute on hardware.

Also, remember that copyright protects the expression of the idea,
not the idea itself. Does GPL work for patents, too?

-- glen

Hi Glen,

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
[]
>> 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. [...]"
> 
> 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 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.

> Just because it looks like software, doesn't mean it is software.
> Verilog describes hardware, not a program to execute on hardware.

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

> Also, remember that copyright protects the expression of the idea,
> not the idea itself. Does GPL work for patents, too?

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.

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

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

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

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.

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

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

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

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.

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
>


-- 

Rick

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.

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.

-- 

Rick

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.

Al