As reported yesterday from CommunityOne:

• MySQL Server is and will always remain fully functional and open source,
• so will the MySQL Connectors, and
• so will the main storage engines we ship.

In addition:

• MySQL 6.0’s pending backup functionality will be open source,
• the MyISAM driver for MySQL Backup will be open source, and
• the encryption and compression backup features will be open source,

where the last item is a change of direction from what we were considering before.

The change comes from MySQL now being part of Sun Microsystems. Our initial plans were made for a company considering an IPO, but made less sense in the context of Sun, a large company with a whole family of complementary open source software and hardware products.

I’d like to shed some light on the big picture, in two different ways — openness, and the business model.

MySQL’s openness manifests itself in three ways:

• MySQL’s code is open.
• MySQL’s APIs are open.
• MySQL’s data formats are open.

These form a foundation around the MySQL Server and its connectors on which we (Sun), our partners, and the community can all freely build upon. And through this openness, we will always provide a means for our users to easily export their data from MySQL.

Then for MySQL’s business model. To financially support MySQL’s free and open source platform, we have a business model which allows both community and commercial add-ons, and we remain committed to it. We believe the model to be useful for both those who spend money to save time, and those who spend time to save money.

As Mårten mentioned yesterday in the CommunityOne panel, expect Sun/MySQL to continue experimenting with the business model, and with what’s offered for the community and what’s offered commercial-only. We won’t always know the right answer from the beginning, but we want MySQL to be the most popular database for both paying and non-paying users.

With 130 entries in the “MySQL” category and no MySQL-related subcategories, my blog had become impossible to search and navigate easily.

And thus I created a number of new categories for the MySQL entries within my blog. They’re listed in the left navigation bar, below the months, as well as below:

• MySQL Server, MySQL Cluster, Falcon
• Connectors: PHP, Ruby on Rails
• Tools: GUI, MySQL Workbench, MySQL Proxy
• Events: MySQL Users Conferences
• Licensing: GPL
• Architecture of Participation, Summer of Code, Virtual company
• Other: Release Policy, Documentation, Use cases

I hope this will make my blog more (re)usable.

(The picture is from this summer, when navigating the way up the Großvenediger, a 3662 m high mountain in the Hohe Tauern region of Austria.)

We congratulate the Free Software Foundation on the release of GPLv3 and offer our thanks to the many individuals in the open source community who participated in the process of drafting the license.

It’s good to see overall improvements in GPLv3 over GPLv2, when it comes to compatibility with other Free/Open Source Software licenses, to the compatibility with other legislations than the US legal system, and to strengthened incompatibility with Software Patents. I am also happy if the work of the Committee B ends up contributing to a better adoption of GPLv3. I am in awe as to the patience and skillful diplomacy with which Eben Moglen could tame the group consisting of everything from techies from comparatively small companies (like Trolltech and ourselves) to the seniormost lawyers from the biggest Fortune 500 companies.

MySQL will continue to monitor the industry’s reaction and adoption of the new license, as we decide the best overall course for our community, our company, our users and our customers.

MySQL is indebted to the Software Freedom Law Center for very good advice and insight on how to combine Free Software with a viable business model. SFLC provides legal representation and other law-related services to protect and advance Free and Open Source Software. Founded in 2005, the Center now represents many of the most important and well-established free software and open source projects.

Professor Eben Moglen, SFLC director and FSF legal counsel, has provided us with profound guidance over the years. We have tried to give something back through our work in the GPLv3 Committee B, but our time resources as a small company are limited in comparison to our fellow committee members.

In recognition of Eben’s help and as a token of our appreciation, we’ve made a small donation to support the continued work of the SFLC. We encourage others who build their business on free software to do the same.

Thank you, Eben!

Today, FSF released the third GPLv3 draft on http://gplv3.fsf.org/gpl3-dd3-guide . It’s great that the entire, complex process now has completed its next milestone, and I can fully understand why the FSF has seen it necessary to proceed at a pace somewhat slower than originally intended.

My thoughts go back well over a year to the Free Software Foundation’s first conference on GPLv3, at the end of January 2006. It was a great meeting, and as a Committee B member and representative of MySQL, I was asked by China Martens of IDG for my input. My reply “I think there was a good balance between different hair and beard lengths” ended up on China’s compilation “2006: The IT year in quotes” as “a colourful description of the cross-section of attendees”.

I wish I had something equivalently colourful to describe the third draft of GPLv3. “A good balance between FSF’s interest to protect software freedom in the name of the end user, and the interests of the industry to develop sustainable business models upon Free Software“? I hope I will feel able to use that for the final GPLv3 one day.

