Back to the archive list

This article was originally published in the Summer 2004 issue of Methods & Tools

---

Collaborative Source Software - Combining the best of open source and proprietary software

Stéphane Croisier, Jahia Ltd - www.jahia.org
CollaborativeSource.org - www.collaborativesource.org

Introduction

There are two worlds in software today: the closed source world of traditional software vendors and the open source(For convenience we use "open-source" or "free software" -note the lower casing- to encompass Open Source, Free Software, and similarendeavors) world of Linux, JBoss, MySQL and others. Neither the open source norclosed source models are new: both have been around almost from the beginning of computing. But neither has managed to take over the other.

More and more customers are today disappointed by closed source proprietary software but they do not want to rely part or wholeof their IT strategy on some pure open source projects managed by virtualpeople. They want real software vendors with long term dedicated and traineddevelopers, real product release cycle management, strong support agreements and code warranties.

After having carefully studied both approaches in order to license our own software, we decided to create a new paradigm whichcombines the best of both worlds. In this article I will present it, how we cameto it and our experience after some years of practice.

1. Current business concerns with open source software

A great deal has been written recently about the advantages of open source software. Some writers have predicted that it willoverthrow the commercial software world. In its present state I find this improbable. Open source software has too many inherent limitations despite thefact that the strengths of free software are still very real. These are discussed below.

Analyzing Open Source software

Open Source software delivers real advantages but has also certain weaknesses especially in its possible underlying commercial business models.

