practical experience with GPL IP core in commercial product

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.

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.

-- glen

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 Texas

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.

Al

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

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.

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.

-- 

Rick

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.

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.

-- 

Rick

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 Texas