How can you influence this decision so it is moved back to BSD?
No clue, Iâm no part of LARA so no insight. You already opened an issue on the right forum for that topic, any further discussion belongs there Moving to GPL from BSD ¡ Issue #282 ¡ epfl-lara/leon ¡ GitHub. Keep in mind theyâre entitled to stick to GPL if they feel soâanybody is free to fork the project from before the license switch and use none of the new GPL code.
Coming back to the MPL recommendation (for the Scala Platform) any decision on this?
My 2 quick cents with recommending MPL. I have worked at some places that have basically tried to avoid GPL like licenses like the plague, I am not sure where MPL falls on this scale but it is something to consider.
I believe its important to consider both the authors and users in this equation, and even if MPL is just a recommended default I have a suspicion that it may not be liberal enough in regards of usage.
I think we also have to consider the type of libraries that are put into SP, I donât think that small standard libraries (such as IO/Json/Http etc etc) are likely to be susceptible to the type of abuse that can happen with more free licenses like BSD or MIT
I think MPL recommendation will hurt commerce. This is relatively to a lesser extent whitelisted compared to other licenses. Also some organisations avoid copyleft. So recommending it self would be considered a risk and would mean Scala would be shunned in such organisations. If the platform grows to the extent that you cannot use any major library without having to use any copyleft dependency, then in organisations where the license policy and legal wins above technical consideration this means Scala cannot be used in such organisations. In the Financial Services industry this can be many firms do not whitelist copyleft and perhaps even as the above examples highlight when it comes to financing startups.
Thanks for proposing the MPL recommendation, Jorge.
Iâd be happier to contribute equally with volunteers, organizations and companies with a weak copyleft license that reciprocates. MPL is a good choice for libraries in the Scala platform since it is compatible with many other free licenses, can be linked with non-free code, and itâs share-alike so distributing a library with modification requires offering the source.
Point of information: Although most 3rd party Java libraries are Apache and MIT-like, the Java compiler, class libraries, and the runtime are under the GPL with the linking exception. Thatâs been a good thing in my opinion.
1 Like
One issue is that comes up is some companies may not:
- Use copyleft licenses (not whitelisted)
- Make available paid developer time for libraries they do not use or non whitelisted libraries
- Encouragement to work on open source (something that might be useful to the company also and in whitelisted licenses) unpaid on own time
Latter can a big source to get the eco system improved. So I would suggest is have a survey where decision / policy makers (opinion who makes the organisationâs policy is what counts as this binds on the developers through their contact) in reasonably big companies (which can allow developer time to work on the platform on paid time) can weight in their opinion on what is the license of choice if they are to contribute on improving the ecosystem projects. This would gather more empirical evidence than just opinions.
Also MPL recommendation can do more damage and what extent is not quantifiable as it is not possible to assess growth trajectory if we what decision is made. So recommending MPL is risky and has a larger source of unknowns vs recommending something like ASL 2.0, BSD, MIT, AFL 3.0, ZLIB, etc. Another option would be to drop the notion of the Scala Platform altogether as of now there isnât one (and things just seems to work just fine) and will make the licensing issues (copyleft vs âŚ) and process issues (C4 vs The Apache Way) irrelevant. Scala platform adopting C4 and MPL will just be opening a can of worms.
Also why not recommend the Apache Way (http://theapacheway.com/) over C4. ASF projects under the Apache Way has seen more success than projects under C4.
If whitelisting of licenses is the problem, GPL + Classpath Exception is an option. Itâs certain to be whitelisted since we can assume all Scala users use the Java stdlib. Itâs a bit less permissive than the MPL though, but nothing too significant.
Whitelisting is giving blanket approval for the license you can have any library under the license. No organisation using license whitelisting have GPL approved but specific libraries like the class libraries may be approved because if defeats the purpose. In case of the use of the JDK, license is not whitelisted but use of JDK is approved. Also if you use the Oracle JDK opposed to OpenJDK then you are still not using GPL code.
Using a non whitelisted license is to jump over the hoops of legal, risk evaluation which can be prohibitive when doing work for 3rd parties.
Also as iterated above it is best to find out what licenses corporations / organisations would support and invest in and also what methodology they would be more comfortable with to further the ecosystems than making arbitrary or philosophical decisions.
For the benefit of other readers, I note that many of Pieter Hintjensâs blog posts fed into his freely available book, Social Architecture - Building On-line Communities, where they may appear edited or expanded.
I do not know that the text is any different in this case, but for completeness, here is your linked blog post, [âHow to Capture an Open Source Projectâ]((https://hintjens.gitbooks.io/social-architecture/content/chapter2.html#how-to-capture-an-open-source-project), in that book.
For the benefit for all I like to make the following comments: through the arguments here are compelling, but there are bigger success stories like the ASF which does not use copyleft and use The Apache Way opposed to C4. There are commercial organisation like WSO2 which use the ASL 2.0 and Apache Way with great commertial sucess. Also anybody who reads the above blog and references please take it with a pinch of salt since the claims are not full backed by empirical evidence.
The best way to choose both license and method is to ask current and potential organisations about their preference than based on argument of a few. If this is not feasible I think since Scala has so far succeeded on the current license this should be chosen. Also if the CLA is a issue then ASL 2.0. For the methodology best would be to recommend Apache Way as this has worked for many projects vs just one project. If not best is to let the project choose it without any recommendation or endorsement.
I think it is important to frame the conversation with respect to what the goals are.
As I understand it, the goal is to grow the Scala development community in the hopes of giving the Scala the best chance at a long, maintained future. This is not the same as âallow as many people as possible to use Scala.â
From this standpoint, I would tend to agree that the choice of MPL is best wherever possible. It leaves the community less dependent on corporate goodwill while not restricting any commercial use cases (that I can think of) other than those that potentially threaten the Scala community.
I am sure this is true. I question, does it matter? Some organizations avoid all open source software. Some organizations avoid commercial frameworks and libraries, preferring to build them themselves. A lot of organizations have been on the wrong side of recent history trends in software development. Some organizations also change their minds.
If there is no clear reasons that an organization should be avoiding a license because it would be a liability for them, but they avoid it anyway, should the project undertake additional risk of a more permissive license just to satisfy that organization?
I believe we should do what we can to educate on the merits and misunderstandings of a license, but the ultimately wellbeing of the project should come first.
@sirinath You have pointed out that the Apache foundation has been around longer. Other than that, why do you think it is the best choice for Apache Way is better for Scala projects? Why do you think it is better than C4?
I do not know how C4 was arrived at so I am only speculating. these are a few objective reason:
- The overhead of the Apache process may not be the best fit for relatively small projects/libraries
- C4 is more prescriptive while also shorter
- C4 is similar to the GitHub fork and pull model that many users are familiar with.
Given their relative ages, I think you are correct about this. As a corollary, âASF projects under the Apache Way have seen more failures than projects under C4.â
It is worth noting that the Apache model also has its detractors. I read âThe forces and vulnerabilities of the Apache modelâ recently, I donât really remember why because it was before anything with Scala Platform or C4 was on my radar. It is somewhat critical of the Apache process.
I am not sure this is a direct analogy. Who is the commercial organization behind Scala? Arguably, this is Lightbend, but (unless there is ownership or agreement I am not aware of) they cannot take control of Scala without either re-branding it or getting EPFL to transfer the trademark. I think chances are good that if there were an organization that commodified Scala, it is be a lot less likely we would be having these conversations.
The linked blog post is about the ability to take a permissibly licensed open source project and make it closed source. There can be disagreements in the likelihood that happens for any given project. I am not sure it can be refuted that the possibility exists. Since it has happed in the past, there is empirical evidence. None of us can predict the future.
As an aside, I hope I am not on some sort of watchlist, for all the searches for C4 that I have done recently.
1 Like
Correct â which is precisely why I think that any copyleft license is fundamentally a bad idea. There are companies that will refuse to use any copyleft software: they wonât even give it a chance. Not a majority, but I suspect not a trivial number.
That presents a real danger to the project, because it provides a reverse network effect: if a non-trivial number of companies will flat-out refuse to use a technology, that provides a disincentive for the rest to invest in that technology. This sort of thing can snowball, sometimes quite quickly â itâs more or less what killed Flash, for example, as a growing number of companies outlawed the platform due to IT considerations, and everybody else eventually shrugged and stopped using it.
Is recommending the MPL necessarily deadly? No. But itâs adding a risk to the platformâs success, for absolutely zero benefit â we have no need to make such a recommendation, since itâs just a recommendation anyway and library authors are capable of making up their own minds.
By your own logic, that the wellbeing of the project is top priority, we should just leave this risky distraction alone. We shouldnât be in the business of recommending any specific license â thatâs not our remit. We should state what our license requirements are (a discussion that I havenât properly seen yet, and which is much more important), and otherwise leave it beâŚ
@jducoeur It sounds like we only disagree on the merits of company refusing to use anything remotely copyleft and on the risk of corporate capture of a project. Both of which are opinions so there is probably no resolution.
In my opinion, current large players coming out against the MPL should have enough chilling effect to put the matter to rest against using the MPL, even if philosophically it is not the best choice. Someone presenting a use case where allowing development of a closed-source fork has a positive impact, or where a reasonable use case is prevented by the copyleft limitations of the MPL would be needed to change my mind about the MPL. Trying to find one, my best guess is that, if there is one, it exists somewhere in the embedded world, but I am not sure.
The benefit is in preventing the project from becoming closed-source in the future and in ensuring that modifications made and externally distributed can be folded back into the trunk if desired. I measure this as non-zero, but others may measure it as zero benefit.
I totally agree with this goal, but this recommendation doesnât do that, because itâs just a recommendation. Itâs not that the MPL has zero benefit, itâs the act of recommending that is.
Thatâs my point: we should instead be stating requirements about the license: in this case, that the license must permit open-source forks such that if it does go closed, we can create an open fork. (Which I think is really the correct way to go, given the nature of the modern ecosystem.)
Making a recommendation is completely off-topic, and we shouldnât be getting into it. We should instead be focusing on the requirements of the Platform, which we intend to enforce, and stating those, as clearly and precisely as possible, instead.
3 Likes
Thatâs my point: we should instead be stating requirements about the license: in this case, that the license must permit open-source forks such that if it does go closed, we can create an open fork.
This is more or less what the OSI does in their approval project - it must meet the open source definition. A requirement of any OSI approved license seems like a good first step with a low bar. One could argue for also requiring a patent grant if youâd want to go further.
@jducoeur @martijnhoekstra On a small note, weâre already asking for an OSI license. This is what the Scala Platform Process says about it in the suggested C4 contract:
Licensing and Ownership
1. A project that joins the Scala Platform SHOULD choose an open-source license. Share-alike licenses such as the MPLv2 are RECOMMENDED.
2. All contributions to the project source code (âpatchesâ) SHALL use the same license as the project.
3. All patches are owned by their authors. There SHALL NOT be any copyright assignment process.
4. Each Contributor SHALL be responsible for identifying themselves in the project Contributor list.
Philosophy and argument is not what is needed. Starting point would be a survey trying to get most of Scalaâs existing uses to comment. Perhaps starting point is Light Bendsâ existing client and potential client database to send out the survey to. It should cover all uses from small to big but special weight should be given to the impact the organisation is make. Once such statistics available on both the License and Method choice this can be taken to account of the discussion otherwise are are just feeling around blind.
I think the the method should be optional but something that has demonstrable success. If it has holes how these can be patched. This should be reevaluated and patched up frequently. Also recommendation should have different maturity and size levels into account. So all what a large project needs to do does not need to be done by a small projects. Statistics should be collected and the results of these should be empirically evaluated frequently.
Also I would presume you want to would would a one of the community building goals:
- new companies using Scala
- prevent exiting companies not to abandon Scala
So every communication should be optimised to achieve this. So the working and language should be adjusted accordingly. Also keep in mind perhaps unlike pure tech companies certain industries have lesses tolerance to copy left than others. You do not want to alienate these industries and drive them away from Scala also.