GPL defense issues

A friend sent me a link to this email from Linus Torvalds to the Kernel Summit Discussion mailing list.  The subject of the conversation is the General Public License (GPL) and whether or not it should be enforced in courts.  Read the whole thing – it’s quite interesting.  Here are a few snippets just to get you started:

Let’s be clear about this: lawsuits destroy. They don’t “protect”.

Lawsuits destroy community. They destroy trust. They would destroy all the goodwill we’ve built up over the years by being nice.

And then this:

Because lawsuits – and even threats of lawsuits – makes companies way less likely to see you as a good guy. Even when you’re threatening
somebody else, everybody else around the target starts getting really
really antsy.

I talked to an Oracle lawyer a few months ago, and told him their
lawsuit just makes Oracle look bad. The lawyer was dismissive, and
tried to explain how it’s silly how people take lawsuits personally,
and talked about how layers _understand_ that lawsuits aren’t
personal, and that they are still friends outside the court.

I’m sure a lawyer can “understand” how lawsuits aren’t actually
something personal at all, but lawyers really seem to be the *only*
people who “understand” that.

The fact is, lawsuits (and threats of lawsuits) do not make for
friends. You just look like a bully.

How Google Uses and Contributes to Open Source

Here is a good Open Source story – “How Google Uses and Contributes to Open Source“, which goes into some detail and history of how Google is working with Open Source community.

I’ve seen this before:

“There are companies and people who just take the software and say, “I didn’t have to pay for it. I can do anything I want. The license file is a big blob of text. I’m not going to read that,” Merlin said.

And I’ve this (quite a few times actually):

Back in its early days, around 1998, Google was a small company. It was using open source just like any other small company. While Google was abiding by licences, they were not giving back much due to several reasons. “Some of it was just run fast and make sure that we have money next month to pay everyone’s salary,” said Merlin.

Having been involved in open sourcing companies’ projects new and old, this is what I firmly believe now is the best strategy:

Go open source from the beginning

Google changed that by writing a lot of things from the ground up as open source or to be open source ready. That was a good lesson that they learned, and that’s a problem many companies face when they want to open source their stuff but can’t because the code was not designed to be open source from the beginning.

This, I think, is an interesting approach too (if  you are too small of a company to have research papers and algorithms, consider blog posts, tips and tweaks, case studies, and the like):

Even if Google can’t open source certain code, they found a way to bring that work to the public. “We wrote papers talking about the magic algorithm that we used. We can’t give you the code for the reason I just explained, but we’re giving you the way they work so you can rewrite them,” said Merlin. Google has published hundreds of such papers and people are using it to create projects based on those ideas.

This bit on Android is mind blowing:

Now virtually all of Google’s open source code is on GitHub, except for Android. “The Android distribution is so big and it gets released in big chunks. So, when it gets released, everyone wants to sync that,” Merlin said. “It’s so huge that if we put it on GitHub, it would completely kill GitHub. We use our own mirrors for that, to help out.”

A word of caution for the companies using Open Source software:

Companies have to be extremely careful when using open source. Different projects use different licenses, and you need to be in compliance with them.

[…]

Things become complicated when you have projects that you ship. In the case of open source, you need to list the projects that you use and their licenses. In the case of BSD and MIT, you need to list the name and the copyright of the person you got that project from.

You’ll probably need a set of tools to deal with issues like this.  For PHP-based projects, composer is indispensable.  You can run “composer licenses” command and instantly get information about the project’s license, as well as licenses for each and every dependency in use (thanks to this blog post).

There is a good section on Contributor License Agreements (CLAs).  I am slightly familiar with the subject (I signed a few myself), but my experience is limited, especially from the company perspective.  I found this part useful, for that distant time when I’ll need to set it up:

Google uses the Apache foundation ICLA, without modifying it or putting anything special in it. CLAs ensure that companies like Google “can re-license your code under a different open source (license) if we need to. Sometimes we need to merge with other projects and that’s what the CLA allows us to do,” said Merlin.

These are just bits and pieces which I found interesting.  I wish more companies shared their practices and experiences – in particular those larger businesses, with years of history and a wide variety of challenges.

I’m not inclined to make grand pronouncements abou…

I’m not inclined to make grand pronouncements about the future of software, but if anything kills off commercial software, let me tell you, it won’t be open source software. They needn’t bother. Commercial software will gleefully strangle itself to death on its own licensing terms.

Jeff Atwood