Declaring multiple licences in a GitHub project

Question

For years, I've been a great fan of putting licences on things shared online to make it easier for others to determine if and how they can reuse said things. Before GitHub began to gently 'push' its users to include LICENSE files with their repos, I didn't really know how to best do this with code – particularly code publicly shared on GitHub! – but I've tried to make good use of LICENSE files ever since.

I'm now in the situation where I've worked on a small project with some other folks, which requires mention of several licences (due to 3rd-party code & libraries as well as non-code files). While my partners go about the issue rather 'sloppily' – it was suggested I 'just put the code online as-is, no-one will care' –, I'd rather do this properly. Problem is: I don't know how one is supposed to make mention of several (different) licences on GitHub.

I've seen several different solutions on GitHub, which is why it's hard for me to judge if this answer to a slightly different question is authoritive. What I'd like to know is which of the following – if any – is the most common, or if there are other, additional ways of doing this.

1. Create one single LICENSE file and put the descriptions of all the different licences in there. (Questions: Should they be put in a particular order? Would I start off the file with mention of the names of all the licences contained within, for a better overview)?
2. Create one LICENSE file per licence used and name them LICENSE.md, LICENSE.LibNameA.md, LICENSE.AssetsB.md etc. as suggested in the linked answer. (Question: The naming would be based on project names? Not licence names? If I used more than one licence for self-contributed material, would I mention them all in the 'main' LICENSE.md? If not, what would I do instead?)
3. Create two LICENSE files: one listing the licence(s) for the 'main' contents, i.e. all code/assets oneself has created; one for all 3rd party materials. (Questions as above: is there a particular naming scheme one would use, and order in which one would list the 3rd party materials?)

Lastly, if I understood the various GitHub explanations and projects regarding their Licenses API correctly, only the 'main' LICENSE file will be taken into consideration when determining a repo's licence (though I haven't been able to figure out which licence would be picked if several were mentioned).

Answer 1

You can use any mechanism to include those licenses that you like, as long as it becomes clear to a visitor of your project which license is applicable to which portion of the project.

My preference would be:

• Put each third-party library that you use in a directory of its own. This directory should contain all files that are part of the library's distribution, including the license and readme files.
• In your own license file, refer only to the license of your own code
• In the readme file of your project, mention which third-party libraries you use and which license each library is distributed under. For full license details, refer to the license file in the library's directory.

Answer 2

In a presentation of the SPDX creators (slide 12), it is very clear:

Contents of LICENSE:

Apache-2.0 OR GPL-2.0-or-later

You could add two additional LICENSE files then: LICENSE.Apache-2.0 and LICENSE.GPL-2.0-or-later.

In all cases, the README.md should contain a a SPDX license identifier:

SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later

You can do it like that:

## License

This work is dual-licensed under Apache 2.0 and GPL 2.0 (or any later version).
You can choose between one of them if you use this work.

`SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later`

Note that Apache-2.0 OR GPL-2.0-or-later and Apache-2.0 AND GPL-2.0-or-later makes a big difference. The former means that the user can choose between both (which is the regular case!) and the second one denotes that the user has to comply to both licenses. See also multi licensing on Wikipedia.

Note that I am using the new (as of 2017-12-28) SPDX License List 3.0 here. The versions of 2017 had GPL-2.0 as identifier for GPL 2.0, but it was not clear whether that meant "GPL 2.0 only" or "GPL 2.0 or any later version".

Answer 3

I did eventually contact GitHub support directly with regard to my question and they said it was OK to quote them if I made clear their answers were only meant as suggestions, not recommendations.

Our team doesn't have any particular recommendations to offer at this time, but we'll make sure to ask around and update you if we have anything else to share!

Their original reply had the following to offer:

One suggestion is to have one LICENSE file for the majority of your code, and add the text of the licenses for the rest of the 3rd party materials in your README file.

Another way is for each path to have its own LICENSE file when it makes sense. So if, for example, your repository has the following path: libs/awesome-lib-v2/ you could have libs/awesome-lib-v2/LICENSE.

In the latter case, you may want to mention that in the README file and/or the LICENSE file in your root.

You may also consider just using one LICENSE file in the root of your repository, and add subsections for any 3rd party material, code, et cetera.