**Discontinued** Pore - A Bukkit-Sponge Bridge

Could you tell me where Bukkit (NOT CraftBukkit) uses Mojang code? Bukkit itself is valid GPL and that’s why you can still download it from the official site… :wink:

Look again at the Bukkit repo, and you’ll see that the last commit is from some time in 2013. Presumably that is the last commit before Wolvereness started contributing.

No the last commit is f210234, from August 17 of this year.

1 Like

bendude56 authored on 8 Jul 2013

However, it seems like I was wrong and those are just a bunch of commits that were recently cherry-picked on top of the repo.

The concern is the Bukkit API, not the implementation, but all the implementations break the GPL. Technically, if there was an implementation of Bukkit API without Mojang code (a.k.a. coded from scratch) it wouldn’t break the GPL as set by Wolvereness.

2 Likes

Didn’t Wolvereness create the working plugin loading system…?
If so then surely he had something to do with the creation of the Plugin class Bukkit uses meaning if somebody took advantage of the existing Plugin class then logically their work is also susceptible to the DMCA treatment?

No, because both the Bukkit API and Pore are released under free licenses. The reason for the DMCA was that GPL code was packaged with non-free code.

Ah I see.
What would the effect of using Bukkit’s code to emulate the server have though given it would require the NMS code? From what I gather the OP has a cloned Bukkit repo which immediately rings alarm bells to me.

See here: Plugins to be ported! - #186 by Inscrutable

Nothing in Pore requires NMS. Rather, it includes the (nearly) unmodified Bukkit API and then uses its own implementation to translate calls to it to something Sponge understands.

I do not believe that applies to Pore, seeing as Sponge is not loading the plugins. Therefore, Sponge and the plugin being loaded cannot be considered one program, as they never directly interface.

I’m no lawyer, but my understanding is that Bukkit itself (the API, which is all Pore needs) is in no legal trouble. You can see its github still up here. Historically, API’s couldn’t be copyrighted (though recent events make me question that statement). Regardless of the future issues, for the time being, Bukkit is still up and legal.

1 Like

Bukkit’s fine, GPL and all legal*. The problem is that pretty much any implementation of Bukkit starts getting into legally muddy waters. I’m not trying to kill Pore, I’d be delighted if it was possible and legit, but ShaRose’s opinion carries weight, IMHO. *IANAL

The issue with Craftbukkit wasn’t the fact that it implemented Bukkit. The problem arose because it was licensed under GPL but was also packaged with non-free code, which violates the license. As long as Pore only includes code under GPL-compatible licenses, it’s legally sound.

2 Likes

As long as pore only links between the Bukkit API itself and the SpongeAPI itself and contains no Mojang code or CraftBukkit code we should be fine legally. Someone just needs to start making this thing.

We’ve already made some progress over on the BitBucket repo. At this point we’re just waiting for Sponge to progress.

2 Likes

great to see someone has tackled this angle too!

Is Sponge really expected to support everything that Bukkit supports? Configuration Serialization, Permissions, World Loading/Generation, Task Scheduler, Plugin Messaging? I don’t see a bridge between the two being easy or efficient.

The bridge by no means is a 100% emulator for Bukkit, it will do the best it can to handle the Bukkit library calls and pass them to sponge but there will of course be some functions that pore will be unable to completely handle. Any plugins that use craftbukkit will also break.

That’s the goal. Pore ships with a copy of the Bukkit API, and uses its own implementation to translate calls back and forth. It’s actually a bit easier than you might think, seeing as a good number of features (e.g. plugin loading, permissions, scheduling) are actually implemented by Bukkit rather than Craftbukkit, so we won’t even need our own implementation for those systems. Currently, our approach involves implementing the most commonly used features first, then moving onto the lesser known ones. It’s better to have 90% of plugins 100% working rather than 100% of them 90% working.

1 Like

So, youre going to use the Bukkit API to run this? If so, its illegal. Because Mojang/Microsoft is now the owner of Bukkit they copyrighted the code. Just saying.

Yours sincerely,