Why do I have to keep my open source software license in the root?

Question

Nearly all open source software licenses require (or at least lawyers generally suggest they require) users to include the full license in the root of the project that they are protecting.

One lawyer I spoke to suggests this is a legacy of the CD age, when it was necessary that a full license be included in a jewel case.

But today, we're living in the cloud age. Why can't I, for instance, simply host the full license at my website, and include the title + URL of that license in the header of my source files?

Bonus: If it's generally agreed that established licenses must be kept intact in the root, why hasn't the OSI of FSF approved a license that you can refer to by URL, and what is keeping someone from creating that license?

Answer 1

From the GPL FAQ (but the advice is applicable to all licenses):

Why does the GPL require including a copy of the GPL with every copy of the program?

Including a copy of the license with the work is vital so that everyone who gets a copy of the program can know what his rights are.

It might be tempting to include a URL that refers to the license, instead of the license itself. But you cannot be sure that the URL will still be valid, five years or ten years from now. Twenty years from now, URLs as we know them today may no longer exist.

The only way to make sure that people who have copies of the program will continue to be able to see the license, despite all the changes that will happen in the network, is to include a copy of the license in the program.

(emphasis mine)

The moment the site hosting you license goes down or changes its URL paths, people who have copies of your software can no longer verify what rights they may safely exercise. Suppose even that you could somehow guarantee that that exact URL will be forever online: the ability for users to verify that their use of your software is legal still depends upon the ability to connect to that particular URL. While this requirement may not onerous in your particular city/country/planet, it may be onerous elsewhere. You should not impose this requirement, especially when the workaround (including the full license text) is trivial.

You might answer this complaint by saying, "So what? If the URL does go down or is not accessible, an unambiguous descriptor like 'GNU GPL v3' should be sufficient. Full-text copies of the GPL are plentiful; users can look up the license themselves." A few problems immediately spring to mind:

1. This doesn't generalize to license identifiers that are less clear (the phrase "BSD license" comes to mind).

2. This doesn't generalize well to licenses that are less common or have been customized ("GPL with linking exceptions" comes to mind: which linking exceptions?). How common does a license need to be before it's reasonable to expect a user to find it reliably by name?

3. This still requires users to have an Internet connection, which may not be the case, even if they had a connection at the time they got the software. (And they may not have had Internet access when they got the software: "the CD age" has not yet ended in many parts of the world. As an additional case, consider national populations that have widespread Internet access but censor large parts of it.) A consequence of freely-redistributable software is that a recipient may not receive a copy of your software directly from you or through a distribution channel you originally anticipated.

One final argument against license links is noted by MichaelT's comment below: it could allow you to dynamically, retroactively change the license. This could be done intentionally, but it could also be done by accident, if you changed the license between versions of the software, but used the same license link for both versions, thereby clobbering your old license out of existence. Such a switch would add difficulty for people who need to prove they got their older copy under a different license than the current version.

So why do I have to keep the license in the project root?

I'm not a lawyer, but I've never seen any compelling argument that you do need to keep licenses in the project root. Even the GPL, which specifies that the license must accompany each copy of the work, is silent on how it must accompany the work. (This may be because the GPL could be applied in non-software contexts, where the notion of "root directory" is not meaningful.)

Keeping the license in the root directory is probably a good idea because it maximizes the likelihood the user will see it, and thereby minimizes both user frustration and the likelihood of complaints against you for trying to hide the license in some obscure directory. If you have many licenses, it might make more sense to place them all in their own folder, and include an obvious project README that contains file paths to find the license for each component.

Placing your license in the directory root is a helpful practice also because it can disambiguate the licenses of modules that are licensed differently that the work as a whole. Suppose my project FooProj uses the stand-alone module BarMod. FooProj might be GPL-licensed, while the standalone module might be MIT-licensed. When I first open FooProj, I see a copy of the GPL in the root and understand that work as a whole is GPL-licensed. When I descend into the folder for BarMod, I see a new license file there, and I understand that the contents of this folder are MIT-licensed. Of course, this is only a helpful aid; you should always indicate the licensing of your modules explicitly in a README, NOTICE, or similar file.

In sum, using the file root is a matter of convenience and clarity. I have not seen any legally binding open-source license text that requires it, nor do I know of any reason why it would be legally required. Your license should be reasonably easy for the recipient to discover; including the license in the project root is sufficient, but not necessary, to satisfy this criterion.

Answer 2

But today, we're living in the cloud age. Why can't I, for instance, simply host the full license at my website, and include the title + URL of that license in the header of my source files?

There do exist licenses that permit that. Apache 2.0, for example. Apache 2.0 requires only that each source file contain a small header that points to the Apache 2.0 License's canonical URL. There is no need to reproduce the full license in the source tree.

From the Apache 2.0 license itself:

APPENDIX: How to apply the Apache License to your work

To apply the Apache License to your work, attach the following boilerplate
notice, with the fields enclosed by brackets "[]" replaced with your own 
identifying information. (Don't include the brackets!) The text should be  
enclosed in the appropriate comment syntax for the file format. We also 
recommend that a file or class name and description of purpose be included 
on the same "printed page" as the copyright notice for easier identification 
within third-party archives.

    Copyright [yyyy] [name of copyright owner]

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.

Answer 3

There is no requirement that it must be in the root of the project. It's simply the most common place, and thus the first place people will look in order to find the license. For that matter, even if it weren't common, it's still likely the first place people will look. Since the license exists to inform, hiding the information doesn't make much sense.

If you hide it behind a URL, there's no absolute guarantee that that URL will be always be available. If it's a file in the root of the project, by definition it will always be available.

In short, this is the most effective, most user-friendly place to put it.