On Tue, May 21, 2013 at 8:39 AM, Theodore Ts'o <tytso(a)mit.edu> wrote:
If the answer is a little of both, is there anything we
can do to make sure that copyleft-next doesn't make the problem of
splitting the copyleft community worse? (i.e., by introducing a new
license which is both GPLv2 and GPLv3 incompatible)
I couldn't agree anymore. The digital revolution and changes in the
market pushed the FSF to come up with a license that although it does
protect freedoms it left behind evolving older copyleft with the
assumption of wider adoption on the new copyleft. So while I do
understand the ideas of evolving copyleft to a point perhaps we've
never been at I think it is important to not evolve it too fast, or if
we do at least allow for advancing the older licenses. So for example
as with Linux with stable releases in which we have on linux-stable:
* linux-3.8.y
* linux-3.9.y
* linux-3.10.y
And then we have Linus chugging along forward on mainline I think it
would be good to split the *new* attributes that copyleft-next
introduces and treat them as branches:
* copyleft-0.1.y
* copyleft-0.2.y
* copyleft-0.3.y
Using the GPL and AGPL as a references, if we could go back in time, I
feel there was a gap between GPLv2 and GPLv3, in terms of attributes
and implications, not only compatibility. This also applies to the
stark differences between GPL and AGPL evolution so in theory I'd see
room for:
* GPL-2.y
* GPL-3.y
* AGPL-2.y
* AGPL-3.y
And in between GPL-2.y and GPL-3.y I see a huge change, and in between
GPL and AGPL I also see a huge change. The evolutions between them and
the changes within should be considered gradually. We are at a point
today where for example the economics simply don't even exist to
enable AGPL to fruition in the market due to the lack of an
appreciation for such licenses. This is why I'm concerned with the
rapid evolution and expectations of embracing advances in copyleft.
Luis