Farm Development

Why you should NOT license your code as GPL

Zed Shaw recently wrote a clear and concise defense for why he used the GPL on Lamson. I've seen a few mentions on twitter that alarmed me because people seemed to think now is the time to release all software as GPL. Here's what you need to ask yourself before you license your code as GPL. First, do you have a business plan that involves selling your software? Most people do not, most business plans have to do with actually using custom software. If that's you then your software and your business become better as more developers work on your software. I.E. when your software is applied to more real world situations, more bugs are fixed and more patches for features are received. GPL does not help you gain users because it shuts out most commercial enterprises.

Zed Shaw argues that without a GPL license a startup business might use his code and not pay him anything for it because startups do not like paying for things. This is probably true. But most startups are not too strict about code ownership -- that is, their developers are typically free to contribute to open source projects, unlike developers at big companies like Apple where code you write for your blog at home on your couch is owned by Apple. Zed Shaw's strategy is to shut out the startups and any other commercial (closed source) entities unless they pay for his code. That's great for him because his business is in selling code (similar to how ExtJS sells its code, maybe?). That's not so great for your project if you want patches from said benevolent startups :) Please consider using the BSD, MIT, Apache 2.0, or a similar license for your code if you are not trying to sell your software. More people will use it, your software will get patches, and you will get more bug reports and bug fixes.

Take Django as an example of a successful open source project that is distributed under the BSD license. Would you fork Django, pay them nothing, take all the credit (except for copyrights)? Well, you could do that but you never would and here's why. As soon as you fork Django, the main line of Django will get better and it would require more work from you to keep up with all the improvements made to Django. I'm not saying Django is perfect but it is very popular and has gone from a mediocre 0.96 release to a stellar 1.0 release in a small amount of time. Why? Because many different people, including those who might even use Django for commercial purposes, are relying on the fact that Django is a rock solid product; they are contributing their expertise to test and report bugs and possibly implement new features. So before you hinder the success of your own project by making it GPL consider all the commercially employed developers out there who are of the benevolent kind, the kind who give you patches ... for free! I don't have empirical evidence but I'd bet that most developers, when working in a corporate environment that supports open source collaboration, are motivated enough to contribute patches or at least report bugs.

Let's go back to Apple for a minute. Specifically, Apple's open source browser engine, WebKit. That was a fork of KHTML and now they have more or less merged. Guess what? Apple was forced to release that fork as open source since KHTML was licensed as LGPL. LGPL is a little different than GPL but my point is that you do run the risk of a company forking your code and making it closed-source when you use a BSD or similar license. You need to be aware of this risk when not using a GPL license but it's really not so scary when you consider the case of Django and any other successful project. There is not much incentive for a company to fork and privatize your code unless they are doing something very specific to their business (that no one else would benefit from anyway) or your software literally prints money or something amazing like that.

OK, so if you use the GPL does that mean you are protected from evil corporations and that no one will fork your code and steal away your business? No! Take the MySQL database for example, licensed under the GPL. There is a fork of it called Drizzle. I'm not saying Drizzle will ruin all the business made out of MySQL, which is a very big consulting business, but it certainly could, I suppose. Open source software is effective because it puts software in the hands of more developers then you could afford to employ. A license like GPL stifles this kind of growth so be careful. It may not be what you want.

