Enforce Free Software Licenses

Discussion in 'Bukkit Discussion' started by metalhedd, Jun 12, 2013.


Should all non-free licensing options be removed from the plugin page?

  1. Yes, it's a legal requirement of the Bukkit licence!

    14 vote(s)
  2. No, I don't believe in legally binding contracts

    26 vote(s)
Thread Status:
Not open for further replies.
  1. Offline


    One thing is that Bukkit uses GPL, another thing is Notch stating about the idea of releasing the code of Minecraft and draconic nature of the GPL, another thing is what people think about building on open-source code or knowledge.

    I am not sure what license is valid for modding Minecraft itself. Could be that CraftBukkit is illegal with the GPL on top of the decompiled Minecraft jar?
  2. Offline


    A developer who doesn't respect the terms of the upstream developers doesn't deserve to have their own terms respected. By releasing non-free plugins that's what they're doing.

    Which is exactly why the level of fearmongering in this thread is ridiculous. There wouldn't be a sudden outbreak of people cloning plugins just because of the GPL, bukkitdev already has rules about that.

    There wouldn't be a sudden drop in the quality of plugins on this site, and there wouldn't be a mass exodus of good plugins (most of them are already open source). What we would see is more plugins getting maintained after the original authors quit working on them, because the source is readily available.

    We should also see increased quality in any plugins that DO relicense, because they'll get more developers able to look at the code and spot bugs and submit improvements.

    The approval process would be improved by eliminating the need for staff to look at obfuscated/uncommented source code, and the rare time an error does slip by the staff, it's much more likely to be caught by a dilligent user right away.

    Sounds great doesn't it? It's gotta be too good to be true!! What would we lose? lets take a look shall we? Without specifically centering out any developers, I'm going to choose 5 random All Rights Reserved plugins, and assume that all 5 of them are so adamant that their code should be protected from theives, that they would immediately remove it from bukkitdev if such a policy were enforced... here's what we'd lose:

    http://dev.bukkit.org/bukkit-mods/jgcommands/ - Fun and useful server commands for your everyday server administrator!
    This adds about 10 commands that can be found in essentials and every other similar plugin. basic stuff like '/ignite', '/extinguish' you can get these commands in a hundred other plugins or write them youself in a half-day.

    http://dev.bukkit.org/bukkit-mods/coponduty/ - type a command to get some overpowered armor and a knockback stick, type another command to take it away.

    http://dev.bukkit.org/bukkit-mods/enchantmentapi/- This one actually looks interesting, and it's made to be extended by developers adding their own enchantments. Awesome concept, but without knowing exactly how it accomplishes what it does, I wouldn't dream of installing it. IMHO this is doomed to fail until it relicenses, as is the case with any "API". no self respecting developer will hook into code he can't view/modify the source for.

    http://dev.bukkit.org/bukkit-mods/chunkkeeper/ - This lets you define certain chunks in your world that won't get unloaded. I know how this one works, and its nothing more than a simple 'event.setCancelled(true)' on the chunk unload event, along with some basic boilerplate to save/load a list of chunks to the config file.

    http://dev.bukkit.org/bukkit-mods/anti1k/ - This plugin stops players from using a weapon that has level 1000 enchantments. (I actually decompiled this one just for kicks, what it actually does is cancel any damage done by a weapon with a fire aspect level higher than 11. it doesn't stop any other weapon with any other enchantment at all.. )

  3. Offline


    The problem is that the GPL license does not necessarily extend out to plugins, especially those that are dynamically linked, just because the people who like GPL want it that way doesn't mean it is.

    This has been an issue for quite some time and without the courts making a solid decision one way or the other, we don't actually know the legal standing to it. So this leaves us to interpretation of the the law that has no legal backing.

    IMO: I don't think that plugins (particularly dynamic link ones) should be forced to accept the GPL of the parent program (or API) that uses them. That is TOO restrictive and forces developers to choose that license. Furthermore, the code adds nothing to the base of the API (or server) so it isn't really a change to that code and should not require the same license.

    Now, as for the legal shaky ground, Bukkit (the API) should be ok in a legal stance as that is separate from CraftBukkit (the server) which CANNOT be GPL's. However, because of this, unless the server is rewritten from scratch (or using GPL compatible code) there should not be a server implementation of the API (as they cannot distribute it because the server part of it cannot be GPL)
    Jozeth likes this.
  4. Offline


    it's not "people who like the GPL" who want it to be that way, its the people who wrote it, and included in the description of the license. People who choose to license things under the GPL do so with full knowledge that it contains this clause, and (presumably) because they share the philosophical belief that this clause is the "right" way to do it.

    By even bringing this up, all you indicate is that you're willing to disregard the wishes of the people who wrote the code you're using, as long as you can get away with it. this is disrespectful and rude.

    It only forces developers to choose that license if they wish to publish their code, and its a small price to pay. regardless of what YOU think, the developer who chooses the GPL obviously DOESN'T find it to be too restrictive, or they wouldn't have chosen it... the fact that they did means your opinion is irrelevant, they've offered you contract terms which you can accept, or go somewhere else. To fight their decision by even bringing mention of the law into it is just rude. have some respect for the giants whose shoulders you're standing on.
  5. Offline


    The BukkitDev staff aren't going to accept that the source code matches the jar on blind faith, and dealing with the dependencies to compile the jar anew for comparison would take longer than just decompiling.
  6. Offline


    Fair point, but it certainly won't be detrimental in any way to have the source code available during approval.
  7. Offline


    It seems like, at a bare minimum, the BukkitDev team could give open source plugins preference. For example, if there is already an All Rights Reserved plugin that does x, and then a plugin developer makes another plugin that does x but it's open source, the open source plugin is approved even though another plugin like it exists. Perhaps open source plugins would also be reviewed for approval before closed source plugins, too.
  8. Offline


    There are plenty of people out there (myself included) that have this view on GPL where it is all fine for code that has been written and extended on but not plugins that derive from an API, that is crossing the line

    Yes while they do not find it too restrictive the point of GPL was to make the code always available even if there are any changes left, plugins DO NOT change the source of Bukkit and therefor should be outside the bounds of the license restrictions that force derived code to be of that license (or one that is compatible).

    The problem with saying I took their contract is moot since no one knows if GPL applies to dynamic plugins, which is still up in the air at this point. Technically the GPL does not cover those under their license (if they do, quote it from http://www.gnu.org/licenses/gpl-3.0.html and put it in a response)

    no it is not rude, this is something that HAS not be decided on whether or not it applies and since the community (those who use GPL) are fragmented on whether or not dynamic linked code falls in this territory it is up to speculation. This isn't rude, it is necessary.

    I would also like to point at to you (as a newish member of the community) that this was discussed at length before when Bukkit was very new and it came down to they are not going to enforce it as there is no reason to except to alienate those developers that were against it at the time
    blablubbabc likes this.
  9. Offline


    Why do you insist on ignoring the INTENT of the license... there are very few software licenses that have ever been tested in court. I have published GPL software, for you to question my intent IS rude. I've made as clear as humanly possible. in a giant document of legalese, my exact intent. you ARE being rude by fighting it.
  10. Offline


    Bukkit allows you to choose your license, so that's how it is. I don't see what you're trying to get at.
    Some people work hard on their code, and some people don't want to share it, that's their choice, and their preference.
    If they don't want to share it and they abandon the project/somebody wants the source code/anything else you can think of, then tough, it wouldn't have been there in the first place if they never made it.
    Jozeth likes this.
  11. Offline


    *eats popcorn*
    *eats more popcorn*

    But in all seriousness:
    Your choices are a tad biased. There are actually some pretty awesome ARR plugins out there, such as:
  12. Offline


    You are being EQUALLY rude to the people who wish to have their own license (or ARR). The INTENT of the license is actually vague because it DOES NOT address this issue. There is this gaping hole where it does not specify what is to be done with this and because there are people who see the value in GPL but not in this case, you are being rude by trying to enforce your version of this copyright.

    Yes, I go into the legalese about it, you know why, BECAUSE THAT IS EXACTLY WHAT THE LICENSE IS! Yes you have made YOUR opinion very clear, but you are unwilling even in the slightest to discuss it and call people rude when they disagree with you.

    My belief (as if you can't tell) is that dynamic plugins do not fall under the license, it doesn't specify them, period. The only mention to dynamic plugins are ones that the software REQUIRE to run and being that the server framework (CraftBukkit) works without a single plugin is proof that Bukkit does not require it,

    Again, this has all been hashed out before, 2 some years ago when they added the GPL to their project. It caused an uproar among (at the time) the developers of some of the leading plugins. They chose to not enforce it and from what I can see they choose not to again.

    I had forgotten about the ability to choose your license when you submit your project, because of this, they are giving permission is a sense anyways about what license we can choose.
    jorisk322 and Jozeth like this.
  13. Offline


    You must have missed the point of desht 's post. If bukkit was to enforce licenses they'd be hypocrites, and at the end of the day, these licenses don't mean anything anyway.
  14. Offline


    following quote changed to not double tag somone
    I disagree, these licenses have a point. Commercial ones are their to protect the intellectual property and GPL exists to protect itself and always be made free and open.
  15. Offline


    But these aren't commercial licenses. None of us are making money by selling plugins on DBO. Also, I think desht made the point perfectly:
  16. Offline


    I was speaking more in generalities than just Bukkit where it is almost pointless (unless you are willing to spend the tim and money defending your work in court)
  17. Offline


    And I was speaking of Bukkit, so your point is not relevant to the discussion at hand.
  18. Offline


    that does seem fairly interesting, but the first comment is from a user claiming it generates massive lag and they had to disable it. either way I'll give you a point for this one, its pretty cool, but it's also about a week old. lets see how it fares.

    has 0 downloads. so you can't possibly know that it's "pretty awesome"

    Abandoned in favor of 'VineControl Lite, this project lived for less than a month

    this is awesome? ok. we'll pretend it is. the license says "All Rights Reserved" but he actually clarifies it in the description as being a non-commercial copyleft style license, would probably pass as GPL Compatible.

    This plugin had 5 releases over a 3-day span back in january. it appears to be dead now.

    Tirelessly the actual poll question only suggests that the OPTION to choose "All rights reserved" be removed, not that bukkit be required to enforce the terms of the GPL. just take away the option to blatantly disregard it.
  19. Offline


    I give up. metalhedd clearly isn't budging, so I'm just gonna back out now. But I do have one question: why should not-so-great plugins only be limited to ones with ARR licenses? Are you trying to say that if a plugin is released under GPL, it's automatically amazing? Some of your reasons for the plugins I listed not being good were a bit of a stretch as well.
  20. Offline


    AngryNerd you're right. There's not a person here that will ever convince me I'm wrong, because it comes down to a matter of philosophy and intent, neither of which can be proven. you'll be happy to know however, I have given up on the idea that this might ever come to pass, and I'm okay with that. But free software is an issue I feel VERY strongly about, so I do want to keep the discussion going if for no other reason that that new developers will stumble on it and know why ARR is a bad choice.

    As for your remark about the quality of GPL plugins, no I'm absolutely not saying that a plugin released under the GPL is automatically amazing. I'm saying that a plugin released under the GPL has a much better chance to BECOME amazing if the developer actually embraces the free software development process. it *DOES* produce better software when properly applied.

    an all rights reserved plugin gets no extra eyes looking for bugs, no contributions from downstream developers, and will eventually stagnate, that's not to say that these things won't happen to a GPL plugin, but they're much less likely if the plugin is actually GOOD.

    I'm interested to know which of my reasons you found to be a stretch. I actually conceded on one of them.

    I think a more interesting exercise would be to find 5 old projects that are still up to date. in fact I challenge anyone to find even 3 All Rights Reserved plugins that come anywhere near the quality/longevity/usefulness of something like WorldEdit, or CraftBook, or Essentials.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: Jun 1, 2016
  21. Offline


    I feel it's worth mentioning that while all of my plugins are released under GPL, the only thing that's come from them being open-source was a developer adding support for cracked servers, which I specifically added a check for. I like to think that my plugins are "good", or at least complex and unique. However, neither I nor my plugins have received any benefit from licensing them under GPL.
  22. Offline


    Hey, I know how that feels too. I've only received one pull request ever, but I've contributed about a dozen to other plugins, and I know first hand that several people have referenced my code on github to figure out how I did something, and there's currently a plugin using an entire class from one of my plugins.
  23. Offline


    To my knowledge, sections of CraftBukkit use LGPL (https://github.com/Bukkit/CraftBukkit/blob/master/LGPL.txt) which allows linking with nonfree modules, such as Minecraft itself.
    However, most of the things plugins will be using are GPL, and the Bukkit API is all GPL.
    I would definitely class plugins as derivatives, since when they call any method, they are running code from CraftBukkit or Bukkit, which is GPL code and so should not be linked with nonfree modules.
    The GPL also does not allow extra restrictions to be applied, so BukkitDev's restrictions are also something that should be avoided, however they're not too harsh and have the community in mind, unlike services like Apple's app store, so I'm not going to complain.
    Perhaps I'm biased; I come from the perspective that all software should be free, but I think all plugins should always be licensed under a GPL-compatible license. I make sure mine are available under GPL or AGPL in some cases. If someone "steals" a plugin, then so be it, as long as it's users are given the same freedoms given to the developer(s) of the derivative plugin, and any improvements can come flooding back to the developer(s) of the original work.
    I will outright refuse to put a nonfree plugin on a server, and will generally only use things I've written myself (or know are a very high standard), though unfortunately many others do not care about their own freedom or that of anyone who plays on their server, so I end up having to weed out nonfree plugins (HeroChat for example is one I've had to deal with a lot)
    In fact, I think maybe someone should start writing a Minecraft-compatible client from scratch without using any of the nonfree code...
    agaricus likes this.
  24. Offline


    Lucariatias Yes it does allow linking to non-free code, except there is one problem they have modified non-free code (without consent and proper license to do so) and added it to the project, so even the LGPL is being violated here (simply because they "stole" the code)

    Again, the plugins are dynamically linked code (which is not a derivative) and is not covered by the GPL. Not every method a plugin calls is a Bukkit or Craftbukkit one, it could be another plugin, its own code, or even some outside code that they imported as a library. While the plugins depend on Bukkit, it doesn't mean they derive from Bukkit.

    Derived code would be more along the lines of taking code from Bukkit (in whole or in part) and including or modifying it to your projects needs, that would be derivative work. Simply using an API that someone exposes is not.
    afistofirony and blablubbabc like this.
  25. Offline


    Of course. Although there are some classes in Bukkit (I know ItemStack is one, there are a few others but that's the first that comes to mind)
    The GPL covers linking modules I believe as well though?
    This is stupidly overcomplicated, Minecraft should definitely be relicensed under a free software license IMHO.
  26. Offline


    No one knows if the GPL actually covers dynamic (or static) linked programs/plugins, its one of the holes in the license, until there is a judgement one way or the other it is in limbo.

    The GPL only explicitly covers dynamic linked modules if they are required for the software to run, because Bukkit does not need them to run (ie you can start up a server with no plugins), they are not covered under that clause

    Then there is the other fact that Bukkit is allowing us to set the license to something other than GPL which means they are not going to enforce it anyways and like I said, this was covered a few years back when Bukkit was still new and the enforcement was thrown out since there were a handful of known devs that didn't like it
    blablubbabc likes this.
  27. Offline


    Well, I think plugin author's should always make sure that their code is open source and for their own safety they should use a GPL license.

    After reading through the pages I agree that there should be no plugin available on bukkit that is not open source. I do not mean the license at all just the code. Github is free to use and really easy to use now as there are many tools available to help out any lost soul.

    In my opinion making the source available to public giving everyone a chance to look at the code will improve the product itself as there are many skilled developers out there that may want to comment on some lines to tell you "hey, you could do that better".

    But with this "i fear that my plugin will be stolen" attitude another problem will be produced. Such ppl also hate when another plugin has the same feature as their own thus they think by hiding their source code it would reduce "similiar" plugins. But let me tell you something: Thats a lie.

    If someone wants to make a plugin they probably want to make it for their own first and see if it could be of any use to others.

    If it works out they will continue to work on it. Also it does not matter to many "consumers" "how efficient the code is coded". As far as i recall features are the most intresting thing here ... if "code" really would matter many plugins wouldn't be used and from my perspective in terms of a "simple plugin" it really doesn't matter if its highly efficient its the purpose -> Someone wanted to code a plugin.

    If the plugin grows, his skills will probably grow too and he will notice "uuuhh, i really did that?" Thus he will improve the code later. Not just his skills improved but also because it is needed. If you ever coded a big plugin that can interact with many things you will have to think about efficiency sooner or later... But for small plugins .. just released ... give it time!

    Back to "always open source your code":
    If you have an idea you probably will checkout existing plugins with a similiar feature. By looking at others code some may be able to improve their skills just by checking out your sourcecode. If i could help someone just because they checked out some lines of code well I would be happy!

    Also they may come up with a better solution and you could learn from them. This is called evolution of code and by hiding the code to others evolution is slowed dramatically (or completely prevented). And thats a bad thing? Yes! (Place your own analogy here. Human evolution, talk instead of smashing others ... etc). Evolution will not stop you might fall behind ...

    Last but not least it could help you finding coding buddies. Some may be really interested to help you out and they may be skillfull enough to provide that help ... So by using github for example they could use the comment function and tell you "thats bad, could be done this way because ... improve performance ... etc"

    I really would not think only one way "someone may copy the whole plugin and change the name" This will happen and bukkit staff will prevent that from happening.

    Either way your plugin might just be redone from scratch if he cant just use your code ... takes longer but checkout other plugins there are tons of plugins that do kinda the same but with a different name. E.g. Authentication plugins ... almost any plugin has the /login command ..

    Should we all hate each other that someone uses the same command heck even use almost the same name as someone else?

    Is it really a name that makes your plugin good or is it the idea behind it? He might be inspired by some features you coded but your ideas can't be stolen cause you most likely have a complete different goal.

    Keep your target in your head and don't let others distract you from that.
  28. Offline


    This is not about the advantages and disadvantages of providing source code. This is about whether or not to let the plugin authors the freedom to decide this by themselves.
  29. Offline


    and by doing so, take away all freedoms granted to all users of said plugin by the GPL on Bukkit.
  30. Offline


    Except that Bukkit has formally stated that they are not going to force the devs to use GPL, so going to your point, the intent is not to GPL the plugins :)

    You seem to be one of GPL ****'* that can't seem to see it any other way than if GPL is attached to it everything has to have GPL, which by the license, is not the case for dynamic linked libraries (unless they are necessary for the program to run, plugins are not required by the server, therefor do not fall under this category)
Thread Status:
Not open for further replies.

Share This Page