RFC Change license of Invenio v3 to MIT license

Proposal

Change Invenio v3 license to MIT license.

Following is a list of repositories affected in inveniosoftware:

BSD-3-Clause -> MIT
inveniosoftware/cernservicexml
inveniosoftware/datacite
inveniosoftware/dojson
inveniosoftware/flask-breadcrumbs
inveniosoftware/flask-celeryext
inveniosoftware/flask-cli
inveniosoftware/flask-iiif
inveniosoftware/flask-menu
inveniosoftware/flask-sitemap
inveniosoftware/flask-sso
inveniosoftware/flask-webpackext
inveniosoftware/idutils
inveniosoftware/jsonresolver
inveniosoftware/pynpm
inveniosoftware/pywebpack
inveniosoftware/requirements-builder
inveniosoftware/xrootdpyfs

GPL-2.0 -> MIT
inveniosoftware/citeproc-py-styles
inveniosoftware/cookiecutter-invenio-module
inveniosoftware/dcxml
inveniosoftware/domapping
inveniosoftware/doschema
inveniosoftware/generator-invenio-js-module
inveniosoftware/invenio
inveniosoftware/invenio-access
inveniosoftware/invenio-accounts
inveniosoftware/invenio-accounts-rest
inveniosoftware/invenio-admin
inveniosoftware/invenio-app
inveniosoftware/invenio-app-ils
inveniosoftware/invenio-archivematica
inveniosoftware/invenio-assets
inveniosoftware/invenio-base
inveniosoftware/invenio-cache
inveniosoftware/invenio-celery
inveniosoftware/invenio-charts-js
inveniosoftware/invenio-circulation
inveniosoftware/invenio-collections
inveniosoftware/invenio-communities
inveniosoftware/invenio-config
inveniosoftware/invenio-csl-rest
inveniosoftware/invenio-db
inveniosoftware/invenio-deposit
inveniosoftware/invenio-files-js
inveniosoftware/invenio-files-processor
inveniosoftware/invenio-files-rest
inveniosoftware/invenio-formatter
inveniosoftware/invenio-github
inveniosoftware/invenio-i18n
inveniosoftware/invenio-indexer
inveniosoftware/invenio-jsonschemas
inveniosoftware/invenio-logging
inveniosoftware/invenio-mail
inveniosoftware/invenio-marc21
inveniosoftware/invenio-memento
inveniosoftware/invenio-migrator
inveniosoftware/invenio-oaiharvester
inveniosoftware/invenio-oaiserver
inveniosoftware/invenio-oauth2server
inveniosoftware/invenio-oauthclient
inveniosoftware/invenio-openaire
inveniosoftware/invenio-opendefinition
inveniosoftware/invenio-orcid
inveniosoftware/invenio-pages
inveniosoftware/invenio-pidrelations
inveniosoftware/invenio-pidstore
inveniosoftware/invenio-previewer
inveniosoftware/invenio-previewer-ispy
inveniosoftware/invenio-query-parser
inveniosoftware/invenio-queues
inveniosoftware/invenio-records
inveniosoftware/invenio-records-files
inveniosoftware/invenio-records-js
inveniosoftware/invenio-records-rest
inveniosoftware/invenio-records-ui
inveniosoftware/invenio-rest
inveniosoftware/invenio-search
inveniosoftware/invenio-search-js
inveniosoftware/invenio-search-ui
inveniosoftware/invenio-sequencegenerator
inveniosoftware/invenio-sipstore
inveniosoftware/invenio-sse
inveniosoftware/invenio-stats
inveniosoftware/invenio-theme
inveniosoftware/invenio-userprofiles
inveniosoftware/invenio-webhooks
inveniosoftware/invenio-xrootd
inveniosoftware/kwalitee
inveniosoftware/metainvenio
inveniosoftware/iugw2017
inveniosoftware/training

Missing license -> MIT
inveniosoftware/invenio-csl-js

Following is a list of affected repositories in inveniosoftware-contrib:

BSD-3-Clause
inveniosoftware-contrib/flask-notifications

GPL-2.0
inveniosoftware-contrib/invenio-checker
inveniosoftware-contrib/invenio-classifier
inveniosoftware-contrib/invenio-groups
inveniosoftware-contrib/invenio-matcher
inveniosoftware-contrib/invenio-metrics
inveniosoftware-contrib/invenio-workflows
inveniosoftware-contrib/invenio-workflows-files
inveniosoftware-contrib/invenio-workflows-ui
inveniosoftware-contrib/json-merger
inveniosoftware-contrib/ng2-json-editor
inveniosoftware-contrib/record-recommender

GPL-3.0
inveniosoftware-contrib/lumberjack
inveniosoftware-contrib/obelix
inveniosoftware-contrib/obelix-client
inveniosoftware-contrib/invenio-record-editor
inveniosoftware-contrib/invenio-tags

