Instead of MPL / GPL / Share Alike licenses can you please consider perhaps the Scala license or ASL 2.0?
The reason why we recommend MPL is because it encourages companies to help maintain Scala Platform modules in the future (be it with money, resources or developers). As the Platform is maintained by volunteers and developers that invest their free time into software that everyone benefits from, this is a huge incentive for them. The Scala License and ASL 2.0 are not appropriate for this matter because they don’t contribute to make maintainers’ life better.
That being said, this is only a recommendation. Libraries joining the Platform can have any open source license they want/already have, so long as it’s compatible with any of the other modules’ license in the Platform.
3 Likes
Perhaps you can give us all a short explanation hashing out why this is indeed the case? I understand the generalizations you’re making, but a bit more detail so we can all understand the tradeoffs would really help.
In the Scala License and ASL 2.0 there is no sense of reciprocity. They encourage “one-way remixability”: your code can be turned into closed source and commercialized by a third party. Of course, this is not very relevant for a SP module that solves a simple problem because the likelihood of a company to create a competing product for it is low. However, it does pose problems. Companies can get the source code of modules, potentially unmaintained, and develop them on their own.
The fact that they are using software developed by open-source contributors, that have invested a lot of their time in it, crashes against the reason why developers worked on the project in the first place: to improve the tooling and libraries for all the Scala developers. All the changes that the new owner has done cannot be remixed again. Maintainers and contributors will need to reinvent the wheel to implement bugfixes and solve performance issues that would have been available long time ago. This kind of behaviour kills unfunded open source projects in the long term; volunteers cannot keep up with the issue tracker, people get burned out and the overall quality of the project decreases.
For a better and clearer explanation of this phenomenon, read this blog post.
On the contrary, MPL prevents these practices by forcing developers to improve projects in the open, either with forks or in the original repositories. How cool is that? It means that even if developers of a company do not have the time to submit a PR, they can fix a bug in their own public fork of a module and someone else can get those changes and patch them on top of the latest master. As a result, Platform users seeing regular updates and an increase in the quality of the software become motivated to create their own patches. The cycle continues, the momentum increases, and more developers decide to help the maintainers creating high-quality bug reports, hanging out in the Gitter channels, contributing PRs and helping other developers learn the project.
Of course, whether that becomes reality or not is something that depends on a lot of factors, but at least MPL makes these events more likely – companies cannot grab publicly-maintained source code and develop private copies. The Scala Platform process focuses on giving maintainers the strongest support to make their developer experience more of a hobbie than an obligation. It’s in the best interest of our community to make their job easy because they will not stay forever and we may even want to get involved and define the future of the Scala Platform. Unfortunately, neither the ASL nor the Scala License helps us go into that direction and protect the people with the skin in the game, and while MPL may not be perfect, it’s a good starting point to create software that outlive us.
1 Like
An observation, as someone who both uses a lot of open-source libraries and has contributed a growing collection of them: this statement turns me off quite strongly. As a rule, I avoid libraries with licenses that force me to do anything – it’s one of a number of reasons why I won’t have anything to do with any variant of the GPL. I’ve never worked for a company that allowed use of such licenses (and mind, I’ve tried to do so at multiple companies), and I’d be cautious about using them myself.
Yes, there are edge cases where companies commit abuses, and those are sad. They’re also fairly rare, and mostly limited to big systems, rather than libraries – the Android OS is by no means representative of the typical library. I strongly prefer to operate in a spirit of free use as one chooses – that’s why I’ve usually gravitated towards the MIT license for my own work. Especially for reasonably self-contained libraries, I think that’s the best approach both for myself and for the community.
Mind, if somebody wants to MPL their library, that’s their choice. But I’m getting a sense that you’re pushing people in that direction, and I do not agree – it should be freely up to library authors, and the SC shouldn’t be getting into the particular battleground any more than it must. I really don’t think you should be doing any more than providing a balanced description of the trade-offs in license choice…
1 Like
Some people have strong opinions on license, and I expect they’ll ignore the recommendation or argue why they prefer what they prefer, and I understand that’s fine. For others, having a default uniform choice doesn’t seem too bad.
1 Like
It is. MPL is just a recommendation in the best spirit of the Scala Platform process, as also said in previous comments in this thread.
I apologize if I sounded pushy, I tried to describe the facts and convince people. That quote is a fact, It’s exactly why MPL was born, but I understand your general concern. I am aware that there are developers that do not like these restrictions, and it’s fine. This is why MPL is recommended, but not enforced.
I would not say “commit abuses” because that implies intentionality or awareness. Most of the times, companies do not even realize that they are a key piece in the puzzle and that could help make open source much better. I was just saying that those practices have become so common that companies make them by inertia. We want to encourage them to do more work in the public so that the community can also benefit from it, and also make it easier for them to contribute back.
2 Likes
On the licensing subject, it seems like it might be wise to adopt a more strict stance in the interests of universality. I would argue that any license more restrictive than that of Scala itself is inappropriate for inclusion in the platform.
While the mpl/gpl style license does protect developers, it also restricts them from using the code in many environments, and for many of us, rather than fight the language lawyers, we prefer to simply contribute to code where there will be the minimum of friction in case legal gets involved. For instance, while the FSF feels that the GPL 3 is strictly “better” than GPL, I’ve run into several legal counsels who were unwilling to accept GPL3 libraries onto the approved list, for hazy reasons mostly related to confusion with the AGPL and patents. The problem is, they are the lawyers and we aren’t, so it’s an uphill battle and usually isn’t worth fighting.
There’s a lot of precedent for this, most of the node/js world, django and rails communities are bsd-style. I might even argue that the linux kernel itself is the single biggest counter-point, and they are such a special case I don’t think they are comparable.
Allowing a mix of “gpl-style” and “bsd-style” licenses in the platform runs the risk of the entire platform being written off by organizations with a GPL aversion. I would argue that it’s better to solve the “lack of contributions” and “companies might take our code” problems by making it really easy to contribute, and educating, rather than choosing licenses that throw up potential roadblocks to contribution.
The Scala license is decided by the EPFL legal department. Enforcing this to open-source work not related with EPFL is not fair. On a side note, there have been some complaints about the Scala license in the past, but this is offtopic, so I would prefer not to discuss it in this thread.
This cannot happen with MPL because it’s compatible with Apache and BSD-like licenses. Sources here and here. It is a problem for GPL but almost no Scala library uses GPL, so I don’t know until which extent is worth to worry about this.
1 Like
Preferring permissive over restrictive free licenses has been the trend over the last year, and I feel by having the MPL as the default or recommended choice, the Scala platform would be an outlier.
I’m a large proponent of the copyleft family of licenses (of which the MPL is one, and the GPL and LGPL are the more well-known examples) , but from what I hear and see around me, I’m a minority, and there is a fair amount of hate for copyleft license - Meandering anecdote, I’ve seen situations where people forked a MIT licensed project, and released their version under the LGPL. The maintainers of the MIT licensed software didn’t like that at all, and added an ad-hoc restriction to their license that people who fork the library had to release it under the MIT as well, effectively becoming the LGPL, just to stop those terrible terrible freetards who wanted to restrict their true open source with their dastardly copyleft restrictions.
Long story short, while I like the MPL over a permissive license myself, I think it would probably better not to promote any OSI approved license over any other, lest we become part of someones holy war. We have holy wars enough in Scala land.
Referring people to http://choosealicense.com/ for some quick&dirty guidance can also help.
1 Like
Can you update your argument accounting for the GPL-LGPL difference? Closed source software can’t ever use a GPL library (or do I miss something?). So did you mean LGPL throughout, or what did you mean? (That would be a pretty significant typo).
Do those legal counsels also reject the LGPL/MPL?
GPL libraries would be a problem, and this might be worth stating, but LGPL is different, and the MPL is closer to the LGPL—in fact, IIUC, it also allows static linking (I’ve only skimmed this link licensing - Mozilla Public License (MPL 2.0) vs Lesser GNU General Public License (LGPL 3.0) - Software Engineering Stack Exchange).
The platform’s goal, IIUC, is to serve the community, not specific users. Now, if some people fear some license without valid reasons (which seems your point), the platform might have to account for that to some extent, but the goal is always serving the community (and helping commercial users is part of that).
EDIT:
Again, I’d be careful with confusing them 
2 Likes
Edited/fixed, thank you
Since this may not be a familiar territory for many folks, allow me a hypothetical.
Say you’re working for a startup. You’re building the next Facebook. You’re building this thing using Scala, and pulling in a bunch of libraries. You’re doing so well, in fact, that investors are interested in giving you money to take over the world.
The investors send in their due diligence squad. One of the things they WILL ask for is a list of all “Open Source Software” in use. You’ll have to provide them a list of stuff you’re using, including version numbers and licenses. They’ll have a junior associate review the list, and they’ll come back to you with any complaints.
Depending on that junior associates experience, the policy of their firm and of the VC, and the phase of the moon, they may come back with complaints. I’ve seen refusal to include AGPL, I’ve seen refusal to allow for GPL-3, I’ve seen refusal to allow any copy-left whatsoever in the fear that it introduces undue risk. It sounds like @jducoeur has seen the same.
That one junior associate is in a position to kill your company if you don’t remove the offending software. Typically you’re not in a position to fight this stuff, you’re on a limited timeline and the “powers that be” don’t understand why you’re making such a big deal about “just some piece of software”.
So back to reality. We all understand there is a lot of subtlety to licensing, and I agree that for all intents and purposes LGPL and MPL are pretty reasonable, but that doesn’t mean that every legal counsel in every company will think so. And hence, the argument against copyleft. Is it REALLY worth the extra hassle? Much of the open source community says no, as @martijnhoekstra just pointed out.
Understood and agreed, I’m not arguing for the Scala license itself, but rather against allowing more restrictive licenses. Compatible does not necessarily mean that a license isn’t “more restrictive”, and I’m arguing that theres a significant benefit for the platform to be able to be considered as the same for licensing purposes.
Yep, just so. I personally don’t mind the LGPL too much in its modern form, but when I’ve talked to lawyers about it, their responses have ranged from “this makes me very nervous” to “I will not allow the company to use this, period”. Can’t speak to the MPL specifically – I’m mostly reacting to the family in general and the problems I’ve had at multiple companies over many years…
1 Like
Licensing is a major source of disagreement and controversy in the open source world.
Therefore, I’m wary of the Scala Platform getting involved with license choice at all, other than to say “Libraries joining the Platform can have any open source license they want/already have” —which Jorge has already said. So, I don’t see why it’s necessary or desirable for the platform to recommend particular licenses at all. Let’s not poke that hornet’s nest.
It the platform does ultimately recommend one or more licenses, I would suggest that the BSD 3-clause license be one of the recommendations we make, since that’s what Scala itself uses. Otherwise I think the recommendations may be perceived as having a strange “do as we say not as we do” flavor. (I understand that the BSD choice for Scala is historical, but it’s what we have.)
I’m not speaking for Lightbend, these are just my own opinions. I would suggest you talk to Hywel Evans at Lightbend for the company’s take on this.
3 Likes
Yeah, agreed. I’ve been mulling this for the past few hours while I run errands, and have pretty strongly come to the opinion that it’s inappropriate. I could go on for a long time about why (the full post in my head probably runs two screenfuls), but it boils down to:
- The primary purpose of the Scala Platform, AFAIK, is to encourage adoption of Scala in more companies, by lowering the barriers to that adoption.
- Some companies (I don’t know how many, but I’ve worked for a couple) would probably look at this recommendation and have a knee-jerk negative reaction to the idea that it is criticizing their development practices; some of those companies will probably reject Scala out of hand as a result, without giving it a chance.
- I don’t think the recommendation helps in any meaningful way – there’s already quite a bit of material online about choosing licenses. (Frankly, as an OSS developer, I find it slightly patronizing, and since I disagree, it gives me just a little pause about contributing to the project.)
- So overall, I think it’s a modest but real net negative, with no obvious benefit, and specifically counter to the objectives of the project.
Of course, I’m just a kibitzer here: my company is tiny and already deeply invested in Scala. But based on my experience in the corporate world, it feels unwise to me…
If you take ASF the ASL and the Apache Way has had more success than any other open source license in building successful projects. I have see the rationalising of C4 and the copyleft license but empirical evidence suggest otherwise.
When the you have to force to give back any changes there is chance that corporations will not contribute to such projects since they cannot keep the IP. If you look at the contributions by many corporates the license of choice is also more permissive licenses. There are few exceptions like in system and utility software and when the corporation uses copyleft with a contributor agreement.
More than forcing contribution by way of license the best is to drive contribution by need and adaptation. Companies will have to contribute in case if upstream library is evolving and they this keep their internal changes. Also as more companies adopt a software the chances of contribution increases. There are certain instances where you might be able to only use whitelisted licensed software, hence it is always better to have a permissive license recommended.
Also I noticed EPFL-LARA (https://github.com/epfl-lara) moving to GPL which was BSD. Since EPFL is the source of Scala and related technologies, I hope EPFL is no gearing towards copyleft and endangering Scala.
As for these projects I hope they would reverse the license back to what it was.
@sirinath Note messages on this forum are unlikely to reach LARA.
As an outsider, I’d expect using GPL is a decision between LARA and EPFL, and I wouldn’t try guessing how many years that took.*
*EDIT: that’s not-really informed speculation, so please don’t quote me on that. The only information I have is about how big institutions (such as EPFL) tend to work, especially in such situations.