Commercialization of PHP Software

I’ve just published an article that explains how a PHP-based product can gain a good position in the market and be made appealing to customers by using marketing communication. The focus is on products licensed under an Open Source license. Yet, most of the recommendations also apply to proprietary offerings.

The article has initially been published in German by PHPmagazin. It has now been translated to English and is available on the Initmarketing website: Commercialization of PHP Software.

Self-hosting Launchpad? Dream on…

Canonical recently announced that it open sourced Launchpad, its web-based project management and collaboration platform. This news came out while we were conducting an evaluation of Open Source collaboration platforms for a client. The client’s intent is to host a collaboration platform for its developer community. The evaluation was done based on feature sets, and was drafted before Launchpad’s source code was released. Launchpad turned out to be the slightly better choice and once it became available, we tried to install it.

Unfortunately, we began to realize that Launchpad isn’t designed or intended to be used as a self-hosting site due to the following reasons:

  • There are no release packages. You checkout the development code via a Bazaar repository and then compile it. Depending on the state of the last checkin, the code might even not compile sometimes. It took us two tries to get the installation done.
  • The working installation is meant for local use only and it’s not trivial to get it running under a normal, fully-qualified domain name.
  • Even if we had figured out how to make Launchpad serve properly via HTTP to the general public, we would have faced a maintenance nightmare by doing QA and release management ourselves.
  • Let’s not forget the fact that Canonical requires you to not use the trademark “Launchpad” and to replace all the graphic icons.

It is not without irony that an Open Source marketing agency was blinded by the fuzzy PR parlance of Canonical. Luckily, the source code always tells the truth.

After we had discussed the issue on the launchpad-dev mailing list, Canonical today added the following line to the Launchpad Development Wiki, which makes it pretty clear:

Note that our focus is on getting Launchpad to build easily so more people can participate in Launchpad development. Running a stable production instance would be ”much” harder than running a single-developer test instance, and we don’t recommend it. Unlike many open source projects, we’re not seeking to maximize the number of installations; our goal is to improve the instance we’re already running at

Obviously, Canonical really doesn’t have to worry that by open sourcing Launchpad, they licensed away their business model.

Our client has opted for FusionForge. It’s a great alternative, works out of the box, is easy to install and includes all the basic features. It runs on top of Ubuntu 9.04, an Open Source operating system backed by Canonical, which, ironically, has some proper release management 🙂

Open Source Business Models: "Dual Licensing" and "Quid Pro Quo" Explained

For anyone wondering, how the “Dual Licensing” business model of MySQL works, they have briefly explained it in a news posting:

As second-generation open source vendors, MySQL AB, Sleepycat Software and Trolltech AS make the majority of their revenue from selling software licenses. This license-based business model offers higher margins than services-based businesses. Historically, most open source companies have tried to make money by selling services and support.

The guiding principle behind dual licensing is “quid pro quo,” or a fair exchange. Under this model, vendors offer their products under both an open source license and a commercial license. This allows open source projects to use the software at no cost, which contributes to widespread use and testing of the software and the fast growth of a large installed user base. Companies redistributing the software as part of commercial products can also get the benefits of the open source software by purchasing a commercial license, which releases them from requirements to publish their source code. Commercially-licensed customers generate revenue for the open source vendors, which contributes to the rapid development of high-quality software.

I thought about the term “fair exchange” and came to the conclusion that the Dual Licensing business model is based on three crucial factors: knowledge, time, money.

This means: If you’re a FOSS software developer, you might have a basic understanding of which licenses are compatible and which are not. If you’re a software developer in a company that has never dealt with FOSS licensing issues but would like to use MySQL for example, you could either consult one or more lawyers that analyse the situation for you. The other option would be to pay the costs for a commercial MySQL license, which are marginal compared to what the lawyers would charge.

Seen from that perspective, the Dual Licensing model is fair in terms of how much the software user knows about the topic: If you do not have money, but time to investigate and inform yourself about FOSS licensing and you produce FOSS software yourself, you can do your work without any financial burdon. On the other hand, if you have money and you’re short on time analysing the whole issue, simply pay the fee for a commercial license.

The revenue of companies like MySQL is based on the three crucial factors “knowledge”, “time”, “money”. Dual Licensing shows that software companies who in fact produce true knowledge goods, can make money based on these factors and behave fair as well as profitable in a knowledge economy. It is also important to understand that there are two kinds of revenue they make: financial revenue from commercial licenses and revenue in terms of knowledge and lower development costs. The later is what MySQL gets back from a FOSS community that might not buy commercial licenses, but do testing, bug fixing, APIs, etc.

