"It is a common delusion that you make things better by talking about them."
Dame Rose Macaulay, English novelist
Open source provides an avenue for distributing academic research well beyond the covers of journals or the lunchtime chatter of sharp-minded thinkers to a much broader audience. Interestingly, the choice of open source license is often a choice of community. By understanding the goals and underlying philosophy of a research project, one is better equipped to find a suitable license and attract a community with similar interests.
This article provides an examination of a particular academic research project's licensing goals and presents some of the lessons learned during the license selection process.
Why Open Source?
The Nunaliit project is a software framework for producing web atlases. From the start of the project, there were many reasons to release the software under an open source license:
- the project leads were already proponents of Open Source Software (OSS) and the idea of contributing back to the community was appealing
- the intention was to incorporate other people's open source code where it made sense
- attracting interest to help develop code was a goal open formats are often best supported by open source efforts
- the use of open standards and open source meant that atlases created with the framework would have a better chance at retaining their value to the world over time
- traction with communities, research partners, and funding organizations would be better if we weren't trying to promote proprietary software
In addition, the research was funded by taxpayers and the lab members felt that outputs should be fully accessible to the public; while academic papers are expected by funding partners, there is also value in the process and tools built to prove the points. With open source, the mark of our success could be measured by our ideas being widely accepted, adopted, and responsible for change for the better.
Another factor was the research itself which was aimed at helping communities to tell their stories in new and innovative ways. These were often communities whose voice was not being heard, in large part due to the financial resources available to them. Building a free and open framework meant they weren't dependent on the project in order to use or improve upon the software in the long run.
Since building a developer community around the framework was a primary goal, the license and contribution agreements would impact on the success of recruiting people to the project.
A secondary goal was choosing a license familiar to other people, meaning we didn't want to create a custom license. For this reason, the Nunaliit project compared the three best known licenses, the General Public License (GPL), Apache Public License (APL), and New BSD License (BSD), to the type of community each license was likely to attract.
The most troubling issue with the GPL was that it requires all distributed derivative works to be released with the same open terms. We were not opposed to closed ventures; in fact, if companies were able to make use of our software in their products, they validated our ideas. Likewise, if we ever wanted to commercialize the work in some fashion, we would not want to offend community contributors by dual-licensing the code.
In order to preserve this possibility with the GPL, the necessary over-reaching contribution agreements might have scared people away. Avoiding the possibility of going back to closed software products is, after all, a major philosophy of the GPL.
The Apache and Mozilla style licenses didn't have that same "keep drinking the kool-aid" clause and were seriously considered. But ultimately, they still placed a more significant burden on people who wanted to make use of our code and would require a more substantial contribution agreement.
The BSD license left things wide open. Asking people to contribute wouldn'Presenct require them to go for outside legal help to understand what they were doing by putting their code under that license. It was clearly one of the most open licenses, but left the question "would people bother helping the project or would the code just get picked up by some company and improved internally without contributing back?".
A good chat with a friend who has been involved with the Mozilla project since its inception helped to answer that question. The insight that came out of that conversation was that forcing openness in the license has very little to do with whether or not you will get contributions back. Community has much more to do with a project's support infrastructure and its responsiveness to contributions. If it's an easy and timely process for someone to ask a question, file a bug, submit a patch, and see the result incorporated, they will do so as it's far easier to contribute to an existing project than to maintain a separate fork of the code.
This friend, who has spent a fair bit of time discussing the three separate licenses that Mozilla is released under, suggested that if he was in a position to do it all over again, he would likely advocate for the BSD license to save a whole lot of hassle.
This made a lot of sense for a very small project with limited resources. With the consent of our existing code contributors, the New BSD License was chosen and all existing code was placed under that license.
Even though the BSD license is wide open and the published code is entirely free and open for any use, our project has decided to not incorporate code from projects that have chosen the GPL. This is due to the project's philosophy that BSD licensed software is free (adjective) while GPL software is on a mission to free (verb) software.
Prior to selecting the license, the project understood that the chosen license would have an impact on potential contributors. Since releasing the code under a BSD license, the following behaviours have been noted:
- contributors tend to select projects that utilize their preferred license
- contributors are also attracted to projects containing technology that matches their interest and skill set
- license selection should consider both the characteristics of the project's technology and the licenses already being used by technologically similar projects
That last point was unanticipated. As a server-side publishing-infrastructure-like technology, Nunaliit may have drawn a bit more interest and understanding by selecting an Apache license.
When evaluating which license to adopt, consider the projects that most closely resemble yours or whose choice of implementation technology is similar. Developers of these projects may be more familiar or even philosophically attached to one license over another and more apt to contribute if your license matches.
Projects should also give serious thought to their motivations and hopes for releasing code to the world before settling on a license.
St. Laurent, Andrew, M., Understanding Open Source & Free Software Licensing
Chen, Shun-Ling, Free and Open Source Software Licensing Primer