License and copyright

[Philippe Pinard]

Hi all,

This is a general discussion on selecting the license and copyright ownership handling for the openMicroanalysis project. Please feel free to reply and share your opinions.

License

The license defines how the source code of the project can be used, shared, modified, distributed, etc. Potential candidates for open source projects:

• Public domain (no license)
• MIT / BSD (Free or simplified)
• Apache
• GPL
• LGPL

Some information how to choose:

http://choosealicense.com/

http://producingoss.com/en/license-choosing.html

License used by other microscopy related projects:

• DTSA-II: Public domain
• openMicroscopy: Dual license, GPL and commercial
• ImageJ: Original version has no license, new version (v. 2) is under Simplified BSD
• hyperspy: GPL

Copyright

By law, the author of any piece of code automatically owns its copyright. In a open source project, this creates the problem that different pieces of code have different author(s). Managing several copyrights can become difficult, especially to enforce the license and protect the "open source nature" of the project. More reading at http://producingoss.com/en/contributor-agreements.html and https://www.softwarefreedom.org/resources/2008/foss-primer.html#x1-110002.3 (Section 2.3). From what I can understand, there seem to be three options

1. Authors keep their copyright (i.e. no need to do anything)
2. Collecting contributor license agreement. Author gives the right to the project to use their contribution.
3. Collecting copyright assignment. Author gives his copyright to the project.

Philippe

[Micah Eastman]

In my view, one of the most important considerations for determining the appropriate license would be how it is intended to be used by commercial entities. Is it an objective for the project to be adopted by commercial vendors? It seems that it should be if the objective of the project is to have transparent quantitative methods deployed as widely as possible, rather than to make transparent quantitative methods as widely accessible as possible.

For the sake of making the methods as accessible as possible, the licensing option is quite open. A project of this type is typically implemented by end-users and front-end software often evolves (sometimes separately) to expand the end-user base. For the wide deployment mission, there must be some consideration for the commercial interests. To this end, I think GPL is likely too restrictive based upon the definition and requirements for "derivate works." As per some of the discussion yesterday at the M&M forum, there isn't much hope that vendors will want to release the source to their software. If my understanding of the LGPL is correct, the "derivative works" definition is less rigid and an LGPL library could be loaded by commercially licensed software without concern. The methods in the library could be used by closed software, while still requiring that any modifications to the library be released. At least this is my understanding of these licenses.

Also, as per the point of copyright, I think the transfer of copyright to the project is the most sensible and least entangling model (and likely the most expected one for incoming developers). However, I don't know that this is necessarily the case for someone who wishes to open/distribute portions of their code which is already existing in some commercial software.