[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: [oc] GNU LGPL license
> I agree with Graham that the Design Science License
> may be a good starting point, and it appears that
> it is quite consistent with the spirit of opencores
> (I am no expert on such licenses, but I have read
> through the DSL).
>
> As an example, Reinoud Lamberts has released
> his "MPGA" core under the Design Science License
> http://ce.et.tudelft.nl/~reinoud/mpga/README.html
> At the bottom of this page he notes:
> "The DSL is a generalised GPL, covering more
> than just software".
I read the license. Here's an opencores' view of the license explanation:
1) Definitions
"License": the words that make up the DSL
"Work": OpenCores IP core and the derivates from the original IP core.
"Object Form": For an IP core this would be a netlist or similar.
"Source Data": The sources in whatever language, including synthesis &
simulations scripts, datafiles, testbenches etc.
comments: So far so good. Sounds like it covers everything there is to cover.
Though one might argue that "all derivates from the original IP core" could
also mean the costumers own IP cores. Which brings us back the original LGPL
problem.
2) Rights and Copyright
The original author holds the copyright.
The user may use and reference the original unmodified work as you would
normally reference copyrighted works.
comments: This places a limit on the useability. The license explicity claims
the same rights as for any material under copyright law. This makes it not
completely open. Any references, other than educational purposes for example,
are only legal with the prior written agreement of the original author.
Though I would like to see credit for my work, if used by others, I don't
want to give written permission to everybody. In my opinion an ideal license
would state that referencing the work is permitted, as long as the author of
the work is credited as in something like: "Partially taken from ...." or a
real reference like in scientific works like: "[Refxx]: OpenCores
MicroIPcore, 2002 Author1, Author2". These are, of course, just examples.
3) Copying and Distribution
Copying the Source Data is allowed, as long as the copyright notice &
disclaimer is clearly printed on all copies. And a copy of the license is
provided.
Distributing the Object Form (netlist) is allowed, as long as the copyright
notice & disclaimer is clearly printed on all copies. And a copy of the
license is provided. And
a) The Source Data is included (under the DSL) or
b) A written offer, valid for at least three years or the lifetime of the
distribution, is included stating that the Source Data is available for free
(postage not included) from a public accessable address (for example the
internet)
c) A third parties written offer to provide b
Aggregating the Work with other works does not bring the other works in the
scope of the license.
Comments:
1) Any storage the costumer or whoever has of the core needs to print the
copyright and disclaimer on it and add the license to it. OK, can be good,
can lead to strange things. Imagine building a SoC from OpenCores and storing
the source files on a floppy disk. Where would you print all the copyright
and disclaimer notices ???
2) Distributing the Object Form. This would be when an ASIC netlist is sent
to the chipmaker. The license requires that
a) either the original source code is included (does this make the chipmaker
happy ??) or
b) the costumer provides a written guarantee that it will provide the source
code, for at least three years or as long as the costumers chip is available,
for free
c) somebody else (probably opencores) provides a written guarantee that it
will provide the source code, for at least three years or as long as the
costumers chip is available, for free
Is anyone of you going to sign such an agreement (I am not)
3) Aggregation: Any proprietary IP core linked with the Work will not enforce
the company to provide the sources for the proprietary core. This is good.
And clarifies the comment on section 1 Definitions
4) Modification
It is allowed to modify the ip core, or to take parts from it to produce a
new ip core (the derivative work). The derivative work may be distributed
when:
a) The derivative work is published under the DSL license
b) The derivative work is given a new name
c) The original author is credited for his work. Any changes are copyrighted
to the changee. A changelist needs to be included.
Comments:
1) It is not stated that changes (like bugfixes) must be returned. Stated is
that the derivative work MAY be distributed.
2) If the derived work is distributed, than the changes MUST be made public,
but the ip core must be given a new name !!! This leads to a wildgrow of
cores, because every bugfix by somebody else but the original author leads to
a new ip core.
3) Change log is handled by CVS, no problems here.
5) Restrictions
It is not allowed to change the restrictions on the work other than stated in
the license.
Comment: An addendum to the license is out of the question
6,7,8) Acceptance, NO WARRANTY, DISCLAIMER
The usual legal protective blabla. Damn american lawyers.
In my honest opinion this license is even worse than LGPL. It is perfectly
suited for it's intended purpose; Scientific Research. But it is unsuited for
our purposes.
Richard
>
> Best regards
> Tony Burch
> http://www.BurchED.com
> Low cost FPGA boards, for System-On-Chip
> prototyping and education
>
> ----- Original Message -----
> From: "Graham Seaman" <graham@seul.org>
> To: <cores@opencores.org>
> Sent: Friday, 26 April 2002 7:56
> Subject: Re: Re: [oc] GNU LGPL license
>
> > On Fri, 26 Apr 2002, Damjan Lampret wrote:
> > > core free and not require any changes to come back to the community. I
> > > checked the GNU page John suggested and GNU LGPL is the closest to want
> > > I'd like from a license. Now what? Should we modify GNU LGPL to better
> > > fit hardware?
> >
> > If you were going to do this, might a better starting point be the design
> > science license (http://www.dsl.org/copyleft/dsl.txt)? This has the
> > advantages that a) it is (IIRC) recognised as compatible with FSF
> > licences, and listed as such on the FSF pages; b) it doesn't have all
> > the software-specific content the gpl/lgpl have, c) it is already
> > occasionally used for hardware designs, and d) it is short.
> >
> > I'm not clear enough about whether it would need to be changed to be more
> > lgpl than gpl like; if you did need to create a 'lgpl-ish' version, you
> > could offer the new version back to the design science site and maybe
> > see if the FSF would also approve your version?
> >
> > Graham
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml