Hacker News Reader

Comment by tptacek | Hacker News Reader

AGPL3 maximizes options down the road. You can start AGPL3 and loosen it up over time. Lots of security projects have tried to go the other way, and the result has always been a mess: all the permissively licensed open source I've seen try to vector back towards GPL has created viable, hostile forks.

View on HN

> AGPL3 maximizes options down the road. You can start AGPL3 and loosen it up over time.

I'm not sure you can easily do that, unless all the contributors assign their copyright to you. You can trivially tighten the license (eg. by adding GPLv3-released code in a LGPL or even Apache codebase) but to loosen it you need approval from all the copyright holders (which is doable, but also a huge pain).

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

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.

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

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.

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.

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.

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.

Reply on news.ycombinator.com