Discussion:
[OpenRISC] spr-defs.h
Peter Gavin
2014-05-13 22:16:05 UTC
Permalink
Hello list,

I've been thinking of consolidating the multiple copies of this header into
one place. The copies I'm aware of (there may be more) are:

or1ksim/testsuite/test-code-or1k/support/spr-defs.h
or1ksim/cpu/or1k/spr-defs.h
or1k-src/sim/testsuite/sim/or1k/spr-defs.h
or1k-src/newlib/libc/machine/or1k/include/spr-defs.h

I think the best way to do this is to make a new package (or1k-headers) and
put it into this package. The new package will have to be installed prior
to any other components of the toolchain.

I was also thinking of separating the NOP_* defines out from this header
into its own file, perhaps called or1k-nop.h. This file will also be in
the or1k-headers package.

And since I've brought it up, I wonder if the name "spr-defs.h" isn't
descriptive enough. Maybe "or1k-sprs.h" would be a better name for it?
And perhaps we can use the new name to help with migrating to the new
package. (I.e. if a package uses the old name, it hasn't been migrated
yet.)

Does anyone have any objections or other input?

-Pete
Sébastien Bourdeauducq
2014-05-14 07:20:05 UTC
Permalink
Post by Peter Gavin
Does anyone have any objections or other input?
I agree with consolidating and renaming. I suggest changing the license
to something more permissive than GPL, too: most embedded software
written for OR1K has to use that file.

Sébastien
Stefan Kristiansson
2014-05-14 07:59:58 UTC
Permalink
Post by Sébastien Bourdeauducq
Post by Peter Gavin
Does anyone have any objections or other input?
I agree with consolidating and renaming. I suggest changing the license
to something more permissive than GPL, too: most embedded software
written for OR1K has to use that file.
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

Stefan
Olof Kindgren
2014-05-14 08:14:34 UTC
Permalink
On Wed, May 14, 2014 at 9:59 AM, Stefan Kristiansson
Post by Stefan Kristiansson
Post by Sébastien Bourdeauducq
Post by Peter Gavin
Does anyone have any objections or other input?
I agree with consolidating and renaming. I suggest changing the license
to something more permissive than GPL, too: most embedded software
written for OR1K has to use that file.
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
Stefan
_______________________________________________
OpenRISC mailing list
http://lists.openrisc.net/listinfo/openrisc
Yes! I love this. Have had the same idea about a or1k-headers package
that everything else can depend on.

FYI we have two open bugs about this as well, so please put some info
there when things are starting to move
http://bugzilla.opencores.org/show_bug.cgi?id=58
http://bugzilla.opencores.org/show_bug.cgi?id=59

Also agree on using a BSD-style licensing for this file, and renaming
it to or1k-spr-defs.h or whatever

Do we have more files that could go in the header package?

//Olof
Jose Teixeira de Sousa
2014-05-14 09:50:55 UTC
Permalink
Fully agree.
Post by Olof Kindgren
On Wed, May 14, 2014 at 9:59 AM, Stefan Kristiansson
Post by Stefan Kristiansson
Post by Sébastien Bourdeauducq
Post by Peter Gavin
Does anyone have any objections or other input?
I agree with consolidating and renaming. I suggest changing the license
to something more permissive than GPL, too: most embedded software
written for OR1K has to use that file.
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
Stefan
_______________________________________________
OpenRISC mailing list
http://lists.openrisc.net/listinfo/openrisc
Yes! I love this. Have had the same idea about a or1k-headers package
that everything else can depend on.
FYI we have two open bugs about this as well, so please put some info
there when things are starting to move
http://bugzilla.opencores.org/show_bug.cgi?id=58
http://bugzilla.opencores.org/show_bug.cgi?id=59
Also agree on using a BSD-style licensing for this file, and renaming
it to or1k-spr-defs.h or whatever
Do we have more files that could go in the header package?
//Olof
_______________________________________________
OpenRISC mailing list
http://lists.openrisc.net/listinfo/openrisc
--
Jose T. de Sousa, PhD
Office: +351 213 100 213
R. Alves Redol 9
1000-029 Lisboa
Portugal
Peter Gavin
2014-05-14 17:36:06 UTC
Permalink
Post by Olof Kindgren
Post by Stefan Kristiansson
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?
Post by Olof Kindgren
Yes! I love this. Have had the same idea about a or1k-headers package
that everything else can depend on.
FYI we have two open bugs about this as well, so please put some info
there when things are starting to move
http://bugzilla.opencores.org/show_bug.cgi?id=58
http://bugzilla.opencores.org/show_bug.cgi?id=59
Also agree on using a BSD-style licensing for this file, and renaming
it to or1k-spr-defs.h or whatever
I think a 1-clause BSD license is appropriate. (See:
https://urchin.earth.li/~twic/The_Amazing_Disappearing_BSD_License.html)

I don't see any reason to restrict distribution of binaries compiled using
these headers, since the headers won't contain any function prototypes. I
only think it's important that the copyright notices on the source files
themselves are maintained.
Post by Olof Kindgren
Do we have more files that could go in the header package?
I'm also going to add or1k-asm.h, which I wrote, so changing the license is
simple.

-Pete
Jonas Bonn
2014-05-15 06:28:37 UTC
Permalink
Post by Peter Gavin
Post by Stefan Kristiansson
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.
Julius Baxter
2014-05-15 11:41:27 UTC
Permalink
Post by Peter Gavin
Post by Stefan Kristiansson
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?
Totally agree with this idea. Good stuff on taking the initiative.

If it's any help, as an author of that file (mor1kx-sprs.v), I'm happy
to re-license a copy for this purpose under anything you like. I'd bet
Stefan would also be willing.

Cheers

Julius

Loading...