Wednesday, November 25, 2009

7.4 Drafting Open Source Licenses











 < Day Day Up > 







7.4 Drafting Open Source Licenses





As should be evident from the

previous discussion, drafting a new

open source license is probably not the best place to start for most

open source projects. In addition to the extra time and expense

associated with drafting any legal document, the use of a new license

will discourage potential contributors from participating in the

project. Those contributors who are concerned about licensing

implications will want to read and understand the license.

Particularly in the case of long or complex licenses, this may

present a substantial barrier to entry.





If you choose to do it, however, the first step in drafting an open

source license should be retaining a competent and experienced

attorney to undertake the task. While

many open source licenses have been drafted by non-lawyers, the

drafting of any contract, particularly one with the complexities

inherent in open source software licenses, should be undertaken by

someone with professional knowledge and experience.





After securing counsel, the next step should probably be devising the

basic mechanics of the license. The new author should give serious

thought to what the function of the license is intended to be. With

open source and free software licenses, the

key

issue will generally be the generational limitations placed on

distribution and modification of the licensed work by licensees. Many

of the possible limitations have already been described. The MIT and

the BSD Licenses, for example, require only that the text of the

license be included in the subsequent distribution and that the

required attributions be made. The GPL imposes much more substantial

limitations: any distribution or modification of the work by

licensees must be consistent with the terms of the GPL. If a licensee

wishes to modify and distribute the work, he or she must license

future users of that modified work under the GPL. The MPL imposes

somewhat similar restrictions for modifications to the licensed work,

but it permits either the original or the modified work to be

distributed as part of a "Larger

Work" under another license, including a proprietary

license.





The number of potential variations is nearly infinite. The

Open Source

Definition, described in Chapter 1, imposes

some specific requirements for a license that the author wants to

have certified as compliant by the Open Source Initiative.





A brief summary of those requirements follows here. An open source

license must permit an open development model to be applied to the

licensed work, in that the source code must be provided or otherwise

made available with the executable version of the code. The license

must permit free modification of the licensed work and free

distribution of both the original and the modified work. The license

cannot discriminate in its application against any person or group of

persons or any field of endeavor.





Of course, a license need not be compliant with the

Open Source Definition to be an effective

license. But if the intent is to draft an "open

source license," failure to comply with the Open

Source Definition is a pretty good sign that the drafter is not

headed in the right direction. Beyond the fundamentals of the Open

Source Definition, there is considerable scope for creativity and

ingenuity in drafting licenses.





Many of the licenses described in this book, such as the

Apache License, v2.0, and the

MPL, begin with long, comprehensive

lists of definitions. While not necessary, using such definitions can

avoid unnecessary repetition of the same language throughout the

license. A definitions section can also avoid accidental, and

apparently inconsequential, variations in phrases or sentences that

are supposed to be identical. Such variations can lead to potentially

serious problems in interpreting the license, as users and

contributors, and possibly lawyers, judges, and juries, attempt to

determine whether the use of slightly different language was

accidental or intentional.





Disclaimer of warranties and limitation of liabilities clauses are

virtually universal in open source licenses. While certainly not

required by the Open Source Definition, they are prudently included

in such licenses to protect the licensor and any potential

contributors from liability. Such clauses are not unique to open

source licenses梞any commercial software licenses contain

similar terms.





The use of choice of forum and choice of law

clauses is relatively uncommon in open source licenses, but there are

many situations in which such clauses could be advantageous to the

licensor, particularly for

"developer-centric" licenses, such

as the Apache License, v2.0, and the Perl License. With such licenses, it is

anticipated that the project will remain primarily under the control

of its initial developer. That developer may want to choose a local

forum and the application of local law for the convenience of the

developer in the event any dispute arises under the terms of the

license. For example, a developer located in Boston may want to

identify the Massachusetts state courts located in Boston as the

forum for any dispute under the license and for Massachusetts law to

control the interpretation and enforcement of the license. When

considering the use of such clauses, developers should consult with a

lawyer to make sure that the law that they are choosing to govern the

license will interpret and enforce the license consistent with the

developer's understanding. Laws vary significantly

among different locales: it is certainly possible that a New York

court would reach a different conclusion than a Massachusetts court

as to how a contract should be interpreted.





One final area that a developer should give some thought to

addressing is the applicability of

patents to the licensed work.

In order to prevent patent litigation to the extent possible, it is

probably worthwhile to include a clause in the license that grants

specific permission for users to exercise a royalty-free right to any

patents held by the licensor, and, depending on the terms of the

license, any subsequent contributors.







For a list of licenses that the Open Source Initiative has approved as

conforming to their expectations of open source, and for information

about their process for approving licenses, visit http://opensource.org/licenses/.






















     < Day Day Up > 



    No comments: