Why is MPL *recommended* to module maintainers of the Scala Platform?

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