On 05/14/2014 07:36 PM, Peter Gavin wrote: > On Wed, May 14, 2014 at 4:14 AM, Olof Kindgren <[email protected]>wrote: > >>> I second that, having a more permissive license on that file would >>> make a lot more sense. >>> You need that or a similar file in basically any software project >>> using OR1K, so all a too restrictive license do is prevent people from >>> using openrisc. >>> Unfortunately, that file has been composed by a large number of people >>> over the year, so I don't think we can change the license of _that_ >>> file without their permission. >>> Tracking people down just to get a non-gpl license on that file seems >>> like a lot of trouble though. >>> That's why I suggested on IRC to make a "cleanroom" version of it by >>> generating a new file from e.g. >>> https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx-sprs.v >> > > Ok, that's a good idea. I'll drop the copy I have and start from scratch. > But if I generate it with a script that reads that file, the result will > also be OHDL, right? Is that permissive enough?
A "cleanroom" implementation really needs to be done by someone who hasn't looked at spr-defs.h... ideally, ever, but at least in a _very_ long time. I'm pretty sure Peter is disqualified from doing this. That said, I think you're making a mountain of a molehill here. The license on that file is totally moot since using #defines from a header file does not count as a derived work. If you don't believe me, here are the prophet's own words: http://lkml.iu.edu//hypermail/linux/kernel/0301.1/0362.html Though I can't imagine hardly anybody cares about their copyright on a file that contains nothing but #defines, let's nonetheless say that's the case and keep the copyright(s) on it... BUT, just drop the license completely and put the file into the public domain because the license as-is is completely meaningless. ...and how different do we think this file is going to be after it has been regenerated, anyway...? /Jonas PS: Linux uses this file, too... noticed that you missed that in the earlier rundown of users. _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
