Multicore Programming Blog

Introduction

As Cilk Arts prepares for general availability of our first product, Cilk++ 1.0, we are finalizing our licensing model. We plan to dual-license Cilk++ using a new open source license: the Cilk Arts Public License (CAPL).

We have been evaluating business models for Cilk++ since founding Cilk Arts in 2006. As a venture-backed company, we need a model that yields enough revenue to attract the capital we need to develop and distribute our solutions. Many closed source models could accomplish that goal, but they serve only those developers who are willing and able to use closed source software.

We wanted to do more. We are proud of Cilk++ and want all developers to be able to use it. Precluding open source users from enjoying the benefits of Cilk++, even if those users are not a source of revenue, is unsatisfying to us. We want to contribute to the open source movement.

Our challenge was to find a model that would allow us to deliver a strong open source version of Cilk++ while building a healthy Cilk Arts. Through our search for an open source model, we found that existing open source licenses contain a loophole that could prevent Cilk++ from thriving. The problem we see is that existing open source business models allow internal development organizations (IDOs) to exploit open source without contributing back to the community. This "IDO loophole" means that the burden of supporting an open source project spreads unevenly across its beneficiaries. It results in higher costs for those who carry the burden, makes open source much more expensive for others, and shrinks the support base. This situation is neither healthy for the open source community nor fair to all stakeholders. These considerations drove us to author the Cilk Arts Public License.

We would have preferred not to write a new license. The world does not need a proliferation of open source licenses, and the legal costs for us to develop our new license were significant. Nevertheless, after we exhausted all other options, our only reasonable choices were to release Cilk++ solely under closed source or to take on the challenge of drafting an open source license that closes the IDO loophole.

We believe that the Cilk Arts Public License (CAPL) offers a step forward not only for Cilk Arts, but for much of the open source community. In this post, we describe the IDO loophole in current licenses and address how the CAPL closes it. We would love your comments on the CAPL, as well as your suggestions for other ways to solve the IDO loophole problem.

Our Selection of a Business Model

The advantages of an open source business model to Cilk Arts and our community are obvious and well established. Open source allows us to leverage the power and intelligence of our user community and involve them more deeply in driving the development priorities for future releases of Cilk++. An open source Cilk++ can be modified by users to fit their needs. Open source yields more reliable and secure software and better support. We also like the high standard of accountability open source enforces on us. This pressure should drive a better Cilk++, which is good for Cilk Arts and good for our users. Given all of these advantages, it was obvious to us that Cilk++, like the original Cilk project at MIT, should be open source if possible.

The question was, "Could we find an open source business model and license that would accomplish all our goals?" To answer this question, we studied key success factors of open source projects, thought about what the open source movement needs to succeed, spoke with many open source experts, and interviewed dozens of our customers. The folks who helped us are too numerous to name every one, but we'd like to thank Marten Mickos (MySQL), Peter Levine (XenSource), Billy Marshall (rPath), Margo Seltzer (Sleepycat Software), Mark Mitchell (CodeSourcery), and the many dozens of users who took the time to speak with us. The collective wisdom and generosity of this group was a big help to Cilk Arts. Thank You!

Our research explored many business models. We then narrowed our research to the three options that best fit products like Cilk++.

One option we considered was anchoring our business on services revenue. Companies like Red Hat and JBoss do well with this approach. Cilk Arts is committed to making the path to reliable multicore performance as quick and easy for our customers as possible; and we provide consulting, training, and support to our customers as needed for their success. Our goal, however, is to make Cilk++ so simple and easy to use that any developer can use it without our assistance. Basing our business on services revenue is antithetical to that goal, and therefore we determined that a services-centered model was inconsistent with our mission "to provide the easiest, fastest, and most reliable way to optimize application performance on multicore processors."

We also looked at componentizing Cilk++, holding back pieces of the solution as proprietary items to be sold separately from the portion available under open source. XenSource and SugarCRM, among others, pursue this model with success. While we may indeed charge for some of our value-adding tools, we think our community needs a complete base solution - a multicore software platform that delivers productivity, reliability, and performance. We want to deliver a solution that doesn't hold major, valuable parts of Cilk++ out of the open source version. We would take no satisfaction in engineering a solution for our open source users that does not completely solve a problem. As a result, we ruled out componentization as the primary source of revenue for Cilk Arts.

Eventually, we selected the option of distributing Cilk++ under a dual license. Under a dual license, we can release a complete Cilk++ solution to the open source community while providing commercial licenses for those who choose not to adhere to the terms of the open source license. This model is well-established, simple for customers to understand, and best fits our mission.

