Open Source Stack Exchange is a question and answer site for people organizing, marketing or licensing open source development projects. It only takes a minute to sign up.
Sign up to join this community
How do I meet the requirement to state changes of a forked project?
The choose a license website has a table comparing licenses. One of the columns is called state changes. This is described as:
Changes made to the code must be documented.
Is the repository commit history sufficient to meet the requirement? Do I need a CHANGELOG file?
(The answer is likely the same independently of the license, but to be more specific I was looking into the MPL-2.0 and the EUPL-1.2.)
The EUPL says the following with respect to "stating changes":
The Licensee must cause any Derivative Work to carry prominent notices stating that the Work has been modified and the date of modification.
Emphasis added. See Section 5 of EUPL-1.2
The version control history alone would probably not be sufficient. I'm not sure if the comments in a version control history log would be considered "prominent", but the more serious problem is that it is too easy for such commit comments to be separated from the code itself. Let's take GitHub as an example -- when you visit a project on GitHub, you can certainly clearly see which files were modified and when, which might appear at first to comply with the EUPL-1.2 requirement, but consider what happens when an end user clicks "Download" to download a specific version from your repository. Unless you've stated the required changes somewhere in an actual file of your repository, the ZIP file that the user downloads will no longer be in compliance with the license. The same potential problem occurs when a user uses "git clone --depth 1" to download only the latest version of your repository, and the same problem will probably also occur with most other version control systems (e.g. "svn checkout" will not copy commit logs of any kind).
The easiest way to comply with the "prominent notices" requirement of the EUPL is to add a note to the source code file(s) that you modified. You don't need to say what you modified, just that they were modified and the date. For example, suppose the source file that you want to modify looks like this:
/* Copyright 2016 J. Random Hacker. This source code file is part of FooLib and is
* licensed under the EUPL-1.2. For the full license text, please see the file
* LICENSE.EUPL12 or visit https://opensource.org/licenses/EUPL-1.2
*/
To meet the requirement, you could modify it to look like this:
/* Copyright 2016 J. Random Hacker. This source code file is part of FooLib and is
* licensed under the EUPL-1.2. For the full license text, please see the file
* LICENSE.EUPL12 or visit https://opensource.org/licenses/EUPL-1.2
*
* 6 May 2019 - Modified by K. Deterministic Hacker.
*/
This way is simple, meets the requirement, and makes it easy for future contributors to also comply. If you wish, you could also add a note in a CHANGELOG if you'd like, but that is extra -- a CHANGELOG could still easily be "lost," overwritten, or otherwise moved around if code from multiple projects are ever combined, or if parts of one project are used in another, etc.
If you are distributing binaries only, note that the EUPL also requires that you provide the source code along with the binaries, or otherwise provide a way for the user to access it:
If the Work is provided as Executable Code, the Licensor provides in addition a machine-readable copy of the Source Code of the Work along with each copy of the Work that the Licensor distributes or indicates, in a notice following the copyright notice attached to the Work, a repository where the Source Code is easily and freely accessible for as long as the Licensor continues to distribute or communicate the Work.
Because you will need to distribute the source code anyway, the notification you made above in the source code file is already sufficient in this case. You don't need to do anything else other than what the EUPL already requires.
The Choose a License page is best used when you need an overview of popular open source licenses and want to pick the right open source license for your own code. But when you are copying someone else's code and need to comply with their license, or when you need details about a particular requirement, the best place is to look at the specific license itself for the specific way that you want to use the code (e.g. whether you will distribute binaries only, or source code as well, etc.).
