search

containers / composefs

The reliability of disk images, the flexibility of files
Other
461 stars 36 forks source link

request to relicense CLI tooling from GPLv3 -> dual `GPL-2.0-or-later OR Apache-2.0` #344

Closed cgwalters closed 1 month ago

cgwalters commented 2 months ago

This is a request to relicense all code in this repository under a dual license: GPL-2.0-or-later OR Apache-2.0 (edit: Clarified from ~GPLv2+ OR ASL2.0~ using the SPDX terms).

Current analysis shows the following users have contributed; I will update this tracker:

Gathered via this script:

git log --merges --pretty=format:'%h %s (%ae)' --full-history -- libcomposefs tools  | sed -e 's,.*from \([-A-Za-z0-9]*\)/.*,\1,' | /bin/sort -u

Users with not-small contributions: @eriksjolund @wahtari @jluebbe @rborn-tx @KatrinJo Smaller sized contributions (1-3 lines) that touch C code: @fboudra @ffontaine @nekopsykose @allisonkarlitskaya Smaller sized non-C contributions: @bfallik @wjt

Since I can't ping people necessarily who don't have write access here I'll also go to representative PRs and reuse those as a communication channel.

Original obsolete issue text:

Today we have 3 licenses, see https://github.com/containers/composefs/commit/4eaa74f7bae91ee91398503aff209861beca7433 ~Right now it's just the CLI tools that are licensed under the GPLv3. The request here is to drop this license from our matrix and relicense the CLI tools as well under LGPLv2+ to just simplify our licensing story.~ At the current time, @alexlarsson and @giuseppe wrote 90% of the initial code there. Any objections?
giuseppe commented 2 months ago

no, I am fine to relicense to LGPLv2+

alexlarsson commented 2 months ago

No objections here.

jberkus commented 2 months ago

Just to be accurate: you currently have 6 licenses.

cgwalters commented 2 months ago

OK, the question came up...why not ASL2.0? Today erofs is dual licensed under GPLv2+ and ASL for the library https://github.com/erofs/erofs-utils/blob/dev/COPYING - and I'm pretty sure some of the logic in our code I think was almost certainly derived from that. So we could follow that pattern instead - but I would say for just the entire codebase because IMO having two licenses for the binary vs the library just makes everything a lot more confusing, especially sharing code between the two happens a lot naturally.

So :+1: if you'd prefer dual GPLv2+ OR ASL2.0 here

cgwalters commented 2 months ago

The question came up: why not LGPLv2+ OR ASL2.0? I guess in the end, it doesn't really matter to the best of my knowledge. I think the argument that erofs-utils is already using GPLv2+ OR ASL2.0+ carries the most weight here for using that; having a compatible license just makes it easier for us to share code with them.

cgwalters commented 2 months ago

I've updated the original comment here with a status, including a list of usernames that will need to approve.

bfallik commented 2 months ago

No objections from me. Let me know if I need to take any steps to officially grant my approval.

nekopsykose commented 2 months ago

no objections from me.

rborn-tx commented 2 months ago

No objections from me either.

fboudra commented 2 months ago

No objections to the request to relicense.

ffontaine commented 2 months ago

No objections

eriksjolund commented 2 months ago

No objections from me.

wjt commented 2 months ago

I have no objection to my tiny readme contribution being relicensed in whatever way seems appropriate.

divineaugustine commented 2 months ago

No objections from me. Contributions were solely from my account (@divineaugustine ) however the fork was created by the github account of my employer (@wahtari) . I will check with @https://github.com/r0l1 who owns that account if he has any objections/comments. In case if this list has any relevance, Since #276 is mentioned here, just FYI #269 was the first PR.

jluebbe commented 2 months ago

Just to clarify, because ASL2.0 is not a SPDX license identifier: https://spdx.org/licenses/

Do you mean Apache-2.0?

If so, I'd be fine with relicensing to GPL-2.0+ OR Apache-2.0 in SPDX terms.

cgwalters commented 2 months ago

Thanks for raising that. You're right that we should use consistent license terms. I believe everyone here understood "ASL2.0" to mean "Apache-2.0". But then if we're strictly going by SPDX it's actually GPL-2.0-or-later and not GPL-2.0+ right?

I've updated the text of the issue to clarify.

cgwalters commented 2 months ago

OK great, the only person remaining is Katrinjo who contributed a change in https://github.com/containers/composefs/pull/201 - they aren't very active here on Github, but let's give them a bit of time.

divineaugustine commented 2 months ago

@https://github.com/r0l1 does not have any objections.

allisonkarlitskaya commented 2 months ago

I don't really care :)

cgwalters commented 1 month ago

OK so https://github.com/containers/composefs/pull/375 merged which rewrote the small bits of code touched by Katrinjo who was the only person who didn't respond.

I went to go update things and stumbled on the fact that actually erofs_fs.h is SPDX-License-Identifier: GPL-2.0-only OR Apache-2.0 - the GPL-2.0-only of course comes from Linux.

But there's also another thing we (I) overlooked: libcomposefs/hash.[ch] is LGPLv2+ code copied from gnulib, which we're almost certainly not going to be able to relicense. I looked at erofs which has a hash table implementation that it copied from the git project, which is GPLv2+ (and clearly identified, but contradicting its license overview which suggests lib/ is GPL2+ASL2).

In the short term, what may be most viable is to relicense what we can here, such that the result is an intersection, where we're mostly GPL-2.0-or-later OR Apache-2.0, but practically speaking for projects linking to us that hash.[ch] being LGPLv2+ is AIUI going to make the project as a whole remain at that license I believe for now. It'd be...a lot cleaner if we rewrote (I think the most effective way to do that would be to RIIR :crab:) but for now this is at least an improvement in the license matrix.