Hacker News Reader

Comment by stormbrew | Hacker News Reader

Is it possible you haven't seen the same result the other way because it's pretty rare for that to happen in the first place? I can't think of any examples off the top of my head.

Also, it seems like getting contributor agreement to license under a more permissive license than they contributed under might be rather more difficult. To use an extreme example, if you accept a patch from RMS it seems extraordinarily unlikely he'll ever agree to let you relicense his contribution as BSD.

I guess if you have a really solid CLA...

View on HN

Everything else aside: you fundamentally can't make code released under Apache more restrictive down the road, but you can make code released AGPL3 less restrictive. Permissive licensing is forever, restrictive licensing isn't.

For an individual copyright holder, or software which is static and no longer being developed, you are correct.

However if either of those preconditions fails, then the reverse becomes true "in practice."

When the copyright is held by multiple parties, re-licensing becomes impractical (or impossible) because every copyright holder needs to agree to the new terms. The more of them there are, the more likely it is that someone will veto.

However, because the AGPL and Apache licenses (and other liberal licenses, MIT, BSD, etc.) are compatible, I can take liberally licensed software, add loads of fancy features using an AGPLv3 license and the combined end result will become AGPLv3 licensed in practice. Just like the combined license of OS X or Chrome is proprietary, even if it contains open source components. The most restrictive license wins.

So assuming the software is evolving over time and you have a wide base of contributors, it is possible to go from less restrictive to more restrictive, but not the other way around.

You have it exactly backwards. Without relicensing, you can't ever revoke the conditions of the GPL and allow proprietary things. You can always make non-copylefted code more restrictive, e.g. you can make it proprietary.

I am referring to relicensing, which is meaningful for AGPL3 but not Apache.

I guess I don't know what you mean by "relicensing". I meant that the original copyright authors decide to change the license. The original copyright authors are always free to change the license to whatever they damn well please, in any direction they want, more restrictive or less restrictive.

What do you mean by "relicensing"?

What the Mailpile contributors are doing isn't exactly relicensing. They're just agreeing that from now on their future contributions will be under only one of the two licenses that were a choice in the past. If they choose the Apache license for all new contributions, they can still in the future decide that they want all contributions from that future on to be AGPlv3. If they choose AGPLv3, they can never again without relicensing decide that contributions are no longer copylefted.

I am thus still unable to interpret things as you explain them.

My understanding is thus:

The work is published with a particular license, and that cannot be changed. However, the creators may republish the work with a new license. If this happens third parties can choose which work they want to use, the original published work or the second published (identical) version. By saying that license can only get less restrictive, we mean that people can always choose to use the least restrictive license a work has been published under.

If I have some egregious misunderstanding please correct me.

Oh, I see. You mean forking the older version.

Sort of, I suppose. A recent example I've been monitoring where this hasn't worked very well is Rhodecode. It was originally GPL'ed and then got locked up into proprietary software (through lies and subterfuge, I must add). The Mercurial folks took the last clearly GPL'ed version and forked it into Kallithea. But Kallithea is not Rhodecode, and Rhodecode has in the meantime added a bunch of development and features that are as restrictive as possible.

I wouldn't take this to mean that Rhodecode is still available under the least restrictive license. The authors have really taken Rhodecode away from us, and we can scamper about with a fork, but there has definitely been some damage done.

That's what I'm saying. It's true that getting consensus for license changes is hard, and that (unless you're willing to rewrite some code) relicensing of projects with diverse contributors requires that consensus. But consensus is required in either scenario.

Meanwhile: once you publish something MIT/BSD/Apache, it's MIT/BSD/Apache forever; when you try to GPL it, people will simply fork from the MIT code. See: OpenSSH.

Not sure about that, see my reply to your original message.

As for "you fundamentally can't make code released under Apache more restrictive down the road", isn't that exactly what LibreOffice (LGPLv3) people do when they import patches from Apache OpenOffice (ALv2)?

Reply on news.ycombinator.com