In a knowledge economy, “knowledge” is a good that gains value the more you have of it – other then the industrial economy, where goods usually loose value if the market is saturated. The Dual Licensing business model somehow plays industrial if you want to combine FOSS software with non-FOSS software, i.e. if you do not adhere to the standards of a community of open knowledge transfer. Then you will have to pay for the software aka knowledge good, just as if it were a car. On the other hand, if you are part of the open knowledge transfer aka a free community (“free” as in “freedom of speach”), you can use for example a GPLed software for free (“free” like in “free lunch”).

Distinguishing Patents and Copyright

Tony Stanco formulated a clear distinction between patents and copyright:

Copyright provides exclusive plenary rights to the owner. Patents provide the owner only with the right to exclude others. I think the distinction was grounded in the fact that it would be hard to conflict with someone else’s copyright in an original work (which usually stood alone), while complex, interrelated processes/machines could easily involve multiple and conflicting patents. As a result, patents are only negative rights and a person’s exploitation of a particular patent in subject to the non existence of conflicting patent(s).

It’s a nice conclusion in a long discussion.

Will We be Sued?

… asks Larry Rosen on the mailinglist of the Open Source Initiative and answers:

Of course we disclaim most warranties and liability in our licenses. Why should we willingly accept potential liability when we give our software away for free? Despite what our licenses say, however, we are subject to local laws relating to gross negligence and fraud. As a matter of public policy in many civilized jurisdictions, we can’t recklessly distribute damaging software to consumers and expect to get away with it.

So we should treat free software businesses as real businesses. Behave professionally and ethically in all our intellectual property transactions. The chances of being sued when we do that are slim to none. But it is wise
to put some money into your bank account just in case you need to hire a lawyer to answer all your questions.

In Germany, you are always reliable for the software you are selling to your customers.

If you really need to go to a lawyer, you should know what you want or need before you go there. Your lawyer is only as good as you are self-aware of your case.

The best thing you can do, is not to do any businesses with customers you sense that they act strange, overdemanding, insidious. If you do not feel good, don’t do it. Well, often you cannot afford sending away customers, then make sure you have enough money on your bank account, just as Larry Rosen proposes.


If Linux were BSD …

> >If Linux were BSD there would be no suit, simply because there would
> >be no competition.
> I agree wholeheartedly with this point. And there wouldn’t be thousands
> of volunteers if they thought they were providing free labor for
> others, particularly development houses that then released products
> only for the Windows platform. Fortunately, we’re not in that
> dimension.

I hadn’t thought of that. That might be part of the reason why the GPL-based projects are so much larger than the BSD-based projects.


Update: Zak has commented on the “If Linux were BSD” thesis. He pointed out that there are many non-GPL projects just as “big” as well known GPL projects. This is a remarkable note by Zak, considering that he works at MySQL AB, whose Database is GPLed and itself one of the “big” FOSS projects.

These kinds of discussions remind me of ideologic discussions during the cold war: is capitalism better then communism? Today, now that the cold war is over, we realize that beyond the east/west antagonism, many problems have been hidden specific to a single country or area.

Ideologic discussions that try to create a linkage between how “big” a FOSS project is and the license it adopted, tend to move our attention away from the real problems the FOSS community has.

Web Services a Thread to GPL?

The OSI mailinglist has a discussion going on how a Corba interface to a GPL application can circumvent the derived work clause.

I am concerned whether a Corba interface can be used by non-free software to
circumvent the freedoms and requirements of the GPL license. […] A proprietary vendor could create non-free software that functionally would amount to a derived work, without actually making a derived work within the meaning of copyright law. Would this break the spirit of the GPL while complying with its terms, hence not be enforcable under copyright law?

As I understand, this discussion is in fact about any service aka RPC API like SOAP, XML-RPC. Hence, the essential question is whether Web Services form a potential thread to the GPL.

IETF Patents and GPL

Lawrence E. Rosen warns the Open Source community about IETF patents in the OSI discussion mailinglist:

“As I understand the GPL, none of the IETF standards that include that patented technology can be implemented under the GPL because of its Section 7.

Any open source projects implementing IETF standards should carefully review the IETF IPR list to ensure that they have proper patent licenses.”

An additional remark by Eben Moglen states:

“Moreover, patents are not global, only local. To say that we cannot *develop* under GPL because a patent exists in country X, and a license has been published there to which those making, using, or selling in country X *might* be asked to subscribe would go much too far. That situation certainly does not prevent development elsewhere, and distribution under GPL can certainly proceed.”

Find the whole thread here.