Noteably the following repositories are excluded from inveniosoftware and inveniosoftware-contrib:

inveniosoftware/inveniosoftware.org (AGPL-3.0)
inveniosoftware/claimstore (GPL-3.0)
inveniosoftware/intbitset (LGPL-3.0)
inveniosoftware/dictdiffer (already MIT)
inveniosoftware/flask-security-fork (already MIT)
inveniosoftware/timegate (Revised-BSD)
inveniosoftware-contrib/workflow  (BSD-3-Clause)

Repositories in inveniosoftware-attic will stay with their existing license, since these are decommissioned repositories.

Why now?

CERN management wants a Contributor License Agreement (CLA) on Invenio (and all other CERN open source projects) so now is a good occasion to review the license situation.
Feasibility: Invenio v3 has a low number of copyright holders which makes it feasible to contact all copyright holders to ask for the agreement.
We have very few GPL dependencies that can be removed.
Invenio v3 have transitioned from a software to a framework which opens up the use of Invenio for many other use-cases than just digital repositories.

In short, we have a chance to change the license now. This chance will no longer exists in 1 year.

What do we want to achieve?

CERN and EU (aka taxpayers) has invested significant efforts in the development of Invenio as the primary contributor to Invenio v3, and CERN therefore wants to maximize the impact of Invenio for the benefit of society. Hence, we are specifically concerned about ensuring Invenio is useful to not only CERN, but also to universities, governments, businesses and people around the world.

We want to achieve that:

Invenio as a framework does not have legal barriers that prevent future unforseen use-cases.
Commercialization of Invenio that will help drive the dissemination and adoption of Invenio.
Bring economic benefits to industry in CERN member states (i.e. public research funding of CERN have an economic and social impact on CERN member states).

Note specifically, that with the license change we do not want to achieve that more people contribute back to the Invenio source code. However, we believe that a derived effect of a license change will drive an increased adoption of Invenio which will result in increased contributions back to the Invenio source code.

Why not GPL?

GPL is a viral license, meaning that anything else combined with Invenio becomes GPL automatically. This also means that with GPL we have no option for later switching license, and hence GPL can become a legal time-bomb which prevents later commercialization and future use cases of Invenio. This legal time-bomb could be mitigated by transferring the completely copyright of Invenio to CERN, but that involves a lot of bureaucratic and administrative work on both contributors and maintainers. Also, since Invenio is now a framework, we believe that we are yet to see many new uses of Invenio, even way beyond digital repositories. Specifically, GPL prevents developing modules to Invenio which can be kept private and be distributed.

Often GPL is used to force source code contribution to a product. First of all, this is not a objective we want to achieve with the license change, however for Invenio, so far GPL has not a single time been used to force anyone to contribute to Invenio. We believe people contribute to Invenio because they realize a greater value by contributing than if kept private.

Why not Apache v2

The main benefit of Apache v2 is the grant of patent rights. This problem will be handled by a contributor license agreement that all non-CERN contributors will have to sign which will ensure patent rights. Also the license text is much longer than BSD/MIT.

Revised BSD or MIT

Both are very permissive licenses. MIT is the most widely adopted license with some 25-30% of the open source projects using it with BSD at around 5-10%. Revised BSD license explicitly forbids using our names in promotional material without written permission (but this is anyway implicit in MIT). Revised BSD uses words like "use and redistribution" where as MIT is more specific to also mention "use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies"

Who finally decides?

As always we strive for consensus decisions on important topics like this, however in the end it is the existing copyright holders of each repository who have the final say.

CERN commitment to Invenio

CERN is still fully committed to continuing Invenio development.

Externally developed Invenio modules

The proposal is limited to Invenio v3 and direct dependencies. Specifically, anyone can make an Invenio module and license it under whichever license they like (given they hold the copyright). We will however only include Invenio modules in our GitHub organisation which is aligned with our default chosen license. Hence, if you release an Invenio modules under GPL, you will need to host it in your own organisation.

Note that CERN services like CDS, Zenodo and CERN Open Data remains under GPL.

Timeline

October 9th: Discussion in Invenio Developer Forum October 16th: Proposal to CERN IT management to change license. October/November: Contact existing copyright holders to get agreement for license change. November: Implement license change

for Invenio, so far GPL has not a single time been used to force anyone to contribute to Invenio

In fact, a company has used a known loophole in GPLv2 to not contribute, which is why I instead propose to switch to AGPLv3, so that those interested non-contributing developers will not be able to pull this off in the future. In my world view, non-cooperation from someone is answered with non-cooperation from my side, not even more cooperation¹.

