Change PyPSA-Earth license to MIT or AGPL #693
Comments
|
I am not very familiar with these licensing questions so please forgive me if I am off-track, however, would AGPL potentially deter governments and other institutions (TSOs, SOEs etc) from using pypsa-earth since they would have to release modifications they make to the code? If that is the case then I would argue it would be better to go with a fully open MIT license. |
|
If TSOs and SOEs use it only in their own company, AGPL or GPL will have no impact. They can change the code and don't need to share it. If a consultant that often works in the background of these companies wants to share the code with others, they need to share the source code changes in the open as it counts as distribution. Moreover, TSOs and SOEs are concerned not about the source code but about personal data. This is also the reason why big TSOs like RTE or Alliander also develop MPL licensed (copyleft similar to GPL) software like powsybl, OpenSTEF and OperatorFabric. Saying that, it is possible to mix non-open data and open-source software. |
|
Personally, I am ok with both AGPL and MIT. Before opening to MIT, may be worth giving it a go with AGPL first. |
Awesome. Added a trophy for you in the text above 🏆 👍 |
|
I think AGPL will help in more contribution to open source cummunity 🦺. |
|
You can put me in as 🏆 |
|
I agree that there might be concerns regarding (A)GLP usage, especially when institutions are involved. My feeling however is that PyPSA-Earth is intended to be applied in the regions where
Given such circumstances, additional pushing towards more openness and transparency might work well. So, I'd go for AGPL for now 🦺 |
|
I think the MIT license fits best |
|
thanks @GridGrapher 🚀 What is the reasoning for it? Maybe it can change the current mood. Do you have any hard feelings about AGPL or would you be ok with a trial and we add you as🏆? (We ideally need a consensus) |
|
The AGPL license has an "infection" problem, becuase any software project that uses AGPL-licensed code must also be licensed under the same license. And since not every software project is suited as an open-source project, this means that the audience for adoption is mainly limited to businesses that already contribute to open-source. We know that is not the case in the energy industry. Anecodotally, I work at a global energy company that works with most of the TSOs in the world, and we are not allowed to touch code that is not MIT or Apache 2.0 as a matter of policy. In my opinion, the way to work with TSOs/goverments/consultants is to show the cool side of open-source (high-quality, well-supported, transparent) rather than forcing it down their throat. Unlike most of the agpl web-apps (like edx, mattermost, mastodon, overleaf, civicrm, nextcloud, r-studio, etc), PyPSA-Earth is not designed to run on a server out-of-the-box. So a huge effort will be required to turn it into an API or complete web app, which should serve as a deterent for businesses looking to be free-riders. More comparably, osemosys-global is MIT-licensed. All of that being said, some unconventional thought should be given to the licensing matter. In particular, how contributions can be made back to pypsa-eur (now MIT) on which pypsa-earth has been based on/inspired by. |
|
Thanks @mnm-matin, for voting 🏆 and for diversifying the discussion. There are pros and cons for both MIT and AGPL. AGPL is not infectious and good for self-hosted, non-library code. Google is probably the most well-known actor that puts restrictions on AGPL use and requires developers to get an OK first (see here and a lot of pro/con discussion on hacker news 11 months ago). You can use the code locally without needing to share anything. As mentioned here, TSOs and DSOs were never famous for coding; however, some leading OS actors in the TSO/DSO domain move towards the copyleft direction promoting open-source. Regarding gov adoption. I guess, if we increase the utility of the code, people will adopt that no matter what. The people working at govs/ NGO's will thank us for helping them by giving with AGPL arguments for contribute to the OS world. |
|
🏆 |
|
🦺 |
|
🏆 |
|
I think we can try AGPL first 🦺 |
|
🦺 Trying AGPL first sounds reasonable to me. I don't oppose to MIT though, specially since PyPSA and PyPSA-Eur have a MIT license |
|
🦺 |
|
🏆 |
3 similar comments
|
🏆 |
|
🏆 |
|
🏆 |
|
You can put 🦺 as my vote. |
|
AGPL sounds good to me |
|
🦺 |
|
The vote is closing now. The remaining colleagues abstain from the license voting.
I am working on the license change today. Thanks all for taking part in the discussion. I am excited to see where we hit the boundaries of this decision. It would be great to show others that AGPL can work as for the other references 🥇 🥇 🥇 |
|
To be added to a list: EmreYorat definition of a shortcut for West Asia region 3fb02de An amazing discussion and a very interesting result :) My feeling it's going to be a fascinating experiment! |
|
🏆 |
and others
Relicensing from GPLv3 to AGPLv3 or MIT
Summary. In my opinion, staying with the GPL does not make sense. We should either move to the more liberal MIT version as PyPSA-Eur or PyPSA or close that GPL loophole with AGPL. Being different and testing PyPSA-Earth as AGPL licensed version is currently my favourite. I am curious what you think reading the below and having yourself informed. We aim to decide on this matter within the next 4 weeks (19.05.).
When we started expanding the PyPSA-Eur work from Europe to Africa and now Earth, we contributed because we believe that open energy planning is the way to unlocking tremendous benefits for society. The openmod manifesto and the paper by Pfenninger (2017) "Energy scientists must show their workings" are two prominent articles that provide a detailed discussion on that matter. In general, we believe that open energy modelling lead to better, faster and more sustainable decision-making, which is urgently needed including for the energy transition.
In contrast to MIT license, our current applied GPL license guarantees that any distributed work of the original GPL-licensed PyPSA-Earth software needs to stay open. For instance, if someone builds on, modifies or shares our model while distributing it, they also need to make the source code available, including the original GPL license. Does it mean you must share your code/changes on your local machine? No. You can do what you want if you don't distribute any work from the code. You might ask now, why do we need then AGPL? People discovered a loophole in the GPL which allows, for instance, software-as-a-service (SaaS) providers to use and modify open-source without sharing the code with the community. This can be risky for the open modelling community because such actors can say that they are using open-source, but we don't really know what good or bad changes are made to the model. Exploiting the value of open-source, they might also slow down other actors that want to keep everything open for good.
Accordingly, the AGPL was invented to motivate SaaS operators to keep the source code open. This FOSSA article puts that in more explicit words: "The idea behind the AGPL License was to address the 'application service provider (ASP) loophole,' which both Henry Poole and Stallman believed existed in the GPL. The ASP loophole meant that software-as-a-service (SaaS) providers and other software that ran primarily over a network were exempt (or could potentially argue exemption) from the terms of the GPL license. This is because they didn’t technically 'distribute' it in the traditional sense."
How could we change the license?
IP lawyer and licensing expert Heather Meeker indicate that in her book (see references, p. 235). In particular, relicensing old code is not possible, but it is possible that any future code can be licensed as AGPL. So old PyPSA-Earth version will always remain GPL, but we can move as a community forward with AGPL. To avoid mixed licenses, we should ask for consent to relicense all existing code to AGPL.
What we need to do to move to AGPL:
Are there successful examples of AGPL projects?
Common arguments:
➖ building SaaS application on PyPSA-Earth will require code sharing
➖ contributing from PyPSA-Earth to PyPSA-Eur will be, in theory, more complicated
➖ lose users when moving to AGPL (maybe talented contributors?)
➖ there are ways around the AGPL which might not require code sharing e.g. not using PyPSA-Earth directly
➕ the ideal of open energy modelling space is as much enforced as possible
➕ GPL/AGPL is a good argument for any actor to contribute code in the open (I made the experience)
➕ lose users when moving to AGPL (maybe people we want to lose? popularity looks exponential anyways? no contributor gain observed when PyPSA moved to MIT?)
➕ when there are ways around AGPL, why not use AGPL and live with the ideal?
Current contributors that needs to decide (please comment below with any of these emoji's)
Ok with AGPL, GPL or MIT 🏆, Ok with AGPL 🦺, Ok with MITⓂ️ , Ok with GPL 🧞
@davide-f 🏆Ⓜ️
@pz-max 🦺
@ekatef 🦺
@DeniseGiub 🏆
@mnm-matin 🏆
@hazemakhalek 🏆
@energyLS 🏆
@Tomkourou 🏆
@giacfalk 🦺
@Ekaterina-Vo 🦺
@euronion 🏆
@LukasFrankenQ 🏆
@AnasAlgarei 🦺
@Tooblippe
@koen-vg 🦺
@juli-a-ko 🦺
@GridGrapher 🏆 &
@squoilin
@stephenjlee
@EmreYorat 🏆
@oayana
@ykuvvetli
@jarry7 🦺
@yerbol-akhmetov 🦺
References:
The text was updated successfully, but these errors were encountered: