The Scala Platform process is opening discussion on many aspects of the Scala ecosystem. One that has come up in a number of venues is the Scala license.
Currently, the Scala License is a 3-clause BSD license. Additionally, contributors to Scala sign an Apache 2.0 Contributor License Agreement (CLA).
Here I invite discussion concerning changing the Scala license to the Apache License, Version 2.0 (ALv2) and eliminating the CLA.
The primary motivation for this change is to protect Scala users while also broadening and simplifying the ability to integrate code from the community to improve Scala.
Why the ALv2?
Like the MIT and BSD licenses, the Apache License is a permissive license placing relatively few restrictions on recipients and allows for the software to be relicensed. Corporate aversion to copy-left licenses (GPL, LGPL, MPL, etc.) and risk of lost contributors have been the primary reasons given for preferring a permissive license. Unlike a BSD license, the Apache License includes a patent grant.
EPFL has the benefits of a license grant from the community because of the CLA. EPFL cannot be sued by contributors for patent infringement without provisions of the CLA going into effect which would open the contributors in question to counter-suit.
Under the current license, users of Scala are vulnerable to lawsuit by EPFL or other patent-holding entities for patent infringement related Scala. The APv2’s patent grant will protect Scala users and thus the community from lawsuits from EPFL or Scala contributors that have made contributions covered by their own patents.
While, this is may never happen in actuality, it is better to have the protection and not need it than to leave one’s self vulnerable.
While individual users may feel they have negligible risk of ever being victim to a lawsuit for using Scala, I pose for consideration, that the risk is potentially greater for public forks of the Scala ecosystem. Were *insert event here* to occur and Typelevel or some other Scala fork to start gaining significant popularity and commercial success, factors that led up to that point could cause that fork to be target for litigation for patent infringement.
As a community there are clear benefits to keeping a cohesive platform and reducing fragmentation. However, forks, such as Typelevel, are important for innovation and for resiliency, both of which are beneficial to the community. Thus, we should try to protect these efforts by affording them the same patent grant status that EPFL Scala enjoys.
Why eliminate the CLA
The patent grant from the APv2 [hopefully] eliminates the need for a separate CLA. By eliminating the CLA, the there are fewer barriers and restrictions for integrating community code into Scala.
The CLA, while minor, is a barrier to contribution that can keep contributors away. I do not know if this has ever happened with Scala, but I have seen it before. With more projects having CLAs and GitHub integration, perhaps this is becoming less of an issue.
Currently, code can only be integrated into Scala a contributor (a) signs the CLA and (b) submits some code as a contribution. If the license were changed to the APv2 and the CLA were removed, code from any APv2 project could be included. While for the most part, the process of a contributor submitting a contribution is the best and correct one, when cases arise that it would be useful to be able to integrate other APv2 code it is in the best interest of the community to have that option.
To illustrate: suppose a skilled newcomer has come to the Scala community with an interest in implementing a great new feature or fixing a difficult bug. The contributor forks the project on GitHub keeps and makes good progress. She pushes his changes just before he heads to a Scala meetup where he can some feedback and will submit the Pull Request. On the way there, she is hit by a truck and never able to finish her contribution.
Unless she took actions to re-licensed her fork, her code is published (on GitHub) under a compatible license. Arguably, if this case, if were known that her intention was for the work to be submitted as a Contribution, and she had already signed the CLA, then it might be allowable to consider it a Contribution and be able to be merged (IANAL). However, if she never signed the CLA, EPFL would not have a patent grant for the work and it could not be integrated.
If there were no CLA and Scala were instead under the APv2, the contributor’s fork would, by default, have been licensed under the APv2. Assuming the user did not take steps to relicense her fork, the fork’s license would have the necessary patent grants to allow her efforts to be integrated into Scala and the question of whether it is an intended contribution is irrelevant because it is published. Thus, eliminating the CLA along with the license change adds further protection and resiliency in the Scala community.
Known issues
EPFL is a patent holder and copyright holder for Scala. In the August 9, 2016 meeting of the Scala Center Advisory board, Martin Odersky raised issue the issue that a relicense would potentially cause delay to Scala releases:
Martin: “I can quickly say what the risk of this would be. Generally from EPFL it’s very hard to do an Apache license, and EPFL is one of the copyright holders for Scala. EPFL has a patent office and holds patents. Having to have EPFL check every Scala release for issues with EPFL’s patents could create long delays for every Scala release.”
Unless a more favorable resolution is found on the EPFL side, this is may be a non-starter because it could greatly hamper EPFL coding contributions to Scala. Technically, a new release needing review would occur every time a covered EPFL employee pushed a change to GitHub. 
(NB. Discourse thanked me for starting a new conversation and told me I needed to have an engaging title, thus the title you see.)