Moreover, I don't buy your argument that this is good for Invenio. The past suggests that companies selling Invenio are not going to contribute back. The libraries and the universities that are going to buy services from those companies are not going to contribute back: not having to write code is why they bought the services in the first place. You're claiming that, if those companies are successful, people visiting these services will learn about Invenio, which might lead to more people contributing to core packages. Perhaps, but in order to get those eyeballs you let a company earn (m|b)illions. Maybe a few hundred dollars in targeted ads on your favorite platform would be a more cost-effective option?

Finally, sorry, but Invenio will never be as big as Flask or Django. It aims to solve a fairly narrow problem, of which there's some need for a solution in the world, but not a lot of it. Most people that have ever contributed to Invenio were paid to do so, and I expect this to continue being true in the future.

¹ See: http://ncase.me/trust/

Forwarded this proposal to join2 / join2 steering for evaluation in our project.

The proposed timeline is quite tough to meet, if one wants any comments at all.

In fact, a company has used a known loophole in GPLv2 to not contribute, which is why I instead propose to switch to AGPLv3, so that those interested non-contributing developers will not be able to pull this off in the future.

I must say that indeed contributing back to Invenio 1 was quite complicated and that could explain why a company basing its product back in the days was having difficult to contribute back (one was forced to hack business logic deep into the core of Invenio and this could have been problematic to share). Invenio 3 is instead extremely modular, and indeed it's very clear how one could contribute back to a specific module. A company based on Invenio 3 could have its core business in internal components that don't need to be contributed upstream, while it wouldn't cost anything to simply keep public forks of those Invenio component that are employed in once project, since these will very likely not contain any sensible private business logic or secret value of the company.

@aw-bib Unfortunately the timeline is quite tight because until the issue is resolved, all merging of non-CERN contributions are on hold (as incase we decide to go ahead, we need to ask all copyright holders for permission). Also, I'm open to pull the break in case further discussion is necessary, but I prefer a short, intense and focused discussion.

I'd like to hear both more comments/opinions/arguments for or against the proposal.

@lnielsen I see your point, however, for a response from join2 we need to ask the members. Getting several insitutions(!) into one (even virtual) room is a bit more challenging than just shouting over the floor ;) However, I put your RFC with important markers on the agenda right away and hope to discuss it in our weekly.

@aw-bib I understand your concern, so your effort in putting it high on the agenda is very much appreciated. I'd be interested to know if join2 or the institutions in join2 have an official open source software license policy, and/or if changing from GPL to a permissive license would prevent you from contributing.

I must say that indeed contributing back to Invenio 1 was quite complicated and that could explain why a company basing its product back in the days was having difficult to contribute back

In general I tend not to like the argument "it was hard!" to justify why something was not done, but in particular a representative of this company explicitly said at a meeting with most developers of most Invenio projects at CERN that they were using the GPLv2 ASP loophole.

Purpose

Thanks for the comments so far. Let me just reiterate why we want to change the license:

Library: Invenio has been transformed from a software application into a library that you can mix/match as you see fit. Most libraries in the world are released under a permissive license (LGPL, Apache, BSD, MIT, ...) to not impose a license on downstream applications. Take e.g. Invenio where we only had one GPL dependency out of our ~200 dependencies. Having a permissive license for Invenio makes it easier to combine with other applications and makes it easier to adopt. Also, having a permissive license, doesn't prevent further downstream product to be GPL (e.g. we don't currently plan to change license of Zenodo, CDS etc from GPL).
Commercialization: We want to allow companies and institutions to keep their add-ons private if they so desire (and forks for that sake). More than halfs of CERNs funding (tax payer money) is going back via e.g. procurement to member states to generate economic benefits and competencies in companies in the member states. This is an explicit desire from our member states, that money invested in research at CERN goes back out into society. Having a permissive license ensures more possibilities for commercial exploitation.

Source code contributions

Note that I specifically mention in the proposal that the the purpose of the license change is NOT aimed at increasing source code contributions to Invenio.

We can debate, whether or not increased source code contributions would be a derived effect of a license change, however again, that's not why we want to change the license. Increased source code contributions as a lot more to do with an open community where people see the benefit of contributing than the license. Also, note that we already have an existing project on making contribution easier. But again, this is not the purpose of the license change.

Impact outside CERN?

I'd like to hear more from non-CERN users and contributors how a license change would impact them. E.g. would a license change from MIT to GPL e.g. prevent/allow you from contributing more?

would a license change from MIT to GPL e.g. prevent/allow you from contributing more?

To state the obvious: I guess of course you meant, from GPL to MIT.

On behalf of the JOIN2 Steering Group:

First of all, non of the institutions within JOIN2 have any policy that prevents them from using non-GPL software or to contribute to projects with free, but non-GPL licences. So there is no formal issue from JOIN2 against a change in license.

However, the JOIN2 community believes that the envisioned change in the Invenio licensing scheme does not help to achieve the goals brought forward. Especially, JOIN2 does not see how a change away from GPL addresses

