Support for multiple licenses

[pchaigno]

It looks like, currently, Licensee stops after the first license it finds.
For instance in puppet-textmate-bundle/puppet-textmate-bundle, it fails to recognize the MIT license in the LICENSE file and it doesn't look for the GPL license in the COPYING file.

@benbalter Is it something you plan to support in the future?

[benbalter]

It'll take a bit of a refactor/abstraction, but something to look into, especially if the package manager file makes the relationship explicit. Added to a new v6.x milestone as it'll be a breaking change.

[benbalter]

Just dropping some notes here:

• Will need to parse licenses fields in package manager files
• Should split ProjectFile into LicenseFile and PackageManagerFile
• matched_files should return LicenseFiles and PackageMangerFiles
• licenses should return an array, licence should return the most confidence license across matched_files
• Will need to parallelize things to avoid a performance hit via levenshtein

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[andrew]

@benbalter is this still of interest as a contribution? Looks like the wontfix label was added by the bot rather than someone saying "we don't want to do this"?

[CxRes]

Could the good people here evolve a strategy/best practice for dealing with multiple licenses (using spdx might be a part of the solution). My specific use case is a website where I want to licence code with an open source licence and content as CC. Ideally, I would like Github to pick up this information as they are really about two separate things.

[mlinksva]

For instance in puppet-textmate-bundle/puppet-textmate-bundle, it fails to recognize the MIT license in the LICENSE file and it doesn't look for the GPL license in the COPYING file.

LICENSE is has higher priority than COPYING. But in this case, LICENSE doesn't contain a license, it contains a GPL notice corresponding to COPYING. I think the reporter must've seen a short text and assumed it was MIT. 😀

#114 says in the case of multiple license files we should detect none, so I think wontfix is accurate.

@CxRes different licenses applying to different material in a project is a different issue. AFAIK there isn't an existing machine-readable solution. SPDX can document per-file licenses, which could correspond to code under one license and content under another, but that conceptual split would not be explicit. At this point licensee finds project-level licenses; per-file or per-type would be a big expansion of scope.

(This doesn't stop you from documenting your projects to make their licensing situations as clear as possible...some reasonable options including (a) using an open source license for code and content, (a') doing (a) but offing content under an additional license where the content is published in its non-source form, (b) put license for dominant type of material in LICENSE and note in README that other material is under different terms...)

[CxRes]

@mlinksva Thanks for the suggestions. Since I am licensing my code as MPL, which uses very strict definitions, (a) & (a') imho don't seem proper. Approach (b) seems much more reasonable. It is similar to what Apache uses - they put all copyright and license info in a NOTICE file with LICENSE file only carrying the Apache licence (This might be even better because it isolates from other content of a typical README and contains rich information about copyright, multiple licensing and even the included libraries). However, there seems to be no consensus on what might be a good way to manage this.

What could perhaps be nice is if Licensee could, apart from examining the LICENSE file/files, also parse such a NOTICE file for just SPDX strings - SPDX suggests the format SPDX-License-Identifier: <Licence Identifier> which could be prefixed/suffixed with the nature of material/intent. If the last part is omitted it may be assumed specified licence is the main one for the repo. This should also be simple to implement as it is nothing but a simple regex, that is to say, something with limited scope. It can still continue to fail if multiple licences are included in a non-SPDX complaint format or where intent is unspecified for more than one license string. (A similar strategy could also be used for multiple LICENSE files but that is another post). This is just a strawman (so please be gentle) but what I am trying to say is that multiple licenses can be dealt in a simple way, provided we can evolve a community standard. You guys (as Github employees) seem to be in a better position (than me!) to do so....

(I think my use case is not that uncommon at least in two circumstances: (1) where docs are shipped with the code and (2) websites).

Sorry about the rather long post!!!!!! :)

[benbalter]

WIP fix over in #203.

[CxRes]

Thanks for bringing in multi-license support. As a next step, please consider my suggestion for license specification and detection where purposes for each is specified (see above).