Relicensing Software

I have licensed the code of the imag codebase under the terms of LGPL 2.1. Turns out, I cannot link libraries which are licensed under GPL 2.0 for example - for example the version crate where I opened an issue and requested a relicensing of the crate. I removed the dependency though.

Either way, having this restriction (cannot link to GPL code) is not nice. I'd like to avoid that restriction. That's why I think of relicensing imag.

License to relicense to

I made the code LGPL in the first place because I care about copyleft. I want contributors to have to share modifications to the original code. That's why MIT and Apache2 are not a solution for me.
Though, MPL2.0 looks perfect to me.

Any comments on that?

Relicensing process

I already opened a tracking issue for the relicensing part. Some questions remain:

  1. Do I need to contact all contributors, or only contributors which have code in the latest master of the codebase?
  2. What if a contributor does not respond? If the "only code in master counts" from above applies, I can rewrite their parts and everything is fine, but what if this does not apply?
  3. Can I ask contributors to hand over copyright to me if they want? Something like "You can either say 'Yes, I am willing to relicense my contributions to ' or you can say 'Yes, I hand over all contributions I made to @musicmatze" (so all future license changes/etc are possible without asking them anymore).
    That could be a good idea as at least one contributor already told me that I can do whatever I want with his code contributions.
  4. How to ask them? I would reach out via Email and wait for replies. Some (three) of the contributors had university emails in their git configuration during their contributions which might not be available anymore. Luckily these contributions could be considered "trivial".

I'd love to hear your opinions and comments on that.

For all: IANAL!

It depends if you want to relicense the whole codebase or just the current HEAD :).

Yes. Also, you need to make sure that you rewrite it without using their code, which is a can of worms, as you have the burden of proof.

Yes, you can. That's a contributors license agreement. Note that the language here can be quite picky, but there's templates around. The GNU projects require a CLA precisely for that reason.

Email is alright.

Note, IANAL, as well.

1 Like

I'm of course also not a lawyer, but I believe the answer to the second question contradicts the first answer: If code in the current master branch is derived from copyrighted code made in an earlier commit, then the current code must be licensed under the LGPL (since the license required derived works to keep the license intact).

What I've seen projects do is to contact all contributors (even contributors who don't show up anywhere in a git blame). That seems to be a fool proof and accepted way of doing this. It is of course also the most difficult way to proceed.

The main goal of the GPL is to ensure users' freedom and the license has been carefully constructed to make sure that the source code remains open. Which I'm sure you already know :wink: So I don't think there is a "loophole" you can use to avoid the GPL in your project while also depending directly on GPL code.

Using a weak copyleft license (like LGPL or MPL) and only depending on crates licensed under the same or weaker (more permissive) terms seems to be the best you can do.

If you really care about copyleft, then you shouldn't ask other projects to change their license :slight_smile:

If I read the Wikipedia article correctly, then MPL 2.0 will not do what you want. Your project might as well be licensed under the GPL if it depends on crates that can only be distributed in accordance with the GPL.

That is, if a program Foo depends on imag, the program will also end up depending on version, which is licensed under the GPL. As such, the combined work will include GPL code and it will therefore be covered by the GPL.

1 Like

Derivation doesn't matter if you are the author of the code (or are allowed to decide in their stead). You are completely free to hand the code out in a different manner.

If you are not the author - and that's precisely where those two statements don't collide - you have to rewrite it in a fashion that doesn't derive anything from the old code. It must be your own work in all regards. There's several techniques to do that.

For example, one strategy to do this is the following: Take the code, remove the problematic code and have someone who has never seen the codebase fill the gaps. Document that process.

2 Likes

Hm. So from what I understand, relicensing wouldn't result in any benefits right now? As I removed the dependency on the GPLed crate, I am safe right now. Relicensing from LGPL to MPL wouldn't result in better ability to link to other code, right?

So the best idea would be to leave it as it is right now and simply not link to GPLed code?

It's best if you contact all authors, since all later code may still count as "derived" from an earlier contribution, even if a line got changed later and doesn't show up in git blame any more.

You can ignore contributions that are too simple to be copyrightable, e.g. someone has added a comma or fixed a typo.

3 Likes

I hope this is somewhat tongue-in-cheek :wink:
This is an age-old debate about what I call "principled copyleft" vs. "pragmatic copyleft".

The version crate is a very useful piece of software, but also quite tiny and non-essential in scope.
I can easily imagine that potential users would shy away from using it at all, if its license is "unpractical" to integrate with their other licenses.

So the question is: does the version author want to support open source "pragmatically, generally" (hopefully spreading the gospel), at the "price" of being used/providing advantage to less-open use-cases, or does he "disqualify" version from being used in anything but the most strongly copylefted projects by using a principled, strong GPL stance.

I wouldn't dare presume either way that is up to each author/contributor on their own principles, but here we see a wonderful, tiny example of the tension it can cause.

I am currently going through 300+ dependencies of an in-house java project, to see if we can open source it. unfortunately, little historic care was given to the dependency licenses, so now we have an unholy mix.
I really appreciate the ~250 that took a "pragmatic", dont-be-a-restriction-on-your-users Apache2.0 choice. The ~50 libraries that didn't have been making my life legally "interesting" for weeks now :slight_smile:

In that respect, I see great value in the Rust community practice of favouring dual MIT+Apache 2.0 for libraries.
It leaves maximum growth opportunity for Rust as a language in all settings, both open and commercial.

4 Likes

So for your crate staying LGPL doesn't matter versus MPL but for crates relying on yours it does. In the context of Rust libraries, since they're almost always statically linked, the LGPL and GPL are effectively identical. This means that anyone using your crate must also be LPGL or GPL. The way to follow this is that the GPL works are the final linked executable boundary, the LPGL works at the licensed code binary boundary, and the MPL works at the licensed code source code boundary, so each becomes more restrictive in scope. For copyleft licenses for Rust, the MPL should be used in favor of the LPGL because of this.

7 Likes

Yes, certainly! That is why I added a smiley :slight_smile:

Over the years, I've too changed my view on licenses: I started out by putting all my projects under the GPL since I wanted to support the free software movement and since I was afraid that "evil" corporations would profit from my code. Later, I started using more permissive non-copyleft licenses since it became more important to me that the code was used in the first place.

Well put!

Yeah, this is what the permissive licenses enable: broad and free reuse by companies and perhaps some companies decide to open source some of their code (as in your case).

1 Like