The declaration increases interoperability of the commons for games, hardware designs, and more
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.
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?No Comments »
The basic idea of Creative Commons, offering free copyright tools, is copied from the free software movement. However, CC licenses are not intended to be used to release software, as our FAQ has always said.
One important reason why Creative Commons licenses should not be used to release software is that they aren’t compatible with existing free software licenses, most importantly the GPL from the Free Software Foundation, which is used by over half of free software projects. A commons fractured by legal incompatibilities is a weak commons, and it would be deeply contrary to our mission to fracture the commons of software. (It should also be noted that the FSF helped unfracture the non-software commons by facilitating Wikimedia’s migration to CC BY-SA as the main content license of Wikipedia and its sibling sites.)
While the vast majority of contemporary free software is released under the GPL or another free software license, there is also a long tradition of public domain software, which was free before the term free software existed. Indeed, prior to the 1970s, copyright did not apply to software. Currently, SQLite, an embedded database that you almost certainly use, is probably the most popular software that is dedicated to the public domain.
There are a variety of public domain dedications used to release software, which is mostly not a problem — to the extent such dedications are well-crafted, they don’t present a legal interoperability problem. This means it is possible to improve the state of the art in public domain dedications without harming the ecosystem. (Though this doesn’t mean an infinite variety of public domain dedications is optimal — at the extreme having to determine whether a new dedication is well-crafted each time one encounters a new public domain work would make using public domain works unattractive.)
In addition to licenses, Creative Commons also offers public domain tools. In creating the CC0 public domain dedication, we did set out to improve the state of the art in public domain dedications, and we think we’ve been pretty successful. Users seem to think so — ranging from governments and institutions to musicians.
We hadn’t set out with CC0 to improve on public domain dedications for software. However, since the release of CC0, we’ve been approached a number of times about using CC0 to dedicate software to the public domain. While we were happy to hear of this unanticipated demand, we wanted to tread very carefully so as to not create any unintended consequences for the free software ecosystem. This led to discussions with the Free Software Foundation, the steward of the GPL and moral leader of the free software movement.
We’re really happy to announce that the Free Software Foundation has added CC0 to its free software licenses list (which includes public domain terms). As usual, the FSF’s language is extremely clear, so we simply quote two sections from their list:
CC0 is a public domain dedication from Creative Commons. A work released under CC0 is dedicated to the public domain to the fullest extent permitted by law. If that is not possible for any reason, CC0 also provides a simple permissive license as a fallback. Both public domain works and the simple license provided by CC0 are compatible with the GNU GPL.
If you want to release your work to the public domain, we recommend you use CC0.
If you want to release your work to the public domain, we encourage you to use formal tools to do so. We ask people who make small contributions to GNU to sign a disclaimer form; that’s one solution. If you’re working on a project that doesn’t have formal contribution policies like that, CC0 is a good tool that anyone can use. It formally dedicates your work to the public domain, and provides a fallback license for cases where that is not legally possible.
We’ve also added an entry to the CC0 FAQ about using CC0 to release software, which you ought read if you’d like to do that. If you’re only familiar with the way CC licenses and public domain tools are typically used on web pages and other media, be aware that with free software, the full license (or public domain terms) are usually included with the software. In order to make this easy to do, we’ve taken this opportunity to fulfill a longstanding request — plain text copies of the “legalcode” for CC0 and CC’s six main international licenses. See CC software engineer Chris Webber’s post for details.
Special thanks to Chris Webber and the FSF’s Brett Smith for their persistent work to make the CC0 software recommendation possible.3 Comments »