CC BY-SA 4.0 is now one-way compatible with GPLv3
- Login o registrati per inviare commenti
"In January we officially opened a public consultation (blog post) on CC BY-SA 4.0 unilateral compatibility with GPLv3, in accordance with our ShareAlike compatibility process and criteria. Following additional months of detailed analysis, discussion and deliberation with the Free Software Foundation and other stakeholders, we are very pleased to announce that we have added a declaration of one-way compatibility from CC BY-SA 4.0 to GPLv3 to our compatible licenses page!
Put simply this means you now have permission to adapt another licensor’s work under CC BY-SA 4.0 and release your contributions to the adaptation under GPLv3 (while the adaptation relies on both licenses, a reuser of the combined and remixed work need only look to the conditions of GPLv3 to satisfy the attribution and ShareAlike conditions of BY-SA 4.0).
This doesn’t mean that you should apply GPLv3 to your revised BY-SA 4.0 work — in most cases it makes sense to release adaptations under the same license as the original, even if not required (e.g., in the case of CC BY or CC0) to facilitate ongoing collaboration with the “upstream” and peer “forks”. But if your use case calls for or requires (in the case of remixing CC BY-SA 4.0 and GPLv3 material to make a single adaptation) releasing a CC BY-SA 4.0 adaptation under GPLv3, now you can: copyright in the guise of incompatible copyleft licenses is no longer a barrier to growing the part of the commons you’re working in. We hope that this new compatibility not only removes a barrier, but helps inspire new and creative combinations of software and culture, design, education, and science, and the adoption of software best practices such as source control (e.g., through “git”) in these fields.
Increasing Interoperability
Since 2005 Creative Commons has been working to increase the legal interoperability of the commons — roughly the ability to use works in the commons together, usually in the form of adaptation, without legal barriers. This has meant retiring little-used CC licenses that were incompatible with other licenses — meaning works under the now-retired licenses could not be remixed with works in the commons under more popular licenses. It has meant working with other license stewards and user communities to migrate projects to licenses compatible with those used for the largest pools of relevant works, as when we worked with the Free Software Foundation and the Wikimedia community to facilitate the latter migrating from the GNU Free Documentation License to CC BY-SA 3.0 as its default license. It has meant working with governments to use and mandate broadly used licenses, or the least ensure that government-specific licenses are compatible with broadly used licenses, most often CC-BY.
Finally, this long-term push for increasing interoperability meant developing an explicit mechanism for declaring compatibility between CC BY-SA and similar share-alike or copyleft licenses. Absent such a mechanism, works under different copyleft licenses cannot be used together to form an adaptation, as copyleft licenses typically require that adaptations be released under the same license as the original work. We first introduced the mechanism in CC BY-SA 3.0 (2007) but it has yet to be used for that license — the most pressing interoperability barrier at the time was mitigated instead through a temporary allowance for license migration (see Wikimedia above) — and we believe compatibility should only be declared after much careful analysis and deliberation. With CC BY-SA 4.0 (2013) the mechanism was enhanced, allowing the possibility of unilateral as well as bilateral compatibility. Nearly a year ago CC BY-SA 4.0 was declared bilaterally compatible with the Free Art License 1.3.
Since the beginning of version 4.0 consultations (2011) and before, we have been discussing with the Free Software Foundation and other stakeholders the possibility of declaring unilateral compatibility from CC BY-SA 4.0 to GPLv3, allowing new contributions to adaptations of works under the former to be released under the latter, and thus also allowing adaptations to be created from works under both licenses. The demand for such an arrangement comes from a variety of use cases, including games and other smart artifacts for which it isn’t always easy to separate software and non-software, hardware designs for which both CC BY-SA and GPL family licenses are popular, and artists who wish to require that adaptations of adaptations not only be allowed, but facilitated through availability of a “preferred form of the work for making modifications”, as the GPL requires. These may seem like niche issues if you think only of media such as text, images, and data. But as the saying goes, “software is eating the world”; the winning educational resources, cultural artifacts, and research inputs and outputs of the future will be software, designed by software, processed by software, or all three. Mitigating legal barriers to remixing “software” and “non-software” in the commons is one thing we can do to help ensure the commons remains vibrant.
Increasing interoperability of the commons is a very long-term, ongoing process, in part enabled by cooperation between license stewards within and across particular domains. CC BY-SA 4.0 one-way compatibility with GPLv3 is a huge win. It took many years to achieve. There are still many incompatibilities among licenses used for data, hardware designs, software, and other materials, both within those domains and especially across them. What commons interoperability fixes do you want to see in the next 5-10 years?"
That's pretty cool! =w=
I wonder if there'd be any drawbacks to it being two-way?
This wasn't a decision, just the only possible way Creative Commons could add compatibility. Making it two-way would require the GNU GPL to be changed. And yes, there would be a huge drawback: CC BY-SA doesn't have any source code requirements, so if GPL programs could be re-licensed under CC BY-SA, any GPL'ed program could easily and effectively be made proprietary.
Ah, yes. I didn't think of the source-code requirement.
- Login o registrati per inviare commenti