For now, MySQL continues to be actively engaged in the Free Software Foundation’s GPLv3 drafting process, the next step of which is the upcoming 60 days that should end up in a final draft. Our flagship product, the MySQL database server, remains licensed under GPLv2.

Until the new version of GPL is finalised, we won’t be in a position to determine whether GPLv3 is an appropriate license for MySQL products. As I said at the end of last year in my blog, until we get clear and strong indications for the general acceptance of GPLv3 over GPLv2, we feel comfortable with a specific GPLv2 reference in our license. So while we support and care for the GPLv3 process, don’t expect us to be amongst the first GPLv3 movers.

By the way, don’t miss Eben Moglen’s keynote at the MySQL Conference & Expo 23-26 April 2007 in Santa Clara, California! Eben is not only a brilliant mind and shaper of the future, but one of the best public speakers I have ever heard.

In his well-written blog entry Open Development: Diversity matters, Gianugo Rabellino quickly replied to my blog entry from yesterday on Defining “Participatory Open Source”. He sees plenty of common ground in our reasoning, but defends the existence of requirements for neutrality in the definition. I agree with nearly all of his reasoning for why neutrality is important for the development of a community of contributors, but I draw partially different conclusions.

The main reason why my conclusions are different from Gianugo’s is the starting point for my reasoning: There is no inherent conflict of interest between participatory open source and pursuing for-profit business goals, so we must not create artificial obstacles for business wanting to develop Open Source software building upon an Architecture of Participation. Now, I can hear Gianugo objecting “But my entire blog entry and reasoning about why we need an impartial body and non-discrimination was about documenting the very existence of that inherent confict of interest”. Well, read on, and let me start by underlining where I agree with Gianugo.

First, I agree with Gianugo in that he has identified the right passage in my previous blog where our reasoning differs:

The interesting middle ground is whether it’s OK to say “no” or “maybe later” to technically sound contributions that don’t fit with the business interest of the owner of the main code base. I would argue that such “discrimination” is OK, as the “Participatory Open Source” requirements would otherwise impose so severe purity limitations, as not to be interesting for companies with a commercial agenda, like MySQL AB.

He argues that this documents that MySQL doesn’t have a neutral point of view when accepting code contributions, and I agree this is coherent with the rest of his reasoning.

Second, I agree with Gianugo in that turning down a contribution for no good reason is an excellent way of demotivating a contributor. If I know my contribution is technically highly merited, usable for many, and thus expect it to be included as part of the body code, I will get very upset if it is rejected for apparently no good reason. I won’t contribute again, and I will share my anger not just with my friends, but with the general public. Others will likely also be discouraged from contributing. This undermines the Architecture of Participation, and any good community vibrations will asymptotically approach zero degrees Kelvin.

While this seems as total agreement between Gianugo and Kaj, how can we then arrive at different conclusions?

Let me describe a scenario where I think it should be legitimate for MySQL to reject a technically valid contribution on commercial grounds, and why I don’t see it as an inhibitor for creating a vibrant community. I can even make the case fairly generic.

Basic assumption: MySQL has created a for-money-only, commercial offering, which constitutes a compelling reason for some customers to buy something from MySQL AB. This offering is of interest to MySQL users and differentiates our free offering from our business offering. It is the “something more” you get for entering a business relationship with MySQL, where you spend money to save time, instead of spending time to save money. The fact that our revenues are greater than zero is proof that there must be some offering from MySQL that our customers consider meaningful on top of what we offer at no cost to our community. Not all of these revenues are services billed by the hour of MySQL employee time spent. Some services are even based upon the delivery of software, such as the MySQL Network Monitoring and Advisory Service. Let’s use the term “the little difference” for what MySQL offers the paying customers beyond what we offer the community of users who use MySQL at no cost.

Now, should you have a contribution that renders the little difference useless, don’t expect MySQL to be happy about adopting it.

If Gianugo now says, “See, Kaj, that’s my point. If there is not a neutral body governing contributions, then progress is hampered by self-interest. So there cannot be true Open Development, and there won’t be a vibrant community.“, then I disagree at least with the second part of his reasoning, and my ambition is for MySQL AB through its deeds to prove beyond doubt that one can create an Architecture of Participation around Open Source software, while pursuing for-profit interest, even preparing for an IPO. I MySQL can fulfil the ten requirements I listed yesterday