If you've read this far and would like a more succinct explanation of the GPL's limitations with a good intro explaining open source licenses, see this article.

  • Re: Why you should NOT license your code as GPL

    "Zed Shaw's strategy is to shut out the startups and any other commercial (closed source) entities unless they pay for his code. (...) That's not so great for your project if you want patches from said benevolent startups :) Please consider using the BSD, MIT, Apache 2.0, or a similar license for your code if you are not trying to sell your software."

    Makes no sense to me. How does adopting GPL will actually make your project receive less patches, or adopting other license will make you receive more patches? It doesn't matter if there's a paid version of your product, it doesn't restrict patches in any way. See ActiveState's Komodo IDE for an example of GPL'd paid product.

  • Re: Why you should NOT license your code as GPL

    If you want to receive patches you have to go BSD because no one ever contributes to GPL projects, ever! (Please ignore the very existence of Linux, and pretty much all of Gnu, Debian, Gnome and KDE)

    The best way to get contributions is to NOT require them, GPL require sharing contributions so nobody will do it.

    Yes, in theory someone could make a closed fork to undermine your business but don't worry nobody really wants your code (could you please look away from Cupertino?). Unless your code prints money no body is going to fork away so you should use the license that allow that which will never happen.

    Oh! And the GPL doesn't protect you from forks! Look at MySQL and Drizzle! If MySQL had used BSD, Drizzle could make closed improvements and take MySQL out of business! But no, they foolishly used GPL, ensuring all worthy improvements from Drizzle can be merged back! Can't you see how negatively affected MySQL was for using the GPL?

  • Re: Why you should NOT license your code as GPL

    It's nice to see people making attempts at sane advocacy about license despite the trolls out there. From my perspective, as someone who has done a lot of open source and closed source work, I always prefer the BSD license and so do my clients and masters. If we make general improvements that aren't part of our core business IP, we can give them back, and we don't have to worry about our core IP. Since it means there's less for us to maintain, we generally give back general improvements. If I do something special, odds are the main project wouldn't appreciate it anyway, but since we have the option of doing stuff we can't or wouldn't want to give back, we've got a pretty big incentive to improve and build on that BSD licensed system, instead of what people tend to do, for example, in the networking space with Linux, which is to throw another TCP stack on top of it and new device drivers, or to throw a nasty layer that does nobody any good on top of the existing TCP stack, so there's nothing to give back, and all improvements (even general ones) are proprietary.

    When a network infrastructure equipment vendor improves TCP on Linux they seldom do it in a way they can give back unless interoperability is a core concern. When they do it on, say, FreeBSD, it's always much more possible that it could be merged, and then all they have to decide is whether they need to.

    I don't see how people don't get that the BSD benefits both groups in that case; the point of the GPL is social change and the elimination of closed source, which is why it's viral, RMS will even tell you so. The only people I know who genuinely love the GPL are people who want nothing to do with closed source and find it immoral and unethical. So long as closed source is around, companies will choose to develop on BSD or to develop on GPL'd systems in such a way that their improvements are seldom funneled back.

    The Linux kernel is a good example of this, in a way, in that e.g. Wireless vendors frequently develop their own wireless stacks or wireless add-ons that don't interoperate at a software level, because they also want to keep some of what they do with it closed source. The same thing happens with databases, and even desktop environments. The GPL forces people to be defensive, and that hinders integration, and that hinders giving back. You can't actually force people to give back, they'll just take their toys and go home. It took a while, but Apple is heavily funding Clang now because the GNU people put them in their sights wrt GCC. GNU played rough and got one over on NeXT (with GCC), but it's obvious that that lesson has been learned. Apple won't even allow any use of GPLv3 code, let alone integration into their system. This is what happens when you act anti-socially.

  • Re: Why you should NOT license your code as GPL

    Juli Mallett: "It's nice to see people making attempts at sane advocacy about license despite the trolls out there."

    Name-calling is always a great opener.

    "It took a while, but Apple is heavily funding Clang now because the GNU people put them in their sights wrt GCC."

    Stallman actually talked to Jobs about this - there's an e-mail conversation referenced in one of the recent licensing discussions [1] - and after consulting a lawyer, Stallman told Jobs that the hitherto unexplored situation of dynamically linking a proprietary front-end to GCC was probably going to violate the licence. It's tiresome to see how the FSF are somehow made out to be the aggressors for making their software available for other people to use.

    "GNU played rough and got one over on NeXT (with GCC), but it's obvious that that lesson has been learned."

    No, they insisted that people comply with the licence.

    "Apple won't even allow any use of GPLv3 code, let alone integration into their system. This is what happens when you act anti-socially."

    Another little example of name-calling. Apple, meanwhile, actively patent software and user interface concepts, so if you drop the sports metaphors and general antagonism towards the Free Software movement, you'll possibly notice which party is the anti-social one.

    [1] http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/doc/Why-CLISP-is-under-GPL

  • Re: Why you should NOT license your code as GPL

    I'm not sure if rgz is being sarcastic when saying we should ignore the examples of GNU, Linux, Debian, GNOME and KDE, but there seems to be confusion about what actually stops people from contributing.

    It's often the mechanisms for contribution that prevent people from contributing (they need to assign copyright to the project) or the environment the users work in (they are not allowed to contribute for legal reasons). These factors may be independent of the licenses used.

    What Zed complains about is that the "not forcing people to contribute" model didn't work for him in a way where it does work for more established, shared-ownership projects with many stakeholders like Apache or Django in which there is less incentive to fork, though there are probably plenty of hidden forks of Apache out there in the wild.

    Saying that using the GPL to force people to contribute won't work in practice is contradicted by real life examples like Linux and GCC, where the license has proved very effective in getting people to contribute who would otherwise have forked and closed the project. It might not work for every project, but then, I don't think Zed is looking for code contributions from proprietary users.

  • Re: Why you should NOT license your code as GPL

    "Would you fork Django, pay them nothing, take all the credit (except for copyrights)?"

    This is an interesting point, but it confuses issues of project momentum with those of licensing. If you can fork a project and keep the changes private, it is usually only worth it if you can outrun the mainline.

    You then bring the example of WebKit to the fore, whose progenitor (KHTML) had a very different profile to Django, having relatively few active committers. Had WebKit been permissively licensed, Apple would have had the benefit of the hard work done by the KHTML developers, but those developers would never have had the benefit of the work done on top of theirs.

    "You need to be aware of this risk when not using a GPL license but it's really not so scary when you consider the case of Django and any other successful project."

    So what you're saying contradicts the WebKit example: don't worry about permissively licensing your code because if your project is successful then no-one will fork it. KHTML is successful - it's been shipped as a central part of KDE for years - yet has only enjoyed a moderate pace of development; had it been permissively licensed, there would have been no growth in the development community in terms of Apple employees, who would be maintaining and shipping their own private fork of that code right now. This touches on another unquestioned assertion often made about permissively licensed projects attracting more contributors - such assertions assume that "commercial" contributors are enlightened about the benefits of sharing their work with others.

    Perhaps, if KHTML had been GPL-licensed, Apple would have needed to find another project to use, especially if one believes that Apple were merely trying to make use of the most permissively licensed or weakest copyleft-licensed project for their purposes. To demolish another myth, that would actually have been Apple's loss: they would have either had to wrestle the beast that is Mozilla, start with something less capable than KHTML, or buy some proprietary product and do a Java-style audit on the code.

    "OK, so if you use the GPL does that mean you are protected from evil corporations and that no one will fork your code and steal away your business?"

    Note that in the case of MySQL (the business), their competitors may be enhancing the code, but just as MySQL cannot sell those enhancements as closed source components, their competitors cannot do so, either. (If those enhancements can form part of a completely different software stack, then they do have that opportunity, however.) But as others have pointed out, MySQL (the project) still benefits from the changes of competitors, and the project may evolve to become more Linux-like in terms of ownership, making the closed source distribution less and less relevant.

    Myself, I can't say that I'm that interested in licensing dilemmas driven by a motivation for some code to be closed off and shipped off to "consumers" with a "do not open" sign on it. The people who complain the most about the GPL are those who feel most threatened by it (and the benefits the end-users and others actually get from its use), who use terms like "viral" and "cancer" to try and sway those without any particular position. As far as these vocal complainants are concerned, let them squirm.

  • Re: Why you should NOT license your code as GPL

    I don't get it. I don't want to give you the option of selling my work for profit, unless you pay me for it first. At the same time I want you to be able to do cool things with it, if you share with me and others what you've done. And you are bitching because you can't profit from my work without giving me a cut? Do you work for the RIAA or some other place that has massive entitlement issues? Seriously why do you deserve the money and I don't? Is it because I choose not to pursue it super hard, and instead spend my time doing something more interesting?

  • Re: Why you should NOT license your code as GPL

    All I'm saying is that non-GPL projects have the potential to reach more users and thus to receive more patches. Of course a GPL project can be just as successful and receive just as many patches (Linux, MySQL, many examples).

    It's just that a lot of people (Zed, Erich in the comments, etc) seem to be afraid that they will not be paid their dues when using a permissive license like BSD. That's an irrelevant fear if you ask me. Free software is free because it cannot be bought. When you put a price on it no one will buy it because it's free! It pretty much defeats a lot of economic models which is also quite interesting.

  • Re: Why you should NOT license your code as GPL

    For those who need a sign, yes I was being sarcastic, on my defense I'm only repeating what I read from Kumar's post.

    Let's analyze this slowly, there are two types of "users" (coders, not end users) of open source software.

    a) Open source developers who are willing to contribute.

    b) Closed source developers who want your code but don't want to contribute.

    BSD attracts both, GPL only attracts the first group, of course it can also make some people change from the second to the first group, at least for the current project, yet the GPL fails to convert those adamantly opposed to sharing their work.

    Kumar's logic is that BSD licensed projects will receive more contributions because it panders to the group of people who will refuse to use a tool specifically on the grounds that it requires them to share improvements.

  • Re: Why you should NOT license your code as GPL

    I'm also saying not to *underestimate* that group of people who are unwilling to share improvements. Those people are usually working in a corporate environment where the boss is hesitant to release in-house code (sometimes for valid reasons, or because code would not be useful to others). These users are important! They report bugs and sometimes even submit patches. Note that submitting patches is often easier than releasing the *entire derived work* to the public. The GPL shuts out this kind of user for the most part.

  • Re: Why you should NOT license your code as GPL

    I have to admit that I considered that scenario and didn't mention it because it doesn't seem realistic at all.

    Those "valid reasons", to not contribute back to BSD projects can be summed up as gaining competitive advantage. Valid indeed but bad for you. "because the code isn't useful to others" is a bad excuse, if the code is being requested that means you think it is useful.

    They are indeed motivated against helping you so I wouldn't expect any patches from them, shall you receive a patch from some guy, he most certainly be a general OSS contributor and would have helped you even if you used the GPL license, maybe even *specially* if you used the GPL.

    The exception is when the closed source project realizes you are a partner and not competition. In this cases the LGPL still helps you better than BSD.

  • Re: Why you should NOT license your code as GPL

    GPL vs BSD is really simple.

    If you have to even think about this, you should go with BSD. GPL is for people who think that if you use their code, their benefit is your patches and money comes elsewhere. If you go with bsd, its just like saying: I dont give a jack what you do with my code.

    Ps. Totally agreeing Erich.

  • Re: Why you should NOT license your code as GPL

    What people seems to be missing here, is that GPL also allows for commercial usages: I can totally pick your software, and resell it, with or without any modification.

    Of course, with the GPL, I'll have to give back the sourcecode, while with BSD I won't be required.

    Both types of licenses are legit in their own ways.

    Personally, I tend to prefer a weak copyleft such as LGPL: give back the sourcecode, but only for the very library you're using. About the rest of your wonderful code, I don't care what you do, and that's fine by me.

    This is for me a fine share: i've spent time on code you're using to spare your own time (and reduce your overall cost, as well as raising the value of your product), so it's only reasonnable to give back your changes of at least this library.

  • Re: Why you should NOT license your code as GPL

    Re: GrosBedo

    "What people seems to be missing here, is that GPL also allows for commercial usages: I can totally pick your software, and resell it, with or without any modification.

    Of course, with the GPL, I'll have to give back the sourcecode, while with BSD I won't be required."

    Yeah, the GPL fanatics happily mention point 1, but are more quiet about point 2.

    It's like they say "I want to walk around naked and unwashed and unshaven (think Richard Stallman) because, basically, I'm a smelly nut". But if they, in some rare moment of lucidity, say something intelligent and you want to use that piece of knowledge you also have to walk around naked and unwashed and unshaven. You're not crazy so you drop it, and the rest of the world, lose the value in that piece of knowledge.

    Welcome to 'freedom'.

  • Re: Why you should NOT license your code as GPL

    Attitude reflects leadership.

    The FSF's main developer was, has been and still is more than adequately compensated while demanding in his license that others work for nothing. Rather hypocritical in most circles.

    Apple supports clang, but anyone contributing to clang does not get paid.

    Intel supports MeeGo, but anyone contributing to MeeGo does not get paid.

    Attitude reflects leadership.

    In a world where Apple, Microsoft, Intel, IBM have sought for riches at the expense of many the FSF is a far cry from a solution nor for users nor for developers looking to be a part of society and not anti-socially parasiting from it, in most cases violently.

    Stallman got a lot of people by surprise. He caught a lot of people off guard, myself included (I have to port a lot of work off all GPL code dependencies as a result of the FSF's misleading people to believe they could negotiate commercial agreements with the original authors of the code. Those efforts are met with violence towards "proprietary" which is now known to mean "not Stallman's proprietary Copyrighted code".

    His proponents, if they be of concience, ought let him fall completely.

    Incidently a fair compensation license is social.

    A distributed cost license is social (in fact very social).

    If one want to give away something for free with no strings attached I'm pretty sure they know how to go about it themselves.

    Cheers! and happy fair compensation license coding!

    PS: you can always request your RnD funding in the distributed cost instead of looking to chase down angel investors, venture capitalists or large rake em dry co's like Apple, Ms etc..etc..etc..

    You either make the world a better place, or you don't.

    Attitude reflects leadership.

  • Re: Why you should NOT license your code as GPL

    the awful true:

    a) small open source project will not get ANY COLLABORATION unless this project will turn popular.

    b) big open source project will get LOTS OF COLLABORATION but, at this level, you don't want any help but by a select group of collaboration.

    So, there are little gaining to launch a project as open source unless you want to get away with your code.

    Also is the case of FORK. For example for LMS (Learning system), existed a LMS called Claroline and it was forked in not one but several LMS that literally killed the original LMS. When a project is forked then the original code could take the new code and incorporate in the main branch. However, if a project is forked several times then, it is not quite possible to track every change and, most of the time, it is left behind.

    IMHO, apparently the best solution is to dual license. BSD is insanely open and LGPL is filled with legal loopholes.

  • Re: Why you should NOT license your code as GPL

    I dev'd a popular Linux-based p2p file sharing program from 2003 to 2007. It was a fork of a Windows-only GPL'd p2p file sharing progrma.

    In mid-2003, after the first 50,000 or so users started using the app (e.g. w/n the first 6 months of success), it was forked. All they did was rip out my name from all the copyrights on every file and change a letter in the name from "x" to "a".

    Then, while I was away on a trip and unknowingly, they proceded to viciously attack both me personally (death threats, lies, etc.) online and the app, on every forum and posting that mentioned it on the internet.

    When I came back a month later, over 1/2 of the users of my app had gone to the duplicate (forked) app that at that point had only a single letter change, just because of the ungrounded attacks by the hostile forkers.

    Over the next few years, I poured my body, heart, and soul plus plenty of sweat and literal tears (particularly due to their continual and aggressive online harrassing (telling me I should never been born, etc.)), I realized it was a hopeless battle.

    What would happen is that due to the GPL'd nature of the code, every time I committed improvements, the forkers would blatantly copy my code and immediately release a new release, even faster than I could, becuase there were 1 to 3 of us nad like 20 coders for them, and then they'd say we copied them, but it was never the truth.

    Even when there were less than a 100 users of my app, I still believed in creating a distributed file system that couldn't be shut down by repressive governments (the app's motto is "to preserve rare cultural content while fighting fascism and promoting freedom"), so I kept it on.

    By mid-2007, however, they started attacking people in my present and past, so I decided to call it quits, and my life has been so much happier.

    My point is that if you are hostily forked, there is NOTHING you can do about it legally per the GPL. You are SO SCREWED, it's impossible to fight against it if your project contains a non-trivial amount of GPL code from other projects, as mine did.

    These GPL people are fanatics. I tried explaining my plight but all the FSF did was attack me, throw me out of Gna, berlios and got threats of dropping from SourceForge (who still kept it going). The app got thrown out of the linux distros cuz they were too afraid to deal with the wrath of the FSF and GPL nutters who SCREAMED lawsuits.

    It's just not good. Not good at all. I did it for free, at considerable hosting expense (esp. after getting cut off of the source code places), and people would insult me, in the meanest ways, both online and in real life, almost non-stop, then spread lies about me EVERYWHERE, and for what? A few users?

    I never understood. Still don't.

    Just google "preservation of rare cultural content" or "Promote freedom; fight fascism" ;-/ Even tho I was more flawed then in my youth than I am now, I honestly had good intentions. I did not deserve that treatment.

    PS I'd like to thank Avi and malware who were great co-devs! And Xaignar of the hostile fork project for always being the only sane one of the lot of 'em.

  • Re: Why you should NOT license your code as GPL

    Wow, that's a crazy story

  • Re: Why you should NOT license your code as GPL

    A very sad story indeed. But how is it related to GPL? If your project was a BSD one, would it have been better?

    Yes, you could have closed your changes. But that would also have the effect of closing you the doors of most distributions repositories.

    And I don't know for you, but I wouldn't trust a random binary downloaded from whichever place on the internet whose purpose is "privacy".

    Though your point is perfectly valid. Thanks for that. But the bright side is that you could figure out that these people were basically forking you without making any change. With BSD licence, you wouldn't know that.

    Nowadays with Github/bitbucket and others running, it is much easier to prove who forked who.

    This was basically harassment. In most country, you can charge these people and have their site shut down.

  • Re: Why you should NOT license your code as GPL

    Well Even Zed Shaw, changed this License of Lamson to BSD, That speaks volumes in itself. Checkout the License here https://github.com/zedshaw/lamson

    Although i am not sure if the author can change the License after they release there software Under GPL. Isnt that Illegal ? Can any one here answer that ?

Note: HTML tags will be stripped. Hit enter twice for a new paragraph.

Recent Projects

  • JSTestNet

    Like botnet but for JS tests in CI.

  • Nose Nicedots

    Nose plugin that prints nicer dots.

  • Fudge

    Mock objects for testing.

  • Fixture

    Loading and referencing test data.

  • NoseJS

    Nose plugin that runs JavaScript tests for a Python project.

  • Wikir

    converts reST to various Wiki formats.