I've just written up some first-draft GPL- and LGPL-derived licenses. I won't wade too deeply into the "how reciprocal should your license be?" argument other than to say that I personally like the free software philosophy enough that I'd like a good GPL-like license option to exist.
The proposed licenses are at the URLs below, and I'd appreciate any comments anyone might have. https://github.com/ewa/free-hdl-license/wiki/GPL-like-license https://github.com/ewa/free-hdl-license/wiki/GNU-LGPL-like-License Thanks, Eric On 12/07/2011 01:26 PM, Julius Baxter wrote: > On Wed, Dec 7, 2011 at 5:51 PM, Bruce Perens <[email protected]> wrote: >> On 12/07/2011 07:33 AM, Julius Baxter wrote: >> >> The main reason why I think there's problems with having the license apply >> (become viral) to anything instantiated within in it is due to the fact that >> synthesis tools will often instantiate blocks within the design at synthesis >> and then reproduce source for it, such as a gatelevel netlist. Of course >> there's no way anyone would want to ask their technology library vendor to >> release those things under the open source license. >> >> >> You don't have to throw out reciprocal licensing (don't call it "viral", >> that's pejorative) because of the synthesis issue at all. An example of how >> you get around it is the compiler exception in the GPL. Taken from the GPL2 >> text: > > Hi Bruce, > > Thanks for the suggestion. I agree, viral is a rather pejorative term > and I probably shouldn't be using it when discussing licensing issues. > >> >> as a special exception, the source code distributed need not include >> anything that is normally distributed (in either source or binary form) with >> the major components (compiler, kernel, and so on) of the operating system >> on which the executable runs, unless that component itself accompanies the >> executable. > > To be a little bit pedantic first, I'm not sure this is analogous to > the situation you're in when synthesising RTL for a particular > technology. I would say the closest analogy to FPGA is to compiling > software to run on the bare metal of a computer - you could argue the > FPGA configuration binary "runs" on the FPGA in the same way that > binary software manipulates the control and datapath signals of a CPU. > For ASIC, however, we're dealing with something entirely different > when it gets to a distributable form (ie. is manufactured) and I'm not > sure something like this compiler exception could apply at all. > > I worry that the point of a reciprocal license, bounded by the module, > could be interpreted as applying to the IP of anything that is > auto-instantiated by the synthesis tools. I take your point that you > can explicitly state that such things are excepted, but what happens > in the case where you're working around a bug in the synthesis tool > and manually instantiating technology-specific cells inside your > design? In a lot of cases you must manually instantiate your target > technology's RAM blocks in your source (or route all of the signals > out to the module boundary - not a pleasant task.) So I feel strongly > reciprocal licenses will never be abided by users of open hardware > source. > >> >> It would be simple enough to create an exception of this form for compilers >> that synthesize VLSI elements for the purpose of creating a working device >> from the source code. >> >> Thanks >> >> Bruce > > Cheers, > > Julius > _______________________________________________ > Openrisc mailing list > [email protected] > http://lists.opencores.org/listinfo/openrisc -- Eric W. Anderson Electrical and Computer Engineering [email protected] Carnegie Mellon University phone: +1-412-268-1908 Roberts Hall 244 PGP key fingerprint: D3C5 D6FF EDED 9F1F C36D 53A3 74B7 53A6 3C74 5F12
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
