Difference between revisions of "IP Issues Discussion Document"
Jump to navigation
Jump to search
(formatting) |
(formatting) |
||
| Line 23: | Line 23: | ||
It is understood that if there is no single license requirement, then license compatibility will become an issue. The problem arises when you want to use more restrictive code in less restrictive codebases. Certain projects therefore may not be able to share existing code – for example, an MIT-licensed project would not be able to share GPL’d code. This is seen as unfortunate, but necessary to get projects to join (it is highly unlikely that we would ever get agreement on the use of one single “preferred” license). To get around the incompatibility issue, a broadly drafted contributor agreement would permit contributors to be cross-licensed to multiple projects. For example, a committer on a GPL-based project contributes code under the foundation’s standard contributor agreement. This agreement grants the foundation a broad license to distribute the code under an OSI-approved license. If the code is useful for other projects, it could be added to the source tree of another project and made part of that project under its own OSI license. | It is understood that if there is no single license requirement, then license compatibility will become an issue. The problem arises when you want to use more restrictive code in less restrictive codebases. Certain projects therefore may not be able to share existing code – for example, an MIT-licensed project would not be able to share GPL’d code. This is seen as unfortunate, but necessary to get projects to join (it is highly unlikely that we would ever get agreement on the use of one single “preferred” license). To get around the incompatibility issue, a broadly drafted contributor agreement would permit contributors to be cross-licensed to multiple projects. For example, a committer on a GPL-based project contributes code under the foundation’s standard contributor agreement. This agreement grants the foundation a broad license to distribute the code under an OSI-approved license. If the code is useful for other projects, it could be added to the source tree of another project and made part of that project under its own OSI license. | ||
| − | + | === Relicensing === | |
| + | This raises the issue of relicensing. If there is no single preferred OSGEO license, should the foundation have right to relicense a project under a different license? Or should contributors be able to put strings on contributions such as “I hereby contribute this code to the foundation, but with a restriction that the foundation may distribute the code only under the [GPL] [MIT] [other favorite license]”. As discussed at the Chicago meeting, relicensing is often required for legitimate reasons (e.g., Apache 1.0 -> Apache 2.0, or Mozilla tri-licensing due to incompatibility), but there was a fear that relicensing could also be done for political reasons (i.e., a move from GPL to MIT, or vice versa, being the obvious flashpoints). | ||
| − | + | # So the big issue for relicensing is: how do you structure contributions such that relicensing them for “legitimate” reasons isn’t made prohibitively difficult (i.e., have to track down every contributor to get their consent to relicense), yet at the same time ensure that a rogue foundation can’t relicense for “illegitimate” reasons. | |
| + | # An effective compromise is to require that contributions to a project be made without licensing strings attached (i.e., under a broad contributor agreement), yet rely on a supermajority (or unanimous) vote of the board and/or the current project’s PSC members to approve a relicensing decision. This would eliminate the need to track down each and every current and former committer, but would ensure that there be an overarching consensus of the foundation board and current project stakeholders before a relicensing decision can be effected. | ||
| − | + | === Inbound Contributions === | |
| + | There was universal concern among foundation members about a loss of control when code is “contributed” to the foundation. Thus, an IP policy that grants the foundation sufficient rights in code but preserves developers’ rights to contributions is strongly desired. | ||
| − | + | * The right to fork provides ultimate control. The reality of open source is that the foundation can only “control” the project if the dedicated committers stay on board and drive the project forward. All open source licenses inherently grant the right to “fork” the project. If too much control is asserted by the foundation and the committers disagree with the direction, they can create a fork by taking the code and setting up shop elsewhere. While this is disfavored, it is the ultimate check on the system. Thus, the foundation governance structure should empower the individual project steering committees with directing the relevant project, rather than micromanagement by the foundation board. There is widespread agreement on this point. | |
| + | * Contributor Agreements. The other way to provide comfort that contributing developers retain rights in their contributions is to avoid the imposition of a requirement that copyright be assigned outright to the foundation. While copyright assignment is desirable for relicensing (the copyright owner can always change the terms of its outbound license) and for enforcement of the license (only the owner of a copyright can sue to enforce the copyright), almost everyone is opposed to this. For one thing, it may not be practical for some projects that would not be able to locate all contributors and have them agree to assign their copyright to the Foundation. Another approach is the one taken by Apache, which is to accept only a broad license (not a copyright assignment). The downside is that enforcing the copyright may be made more difficult because it would require joining all committers (the copyright holders) in an action to enforce the license. Of course for some licenses such as BSD or MIT which don’t really impose any substantive obligations on licensees, enforcement of the licenses is really a moot point. I would recommend the Apache approach of a broad license rather than a copyright assignment. | ||
| + | * What Standards of Due Diligence Are Required to Accept Code Contributions? A closely related question is: what level of code “purity” should be required before an existing project can be admitted into the foundation? Apache has fairly stringent requirements: all committers to a project (and their employers, if applicable) must sign a contributor agreement and all code must be ASL-compatible. Eclipse is even more rigorous, requiring that committers make representations about the provenance of the code and the code is run through an auditing scan tool. The foundation assumes some legal risk if it accepts a project where the provenance of the code is not understood and all committers (known and unknown) haven’t granted the foundation the necessary rights. This is less of a problem for MapGuide Open Source (Autodesk is the sole copyright holder in the code), and may not be a problem for some projects with a known committer population like OGR/GDAL or PostGIS, but could be a problem for MapServer, and will likely be a problem for longer term projects like GRASS. If all contributors can’t be tracked down and proper contributor agreements obtained, the foundation board will need to assess the risk of IP claims before admitting such a project into the foundation. | ||
| + | * What About Third Party Code Dependencies? Some projects have dependencies on third party code and include such code in their distributions. For example, suppose MapGuide Open Source, an OSGEO project, includes code from the imaginary “SuperFoo library project”, which is non-OSGEO open source code freely available for download on sourceforge and licensed under the MIT open source license. It is not practical to find the authors of SuperFoo and ask them to sign an OSGEO contributor license so that the code can be included in MapGuide Open Source. Instead, we would look at the terms of the MIT license and conclude that it is compatible with MapGuide’s LGPL license terms. The MapGuide distribution containing SuperFoo would need to reference the MIT-licensed code and comply with the terms of that license, but it would not be necessary to have contributor licenses on file from the SuperFoo authors. Of course it would be up to the relevant PSC to determine whether the inclusion of third party code in the OSGEO project was warranted. Anytime you include code “not invented here” you run a somewhat higher risk of IP issues, but of course this risk is often outweighed by the practicality of not having to invent a new SuperFoo when it already exists for free under favorable licensing terms. | ||
| − | + | == Other Reading == | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | Other Reading | ||
* [http://www.eclipse.org/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf Eclipse IP Policy] | * [http://www.eclipse.org/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf Eclipse IP Policy] | ||
* [http://incubator.apache.org/incubation/Incubation_Policy.html/ Apache Incubation Policy] | * [http://incubator.apache.org/incubation/Incubation_Policy.html/ Apache Incubation Policy] | ||
Revision as of 06:11, 17 February 2006
Background
OSGEO is to be an umbrella foundation for Open Source projects related to web mapping/geospatial software and data. The goal is to formalize the establishment of a legal entity that will act as the repository for a broad range of existing and future geospatial Open Source projects. An important consideration is that although these projects occupy a common substantive area at a high level, each has its own unique history, different levels of maturity and community involvement, and licensing philosophy. This historical fact will inform and influence many of the decisions regarding IP licensing, code diligence and contribution policies, as well as project and foundation governance.
Naming/Branding
The foundation name will be The Open Source Geospatial Foundation, or OSGEO for short.
Trademark Registration
In order to commence protection of the mark, the foundation should begin affixing a “TM” on OSGEO whenever it is used as a brand. Registration of the OSGEO mark with the USPTO (and perhaps in other key jurisdictions) may be advisable if budget permits.
Logo
Similar to the Apache feather, the Debian swirl, the Gnome footprint, etc., the foundation can create a stylized OSGEO logo, and obtain trademark protection over the logo.
Trademark Policy
There was general consensus that establishing a “brand” for the foundation – a la Apache, Mozilla, Debian, Gnome – was desirable. However, there was reluctance to have a strict trademark policy that would require the foundation to play the “bad guy” and enforce the mark against small developers or users. Thus, the desire is for an extremely liberal usage policy. Rights could be broadly granted to those using or developing on foundation code, and reserve enforcement efforts against those passing non-foundation code off as “OSGEO brand” code. We could also create a special “OSGEO Associate/Friend” logo for use only by Associate Members/“Friends of the Foundation”.
Project name Trademarks
It may be desirable as well to have the foundation act to protect the names of individual projects as well. Some names (MapBender) are stronger than others (MapServer) from a trademark perspective, so these would have to be evaluated on a case-by-case basis.
Outbound Licensing
The many projects being evaluated for OSGEO are offered under a broad spectrum of licenses. There are many MIT-licensed projects, a handful of LGPL projects, and a couple of GPL projects. Each project has its own reasons for choosing its particular license based on the philosophy of the main committers to those projects, or simply due to historical accident. Thus, there is a general consensus that OSGEO should not, and indeed cannot, require that all foundation-licensed code be offered under a single preferred license. Rather, projects would be able to select their own licenses, provided that every project must use a license that meets the open source definition and is certified by the Open Source Initiative.
License Compatibility
It is understood that if there is no single license requirement, then license compatibility will become an issue. The problem arises when you want to use more restrictive code in less restrictive codebases. Certain projects therefore may not be able to share existing code – for example, an MIT-licensed project would not be able to share GPL’d code. This is seen as unfortunate, but necessary to get projects to join (it is highly unlikely that we would ever get agreement on the use of one single “preferred” license). To get around the incompatibility issue, a broadly drafted contributor agreement would permit contributors to be cross-licensed to multiple projects. For example, a committer on a GPL-based project contributes code under the foundation’s standard contributor agreement. This agreement grants the foundation a broad license to distribute the code under an OSI-approved license. If the code is useful for other projects, it could be added to the source tree of another project and made part of that project under its own OSI license.
Relicensing
This raises the issue of relicensing. If there is no single preferred OSGEO license, should the foundation have right to relicense a project under a different license? Or should contributors be able to put strings on contributions such as “I hereby contribute this code to the foundation, but with a restriction that the foundation may distribute the code only under the [GPL] [MIT] [other favorite license]”. As discussed at the Chicago meeting, relicensing is often required for legitimate reasons (e.g., Apache 1.0 -> Apache 2.0, or Mozilla tri-licensing due to incompatibility), but there was a fear that relicensing could also be done for political reasons (i.e., a move from GPL to MIT, or vice versa, being the obvious flashpoints).
- So the big issue for relicensing is: how do you structure contributions such that relicensing them for “legitimate” reasons isn’t made prohibitively difficult (i.e., have to track down every contributor to get their consent to relicense), yet at the same time ensure that a rogue foundation can’t relicense for “illegitimate” reasons.
- An effective compromise is to require that contributions to a project be made without licensing strings attached (i.e., under a broad contributor agreement), yet rely on a supermajority (or unanimous) vote of the board and/or the current project’s PSC members to approve a relicensing decision. This would eliminate the need to track down each and every current and former committer, but would ensure that there be an overarching consensus of the foundation board and current project stakeholders before a relicensing decision can be effected.
Inbound Contributions
There was universal concern among foundation members about a loss of control when code is “contributed” to the foundation. Thus, an IP policy that grants the foundation sufficient rights in code but preserves developers’ rights to contributions is strongly desired.
- The right to fork provides ultimate control. The reality of open source is that the foundation can only “control” the project if the dedicated committers stay on board and drive the project forward. All open source licenses inherently grant the right to “fork” the project. If too much control is asserted by the foundation and the committers disagree with the direction, they can create a fork by taking the code and setting up shop elsewhere. While this is disfavored, it is the ultimate check on the system. Thus, the foundation governance structure should empower the individual project steering committees with directing the relevant project, rather than micromanagement by the foundation board. There is widespread agreement on this point.
- Contributor Agreements. The other way to provide comfort that contributing developers retain rights in their contributions is to avoid the imposition of a requirement that copyright be assigned outright to the foundation. While copyright assignment is desirable for relicensing (the copyright owner can always change the terms of its outbound license) and for enforcement of the license (only the owner of a copyright can sue to enforce the copyright), almost everyone is opposed to this. For one thing, it may not be practical for some projects that would not be able to locate all contributors and have them agree to assign their copyright to the Foundation. Another approach is the one taken by Apache, which is to accept only a broad license (not a copyright assignment). The downside is that enforcing the copyright may be made more difficult because it would require joining all committers (the copyright holders) in an action to enforce the license. Of course for some licenses such as BSD or MIT which don’t really impose any substantive obligations on licensees, enforcement of the licenses is really a moot point. I would recommend the Apache approach of a broad license rather than a copyright assignment.
- What Standards of Due Diligence Are Required to Accept Code Contributions? A closely related question is: what level of code “purity” should be required before an existing project can be admitted into the foundation? Apache has fairly stringent requirements: all committers to a project (and their employers, if applicable) must sign a contributor agreement and all code must be ASL-compatible. Eclipse is even more rigorous, requiring that committers make representations about the provenance of the code and the code is run through an auditing scan tool. The foundation assumes some legal risk if it accepts a project where the provenance of the code is not understood and all committers (known and unknown) haven’t granted the foundation the necessary rights. This is less of a problem for MapGuide Open Source (Autodesk is the sole copyright holder in the code), and may not be a problem for some projects with a known committer population like OGR/GDAL or PostGIS, but could be a problem for MapServer, and will likely be a problem for longer term projects like GRASS. If all contributors can’t be tracked down and proper contributor agreements obtained, the foundation board will need to assess the risk of IP claims before admitting such a project into the foundation.
- What About Third Party Code Dependencies? Some projects have dependencies on third party code and include such code in their distributions. For example, suppose MapGuide Open Source, an OSGEO project, includes code from the imaginary “SuperFoo library project”, which is non-OSGEO open source code freely available for download on sourceforge and licensed under the MIT open source license. It is not practical to find the authors of SuperFoo and ask them to sign an OSGEO contributor license so that the code can be included in MapGuide Open Source. Instead, we would look at the terms of the MIT license and conclude that it is compatible with MapGuide’s LGPL license terms. The MapGuide distribution containing SuperFoo would need to reference the MIT-licensed code and comply with the terms of that license, but it would not be necessary to have contributor licenses on file from the SuperFoo authors. Of course it would be up to the relevant PSC to determine whether the inclusion of third party code in the OSGEO project was warranted. Anytime you include code “not invented here” you run a somewhat higher risk of IP issues, but of course this risk is often outweighed by the practicality of not having to invent a new SuperFoo when it already exists for free under favorable licensing terms.
Other Reading
- Eclipse IP Policy
- Apache Incubation Policy
- Mozilla Trademark Policy
- Debian Logo Use Policy
- Chapter 2 (Intellectual Property) of Larry Rosen’s Open Source Licensing book. I would particularly direct your attention to the section entitled “Assigning Ownership”, which is instructive in the context of the OSGEO Contributor Agreement.