Having settled on the dual license model, we searched for a suitable open source license for our dual license business plan. Unfortunately, all the licenses we found contain a loophole that would have hindered Cilk++ from being a successful contribution to the open source community or serving as the basis of a successful business.  Moreover, we believe this loophole, if left open, may prevent other companies like us from contributing to the open source movement.

The IDO Loophole in Existing Licenses

All successful open source projects are supported by exchanges. There is a give-and-take between a project and the community it serves, which results in a win-win situation for all.

The developers who contribute to the project give their software to the community and take back a variety of valuable things. They may take contributions in the form of bug fixes, product enhancements, and ideas to drive future development. They may take satisfaction from seeing their creations used by others. Finally, they may take income from commercial licenses paid for by those who enjoy the open source software but cannot abide the openness of their own derivative works. This income supports further open source development, attracts investors, and affords the developers soda and donut holes. (Cilk Arts developers eat many donut holes.)

The consumers of the project take the software and do useful things with it. They may create and sell new programs based on the original. They may build web services. They may use the software to run their companies. These consumers can give back to the community in many forms. Some folks contribute modifications and new works back to the project. Others give back by buying commercial licenses - providing cash to buy more soda and donut holes. This fundamental give-and-take between producers and consumers is a key element of any successful project. And, it is fair.

Unfortunately, today's licenses that support open source projects contain a disturbing loophole: many of the project's beneficiaries need not give back. Consider the GPL as an example. When used as the open source half of a dual license model, the GPL requires those who create and distribute derivative works to either share their source code or purchase a commercial license. Under this model, independent software vendors (ISV's) that distribute derivative works and typically make up approximately 20% of beneficiaries, have two options for giving back: distribute their derivative works under the GPL or buy a commercial license. They are free to choose either option, but they must give back one way or the other. In contrast to the ISV's, most of the other 80% of beneficiaries are internal development organizations that create but do not distribute their derivative works. The IDOs use them internally, and thus by the GPL, they need not share their derivative works with the community or obtain a commercial license to help fund further open source development. The IDOs exploit open source without giving back. They get a free ride on the backs of the open source community who share their software and the ISVs who pay for commercial licenses.

Some of the world's most successful businesses benefit from the IDO loophole. Many Internet companies deliver valuable web services built on open source software, keeping as proprietary software the derivative works that they build from open source. These IDOs enjoy this free use without a paid license, because the existing open source licenses permit it. Alternatively, to pick a popular target, consider the investment banks and hedge funds who build in-house applications using open source. These IDOs use open source to build applications that create enormous value (or at least income), but since they do not distribute their applications, they are under no obligation to contribute back to the open source project.

We do not think that the IDOs who take from open source without giving back are bad people. Minimizing cost and maximizing gain are desired behaviors in a market economy. These companies are just exploiting a gap in existing licenses that permits them to take without giving. They are not evil, but the open source license model under which they operate is unfair.

The IDO loophole is also bad for the health of companies like Cilk Arts who need to sell commercial software to make ends meet, but who nevertheless wish to contribute to open source. When the vast majority of people take without giving, the entire burden of supporting a project rests on the backs of the minority of open source contributors and the ISVs who buy commercial licenses. Costs are inevitably higher for the few who support the work benefiting many. The higher costs make it hard for some open source projects to be competitive with proprietary alternatives. Moreover, when the avenues for an open source project to generate revenue to support itself are restricted, it means the project has less to invest into developing new features or in providing the kind of commercial-grade support many users need to utilize open source. It also means that fewer software categories can support an open source business, narrowing the open source ecosystem. The net result is a narrower footprint of well-supported open source software, which is to the detriment of all - including the IDOs that today widely use open source software without giving back.

As we set out to develop our business plan, we looked for a way to plug the IDO loophole. We wanted to offer ISVs and others who are contributing to the open-source community today the same choice that dual licensing with the GPL offers: contribute derivative works or buy a commercial license. But, we wanted to go further with the requirement to share. We wanted to spread the burden of supporting Cilk++ more broadly, in particular to the IDOs, so that we can afford to release Cilk++ under open source while lowering costs for everyone. We also hoped that we could build a larger community of developers who contribute back to Cilk++, one way or the other.

Closing the IDO Loophole - the Cilk Arts Public License

Cilk Arts is not the first to address loopholes in open source licensing. We really like what Fabrizio Capabianco at Funambol wrote on the topic. Fabrizio's Honest Public License solves part of the problem by addressing the "ASP loophole," where application service providers (ASP's), which offer services to customers over a network, fail to give back. Another license, the GNU Affero General Public License, also helps to close the ASP loophole by extending the "contribute or pay" decision to web services companies.

