r2 - 16 Mar 2004 - 10:56:38 - DuckySherwoodYou are here: OSAF >  Projects Web  >  CommunityHome > LicensingTopics > ImplicationsOfPreexistingLicenses
Licensing issues are complex and can be quite abstract. We will use the question of IMAP libraries to bring some of these issues into focus and discuss the implications in a concrete setting.

Right now Ducky is researching existing email libraries (IMAP, SMTP, POP) to help OSAF determine which, if any, are suitable for reuse in Chandler. Obviously, these libraries come with a license. Once Ducky has completed her review and determined the most suitable candidates, we will have a discussion of the licenses under which these candidates are offered and the implications for the Chandler codebase.

Then we can make a decision, including both technical desirability of a library and implications of its license.

Briefly,

  • the BSD is easy, it will allow us to do what we want;
  • the LGPL and MPL allow part of what we want, but provide a more complex world for our commercial licensees
  • the GPL makes our licensing plan very difficult, and outright impossible for some commercial uses

In more detail,

A complete licensing plan involves at least three elements:

  • the licenses governing code written by others
  • the license(s) under which OSAF uses for OSAF releases; and
  • the integration of (1) and (2) into a unified system.

The Chandler plan aims to provide maximum flexibility for OSAF's potential licensees by making Chandler available under both open source/free software licenses and commercial licenses. We also want to own the copyright on the code in our tree (like the FSF, mySQL, OpenOffice? and increasingly Apache; unlike the Linux kernal, Mozilla or early Apache).

We will need to balance these goals with our desire to use code written by others outside the Chandler project*. To the extent we feel it necessary to own or share the copyright, we will need to find incentives for people to transfer some or all of their copyright interest to OSAF. We may be able to do this with some authors, but there will certainly be others who will not agree, or where it is impossible due to the number of contributors. And this could sets a tone for OSAF that may be undesirable. So we will want to evaluate carefully exactly how much of our codebase we need to have the copyright for in order to meet our goals.

To the extent we feel it necessary to be able to license the entire codebase under commercial licenses, we will need to restrict ourselves to third party code licensed under BSD-style licenses, or to develop incentives to persuade others to allow OSAF to include their work in OSAF commercial licenses. So we will want to evaluate carefully which parts of the code must be available under a commercial license, and which other licenses might be acceptable to potential commercial licensees.

For example, if we use IMAP licenses under an LGPL or MPL license, we might be able to say to commercial licenses:

"The vast majority of Chandler code is available to you under the terms of a commercial license. The IMAP libraries are available only under the LGPL [or MPL or whatever]. You'll get all the code from us in one integrated release. You'll need to make sure that if you modify or distribute any of the code governed by the open source license, you need to comply with that license. Obviously, you're not paying us for the value of that code, it's available to you for no charge under the open source license."

If we go this route, we also need to evaluate which licenses are likely to be acceptable to most potential commercial licensees. The GPL is not a likely candidate for this system, due to its inheritance feature.

This is not as easy a system for our potential commercial licensees than one which simply says: Here's our code, use it under the terms of this commercial license. We will need to evaluate how to balance simplicity of commercial licensing with speed and quality of development.

(*It's possible that we'll need to balance these goals with that of attracting non-staff contributors, since some may object to contributing or even sharing with OSAF the copyright on work they have written. However, this model appears to work for the Free Software Foundation and other software projects, and we hope potential participants understand why we want to do this as well.)

Proposed Working Plan

  • Determine if we are going to limit ourselves to code we've written so that we have copyright ownership of the largest possible portion of our source tree. (Mitchell's view: Many, many commercial products include code licensed from other developers, the copyright registration lists this code, and yet still is seen as providing protection. So requiring 100% ownership may not be required for useful copyright registrations. It would be helpful to talk with a copyright litigator on this point.)

  • Determine if are going to limit ourselves to code we've written and BSD style licensed code only to allow us to grant commercial licenses to the entire codebase. Mitchell's view: Limiting ourselves to code we've written or which is available under a BSD style license will add additional work, in some cases in areas in which are not our core value proposition. In suspect the pressure to use high-quality, pre-existing infrastructue code will push us into using some code governed by other licenses. Many commercial enterprises already deal with complex licensing issues, and are capable of coping with a setting where most of the code is govened by one license and a portion by another. However, the number of other licenses must be kept very small, and they must be licenses that are understandable and acceptable to business entities.

  • Assuming we decide we will use code under some license other than the BSD, then we use the following guidelines:

    • Do not use GPL only licenses in the OSAF source tree. If we do so we will be unable to deliver the entire code base to those people to whom we want to give a commercial license.

    • Each use of code governed by LGPL and MPL must be specifically reviewed to determine if the added complexity of the licenses is worth it. Each piece of code included in the tree which can't be included in a commercial license makes life more complex for potential commercial customers.

    • Create a "third party code review committee" to determine value of code vs. license complexity.

  • Maintain an accurate list of the exact code that is governed by the other license(s).

-- MitchellBaker - 25 Jun 2003

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r2 < r1 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.