Last week Eben Moglen, founder and executive director of the Software Freedom Law Center (SFLC), submitted an independent opinion on the Oracle/Sun merger to the European Union (EU). Moglen summarized his submission as follows:

“The GPL was designed specifically to ensure the permanent freedom of software, and the ability of everyone to improve and share their improvements to the program, no matter who acquires the copyrights to the code.  The whole point of GPL as a copyright license is to deal with every contingency that could result in hobbling or destroying the freedom of code shared under it. The drafters of GPL versions 2 and 3 considered scenarios very similar to the ones that the Commission is concerned about now. The design of the license, and the experience we have had using it, show that it can be counted upon to operate as intended in situations like this one.”

Moglen issued the 11 page opinion, pro bono and without the charge, at the request of Oracle’s counsel.  Moglen clarified that Oracle is an ongoing contributor to the SFLC, while Monty Widenius has contributed in the past.  However, neither the contributions from Oracle nor Widenius have exceeded 5 percent of SFLC’s funding since inception.

I found the following paragraph from Moglen’s submission particularly interesting:

“MySQL is now and always has been an atypical GPL software project, because its copyright was highly centralized inside a small commercial firm that considered dual licensing its only commercially attractive strategy for survival. But even MySQL AB’s atypical business model, which was highly unreflective of the mass of GPL’d software development, occurred within the parameters of the GPL’s overall design, which is to ensure the freedom of the software it protects regardless of the commercial motivations or behaviors of the parties distributing the primary upstream version.”

On the other end of the debate, Florian Mueller announced that he has submitted a 31 page rebuttal to Moglen’s position.  Mueller provided a summary of the highlights via email, from which I selected these comments:

“Fundamentally, his paper offers a different prediction as to what would happen post-acquisition. He simply expresses his firm belief that whatever made MySQL successful in the past is not really an indication for the future. In fact he believes MySQL AB had a very suboptimal business model…

If he were right that MySQL AB and all of the companies that succeeded around MySQL didn’t do it right and that a GPL-only approach works best, then actually there would be no point in Sun having acquired MySQL last year nor in Oracle acquiring it now because then the future would at any rate be that someone has to fork it and do a GPL-only project dependent on voluntary contributions. Interestingly, that approach would have been possible during all of those almost 14 years that MySQL has been available and no one, not even Eben Moglen, decided to seize that opportunity.”

Both Moglen and Mueller make strong and weak points.

First, Moglen is too quick to dismiss MySQL as an atypical GPL project.  As Mueller points out, whatever you think about MySQL and their business model, you can’t simply conclude that another business model would be more appropriate.  Just because Linux is licensed under the GPL and Linux vendors, namely Red Hat and Novell are closing in on a combined $1B in revenue, does not mean the GPL is the best license for every open source product with commercial aspirations.  The Linux ecosystem is very different than say, application servers or web content management.  Different markets with different ecosystems require different license considerations.

While Moglen appears to be arguing for a “pure GPL” MySQL, departing from the dual-licensed status quo, Groklaw reports that Mueller and Widenius would like to see the MySQL open source license changed from GPLv2 to the Apache Software License.  According to Groklaw, page 19 of an unreleased submission to the EU from Mueller/Widenius stated:

“We would like to draw attention to the fact that some major concerns about the effects of the proposed transaction could be somewhat alleviated by requiring that all versions of MySQL source code previously released under the GPLv2 license …must be released under a more liberal open source license that is usable also by the OEM users and would also create an opportunity for other service vendors to compete with offerings comparable to MySQL Enterprise. A good candidate is the Apache Software License (ASL).”

Something doesn’t feel right about Widenius proposing a license that MySQL could have chosen “over the past 14 years”.  Clearly MySQL decided against this move as the GPL/dual licensing approach led to a competitive advantage that the ASL v2.0 would not provide MySQL.  But I guess that’s why Widenius suggests Oracle should be forced to re-license MySQL under a permissive license such as the ASL v2.0.

We haven’t heard the last from Widenius & Mueller. Enjoy your holiday season ;-)

Follow me on twitter at: SavioRodrigues

PS: I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.”

I don’t want to get into whether or not Microsoft violated the GPL with their Windows 7 USB/DVD Download Tool. That’s already been covered in depth.  I do however want to ask how a situation like this could have even happened, and how it could be prevented.  Not just at Microsoft, but at a typical enterprise that sells products or services which include software.  Enterprises that fall into this category are increasing in number daily and will accelerate as enterprises start building mobile device applications.  Air Canada and Domino’s are early examples of the enterprises that I’m referring to.

We’ve previously discussed the notion of using open source to compliment a development budget. This is true for enterprises and software vendors alike.  As Black Duck Software’s Eran Strod writes:

“There is an abundance of great open source code available that includes components like libraries, stacks, databases, frameworks, etc; it simply doesn’t make economic sense to allocate development resources to build what Savio calls ‘undifferentiated capability’. Why spend money, and time, reinventing the wheel?”

As enterprises start to use open source within products that will be released externally, the need for an open source usage policy becomes critical.  This effort begins with developer education.  It’s helpful to have a set of guidelines with approved licenses and open source projects that developers can potentially build from.  But that’s not enough.  Enterprises need to verify the pedigree of code checked into each build, to the degree possible.  Companies like Black Duck Software and Protecode offer services to help enterprises using open source in their development process.

What surprises me about the Microsoft situation is that I’d be shocked if Microsoft doesn’t have an open source usage policy. Microsoft uses open source in some areas of Windows.  So, it’s possible that a developer just made an honest mistake.  However, that really isn’t a viable excuse, not for a software vendor and not for an enterprise in the future.  The need for education and vigilance is an endless task.

We’ve all seen the news about the waning use of the GPL open source license. It’s also becoming clear that a handful of OSI approved licenses are going to win out over the sixty-plus OSI approved open source licenses.  Which licenses are winning, why, and which license should you use for your open source project?  Great questions.  Go ahead and ask them here.  They’ll get answered by three open source luminaries on August 31st.

The Free and Open Source Software Learning Centre (FOSSLC) has arranged a live debate (in Ottawa and on free webcast) to discuss the GPL, the Eclipse Public License (EPL) and the BSD license.

Alfresco’s Matt Asay will be defending the GPL.  The Eclipse Foundation’s Executive Director and Mike Milinkovich will be backing the EPL.  Finally, Coverity’s Open Source strategist and BSD board of director will be representing the BSD.

Go ahead and submit your questions before the event attend virtually or in person if you’re in Ottawa, Canada.

My pragmatic nature says that the smackdown will end in a three-way tie.  Deciding between the GPL, EPL, BSD or other open source license should be a result of which license best helps attain your business goals.  It’s also important to consider the ecosystem around your product.  For instance, it’s no coincidence that the latest incarnation of the JBoss messaging project uses the Apache license, not the LGPL which most other JBoss projects use.  The project team felt that the Apache license would ensure that the project’s code could be more easily included into products from the ecosystem. Being pragmatic, it’s not just for Canadians anymore.

It’s always good when respected open source luminaries such as Matt Asay begin to question long held open source software truths.  Matt wonders whether the GNU General Public License is “an alternative way to release proprietary software?”  Matt argues:

“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 (GPL & the Apache Software License). 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.”

Matt uses Eric Raymond’s post titled “The Economic Case Against the GPL” to bolster his evolving view that the Apache Software License (ASL) is a more effective license for the future of open source than the GPL.

Before writing off the GPL in the long run, there are three situations to consider.  They all deal with the viability of the open source vendor considering the GPL vs. ASL.

1. Does the GPL license encourage customers to purchase a license more so than the ASL would?

2. Does the GPL license encourage partners and/or OEMs to purchase a license more so than the ASL would?

3. Does the GPL protect the open source vendor’s IP against a (larger) competitor more so than the ASL would?

1. Customers:
I was going to argue that the GPL encourages customers to pay for the software more so than the ASL does.  But that’s false, and if it isn’t today, it will be in 5 years.  There was a time when inside counsel would recommend their companies stay away from using GPL software for fear of the GPL’s viral nature.  Today, customers understand that the viral nature of the GPL is only applied if the GPL software is modified and distributed outside of the company’s walls.  The overwhelming majority of enterprises and business using open source products do not satisfy both of these requirements.  As a result, there is nothing inherent about the GPL that would drive higher open source vendor revenue than if the ASL was used.

2. Partners & OEMs:
Some ISVs, SIs and device manufacturers may want to use open source software within their final product without having to open source the product’s software.  In this situation, the GPL in conjunction with a commercial license will result in higher open source vendor revenue than the ASL in conjunction with a commercial license.

It is interesting that device manufacturers such as Cisco and Western Digital are using GNU/Linux in their products and are opting to open source their software versus paying a license fee and keep their software private.  I believe that device manufacturers are going to increasingly open up their software in ways that encourage the interested/skilled user base to tinker. So from a device manufacturer standpoint, I’d argue that there is little OSS vendor revenue difference in using the GPL vs. ASL.

Next, let’s consider ISVs and SIs.  On one hand you could argue that since software is going to be increasingly delivered through the mythical cloud, the GPL’s role as a stick to encourage a license purchase will diminish.  But I don’t believe that the enterprise world is moving to SaaS as fast as they hype would suggest.  For years, if not decades to come, the vast majority of ISV and SI delivered applications will be distributed to enterprises and installed on corporate servers as they are today.  As such, the GPL’s role in driving open source vendor revenue from ISVs and SIs will remain an important reason to select the GPL.

3. Hostile Competitors:
The final reason to use the GPL over the ASL is that the GPL provides better protection against competitors, especially larger ones, using the OSS code to compete with the open source vendor in question.  However, I could quote examples of GPL and ASL licensed open source products that have been forked to varying degrees by larger competitors.  In the two situations that come to mind, it can easily be argued that the forks have been unsuccessful.  The open source vendor’s brand has proved to be a more realistic barrier to entry than the license was thought to be.

I can think of only one business reason that an open source vendor would select the GPL over the ASL; namely, the revenue opportunity from ISVs and SIs who would rather pay for a commercial license than have to open source their own applications.

What do you think?

Follow me on twitter at: SavioRodrigues

PS: I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.”

Very cool news that a group of independent film makers (with programming skills) have developed a firmware update to the Canon 5D Mark II digital SLR.  According to the team:

“…the software in video mode has limitations, even after the recent 1.1.0 upgrade from Canon that fixed the most glaring manual exposure “bug”.

That’s where Magic Lantern comes in — it turns your 5D Mark II into a 5D Mark Free. We’ve written extensions and widgets that fix many of the annoyances in working with the 5D Mark II on a film or video set. Our first set of fixes are targeted at the audio limitations of the camera, but there are some video enhancements included, too:

* On-screen audio meters
* Disabled AGC
* Manual gain control
* Zebra stripes (video peaking)
* Crop marks for 16:9, 2.35:1 and 4:3″

They’ve released the Magic Lantern firmware under the GPL and are seeking donations, programmers with ARM assembly or embedded systems skills and folks who don’t mind risking their expensive 5D Mark II cameras!

Reading the 5D-II forum, the response has been quite positive.  I’m not a lawyer, but the EULA seems to have terms and conditions that restrict the work done by the Magic Lantern team.  This begs the question, what should Canon do about, or as a result of, Magic Lantern?

Canon could open source its firmware and encourage community contributions. The thinking follows that Canon’s hardware (CMOS, lenses) is a whole lot more valuable than its software.  While competitors could potentially reuse Canon’s open source software firmware, these competitors would not be able to match Canon’s hardware R&D and manufacturing processes.  And in most cases, the firmware is pretty hardware specific to Canon.  Or one could argue that Canon’s software is very important to its value proposition, but that opening up to an open community of developers will help Canon innovate faster than it could using its internal resources only.  On the flip side, Canon’s camera product portfolio would be disrupted if a programmer was able to add some firmware-based capability to a lower end model that is only officially offered in a higher end model.  But even here, one could argue that the vast majority of Canon users will only install the official Canon firmware which would not have to include features that Canon didn’t wish to add to a given product level. On the other hand, wouldn’t these folks be the exact users that Canon wants to upsell to the higher end model?

I could, and have, gone back and forth on this one.  What about you?

Follow me on twitter at: SavioRodrigues

I started to consider the reasons why open source vendors select the GPL after ESR wrote:

“The GPL may be a community-building signaling device, but it is also a confession of fear and weakness. To believe that it matters, you have to believe that you live in a Type A universe where closed-source development is such an attractive proposition that you have to punish people for trying to move to it.”

The first reason has to be the big-bad Elder Companies.  It’s no surprise that Elder Companies prefer more permissive licenses such as the Apache license.  OSS startups fearing that their work will be hijacked by a larger vendor tend to select the GPL as a result. The validity of this fear has been called into question by the success of Oracle’s Unbreakable Linux.  Or imagine if MySQL had used the Apache license.  Would Oracle, Microsoft or IBM (or others) have been able to use MySQL’s IP to compete against MySQL?  Well, in theory yes.  In practice, just imagine the community uproar against an Elder Company that tried to fork MySQL.  Using the GPL for fear of Elder Companies is unfounded.

The second reason to use the GPL is to encourage customers and partners to pay for the open source software in question. Let’s only consider the situations where the customer or partner is seeking not to pay for the OSS.

Does the GPL encourage payment from a customer any more than the Apache license? I’d argue no. Very few customers create applications that are distributed outside of their walls.  Hence, there is no trigger for the viral nature of the GPL. A customer could equally choose to use GPL or Apache licensed software without paying the OSS vendor.

Does the GPL encourage payment from a partner any more than the Apache license?  In this case, yes.  The partner must choose to pay for a commercial, non-GPL, license or choose to license their own product under an open source license.  Since the latter is not the preferred route for ISVs/SIs, especially regional ISVs & SIs, the GPL does encourage payment more so than the Apache license would.  But there’s a catch.  The GPL would force this partner (that doesn’t want to pay or open source its product) to look at non-GPL alternatives.  When this occurs, the OSS vendor has lost a partner and end-customers delivered through this partner “forever” (as long as that is in the IT market).

The third reason is that the OSS vendor intends to leverage code from third party GPL projects.  Considering the amount of GPL projects out there today, this is a pretty strong reason for startup OSS vendors to select the GPL.

For me, reason #3 is, at this stage in the maturity of open source, the reason that the GPL will retain it’s dominance in the industry.  For better or for worse.

Follow me on twitter at: SavioRodrigues