Hi Opencores,
I've been using cores from this site and other sites distributed under
the GPL license for some time now. I thought I understood the terms
and conditions of the GPL license until I read the note added on the
project page of the "IMA ADPCM Sound Encoder" core added recently:
"PLEASE NOTICE THAT THIS CORE IS LICENSED AS GPL. That means you may
use it only for NON-COMMERCIAL purposes."
Lets put aside the fact that the writer is using the OpenCores.org web
site to advertise its product without giving any real asset to the
open source community. I did not download the core and will not do so
while this note is there.
I personally think that the note is wrong and any work licensed under
the GPL license is free for use in a commercial product under the
described terms.
Who is closer to the truth in this case?
Thanks,
Moti

Hello Mr. Moti, I am the author of the core you mention. First of all, the IMA ADPCM core at opencores.org is *completely functional* and anybody can easily implement it. Second, I think you should understand what the GPL stands for. So this is a copy/paste from http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem : "I'd like to incorporate GPL-covered software in my proprietary system. Can I do this? You cannot incorporate GPL-covered software in a proprietary system. The goal of the GPL is to grant everyone the freedom to copy, redistribute, understand, and modify a program." "Best regards, Victor Lopez" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20090125/2aaf8d6b/attachment.htm

Hi Moti, On Sun, 2009-01-25 at 11:08 +0100, motilito at gmail.com wrote: you are absolutely right in your understanding, as can be seen here: http://www.gnu.org/philosophy/selling.html Hellwig

Subject: [oc] GPL License - again

Unfortunately, the GPL is an often misunderstood license. Some
commercial interests use the GPL for cores and libraries so that
using them with other cores or code is only allowed if that code
is also licensed under the same terms. This has the effect of making
it prohibited to produce "commercial" product with the core or library,
because it is unlikely feasible for the entire aggregate work to be released
under the GPL, which is Really what the license requires. Trolltech did
this with the Qt library for a long time, just moving to LGPL recently and
Gaisler licenses the LEON3 cores under the GPL, while LEON2 is LGPL.

So, certainly, this "non commercial use" notice is a serious misunderstanding
by the people posting this core. That is absolutely not, under any valid
interpretation, what the GPL says. The correct statement would be "If
you use this core, you are required to make available the sources for the
complete design and the scripts required to build it". If you can't do that,
then the effect might be the same, but that's secondary.

J.

On Mon, 2009-01-26 at 10:29 +0100, djd328 at yahoo.com wrote: There's been a lot of discussion on the OpenRISC mailing list in the last week or two. The underlying problem is that GPL and similar licenses are for software and based on copyright law. When you publish your software (distributing a compiled binary counts as publication), then you must distribute the source. The problem is that chip manufacturing is NOT publication, so you don't have to publish the source (GPL or LGPL) just because you make a chip out of OpenCores IP. The Free Software Foundation warn that their licenses do not work for hardware. But of course if you were to make available a model of your chip for simulation purposes (i.e. a compiled binary), then the obligations of the GPL/LGPL would apply. The comment about GPL not being feasible for commercial is nonsense. IBM is the world's biggest patent holder, yet makes twice as much from its open source products and services as it does from its patent portfolio. Red Hat has just overtaken Sun in market cap. There is a good description of the reasons for preferring GPL over LGPL from the Free Software Foundation: http://www.gnu.org/licenses/why-not-lgpl.html Free and open source software (and for that matter hardware) is about a better way of developing code. The price of using GPL'd code is that you have to become part of that approach, because your code will also become open source. LGPL is BAD because it allows people to have all the benefits of open source WITHOUT putting anything back. If you've got something good and it's only available under GPL, people will use it, even if they have to obey the open source rules. The only time to use LGPL is where there are free alternatives available, and you want to persuade others to try your stuff. That's why glibc is LGPL (there were already other free C libraries), but readline is GPL (there is no other library like it). If you want a nice readline interface in your program, you'll have to go open source. The moral is: believe in your code. If it's good, people will use it, even it it's GPL. I'm working with a number of organizations in the UK to bring forward a license that works for open source hardware, with obligations triggered by manufacturing, rather than publication. If you'd like to be involved, drop me an email. HTH, Jeremy -- Tel: +44 (1202) 416955 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: jeremy.bennett at embecosm.com Web: www.embecosm.com

Hi Victor, As other members of this forum indicated the GPL license does not limit the use of the "software" for commercial use. Which was my concern. As requested in your post of the core, it is not intended for commercial use. This limitation must be met by all users, at least that is what I think regardless of the license attached to it. I would like to apologize if my post implied that the core is not functional or only partially functional. There was a link to an attachment in the forum but I could not see it. Regards, Moti ----- Original Message ----- From: Víctor Lópezvictor.lopez at o...> To: Date: Sun Jan 25 20:59:55 CET 2009 Subject: [oc] GPL License - again

Dear all, I am not lawyer but I am the copyright holder, and I consider I have the rights to establish my terms above any license, and they are "use for non-commercial purposes". What I am sure of is that I will carefully consider releasing new cores to the community and if so, I will veeeeery closely look at the license. It would be wonderful if the persons who so ardently defend their rights to decide under what conditions they can commercialize the work of others (contributed for free), would in turn contribute with any core at all. Because, while I have contributed to the opensource community with 5 fully functional cores ( http://www.opencores.org/people.cgi/info/galland ), Mr. Moti, the originator of this discussion about GPL happens to have never contributed with any core to the opencores community, as can be seen in the following link: http://www.opencores.org/people.cgi/info/motilito Regards, Victor Lopez

...

...
I'm glad Victor Lopez quoted and gave a direct link to GNU's "GPL FAQ"_. I find that much more useful and convincing than listening to what other people say they think the GPL means. That same FAQ also says: "I'd like to license my code under the GPL, but I'd also like to make it clear that it can't be used for military and/or commercial uses. Can I do this?" "No, because those two goals contradict each other." I am also glad Hellwig Geisse posted a link to GNU's "Selling Free Software" essay. Fascinating. Another document I found useful is "A Practical Guide to GPL Compliance" from the Software Freedom Law Center, which specifically mentions the case where one "distributes the GPL'd software commercially": Take the example of Vendor V , who develops a software platform from GPL'd sources for use in embedded devices. Manufacturer M contracts with V to install the software as firmware in M's device. V provides the software to M, along with a compliant offer for source. In this situation, M cannot simply pass V 's offer for source along to its customers. M also distributes the GPL'd software commercially, so M too must comply with the GPL and provide source (or M's own offer for source) to M's customers. While we are talking about license confusion, has the "OpenIPCore license" become obsolete? I see the "Open Design Prototype Board" project mentions it, but its link to the license is 404. .. _IMA ADPCM Sound Encoder http://opencores.org/projects.cgi/web/ima_adpcm_encoder/ .. _"GPL FAQ: proprietary" http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem .. _"GPL FAQ: military and/or commercial" http://www.gnu.org/licenses/gpl-faq.html#NoMilitary .. _"Selling Free Software" http://www.gnu.org/philosophy/selling.html .. _"A Practical Guide to GPL Compliance" http://www.softwarefreedom.org/resources/2008/compliance-guide.html .. _"Open Design Prototype Board" http://opencores.org/projects.cgi/web/board/overview -- David Cary http://carybros.com/

We recently had a discussion about the GPL and LGPL license on
the OpenRisc mailing list as well. The consensus seems to be that
there is little known about how open source licenses should work for
hardware. Just the following snippet from the GPL FAQ over at
gnu.org is rather worrying:

Can I use the GPL to license hardware?

Any material that can be copyrighted can be licensed under the
GPL. GPLv3 can also be used to license materials covered by other
copyright-like laws, such as semiconductor masks. So, as an
example, you can release a drawing of a hardware design under the
GPL. However, if someone used that information to create physical
hardware, they would have no license obligations when
distributing or selling that device: it falls outside the scope
of copyright and thus the GPL itself.


/Andreas

Has this opinion been tested in the courts? It is not at all clear to me that hardware derived from an HDL is not subject to the same license as the HDL code. In essence, copyright restricts the copying and distribution of protected works in *any* form. If you transliterate VHDL to Verilog, it is still under the copyright of the original code. If you compile C code to machine language, it is still under the copyright of the original code. Am I wrong about this? If the above is correct, I would suggest that the embodiment of HDL IP in hardware is no different from compiling C code to produce machine language. I know the courts have ruled on hardware issues before, but I don't recall if the cases I have heard about related to actual IP as opposed to the architecture in general. In the general case hardware is protected by patent, but that is more restrictive than copyright. I can write my own program to do the same thing as Word without violating copyright, but I can't build my own ARM chip because it relies on hardware features that are patented. Does anyone know of court cases relating to copyright of IP as expressed in hardware? Rick At 03:14 PM 1/26/2009, ehliar at isy.liu.se wrote:

From: Jeremy Bennettjeremy.bennett at e...> Jeremy, Thanks for the lecture on licensing ;^) However, you're mailing list debate, it would seem, has come to some completely unfounded conclusions:

The GPL is clear enough to those of us who's professional career depend on it.
The accuracy of this is somewhat limited. If it's Your software, you can do as
you please, you only required to offer to distribute (and then if requested)...
But the sentiment is correct, yes.



However, this doesn't make any sense at all. Of course chip fab is publication
of the mask works, that's why you can see the big (C) on photomicrographs and
such of commercial devices. It is easily shown that there is a direct 1:1 mapping
relationship between C->binary that is identical HDL->layout. The obligations
clearly apply, this is what legal council has told real companies (SUN, Gaisler...)

The FSF has done many good things. When I choose licenses, I read and
understand them and I ignore common wisdom and ideology. There is no
"good reason" for choosing one license over another, just the correct license
for the situation. That's best determined by understanding, choosing, then
check confirm with legal.

Victor, Don't use the GPL. It's not what you want. Just put the license you want on the core. If "use for non-commercial purposes" is it, then so be it! There's nothing wrong with you choosing what license you want, but it would be a shame for you to be upset that the GPL doesn't do what you want and then to feel you were "ripped off". GPL is commercial agnostic, not a "better non-commercial" license. Entire large companies make their living on my GPL code. Seriously. ----- Original Message ----- From: Víctor Lópezvictor.lopez at o...> To: Date: Mon Jan 26 15:01:49 CET 2009 Subject: [oc] GPL License - again

On Tue, 2009-01-27 at 14:57 -0500, Rick Collins wrote:


Hi Rick,

I'm not aware of any legal prededent that accepts distribution of a chip
as publication of its design under copyright law. I'm not a lawyer, but
the legal opinion I have received is that copyright law does not apply
to manufactured silicon.



You've hit the nail on the head. ARM's IP is protected by patent law,
NOT copyright law. Copyright is free - in many countries it's automatic.
Patents cost money to obtain and need to be obtained under multiple
jurisdictions.

I'd be very interested to hear of any. Despite the work we've been doing here, no one has been able to find any precedent. Jeremy -- Tel: +44 (1202) 416955 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: jeremy.bennett at embecosm.com Web: www.embecosm.com

On Wed, 2009-01-28 at 09:29 +0100, djd328 at yahoo.com wrote: Hi djd328, You've raised a particularly interesting example with Aeroflex Gaisler. I believe you have some useful experience with their LEON processors. Gaisler offer their LEON processor with either LGPL/GPL licensing (free) or with a commercial license (for which you pay). If you pay for the commercial license, then you can incorporate the IP in a chip and keep it secret. It is particularly interesting that they changed from LGPL for LEON2 to GPL for LEON3. In this case the use of GPL increases the value of their commercial license over the free option (under GPL you would have to publish the *whole* chip, not just the LEON core). It's a good business model, because I can experiment to my heart's content for free, but if I decide to make a chip I can pay to keep it secret. Encourages users to try LEON as an option for their chip. However I still don't believe that LGPL/GPL properly protect hardware IP. The legal advice over masks (which are usually confidential between design house and fab) is contrary to all the advice we have received. Any more information about this would be good to hear. ATB, Jeremy -- Tel: +44 (1202) 416955 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: jeremy.bennett at embecosm.com Web: www.embecosm.com

On Wed, Jan 28, 2009 at 11:38:55AM +0000, Jeremy Bennett wrote:
This is unfortunately my understanding as well. Otherwise there would be no need to have a special law about so called "Mask Works". (See http://www.copyright.gov/circs/circ100.html for more information.) Secondly, I am not a lawyer. But lets move on anyway: * If you have a ROM which contain some sort of program it seems (to me) likely that copyright would still protect the contents of the ROM. (If not there would have been a huge amount of pirated video games during the eighties.) Assuming this is true designs that uses a lot of microcoded sequencers may be harder to copy without infringing an open source license. * If you are using an FPGA I would guess that the FPGA bitstream would also be protected by copyright. (If you are using an anti-fuse based FPGA things may not be quite as clear.) Incidentally, if a standard cell basic would not be protected by copyright, this may be a loophole in the GPL for software: * Step 0: Get hired by Microsoft * Step 1: Download all Debian files * Step 2: Create Microsoft/Linux, Microsoft/Firefox, Microsoft/Emacs, Microsoft/Perl, Microsoft/PostgreSQL, and Microsoft/GCC * Step 3: Create a good C/C++/Perl/LISP/etc to Verilog translator (The exact details are left as an exercise for the reader) * Step 4: Create a chip out of your design * Step 5: Laugh maniacally * Step 6: Profit? Oh, and the last idea is not really meant to be taken literary, but as C to hardware translators gain in capabilities this may eventually become a problem. /Andreas