Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 157225

Article: 157225
Subject: Re: practical experience with GPL IP core in commercial product
From: DJ Delorie <dj@delorie.com>
Date: Wed, 05 Nov 2014 12:08:01 -0500
Links: << >>  << T >>  << A >>

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
Subject: Re: practical experience with GPL IP core in commercial product
From: rickman <gnuarm@gmail.com>
Date: Wed, 05 Nov 2014 14:00:05 -0500
Links: << >>  << T >>  << A >>
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

Article: 157227
Subject: Re: USB PHY recommendations
From: Mike Perkins <spam@spam.com>
Date: Wed, 05 Nov 2014 19:49:56 +0000
Links: << >>  << T >>  << A >>
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.uk

Article: 157228
Subject: Re: practical experience with GPL IP core in commercial product
From: DJ Delorie <dj@delorie.com>
Date: Wed, 05 Nov 2014 16:50:34 -0500
Links: << >>  << T >>  << A >>

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
Subject: Re: practical experience with GPL IP core in commercial product
From: rickman <gnuarm@gmail.com>
Date: Wed, 05 Nov 2014 17:48:19 -0500
Links: << >>  << T >>  << A >>
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

Article: 157230
Subject: Re: practical experience with GPL IP core in commercial product
From: al.basili@gmail.com (alb)
Date: 6 Nov 2014 07:30:40 GMT
Links: << >>  << T >>  << A >>
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

Article: 157231
Subject: Re: practical experience with GPL IP core in commercial product
From: al.basili@gmail.com (alb)
Date: 6 Nov 2014 08:22:00 GMT
Links: << >>  << T >>  << A >>
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.

Al

Article: 157232
Subject: Re: practical experience with GPL IP core in commercial product
From: al.basili@gmail.com (alb)
Date: 6 Nov 2014 09:28:12 GMT
Links: << >>  << T >>  << A >>
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.

Al

Article: 157233
Subject: Re: practical experience with GPL IP core in commercial product
From: rickman <gnuarm@gmail.com>
Date: Thu, 06 Nov 2014 04:57:11 -0500
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 157234
Subject: Re: practical experience with GPL IP core in commercial product
From: al.basili@gmail.com (alb)
Date: 6 Nov 2014 10:21:29 GMT
Links: << >>  << T >>  << A >>
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).

Al

Article: 157235
Subject: Re: practical experience with GPL IP core in commercial product
From: David Brown <david.brown@hesbynett.no>
Date: Thu, 06 Nov 2014 13:33:09 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: practical experience with GPL IP core in commercial product
From: "O.J.K." <ojk980@gmail.com>
Date: Thu, 6 Nov 2014 04:39:04 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Re: practical experience with GPL IP core in commercial product
From: DJ Delorie <dj@delorie.com>
Date: Thu, 06 Nov 2014 13:29:00 -0500
Links: << >>  << T >>  << A >>

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
Subject: Re: practical experience with GPL IP core in commercial product
From: DJ Delorie <dj@delorie.com>
Date: Thu, 06 Nov 2014 13:38:10 -0500
Links: << >>  << T >>  << A >>

> 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
Subject: Re: practical experience with GPL IP core in commercial product
From: rickman <gnuarm@gmail.com>
Date: Thu, 06 Nov 2014 13:52:27 -0500
Links: << >>  << T >>  << A >>
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?

-- 

Rick

Article: 157240
Subject: Re: practical experience with GPL IP core in commercial product
From: rickman <gnuarm@gmail.com>
Date: Thu, 06 Nov 2014 14:04:46 -0500
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 157241
Subject: Re: practical experience with GPL IP core in commercial product
From: DJ Delorie <dj@delorie.com>
Date: Thu, 06 Nov 2014 15:05:04 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: practical experience with GPL IP core in commercial product
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Thu, 6 Nov 2014 20:19:22 +0000 (UTC)
Links: << >>  << T >>  << A >>
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







Article: 157243
Subject: Re: practical experience with GPL IP core in commercial product
From: Joe Chisolm <jchisolm6@earthlink.net>
Date: Thu, 06 Nov 2014 15:05:48 -0600
Links: << >>  << T >>  << A >>
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

Article: 157244
Subject: Re: practical experience with GPL IP core in commercial product
From: al.basili@gmail.com (alb)
Date: 6 Nov 2014 22:55:22 GMT
Links: << >>  << T >>  << A >>
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

Article: 157245
Subject: Linux USB JTAG Cable Driver for Xilinx Impact
From: Ron Aikins <rgaikins49@gmail.com>
Date: Thu, 6 Nov 2014 15:58:02 -0800 (PST)
Links: << >>  << T >>  << A >>
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,
Ron

Article: 157246
Subject: Re: practical experience with GPL IP core in commercial product
From: DJ Delorie <dj@delorie.com>
Date: Thu, 06 Nov 2014 21:43:04 -0500
Links: << >>  << T >>  << A >>

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
Subject: Re: practical experience with GPL IP core in commercial product
From: DJ Delorie <dj@delorie.com>
Date: Thu, 06 Nov 2014 22:19:04 -0500
Links: << >>  << T >>  << A >>

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
Subject: Re: practical experience with GPL IP core in commercial product
From: rickman <gnuarm@gmail.com>
Date: Fri, 07 Nov 2014 00:19:05 -0500
Links: << >>  << T >>  << A >>
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

Article: 157249
Subject: Re: Linux USB JTAG Cable Driver for Xilinx Impact
From: Jon Elson <jmelson@wustl.edu>
Date: Fri, 07 Nov 2014 18:06:06 -0600
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search