Unfortunately, these efforts still leave the IDO loophole wide open for many beneficiaries. In particular, the Affero GPL allows IDOs building non-web, in-house applications to exploit open source projects without contributing back to the community. We think IDOs of all kinds should be required to make a fair exchange with the open source community. Expanding the "give" requirement to all IDOs will lower the costs for the rest of the community and expand the population of derivative works contributed into open source.

To close the IDO loophole, we set out to create a license that works identically to the GPL for groups who are already giving back. We sought to allow people who modify Cilk++ to have their modifications become part of the project. We also sought to allow developers to build things for their own use freely (free as in both "beer" and "speech"). The only change is to ask all who derive significant benefit from Cilk++ to give back to the project or community in some way.

These goals led to the creation of the Cilk Arts Public License. The CAPL is an open source license that enforces the notion of fair exchange. It is a you-share, we-share model. The concept behind our license is simple. It works as follows:

• You can take Cilk++ (or any other program licensed under CAPL) and use it without charge, just as you do any open source program.
• You can modify Cilk++ as much as you please.
• You can redistribute Cilk++ together with your modifications.
• You can use Cilk++ to build derivative applications for your own use.
  

If you, as the author of a derivative work, decide to share your work with someone else (other than for development and testing), however, then you must give back to the community in one of two ways - your choice. You can either share your derivative work with the community (under either the CAPL or a GPL compatible license), or you can forgo the CAPL and purchase a commercial license that does not have the sharing requirement.

The CAPL will not adversely affect the open source community of Cilk++ consumers. If you are building open source software and sharing your derivative works with the community, the CAPL operates like the GPL. In addition, you benefit from a Cilk++ that is supported by a wider base of "givers."

If you are an ISV who uses open source software but buys a commercial license to avoid open sourcing your products, you benefit. Cilk++ is still open source, and so you reap the advantages that open source brings. Moreover, your commercial license for Cilk++ will be cheaper than a dual commercial license paired with GPL, since Cilk++ is supported by a wider population.

If you are a developer or group of developers using Cilk++ to build an application for your own use, you should see no difference between developing under GPL versus under CAPL. Although we would like to encourage you to share your derivative works with the community, the CAPL does not require you to do so. Likewise, if you have a customer for your prototype Cilk++-based product, you can give them the Cilk++ source code to evaluate your product without you having to share your product more widely or pay for a commercial license.

If you are building an open-source application that you are distributing on the web, you won't see a change, but if you are distributing it only privately, you will see an impact. For example, if you're an IDO building applications for use by others but not "distributed" under the existing open source definitions (e.g., GPL) and you want to keep your Cilk++-based derivative work proprietary, then the CAPL requires you to make a fair exchange in order to use Cilk++. If you share your software with everyone, we share ours with you. If you do not wish to share, you can give back to the project by purchasing a commercial license. And if you do need a commercial license, we will ensure that Cilk++ is still a cost-effective option.

Free software purists may argue that the CAPL does not allow an IDO the privacy to do whatever it wants with their derivative work, and thus the CAPL does not promote "free" software. We believe that the CAPL does promote free software, but we disagree on the notion of privacy. We don't see how large-scale sharing within a corporation or among members of a cartel, which the GPL allows, constitutes "private" use, although reasonable people may differ on this point. The CAPL values community good and the privacy rights of individual developers over the so-called "privacy" of large corporate entities. We don't expect the free software purists to agree, but we believe that there is a need for a license with our interpretation of privacy.

We hope that the CAPL balances the give-and-take across all stakeholders. It requires a fair exchange with all beneficiaries. It lowers the burden for those who contribute to open source. It results in stronger Cilk++ software and support. It allows Cilk Arts to extend its commercial offering to the open source community. And, it is fair.

Comments?

Our efforts to introduce the Cilk Arts Public License could use your help. You can see a draft of the CAPL here. Please tell us what you think!

1. If you are developing open source software, would you consider using Cilk++ under the CPL?
2. Will closing the IDO loophole be good for Cilk++ and for the open source community?
3. Do you see other loopholes in the GPL or in other open source licenses that should also be closed?
4. Does the specific language of the CAPL accomplish the goals we set out?
5. Are any of the terms of the CAPL unclear, ambiguous, or unnecessarily onerous?
6. Have we missed a better way to close the IDO loophole?