25

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).

  • 2
    So have a README and one or more LICENSE files then. This isn't rocket science. – Robert Harvey Dec 12 '15 at 0:50
  • 4
    Regarding the linked page: it doesn't have anything to do with the distribution of license files, it has to with GitHub's Licenses API which determines/reports back on a repo's licence. As I was asking about licencing/the use of LICENSE files on GitHub specifically, not open source or git in general, the way an open source project is 'portrayed' to be licensed on there is relevant too. 'This isn't rocket science' isn't particularly helpful, btw., esp. not in the context of my GitHub-focussed question. – Kay Dec 12 '15 at 0:52
  • 2
    I might suggest that your README has a section on licensing, simply stating that there are multiple licenses and informing for each license, the name of the LICENSE file it is in? – Erik Eidt Dec 12 '15 at 0:55
  • 3
    @immibis I'm aware of that and it's not at all what my question was about. I was specifically asking for an answer regarding 'whichever way makes most sense for humans' (on: GitHub). – Kay Dec 12 '15 at 10:13
  • 3
    @immibis: "No compiler will read it" - the issue is that strictly speaking, this is not true for Github. Github does use an automatic tool to determine "the" license applied to the contents of the repository. The name of the thusly determined license will then be displayed in the title bar of the repository, along with some more very general information that provide visitors with a basic impression of the project (e.g. number of contributors and releases). – O. R. Mapper Nov 1 '17 at 23:28
14

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.
  • 1
    How would you handle your own LICENSE file in the case of dual licensing of own contents in this scenario? I.e. if you used different licences for different parts of the project (code vs. media files) or if you wanted to distribute your code under two (or more) different software licences? Putting additional info in the README makes a lot of sense and is what I'd do too, but I'm particularly interested in how to deal with LICENSE files on GitHub (which, in my eyes, are encouraged to give visitors/viewers of the project a quick overview). – Kay Dec 12 '15 at 10:34
  • 1
    If (portions) of my own code are dual-licensed, I would add two (or more) license files to the project, one for each license, and make it clear in the readme file which license applies in which case. – Bart van Ingen Schenau Dec 12 '15 at 12:34
  • 1
    Bart, thanks for sharing how you'd do it – that's a lot more helpful than some of the comments I got. :) I've meanwhile actually contacted GitHub about it and will leave this question open for now in case anything comes out of that. – Kay Dec 13 '15 at 13:41
  • 2
    When you get an answer from Github, please post that information as a self-answer to this question. – Bart van Ingen Schenau Dec 13 '15 at 13:44
  • 1
    I definitely will if it's ok with them as it might be interesting to know for others as well! – Kay Dec 13 '15 at 13:47
11

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 is 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".

4

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.