The Open Road

If most developers contribute to open-source projects because they want to, rather than because they're forced to, why do we have the GNU General Public License?

Free Software Foundation

That's the question that hit me last night as I tried to sleep in the shadow of Richard Stallman's MIT. Stallman, of course, originated the GPL, a brilliant way to turn copyright on its head in order to force software to remain open.

But in the process, did Stallman simply create an alternative way to release proprietary software?

I'm not trying to be cute here. Think about it. If you you want to maximize adoption and reuse of your software, why wouldn't you use Apache? Perhaps because you don't like the thought of someone using your free software in a proprietary product?

"I would actually rather nobody use my software than be in a situation where everyone is using my gear, and nobody is admitting it," wrote Zed Shaw, creator of a popular library and Web server for Rails called Mongrel.

Shaw, and perhaps other coders, have turned to the GPL as a way to protect their software from use they deem objectionable. But isn't this precisely what the proprietary software licenses do? The only difference is that the GPL forces code to be open, rather than closed.

Are the two approaches so very different? The effect--blocking undesirable use of one's software--is largely the same.

After 10 years in open source, I'm increasingly of the Apache-licensing persuasion because I'm starting to concur with open-source luminary Eric Raymond that "the GPL is unnecessary...(and) is also a confession of fear and weakness."

If I'm mostly concerned about adoption, Apache promises to be better than the GPL for all the reasons stated by Daniel Jalkut in his excellent ode to Apache.

And if I'm concerned about protection, then why not simply use a proprietary license--one that doesn't scare opposing legal counsel?

With the Web making open-source licensing largely irrelevant, anyway, it's a good time to evaluate the merits of the two dominant open-source-licensing approaches. For this moment in time, they're essentially equivalent, at least to end users and Web developers, neither of which is required to contribute back derivative works.

Indeed, I believe that one of the primary reasons that Linux, MySQL, Lucene, Hadoop, and other Web-oriented technologies have thrived in the past few years is that they have basically come legal-encumbrance-free.

Would Google have built its server infrastructure with Linux if it had been required to contribute all its software back? Almost certainly not. Yes, it has elected to contribute back to MySQL and others when it was advantageous to do so, but I think that Affero GPL, which translates the GPL's provisions to network-hosted software, would have effectively killed the utility of MySQL, Linux, and other open-source technologies for Web titans like Google, Facebook, and others.

In short, perhaps the best thing that could have happened to open source in the past few years is the increasing relevance of its code due to the decreasing relevance of its licensing. More adoption due to fewer controls.

Developers don't contribute to open-source projects out of force. They do so out of interest, desire for recognition, and other reasons. Once you take force out of the equation, the GPL loses its relevance except as a tool to protect against competition...which proprietary licensing perfected long ago.

For those who worry about the world being closed off behind proprietary licenses, it's not going to happen. The software world has been opening up, though not always at the pace some open-source advocates would prefer. On this point Tim O'Reilly has correctly argued:

If you close things off, eventually, you lose. This is why one of my slogans is, "Create more value than you capture." As long as people are doing that, I don't care whether they're trying to capture some value (through proprietary licensing).

In other words, people don't have to be forced into openness. It happens out of natural, selfish desires. Given the history of humanity, that's probably a more dependable basis for business strategy than an expectation of charitable donations through code contributions.

So, wither the GPL? I'm asking a sincere question to which I have hunches but no definitive answers. I'd love to hear your thoughts.

Disclosure: my company licenses its software under the GPL. This post reflects my personal (evolving) opinion and should not be construed as representative of the intentions of my employer.

Follow me on Twitter @mjasay.

Over the past 10 years that I've been involved in open source, one thing has become strikingly clear to me: there are no real predictors of open-source success. There are, of course, general principles that contribute to the creation of successful open-source projects, but serendipitous "right project, right time" circumstances often matter most.

Apache Software License 2.0.

(Credit: Apache Software Foundation)

I was therefore intrigued to read two articles that crystallized my own thinking around critical components of successful open-source projects.

The first is from BusinessWeek and details the mechanics of Mozilla's Firefox community. Mike Beltzner, Mozilla's director of Firefox, reveals that while 40 percent of Firefox is contributed by outside developers, what and where they contribute may not be what many would expect:

There's structure in (how Firefox is developed). But at the same time you allow people to innovate and to explore and (give them) the freedom to do what they want along those edges--that's where innovation tends to happen in startling and unexpected ways (emphasis mine).

This may be easier for the Mozilla Foundation, given its nonprofit status, as you'd expect developers to more willingly build around a product if they trust the foundation (pun intended) upon which they're building.

But the general principle holds: most open-source development and, for that matter, most development around proprietary software, happens at the edges. Whether it's Microsoft Windows or Mozilla's Firefox, developers generally don't touch the core: they create add-ons, complementary products, and so forth.

