-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
volk: Start relicense GREP #33
Conversation
grep-00XX-relicense-volk.md
Outdated
|
||
### The meantime | ||
It might take time to gain approval by every contributor. | ||
We want to be able to continue VOLK development while we are in this license transition period. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does that entail a CMake flag that disables all non-permissive code, so that people can actually use the parts of VOLK that are already available under non-strong-copyleft terms?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the transition period is, e.g. a month, I'd argue it is more sensible to wait for enough approvals. If it was a year or so, this might justify the additional work with a CMake flag. I'd really like to avoid that though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is going to take a while.
That said, I'm also not sure it's worth trying to split the distribution to have GPL and non-GPL builds? That seems like it would be really hard to manage. You could do something like gradually update everything as you get new code & relicenses, and then swap the whole thing over to a completely non-GPL distro in an atomic commit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated the text here to be more precise.
I have no idea how long things will take. I just hope it won't take too long.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it'll take a while to get everyone's approval, but it might not take too long to get a few core contributor's approval sooner. That would give us a good core to build upon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the stragglers, and those who don't want to relicense, I think it's the right way to nuke those kernels or contributions. If people need them, they can contribute new versions thereof.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it'll take a month to get the vast majority of contributors in place; there'll be a long tail for another 95% & some just never will. I agree @mbr0wn that we need to be willing and able to remove kernels for folks who do not agree after some amount of time -- 2 months maybe -- so as to allow for VOLK development to move forward without splitting releases between GPL and LGPL versions ... which I think will be a PITA.
grep-00XX-relicense-volk.md
Outdated
Either, we decide to give up on this relicensing effort or, we are required to remove all contributions by that contributor. | ||
Though, we hope to avoid this situation. | ||
Yet, we need to define a final date by which we will end the transition period. | ||
Otherwise, we risk to stay in relicensing limbo. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe say that you'll also want to do a major release at that point, simply to make that distinction easy for consumers of the library. E.g., if you've got non-GPL code that wants to use VOLK, find_package(VOLK, >=14.0)
, simple as that.
Maybe defining a "last version number that also includes optionally enabled GPL kernels" is better than a date?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First, I thought, we'd bump this to a new major version number. This might be the case if we need to drop kernels entirely. Otherwise, I'd probably like to stick with the VOLK 2.x line.
How does a license change work with packaging? @maitbot Do we need to consider anything here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I definitely wouldn't do this within the 2.x line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe defining a "last version number that also includes optionally enabled GPL kernels" is better than a date?
A date still works if we require all contributions to any VOLK branch to be LGPL, or relicensable under LGPL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really don't have an idea how long it'll take for most contributors to react to such an email and take action. Based on our experience after a short while, we can make a good statement.
Alternatively, we can set a date e.g. 2 months into the future. Then we follow the best academia tradition and extend this deadline.
I'd honestly like someone from industry to co-champion this, someone who's actively committing their instead of your time to getting this done. |
I hope to spark some interest and hopefully some participation from that direction with this GREP. e.g. now you could point people to this GREP. |
grep-00XX-relicense-volk.md
Outdated
|
||
### The meantime | ||
It might take time to gain approval by every contributor. | ||
We want to be able to continue VOLK development while we are in this license transition period. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is going to take a while.
That said, I'm also not sure it's worth trying to split the distribution to have GPL and non-GPL builds? That seems like it would be really hard to manage. You could do something like gradually update everything as you get new code & relicenses, and then swap the whole thing over to a completely non-GPL distro in an atomic commit?
If we're going for renaming, I'd recommend "reserving" a name early on (and for what it's worth, I like the wolf imagery; maybe just pick a different language than English and find a bacronym for "wolf" in that language. Loup already shares 3 of 4 letters of VOLK!) |
I assume @bhilburn renaming comment refers to "rename default branch" rather than "rename VOLK", correct? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to suggest a radical approach. Something like this:
- You tag your final 2.X release
- You branch for the upcoming 3.X release.
- On this new branch, the first thing you do is nuke everything.
git rm -rf * && git commit -a -m "Removing all GPL-licensed code"
. - Then, you add a file called
RELICENSING.md
or something like that. This is where people add their names. - As you collect names, you can merge stuff over from the 2.X branch. I would assume that 20%-ish of the developers wrote 80% of the code, and those devs are also most likely to respond. People like Nathan W., Nick M., and so on. As you merge from the other branch, make sure to commit stuff with the right SPDX header.
- You can of course also create a side-branch that's empty (rather than make it the new main branch) and collect some names first.
- On the older 2.X branch, you amend the license, stating that all new contributions come in under the LGPL. This doesn't change the license of the 2.X branch, but it allows using commits for both the new and the old branch.
grep-00XX-relicense-volk.md
Outdated
|
||
### The meantime | ||
It might take time to gain approval by every contributor. | ||
We want to be able to continue VOLK development while we are in this license transition period. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it'll take a while to get everyone's approval, but it might not take too long to get a few core contributor's approval sooner. That would give us a good core to build upon.
grep-00XX-relicense-volk.md
Outdated
|
||
### The meantime | ||
It might take time to gain approval by every contributor. | ||
We want to be able to continue VOLK development while we are in this license transition period. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the stragglers, and those who don't want to relicense, I think it's the right way to nuke those kernels or contributions. If people need them, they can contribute new versions thereof.
I'm still in favour of VORK. |
To amend my comment, and also, it seems like @bhilburn wrote something similar: If we stop active development of the 2.X GPL version, and move to a 3.X LGPL version, that also incentivizes people to relicense. |
@bhilburn You mentioned a while back that tiny, trivial changes could be relicensed without the author's permission? Like, when there's only one obvious way to change something and it's a small change? |
I'm nearly positive that @bhilburn meant "removing" not "renaming" in his comment as the referenced area of text is about removing all non-LGPL code at the transition. Ben please confirm? I see little reason to rename the project. I think the reasonings given for the relicensing are good. There's also useful guidance from the GNU Project about this that can be referenced.
https://www.gnu.org/prep/maintain/maintain.html#Licensing-of-GNU-Packages I think it is honest to say that there are now a variety of other non-copyleft SIMD accelerated math libraries around that are currently used in similar application spaces. I strongly think that 2.x GPL, 3.x LGPL is the least chaotic way of making the transition clear. If someone wants to submit GPL only code to 2.x that's up to the VOLK maintainers to decide about, but backports from 3.x to 2.x would need explicit statements from the code contributor that they're submitting under both licenses. |
Perhaps someone from SRS would be willing to step-in, here?
Correct. Generally, small changes, and changesets where what's being implemented can realistically can only be done with a single approach (there's no room for creativity / difference in implementations), are not protected by copyright.
I meant |
Industry involvement rarely comes through this path. Instead, a carrot-and-stick approach is often more effective. In this case, I would suggest some hard deadlines and consequences. If we can get a small number of core developers to agree to re-license, we'll have enough material for a LGPL 3.0 version of VOLK, but it might have fewer kernels. The hard work is then to get the rest of those kernels ported. That's when you can enlist help: "Oh, you were relying on those kernels? Well, here's how you can help...". At the same time, we severely reduce support for VOLK 2 to make it clear we are serious about this. Ideally, GNU Radio in the future could make its minimum VOLK version 3.0 to drive that point home further. People who need VOLK will now have a good incentive to help porting (or rewriting, where necessary). At the same time (:carrot:) we also have a more palatable license (for some folks, there are other folks who don't care). |
@mbr0wn Agreed, an "adopt the kernels you care about" might be a good approach. Also, potentially, putting the logos of those who adopted a kernel on the website might be cool for them. |
Plus, honestly, we've got enough architectural bugs that VOLK 3.0 is kind of inevitable. And we've got enough kernels that are already LGPL or easy-to-get-agreement to start fixing them today in a clean slate branch. |
Hehe, I love this. It reminds me of the petting zoo we take the kids, where it says "this chipmunk was adopted by the local bakery". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jdemel we should remove all hypotheticals/ambiguities before finalizing. That includes all usages of "should", "might", and so on.
I just updated the GREP. I hope I caught all the hypothetical statements and replaced these with a clear path forward. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great. I feel strongly about adding all sorts of easy ways to sign, and would request adding more options (see suggestion). Also, one typo. Otherwise, I'm all 👍 👍 👍
grep-00XX-relicense-volk.md
Outdated
- Open a PR against the VOLK repository and add themself to the list. | ||
- Write an email to the current VOLK maintainers that clearly states the required author information. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Open a PR against the VOLK repository and add themself to the list. | |
- Write an email to the current VOLK maintainers that clearly states the required author information. | |
- Open a PR against the VOLK repository and add themself to the list. | |
- Write an email to the current VOLK maintainers that clearly states the required author information. | |
- Add a line saying they agree to a public GitHub issue. | |
- Sign a paper form and make it available to us. This is generally cumbersome, but can be a useful method at events where people are available in-person. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rationale: We should make it as easily as humanly possible to resubmit. If we only get a developers attention for 30 seconds, those need to suffice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed with @mbr0wn here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. I just added it. We'd need to figure out who'd be in charge of storing them though. Would this be a SETI thing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
still a few changes needed IMHO ... almost there!
grep-00XX-relicense-volk.md
Outdated
- Open a PR against the VOLK repository and add themself to the list. | ||
- Write an email to the current VOLK maintainers that clearly states the required author information. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed with @mbr0wn here
grep-00XX-relicense-volk.md
Outdated
|
||
### The meantime | ||
It might take time to gain approval by every contributor. | ||
We want to be able to continue VOLK development while we are in this license transition period. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it'll take a month to get the vast majority of contributors in place; there'll be a long tail for another 95% & some just never will. I agree @mbr0wn that we need to be willing and able to remove kernels for folks who do not agree after some amount of time -- 2 months maybe -- so as to allow for VOLK development to move forward without splitting releases between GPL and LGPL versions ... which I think will be a PITA.
Thanks for all your comments. I updated the PR accordingly. @mbr0wn I'd like to use your email draft to write an email to all contributors and open a PR for our re-licensing effort. The PR can serve as a the mentioned issue for contributors to express their wish to resubmit their code. |
Please use my email draft however suits your need. You can also put the email draft into this GREP PR for reviews from others. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM ; let's do this!
01e8e1b
to
e250457
Compare
This GREP suggests to re-license VOLK under LGPLv3+. The details and reasons are discussed in the GREP. Co-authored-by: Martin Braun <martin@gnuradio.org> Signed-off-by: Johannes Demel <demel@uni-bremen.de>
e250457
to
f744334
Compare
The commits are squashed and the GREP number updated to 23. Thanks to everyone for making this happen! |
This is the initial draft to discuss a possible transition to a new license for VOLK.
I'd like feedback and especially contributions to improve this draft. I just add a few people here to notify them of this GREP.
@michaelld, @bhilburn, @osh, @n-west, @mbr0wn, @marcusmueller, @mormj