A little over a month ago, the Fedora Project announced a plan to replace the existing Fedora Individual Contributor License Agreement (FICLA) with something new, which we've imaginatively titled the Fedora Project Contributor Agreement (FPCA). After gathering some feedback on the first draft from the Fedora community, the Fedora Project published a revised draft.
Some background: In many cases, individuals wishing to contribute to Fedora must first create an account in the Fedora Account System, a process that generally requires the new contributor to assent to the FICLA. The basic idea behind the FICLA's legalese is that contributors agree to grant generous permissions to Red Hat and downstream Fedora recipients covering the (so-called) intellectual property rights they may have in their contributions.
The FICLA, which has been used for a number of years, is based closely on the Apache Software Foundation's Individual CLA, with some minor changes. So far as I can tell, the Apache CLA has worked well for ASF projects in the several years since its adoption, and Fedora is not the only project to reuse its text. It is not difficult to see why the Apache CLA was originally assumed to be a good model for Fedora. On the assumption, which can be questioned, that some sort of formal contribution agreement was advisable at all, there were, and are, few other models with a genuine free software pedigree.
In retrospect, however, an Apache-style CLA was a poor choice for Fedora. This reflects some significant technocultural differences between ASF projects and Fedora. From the perspective of a Linux distro project like Fedora, ASF projects are upstream. Typical contributions to ASF projects are original material created by the contributor. The Apache CLA is written with this in mind. There are important Fedora sub-projects for which Fedora is, in a sense, its own upstream, and there are many invaluable, indispensable contributions by Fedora community members that categorically resemble what I'm calling the typical Apache contribution. Nevertheless, it's fair to say that the central form of Fedora contribution involves the packaging of code created by other projects upstream. While that sort of contribution involves original material created by the contributor (for example, a spec file), it will consist primarily of material created and copyrighted by others.
Unsurprisingly, it has proved awkward and difficult to map this variety of Fedora contribution to the Apache-oriented terms and conditions of the FICLA. Efforts to understand how the FICLA applied to the work of package maintainers have led to fears, expressed from time to time by Fedora community members, that the FICLA would somehow supersede the preexisting licensing terms governing upstream code, or would force contributors to grant a special permissive license to Red Hat contrary to their own more stringent licensing preferences. We know that the FICLA discouraged some Fedora users from becoming contributors.
The broad license grant that is at the heart of the Apache CLA is
unremarkable in the setting of ASF projects. It closely matches the
Apache License 2.0, the standard outbound license of ASF projects, so much so that I wonder why the ASF does not simply ask its contributors to license their contributions directly under that outbound license. ASF project developers themselves tend to favor permissive licensing over copyleft as a matter of principle. But the Fedora contributor community is quite different from the Apache developer community. Certainly Fedora has a larger proportion of contributors who favor relatively strong copyleft licenses (especially the GPL) and who disfavor the proprietarization of free software. Therefore, while the Apache CLA is quite reflective of its developer culture, one cannot say the same of the FICLA and the Fedora contributor culture.
In response to these problems, in recent years the Fedora Project has sought to interpret the FICLA liberally and creatively in a way that would better match the expectations of its contributor community and the nature of its technical mission. The new FPCA is designed to codify this interpretation in a document that is written from scratch.
The FPCA is guided by a principle of minimalism. Unlike the FICLA, anything that the contributor did not write is outside the scope of the FPCA (we define "Contribution" to exclude such material). Moreover, the FPCA does not affect any original contribution that already has explicit licensing terms attached to it (of course, such terms must comply with Fedora legal guidelines in order for the contribution to be used by Fedora). For anything that is left over - i.e., original work of the contributor that bears no explicit license - the FPCA specifies that a default free license will apply. For code, the default license is the most popular version of what most of us call (for better or worse) the MIT license. For non-code "content", the default license is CC-BY-SA. The MIT license was chosen for code because it is one of the most popular permissive FLOSS licenses in use today, with no known license incompatibilities. Contributors who object to application of a non-copyleft license to their contributions can instead designate a license such as the GPL. As for CC-BY-SA, it has become a highly favored license in the Fedora community for non-software material; for example, CC-BY-SA is now the outbound license for Fedora documentation and the Fedora wiki.
One of the concerns expressed in feedback on the first draft of the FPCA was the problem of reusing default CC-BY-SA-licensed content in works otherwise governed by the GPL, because of the incompatibility between those two elaborate copyleft licenses. In the second draft we fix this by making the default content license CC-BY-SA plus additional permission to use the contribution under the GPL. I like our legal craftsmanship here, but I wonder whether there's a simpler solution.
I'll be giving a talk at LinuxCon in August on the subject of open source project contribution policies. My experiences over the past couple of years working with Tom 'spot' Callaway on issues relating to FICLA interpretation and drafting the FPCA have deeply influenced my views on this topic, including my skepticism of the value of maximalist approaches by companies having limited exposure to FLOSS culture.
Comments are closed.