So, principle No. 1: Open-source projects that create a strong, valuable, easily extensible core that developers have the ability to build upon, as well as the pecuniary or reputational interest in extending, are more likely to succeed. No one works for "free."

The second principle is related to the first, and deals with ownership of add-ons. While some people are motivated by peace, love, and open source, others (rightly, in my view) see open source as a means to an end, and not the end itself.

As such, the license used for an open-source project matters a great deal. I've long been a proponent of the GNU General Public License (GPL) because it enables vendors to bless customers (free code!) while cursing competitors (we just open-sourced your entire value proposition and you won't dare touch our code!).

But lately I've been seeing the role Apache-style licensing can play in fostering vibrant open-source communities. Daniel Jalkut, founder of Red Sweater Software, describes this well:

As the developer evaluates communities to participate in, they must evaluate the legal impact such participation will have on their own project. The closed-source communities are, by definition, uninviting to outsiders. GPL communities are open and embracing of other GPL developers, but generally off-putting to liberal-license and closed-license developers. Only the liberal-license communities are attractive to developers from all three camps.

It's your party, and you're entitled to write the guest list. But take a look around the room: not as many folks as you'd hoped for? Liberally licensed projects are booming. Speaking for myself, a developer who has been to all the parties, I'm much more likely to pass through the door that doesn't read "GPL Only."

If you want maximum participation whatever the cost, Apache/BSD is probably the right way to go. Most companies and project owners, however, have to make a living, so it's reasonable that they measure the costs of going Apache, which likely means they'll trade a liberal license to some of their code for a proprietary license of the rest of their code.

IBM is an example of this strategy on a big scale, but so are Day Software, Microsoft, SpringSource, and others.

Principle No. 2, broadly stated, is this: Your odds of encouraging adoption of your product go up if you use a liberal license like Apache, but your ability to directly monetize Apache-licensed code vaporizes.

This isn't a bad thing. It just means you have to separate community creation from customer creation, as Funambol's Fabrizio Capobianco has stated. The two aren't necessarily the same, and are sometimes inimical to each other.

As noted above, however, you don't have to license your software as open source to encourage community around it. Microsoft, with its vibrant partner ecosystem, demonstrates this, as does Apple with its amazing iPhone ecosystem.

Developers will flock to the platforms that offer them the most return, whether financial or in reputation (which eventually translates into money). Liberally licensing of your code might tip the scales in your favor if you lack the largess of Apple or Microsoft. But no guarantees.

Follow me on Twitter @mjasay.

The Open Knowledge Foundation blog provides some excellent reasons to take open-source licenses seriously, especially for data on the Web, but these struck me hardest:

Together, a definition of openness, plus a set of conformant licenses, deliver clarity and simplicity. Not only is interoperability ensured, but people can know at a glance, and without having to go through a whole lot of legalese, what they are free to do...Thus, licensing and definitions are important, even though they are only a small part of the overall picture.

If we get them wrong, they will keep on getting in the way of everything else. If we get them right, we can stop worrying about them and focus our full energies on other things.

Efficiency can be reached through consistency and transparency. This is why licenses like the General Public License and Apache/Berkeley Software Distribution work in open source: everyone knows what they mean or, at least, what everyone else thinks they mean.

They're not perfect licenses, but they're understandable, and the Open Source Initiative has proved invaluable in ensuring the ongoing integrity of what "open source" means.

As the debate shifts from software to the data enabled and constrained by software, it will be critical that open data licenses emerge. Just as open source and open protocols paved the way for the modern Internet, so, too, will open data ensure the freedom of the next-generation Internet.

Open-source licensing is fundamentally about efficiency, not law. It's about understanding and keeping everyone on the same page so that the more important work can move forward. Licensing matters.

Matt Aslett of The 451 Group and I met in London this morning, and discussed a range of issues. One thing that came up, which Aslett discusses on his blog, was the furor over CPAL, AGPL, and other open-source licensing designed for the Internet. I heavily contributed to that furor but, looking back, it would seem that the concerns were almost completely overblown.

Mea culpa.

A year and a half later, very few open-source projects use the CPAL license, which introduced a specific form of graphical attribution for open-source projects. There was sound around it, and there was fury, but the reality is the world didn't end when the OSI blessed CPAL, neither with a bang nor with a whimper. It simply ignored the licenses, even though a few prominent open-source companies like Zimbra still use CPAL licensing.

Affero General Public License (AGPL)? Fabrizio Capobianco cheered its progress recently, and I continue to believe it has a valuable role to fill, but the reality is that it powers 181 open-source projects out of more than 180,000, according to Palamida, and most of the projects that have adopted it are no-name projects.

