Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; he spends his daytime hours at the startup he founded, Tilde Inc.. Yehuda is co-author of best-selling jQuery in Action and Rails 3 in Action. He spends most of his time hacking on open source—his main projects, like Thor, Handlebars and Janus—or traveling the world doing evangelism work. He can be found on Twitter as @wycats and on Github.

The Maximal Usage Doctrine for Open Source

I’ve worked on a number of open source projects over the past several years (the most prominent being Merb, Ruby on Rails and jQuery) and have begun to form some thoughts about the usage (aka adoption) of open source projects and the practical effects of license styles.

The Playing Field

There are essentially two kinds of licenses popularly used in open source[1].

The type I’ve worked with most extensively in the BSD or MIT-style license. This license allows unlimited usage, modification, distribution, and commercialization of the source code, with two caveats. First, the copyright notice must be distributed with the source code. Second, to the extent legally enforceable, if you use my MIT-licensed source code, you may not sue me for the effects of using the source.

The other major license type is called copyleft, and essentially leverages copyright law to insist that any modifications to the original source must themselves be made public. The practical effect of this license could not be effected without government-enforced copyright laws.

The most popular copyleft license is GPL, which is used by Linux, and which also has viral characteristics. In short, if you link code covered by the GPL into your own code, you are required to open your code as well (if you distribute it). The GPL is not very clear about what this means for more dynamic languages (is requiring a Ruby file “linking”?).

A less viral version of the GPL, the LGPL, requires that any modifications you make to the software itself be released, but drops the “linking” requirement.

Because of the uncertainty surrounding the viral characteristics of the GPL, legal departments in big corporations are very hostile to the GPL license. Software covered by the LGPL license is more likely to get approval by corporate legal, and MIT/BSD licenses are the most well-liked (probably because they don’t confer any obligations on the corporation).

What I Want When I Write Open Source

When I work on a serious open source project, like Ruby on Rails or jQuery, I have relatively simple desires.

One. I want as many people as possible to use the software I am working on. This is probably a selfish, egoist desire, but it may also be a desire to see useful software actually used.

Two. I want some subset of the many users to be willing to report bugs, and for the varied situations the code is used in to help improve the quality of the software as a result. This is essentially “given enough eyeballs, all bugs are shallow”.

Three. I want people who are interested in improving the software to submit patches. Specifically, I want to receive patches from people who have thought through the problem the bug is trying to fix, and want to receive fewer patches from people who have hacked together a solution just to get it to work. In essence, a high signal-to-noise ratio of patches is more important than a high volume of patches.

Four. I want people who are interested in improving the software long term to become long-term contributors and eventually committers.

Of these concerns, numbers two and three are the highest priorities. I want to expose the code to as much real-world pressure as possible, and I want as many high-quality patches to fix those bugs as possible. If I had to choose between those two, I would pick number two: exposing my code to real-world stress is the best way to rapidly ferret out bugs and incorrect design assumptions that I know of.

Meeting Those Requirements

Starting out with the easiest, my first desire, to have my software used as much as possible, is most easily satisfied by an extremely liberal usage policy. Adding restrictions on the use of software I write reduces its adoption almost by definition.

Much more importantly, the same can be said about exposing code to real world stresses. By far the most important way to achieve this goal is to make it as easy as possible for as many people as possible to use the code.

If only 1% of all proprietary users of the source ever report bugs, that’s 1% of potentially thousands of users, as opposed to 100% of the zero proprietary users who were able to use the software under a more restrictive usage scheme. In practice, this number is much more than 1%, as proprietary users of software experience and report bugs just like open source users do.

The only real counter-argument to this is that by forcing users to contribute, some number of proprietary users will be forced to become open source users, and their contributions will outweigh the smaller contributions of proprietary users. In practice, proprietary users choose proprietary solutions instead when they are forced to choose between restrictive open source usage schemes and other proprietary software.

There is also much to be said for exposing open source tools into proprietary environments.

There is also much to be said for introducing proprietary developers to the open source ecosystem. Proprietary developers have access to things like paid time, access to obscure usage scenarios, and access to markets with low open source penetration that the open source community lacks.

The next major desire I have while working on open source is a steady stream of high-quality patches. This should be advantage copyleft, because all users of the software are forced to contribute back. However, since copyleft licenses are not used in proprietary environments anyway, the patches to open source projects from those environments under more permissive licenses are much more numerous. Again, even if only a few percent of proprietary users contribute back to the project, that is significantly more contributions than the 100% of zero proprietary users.

