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


    no need for name calling sir, you seem equally adamant about your position on dynamic linked libraries and the GPL, but you've yet to back it up with the relevant text from the license which indicates it. I've been searching for a while now and I can't find any reference in the GPL v2 or v3 that makes any such claims about dynamically linked libraries. the closest thing to an official word on the subject is in gnu's faq which says the exact opposite.

    Yes it is a grey area. you are absolutely no more correct than anyone else until you cite the exact text from the GPL which agrees with the point you've been claiming.
  2. Offline


    The only line that mentions anything dynamically linked states that it has to be a required part of the program (or software)

    The work would be bukkit btw (as it has the License)
  3. Offline


    mindless728 The section you pulled that from is defining what constitutes the "corresponding source" for a piece of software. it only states that bukkit needs to release the source code for any libraries that they require. obviously plugins are not considered part of the source code of bukkit, and thus aren't required to be distributed by bukkit, but this has absolutely no bearing on what constitutes a derivative work of bukkit. you literally took a tiny part of one section out of context, and it doesn't say what you're implying it does.

    If you consider the relationship between a plugin and bukkit such that bukkit provides a library of functions for the plugin to use (and the plugin depends on bukkit) which I think is a very reasonable definition, then this link (which outlines the differences between the LGPL and the GPL for use in libraries) makes it very clear that the non-free software is NOT permitted to make use of the GPL library.
  4. Offline


    My plugins were all released with the All Rights Reserved licence for the simple reason that the licence choice was too overwhelming.

    My first plugin was the first time I had ever touched Java, and I had no experience with Github or source control back then. I would guess that this holds true for a lot of the authors here.

    Since then I have created public repositories for all of them, and am slowly changing the licence over to a different one. The choice is still far too complicated though and I don't have the energy to study the differences between all the available licences.

    In view of this, possibly a better solution is to either have a GPL licence selected by default when creating a new project, or to replace the box with a series of checkboxes - I allow others to view my code, etc.
    jorisk322 likes this.
  5. Offline


    I have seen first-hand how plugins are ripped off and distributed under a new name, also outside dev.bukkit. But guess what? Some guy clones a GPL-compatible plugin and makes it 'all rights reserved'. In a sense, by not enforcing people to show the source code, you allow people to easily clone plugins. Showing source code proves credibility.

    Want a famous example? How the author of PerformanceTweaks published the source code, but PTweaks (which continued with the same code) is 'all rights reserved'. I guess most people remember the drama a long time ago. Another example is plugins claiming features exist that do not really exist. "This plugin will protect against hackers/cheaters/etc.", when in fact all it does is check for player movement > 2 blocks. Source code is needed to verify the claims an author has. This is why I publish the source code for ALL my plugins.

    As mentioned already, making your plugin 'all rights reserved' does not protect it from being stolen. You can easily decompile it and publish it under a different name. In fact, GPL (which enforces source for ALL derivative works, and thus all plugins) makes this impossible: people see the source and instantly know you stole it. In fact, it could even show up when doing some Google searches. In addition, requiring source code to be added will reduce the amount of malicious uploads...because why bother with it when you have to write legitimate alternative source as well?

    If you want to protect your plugin, do so at the root! Be on the lookout for thieves and report them to devbukkit staff.
    You can NOT stop people from physically cloning your plugin if they really want to. The jar files contain the physical plugin bytecode and it can easily be used to recompile.

    Fearing licensed GPL derivative forks? Well, your credits are still on there, if not, then the license is violating. If you fear a fork being used more than your own plugin, then it's time to write better plugins so the fork is not needed.
  6. Offline


    Oh wow, someone get's it!
  7. Offline


    I guess the first argument does say it all. Second argument "lookout for thieves" is also valid. I do that quite often and checkout alternative plugins and monitor them.

    Third) Competition is nice to have but if it is a blatant copy or they add features you wanted to implemented long time ago thats something I would think about and take action if needed.

    But yes, thinking about his own strategy first instead of going on a rampage is always a good choice.
  8. Offline


    Correct about the competition thing, but you can always discuss with the author to allow an upstream merge of the fork, and adding him as contributor. Usually it's better if people ask you to implement (or accept a pull request) prior to forking it, though, it's more polite.
  9. Offline


    bergerkiller well, sometimes that works but when they already started an uploaded a project to DBO they most likely want to continue it their way. Thus dont want to work together :D

    Also many of them build their own project because one or two things they wanted in and where denied by the author. Name it differently and think thats it ^.^

    I find it kinda hard to get that under control as you get that information most likely when its already done. And at that stage (released a plugin) its senseless to argue with them, sadly.
  10. Offline


    Well, if the changes he proposed are taken with gratitude by server admins, and his fork ends up more popular, then it was your mistake of not wanting to implement said features. Of course, you have a vision for the plugin, and if people fork it to change that vision and it ends up good, it was you to blame. If you vision was correct, then the forked plugin should end up less popular or 'a mess of features'. You are in no way responsible for the actions performed by others.

    And you can always decide to implement said features yourself if they appeared to be demanded a lot.
  11. Offline


    pTweaks is at least 50% new code. The plugin was always meant to be a continuation though, that's pretty obvious by the name. I have no issues with anyone looking at the source. I didn't think twice about the License. I have never complained about someone looking at it either.

    I understand what you are saying though. However you believe because half (if that) of the plugin is from an open source that the entire thing should be? I don't agree with you. However if Bukkit removed the license thing from their website i wouldn't be bothered by it.

  12. Offline


    I am aware that you made significant changes over time, but I was also aware that at the time of the conflict you used 'all rights reserved' to hide the actual source code of the plugin. Let's say that it did not paint you as someone doing something legitimately. I hold nothing against you at this time, since you made appropriate changes to give credit to the previous author.

    Using 'all rights reserved' enforces that a plugin author is trying to hide the source code. Be it from people stealing your plugin, be it because the author stole the source code, be it because the author knows the source code contains malicious instructions or is not doing what the description says it does.
  13. Offline


    Interesting... Does this mean that I can go on a server like minez and demand to see their code?
  14. Offline


    I wouldn't think so, as they didn't release any software linked to CraftBukkit/Bukkit.
  15. Offline


    These poll options are so biased it's hilarious. I'm all for open source, but forcing it on people like the GPL does isn't the way to go about it in my opinion, which is why I prefer GPL compatible, but non-viral licenses.
    blablubbabc and jorisk322 like this.
  16. Offline


    Hey OP, get me the source-code for Bukkit now. Drop everything you are doing, and get ALL the source code now, decompiled. Failure to do so is in violation of the GPL you agreed to in working on the code.

    I want to make my own plugin API based on your code. None of your code will be used, trust me.
  17. Offline


    I realize this thread died off a long time ago but it was recently linked from reddit, and I couldn't let this kind of ignorance pass:


    The source code for bukkit and craftbukkit has been freely available to anyone for as long as I've been working with it. You're 100% free to download, modify, copy, reuse and even redistribute any parts of it however you see fit, so long as you also license under the GPL. That's what the GPL is all about. That's why Spigot and mcpc+ exist, they're forks of CraftBukkit, based on the source code available on github.
    agaricus and Jozeth like this.
Thread Status:
Not open for further replies.

Share This Page