GPL License is not suitable for this project

[JayFoxRox]

The GPL is not suitable for this project for multiple reasons:

• Incompatibility with Unity-License for example (Unity is not GPL licensed, so linking it means that the user is causing a license violation, this quickly leads to the GPL becoming meaningless, so some users might argue that the license is void).
• Incompatibility with app-stores. Many app-stores (think mobile phones, but also game consoles or even desktop OS) do not allow software to be duplicated, but the GPL explicitly allows this. This is why companies like Apple ban GPL software. If app-stores become the only choice for distribution in the future, then the GPL might hinder distribution.
• Some VR libraries will not be GPL compatible, so you might prevent use of VR, even outside of Unity.
• The growing market of Game-Streaming services means that the GPL might be meaningless because it won't be enforceable via network. A company could create a hostile fork that is only accessible via streaming. Users would not be able to demand the source-code. AGPL could prevent this, but also causes new issues.

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.

[freezy]

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:

1. This project contains ported code from Visual Pinball, which still uses the MAME license. GPL-2 seemed the closest to the MAME license (which is also what the MAME project is running under now).
2. We depend on an ecosystem of open and moddable table creations. They are a learning resource and allow faster iterations from other creators. I'm not sure in which way the GPL would prevent creators from distributing their games with VPE as closed source, but the thinking was that a copyleft license would be a good start.

[JayFoxRox]

My first hunch would be to change to AGPL-3 [...]

The AGPL does not solve the first issues. AGPL is still incompatible with the Unity license (according to the FSF).
The AGPL only ensures that you can get access to the source-code, even if you don't have a copy of the program, but only interact with it via the network.

The LGPL was created specifically for use with plugins to avoid this ambiguity.
However, the LGPL might ultimately lessen the strictness of the GP, as new - non GPL - code can be moved into another black-box library (say.. "VPEExtension") which simply extends VPE.

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.

[...] that's also what UnityStation did, see unitystation/unitystation#2057

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.
I am not a lawyer, but I'd argue that UnityStation has the same issue as this project.

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:

• With the GPL someone else can not make a new simulator which is closed-source (like Unity). They can not add another closed-source "VPEExtension" library either to keep their new code away from the GPL.
• With the LGPL someone else can make a new simulator which is closed-source (like Unity). But now, they can also add another closed-source "VPEExtension" library to keep their new code away from the GPL.

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.

• With GPL you are requiring everything to be used (or extended!) as open as the GPL (rejecting other platforms or code / binaries like Unity, VR or App-Stores).
• With AGPL you just make it more aggressive as it also enforces the GPL as soon as the program can be interacted with over network (think multiplayer where someone uses a modified VPE).
• With the LGPL you are allowing everything to be used (or extended!) in projects as closed as Unity (or even more closed).

contains ported code from Visual Pinball, which still uses the MAME license. GPL-2 seemed the closest to the MAME license (which is also what the MAME project is running under now).

That's a much bigger issue that I wasn't aware of.

You can't just take the code and re-license it yourself.
If it's a derivative work it must be under the original license.

However, the MAME license is incompatible with the GPL.
Re-licensing MAME was a huge effort that took a lot of work and time.

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.

What would be the other issues with AGPL you're mentioning?

(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:

From the AGPL License: Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.

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
So it's possible that you'd require AGPLv3 to resolve them, but that might be incompatible with GPLv2-only code, so you'd limit compatibility with existing open-source code (including projects that might be useful for emulation of the Pinball CPUs or similar things).

[freezy]

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?

[freezy]

About your first point, wouldn't this cover it?

[JayFoxRox]

Well, UnityStation seem to have their interpretation confirmed in writing by Unity and Steam.

I don't think they do? Where is this?
Every discussion about Unity and GPL that I find strongly implies that it's not a good fit. The FSF also seems to refer people to their FAQ which says that such combinations are not acceptable.

But there are many other points. Interested in discussing this on our Discord?

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.

About your first point, wouldn't this cover it?

No, for 2 reasons:

• Unity is the program, VPE is the library. So this isn't about "use GPL-incompatible libraries with GPL software?" but "use GPL-incompatible software with GPL libraries?" - and that's what the LGPL was made for.
• If you add an exception to your license, it will be incompatible with other GPL code (which doesn't have those exceptions, because the authors did not give you this right - you aren't allowed to add or remove such exceptions from their license).

The 2 more interesting FAQ points are these:

• https://www.gnu.org/licenses/gpl-faq.en.html#WindowsRuntimeAndGPL
  Unity is in a similar situation; but unlike the MS DLLs, it's very difficult to distribute VPE without Unity if you are shipping to end-users. So this very common exception does not work. You'd basically have to tell people to grab Unity themselves and launch VPE through the Unity Editor. However, even then it's probably a legal nightmare if anybody were to challenge it (determining wether Unity is actually a "System Library").

• https://www.gnu.org/licenses/gpl-faq.en.html#GPLPluginsInNF
  This specifically describes what VPE is: a GPL plug-in which combines into a single combined program with Unity. The FSF tells you to add an exception to your license (which is bad, for the reasons described above: incompatibility with other GPL code) or to rewrite the non-free code (but rewriting Unity is unrealistic).

Long story short: I don't think the GPL is suitable. At very least you should be dual-licensing.
If you want to stick to the GPL (you probably shouldn't), you should probably get rid of Unity and default to a "free" engine which is inherently GPL compatible.

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.
Personally I prefer PD+CC0 or MIT over the BSD-3, but I can see why they went with BSD.

You should make those decisions now, while the project is still small enough and you can still reach all contributors to get their permission.

[freezy]

I don't think they do? Where is this?

They say so in the issue. I said "UnityStation seem to [...]"

I don't join new Discord servers because I don't like that service.

"new" Discord servers? So you're on Discord but you don't like ours?

Unity is the program, VPE is the library.

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?

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.

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.

[JayFoxRox]

I don't join new Discord servers because I don't like that service.

"new" Discord servers? So you're on Discord but you don't like ours?

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)")

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?

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.
- Because this project deals with preservation, you should think long-term, so individual exceptions are also impractical for that reason.

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.

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.

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.
This also gets much more complicated if you also have things like a future version of PinMAME linked into it, which might use GPL code like QEMU (like my Stern Spike emulation).

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).
While it remains ethically problematic anyway, it would be good to have at least a good legal clarity.
And I feel this can be achieved by avoiding the GPL for this project, or moving it to the LGPL (although this might defeat the purpose of the GPL).

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.

[freezy]

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.

1. Firstly and most importantly, we need a license that is compatible with what VPE is linking to. Currently, that means Unity. In the future, it might be PinMAME, the stuff you're working on, and future stuff we don't know yet.
2. Secondly, we want to have some rules for people using VPE in other projects.

Our options are:

• Keep the GPL - According to you (contradictorily to UnityStation), the GPL as-is (i.e. without exceptions) conflicts with Unity. This seems pretty clear though.
• Keep the GPL but add an exception for Unity - This would resolve the point above, but would be hard to maintain as the project grows, because a) we might need to add additional exceptions, and b) not all contributors might be reachable to agree upon them. Additionally, we wouldn't be able to pull in vanilla GPL dependencies.
• Switch to LGPL - This would also resolve the Unity issue, but we would allow non-GPL (or even closed source) projects to use (unmodified) VPE.
• Switch to a permissive license - This would even allow for non-GPL or closed source projects to use modified VPE without publishing their changes.

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 stern-pba-emu, which is GPL3. Am I getting this right?

[PrivatePuffin]

I don't think they do? Where is this?

From Unity i'm sure I have it, in writing.
From Steam I need to check what exactly I have and don't have. I don't know how much Unitystation is integrated into steam and really can't say if there are any legal issues currently with the steam implementation though.

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
Please be aware: Unitystation uses (A)GPLv3, v3 has some very important changes in regards to packaging software with incompatbile software in regards to v2 (which this project seems to use)...

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 :

• Keep the GPL - No, Unitystation does not use GPLv2, but uses (a)gplv3, which is a different licence.
• Keep the GPL but add an exception for Unity - I would advice having a CLA instead, much simpler.
• Switch to LGPL - LGPL is an option, but I don't think thats what you want.
• Switch to a permissive license - This would even allow for non-GPL or closed source projects to use modified VPE without publishing their changes.

I wouldn't suggest any of those options.
My suggestion:

• At least move to GPLv3 - (why the heck do you use GPLv2 for something that isn't forced to be v2 (aka non-kernel stuff)?
• Consider adding a CLA - if you want to add GPL exceptions

@JayFoxRox

Every discussion about Unity and GPL that I find strongly implies that it's not a good fit.

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 also seems to refer people to their FAQ which says that such combinations are not acceptable.

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:

1. One thing I learned from Unitystation: If you use GPL, no mater how solid your legal advice, there will always be random people on the internet complaining things are incompatible. It's your job as maintainer to respond politely and close the issue. Because you can't keep responding to the same arguments over-and-over.
2. Don't use GPLv2 with Unity if you can help it, I am pretty confident about GPLv3+Unity being sue-proof. I am not as certain about GPLv2+Unity being sue proof.

[freezy]

Makes sense. I'll talk to all the contributors in order to reach a conclusion. Thanks for your help @Ornias1993!

[jsm174]

Hello. I am fine with changing the license to GPLv3.

[Roland09]

Hello. I am fine with changing the license to GPLv3.

[Vroonsh]

I agree to change the license to gplv3 👍