Also importantly, the patches are contributed by much more dedicated users of the software, instead of being force-contributions. I have never heard a team member on an open source project say that inadequate patches are received by permissive-license software, and that this problem would be solved by going to a more restrictive model.

Finally, I can only speak for jQuery and Rails (and other smaller open source projects I work on), but a large number of new long-term contributors became involved while working on corporate projects, where a permissive license made the decision to use the software in the first place feasible.

Lower Barrier to Entry Helps Meet Open Source Goals

Regardless of how much of the above argument you agree with, it is clear that copyleft licenses intentionally impose a higher barrier to entry for usage than more permissive licenses.

For projects that use more permissive licenses, the fact that many proprietary users of their software do not contribute back changes is a feature, not a bug.

That’s because we don’t focus on all of the people who use our software without contributing back. Instead, we focus on all the users, bug reports, patches, and long term contributors we have gained by keeping the barrier to entry as low as possible.

In the end, the world of ubiquitous open source is here. And we made it without having to resort to coercion or the formation of an entirely self-contained set of software. We made it by building great software and convincing real users that it was better than the alternative.

Postscript: Linux

Linux is a peculiar example because its license has not impeded its usage much. In part, that is because most users of Linux do not make changes to it, and the linking characteristics of the GPL license rarely come into play.

In cases like this, I would argue that copyleft licenses are close enough to usage maximization to get most of the benefits of more permissive licenses. However, it’s not clear to me what benefits the copyleft licenses provide in those (relatively rare) cases.

[1] There are other kinds of licenses, like the Affero license, which is even more restrictive than the GPL license. I would classify Affero as copyleft.

26 Responses to “The Maximal Usage Doctrine for Open Source”

Using the GPL or the LGPL doesn’t force people to submit patches. The only thing it forces you to do is to make the source code available for any software that you *distribute*. If I modify any GPLed code, I’m not required to share my modifications until such a time as I distribute my program. I can sit on my patches forever and never share them, and that’s perfectly fine.

The problem with a MIT/BSD-style license is that a company can use your code, modify it, compile it, obfuscate it, and then sell it to people and never let them see the source. If you see that their code can run method ‘foo’ 100x faster than yours, well, that’s too bad for you. If you want the same speedup you’ll have to figure out a way to achieve it yourself. This is exactly the scenario that the GPL is meant to protect against.

I also wonder if the GPL restrictions apply when you change code in runtime using Ruby metaprogramming techniques. Does it apply to files or running code too?

I’m very much in agreement concerning your preference for BSD/MIT-style licenses for Open Source projects. For me the point of writing Open Source code is so that anyone, no matter their purposes, can make use of my work. This is not the goal of the Copyleft crowd though. There’s a fundamental disconnect between the motivations of Copyleft developers and those of plain Open Source developers. And the disconnect centers on the perception of “rights.”

Copyleft developers believe that there is some sort of “right” to modify, distribute, etc. code that needs to be preserved. And they seek to preserve these various “rights” by leveraging the copyright system. I’ve gotten into countless arguments over the merits of the GPL and Copyleft and the issue always eventually boils down to a perception of morality concerning code. I once had someone tell me that the GPL and Copyleft was the only morally correct way to produce software. Not all Copyleft advocates are so dogmatic, but that is what the Copyleft licenses are built upon: a perception that there is morality tied up in software development.

Alex M.,

that’s only one potential scenario, not a very common one. Just like Yehuda mentioned: code is coming back.

The GPL doesn’t really protect either. You probably won’t know they used certain source code.

The world would be a much better place if lots more high quality MIT/BSD licensed code would be used by corporations, instead of reinventing the wheel. The license is not a guarantee for good code off course. (in fact, there is so much crappy open source out there….).

In my opinion:
* GPL is selfish
* GPL is open source, not free source

I think your goals exist in a world where the GPL has already created a conducive environment. By ensuring a base level of software that is “free” — in the “free as in speech” sense of the word — the GPL has given the open source ecosystem a substantial amount of high quality code that is safely its own. It’s from these code bases that amazing communities have arisen to create the larger open-source community where it is more-or-less taken for granted that if you /can/ contribute back, you do.

