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

[Richard Herveille <richard@asics.ws>]

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

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.

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 
agree that opencores is a great idea. But without the support of the 
industrie it will never grow out of the student/amateur area. Shoot me if I 
am wrong.


> > Problem with the GPL style license are the terms 'linked' and 'derived
> > work'. We all UNDERSTAND that somebody who uses an OpenCores core in a
> > proprietary project does NOT have to open their proprietary core. Problem
> > is that in fact
>
> I would not say that there is such an understanding, since some of the
> OpenCores projects are under licenses that do not say this.

I am only speaking about the cores that use GPL style licenses. I know there 
are cores that use a different type.


> Of course, it's possible that the people who put their cores under those
> licenses did not understand what they were doing, but you can't assume
> that.

We have discussions about licenses ever so often. We know there are problems 
with the GPL style licenses that keep companies from using cores that are 
based on them.


> > the OpenCores core and the proprietary cores are 'linked' together to
> > form one netlist. Someone then might argue that the entire project is a
> > 'derived work' from the OpenCores core and that the entire work needs to
> > be opened. We
>
> It would be hard to argue against it, I would think.
> That's what 'derived work' in the (L)GPL sense means.

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.


> > eCos faced the same problem. In eCos 2.0 they slightly modified the
> > license and disclaimer header (see below)
>
> ....
>
> > Interresting here is the exception clause. This is exactly what we want.
> > I therefore suggest adding this exception clause to all cores using a GPL
> > style license.
>
> 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.


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


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


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


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



--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml