7

Example

GPL v3 Project, MIT (ExPat) file/directory.

myproject
├── LICENSE (GPL v3)
├── ...
├── gpl_licensed_file
├── mit_licensed_directory
│   └── mit_file1
└── mit_licensed_file

So If I were looking at this project, I would have on way to know that mit_licensed_directory and mit_licensed_file were not under the primary License declared in LICENSE.

How do I denote when a file or directory is not using the same license as the rest of the project?

  • The clearest way is to note the license in the file header. – curiousdannii Mar 30 '16 at 2:08
6

There are no hard-and-fast rules on how to show this information. The bottom line is to make sure recipients can easily figure out which files are under which license. You also need to preserve copyright notices, where required. This is a common requirement of many licenses, but most licenses do not dictate where those notices are kept, only that, again, recipients can easily figure out which files correspond to those copyright notices.

So I'd like to refer to best practices instead. There's a good article provided by the SFLC which covers this, Managing copyright information within a free software project:

Best practices for maintaining license information

License information can also be maintained in individual files, in a central location, or in some combination of both. Most projects use a hybrid approach, placing the primary license in a top-level COPYING or LICENSE file, and also including some license information in each file’s header.

So the two approaches are (and most projects use both):

  • Information in individual files (i.e. Copyright 20XX Jane Hacker under Foobar License at the top of files)
  • In a central location, usually a top-level COPYING or LICENSE file

These are all best practices, not requirements. For example, you do not have to have a top-level COPYING/LICENSE file, the same information could be in the readme. Note that some licenses require that you provide the full text of the license, but again that doesn't have to be named COPYING or LICENSE.

The article does recommend the central location approach though, as it makes it easy to know the full licensing information at one place:

In many situations, a semi-centralized approach will work best. Consider a GPL-licensed project whose codebase contains a number of permissively-licensed libraries with custom modifications. While the license of the resulting program will be GPL, because of GPL’s copyleft provision, the source for the libraries can be maintained under their individual licenses. In this scenario, it makes sense to keep license information for the individual libraries at the top level of the directories they’re kept in, as well as in the license information for the entire project.

That is:

  • Maintain a top-level file describing the licensing of the entire project, i.e. which parts are under which licenses
  • Under each directory that contains a sub-project under a different license, maintain a file there describing the licensing of that sub-project

So your example project might look like this:

myproject
├── LICENSE
├── GPLv3.LICENSE
├── ...
├── gpl_licensed_file
├── mit_licensed_directory
│   ├── LICENSE (MIT)
│   └── mit_file1
└── mit_licensed_file

Where the top-level LICENSE file contains something like:

myproject is licensed under GPLv3, except for mit_licensed_directory and mit_licensed_file

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.