Despite our efforts to tweak open-source licensing to fit the realities of Web-based "distribution" of software, the world still revolves around L/GPL, BSD/Apache, and MPL. I doubt this is going to change anytime soon.

Why? Because customers don't care about this issue. Just as they don't care about whether 100 percent of their code is open source, they also don't care about vendors protecting their code from other vendors. They just want software that works. If freedom comes with that, all the better, but they don't fetish licenses the way open-source vendors and communities do.

License proliferation, badgeware, and all the other "big" open-source licensing debates have turned out to be somewhat hollow in retrospect. Customers are voting for open-source software, not open-source licenses. There is a difference.

Wired has the scoop on what could have been the sexiest Linux device of all time: Apple's iPhone.

Given Linux's momentum in embedded devices, Linux actually makes a lot of sense as an operating platform for the iPhone. I was involved in building the first Linux-based smartphone, the Sharp Zaurus, and Linux has only expanded in embedded devices since then.

But Wired makes a good (and very funny) suggestion as to how Not-Invented-Here-Jobs must have reacted to the idea of Linux:

In fact, I like to imagine the scene: Fadell mentions the "L" word. Jobs' eye twitches, the flinch almost imperceptible. He motions Fadell to continue and, a few moments later, stands up casually, apparently to stretch his legs. Then, suddenly, a folding chair is in Jobs' hands, swinging wildly towards Fadell's corner of the room. Jobs smashes the entire presentation - hardware prototypes and all - and screams at Fadell to "Get the **** out. Get out now!"

Classic, and quite possibly true.

Just as Apple used BSD software at the heart of its OS X operating system, it could easily have used Linux. The difference, of course, is that while Linux would have provided the technical quality Apple sought, its licensing would have been a non-starter. With Linux (and its GPL license), Apple would have had to make its modifications/derivative works open source, which the liberal BSD license does not require.

I doubt the conversation ever would have moved beyond that point. Apple does contribute to various open-source communities, but the core "secret sauce" for one of its biggest products ever? Not going to happen.

Kevin Johnson, who has headed Microsoft's Windows empire, is leaving Redmond to take the helm of Juniper Networks, a leading network infrastructure vendor.

Johnson, the man who for years fought against open source, and particularly Linux. The man who talked about Linux forking back in 2005 and then who, as head of Microsoft's Windows unit, must have been involved in trying to foster that fork with Microsoft's patent deal with Novell. The same Johnson who, as head of the Windows business, had to have been involved in Microsoft's patent campaign against Linux.

Johnson, the man who now heads up a company deeply indebted to and entrenched with the open-source FreeBSD operating system at the heart of its Junos operating system, as well as Linux.

Yesterday: Open source, Johnson's enemy. Today: Open source, Johnson's friend. Oh, how sweet the irony!

From its Intrusion Detection Platform to the FreeBSD-based Junos, Juniper is in deep with open source. In Junos it has chosen an "open, but not open source" model that may play well to Johnson's Microsoft sensibilities.

Regardless of the model, it is delightful to see Johnson now dependent on the same "patent-infringing" open-source operating systems that he once fought. Who knows? Maybe Steve Ballmer will sue him?

Leave it to Linus Torvalds, founder of the Linux kernel, to speak his mind. While many point to Linux as superior to Windows as offering superior security, Torvalds doesn't want anyone to make a fetish of security, including the OpenBSD people to whom he addresses this classic missive:

...[O]ne reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior.

It makes "heroes" out of security people, as if the people who don't just fix normal bugs aren't as important.

... Read more

I recently spoke with Sigurd Magnusson, the intrepid chief marketing officer for Silverstripe, a New Zealand-based, open-source content management company. Silverstripe is a programming framework similar to Ruby on Rails, but for PHP5, allowing developers to quickly write website features using modern programming practices that are gaining popularity through Ruby and Python but not often used yet with PHP.

In a large crowd of open-source web publishing tools/content management systems, Silverstripe prides itself on an innovative and intuitive editing interface (and a prime slot in Google's Summer of Code last summer). It's also a finalist in Packtpub's CMS awards.

Silverstripe has an uphill battle, however, due to its location. New Zealand, home to hobbits and beautiful landscapes, is not the center of the software industry. Or any industry. It's simply not cost effective to hire a direct sales force in a country as spread out as New Zealand is, which leads to open source:

TIBCO just released its PageBus publish-and-subscribe message bus as open source. And no wonder: the company is under assault from open source projects/vendors like MuleSource (whose EVP of Sales used to work for TIBCO - funny these Oedipal complexes we have in the open source world :-), Talend, etc.

PageBus goes hand-in-hand with the OpenAjax Alliance work that TIBCO has done. It's a good start for TIBCO, though shows that it's still guarding its crown jewels. Give it time. In the meantime, here's what PageBus does: