Out-Licensing

 <  Day Day Up  >  

Licensors decide what license to use for their open source software. If at all possible, licensors should use an existing template license. Please don't invent your own. The open source community is not seeking new licenses to analyze and interpret.

The proliferation of open source licenses creates a serious problem: It risks additional fragmentation of the public commons of free software. While software under some academic licenses can be combined without restriction, combining software under different reciprocal licenses ”particularly the more complex reciprocal licenses used by large companies ”requires that lawyers or skilled licensing professionals review each of the licenses for incompatibilities. Even where the differences between licenses are trivial, such as their designation of governing law, a combinatorial analysis of open source licenses rapidly becomes a nontrivial exercise. For example, it is a nontrivial exercise to determine whether a work that combines two separately licensed programs requires a file-by-file, MPL-like comparison or the more general work based on the Program derivative work test of the GPL. I say more about this problem later in this chapter.

Without exception, leaders of the open source community discourage the submission of "yet another license." Any software company deciding to distribute its software under an open source license is fervently encouraged to select among the existing licenses rather than to create a new one.

  • As before, the key licensing factor is whether to use a reciprocal or an academic license. As a licensor , do you want to be able to benefit from improvements made by others? Do you want derivative works created by your licensees to be distributed under the same license so that you can incorporate their improvements into your own software?

  • If a reciprocal license is desirable, you should consider the scope of the reciprocity obligation. Licenses like the GPL contain vague provisions about derivative and collective works; some licensors prefer that ambiguity because it results in more software licensee contributions licensed under the GPL. Licenses like the MPL have a more narrow definition of derivative works, requiring only files that are changed to be distributed under the MPL; this can reduce resistance from licensees who want to retain the proprietary status of their own contributions. For a more balanced approach, the CPL or OSL leave the term derivative works to be defined by the courts under copyright law.

  • Does the license define distribution ? The OSL goes farther than the other licenses described in this book by defining external deployment , so that the reciprocity provision applies regardless of how the derivative work is distributed. (See also the even more dramatic definition of external deployment in the Real Networks Public Source License published on the OSI website at www.opensource.org .)

  • Consider the scope of any patent licenses you will grant. Many licenses have only implied patent grants; the scope of those licenses is unclear. As for licenses with explicit patent grants (i.e., the Mozilla, CPL, and OSL/AFL licen-ses), decide whether you wish to allow your patents to be used for creating derivative works; these licenses have subtly different patent grants.

  • Are you prepared to grant a warranty of provenance (e.g., the OSL/AFL licenses, and similar "representations" in the MPL and CPL licenses), or do you prefer to disclaim all warranties? Remember that a disclaimer of warranties is not always effective in every jurisdiction, so if you intend to distribute open source software in some countries you may have to accept warranties regardless of what your license says.

  • Also consider your disclaimer of liability. You should consult an attorney to determine your potential liability in all countries in which you intend to do business.

  • Do you want a defense against patent infringement lawsuits? If so, should the defensive strategy terminate only patent licenses (i.e., the Mozilla and CPL licenses) or both copyright and patent licenses (i.e., the OSL/AFL licenses) for patent infringement claims? Is it sufficient to mandate an express condition that the software cannot be distributed if there is a patent infringement claim against the software (i.e., the GPL license)?

  • Do you want your license to be interpreted under copyright law only (i.e., the GPL) or under both copyright and contract law (i.e., almost all other open source licenses)? If the latter, don't forget that it isn't only the license terms but the license formation issues ”offer, acceptance, and consideration ”that must be dealt with.

  • Does the template license you use select a convenient and comfortable jurisdiction, venue , and governing law? If not, ask your attorney what the defaults are in your jurisdiction.

  • Do you want an attorneys' fees provision in your license? Remember that, in most jurisdictions, such provisions apply equally to all parties to a contract. You are usually subject to paying attorneys' fees if you lose a lawsuit under a license with an attorneys ' fees provision regardless of whether you're the licensor or the licensee.

These questions are intended merely to get you thinking about licensing alternatives. Your attorney should be consulted before you actually craft or select a license.

 <  Day Day Up  >  


Open Source Licensing. Software Freedom and Intellectual Property Law
Open Source Licensing: Software Freedom and Intellectual Property Law
ISBN: 0131487876
EAN: 2147483647
Year: 2004
Pages: 166

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net