software licensing

InfoWorld has an interesting story on GPL’s decline (might be a strong word) in favor of some more permissive licenses, notably Apache, MIT, and BSD. I think this part hits the main deciding factor:

Originally associated with variants of Unix, these “permissive” licenses took their names from the universities at Berkeley and Massachusetts: the BSD and MIT licenses. These licenses allow you to do almost anything with the associated software, including making it closed, proprietary software to which the four freedoms no longer apply. This is also a source of controversy, as some people consider it wrong to take open source software and prevent others in the future from using, studying, modifying, and distributing it.

Many corporations out of licensing concerns forbid GPL, rational or not. In my experience if you want to keep your project open to as many enterprise and corporate uses as possible, BSD, MIT or Apache is your best bet. I don’t think many these days still forbid all open source. Some still forbid GPL. They will use GPL licensed software, just not the code.

Deciding what license you pick is an important part of any software project.

So Microsoft will open up with information on many protocols/formats, and provide a “covenant” not to sue open source developers. Note the exception. Microsoft reserves the right to sue companies who commercially distribute such implementations. They need to get a license. As Microsoft put it in their principles:

Open Source Compatibility. Microsoft will covenant not to sue open source developers for development and non-commercial distribution of implementations of these Open Protocols.

As far as everyones reaction to this, Arstechnica wins with the best quote:

“Instead of offering a patent license for its protocol information on the basis of licensing arrangements it knows are incompatible with the GPL—the world’s most widely used open source software license.”

It may settle some curiosity in regards to how close certain reverse engineered implementations are to the actual protocol, but beyond that I don’t think it will make any difference. I think this caveat would limit most projects ability to utilize the information. I don’t think any major project is willing to utilize code subject to that limitation.

For example I mentioned just the other day that Exchange compatibility would bring about the most corporate adoption to Mozilla Thunderbird. Well this could potentially help make that a reality, except Mozilla’s commercial arm would be subject to trouble come release time. Not to mention any downstream commercial distribution that includes it (including many Linux distributions) unless they include a version without this code.

It may however be possible for a company to sell a product and offer a GPL licensed open source “plugin” or “addon” that adds the functionality. So for example Thunderbird would ship as usual via Mozilla Messaging and various Linux distributions. If you wanted exchange compatibility you would need to go to mozilla.org and download the addon for it. Similar to the current process for the provider for Google Calendar. However this adds a nasty extra step for users. It’s far from ideal.

The other notable thing in my mind is this part of their principles:

Industry Standard Formats. Microsoft supports many data formats promulgated by standards bodies in its products today. We will apply Principle II with respect to any standards-based data formats in our high-volume products. We will incorporate customer advice from our Interoperability Executive Customer Council and our ongoing community and customer engagement efforts to give us guidance to prioritize which standards we support in any given product release.

We want OpenDocument.

So despite all the media attention, I don’t think open source gained much today. There’s potential (OpenDocument getting priority would be nice), but really no big win. I just don’t see projects giving up GPL, and I’m pretty sure this agreement would violate GPL.