Stepping up to save Bukkit

Discussion in 'Bukkit Discussion' started by gkid117, Sep 6, 2014.

Thread Status:
Not open for further replies.
  1. Offline


    I spent quite some time exploring sources, exploring licensing situations and stuff this morning.

    Nothing about craftbukkit will have to change. Craftbukkit is already lgpl and it its own right perfectly okay.

    Its bukkit that causes the problem(The api bukkit). That is GPL licensed. and lgpl is incompatible with GPL. In order to use bukkit as it is craftbukkit would have to be GPL too, but that isnt possible because of the propietary minecraft code.

    So in order to make craftbukkit work again we need an LGPLv3 bukkit implementation.

    This is what I am working on right now. I am at the moment making blank files for all the hooks and things craftbukkit will need that can be filled with LGPLv3 original code. This means nothing can be copied from the original bukkit api code. All has to be redone manually(and maybe even better. I already discovered two types in classnames, but those will have to stay for compatiblity, god knows who writes armour as armor...)
    Only the function hooks and public variable names can have the same names, but the rest will have to be redone from scratch.
    A lot of work, but doable within reasonable time.
    I think I will have the blank files in the Git in about 2-3 hours.

    The git is at

    Updates / guidelines will be posted on

    cheesy update /status messages:
  2. Offline


    Gamecube762 With the people who are making Sponge, it will turn out great.
  3. Offline


    Looking at it, if its lgpl the copyright issue wont be of significance really. the only thing the owners could enforce is that the code is lgplv3 or gpl3. I will remove it as a requirement.
  4. Offline


    Look everyone.. If mojang does not want bukkit to be apart of the community there is nothing we can do about it. Now i have not had the time to read through everyones good bye and nor do i know why all the devs are quiting if someone would like to fill me in on that i would appreciate it. But bukkit its not only for minecraft.. Its for growing a better community making friends and making the world just a little bit smaller by meeting developers and forum users across the state or even across the world bukkit is what truly brings the minecraft community together.. Now i will be active on this thread and if anyone working on sponge or whatever needs my help ill be happy to just om me :) Anyways guys i got a short class to get to so ill be back in about 3 hours! #SaveBukkit
  5. Offline


    I could use your help cnniillaa any hands that help are for the better.

    The only thing we need to do is make a bukkit API that is lgpl compliant. for that I started this repo

    Keep in mind it needs to be original code! You can look at the bukkit api at for what the public accessors need to be, they need to stay the same for compatibility reasons. Anything that is private, feel free to give your own flair.

    When this is done, craftbukkit, spigot and cauldron can use this lgplv3 api and be public again without worries.
  6. Offline


    Ok i will pm you about any questions i have
  7. Offline


    Or use the subreddit. I get alerts faster that way. /r/wolf_in_a_bukkit
  8. Offline


    As far as i understood all that loads of news, posts and stuff, if the dev teeam rewrites Wolverness's code, with no DMCA violation, the bukkit will be alive back?
    Anyways, if you dev guys who are still on the board, put up the repo, i can write documentation and other stuff.
  9. Offline


    Actually to make craftbukkit operational we need an lgpl bukkit. Im already 8 files in, but got 640 more to go. By the time im done im afraid people will have forgotten about craftbukkit.

    You can look at my repo at wolf in a bukkit
  10. Offline


    For me sponge is fail.
    It has totaly new Forge - based plugin system.
    It just can't be convinent for coders.
  11. Offline


    Well i could use all the help I can get. It gets a bit demotivating to hack at it alone and having people throw in your face its dead buddy, leave it
  12. Offline


    I've been playing MC for a while, but more on a private LAN server; I've used CB for it before. I have been lurking, and contemplating recent events, and have some questions and possible suggestions.
    TL;DR: Implied GPL exception from day zero; CB mistakenly integrated into vanilla MC server; change design to use vanilla MC server jar as a library; fork new project based upon then-compliant code
    Warning: Serious wall-o-text.

    Caveat: IANAL;
    #include <std_disclaimers.h>
    I'll start by admitting that I'm not HUGELY familiar with CB's internals, and I'd appreciate it if you would please correct me wherever my understanding is incorrect.
    Didn't the CB project start by the Bukkit/CB team taking a copy of the pre-existing vanilla MC server and merging Bukkit into it, with the underlying goal of retaining complete compatibility with the standard Mojang MC client software while adding additional capabilities that the vanilla MC server didn't have?
    Isn't the build process still based on taking the (proprietary) vanilla MC server and then decompiling it, generating mappings from the obfuscated identifiers used in vanilla MC server to usable "friendly" identifiers, using those mappings to directly patch the decompiled vanilla MC server source, and then to use that decompiled and patched source as a major component of CB?
    This would seem to be a violation of Mojang's license and/or copyrights, but it also appears that Mojang has given tacit approval of this.

    Since the GPL does allow proprietary code to be used as a major component of a GPL project, so long as it is a library, and an exemption is given, would the use of vanilla MC server as a major component of CB have created an implicit GPL exemption, even though the project had a minor mistake in its architecture created by tightly integrating vanilla MC server instead of referring to vanilla MC server as a library, especially given that the issue of license compatibility was raised at least as far back as July 2012, yet the developers continued to contribute to the project as if there were no licensing issues?
    If that is true, then could the architectural mistake caused by tightly integrating CB into vanilla MC server possibly be resolved by reversing the mapping generation so that friendly identifiers were mapped to obfuscated identifiers and then taking one of the two steps that follow? (This might also resolve the Mojang license issue, since there may be precedent for reverse engineering for compatibility and enhancement)
    After generating the reversed mappings could the CB source then be patched to directly refer to the obfuscated identifiers instead of patching the decompiled vanilla MC server code to allow it to be bound into CB? This would have the disadvantage of adding difficult to read intermediate source code to the CB project, but it may shorten the build process, as there is no longer any need to recompile Mojang's source, assuming that patching the CB sources to refer to the obfuscated identifiers used in the vanilla MC server.
    Another possible use of the reversed mappings might be generating shims to allow use of friendly identifiers to continue in the CB source while translating the friendly identifiers into the obfuscated identifiers found in the vanilla MC server.
    Either of these should allow CB to work without tightly integrating it into the vanilla MC server. Instead, CB would treat the vanilla MC server jar as a library. Given the implied GPL exemption, this would cure the only remaining GPL violation, triggering an automatic (provisional) reinstatement of GPL rights.
    The GPL doesn't say anything about revoking an exemption, only about termination due to non-compliance, and a developer participating in the distribution of version that has been document as being non-compliant could be a fair indication that the developer intends the version to be exempt from whatever provisions it does not comply with. It should therefore be safe to take any version that the developer hadn't added additional code to and patch it to use the vanilla MC server jar as a library. I'd expect that taking an existing project, adding some code to it, and forking it under a different license would require the approval of ALL developers who contributed code to the project under the GPL. This could become very complicated if the permission had to be obtained from someone's estate!
    A compliant version that correctly uses the vanilla MC server jar as a library could then be legitimately distributed, and even used as the basis for a fork/new project (CB-ng or Spigot-ng anyone?). Since the project would correctly refer to the vanilla MC server jar as a library, the (implied) exemption to the GPL is considered part of the project's license, and the only thing that a developer can forbid is the right to distribute their future additions; they can't retroactively revoke licenses already granted or the rights granted by them. The GPL explicitly prohibits revocation of downstream licensees' rights under the GPL, so long as they are compliant.
    With respect to the DMCA notices, would it be reasonable to consider that the combination of the documented knowledge of the historic non-compliance and the lack of action for two years might fall under estoppel by acquiescence and/or laches, or that the continued contribution of code to the project after the documentation of the license compatibility issue might raise questions about bad faith and unclean hands? Would copyright misuse also apply?
    Lastly, Mojang's claims to own the Bukkit project probably have no bearing on the whole situation, as Mojang has apparently treated Bukkit as a separate entity so well that the entire community was unaware that Mojang owned the project. Bukkit appears to have been granted true independence until someone else attempted to drop the project.
    In any case, there is nothing in the GPL that prevents one entity from picking up a project abandoned by another entity, so long as the provisions of the GPL, including any exceptions, are adhered to.
  13. Offline


    Ok. You got it almost right jreames3. No worries, took me some studying too.

    The thing is there are two components at play here

    Bukkit api which is gplv3
    Craftbukkit which is lgplv3

    Gplv3 does NOT allow to be linked against or used by proprietary software UNLESS its a system library.

    Any software that wants to use a GPL library(which bukkit api is) has to become gplv3 too to be compliant.

    Because craftbukkit is lgplv3 it cannot use the bukkit api without becoming gplv3. However it cannot do this because it is tightly integrated with proprietary software and that software will not become gplv3 because then mojang would lose all control.

    The fact that this continued to be done is because it was ignored. Until wesley decided to do the ultimate grief.

    Why is the bukkit api gplv3 you ask?
    Imho because thats the default option at github. Need i say more?

    Craftbukkit isnt in violation if it wouldnt use the bukkit api. But without the bukkit api it wouldnt work.

    That is why i'm fighting the lonely fight to make a new bukkit api called wolf in a bukkit. This is be an lgplv3 that has the same hooks as the bukkit api,(public method names, public variables) but the rest of the code is original. When programming restrictions force me to use similar looking code(such as interfaces) i have no choice but thats defendable and cases have been tried over this. You cannot copyright/patent default programming behaviour. Plus I dont think people from the bukkit api dev team will hunt me down. At least I hope not.

    Unfortunately I cannot use bukkit code in the project since that would force my project to become gplv3. UNLESS the copyright holders of code in the bukkit api would add it to the wolf in a bukkit project.

    I study its function and device another route to achieve the same result. Which is a pain because it forces me sometimes to use inelegant solutions.

    I would love to have more devs helping me, but i'll keep plodding along slowly
  14. Offline


    What is going to happen is once the Bukkit project has gone down, no server will be available to run...and there will be half the amount of players actually using Minecraft servers...because there will be so few that are able to keep running and have the funding to be able to keep updating it. Mojang will hopefully realise the Bukkit is one of the greatest parts / additions to Minecraft and without it, not as many people will be using and playing Minecraft.
  15. Offline


    MrEditor97 I guess thats why I keep on eith the project despite people calling me a fool.

    The problem is, mojang cannot declare the bukkit api lgplv3 WITHOUT all the people who worked on it agreeing. The copyright holders have to agree to release their code under lgplv3.
  16. Offline


    I get that CB must be GPL3; no argument there. A plain reading of the licenses shows that, as does a look at the GPL3 FAQ.

    I know that MC server has an incompatible license.

    If the tight binding could be broken, and CB looked for the MC server jar in its classpath, then CB would be using the MC server as a library.

    The first release of CB had to include the existing MC server code. Because of that, CB is integrated into MC, and not the other way around.

    Googling gives mentions of the license compatibility issues that go way back, to at least July 2012.

    Because the developers based CB on MC server, because they continued to contribute code for at least two years after the topic of license incompatibility was raised, and because they continued to distribute it under GPL3, the intention that CB must be GPL3 compliant is obvious.

    The only way for the license the developers chose to use to be valid, and in choosing to use it, they indicated their intent was that it should be valid, is if there is an exception to the GPL3 for the MC server code. This exception is implicit in those choices.

    The developers did make ONE mistake; that was when they chose to integrate CB into the existing MC code (not the other way around).

    This certainly makes CB code more readable, and I get that.

    What I am suggesting is that instead of remapping the MC server code, that instead those mappings can be reversed and applied to the CB code as an intermediate build step. The resulting code would then treat the unmodified Mc server jar as a library, which would correct that single mistake.

    That action, when combined with the exception that was implicitly granted, makes CB fully GPL3 compliant.

    Under the GPL3, a developer can't take away code they have already contributed; they can ONLY change the license on new code they might add.

    Retroactively forbidding distribution is effectively a license change. This isn't permitted under the GPL3. About the only thing that can be done is to change the license on new code. That can only be done by unanimous agreement of all developers.

    The DMCA takedown is bogus, plain and simple

  17. Offline


    I get what you are looking for, but also for the exception all bukkit api devs would have to be onboard. An implied consent does not make legal and will not hold up.

    If getting all devs on board is going to happen just change the license to lgplv3 instead of adding minecraft as exception and loading it as a library.

    But I don't think that will happen because of the way people left. They like it broken and give a big f** u to the community.

    The dcma is bogus but it is effective since everyone is scared silly and no-one is taking it to court.

    Crafbukkit is in violation of GPL yes. But not in violation of copyright. Everyone seems to miss this.. But as long as nobody issues a counternotice and goes to court wesley wins.

    Thats why im taking the long way around making a new api that is bukkit compliant and is lgplv3
  18. Thank you, Tschallacka. I know it sounds cheesy, but you are our only hope. I can't code myself, but I truly hope you'll succeed. Just remember, haters gonna hate, nobody will remember your name, but what you're doing is amazing!
  19. Offline


    Since CB is under GPL3 (inherited from Bukkit), it can only be distributed according to GPL3. Since it has many authors, ALL of them have to agree to distribute it otherwise.

    If the project is, as you say, not intended to be compliant with GPL3, then every time any of the developers checked out/pulled code/cloned/mirrored/updated their local copy of the repository, they were violating the copyright of ALL of the other developers.

    Remember, in the absence of a license, copying is forbidden. The GPL is the only thing that allows legal copying of CB. If the project was not compliant with GPL3, then the developers were actively violating each other's copyrights. They were engaging in piracy of the work of all of the other developers.

    So, the only reasonable interpretation is that the developers intended to legally copy each other's code.

    This means that the intent was that the project, as it existed, was GPL3 compliant. The GPL does permit exceptions, however it is ambiguous as to whether there is an exception. To resolve that, the actions of the developers can be examined to determine whether or not there is an exception.

    Despite the fact that there is no explicit exception, the actions of all of the developers show that there must be an implicit exception, otherwise they were all in violation of GPL3, and therefore had no legal rights to copy CB.

    Therefore the only way the GPL can be valid, and the only way that the developers could copy anything, is if there was an implicit exemption. This exemption would become part of the license. It's the only way that the development process could have occurred. The collective actions of the developers demonstrate this unambiguously.

    That exemption, being a part of the license for the project, would be extended to everyone.

    Admittedly they made a mistake w/r/t including MC server instead of using it as a library.

    That can be fixed by any of the developers who care to. Given the exemption, this would resolve compliance issues and grant at least a provisional license to resume distribution.

    At that point, anyone can obtain a copy of the compliant version and start a fork from it. The exemption, as part of the license, would persist, unless all of the developers agree to revoke the exemption going forward. (They can't revoke it going backward)

    Remember, with CB, it's a collective work. It's a different situation than it would be if CB was the work of a single developer.

    BTW this could get gnarly in a long term project where one or more of the developers has died; the permission would have to be obtained from the person's estate or whatever entity got "everything else" unless their will explicitly assigned their intellectual property rights to another entity.

    Again IANAL, but the above is the only legal way the developers could have worked on the project.

    In the alternative, asserting that the license was not valid means the developers were illegally copying the intellectual property of each other and modifying it. Since they continued to copy and contribute under to CB, I believe that unclean hands applies.

    This means that any attempt by any of the developers to prevent distribution would be in bad faith, and could lead into copyright misuse. One remedy for copyright misuse can be a determination that the person making the assertion could be prevented from enforcing their copyright.

    Additionally, the delay in enforcement of the copyrights could leave the door open for laches and estoppel by acquiescence.

    Again IANAL (but I was a regular reader of Groklaw since it's early days... May it rest in peace, or better yet, may it find a glorious resurrection on some better day!)

  20. Offline


    My java skills is moderate, and truth by told i'm doing 16 hours of school to graduate and working 22 hours on top of that, however if I can assist in anyway shoot me a message. I've been a member of Bukkit for a few years now and I would hate to see all of this lost. Bukkit is what made me fall in love with coding.
  21. Offline


    jreames3 yes and no.

    Craftbukkit only be distributed under gpl3 yes.
    But bukkit api being gpl3 does not automagically upgrafe craftbukkit upon distribution.
    This is impossible because of the lack of consent of craftbukkit developpers.
    Summarisation violation of GPL != automagical upgrade

    Its a violation situation. Not an upgrade.

    Yes its true everyone willfully ignored it though and worked with it despite the incompatible licenses.
    But, since the bukkit dev team took a hike, a lot of bukkit devs quit nobody will take up the situation to court. Even spigot isnt going to contest it :( whilst it is a pretty easy defendable subject but when you go to court you put everything into a judges decision.
    So whilst speculating over what is right and how it should be done if great passtime in the practical world it serves no use since no-one is going to pursue the matter.

    That is why it can be simply resolved by making a new api under lgplv3

    It is really that simple.

    MikeGold thank you :) i'm not doing it to be remembered but to resolve a fucked situation because of the way it happened.

    Open source should not be treated this way and discarded so flippantly. And since its only a few files that cause the violation situation its a relatively short term effort.

    paully104 any help is greatly appriciated! I could use some
    No great skills needed since its mostly simple code like interfaces and events
  22. Offline


    If I was part of the project, I would definitely be standing by it.
  23. Offline


    MrEditor97 feel free to join ;-) could use the help
  24. Offline


    I'm here and ready, if someone would like to ask...
  25. Offline


  26. Offline


    Im on board all the way
  27. Offline


    I hope most of the community is...
  28. Offline


    This gets me excited!
    I and many others are used to bukkit and how it works. So any Mod that allows us to keep our Myspace until a FB comes along for Minecraft would be amazing! (<-- Its a Joke) Also I wanted to learn Java through MC but this little stunt almost makes me not want to get into coding. Seams there are some A$$holes out there for sure. Cant let that stop me but this MC community has made players on my server go to school. Its fucking nuts the shit this game produces. Kids wanting to learn in school? What the hell happend to the world.... Oh yah Minecraft! Thanks for this post and I will support with small funding if needed. Like I said I wanted to learn to code but I cant even get a .Jar atm.

    Keep It Up!
  29. Offline


    How do you plan on making your api binary compatible with bukkit plugins? also, pretty sure this: is sufficient proof that whatever you do isn't a cleanroom project...... as you literally had a copy of bukkit in your repo.
    bluej100 likes this.
  30. Offline


    I know I had. I started the project over 3 times over as i learned more.

    Currently I have the project fully stripped of bukkit, a different license and clean files.

    In the is detailed how to do the clean room. We document everything where we based code off from. To leave a paper trail thatwhere the idea for code came from and how we deduced its function.

    I also sent out an email to mojang asking if we could use grumms and dinnerbones code under x11 license which helps a great deal with classnames and the like.
    MrEditor97 and vokisa like this.
Thread Status:
Not open for further replies.

Share This Page