Previous    Table of Contents    Up    Next

Licensing Issues

The license you choose can create problems if it is unfamiliar to your target audience or inappropriate for your project.

It is a bad idea to create a new license for your project. There is a set of existing, mature open-source licenses that open-source developers are familiar with, and it is unlikely that your concerns are not addressed by one of them. If people are unfamiliar with a license they tend to be suspicious of it and shy away from the project. When Sun first introduced the Sun Community Source License (SCSL), no one quite knew what to make of it; it was also hard to understand. Using a new license requires taking on a large community education effort--time that might be better spent working on your project.

The Mozilla project has decided that it wants to be able to engage more with a number of projects that use the GPL. As a result, it is in the messy process of contacting all the people who have ever contributed code to Mozilla to get their permission to multiply license the code under MPL, GPL, and LGPL. This highlights two problems: how letting contributors hold the copyright for their contribution prevents changing licensing terms and how the choice of license can limit who will work on the code.

Beware of trying to change either the license or the contributor agreement after your project is underway. Sometimes doing this is no problem; for example, OpenOffice changed from requiring contributors to assign copyright of their submissions to Sun to requiring contributors to sign a joint copyright agreement (JCA), which gave contributors more rights and was accepted by the community almost without comment. However, when the NetBeans project, which had not previously required copyright assignment, announced it was adopting the same joint copyright requirement for contributors, several community members complained that Sun was acting unfairly, because it took away the right of exclusive ownership. Had NetBeans started with a JCA, it is likely that the issue would never have arisen. Part of the problem with almost any change you make is that it will act as a lightning rod, opening the door to larger-scale criticism if your community has major unresolved issues with the way you are leading the project.

In general, when a company sponsoring an open-source project decides to make a major change to the license, the code, the architecture, the community, or anything else visible and important, the outside community will tend to view such decisions with suspicion. It will wonder whether there is some hidden, sinister reason for the change that is not decipherable and hence represents a trap. Therefore, make changes with care and involve the community as early as possible in discussions about important changes.