Let's change the Scala License!


#1

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. :confounded:

(NB. Discourse thanked me for starting a new conversation and told me I needed to have an engaging title, thus the title you see.)


#2

If at all it can get dual licenses with ASL 2.0 while retaining the current license also than abandoning the current license and moving to ASL 2.0.


#3

Do I summarize the position of the EPFL correctly that using the Apache license is problematic, because Scala may be patent-encumbered, and the risk of accidentally giving away a free patent license outweighs the risk of accidentally releasing patent encumbered software?


#4

I’d be interested to hear more of your thoughts behind this. Who this would benefit, and how?


#5

It makes sense to keep the original license as the legal aspect of the decision to use Scala would have been based on the existing license. If the license changes there might be some license evaluation related work needed in some cases which cost money. So best is the keep the existing license also incase you want to adopt ASL 2.0.


#6

IANAL, but I think if you keep the old license in addition to a new license, you do not relieve contributors from the need to sign the CLA, which is, IIUC, one of the major reasons for changing the license in the first place. Kind of defeats the purpose …


#7

If the you are getting rid of the CLA then ASL 2.0 change would be best and will be minimally disruptive. If CLA is retained dual license would be a the best option to accommodate everyone who is started using Scala when the old license was effective.


#8

IANAL, and some imply otherwise. In particular Miles Sabin (not a lawyer but IIUC more informed) suggested using both Apache and Apache CLA, and they’re designed to be used together.
https://groups.google.com/d/msg/scala-debate/ryr2q18b74w/B6893W6nCAAJ

Scala Center’s Advisory Board is going to discuss the topic:
https://groups.google.com/d/msg/scala-debate/ryr2q18b74w/3wJ9k54DAQAJ

I’ll agree CLAs are a barrier to adoption, but I understand there are legal concerns with not having them.

That might work legally (not sure why the clause is there in the first place). But with a CLA, contributors also declare they have a right to license the code. So if it turns out the contributors didn’t because their work is owned by their employers (https://www.joelonsoftware.com/2016/12/09/developers-side-projects/), the CLA might protect EPFL.


#9

I agree that requiring a CLA is a higher standard; which, if nothing else, helps to establish intent which could be important in the event there is ever a challenge, though I do not believe CLAs to be generally necessary for all open source projects.

Plenty of Apache 2.0 licensed projects, including ASF projects, don’t require a CLA. That said, groupthink is not good legal standing or advice.

The possible benefits conveyed by eliminating the CLA had the most appeal to me which is why I took the time to start the discussion. However, I do not think anyone other than EPFL and its legal team is in a position to determine whether a CLA provides benefits enough for its needed continuance after the license is changed, or if it could be forgone in the context of a license change to the ALv2.


#10

Probably people who participate in this forum also read the Scala blog, but just in case: https://www.scala-lang.org/news/license-change.html