maximize the impact of Invenio for the benefit of society.

JOIN2 does also not share the opinion that

a license change will drive an increased adoption of Invenio

The JOIN2 community believes, that adoption of Invenio is not hindered by using GPL as a licence, while JOIN2 believes that one can expect some cooperation, even from companies, who use for free what was achieved by

CERN and EU (aka taxpayers) has invested significant efforts

JOIN2 want to stress that we especially like the fact that GPL is a viral license and this ensures that everyone (even the taxpayer) can profit from improvements. (In this regard JOIN2 even sympathizes with @jacquerie comment.) JOIN2 sees no real issues with GPL even for extensions around Invenio or businesses build on top of Invenio. JOIN2 is of the opinion that one can build viable business models on GPL software.

We believe people contribute to Invenio because they realize a greater value by contributing than if kept private.

JOIN2 makes the point, that if this is the case there is no need to change the license at all. One can stay with GPL and also to make the clear political statement that contributions back to the project are welcome.

JOIN2 can envision, however, some sort of dual licensing as common in other projects, if ever a need for another license than GPL arises.

isResultOf: join2/join2-data#2017

Alternatively, have you considered LGPL? With that license, modifications to core invenio would need to be open and benefit all of the invenio ecosystem, but a business model could be built around developing and selling closed source extensions.

Though personally I think that AGPL is the best way to go in the long run (ecosystem wise), and that you can still build a business around it, just not by hiding code (you can still sell it, just that you have to give the source code too), I understand that lots of people don't see it that way, and are afraid of using a "really free" license, so maybe LGPL is good enough, at least, that way they will have to publish any changes that they make to the core, then the community can decide if they should be integrated or not.

Just my two cents.

For today's DevForum discussions, I've compiled a draft list of copyright holders for the inveniosoftware repositories. I've only included repositories which are currently under GPL.

Following repositories have CERN as the sole copyright holder:

inveniosoftware/citeproc-py-styles
inveniosoftware/dcxml
inveniosoftware/doschema
inveniosoftware/generator-invenio-js-module
inveniosoftware/invenio-access
inveniosoftware/invenio-assets
inveniosoftware/invenio-accounts
inveniosoftware/invenio-accounts-rest
inveniosoftware/invenio-admin
inveniosoftware/invenio-app
inveniosoftware/invenio-app-ils
inveniosoftware/invenio-archivematica
inveniosoftware/invenio-base
inveniosoftware/invenio-cache
inveniosoftware/invenio-celery
inveniosoftware/invenio-charts-js
inveniosoftware/invenio-circulation
inveniosoftware/invenio-collections
inveniosoftware/invenio-config
inveniosoftware/invenio-csl-rest
inveniosoftware/invenio-db
inveniosoftware/invenio-deposit
inveniosoftware/invenio-files-js
inveniosoftware/invenio-formatter
inveniosoftware/invenio-logging
inveniosoftware/invenio-marc21
inveniosoftware/invenio-migrator
inveniosoftware/invenio-oaiharvester
inveniosoftware/invenio-oauth2server
inveniosoftware/invenio-oauthclient
inveniosoftware/invenio-openaire
inveniosoftware/invenio-opendefinition
inveniosoftware/invenio-orcid
inveniosoftware/invenio-pages
inveniosoftware/invenio-pidrelations
inveniosoftware/invenio-pidstore
inveniosoftware/invenio-query-parser
inveniosoftware/invenio-queues
inveniosoftware/invenio-records-files
inveniosoftware/invenio-records-js
inveniosoftware/invenio-records-ui
inveniosoftware/invenio-records
inveniosoftware/invenio-rest
inveniosoftware/invenio-search
inveniosoftware/invenio-search-js
inveniosoftware/invenio-search-ui
inveniosoftware/invenio-sequencegenerator
inveniosoftware/invenio-sipstore
inveniosoftware/invenio-sse
inveniosoftware/invenio-stats
inveniosoftware/invenio-theme
inveniosoftware/invenio-webhooks
inveniosoftware/invenio-xrootd
inveniosoftware/iugw2017
inveniosoftware/metainvenio
inveniosoftware/training

Following repositories have multiple copyright holders:

inveniosoftware/cookiecutter-invenio-module
    CERN, TIND
inveniosoftware/domapping
    CERN, TIND
inveniosoftware/invenio-communities
    CERN, jainaman224
inveniosoftware/invenio-files-processor
    CERN, xiaom
inveniosoftware/invenio-files-rest
    CERN, University of Tubingen
inveniosoftware/invenio-github
    CERN, TIND, kapadia, dan-blanchard, cglewis
inveniosoftware/invenio-i18n
    CERN, TIND
inveniosoftware/invenio-indexer
    CERN, TIND
inveniosoftware/invenio-jsonschemas
    CERN, sulami
inveniosoftware/invenio-mail
    CERN, TIND
inveniosoftware/invenio-memento:
    CERN, cg-cnu?
inveniosoftware/invenio-oaiserver:
    CERN, TIND, University of Tubingen
inveniosoftware/invenio-previewer:
    CERN, targos, jainaman224
inveniosoftware/invenio-previewer-ispy:
    CERN, tpmccauley
inveniosoftware/invenio-records-rest
    CERN, RERO, TIND, satwikkansal
inveniosoftware/invenio-userprofiles
    CERN, guptavaibhav18197
inveniosoftware/invenio
    CERN, TIND, Adam Lawrence, Ivan Masár, João Gonçalves, Xiao Meng, evelthon

Note that this is a draft list and may contain errors.

As a long-time OSS champion at CERN and a member of the task force which penned the original recommendation for CERN to adopt a default GPL policy, I too once believed that GPL and dual licencing was the answer. However experience over the past year of putting this into practice has exposed me to the complications and pitfalls, and I am no longer convinced it is the best way. Firstly, to dual licence you must have unanimous agreement of the copyright holders. The more holders, the less likely, easiest with a unique copyright holder; but copyright transfer was never cleanly established in v1, and isn't the norm in the world, quite the opposite. Secondly you don't dual licence to a permissive version, you dual licence to a completely closed one dedicated to the purpose, and what you define the "purpose" to be is complicated both legally and philosophically. Hence instead, to establish from the start a permissive licence for v3, without copyright transfer as it is unnecessary and undesired, that is just as encouraging of OSS contributions but in addition does not exclude or discourage commercial usage, is a more natural fit. It also aligns us with the majority of real-world packages that we ourselves rely on, and the OSS based business models that we see.

As an extremely minor contributor, I'm neutral towards the change. Feel free to let me know when there's something to agree to or the CLA to sign.

If I can give my 2 cents, I have the feeling that the GPL choice (as Tim Smith also expressed) was the right choice a few years ago, when the culture around open source and sharing was really different, when the web was much less invaded by web projects/frameworks and when big companies feared open source. In my humble opinion, nowadays, the culture around open source projects has changed: with this "rush" to release software as open source, that hit a very large part of companies that are working with the web, it becomes natural, the way to do, to people to contribute back, and not the contrary. If it was not the case, GPL would have been chosen by most of the projects, wouldn't it? https://www.whitesourcesoftware.com/whitesource-blog/open-source-software-licenses-trends/

A very similar topic is discussed here, when Meteor js long time ago (5 years ago!!!) decided to change license to MIT, and in the infinite discussion on HackerNews, a couple of comments can, in my opinion, summarize and maybe help to understand the choice of CERN/Invenio:

GPL restricts the pool of potential collaborators.

Also, GPL has served its purpose: these days 1) almost everyone realizes that it is in
everyone's interest to share code and contribute back (maintaining private forks is
expensive in the long term), and 2) most software is offered as a service and the value
is not just in the software, but also in the infrastructure, maintenance, support, etc,
meaning you rarely encounter the problem of restricted liberties because of a
software license.

GPL requires you to give back; MIT gives you the choice. Developers are by nature creative
people. And humans are not incapable of altruism. Even with an MIT license, I expect
a lot of community contributions to pour in.

In fact, I expect more community contributions to come in. MIT means (perhaps) a lower
percentage of users will give back, but there will be a higher absolute number of users
since the license is more permissive.

To finish, I am strongly convinced that companies will contribute back, to avoid to go through upgrade nightmares on diverged code, or they will be stuck with old releases on Invenio and customers will then complain... or they will simply choose better companies!

Just my personal opinion (not join2, not my employer or whoever).

IMHO the reasoning against GPL is a logical circle. So far the reasoning is

We needed GPL back then because companies feared Open Source.
Nowadays, companies live in Open Source and release everything in Open Source anyway. There was a change in culture and a rush to release. (Only slightly exaggerating the points made, just for clarification.)
Because companies live in Open Source, one needs a "more permissive" license and not something viral like GPL.
That is required, because companies need the possibility to hide back something to rise their share holders value.

This is contradictory.

If a company really lives in Open Source (A)GPL would not hinder them in anything. They'd release all their stuff anyway, and if we see a change in culture (A)GPL would be a natural thing to them. It would also ensure that the competitor does the same. If we do not see the change in culture we should head for it, again we are at (A)GPL.

Companies only need something "more permissive" if they do not want to share everything. To keep something private to be "better", to "raise their corporate value". (This is also in line put forward by @lnielsen in Dev Forum.) I buy this point as a reason, but I do not support it.

At some point it IMHO boils down to the question what I buy from a company. In Open Source I would not buy software, but I would probably buy the hosting and other services around it. So it is unimportant that the software is really open or not. I'd even go so far as to say that the software as such is entirely unimportant and interchangeable in this framework as long as the service stays the same. Hypothetically, Open Source would give me as a customer the advantage of the vague possibility to switch my service provider, so I could argue that this is an advantage for a business running on Open Source software.

Furthermore, where I usually lack openness is when it comes down to interfaces. Naturally, the interface definition has to live within the code where I need this interface. At least this definition has to be free to ensure that I could live on an interface even if a company just looses interest in supporting anything on it. (Here I could follow @david-caro argument for LGPL, or more generally non-AGPL, as a minimal requirement.) Much of the hackish stuff I need to do (I'd not call this "development") is exactly fixing such issue, working around it, up to the point of reverse engineering some strange protocol or format.

Given software being interchangeable, but interfaces are not, while I also run more and more on services that communicate with one another via interfaces, IMHO today GPL is required even more than ever to ensure that free software stays free and usable.

To me, as a tax payer, the latter is also of foremost importance. Just if one wants to make a monetary point.

The more natural reasoning is that you are of course free to swing your fists. But this freedom ends at the tip of my nose. So what you call restriction of freedom may just be ensuring its persistence.

Seeing how the licensing discussion evolves, I sense a certain split in the community that makes me feel uneasy. Having steered Invenio project for about fifteen years, I would like to bring some late-night musings on this touchy topic. I hope my reflections might be useful in bridging the two perspectives. Everybody is entitled to their opinions, and discussions about licensing are usually very opinionated. Here's hope that my musings won't add even more fuel to the fire.

TL;DR One can argue that (1) with GPL, the community has lower potential for growth, since there are some public users (and most private companies) that would refrain from entering that territory; however the final product is guaranteed to remain free software for the community. While (2) with LPGL/BSD/MIT, the community has higher potential for growth, which can improve the product; however at a risk that the non-free software in the ecosystem might take larger and larger share, perturbing the hitherto free ecosystem. The decision is a judgement call, the outlook is uncertain, the opinions of software creators and of free software advocates will likely differ. Seeing some opinions going predominantly in one or the other direction, it is important to try to consider the perspectives with a balanced point of view, to ponder not only the pros but also the cons and vice versa, to reflect on the strategical implications of mixing free and non-free components and how it might affect certain use cases in our ecosystem more than others. Finally, it would help to better clarify the motives behind the move, because a sentence like "Note specifically, that with the license change we do not want to achieve that more people contribute back to the Invenio source code" might look really puzzling.

Nicola rightly highlights that the times have changed since the days of old (e.g. Microsoft is now amongst the top open source code contributors on GitHub; who would have thought?) and that the permissive licenses such as MIT have been gaining momentum in recent years thanks to amongst others the web development technologies. However, note that GPL remains the most popular license choice out there; the very quoted article permits to conclude that GPL remains at the top with 34% market share (19% for GPLv3 and 15% for GPLv2) over 25% for MIT. (The article itself says so later on, even if their choice of introductory picture was to present the findings otherwise, with MIT on top over GPLv3. In my eyes, when one compares the market share of web browsers, one should be comparing the overall impact of say Firefox and Chrome, not studying Firefox 54 and Firefox 56 apart.)

Nicola also rightly highlights that the companies have very good incentives to contribute to some of the free-software components they use. However, this is only one part of the picture. The companies also have very good incentives not to contribute those components where they perceive their competitive advantage, making them non-free and closed-source. A possibility to mix free, open-source components with non-free, closed-source components is precisely the at the core of LGPL/BSD/MIT existence.

From the point of view of a software creator, let me borrow the above quote to illustrate the core of the thinking:

MIT means (perhaps) a lower percentage of users will give back, but there will
be a higher absolute number of users since the license is more permissive.

This is exactly the heart of the matter and I think the word "perhaps" is the key here. It cannot be easily foretold what such a license change brings; it could foster the free-software part of the ecosystem, just as it could foster the non-free-software part of the ecosystem. One only speaks of probabilities here.

From the point of view of a free software activist, the same "perhaps" appears. Let me borrow the GNU/FSF musings on why it is sometimes bad and sometimes good to use LGPL over GPL:

Using the Lesser GPL for any particular library constitutes a retreat for
free software. It means we partially abandon the attempt to defend the users'
freedom, and some of the requirements to share what is built on top of
GPL-covered software. In themselves, those are changes for the worse.

Sometimes a localized retreat is a good strategy. Sometimes, using the
LGPL for a library might lead to wider use of that library, and thus to more
improvement for it, wider support for free software, and so on. This could be
good for free software if it happens to a large extent. But how much will
this happen? We can only speculate.

It would be nice to try out the LGPL on each library for a while, see
whether it helps, and change back to the GPL if the LGPL didn't help.
But this is not feasible. Once we use the LGPL for a particular library,
changing back would be difficult.

So we decide which license to use for each library on a case-by-case basis.

I think this summarises nicely the feeling of a free software activist as well. The licence change from GPL to LGPL/BSD/MIT is basically a "gamble" that the change will help to increase the user base of the free-software ecosystem, even at the price of inviting non-free components, and that this change will overall benefit the original free-software community. However, it is a decision that is fully speculative, and to be pondered rather carefully.

Historically, Invenio has been using GPL from its inception in 2002. It has been developed mostly at CERN for the purpose of running various particle physics services. It has been adopted since 2002 already by various organisations, institutes and libraries both small and large. The adopters were usually not bothered by the GPL license; in fact, the GPL license was typically considered a big plus, because the licence gave a moral ground that any improvements will be shared within the ecosystem for the mutual benefit. When there was a good reason to change the license later, such as for intbitset library (moved from GPL to LPGL at the demand of an Apache project), or for Flask-* extensions (moved from GPL to BSD that the Flask ecosystem natively uses), the proposed change was always approved by the respective CERN and non-CERN code contributors. It was a painful work to change the license, and this energy could have been devoted elsewhere; but the potential benefits were considered worth the trouble, and we did see minor code contributions coming after this change.

Enter 2017. Widening the license change from GPL to LGPL/BSD/MIT upon all Invenio components may be seen as a rather categorical move. On one hand, it is a logical continuation of the Flask-* licensing changes mentioned above (and one could argue that the logical licence choice would be BSD for us). This is especially true for our "base" technology components. Invenio can be seen as a configurable Flask application builder helper, so to speak, usable for any Flask application outside of the strict digital library domain. (RECAST's need for OAuth comes to mind.) However, on the other hand, and especially for our "add-on" components, it can be questioned whether say Circulation is truly of "library" nature, and not rather a complete "app" that services would usually develop on top of the said libraries in their overlays? Be it as it may, there is also a certain beauty and practical advantage behind using the same license for all Invenio components.

A possibility that the "circulation app" may be likely open-source, if developed by a public institution, and likely closed-source, if developed by a company, is something that the licence change from GPL to LGPL/BSD/MIT would encourage, as it were, since the "moral imperative" to share associated with GPL would not longer apply. This brings an inevitable question of how the ecosystem of mixed free and non-free components might look like in the future.

Let us imagine that somebody started to use Invenio because they liked a particular feature set, e.g. support for a particular data format (MARC) or a particular digital repository flavour (multimedia management) or a particular add-on application (keyword tagging). Imagine that such a feature is a mandatory must-have to some members of the ecosystem, while an optional nice-to-have to other members of the ecosystem. Now imagine the original developers stop supporting the given feature set for a reason or another, for example the business priorities change, the funding models change. The hitherto maintained feature set is now at a risk of no longer being maintained. How is this situation handled under different licensing scenarios? With GPL, one can always take up the original code, but the members of the ecosystem must find resources to take up its maintenance. An optimist might argue that if the community has grown sufficiently large, then there will be opportunities to take it up. A pessimist might argue that funding in our domain goes smaller and smaller, so that this would be a problem, and people might have to move elsewhere. With LGPL/BSD/MIT, the commercial players can enter the game and offer their services. An optimist might argue that it is great that the commercial providers can fill the hole, and that the free market competition will ensure the reasonable pricing at the end. A pessimist might argue that the commercial vendors will try to lock their users up to their clouds, and aim at Elsevier-style profits. I am exaggerating, obviously. The point is, nobody knows. The glass can be both half-full and half-empty, and people are likely to disagree about the probabilities of those optimistic and pessimistic scenarios, based on their personal outlook, the past experiences, and the knowledge of our concrete ecosystem.

In any case, the arrival of non-free software components into a hitherto essentially free-software ecosystem will create an imbalance, where some use case applications and components might thrive thanks to the increased overall usage, while other use case applications and components might struggle or might become the domain of the non-free in longer term. That's the example of a dilemma of the free software activist applied in our particular domain.

The choice of a more permissive license is basically an expression of trust that the overall benefits will be worth it in the longer-term. From a software creator point of view, the likelihood looks good. From a free software advocate point of view, the opinions will likely differ, as will the assessment of dangers for each concrete beloved feature set of our current ecosystem.

It is up to us, the Invenio community, to try to set the rules so as to maximise the opportunities and minimise the risks. Building a healthy cooperating ecosystem may be more important than the concrete license choice. History have seen GPL, BSD, and MIT communities both thrive and struggle. Even GNU Affero GPL cannot guarantee any shield from the hard case scenarios outlined above, when projects are impacted by hard real-world events. A good recent example might be the acquisition of ShareLaTeX (free software, open source, AGPL licensed) by Overleaf (non-free, closed-source). People who build their future around ShareLaTeX now face the same hard questions I raised above.

The LGPL might be a better middle-ground choice thanks to our GPL past; the BSD might be the most logical choice to align to the upstream Flask ecosystem; the MIT might be the most second-popular choice (after GPL!) out there. Whatever license we choose, we should quickly start pondering about how to improve the ecosystem practices, so that the pros would really outweigh the cons, and not the vice versa.

@tiborsimko I buy all your reasoning especially that it is a gamble.

I would still argue, that, if the main goal is to increase the number of installations the license (given the ones mentioned) is not of that much importance. One would surely have a much larger impact with regard to this, if invenio would "just" be packaged in standard distributions and run on the usual server suspects in some flavour where I can see what it can do, without requiring programmers to set it up.

it is great that the commercial providers can fill the hole, and that the free market competition will ensure the reasonable pricing at the end

I am not sure that a market exists in the domain in question at all. If it exists, it's most likely an oligopolistic (if not even a monopolistic) market. So it is hard for me to buy reasoning based on competition, marked, free forces etc.

OTOH I still do not see anything that hinders integration of some closed source services with a GPL framework provided you contribute the interface. In this case, if the market looses interest, one could at least replace the missing part, as you say by finding the resources to do so.

First of all, I'd like to thank everybody for participating in the discussion and for providing a lot of valuable feedback, and especially also for accommodating the very short timeline.

Open Source license discussions, especially permissive vs copyleft, have the potential to ignite very strong feelings, as the discussion often boils down to strong differences in ideological beliefs. Hence, I'd like to also say thank you for keeping an open, considerate and respectful discussion. I believe it is highly important for a community and a healthy sign to be able to have these hard discussions with strong disagreements in an orderly fashion so that we can continue together afterwards.

I acknowledge that there are strong differences in opinions on this proposal, both outside but also inside CERN's Invenio community. I believe those strong differences boil down to above-mentioned differences in ideological beliefs. In both cases, i.e. adopting the proposal or staying with GPL, it will be a gamble where we can only speculate about the possible outcomes.

I've noted that the proposal will not have a direct negative impact on the existing community, in the sense that users already using Invenio can continue using Invenio, contributors already contributing to Invenio can continue to contribute. Long-term impact, as mentioned before, we can only speculate about, and there are pros and cons no matter which license we adopt.

I believe that due to the ideological differences it will not be possible to arrive at a consensus decision on the proposal, even if we let the discussion run for another month or two. Also, as already mentioned in the proposal, the final decision is taken by the existing copyright holders, as these are the legal owners of the code and the ones that legally have to agree to license change.

In that respect, CERN is the majority copyright holder of Invenio v3 having contributed more than 95+ % of Invenio v3 source code so far. The current situation with GPL plus shared copyright between potentially 100s of contributors is something that CERN believes is an unacceptable legal time-bomb because downstream it will be impossible to revert this decision. Even if the entire community later agreed to go with another license, a single contributor could veto against that decision. Having invested large efforts in Invenio, this is a risk CERN is not willing to take. Hence, we must take a conscious decision now, while we still have a choice.

We (CERN)[1] believe going with a permissive license like MIT is the right choice for Invenio for the reasons we have listed in the proposal and reasons given during the discussions. We believe an alternative, e.g. GPL with copyright transfer to CERN, would have a negative impact on contributing to Invenio as well as be very hard to administrate.

Therefore, considering that a consensus decision will not be possible, considering that a decision must be taken before it is too late, considering that CERN is the majority copyright holder and cannot accept the current license/copyright situation, and considering that the proposal will have no direct negative impact on using or contributing to Invenio for the existing community, I (as Invenio Product Manager) decide to continue with the proposal of changing the Invenio v3 license to MIT license. I take this decision only because I believe a consensus decision cannot be reached on the proposal, and thus I also fully understand that part of our community do not agree with the proposal. I am therefore also happy to take criticism, both public and private, and further discuss the decision, but I do believe I've tried to take a balanced decision.

The final decision still rests with the existing copyright holders, whom I will now take contact to get a legally binding confirmation that they agree to the license change.

Last but not least, I'd like to highlight what Tibor said:

building a healthy cooperating ecosystem may be more important than the concrete license choice

I fully agree with this statement, and I'm fully committed to building that ecosystem in collaboration with all of you.

[1] "We (CERN)" should be understood as CERN's official opinion on the matter as decided by CERN management. I fully acknowledge that some Invenio developers at CERN do not share this opinion.

Specifically GPL prevents developing modules to Invenio which can be kept private.

This is incorrect, as written. See FAQ:

The GPL does not require you to release your modified version. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.

https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#GPLRequireSourcePostedPublic

You are right, the correct sentence should read:

"Specifically, GPL prevents developing modules to Invenio which can be kept private >> and be distributed <<."

I've updated the text.

Thanks! That's right.

inveniosoftware / invenio