Short Background on COIN-OR Foundation Legal Policies
The COIN foundation is currently at a crossroads, faced with the difficult question of what policies to put in place in order to ensure that the legal pedigree of codes in the repository is such that we enable their use by those concerned about legal exposure and yet we do not impose an undue burden on those who wish to contribute. There is an obvious tradeoff underlying this question that has been hard for the Foundation's board to come to grips with. On the one hand, the foundation's guiding philosophy has always been one of openness. Among our most fundamental goals is to lower barriers to entry for users of operations research technology. On the other hand, we must be cognizant of the legal realities of maintaining a repository of open source software. For our codes to be useful to those who are averse to the legal exposure that comes with the employment of open source codes, we must be aware of the necessity to keep a clean legal bill of health and to do our best to ensure that the legal pedigree of codes in the repository is transparent, if not of verifiably high quality.
Our present policy is a "one-size-fits-all" proposition. For every code that is added to the repository, we try to determine, with the contributor's help, who the legal owner is. We require a statement from that owner acknowledging that the code is legally licensed as open source. We require statements from all contributors that they understand the legal status of their contribution and the legal implications of what they are doing and that they will respect all applicable intellectual property laws. Once a code is in the repository, it is up to the project manager to track contributions and make sure that the legal pedigree of the code is maintained. All codes in the repository have the same legal status. There is no differentiation with respect to the amount of due diligence that was performed to determine the code's ownership or the quality of the procedures in place to track on-going contributions. This is clearly a compromise. On the one hand, these procedures are somewhat more burdensome than many contributors in the academic community would like and they make the barrier to entry for contributors somewhat high. On the other hand, the bar is perhaps lower than some corporate entities would like in order to feel comfortable using COIN code in commercial products.
Proposed Change
We are now considering a change that we believe is a better compromise and would streamline the contribution process, while still providing a clear picture of the legal pedigree of codes in the repository. The basic concept behind this proposal is for the foundation not to act as a gatekeeper, only allowing codes in the repository if they reach a certain legal standard, but to act as an assessor, providing clear information to users on each project regarding what its legal pedigree is and what steps have been taken to ensure that it is legally licensed. In this way, each user would be able to make an informed decision about whether to use a given code or not. At the same time, project managers would be encouraged by market forces to improve the legal pedigree of their code in order to ensure wide usage.
This vision will allow COIN to continue as a completely open community, accepting most projects that want to be a part of the repository. Upon contribution, the legal and technical merits of the project would be assessed in some fashion, but this would generally not be a criteria for acceptance or rejection. Rather, each project will receive "grades" in both areas and these would then be prominently displayed in order to help users determine which projects are appropriate for their purposes. These assessments could be improved over time and project managers would be encouraged to do so mainly because of the perceived benefits, not because of Foundation policy. This system provides significant benefits to those who are willing to improve the quality of their projects, without having to exclude other participants from existing outside of this system.
This system is already in place for technical merits. Each project gets a score for "maturity" on a scale of 1 to 5 based on compliance with a list of technical "best practices" listed here. This provides a potential user with a clear snapshot of the level of maturity of a project. We are proposing a similar checklist on the legal side, but probably without the single numerical assessment score. The current list of items that would be on the checklist and prominently displayed for each project are below.
We believe that the advantage of this approach is that it embodies the inclusive philosophy that is espoused by the open source community in general and encourages those who would otherwise be left on the outside to be active in the community and to contribute in whatever way they can. This inclusive philosophy is a defining aspect of the open source movement and seems to be part of what motivates many of the volunteers who work for COIN. It would also help us draw the support of other organizations, such as INFORMS and the National Science Foundation, and makes it easy for us to maintain our tax status as a non-profit. Improvements in the quality of codes in the repository would happen naturally due to market forces, preserving free choice among the project managers while still accomplishing the goal of commercial-grade code.
The downside of this approach is that there is the perceived danger that by mixing codes of differing legal and technical qualities and not strictly enforcing standards, the overall quality and usefulness of codes in the repository could be lower that it would otherwise be. There is also a perceived danger that projects that could otherwise achieve the high standards of the current system would not have enough incentive to do so under the proposed system. We believe this is balanced out by the advantages outlined above, but we would like to hear your opinion!
Proposed Legal Checklist
Below is a proposed checklist that prospective users of a project would be able to consult to quickly determine the degree to which the project has attempted to track the provenance of its code base. The initial mandatory items are required to demonstrate that the Project Manager and the Foundation have made a good-faith effort to avoid IP violations. The Foundation will keep on file the legal documentation that it receives, but it does not have the ability to verify the documentation or to perform code reviews; this is left to prospective users.
In general, project managers who would like to see their project adopted for commercial use will be encouraged to maintain the detailed records and to take care to carefully document code provenance from the project's initiation. Some effort is required to maintain this information on an ongoing basis, but it's much less than the effort required to document code provenance after the fact.
| mandatory | OSI approved open-source license for all project content. LICENSE file distributed with the project's code, along with any other information required by the chosen license. |
| mandatory | AUTHORS file listing authors only, where authorship is determined as per the GNU guidelines for a legally significant contribution. AUTHORS file distributed with the project's code. An email address for each author would be nice. |
| mandatory | Electronic plaintext CSOL (Contributor's Statement of Ownership and Licensing) (or equivalent) on file for project, according to the Project Manager. CSOL held online by the Foundation but not publicly accessible. |
| mandatory | Electronic plaintext CSRO (Contributor's Statement of Respect for Ownership) (or equivalent) on file for Project Manager and all project members with commit permission (`committers'). CSRO held online by the Foundation by not publicly accessible. |
| strongly recommended | Electronic plaintext CSRO on file for each author. CSRO held online by the Foundation but not publicly accessible. |
| strongly recommended | Electronic plaintext OCL (owner's confirmation of licensing) (or equivalent) on file for each owner (as listed in the CSOL). Where the owner is a corporation, this document must include the statement that the corporation is aware of and permits the release of the software under the specified license, and must specify the individual, in the supervisory chain above the contributor, who gave permission for the release. OCL held online by the Foundation but not publicly accessible. |
| optional | AUTHORS file listing authors and contributions as per the GNU guidelines for a legally significant contribution and for recording contributors. |
| optional | For all committers who are employed or performing services for a third party as an independent contractor, permission from the employer or third party for the individual to contribute code. This can be a blanket permission, or permission to contribute to a particular project under a particular license. |
| optional | A project IP log containing details of each contribution to the project, including the author's name, the path to the relevant file(s) in the repository, the ticket number (where applicable), the number of lines of code, the committer, and a description (for a new contribution or a contribution addressing multiple tickets). |
| optional | For significant contributions, documentation for the contribution containing the name and contact information of the contributor, name and contact information for individuals who will develop and/or support the contribution, the name of the committer, and details of the contribution. Details of the contribution should include licensing, lines of code and documentation, a brief description of the package and its algorithms, any third-party dependencies or use of code taken from other sources, use of cryptography, patent encumbrances, and any other unusual circumstances related to the contribution. |
| optional | Hardcopy or electronically signed CSOL, CSROs, OCLs, and employer contribution permissions on file. For corporate owners, the individual signing an OCL or employer contribution permission must be an individual authorised to provide appropriate consent on behalf of the corporation. |
Notes on the Checklist
- Items listed as mandatory must be provided before a project will be hosted on the COIN-OR repository.
- `Permission from the employer could be in the form of specific permission to contribute to COIN-OR or a specific project, or a general permission for release of information/intellectual property documentation from the employer. It could also potentially be in the form of an assignment of ownership, copyright or stewardship to an individual to proceed as they see fit with the contribution(s).
- The Eclipse guidelines for a Project IP Log are one example of how to maintain a detailed project IP log. For projects attempting to maintain this level of documentation, it is strongly recommended that you enforce a rule that all contributions feed through Trac or an equivalent system that provides an archival record for the contribution and any ensuing discussion. Repository commit records in general do not support this level of detail unless committers are careful to include this information in the commit comments.
- The threshold for 'significant contribution' must be set by a project. Size is not the deciding factor, rather, a combination of size and algorithmic significance. With respect to size, the Eclipse project sets a threshold of around 250 lines for the total contribution (code, documentation, and any other infrastructure). This is not the same as the threshold for 'legally significant contribution', which denotes ownership (a copyrightable contribution) and can be considerably lower (as small as 15 lines in the GNU guidelines).
- `Hardcopy or electronically signed' is interpreted to include faxed hardcopy and scanned images.
- Note that in many corporations only someone with authority specifically delegated by the corporation can sign any document of any legal bearing without serious repercussions.
Availability of Legal Documents
Each project will make publicly available a listing of the legal documentation on file for the project according to the above checklist. On request, the Secretary of the Foundation will make available a list of documents and contact information sufficient to allow licensors to be contacted directly for verification of legal documentation. Copies of the original documentation will be made available by the COIN-OR Foundation only where the original licensors are unresponsive or have specifically requested the Foundation to provide copies of the documentation in response to such requests.Further Items for Consideration
Some other ideas/concepts under consideration:- Listing whether all dependencies are also open-source
- Listing whether all dependencies are open-source and available under the same (or compatible) license
- Listing whether the same (or better) level of legal documentation is available for any (open source) software dependencies
- A legal checklist or score for dependencies listed within the main legal checklist
- Listing differences in legal checklist between main project and its dependencies
- Making electronic legal documentation available for download
- Making scans of hard copy paper work available for download