1. software released under an Open Source license;
2. well-defined public guidelines for how to participate in the development process;
3. a publicly available detailed list of bugs;
4. a public roadmap with detailed descriptions of planned tasks;
5. code reviews accessible for the public;
6. public code acceptance criteria;
7. active public instant messaging between the developers;
8. well-maintained public system documentation;
9. a publicly documented mentoring system for grooming new developers;
10. a worldwide geographic spread of the developers;

then I think we will have created a vibrant community of contributing developers.

So what happened with the upset contributor mentioned earlier, whose well-merited contribution was turned down because it undermines our business offering, and who told all of his friends about his negative experience, and who blogged for everyone to see about why he won’t ever contribute again, and loudly proclaims nobody else should, either? Well, I think that won’t happen, and I’ve actually already communicated why, in the little sentence “Now, should you have a contribution that renders the little difference useless, don’t expect MySQL to be happy about adopting it.”

While most of the interests of the community of MySQL users are very well aligned with those of MySQL AB the company, there is a small subset which is not. Expect us to happily adopt nearly any technically merited contributions that make MySQL more powerful, easy and efficient to use. Don’t expect us to adopt contributions that eliminate or fully undermine the compelling reason to buy our commercial offering.

The virtual Gianugo sitting opposite me now objects: “So why would I as a contributor know, or even be interested in, what you consider to be your business interest, and what will undermine it?“. I hear him, I understand his question, I think it is a valid one, and I even have an answer. You don’t know our business interest. You would merely need to accept that there is a legitimate interest for MySQL to earn money on something, and the rest is taken care of by the contribution process itself. That contribution process has feedback loops between contributors and MySQL to give answers to contributors to the question “Is MySQL interested in adopting my contribution?“, before so much time is spent by the contributor that the answer “I’m sorry, no” will render him or her furious. Remember, the virtual Gianugo sitting opposite me accepts that there are technical reasons why we might see us forced to answer “I’m sorry, we cannot enter your contribution into the code base at this point in time.” — the code might not conform to our coding standards, it might be in conflict with another feature we’re just inserting, it might make MySQL too slow, it might not work with Replication, etc. etc. And if I, as a contributor, have spent huge amounts of time on a contribution, expecting it to be accepted into the codebase, I will indeed be furious, no matter what the reason for non-acceptance is. If I have an idea for a contribution that is deemed unacceptable by MySQL AB for commercial reasons, but it’s turned down by MySQL while I haven’t still spent loads of time on it in the belief that MySQL will adopt it, I will be disappointed, but I’m not going to lead a rebellion.

So this is why the yet-to-be-published acceptance criteria for code patches (item 6 in my ten requirements) will also include commercial aspects. This is why the “well-defined public guidelines for how to participate in the development process” (item 2 in my ten requirements) will state that there must be frequent enough feedback loops between the contributor and the non-neutral body managing MySQL, i.e. MySQL AB, to ensure that a contribution being developed is on track towards acecptance in the code, on both technical and business grounds.

My firm belief is thus that the Architecture of Participation is compatible with commercial interests. Non-neutral owners of Open Source code bases who strive for profit can, legitimately and without a bad conscience, exclude certain contributions on commercial grounds. And they can still establish vibrant contributing communities, by not setting false expectations. I think there is a sufficient number of developers who are willing to contribute code to such projects, because of the many common interests, including the expansion of the world of Free Software.

The Open Source thinker and BSD advocate Gianugo Rabellino just made me aware of a year-old blog entry by Susan Wu in Planet Apache on “Should OSI redefine the label Open Source?”. As I read the entry, it proposes a term “Open Development” and lists these “first stab” requirements:

1. an Open Source license, of course;
2. a non-discriminatory access to the developer’s community;
3. a well-defined and stated process for people to get involved;
4. a neutral and self-elected governing body;
5. (more difficult, could mean having a preferential lane) a neutral party such as a foundation owning the code.

I think Gianugo and Susan are pursuing a worthy cause in defining a software development model that doesn’t just release software based on an Open Source license, but also builds upon an architecture of participation. However, for reasons I don’t understand, they have included requirements that practically exclude companies like MySQL AB from ever fulfilling them. I am referring to requirements 4 and 5, and partly also 2. I argue those requirements are unnecessary: Open Development is possible even in commercial, for-profit companies.

In order not to steal or redefine Gianugo’s term, let me thus propose another term “Participatory Open Source“, with the following “first stab” requirements:

1. software released under an Open Source license;
2. well-defined public guidelines for how to participate in the development process;
3. a publicly available detailed list of bugs;
4. a public roadmap with detailed descriptions of planned tasks;
5. code reviews accessible for the public;
6. public code acceptance criteria;
7. active public instant messaging between the developers;
8. well-maintained public system documentation;
9. a publicly documented mentoring system for grooming new developers;
10. a worldwide geographic spread of the developers;

In some respects, this is similar to Gianugo’s requirements. My 1 = his 1. My 2 = his 3. With his 2 and 3, he may also refer to some of my items 3 to 10, that are on a more detailed and practical level, attempting at describing the baseline components of an Architecture of Participation in software development.

In other respects, there are clear distinctions between Gianugo’s set of five, and my set of ten. Most of all, my set of ten would work for a company with a commercial agenda (like MySQL AB), whereas Gianugo’s items 4 and 5 would not. I think it is absolutely possible to combine a commercial agenda with an Architecture of Participation when developing software, and not just in producing or distributing content (like, say, Google or Amazon). That is why I have excluded any requirements like Gianugo’s 4 and 5 from my list.

On a specific, detailed level, I also see a need for clarification in Gianugo’s item 2 “a non-discriminatory access to the developer’s community”.

• First, what is “non-discriminatory”? If non-discriminatory means “code contributions shall be accepted regardless of the gender, race, country of origin, or age of the contributor”, it’s probably OK (whereby certain countries of origin might incur exposure to legal or other risk). If non-discriminatory means “even technically inferior contributions must be accepted”, it’s obviously not OK. The interesting middle ground is whether it’s OK to say “no” or “maybe later” to technically sound contributions that don’t fit with the business interest of the owner of the main code base. I would argue that such “discrimination” is OK, as the “Participatory Open Source” requirements would otherwise impose so severe purity limitations, as not to be interesting for companies with a commercial agenda, like MySQL AB.
• Second, what does “access” mean? The right to participate? Sure. The same rights as the central governing body? No way.
• Finally, what is “the developer’s community”? OK, this may only need a phrasing clarification, as I suspect Gianugo does refer to the community of people developing the software itself (in our case, those who code MySQL using C or C++), as opposed to the community of people developing code using the software (in our case, those who use MySQL when coding in PHP, Perl, Java, Ruby, Delphi, VB, Python, etc. etc.).

At any rate, I fully agree with Gianugo that there is more to Open Source than an Open Source software license: The active participation of the community in developing the software.

Oh, and finally: I don’t think MySQL AB is yet fulfilling all ten points. But if I can have my way, we will when the year 2007 is over.

Contrary to some reports in the community, MySQL will continue providing binaries both for Windows and other operating systems. All our download pages, including those for MySQL 5.0, have binaries today, and will continue to have them.

The source-only releases we introduced with 5.0.33 (and will continue to provide in the future)are just in addition to the binary-and-source releases. The current latest binary-and-source MySQL Community Server release is 5.0.27, and I expect MySQL 5.0.35 Community Server to be released as binary-and-source within a month, both for Windows and our other platforms. This is as we always planned it, and tried to communicate it. I am sorry our communication has not been clear enough.

MySQL has today refined its licensing scheme from “GPLv2 or later” to “GPLv2 only“, in order to make it an option, not an obligation for the company to move to GPLv3.

Specifically, this means that copyright notice in the MySQL source code files will change from referring to “either version 2 of the License, or (at your option) any later version” to “version 2” only, in the MySQL 5.0 and MySQL 5.1 code bases.

Six years ago in the summer of 2000, when MySQL AB licensed its software under the GPL, our founders David Axmark and Michael Widenius made this choice because the GPL was a license followed and respected by everyone. We have kept to it, because the GPL is the most palatable license, and poses the least friction for our user base.

MySQL has been part of the GPLv3 Committee B advising FSF since the GPLv3 draft was announced in January 2006. For GPLv3, we have seen fantastic improvements and hope for GPLv3 to spread. Even though my activity level as co-chair for Committee B was by far higher in the spring than what it has been in the past few months, MySQL AB continues to work with the FSF for GPLv3 to be the new, widespread license under which Free Software is licensed. However, now, until we get clear and strong indications for the general acceptance of GPLv3 over GPLv2, we feel comfortable with a specific GPLv2 reference in our license.

I have been in contact on the topic with Professor Eben Moglen, General Counsel for the Free Software Foundation, and Chairman of Software Freedom Law Center. He has emailed me:

I appreciate MySQL’s thoughtful contribution to the GPLv3 drafting process, showing how a business model and an entire company can be built around Free Software. Looking at recent developments and announcements, I believe MySQL will soon be in a position to see the GPLv3 being adopted over GPLv2 by various Free Software projects.