2 ms·

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

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.

tptacek 11y ago
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.
jordigh 11y ago
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.