In relation to the other thread discussing the subject of sunset clause, I've re-read the clause in question and personally (as a developer) I am even more confused about how it should be properly applied.
Quoting (from v0.3.1): << The conditions in sections 3 through 5 no longer apply once fifteen years have elapsed from the date of My first Distribution of My Work under this License. >>
(Although the current master has almost the same words, its clause coverage is different, most notably including the proprietary dual license clause.)
I have problems understanding the following items:
* the fact that it applies 15 years since my **first** distribution; this implies that if one is maintaining a work for more than 15 years, basically after that point one is doing public domain work, which reduces ones incentive to keep contributing, given that now distributors (and competitors) can just take any new enhancements for free and not contribute anything back;
* in the "master" version of the license, the sunset clause also applies to the "proprietary dual licensing" clause, meaning that after 15 years, the original author can now re-license both the original work and any later derived works, thus completely side-stepping the original license; (it seems that this doesn't hold for v0.3.1, which doesn't sunset the proprietary dual licensing clause;)
* who is the "my" in that clause? according to the definition in v0.3.1 (which is missing from the master), "my" is the original author of the "my work"; however in the context of open-source software development there are many authors that submit patches, which under the definitions of the license (at least v0.3.1) are actually "distributors" that "distribute" "derived works"; so in the end this clause applies only to the original author, i.e. the first open source contributor (i.e. "my"), and not to later contributors? if so how does this clause apply to a project with many authors throughout the time?
* how does this clause apply in the case of patches? in v0.3.1 section 6 (licensing for upstream contributions) it is stated that a patch becomes in fact "my work", and thus the contributor becomes in his turn "my"; thus taking that patch as a "my work" in itself, the sunset clause applies to this contributor 15 years after he made his first contribution to a project, but only for versions of that project that come after that patch;
Based on my observations above, in the context of an open-source project, the sunset clause would apply to the latest version of a project only when the youngest developer has already been involved for 15 years in the project. And any new contributor to that project would prolong the 15 years deadline, which in essence, for popular projects would mean that the sunset clause would never actually apply in practice.
I've tried searching the mailing list archives, and found a similar topic in the thread `Copyleft Sunset` from February 2018, where Janson made the following two interpretations:
* that in the sunset clause "my work" actually implies the original author's work and any other derived works; (I don't make such an interpretation, since my question regarding patches;)
* that 15 years are counted since the first distribution of "my work" but then it applies to all future versions that "my" am releasing; (I am also making this interpretation;)
However reading that thread, especially Janson's suggestion of including the word "version" in the sunset clause, now I too wonder if the "my work" actually means "a particular version of my project", or to the whole project continuously morphing? I.e. are we putting in public domain only works that are 15 years old, or any versions of a project that has more than 15 years of existence?
As a conclusion, I think at least in the context of open-source projects with many authors, the sunset clause doesn't quite work in the current form (or at least it's unclear how it is to be applied). I think it makes a lot of sense for a company that releases software as source code snapshots with no other contributors and no public history (i.e. there is only one "my" entity, a clear "my work" that is the current release, and perhaps only patches with a copyright assignment that are not seen by the public). However I have a hard time wrapping my head around how this clause would apply to a GitHub project with thousands of commits and hundreds of contributors. (I.e. what is an original "my work" combined with a patch that is another "my work"? Is it just an "derived work", or given that it can be a base for other patches, becomes in itself a "my work"?)
In the end I think I agree with Solomon and Jason observation, made in the last thread about "sunset a disadvantage to free software", that perhaps open-source work should always remain open-source (i.e. not public-domain).
Or perhaps, a different approach to the sunset clause would be to replace the public domain with any "OSI-Approved and FSF-Free" (as is the case of the inbound license compatibility) thus allowing the re-licensing by users after 15 years.
Thanks, Ciprian.
In practice, If you want to extract the subset of code for which the copyleft sunset clause applies from a project that has been licensed under copyleft-next for more than fifteen years; you would go to the revision control system, then roll back the commit history 15 years earlier, - for example if you are doing this in 2021 you would roll back the commit history to 2006 -; The resulting revision history tree from the top commit backwards is licensed under copyleft-next but the copyright protection of the license is similar to Apache 2.0 not GPL. As each year passes you can move one year up in the revision control history and get more code under a permissive license with patent protections.
copyleft-next@lists.fedorahosted.org