But imagine a world where that community doesn’t exist… and all those cool expectations that you listed aren’t the norm, because the idea of open source software never really caught on. New projects spin up, some commercial outfit recognizes there is money to be made, appropriates the software and the community, and that’s that. But with the GPL, and all the code it protects, firmly in place the rest of the community is free to experiment with more permissive licenses safe in the knowledge that the OSS community isn’t going to die out tomorrow.

I appreciate that the GPL isn’t for you or your projects, but failing to give credit where credit is due… it’s just bad form.

When it comes to IP, most companies tend to err on the side of caution. Even when your usage would be safe, they’ll want no part of it. It is better to not leave yourself open to question. On the flip side, MIT/BSD is no problem at all. Where I work, it could be the world’s greatest code, but if it has a copyleft license we’d never even consider using it.

So what is your fear when releasing open source code? Is it commercialization or not contributing back? If it is not contributing back, then certainly encouraging adoption is the best way to go rather than scaring away potential users. If you fear commercialization, then go for the GPL. The two camps have different motives.

At least from the project’s I’ve worked on, having commercial products using your code is a good thing. They have a vested interest in seeing continued development and your app/library being successful. Often, we’d rather contribute a patch back than to be stuck maintaining our own fork (in addition to our app’s code).

probonogeek: FreeBSD predates Linux and the work of the FSF. Open Source existed before Linux or Stallman or the GPL. It’s speculative to think what the landscape would have been like without the rise of the Free Software movement but that movement has always been somewhat distinct from the much broader Open Source movement that predates it in the *BSD community. Free Software and the GPL is about a very particular sort of ideology concerning software and its code. The BSD/MIT tradition is much more relaxed when it comes to issues that the Free Software crowd take very seriously.

This is exactly why I use a BSD license (or sometimes the WTFPL, if I’m feeling snarky) for my projects. I’d like for the most amount of people possible to use my software, regardless of what they end up doing it.

If I can help another do whatever it is that they’re doing, that’s good enough for me.

Hello, interesting view point. In the context where you are working in Engine Yard leaders on Merb/Rails frameworks I think it makes a lot of sense.

Now, I’ll defend a bit the GPL however. There are also some situations – I’m currently working a lot with open source ERP’s such as OpenERP and I think it’s a great example – where if the editor fools him into releasing under MIT/BSD/Apache, he will just be beaten down the line by competitors taking all his work, investing a bit, packaging it better and fucking them with a cheap closed source package/Saas. Even with the GPL, they suffers illegal hidden forks trying to beat them with their own products. Now, with a liberal license…

In in short: I agree that GPL here to just force everybody pay or contribute feedback is indeed narrow minded by a time where Open Source already won the battle (well, forgetting about beloved Sun/MySQL), especially when speaking about framework that is hardly a pure editor job. Now, if you choose GPL/AGPL to ensure you as an editor won’t be killed by a closed source fork/Saas, I think that perfectly makes sense until better is found.

Thoughts?

There is a paper on the ACM site that gives another good perspective on software licenses. I believe it was written by a lawyer who also has a technical background. It’s a good, short read. http://queue.acm.org/detail.cfm?id=1005066

Also, I believe the GPLv3 is much more restrictive than GPLv2 and this may lead to some more shunning of open source products if it is widely adopted. e.g. FreeBSD trying to move their core away from newer versions of GCC and onto LLVM.

http://ivoras.sharanet.org/freebsd/freebsd8.html

“The only way to control your content is to be the best provider of it.” Source: http://nrkbeta.no/2008/03/26/the-nrkbeta-doctrine/.

I think this applies to open source software as well, which is why I prefer BSD-style licenses to GPL-style licenses. License restrictions doesn’t work, just as making piracy illegal doesn’t work. (Ref arguments in the mentioned nrkbeta.no article.)

@James Thompson: No doubt, there were a lot of efforts that came before the GNU project and the FSF, of which FreeBSD is one and absolutely deserves credit in that lineage. As for speculative… maybe so, it’s hard to say. All I know is what did happened, and from that perspective I see the GPL, GNU, and FSF making huge advancements and creating the spaces in which free and open source software, under a variety of licenses, thrive.

When I look at what the BSD license has gotten us… well, I can’t help but remember: http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish.

Truth is, I wasn’t going to post anything at all until wycats follow up tweet suggesting this post should have been called “Why the GPL sucks.” Seriously?! A lot of really smart people think otherwise, I don’t think it’s inappropriate to show a little humility.

Your project’s license is determined by your goals, so I don’t think there is any license intrinsically better than any other. If your goals are dependent upon widespread adoption (which is necessary for serving all of Yehuda’s goals), a permissive license will better serve that purpose.

The GPL can be useful in releasing software under a dual license, as in the licensing model of ExtJS with their quid pro quo principle. In that way, the GPL can be used to support a certain kind of licensing/business model, while still contributing to the open source community. I don’t think there’s anything wrong with requiring some kind of contribution in exchange for a software product, assuming you’re okay with taking the adoption hit.

With either a restrictive or a permissive license, the developers get the results that they want. Appcelerator’s projects and business objectives are better served by releasing under the business-friendly Apache 2.0 license, so that’s the OSS license we chose. Different strokes for different… projects.

If we’re speculating on counterfactual history, what might the software ecosystem look like today if the GPL were more like BSD or MIT? Linux could have gained greater market share; open source could be even more popular.

I think it is safe to say the GPL effectively stops any commercial exploit of a software as a product. It makes it hard even for the original author to squeeze money out of a GPLed project, since Business distrusts the hidden hooks of GPL deeply (as was already said here). But if you’re fine with that, GPL is a good license, since you have the FSF to fight for you (which might proove worthy for single developers or small teams).

If you are, say, 37signals, opening the infrastructure projects under MIT/BSD is a smart move: You won’t sell this software anyway, so why not crowd-sourcing the development? In case of 37signals, it had the additional benefit of driving business to them. If that’s you line, go with BSD/MIT. But keep in mind that you will probably be unable to immediately get money out of the software you are releasing.

What I don’t like are “dual licenses”: It’s a foggy thing, trying to catch customers with pretended OSS terms, while any commercial application nullifies the OSS promise. ExtJS is an especially nasty example: Either you agree to never make a penny with our project (it states you must open *your* product, not help them with ExtJS), or you pay a rather hefty price.

Yehuda, GPL was designed in a world where code is compiled, the ultimate form of obfuscation. Yes, the ideology behind GPL presupposes that information wants to be free, and that owning an idea is a terrible thing to assume you can do, because ideas aren’t tangible things. Anyone can provide a better service, but saying that one person owns an idea just puts limits on the marketplace of ideas.

There is a clear analogy in Western science. GPL requires peer-review. If you distribute an algorithm, you have to also distribute the means of testing and inspecting the algorithm. The MIT/BSD is more like subsidized research in this analogy. An institution may make a discovery, and then a corporation takes the discovery, makes a few modifications, and produces a product without ever sharing its modifications with competitors or the rest of the marketplace.

Clearly peer-review and commercialization have both done much for our civilization. Can you say that one is better than the other? Can you say which one we could do without?

I may be wrong, but most of your work seems to be in Ruby and Javascript, a world where the initial concern of the GPL, distribution of compiled code, is not an issue. Perhaps your opinion with respect to GPL vs MIT/BSD is biased towards interpreted languages?

A thought provoking article and discussion, thanks.

Personally, I lean towards a variant of the philosophy August mentioned: if the stewards of a project are doing a good job of serving their community, their community will support them back. That is why MIT/BSD licensed projects like jQuery and Rails succeed, and why other MIT/BSD projects do not. But that is equally true of GPL and LGPL projects: Linux is not the sole example, by a long shot (mysql, git, gcc, webkit, and 1000s more).

Further, I’ve worked at a number of very large corporations (Apple, Microsoft, Adobe, etc.) and of those companies, only Microsoft had any issue with using GPL’d software internally (and their stance may have softened in the many years since I worked there, I have no idea). Company lawyers do tend to shy away from including any GPL’d code in products that get distributed to end users because of copyleft, but in my experience this was not a big inhibitor. To name just one example, Adobe’s acrobat.com runs primarily on Linux servers using mysql and many other pieces of LGPL software. Of course, the fact that these corporations are using these GPL packages more or less “as-is” means that they are less likely to be contributing patches back to those GPL projects as you discuss in your article. But its not black or white.

For my project, Libre.fm, we chose the Affero GPL. Why? Because we want people to give back when they modify our software, and because it’s a web app, there’s usually no distribution involved for the user.

Regular GPL does the same thing for non-network applications.

