When I first started writing software, my only understanding of the term ‘license’ was that it was something I needed to drive a car or to catch fish. As my career progressed, I learned that software also has licenses that describe – ideally - how the author of the software wants his or her creation to be used (terms, conditions, permissions, etc.). Of course, there are many types of software licenses today. You may not follow this topic that closely, but you certainly have seen things such as End User License Agreements – that little agreement you can choose to click ‘I Accept’ or ‘I Do Not Accept’ after you read in infinite detail all the terms, conditions and restrictions (right?). Early in my career, I typically just used a) whatever license the company I worked for used or b) whatever licenses other developers seemed to use. It was a combination of laziness, naïveté, and general indifference to all things legal. This perspective of course changed as I began to understand that licenses were indeed quite important and powerful in determining how I could control the thing that I wrote – or how I could lose control.
Thus began my entrée into the legal world of software licensing. I’m generally not one for bureaucracy or unnecessary complexity, so, to be frank, some software licenses seemed ridiculous to me. Many still do. But again, I’m not a lawyer (nor do I play one on TV) and I do have a high degree of respect for all my friends in this discipline, so I understand it’s not always as simple as one may desire it to be. That said, it doesn’t hurt to try to strive for simplicity. Programmers and IT professionals learn early on that the K.I.S.S. rule is the only true path to technical enlightenment, so I try to apply this same thinking to software licenses.
Licensing is a broad field, so I’m going to focus in on what we’re doing with our community software licenses. It’s worth noting that there is an important difference between binary and source licensing. The fact of the matter is binary licensing governs the vast majority of revenue-generating activities in commercial software. Source code licensing is about the use (and re-use) of the underlying intellectual property in terms of copyright, trademark, and patent. I’m focusing on what source licensing programs we are doing for our community projects.
Around a year ago, we rewrote our software licenses that we will use for many of our community programs in our Shared Source Initiative. If you’re not familiar with Shared Source, this is a program we have where we share source code with customers, partners, developers, academics, and governments worldwide. There is a variety of software we have in this program, such as wikis, Atlas/Ajax toolkits, IronPython (Python in .NET , click here for an interview with with IronPython Architect Jim Huginen ), drivers, installers, and so on. Jason Matusow announced these new community licenses on his blog last October.
There were four main goals for writing these new licenses:
- Short and easy to understand - The new licenses are typically shorter than a typewritten page and are easy to read and understand.
- Effective and modern - Although simple, the licenses are designed to be effective and to reflect modern best practices in source code licensing.
- Efficient - By using three simplified licenses, Microsoft will be able to streamline its own internal source code release process, which will allow for more rapid Microsoft source code releases.
- Ecosystem-friendly - Using three simple and well-understood licenses help to simplify source code sharing throughout Microsoft’s various software ecosystems, and help to avoid excessive license proliferation.
(To be clear, I was just a cheerleader and supporter of these efforts, smarter people than me did the actual work to meet these goals in each license .)
The result was something we were quite happy with. But it’s not just for Microsoft’s Shared Source projects – SugarCRM, the leading Open Source CRM solution, has chosen to use one of these new licenses, the Microsoft Community license. As John Roberts, CEO and founder of SugarCRM commented:
"We were really impressed by the Microsoft Shared Source Community License and like it a lot. We think it is a license that represents the ideals of our community and is one that they want to use, especially those customers who already run on the Windows platform.”
You can read more about this news here.
I’ll be blogging a lot more about Shared Source in the future. As this blog entry’s title suggests, I’m a Kubrick fan and although I’m not worried about fluoridation conspiracy theories, I did want to share a snapshot into how we think about community source licensing. Regardless if you write code, manage an IT environment, or just install applications on your desktop or server, understanding software licensing is an important aspect of the software world we live in. It is my hope that the future of software licensing gets simpler, more pragmatic, and more empowering for the world’s software authors.
And since I’m so lazy in writing my blogs, I now have to add in a bunch of post scripts…
P.S.: In the same theme, we have also recently announced some interesting work with Office, giving authors the option to create Creative Commons licensed work using a plug-in within Office. Creative Commons is a nonprofit organization that has written licenses that allow content creators to share information while retaining some rights. Creative Commons was founded by Larry Lessig, a Stanford Law Professor I've come to respect and read often – Larry blogs about this news here. We’ve worked with Creative Commons in the past, on a spec for RSS extensions and the PatternShare wiki site (using the Creative Commons Attribution-ShareAlike license and the Creative Commons Attribution license, respectively).
Stephen McGibbon's has a great blog about the Creative Commons Office plug-in here, with screenshots and commentary.
Speaking of Office, you may have caught the recent news about the new community project building an Open Document Format (ODF) converter for Word 2007 (up on SourceForge: http://sourceforge.net/projects/odf-converter). If you are a spectator in the Open XML vs. ODF debates (a very en vogue topic for Open Source pundits), I suggest reading Chris Capossela’s letter about the differences between Open XML and ODF. Chris is one of the key leaders of our Office organization and this letter helps clarify a lot of the FUD spread by Microsoft competitors around Open XML and ODF.
P.S.S: On licensing, CIO Magazine Technology Editor Christopher Lindquist just wrote an article on OSS licensing that is worth reading.