-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GPL License is not suitable for this project #159
Comments
Thanks for the issue. My first hunch would be to change to AGPL-3 (that's also what UnityStation did, see unitystation/unitystation#2057), but I need to read some more about the topic. What would be the other issues with AGPL you're mentioning? There are two reasons for why we chose a copyleft license:
|
The AGPL does not solve the first issues. AGPL is still incompatible with the Unity license (according to the FSF). The LGPL was created specifically for use with plugins to avoid this ambiguity. So I assume that you'd need something like a mix from the LGPL and the AGPL; but I don't think such a thing exists.
I only skimmed over the issue (because it's very long) and there either seem to be many misconceptions or statements which are confusing (out of context?). However, the "schools of thought" are actually described here: https://en.wikipedia.org/wiki/GNU_General_Public_License#Libraries So it's a theoretical issue until someone actually takes it to court. You can stick with the GPL, but the library / Unity thing isn't the only issue (as described above), so I feel like you will have to make some choice anyway (depending on what your goals for VPE are). If you stick the LGPL on it, there's a new issue:
So it's a tricky situation. It all comes down to what your intention is with the GPL. Are your license goals potentially inherently incompatible with projects like Unity? In that case you'd have to drop to weak forms of the GPL (LGPL) or non-GPL, which might lead to new closed-source code.
That's a much bigger issue that I wasn't aware of. You can't just take the code and re-license it yourself. However, the MAME license is incompatible with the GPL. If you wrote it from scratch and it isn't a derivative you can make your own choice, but then you shouldn't be restricted to ~"this is close to MAME". MAME also isn't just GPLv2; it's a mixture of BSD licensed code and GPL code. So typically binaries will be GPL, but much of the code is BSD licensed.
(It gets really theoretical here, so feel free to ignore this, depending on where this project is heading) The AGPL might complicate distribution because if you add features like network play (or hooking up things over network, like a Stern Spike nodebus), then you must offer the source-code to that version of VPE to the network user:
Sending that offer might not be easily possible (integration with UI) without a centralized system. However, it's probably such a niche theoretical legal issue that you don't have to consider it. But it shows how the AGPL isn't really meant for this sort of situation either. So with the future of computing, it's tricky to see what other issues will arise. Additionally the AGPL has some compatibility issues with GPL code: https://en.wikipedia.org/wiki/Affero_General_Public_License#Compatibility_with_the_GPL |
Well, UnityStation seem to have their interpretation confirmed in writing by Unity and Steam. But there are many other points. Interested in discussing this on our Discord? |
About your first point, wouldn't this cover it? |
I don't think they do? Where is this?
I don't join new Discord servers because I don't like that service. I only remain on servers that I have to be on for previous FOSS contributions.
No, for 2 reasons:
The 2 more interesting FAQ points are these:
Long story short: I don't think the GPL is suitable. At very least you should be dual-licensing. Especially with the license issues in PinMAME and VPX (and previously MAME) and their intended goal of preservation, it would be very unwise to develop a replacement (of any sort) under a new license which would lead to the same issues again. I think the lesson learned from MAME is that dual licensing and something permissive like the BSD-License is the way to go. You should make those decisions now, while the project is still small enough and you can still reach all contributors to get their permission. |
They say so in the issue. I said "UnityStation seem to [...]"
"new" Discord servers? So you're on Discord but you don't like ours?
Fair enough. So your point is that if we added an exception and ever wanted to use a GPL-licensed piece of software, we couldn't?
We could add the exception only to the Unity-specific code. They are different sub projects. I mean if it's a legal issue, there wouldn't be a use case where any other GPL-software would want to use VPE's Unity code without having that exclusion in there as well. I'm currently leaning towards that. The VPX MAME license issue is being worked on. VPE only ports a small part from VPX, and it might be possible to get that code re-licensed. |
I disagree with some of the Discord tech/politics and Discord as platform. So I avoid adding more dependency on Discord (= I don't join any other ["new" for me] servers). However I still remain active in some Discord communities that I have used for a long time, until they have alternative communication channels. (I guess I'd describe it as "I am on Discord but I don't like Discord (but begrudgingly keep using it in limited form)")
Yes. That's the problem I perceive. Adding exceptions is tricky anyway, because you can't just add another exception in 20 years without contacting all contributors again (unless you have a CLA). However, you might need more exceptions in the future, if someone asks "can I use this with [project/store/engine that will first be created in year 2040]" / when Unity project renames itself / .., etc. Exceptions also still don't fully solve the app-store and streaming issues. The app-store problem has not been interpreted by the FSF yet (I think), and the streaming issues are unrelated.
In theory: yes. However, the exception still wouldn't make it possible to run VPE on some game consoles because their only way for software distribution might be app-stores (which typically ban GPL code, because the GPL allows buying a single copy, and duplicating it - which defeats the core idea of most app-stores). This typically even affects free (as in free-beer) software. You probably must also have the exception on the non-Unity portion, too, because otherwise linking the GPL and GPL-with-exception code would probably violate your own license. You also have to consider potential exceptions for other proprietary code like https://github.com/JayFoxRox/stern-pba-emu. The integration of that in PinMAME is already very sketchy and almost certainly violates the MAME license at time of use (and would probably violate the GPL, although it might be protected by the system library exception). If you want to stick to the core idea of the GPL (= force code to remain open-source at all cost), I'd suggest AGPL with a lot of exceptions - but you have to realize that you likely can't legally connect it to very useful GPL projects like QEMU (including potential benefits like Stern Spike emulation). If you'd still connect those portions (or advertise them as being compatible), you run the risk of being sued by companies like FarSight, Stern or some license-trolls in the future (over your own license). You might also scare away contributors or users who disagree with the ethics or legal issues this poses for them. We also don't know what the future will hold for us. Maybe some pinball company will be sold to another huge corporation which has a different legal interpretation and isn't so community friendly. So it would be good to consider these things. |
Okay, so to summarize, there are two main aspects. I think it's important to state that everything we've talked about is about redistribution, VPE as-is doesn't violate anything apart from the MAME-licensed code, which is being worked on.
Our options are:
The main issue I'm seeing here is that everything but keeping GPL would block us from using GPL dependencies. Ironically, a potential one is your |
From Unity i'm sure I have it, in writing. But i'm not going to release private emails, its bad form (unless I have to, due to a lawsuit for example). I don't do so for clients and I don't do so for opensource projects I work(ed) for, it opens a box of pandora. edit To be clear: I agree GPLv2 is NOT a good choice for a unity game. GPLv3 excludes certain linked-software/plugins, which GPLv2 doesn't. Under GPLv2 you might indeed have a violation on your hands. About the options from @freezy :
I wouldn't suggest any of those options.
There are many forms of GPL and many forms of stupid people. I think following internet discussions about "GPL" by random people isn't the best source to base legal decisions on. (In this case GPLv3 is significantly different from GPLv2 for example)
The FSF can say you need to eat your mother according to GPL, that doesn't make it true. You use their licence text, thats all. That doesn't give them or GNU folks or who-ever, the right to (re-)define things after-the-fact. Important points to consider:
|
Makes sense. I'll talk to all the contributors in order to reach a conclusion. Thanks for your help @Ornias1993! |
Hello. I am fine with changing the license to GPLv3. |
Hello. I am fine with changing the license to GPLv3. |
I am fine with changing the license to GPLv3. |
I'm fine with changing to GPLv3. |
I'm fine with changing the license to GPLv3. |
That leaves: @shaderbytes and @ravarcade to give permission and then you're fine to change licences @freezy 👍 |
I'm fine with changing to GPLv3. |
GPLv3 sounds good , go for it |
Alright, got the okay from everybody. Thanks all involved, specially @Ornias1993 for your help and @JayFoxRox for raising the issue. We're GPLv3+ now! |
The GPL is not suitable for this project for multiple reasons:
There are probably other reasons I couldn't think of yet.
A CLA or dual-license could prevent this. LGPL solves the first 3 issues, but also causes some new ones.
It's not documented what the intention behind the GPL are (for this project), so it's hard to discuss alternatives or make a suggestion.
All I can say so far is that the GPL doesn't seem suitable here.
The text was updated successfully, but these errors were encountered: