search

Phoenix616 / IDConverter

Converts numeric item IDs to Bukkit Material names (1.13 and legacy) in files (e.g. configs)
https://www.spigotmc.org/resources/id-converter.52099/
GNU General Public License v3.0
12 stars 9 forks source link

Please licence under LGPL #1

Closed Pr0methean closed 6 years ago

Pr0methean commented 6 years ago

If this were licenced under LGPL or the Apache licence rather than GPL, we'd be able to use it in Glowstone (https://github.com/GlowstoneMC/Glowstone), which is an open-source clean-room reimplementation of a Minecraft server. Could you please consider doing so?

aikar commented 6 years ago

Or better yet, MIT :)

Phoenix616 commented 6 years ago

Not right now, no.

aramperes commented 6 years ago

@Phoenix616 While I respect your decision and your choice of license for your project, I disagree with what you linked in regards to this issue.

The argument against using LGPL is about influence by third-parties who seek to make money. This is quite irrelevant to what the Glowstone project is trying to accomplish. Influence by proprietary parties is, in evidence, an issue of its own, but is not pertinent for the sake of this case. In my opinion, re-licensing to a more permissive license, even if not LGPL, does not threaten your project.

In fact, it also states that free software developers should support one another. Using this open-source library would honestly help us a lot, as updating to 1.13 is increasingly looking like a colossal task for our project and others of the kind. It's something we've looked into for a few weeks and this looks like our best option.

The decision is yours, but I'm simply asking you to reconsider it, from a fellow open-source and free-software developer.

Phoenix616 commented 6 years ago

While I (obviously) believe in the importance of open source projects I don't see how the nature of one specific project being able to profit from it has any relevance on the licensing choice. As soon as its licensed to something else all the points stated in the linked page hold true again as any other non-open project could profit from it.

I could even make the counterargument and ask why your project is not licensed under something that allows the usage of my library and helps spread the usage of open source software seeing as the MIT license is rather lax on what it allows people to do to your code and the GPL being perfect to ensure the openness of such a software.

Also the reason why I said "Not right now" is related to another point made on that page: There are no other programs/libraries that I know of that currently do this exact thing as mine so anyone using a compatible open source license can profit from it and other (proprietary) projects will have to spend their own time implementing a solution. (Granted the time to do this is not much in comparison to a full server software but this is more about the principle behind it)

aramperes commented 6 years ago

In regards to the reason why the motives of our project is relevant; it is because you linked an article which has the explicit objective to warn developers against influence from companies.

I am not arguing on behalf of Glowstone, so I will not argue as to why it chose to use the MIT license. In my opinion, however, selecting a permissive license has the objective of taking a stance on "what is best for humanity": is closing a project to open-source objectively the best solution? Is the freedom of not being free irrelevant?

Again, I respect your decision to license this under the GPL, as well as your stance in support of FOSS. However, I would argue that a permissive license gives more freedom to everyone; permissive licenses give freedom to both developers and proprietary entities. End-users still have the freedom of choosing not to use proprietary software.

aikar commented 6 years ago

Considering that premium plugins violate the GPL already, nothing stops you from enforcing the GPL on premium plugins today as you are a contributor to Bukkit/Spigot. If your not going to enforce the GPL already, then premium plugins have no reason to care that this is licensed GPL.

It really only hurts those who do want to comply with licenses.

In defense of MIT, And I and others choose MIT because we ultimately don't care if a company uses it for profit. I don't want the nightmares of worrying about legally suing someone. I choose to release my code into the ecosystem to be used by anyone who benefits from it, paid or not.

Phoenix616 commented 6 years ago

Disclaimer: I'm not a lawyer so my understand of these licenses is solely based on what I read others stating about it (lawyers included).

Considering that premium plugins violate the GPL already, nothing stops you from enforcing the GPL on premium plugins today as you are a contributor to Bukkit/Spigot. If your not going to enforce the GPL already, then premium plugins have no reason to care that this is licensed GPL.

Just because I linked one of their pages which summarises my point of view on one issue it doesn't mean that I completely agree with some of their other pages on different issues.

Especially in regards to dynamically linking to (and not actually sharing) GPL licensed code my viewpoint is that this does not require the code doing the linking being under GPL (or a similar license). This viewpoint is shared by other copyright lawyers (see the GPL wiki page for more info) and the page that you linked itself even states that they only "believe they form a single combined program" when one links to a library.

I do not share this believe, especially not for cases where the plugin and the software running it aren't even distributed together and therefore do not "form a single combined program" ‒ you could as well run the plugin with any other server software that implements the Bukkit API (e.g. Glowstone) and because API specifications can't be licensed under anything (which the Oracle vs. Google lawsuit about the Java API has shown us (correctly imo.)) it means that just accessing the methods and classes of a GPL licensed API-implementation does not put it under the same requirements as it does not create a "derivative work" of the API code itself. (Hence it would not be required for "premium plugins" to be under the GPL)

Which brings me back to the original topic on using this library in non-GPL (but GPL compatible) licensed projects like Glowstone: The solution for a situation where you for whatever reason would want your code under a non-GPL license is to keep the code under a GPL-compatible license (like the MIT license) and distribute the fully build application (which includes the library's binaries) under the GPL. (This is even described in their FAQ) If just accessing the library doesn't require all code being licensed under the GPL this would mean that the code stays under it's own (GPL-compatible) license but that you gain the benefits of the GPL when distributing the executable. As it's already possible to re-license any GPL-compatible code under GPL this shouldn't be any issue as the possibility to obtain the differently licensed code under the original license is still available.

So no, I don't believe that licensing this library under the GPL "is closing a project to open-source" like @momothereal stated, it just ensures that it stays open and that only open source projects can benefit from it. As soon as I would put it under the LGPL anyone could take the library and distribute it as part of their proprietary program without disclosing any of their source code besides modifications to my library. My issue is not about someone making a profit of my code (which you still can even when openly sharing) this is about sustaining freedom.

And if this stance limits the freedoms of those who don't want freedom then that's alright with me. After all it's their decision not to support free software so they have to live with the consequences.

Phoenix616 commented 6 years ago

@Pr0methean, @momothereal I just noticed something interesting that I thought was worth pointing out: You already include/shade-in GPL-licensed libraries in the distributed Glowstone jar (Glowkit) which should mean that the distribution is licensed under GPL as well already? So there is literally no reason that you can't include my library in the same way without a re-licensing.