Re: [oc] RE: [pci] PCI core ( LICENSING )

[Johan Klockars <johan@klockars.net>]

> There's a difference here between software (as in software programs) and 
> hardware (as in chips, ICs).

Obviously.

> It is perfectly fine to use a piece of GPL software in a proprietary system. 
> You link the GPL based piece to a dynamic linkable library and your 
> proprietary code uses it. No harm done, no licenses violated.

Uhm. No. You can't do that to 'get around' the GPL.
The LGPL, however, is intended for just such things.

You can find the following at
http://www.gnu.org/licenses/gpl-faq.html#WhatDoesGPLStandFor:

"If a library is released under the GPL (not the LGPL), does that mean
 that any program which uses it has to be under the GPL?"

  "Yes, because the program as it is actually run includes the library."

> For hardware the story is different. If we want to push the usage of a core, 
> let's say the OR1200, then we need to get it out of the 'everything should be 
> for free' utopia and get it used in some real designs. Everybody seems to 

GPL is not about 'everything should be for free', although that is a
common misconception.

>From 'The Free Software Definition' (at www.gnu.org):

  ``Free software'' is a matter of liberty, not price. To understand the
  concept, you should think of ``free'' as in ``free speech,'' not as in
  ``free beer.''

  Free software is a matter of the users' freedom to run, copy,
  distribute, study, change and improve the software. More precisely, it
  refers to four kinds of freedom, for the users of the software:

    * The freedom to run the program, for any purpose (freedom 0).
    * The freedom to study how the program works, and adapt it to your
      needs (freedom 1). Access to the source code is a precondition for
      this.
    * The freedom to redistribute copies so you can help your neighbor
      (freedom 2).
    * The freedom to improve the program, and release your improvements
      to the public, so that the whole community benefits (freedom 3).
      Access to the source code is a precondition for this.

> Yes, however most of us (maybe not you) would read that a derived work is 
> something where you take a core from opencores. Modify the core and then use 
> it. However if you take a core as is, you do not modify the core, but you use 
> it in a system than I would say it should not be a derived work.

What you or I say is not relevant. The following is from the LGPL:

5. A program that contains no derivative of any portion of the Library,
   but is designed to work with the Library by being compiled or linked
   with it, is called a "work that uses the Library". Such a work, in
   isolation, is not a derivative work of the Library, and therefore
   falls outside the scope of this License.

   However, linking a "work that uses the Library" with the Library
   creates an executable that is a derivative of the Library (because it
   contains portions of the Library), rather than a "work that uses the
   library". The executable is therefore covered by this License.
   Section 6 states terms for distribution of such executables.

Quite clear regarding this case, I would say.

> > > eCos faced the same problem. In eCos 2.0 they slightly modified the
> > > license and disclaimer header (see below)

Actually, they started out with a non-GPL license and wanted to be
GPL-compatible.

> > To me it looked like that was a clarification regarding a header file
> > and not actual code, but I don't know the details of this.
> 
> Read the exception. It clearly says that any modifications to the GPLed source 
> code most be opened. But that linking the GPLed code with proprietary code 
> doesn't enforce you to open you proprietary code too.

The first statements about template instantiation and such led me to
believe that it was only for headers, but it appears you are indeed
correct.

> > If you do this kind of thing for actual code, it would nullify the
> > whole reason for the GPL, IMHO.
> 
> Do you still think that everything is for free??

What I think has nothing to do with what the GPL says.
For that matter, you can certainly sell stuff that is GPLed, you just
can't take away the user's freedom to modify the software (or to give
it away to someone else).

> If you design a chip that's supposed to knock your competition out, you spend 
> a few million dollars on it, than I would consider that at least 
> confidential. So the next step to take is to provide the source code to 
> everyone because you used a GPLed core from opencores? I don't think so.

You would not have been allowed to use the GPLed core unless you
put the rest of your work under the GPL as well. End of story.

No one is forcing you to use GPL licensed parts in your project. You
are certainly always free to do everything yourself (or buy it).

> > The idea is to preserve the freedom of the user, not to enable
> > anyone to use whatever code they want in proprietary software (or
> > hardware, in this case).
> 
> Freedom of the user in what? I would say freedom of the designer. If you 
> really believe that everything should be opened, go for the GPL licenses. If 

Again, we were discussing the GPL and what I say above applies to that.

> you think that any modification to the free cores should be opened, but not 
> any proprietary code hanging around in the chip somewhere, then add the 
> exception.

A quick look around the net seems to suggest that no one is taking
exception to the eCOS modification of the GPL license. It is even
officially listed as a GPL-compatible license.

There's still the problem with the software related terms in the 
license, though, which make things unclear.
Perhaps an addendum of some kind could take care of that.

> > I'm not saying that making cores available that anyone can use, as long
> > as they contribute their improvements to the public, is a bad idea.
> 
> I thought that's exactly what we're doing here.

I've never taken issue with what OpenCores is about. I've only been
talking about what the GPL and LGPL licenses say.

> > Just that it is not what the GPL is about and that, thus, trying to
> > base such a license on the GPL is not a good idea (if it's even
> > possible, which seems unlikely).
> 
> Well it is. eCos 2.0 uses the license as described.

Apparently.

-- 
                        | Why are these |  e-mail:   johan@klockars.net
                        |  .signatures  |
                        | so hard to do |  WWW:      http://www.klockars.net
                        |     well?     |            (fVDI, MGIFv5, QLem)
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml