volk: Start relicense GREP #33

jdemel · 2021-03-18T19:25:32Z

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

grep-00XX-relicense-volk.md

marcusmueller · 2021-03-18T19:38:51Z

grep-00XX-relicense-volk.md

+
+### 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.


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?

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.

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?

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.

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.

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 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

marcusmueller · 2021-03-18T19:43:56Z

grep-00XX-relicense-volk.md

+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.


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?

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?

I definitely wouldn't do this within the 2.x line.

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.

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.

grep-00XX-relicense-volk.md

marcusmueller · 2021-03-18T19:47:11Z

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.

jdemel · 2021-03-18T21:49:17Z

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

bhilburn · 2021-03-19T15:14:17Z

grep-00XX-relicense-volk.md

+
+### 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.


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?

grep-00XX-relicense-volk.md

marcusmueller · 2021-03-20T18:08:35Z

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!)

jdemel · 2021-03-20T18:46:46Z

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?

mbr0wn

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

mbr0wn · 2021-03-30T17:24:36Z

grep-00XX-relicense-volk.md

+
+### 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.


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

mbr0wn · 2021-03-30T17:27:23Z

grep-00XX-relicense-volk.md

+
+### 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.


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.

grep-00XX-relicense-volk.md

mbr0wn · 2021-03-30T17:35:37Z

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'm still in favour of VORK.

mbr0wn · 2021-03-30T17:44:18Z

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.

mbr0wn · 2021-03-30T17:57:42Z

@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?

dkozel · 2021-04-01T11:14:49Z

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.

Occasionally, a GNU library may provide functionality which is already widely available to proprietary programs through alternative implementations; for example, the GNU C Library. In such cases, the Lesser GPL should be used

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.

bhilburn · 2021-04-03T02:56:48Z

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.

Perhaps someone from SRS would be willing to step-in, here?

@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?

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'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 meant renaming, but I wasn't referring to the project, but rather the name master for the primary branch.

mbr0wn · 2021-06-08T14:50:35Z

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.

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).

marcusmueller · 2021-06-08T18:03:45Z

@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.

marcusmueller · 2021-06-08T18:05:22Z

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.

mbr0wn · 2021-06-09T06:34:44Z

@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.

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".

mbr0wn

@jdemel we should remove all hypotheticals/ambiguities before finalizing. That includes all usages of "should", "might", and so on.

grep-00XX-relicense-volk.md

jdemel · 2021-08-28T12:41:29Z

I just updated the GREP. I hope I caught all the hypothetical statements and replaced these with a clear path forward.

grep-00XX-relicense-volk.md

mbr0wn

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

mbr0wn · 2021-08-30T09:33:52Z

grep-00XX-relicense-volk.md

+    - 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. 


Suggested change

- 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.

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.

agreed with @mbr0wn here

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?

grep-00XX-relicense-volk.md

michaelld

still a few changes needed IMHO ... almost there!

grep-00XX-relicense-volk.md

michaelld · 2021-08-30T14:08:52Z

grep-00XX-relicense-volk.md

+    - 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. 


agreed with @mbr0wn here

michaelld · 2021-08-30T14:12:26Z

grep-00XX-relicense-volk.md

+
+### 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.


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.

mbr0wn · 2021-08-31T12:59:36Z

I wrote this a while ago, it's not quite up to date with what @jdemel added recently, but if you want to take some text blocks be my guest: dabc3e9

It explains the re-submission part.

jdemel · 2021-08-31T19:32:30Z

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.

mbr0wn · 2021-09-01T09:51:40Z

Please use my email draft however suits your need. You can also put the email draft into this GREP PR for reviews from others.

michaelld

LGTM ; let's do this!

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>

dkozel · 2021-09-29T13:25:53Z

The commits are squashed and the GREP number updated to 23. Thanks to everyone for making this happen!

marcusmueller reviewed Mar 18, 2021

View reviewed changes

bhilburn reviewed Mar 19, 2021

View reviewed changes

mbr0wn reviewed Mar 30, 2021

View reviewed changes

mbr0wn reviewed Aug 25, 2021

View reviewed changes

grep-00XX-relicense-volk.md Outdated Show resolved Hide resolved

grep-00XX-relicense-volk.md Outdated Show resolved Hide resolved

mbr0wn reviewed Aug 30, 2021

View reviewed changes

grep-00XX-relicense-volk.md Outdated Show resolved Hide resolved

mbr0wn approved these changes Aug 30, 2021

View reviewed changes

marcusmueller reviewed Aug 30, 2021

View reviewed changes

grep-00XX-relicense-volk.md Outdated Show resolved Hide resolved

marcusmueller approved these changes Aug 30, 2021

View reviewed changes

michaelld requested changes Aug 30, 2021

View reviewed changes

michaelld approved these changes Sep 5, 2021

View reviewed changes

dkozel approved these changes Sep 29, 2021

View reviewed changes

jdemel force-pushed the relicense-volk branch from 01e8e1b to e250457 Compare September 29, 2021 13:21

volk: Add GREP to re-license VOLK under LGPL

f744334

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>

jdemel force-pushed the relicense-volk branch from e250457 to f744334 Compare September 29, 2021 13:24

dkozel merged commit 4feae6f into gnuradio:master Sep 29, 2021

		- 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.

volk: Start relicense GREP #33

volk: Start relicense GREP #33

Conversation

jdemel commented Mar 18, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bhilburn Mar 19, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marcusmueller commented Mar 18, 2021

jdemel commented Mar 18, 2021

bhilburn Mar 19, 2021 • edited

Choose a reason for hiding this comment

marcusmueller commented Mar 20, 2021

jdemel commented Mar 20, 2021

mbr0wn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mbr0wn commented Mar 30, 2021

mbr0wn commented Mar 30, 2021

mbr0wn commented Mar 30, 2021

dkozel commented Apr 1, 2021

bhilburn commented Apr 3, 2021

mbr0wn commented Jun 8, 2021

marcusmueller commented Jun 8, 2021

marcusmueller commented Jun 8, 2021

mbr0wn commented Jun 9, 2021

mbr0wn left a comment

Choose a reason for hiding this comment

jdemel commented Aug 28, 2021

mbr0wn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michaelld left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mbr0wn commented Aug 31, 2021

jdemel commented Aug 31, 2021

mbr0wn commented Sep 1, 2021

michaelld left a comment

Choose a reason for hiding this comment

dkozel commented Sep 29, 2021

bhilburn Mar 19, 2021 •

edited

bhilburn Mar 19, 2021 •

edited