Ah alright thats awesome
@M4GNV5 I donât think you understand the point. What heâs trying to say is that the IMPLEMENTATION is copyrighted, not the API. Pore only uses the API, therefor no DMCA
The federal appeals court disagrees with your assessment that APIs are not copyrightable. All you need to make sure than anything distributed with classes that link against Bukkit is that it satisfies the conditions of the GPL.
Since this thread is still sort-of alive, I thought Iâd point out a post I made over on the subreddit regarding Poreâs legal status. While Iâm not 100% sure of my interpretationâs accuracy, Iâm pretty sure Pore is safe either way.
1 Like
Simply put, the problem lies and always has lain within CraftBukkit; Bukkit itself has no problems. As long as Pore is licensed properly, there should be no problem. Implementing Bukkitâs API is completely legal as long as the implementation has a valid, compatible license.
I highly doubt that it will be discontinued because of a copyright strike considering Pore doesnât use any of Bukkitâs code as far as i considered.
Iâd also think itâs safe. Not to contest the legal status of any code, but rather because Spore would only take method calls and route them to Sponge methods. It wouldnât be using anything other than method names Iâd guess. And Iâm doubtful that the method names themselves would constitute copyright infringement.
Even if it needs to virtualize a Bukkit server internally and then intercept the called methods. In that case, I still think itâd only need Bukkitâs API (just the shell with method names that forward to Sponge methods somehow), but none of the code that processed the methods.
Before you read this, I am not attempting to scaremonger, I would like to see this succeed - but I donât think Pore is currently in compliance with the GPL of Bukkit and is vulnerable to a takedown request.
TL;DR: You canât relicense the Bukkit portions of the code under the MIT as it seems you have tried to do in Pore. They are compatible, not interchangeable. Either go full GPL v3, or add that the org.bukkit classes are GPL v3 in the license. Any original code that doesnât touch the org.bukkit classes can most likely remain MIT - because itâs compatible with the GPL.
Iâm not a lawyer, but Iâm pretty sure licensing your whole repo under the MIT whilst including the Bukkit code in your repo actually breaks the GPL of Bukkit.
I know that you say the MIT licence is compatible with the GPL, thatâs true - but the whole combined work must then be licensed under the GPL. The MIT licence is compatible because it doesnât have any restrictions that the GPL doesnât, and it allows sub-licensing, which the GPL doesnât. That last point is important - technically, you are breaking Bukkitâs GPL licence by including the GPLâd code in a repository that is solely labelled âMITâ - you are attempting to relicense the Bukkit code, something that the GPL does not allow. Based on what youâve done, you are saying someone could take Pore and make a closed source version because itâs MIT - but you actually donât have the right to say that the Bukkit code can be used in a closed source situation, because the GPL doesnât give you the right to decide this.
This is why youâve broken Bukkitâs license on this - and I believe you are entirely vulnerable to a takedown request as it stands.
You could mark Pore as MIT except for classes in the âorg.bukkitâ package, explaining that they are GPL v3. That way, people could take the original parts of Pore and reuse it under the MIT (the Pore framework could be useful as a translator from another API), but if they use Pore âas-isâ with any Bukkit class, then it becomes GPL. This is because the MIT licence allows you to sublicense your code - you can go from an MIT licence to the GPL licence (to a more restrictive license), but not the other way around.
I am of the opinion that, if you sort this licensing issue out, then you should be OK legally - but as I say, Iâm not a lawyer - donât take my word for it.
Sorry if this post seems very legal-like and aggresive. Itâs not meant to be - itâs important that the license is right so you donât fall foul of any issues. I hope it helps - Iâm hoping Pore can help eek out a bit more life of abandoned pluginsâŚ
Ah, I didnât think about that. Although it wouldnât directly be in use of code other than method names at best, I guess the license may be another ordeal entirely, since youâd be directly referencing the Bukkit method names, so would potentially need to at least be the same license.
Thatâs an interesting point. While I was of the impression that the GPL is implied in reusing the code, I suppose it couldnât hurt to add a disclaimer. However, keep in mind that the MIT license is GPL-compatible, and therefore derivatives of Pore could be legally licensed as such.
I feel you kind of missed my point a little here. The compatibility is one way only - you can use MIT code in a GPLâd codebase, but you canât use GPL code in an MIT codebase unless you make the MIT codebase GPL (which you correctly say you can do).
By using Bukkit code in Pore, youâve automatically made it a GPL codebase. There is nothing stopping you from saying that the code around Bukkit that youâve written is MIT, but because youâve included code that is GPL, the combination is GPL too - so effectively, Pore is under the GPL. However, you havenât said this anywhere.
Unfortunatley, you canât really say that - if you use GPLâd code, you have to include the GPL license terms with it.
Essentially, the problem comes in because youâve not stated that the Bukkit code is GPL. By not doing so, youâve stated that the whole of Pore is under the MIT license - you are violating the GPL, as you canât sublicense from GPL to MIT.
Itâs not a disclaimer you need to add - you need to change your licensing. As I said, saying code in org.bukkit is licensed under the GPL v3 and code in other packages is licensed under the MIT license should be enough.