EDK : FSL macros defined by Xilinx are wrong

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

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
 
Hello
I appreciate your guidance in advance!

I want to implement a high speed USB 2.0 host controller on FPGA for an image processing application. There are none free USB 2.0 host high speed IPs and commercial IPs are very expensive for me. I want to read some files and processing them.

Now, I have a Altera FPGA and USB3300 ULPI PHY.

I also find document and read that.(ULPI interface. UTMI+ Low Pin Interface (ULPI) Specification REV 1.1 oct 20 2004) . In this document only discuss about handshaking an transmit packet. I want understand how can I read some cluster from flash memory in USB mass storage device.

What kind of other protocols and interfaces are required for "read file from usb mass storage"?
 
Hi DJ,

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

IMO your statement is partially incorrect. The GPL allows you to copy,
modify, distribute the 'source' code and you can do all of them without
the need to manufacture anything.

What the GPL states as well is the freedom to 'run' the program. Now if
we want to continue with the parallelism hardware/software, than it
would not be possible to 'run' the hardware unless you build it.

For the specific case treated in this thread, the assumption that the
underlying hardware to run the IP is /accessible/ to the user is very
similar to the assumption that a computer is accessible to the software
user as well.

The copyright protects the 'original work of authorship', not
necessarily the mean it comes with. And the license grants certain
rights on the original work, not necessarily the physical mean.

You can easily grab a piece of the schematics and embedded it into your
design, provided you distribute under GPL.

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.

There are software that runs on cluster of computers and are licensed
with GPL and is certainly legitimate to do so, I doubt that John Doe
will have the capability to run the software 'as is' but he can
certainly read it, modify it and distribute it.

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.

GPL came to protect freedoms which are not at all linked to the cost of
production. Yes you are free to produce a hardware artifact and this
freedom does not contraddict any of the GPL statements. Whether it costs
too much for you to produce is another story and has nothing to do with
the license which remains valid.

Al
 
DJ Delorie <dj@delorie.com> wrote:

(snip)

For example, you take a GPL'd schematic and make a PCB out of it. You
give the PCB to someone else. Does that new person have the right to
copy it? Do they have the ability to copy it? If the GPL doesn't apply
to the PCB itself, how does that new person GET the right to copy? They
never got a copy of the schematics...

How about a different question: Has anyone ever been successfully
prosecuted for PCB copying?

-- glen
 
rickman <gnuarm@gmail.com> writes:
(basically, anything that's not commonly available could be used to
"lock you out" of copying by making it essentially impractical to copy
it even though you have the design files; the GPL has clauses to prevent
this)

Who is doing the locking out? 1st party, 2nd party???

Consider that the GPLv3 now has anti-lockout clauses as the GPLv2
allowed you to distribute the sources but require that any binaries be
cryptographically signed before the device would load them (*cough* Tivo
*cough*). "You have the sources but they'll do you no good! HA HA HA!"
- I.e. the vendor tried to lock their device to one of their binaries,
taking away your right to use a modified GPL'd binary instead.

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.

The embodiment of a design is the "binary" of the design, and the GPL
does apply to software binaries. Why shouldn't it apply to hardware
"binaries"?

Yes, why not?

As opposed to applying to the hardware design files, and not the
hardware itself.

Remember, the purpose of the GPL is not to provide a way to let people
copy a design, it's to prevent people from hiding a design from its
users. To meet that purpose, they need to control the binaries as much
as the sources.

Control? How does FOSS "control" binaries?

By preventing you from legally redistributing them except under the
license terms.

The GPL equivalent here is "you may not distribute this hardware, unless
you give each recipient the design files."

Yes! Exactly!!! Well, almost. I don't beleve FOSS requires you
*give* the sources, it requires they be available such as a download.

It depends on which GPL clause you choose; one option is to make them
available for download, another is to include a written promise to give
the source later. I include either of these in "give" above, for
brevity.
 
On 11/11/2014 8:57 PM, DJ Delorie wrote:
rickman <gnuarm@gmail.com> writes:
(basically, anything that's not commonly available could be used to
"lock you out" of copying by making it essentially impractical to copy
it even though you have the design files; the GPL has clauses to prevent
this)

Who is doing the locking out? 1st party, 2nd party???

Consider that the GPLv3 now has anti-lockout clauses as the GPLv2
allowed you to distribute the sources but require that any binaries be
cryptographically signed before the device would load them (*cough* Tivo
*cough*). "You have the sources but they'll do you no good! HA HA HA!"
- I.e. the vendor tried to lock their device to one of their binaries,
taking away your right to use a modified GPL'd binary instead.

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.

The embodiment of a design is the "binary" of the design, and the GPL
does apply to software binaries. Why shouldn't it apply to hardware
"binaries"?

Yes, why not?

As opposed to applying to the hardware design files, and not the
hardware itself.

Remember, the purpose of the GPL is not to provide a way to let people
copy a design, it's to prevent people from hiding a design from its
users. To meet that purpose, they need to control the binaries as much
as the sources.

Control? How does FOSS "control" binaries?

By preventing you from legally redistributing them except under the
license terms.

The GPL equivalent here is "you may not distribute this hardware, unless
you give each recipient the design files."

Yes! Exactly!!! Well, almost. I don't beleve FOSS requires you
*give* the sources, it requires they be available such as a download.

It depends on which GPL clause you choose; one option is to make them
available for download, another is to include a written promise to give
the source later. I include either of these in "give" above, for
brevity.

I really have no idea what point you are trying to make with all this.
You go around and around without making anything clear. Instead of
discussing this in tiny paragraphs, perhaps you could make a single post
that actually explains your thoughts?

--

Rick
 
rickman <gnuarm@gmail.com> writes:
I really have no idea what point you are trying to make with all
this. You go around and around without making anything clear. Instead
of discussing this in tiny paragraphs, perhaps you could make a single
post that actually explains your thoughts?

Because each time I make a statement, someone picks it apart from a
different direction. That led to "clarifications" that weren't relevent
to my original point.

My point is that the FSF chose not to try to cover hardware with the
GPL, because hardware is a tangible good that costs time and money to
replicate, whereas software (either in source or binary format) is
intangible and thus effectively cost-free to copy.

A correlary to this point is that you can't say "the GPL only applies to
the design files" because if the GPL doesn't apply to the physical
hardware, there's no way to ensure the recipient of that hardware has
the rights to its design files. But, applying a copyright license to
physical hardware is both legally and philosophically difficult.

As far as the OP is concerned, my only point was that the definition of
"work" is a legal one, and that - in general - attempts to circumvent
the GPL typically imply that the GPL does apply to the whole you're
trying to split up. This is hard enough to work through for software,
adding a hardware element to it makes it much harder.
 

Welcome to EDABoard.com

Sponsor

Back
Top