[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC

On Sun, 9 Sep 2001, nicO wrote:

> Reichelt a écrit :
> > 
> > Hello.
> > 
> > At first I want to apologize for my comments, since I am lurker on this list,
> > with exception of some very few side remarks. But in my opinion the project of
> > Juergen Goeritz could be important to the f-cpu project. I am afraid that a
> > chance for funding might be given away without looking for a good solution which
> > could make evrybody happy.
> > 
> > The situation as I see it, is as follows:
> > Juergen Goeritz seems to be prepared to base a major development effort on the
> > f-cpu, which is not even completely defined yet (see discussion on "Dark and
> > dusty corners"). He is prepared to throw major resources at the f-cpu project.
> > He wants to protect his own development effort.
> > The key persons are not willing to switch to LGPL just for Juergen Goeritz.
> > 
> > Is it possible to draw a clear line where the f-cpu ends, and where the other
> > parts of Juergen Goeritz' SoC starts ? If that is possible, the f-cpu project
> > could offer a special license to Juergen Goeritz. He would be allowed to use the
> > f-cpu for his project, in exchange for contributions to the project to be
> > negotiated. Changes to the f-cpu itself arising from his project would be put
> > into the f-cpu, but the work on the rest of his SoC would remain his own. All
> > people contributing code would have to agree on this special license.
> > 
> > The situation would be similar to the mySQL license: If your code is GPL, it use
> > it for free; if you want it inside propriatory code, get a license. The GPL does
> > not preclude the author to give somebody an additional license.
> > 
> There is a problem to protect the design. So we use GPL but i want to
> speak to a lawyer to know what to do. There is a problem concerning the
> binaries/hardware issue of the licence. But the licence speak a lot
> about source code and VHDL or C, it's always source code.
> I don't know exactly where is the limit that Micheal want to put. but i
> know that he prefer design rather than thinking about licence issue.
> >From my point of view, i think that prorietary SoC should be possibly
> made with F-CPU code. Maybe we could use the IP sense of view from
> opencores.org. They have defined a "simple" Bus for SoC (Wishbones), so
> we could defined a fcpu component (IP?). So every thing inside this bloc
> is under GPL (or GPL like) the other part is what you want.
> nicO
> > Now the most important question:
> > Is a compromise along these lines ok, both for Juergen Goeritz and the key
> > people (whygee, Michael Riepe, nico, ...) ?
> > 
> > I hope this will trigger a discussion about a compromise


why go for a new bus? It may be a good idea to e.g. define
the f-cpu license from caches on (incl.). Everything inside
from caches on is protected. Which external memory interface,
which IO and which bus to use would be free for implementor

In return anybody using the f-cpu in a chip could be asked
to develop a part of the f-cpu or do a 'donation' to the
development team or a 'fee' for public registration of the
f-cpu ID or whatever.

What's your opinion?

P.S. In my opinion the GPL license has a big drawback when
you add own components on the netlist level. My standpoint
is that this is the weak point. A netlist is comparable to
'.o' files or libraries (vendor macro instantiations like
gates are connected to each other in the netlist). Good
people can write and modify netlists directly. Netlists
mostly are produced by proprietary tools, e.g. synthesis.
When you follow this thought you end up with a system
around the f-cpu that is completely outside the license
coverage because libraries and operating systems (or the
chip - in my thought) are not covered.

To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/