Firstly, one has to understand the world of software license. Stig Hackvän has dressed a basic chart of the licensinguniverse that is quite explicit (©Stig Hackvän - http://devlinux.org/devLicense.html

                                  COOPERATIVE

                                      |                            x
                                      |                        Public
                                      |                        Domain
                CONSTRUCTION          |            FREE
                (LEASE TO OWN,        |            (GRATIS, PERMISSIVE)
                 DISTRIBUTED DEV)     |
                                      |          x BSD-style
                 variable transition  |          x Artistic
                 (delay, or flat fee) |          x Mozilla Public License
               x <-----------------------------> x pub/License (paid in full)
               dev/License            |
                                      |
             C2Net's Stronghold       |
EXCHANGE  ---x------------------------+-----------------------------  GRATIS
TIT FOR TAT                           |                          OPEN SOURCE
             x                        |
             SCSL                     |
                                      |
                                      |
                PROPRIETARY           |            COPYLEFT
                (CLOSED, CONTROLLED)  |            (GRATIS, CONTROLLING)
                                      |
                        ~ 1yr delayed |
                        transition    |
                      x -----------------------> x
                      AFPL            |          GPL
          x Typical Commercial        |
            License
                                 UNCOOPERATIVE

However this matrix is not representative of the size of each market. Most of the ready to use enterprise software is still located in the bottom-left quadrant. Why? Why are there so few ERP, CRM, CMS, Portal… or other similar types of enterprise software in the open source world compared to the proprietary offerings and why do open source projects mainly stick to the lightweight product corner and have difficulties competing with mid-range or high-end proprietary products? And finally why there is no existing license today positioned right in the middle of the quadrant allowing best of all worlds?

To understand it, you have to analyze one of the key criteria for an open source project which is usually proportionallyinverse to the success of the project: "the economic of respect". Themore an open source project is successful, the less this criteria will be respected.

The economics of respect is only relevant for a small fringe of the population

The hacker community is based on a gift culture. The term hacker is taken in the meaning of a computer enthusiast, i.e.,a person who enjoys learning programming languages and computer systems and canoften be considered an expert on the subject. The term can be eithercomplimentary or derogatory, the negative connotation refers to individuals whogain unauthorized access to computer systems for the purpose of stealing andcorrupting data. Hackers, themselves, maintain that the proper term for suchindividuals is cracker. Its inhabitants gain respect not by amassing propertybut by giving it away. And the word "community" is important as well.It means a particular sub-culture. Humans evolved to cope with a community of afew hundred people at most, not hundreds of millions. We solve this problem bycreating mini-communities and seeking respect within those. Hackerdom is acluster of these mini-communities and hackers seek respect within them bycontributing code "for free". When the group felt that the person had"earned" the merit to be part of the development community, she wasgranted direct access to the code repository, thus increasing the group andincreasing the ability of the group to develop the program and maintain/ developit more effectively. This principle is called "meritocracy": literally, govern of merit and is used in most open source projects.

Then "respect" acts as a form of value. The analogy with money is quite close. Like money the supply of respectis limited, and it is valued by members of the community. However there is onebig difference: respect cannot be traded between communities. I might gainrespect amongst the community of hackers, but that won't get me free credit froma shopkeeper. In contrast money is freely exchangeable between communities. If Iwant something from a shop I have only to walk in with money. This is the greatlimitation of gift cultures: they can only barter with the outside world. To do more you need money.

This limitation means that money has a divisive effect on gift cultures. A member of a gift culture is tied to thatculture: the amount of respect he has earned is in the heads of other members ofthe culture and cannot be transferred elsewhere. But if the same individualobtains money instead of respect then that money can be taken elsewhere, andeven traded for respect in another gift culture if desired.

The lack of mobility in respect matters in another important way. This lies behind the greatest failure of the free software effort: until recently its products could only be used by other hackers. Documentation was sparse and poorly maintained, and user interfaces were arcane and forbidding. The reason is simple: hackers don't see interest in easy-to-use packages, and so would give little respect to anyone who wrote one. If you want the respect of hackers then you are much better advised to write something that they want. The rest of the world needs easy-to-use software to handle routine administrative jobs, but the money behind that need does not buy respect in the free software community.

There is nothing like a free beer

Furthermore for the rest of the world there is almost no such thing as free software. Of course everybody agrees when Mr. Richard Stallman, one of the founders of the Free Software Foundation, mentions: "Think free speech, not free beer". However due to the inherent clauses which needed to be assessed by the open source world in order to keep this "speech freedom", the segregation between the free speech and the free beer became nearly impossible to apply in practice: with an open source license, everybody automatically gets the freedom to use, modify or copy the program from a royalty free manner. The software author can then only charge a fee on the distribution of his software. But if he plans to resell the "distribution" of his program, any of his customers also get the right to duplicate and redistribute his work for free. With the increasing popularity of the Internet today, this is now becoming even easier to freely "redistribute" software all around the world in a few clicks. Software distribution is then not an entry barrier any more. So finally open source software equals free beer in most of the cases.

Then commercial companies based on open source software needed to find other ways to generate some revenue streams. The most well known commercial open source business models today are for example based on:

• Selling some support agreements and a wide range of value added professional services on top of a widely spread open source project (e.g. JBoss Inc)
• Proposing some proprietary modules or add-ons on top of an open source framework (e.g. Covalent) or commercializing a distribution with improved installers, tested drivers… (e.g. Linux Distributions)
• Proposing a yearly subscription fee to get some enhanced documentation, some automatic upgrade programs… (e.g. Redhat)
• Dual licensing the software under one commercial and one open source license (e.g. MySQL AB).

Most of these business models still face one critical problem. They are giving away toothpaste while reselling toothbrushes. However they still need to cover both production costs. Everybody agrees that if a programmer writes some software then it necessarily is at some cost to somebody, even if that cost is only the payment that the programmer could have had for writing something commercial (known to economists as an "opportunity cost"). The problem is that, to go on with the comparison, the producers also publicly disclose their toothpaste formula and agree to let anyone freely copy and reuse it at will. Anyone may then easily understand that such a mechanism is not a reliable formula from an economical point of view. Any "competitor" may just take your toothpaste formula for free, decide to do not involve himself in your "R&D community of gift" in order to share with you the underlying maintenance and improvements costs and just focus on the commercial lucrative aspects: that’s to say selling the toothbrushes. The "competitor" is then easily in order to provide more affordable toothbrushes than the original producer may never do.

Hang on a minute. If this is so, why do so many people write such good software for free?

• Some of the incremental progress in free software can be attributed to the value of existing free software. If someone finds free software that almost fits their requirements then a few extra features can often be added for less than the cost of switching to a commercial package which could handle them.
• Some software is written by government employees, and is therefore automatically placed in the public domain. The cost of developing the code is then indirectly financed by your taxes.
• Increasingly, companies are releasing the source code of their non-strategical and non-tactical legacy IT asset in the hope that other programmers will extend and maintain them for free.
• A software company may decide to commoditize a certain technology in order to gain some market shares and be in a better situation to leverage other products or services. However this practice may only be applied by large software vendors which can leverage cross-selling opportunities in term of hardware, software or services

Open source programs assume de facto today that a certain number of end-users will never involve themselves into your community of gift. Such users like what you are doing, they want to use it but even if they wanted to they do not have the level of skills, experience or even just time to enter and involve themselves into your sub-community. This trend is even worse if the software company open sources a ready to use program as most of the end users won’t be any more hackers but common anonymous end-users. They become what we commonly name a technology free-rider. Their only interest is then not to gain some kind of "respects" but to simply freely reuse the work other did and, as good capitalists, to maximize their profits.

While your open source project is limited to a certain sub-community which can naturally respect each other member and who does not really take care if third party people can take benefits from your resources or if your project is indirectly financed by your taxes or by a company which agrees to finance your open source driven effort for one reason (extending the company market shares) or the other (trying to share the development costs), a classical open source model may be perfectly adequate. For other more traditional software vendors especially SMEs which focus on one or a limited set of programs (without any cross-selling opportunities) and that have to deal on a daily basis with the liberal system, they will face a major problem: they can not tolerate technology free-riders. There is no longer a win-win relationship here. As the program targets a larger audience the number of technology free riders increases, creating a feeling of being abused by the system for the software vendor. This certainly explains why so many software programs stay proprietary.

Solution: enforcing a real quid pro quo paradigm

• In summary we may say that the key open source advantages are:
• Free access to source code
• Unlimited right to modify, copy and redistribute the program
• Free use of the software

And the main open source weaknesses are:

• No possible direct license revenue streams leading to some absurd business models (technical documentation only available against payment, stable releases only disclosed to yearly subscribers, dual commercial license available to remove any possible viral effect on your code modifications...)
• A growing number of "technology free riders" who will never contribute to the program despite their increasing usage of open source technology.
• Most of the time, a lack of a competitive and reliable "software vendor" in charge of managing, maintaining, supporting the software and of coordinating the community of development on a dedicated and long term manner.

The major problem current open source licenses are facing is that they do not really enforce any quid pro quo paradigm ("something for something"). The open source culture is however heavily and strongly based on the gift culture we described above. For some open source projects this is perhaps not important to formalize it, as it is mainly restricted to a limited hackers sub-community who de facto respect each other. It is then clear for most of the interested parties that they will have to involve themselves in order to see the program evolved and maintained. For others, mainly ready to use finished software, the large majority of the end-users are technology free riders who do not ambition or even consider entering in your gift community and simply evaluate their own market advantages of benefiting from a gratis offering versus some commercial ones. There is no more sense of collaboration here, just some pure economic rationale.

Observing this for our own programs, we decided to "extract" the key benefits of open source and community based programs and to create a new licensing model which would respect most of the open source fundamentals, but which would enforce a strong quid pro quo paradigm where each user would have to contribute in cash or in kind to the project pro rata his usage of the technology.

2. Collaborative source software

Making open-source software commercial without some business tricks and workarounds (cf. the commercial open source business models mentioned above) while keeping the community and openness aspects requires two things: first that payment is collected in proportion to the benefit gained from the software, and secondly that active users in the community can compensate their license charges in proportion to their code contributions.

This means:

• Being as close as possible to the Open Source Definition (OSD) and allowing free access to the source code, free possible redistribution and free rights to modify the code 
• Being able to introduce some limited charges based only on certain limited type of execution of the program
• Allowing payment in cash or in kind (contribute or pay paradigm)

That is what we named Collaborative Source Software (CSS) and that we defined in a general Collaborative Source Definition (http://www.collaborativesource.org/jahia/page417.html). The whole mechanism aims to enforce a real quid pro quo mechanism. The rest is similar to the open source definition (http://www.opensource.org/docs/definition.php).

The underlying philosophy of this approach is the following: "We are very happy to share our program for no payment with those who agree to contribute to the project (enhance, debug, document, translate,...), but we also think it is fair to charge a fee from those who are not ready to involve themselves in our community of gift."

Allowing Value Added Execution-Based Payment

The origin of the strength of open source software is its freedom. Users are free to modify open source software and to distribute modified copies. Charges can be levied for the act of copying the software, but not for the information itself. CSS preserves these freedoms. Almost all the requirements for use of the trademarked term "Open Source Software" can be satisfied by a CSS license. The only freedom of conventional open source software which CSS modifies is the freedom to use the software without charge: open source software requires that the software be available for any use without restriction, while CSS requires that certain uses carry a charge.

The access to the source code remains of course free. There should be no charge (other than the usual copying expenses) for obtaining, reading, modifying or compiling the source code. It will also be permitted to execute the software for experimental purposes, for example to determine if it is suitable for the job, or to test some modified copies.

Instead, the charges will be imposed only for certain type of execution which adds value. In a commercial setting this is fairly easy to define: the use of the software to assist in any way with the operation of the company is adding value, and therefore should incur a charge. In a domestic setting the value is defined by the purpose of a particular execution: running a game program provides entertainment, which is valuable, and using a word processor to write a letter saves time and increases the quality of the result.

There are many possible frameworks for charging, most of which have also been tried by the closed-source software companies. For example:

• Per-copy charges. A fee is charged for each computer with a copy of the software installed.
• Seat charges. A fee is charged for each user authorized to run the software.
• Concurrent user charges. The software can be used by anyone anywhere, but may only be used by a limited number of people at any one time.
• Per-invocation charges. A fee is charged for each time the software is used.

Accepting payment in kind

However allowing value added execution payment is not enough to create a community of gift. This is no different than any other shared source or developer source initiatives. To enforce a real quid pro quo paradigm you also need to let users finance their license royalties in cash or … in kind. Otherwise speaking you need to agree to "value" contributors’ work by providing to them some free license’s credits.

Thanks to this system, instead of just being able to contribute to an open source project if a user wants to, he will now HAVE TO involve himself or he will be "taxed" as a technology free rider by some license royalties according to the value he gets from the program. We call this simple paradigm the "No Value Added Tax".

Such a mechanism helps the original authors create and maintain a stronger community of active developers in the long run as it provides clear incentives to all the end-users to contribute. A software author does not have to wait that new "volunteers" spontaneously decides to assign some of their time in order to help. The original author now has a leverage to push them to involve themselves in the community.

This also provides some good arguments for the IT managers to allocate resources on your project. The price of your program is not free anymore. It has a certain market value and an IT manager will need to compensate it in one manner (in cash) or another (in contributions). The passive "wait and see" attitude we commonly see from a lot of open source users is now banned.

Finally, in the spirit of Open Source Software, modified copies of CSS packages must of course be permitted. This ensures that the authors of a package do not have a monopoly on improved versions. However the end-users shall still pay the run-time license fees for the original package as well as any license fee imposed for the modification. The viral effect is no more on code (copyleft) but on contributions. A reseller or a distributor may then decide to freely repackage your work for research and test purposes. However when the final end user executes the software, he will have to pay to the various concerned intermediaries royalties in cash or in kind pro rata his use of the technology.

Valuation issues

Of course when trying to convert a user contribution into some license credits, the software author will face a valuation problem. This is not a trivial task and if he wants to go into the details, it may rapidly become quite complex. Indeed basing the valuation mechanism on a standard time = money equation may raise several problems: for example a junior developer will not have the same efficiency as a senior one, so the rate applied should then not be the same. In a similar manner you may say, from a marketing point of view, that a small killer extension may be worth more than a complex but not heavily used one. You will also face the problem of globalization: is it normal that certain users in certain countries with the same level of skills may need to work 10 times more in order to get the same license value. All these points should be correctly assessed but are not directly defined by the CSS definition. This is left to the responsibility of the program’s author(s).

From our experience the valuation issue should not become an administrative burden. The real underlying objective is to enforce a quid pro quo paradigm, not to scientifically know if the value of the contribution is worth ABC or XYZ to the precise cent. Valuing a development is performed every day by system integrators all around the earth. The same best practices may then be easily applied to your CSS project except that the rules are this time inverted: the software author will act as the customer requiring a "quote" from the future licensee.

Synthesis

So, in summary the CSS licensing policy is taxing only to the one who attempts to get an unfair benefit of other peoples' work. The choice of payment type is completely up to the user.

The quid pro quo principle is the best way to ensure the availability of high-quality, rapidly evolving software while keeping full and free access to the whole source code. Thanks to the community of contributors, users have battle-tested and well-integrated software. Thanks to the paying customers, the editor can afford to hire great developers and have them work full-time on developing and maintaining the product.

3. Advantages of the Collaborative Source License

As mentioning before, Collaborative source software solves a lot of business issues. You now have a real win-win deal for each actor. No one may feel left out in the blue.

From a customer point of view:

• Customers will have all the benefits of a program managed and supported on the long run by one or several professional software editor(s). This includes a dedicated full time R&D team, some level of free support and assistance, patches and bug fixes that could be developed rapidly,...
• Similar to open source software, customers will be able to contribute new generic features that they needed to the original project. This means that the code will be maintained, upgraded and/or debugged afterwards by the whole community and not only by the customer or the software editor.
• Thanks to the "contribute or pay" paradigm, customers will not increase their overall project TCO (Total Cost of Ownership). If they want to extend the program for one reason or another, they can use their license budget either to recruit or assign internally some development resources or to mandate an existing project contributor.
• This is the fundamental principle of Collaborative Source Development: thanks to this philosophy, an active contributor will pay only part of his royalty or, according to the value of his contribution, no royalty at all, reducing the cost of ownership in such a case to the cost of a standard open source project, that is to say zero.

From a developer point of view

• Free and unlimited access to the source code for all the latest stable releases and to the new version under development. No delayed open sourcing. No kind of hidden license cost based on some "yearly community subscriptions" required to get access to the latest stable builds or to the development documentation. Developers immediately get free access to the whole development resources as the license is only limited to certain types of value added executions (e.g. production server only).
• Similar to any classical open source project, developers are able to adapt the software to their own needs without the usual constraints imposed by proprietary code. Then if it's important for the company, you don't have to wait for the editor to develop the needed updates or patches.

From a software editor point of view

• The software editor is now able to finance his company from a reliable and competitive manner thanks to revenues coming directly from license and maintenance royalties. He can then stop inventing crazy business model, often difficult to explain to customers (let's think about the dual licensing model based on a "viral effect on derivative work" which may impact your code modifications if you take the free version of the program).
• As there may be some limitation on the software sales, the software editor may also improve control of the network of authorized resellers and vendors. This avoids having companies without a real knowledge of your product being able to resell any kind of services while using your product’s notoriety. This also allow the software editor to better control OEM, VARs or other type of software vendors that will embed part or whole of your technology for their own benefits.

• As the main architect of the technology and thanks to the mechanism of payment in kind, the software editor may also leverage cross-selling opportunities by also offering a wide range of professional services. Of course, in opposition to proprietary software business models, the editor no longer as the exclusivity of developing new features. However, in practice, customers will often mandate the software editor to enhance the program thanks to his larger expertise on the technology.

From a partner / system integrators point of view

• The partner (e.g. a system integrator) has full access to the source code. He can then solve problems for his customers (bug fixing code, adding some new features) without having to rely on the software editor in term of pricing, delay...
• The partner may get some license sales commissions as it is usually the case in the industry to cover his marketing and promotion costs
• The partner can finally propose a wider range of services to his customers without increasing the overall project TCO. The end-customer may mandate his regular system integrator in order to develop a new generic extension which he will contribute back to the community once developed in exchange of a software license. This process creates a win-win situation for every actor: the customer gets the new extension he wanted, the partner can resell more value added development services without increasing the overall project pricing, the editor and the community finally gets a better program.

4. Feedback from experimenting collaborative sourcing

We will try to introduce in this section some best practices that certain software editors experienced while releasing their programs under a collaborative source license schema these last years.

Impact on software management

Managing a CSS project is quite close to managing an open source project. If a software author wants to really leverage the "collaborative sourcing" effect on his program, he will need to organize his developments to best leverage contributions from the community. This often requires significant adjustments for software vendors generally used to centrally control all their software release cycle management to have to move to a community based system. Thus agile methodologies such as XP are usually clearly more adequate. Such flexible methodologies may be more easily adjusted to virtual community members who will all follow their own vision, milestones and deadlines.

However, in opposition to open source projects where it is sometimes difficult to refuse volunteer contributions over the pretext that it is not documented enough or that it does not include certain test units, CSS allows you to better formalize the quality, milestones and deadlines of the "outsourced" developments. Rules are reversed. The original authors now act as a customer in case of a payment in kind. The follow-up, tracking and reviewing process of external contributions are then considerably eased by the fact that there are now some "contractual" agreements between the actors.

Finally the Technical Committee will play a role even more critical than for a similar open source committee. Not only shall it lead the technical vision, it will also be in charge of accepting, valuing, tracking and reviewing all the external contributions. But correctly applied, this will enforce a stronger quality to your project while considerably reducing your R&D budgets.

Impact on organization

Thanks to the introduction of limited execution charges, the software company can now get some real license revenue streams that can be directly allocated to maintain and improve the program or to cover the direct administrative operating costs.

When allocating license revenues two main approaches are possible:

• The classical software vendor approach. The original authors keep the license revenues internally in order to finance their own dedicated R&D team and optionally to make some benefits.
• The collaborative approach. The software organization acts as a shell (it may be either a commercial company or a non profit foundation) in order to secure the IT assets and redistribute the license revenues to key contributors. Usually contributors could be divided in two major categories: developers who extend the software on a periodical basis when they need it and committers that are assigned on the long run on the project. In practice, the former tends to be employed by system integrators which allocate their IT resources according to the requests and needs of their customers, the latter tends to be small or mid sized software vendors which aim to leverage their sales thanks to the software.

This lead in practice to two main categories of partners: the System Integrators which integrates and occasionally develop on the software and the R&D Centers which acts in cooptation as the de facto software editor, the whole thing being managed and coordinated by a virtual organization.

The collaborative approach is of course certainly more community-centric as A) it creates competition among the various R&D Centers B) it provides warranties to the customers against any possible bankruptcy of one of the R&D Center and insures that other dedicated teams will still be driving the software on the long run.

Finally in a full virtual community based organization where there is no more one or a small number of lead software vendors but a multitude of independent authors, you may decide to allocate the revenues pro-rata the contributions realized. If you have created a commercial company to centrally manage your software asset, you may even think about providing shares to all the key contributors according to their respective efforts.

Of course CSS does not stipulate how the company revenues or shares shall be distributed among the contributors. This is up to the original author to decide how he wants to manage it according to the legal structure he puts in place and his product strategy. The only mandatory condition is to let users pay part or whole their license fee in kind.

Impact on partners

Thanks to the clear segregation among license revenues and professional services revenues (from support agreements to customization services), CSS also avoids conflicts as they may today arise between existing system integrators and other commercial open source business players. With a collaborative source program, the software vendor or the ones acting as the de-facto software vendors (the R&D Centers) may keep a partner neutral attitude and will not try to bypass their local system integrators partners by trying to resell their own range of professional services. In this business model each rule in the industry is clearly respected.

The limits of collaborative source software

The main limit created by a CSS program is obviously caused by the viral effect on contributions (and indirectly on royalties). An organization may not simply modify and enhance the software and then redistribute it in an unlimited royalty free manner to all its subsidiaries. Like for any traditional proprietary software, there is now some charges pro-rata the use of the technology. However the original authors may propose some kind of "Organization Wide License" that could be easily dealt in the spirit of a collaborative source win-win approach between all parties.

End-users shall also be able to predict the long-term cost of owning the software if they have to make some rational choices based on value for money. So in a CSS program, the fee for a particular version may only be increased in line with general price inflation. The practice of "stiffing" clients who need to add users or upgrade hardware after becoming locked in to a particular package is therefore banned.

Finally several users also raised the risk that a CSS editor may abruptly reject the collaborative source approach once a large community of users is locked to his software. Even if this risk is not limited to CSS project only (you may exactly face the same risk with MySQL AB for example), it is true that it may become more difficult to fork a CSS program rather than an OSS program. To compensate this threat and in order to get the same advantage than a classical open source program, authors can add a backward open source compliant clause that will force them to release the last version of their software into a classical open source license if they cease to support a CSS license.

All these clauses (and certainly new ones as we are still experiencing the model) should avoid a software vendor being able to abuse "the community" he created around his project.

Synthesis

CSS software could be easily adjusted to any type of programs. According to our experience it best applies to ready to use enterprise software developed by some small and mid-sized ISVs and whom value are more than 1’000 USD. If your program aims to the large public and only costs a few dozens or hundreds of dollars, the administrative costs of valuing contributions in kind will be too high compared to the community benefits you will obtain. Then a classical open source approach or even a developer source approach (source available only after having paid some royalties) would be more adequate. On the other side large software vendors may prefer leveraging some of their open source investments by choosing a cross-selling (open-source-proprietary extensions-services) strategy. However such a practice is often not possible for a small or mid-range ISV.

Summary of the main various software licenses

	Open Source		Collaborative Source License	Developer Source License	Proprietary License
	Copyleft license (e,g, GPL)	Permissive License (e.g. BSD)
Source Code Access	Yes	Yes	Yes	Limited (e.g. under NDA)	No
Warranty of code availability in time	Yes	Yes	Yes	No	No
Code Modifications Permitted	Yes	Yes	Yes	Limited	No
Community based working	Yes	Yes	Yes	No	No
Derived Works Possible	Yes (but only open source derivatives compliant with the license)	Yes	Yes	OEM Agreement	OEM Agreement (based on a proprietary API)
Free redistribution	Yes	Yes	Yes	No	No
Free use	Yes	Yes	Limited	No	No
Royalties	0	0	0-∞	0-∞	0-∞
Payment	N/A	N/A	In cash or in kind	In cash	In cash

Conclusion

The sudden realization of the importance of open source software to the world economy has had a mixed reception from bothcapitalists and free software hackers. Hackers are afraid that capitalists willdestroy the gift culture that they have created, and capitalists are unwillingto trust hackers with their future. Neither side really understands orsympathizes with the world-view of the other. Hopefully the two sides can findcommon ground in the principle of giving value in return for value. Trade is thebasis of capitalism, and I hope that in this article I have shown how it isalready the basis for open software as well, in the form of respect. Byarranging for both money and respect to flow in the merit stages we can combinethe advantages of open-source software with capitalist economics and motivation. This combination should conquer the world.

Back to the archive list