3

Usually you put your license into a single file called COPYING or LICENSE. However there may be reasons you do not want to do this - let's not discuss them - and therefore you look for alternative ways.

So what about putting the license into the issue tracker? An advantage may be that you can clearly see who did this (the author).

So is this okay from a legal perspective? Is it possibly even superior than putting the license into a file? And should this be done? (You may list other reasons than legal ones here)

This question was arose out of a discussion about the LICENSE file on GitHub. You may have a look there to get some arguments, however please answer this question in an objective way as you should on Stackoverflow. If you want to participate into the discussion please comment on GitHub instead.

rugk
  • 133
  • 4
  • 1
    [Do you have to include a license notice with every source file?](http://programmers.stackexchange.com/questions/125836/do-you-have-to-include-a-license-notice-with-every-source-file) – gnat Feb 02 '16 at 20:04

2 Answers2

10

There is a key difference between an issue tracker and the repository itself:
The issue tracker isn't distributed with the repository

When one downloads the library or does a git clone https://github.com/jsmith/acme, the license that the library and code is distributed under needs to be there. Consider the situation where someone had their code on Google Code, or Source Forge with the license in the issue tracker over there and then migrated the project to github... and there's no hint of a license file any more.

Specifically with GitHub and its culture of forking, one should also look at what one sees when downloading or cloning from a fork. There isn't even a hint of an issue containing the license in the forked code. For that matter, the fork might have enabled its own issues on there and claiming a WTFPL license on it (anyone downloading from the fork and going to https://github.com/sjane/acme/issues/97 hinted at by someone as containing the license in it could see something completely different than the MIT).

The license needs to be distributed with the library and source files. Otherwise there is no license on them and it makes the legal department rather twitchy.

Furthermore, issue trackers aren't tied to a revision. Consider if jsmith later decides to switch from MIT to GPL (as the only author, perfectly acceptable). And now... what's the license? There's one issue here that says its MIT and another one there that says its GPL. If I clone from revision 1, what license is it under? What about if I clone from revision 2?

The only way to resolve this is if the license is part of the distribution itself. Posting it in an issue tracker doesn't actually identify the license that a given revision is under. Nor does posting it in an issue tracker allow me to redistribute the code under the license I (might have) received it under when that issue tracker is gone.

2

It probably depends on how you intend to distribute your software but I expect that it won't be very useful, to say the least.

Normally, free software is distributed as source code archives. (Other projects – or you yourself – might pick those archives up and create “installable” distribution files for their respective package manager from them.) If you distribute your software like that, having the license information anywhere else but placed prominently right in the source archive itself is extremely unhelpful. Essentially, it makes the source archive useless for anybody who is serious about copyright because they have no good way to prove that the files in the archive are the same as in your repository other than checking out the repository directly and making a diff.

Some projects do not make source archives but rather ask people to check out their repository directly. For such a project, it might do less harm to place the license file somewhere else but I still cannot see any advantage of doing this.

From a legal point of view, you won't be likely to shoot yourself into the foot with this approach – that is, unless you count annoying potential users away as shooting yourself into the foot. If I'm not given a license to do X with your software, then I have to assume that it is non-free and I must not do X with it. (Where X is basically anything interesting people want to do with software.) Of course, if you make it unclear what the license of your project is, it might fall back onto you if potential violators can argue that they rightfully assumed that the license was Y when you think that it actually was Z. But unless you create the impression that the license might be Y, nobody must assume this because unlicensed works default to “all rights reserved”.

5gon12eder
  • 6,956
  • 2
  • 23
  • 29