If your goal is to protect the rights of the users to be able to live in freedom, you want the GPL.

@Till Salzer: The GPL family of licenses does not prohibit commercialization. Take for example the case of StatusNet – their product is licensed under the AGPLv3 – by this post’s author’s definition, and incredibly “restrictive” license. However, the company has received ventured capital, and has a solid business model developing customizations for paying customers, doing consulting, and selling support contracts. IMHO, the StatusNet business model seems far more robust that the Twitter (SN’s proprietary competitor) business model… which I still can’t figure out.

Free software can be commercial software. For another example, take a look at Red Hat. They make many millions of dollars per year in global profits on GPL’ed software, and they are clearly a commercial entity.

For another point of view, consider the case of say Pidgin, the popular IM client. Pidgin is licensed under the GPL, and has many proprietary competitors. If Pidgin were to be BSD/MIT/APL/etc licensed, you can guarantee some company would take the code, throw some money and shininess at it, and sell the result. They would make millions… and the Pidgin project would die. Users are left with unmaintained, buggy software (as proprietary software tends to be), and the original developers would feel “ripped off” as their code is now in use by a product they don’t even have the source code, and to add insult to injury, they would have to pay for it.

I’m a software engineer by profession, and make money doing it. And I’m certainly not concerned that Free software will ruin my career – in fact, I’m positive it will improve it.

I couldn’t agree more. We have two open source libraries we’d be very willing to contribute paid developer time to, *if* they were MIT/BSD licensed and not GPL. Why? Because we could then use the libraries in a proprietary product we’re developing to sell to commercial customers.

Instead, we have to redevelop the library from scratch. I can understand applications and ‘top-level’ software being GPL licensed as these are a ‘finished product’, but for libraries I would prefer them all to be permissively licensed, so we get one well-developed, solid library and not half a dozen incomplete implementations – as is all too often the case in the PHP world (and what I’ve seen of Python GPL libraries too).

Interesting, most people commenting and Yehuda seem to assume that a company cannot use the GPL and sell its products. I don’t agree.

For instance there are more and more hardware devices using embedded Linux being sold. Since Linux is licensed under the GPL the source code needs to be made available as well. This does not seem to have slowed down adaption of embedded Linux in the hardware world.

I guess it really depends on the context, but I would be very interested in any research results on the adaption and usage of software licenses in relation to the Tragedy of The Commons principle.

Personally I prefer to use copyleft licenses. It seems both the best and worst way to teach people the quid pro quo mentality some of us seem to take for granted.

Just one question:

Does Apple contribute to BSD as much as Intel, Nokia and Google contributes to Linux?

I really don’t think so.. I think they contribute because the license requires them to contribute, not because they are “nice guys”.

I simply choose to develop open-source software (always MIT licensed) that would never be monetizable. When you develop for the common good, and in an ecosystem where people are used to not having to pay for good things, you don’t have to worry what might happen if some company tried to monetize it, because you have a built-in, easy argument: my version of the code is free, their’s costs money. which one do you, little simple web developer, want to use?

AFAIK, MIT doesn’t require the license statement to be perpetuated through derivative works, but it seems to just suggest/request it. And this is good enough for me. I hope I get some credit for the work I do, but more than that, I hope my work contributes to the overall good.

Bottom line, the reason I open-source code is because I *trust* the open-source community as a whole.

I agree in general, but disagree on the Linux Kernel. For example, i use a LinkSys router as a little home server. Linux based and some time ago it was “just” a proprietary router. Threatened with a law suit they decided to open source the firmware und promote the entire product line as “open products”.

This would never have happened with a BSD style licencse.

Because a copyleft license has a network effect I think the essential difference is that a copyleft license guarantees more freedom to the person to whom software in general is distributed.

A BSD/MIT license guarantees more freedom to the person receiving or distributing specific software.

Both are useful.

Personally I agree that that non-protective licenses fit the needs of small or mid-sized Open Source projects, but in long-term GPL is a better choice.

For example, imagine that Linus chose BSD license for Linux, formed the community around it, but then after a while a big company decides to make its own closed Linux and calls in Pinux. Next say 5 years they constantly improve Pinux while merging from geek-powered community of Linux, so in 5 years they have all features of Linux plus a lot of their closed-source improvements. Would Linux have gained such success always being an outsider? I guess not.

Leave a Reply

Archives

Categories

Meta