ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
back

Dual licensing the only way to go?

Matt Asay proposes the following definition to the answer what consititudes an "open source company" that I blogged about yesterday: "An open source company is one that, as its core revenue-generating business, actively produces, distributes, and sells (or sells services around) software under an OSI-approved license."

I see a lot of merit in this definition. However it does shut out companies like EnterpriseDB that do proprietary extensions while feeding a lot of code back to the open source parent. Of course you can point to the fact that the product they sell is not open source.

This however is the only code based business model around BSD projects. Without picking favorites, I personally do appreciate the fact that BSD style projects produce an ecosystem that is much more open on the code development end. I do think that MySQL contributors program is a nice touch, but do note that even with it, MySQL still requires that contributions are licensed to MySQL in a way to allow their very important closed source licensing business model.

As such I do not think it is wise to frame the definition of "open source companies" in such a way that dual licensing starts to look like the only viable business model for code producing companies in the open source scene. Especially since dual licensing companies, as proven by Sleepycat and InnoDB, can just as quickly be acquired by closed source companies. While on the surface nothing has changed for these two companies, I can tell you that it did change their community interaction. Just try to get an interview with someone else than Heikki or Michael from these two companies .. most of them now run around with a gag (ok I am venturing in polemic language here, but I got bitten by it personally while researching my thesis) when it comes to talking about open source.

I therefore still stand by the definition I proposed yesterday:
"a company whose business model depends on being in good standing with an active open source community"

Comments



Re: Dual licensing the only way to go?

"Whose", not "who's". Also, "Heikki", with 2 k's. HTH!

Re: Dual licensing the only way to go?

Thanks, spelling corrected.

Re: Dual licensing the only way to go?

I don't really see a distinction between MySQL and EnterpriseDB as far as business models go. Both companies foster open source communities as a resource to leverage when selling thier propietary products. Granted MySQL's proprietary solution more closely resembles it's open source counterpart, but in the end they are different products with different release processes. (Think CMD and it's Mammoth PostgreSQL offering for something more analagous if you'd like).

The other question is what do you mean by code producing companies? PostgreSQL accepts code contributions from a number of sources including companies like EDB, but also companies like Red Hat which uses it as part of thier supported application stack, and companies like Skype which use it as a part of the core service offering, and companies like OmniTI which is a consulting/services company that happens to support PostgreSQL, not to mention code from at-large hackers with unknown ties to the project. That means that for a BSD project at least, there are a whole range of business models you can use to make money that involve producing code for open source projects.

Re: Dual licensing the only way to go?

"a company whose business model depends on being in good standing with an active open source community" is a tad too broad in my opinion. It would also include companies such as IBM and Intel. The contributions of these two companies to open source is certainly not to be sneezed at, but it doesn't make them open source companies by any stretch.

Re: Dual licensing the only way to go?

I don't think you can really say that IBM or Intel are dependent on this. Maybe some small business units within IBM and Intel are. But nobody would expect either of these companies to disappear if they pull a stunt like SCO. I would not even say that IBM or Intel have a particularly "good standing" in the community in general.

Re: Dual licensing the only way to go?

I still think we are focusing on the wrong part of things, in general. Why do we care if EDB calls itself an 'open source company'? That's just branding that only matters to those companies/people who are interested in differentiating their companies from the proprietary pack.

Instead (IMHO) the correct course of action is to brand the products themselves, which has to some degree been done with the advent of OSI approved licenses. The proprietary software that EDB releases will never pass the definition for open source. If customers license and use this software, they are not using open source software <i>regardless of whether we call EDB an 'open source company' or not</i>. The same would go for SugarCRM, Zimbra, and the other 'boundary cases' that exist.

In the end, it is insignificant whether or not customers use proprietary or OS software to solve their problems, nor does it matter what we call the company who services the software. What matters is that they understand the complete ramifications of the license associated with each individual piece of software itself.

Re: Dual licensing the only way to go?

Well the reason why it matters if EDB is an "open source company" or not was started by the question of what companies should be allowed to present at OSCON. This highlights the question at hand .. the idea here is by determining what we as the OSS community define has companies that are part of our community, we determine how we allow them to participate at exclusive events and other things we control.

We have the ability to seriously affect what kind of business models can be build on top of open source software. That is if we decide that we do not like EDB's business model, we can make their life that much harder. Alternatively we can decide if we like their business model and thereby make life easier for them.