Retain Licence only in a single LICENSE.md file at the root of the repo; Remove License Header from all source files

[cmhulbert]

License headers in source files bloat the sources files, throw off git histories, and require maintenance for all files that frequently results in duplicate license information in source files being out of date. I don't believe there is any additional legal protection provided by putting the head in the source file that is not already provided by the LICENSE.md.

Some examples of License header issues we recently dealt with in N5

• until this recent commit. most LICENSE headers were out of date since 2017 (368d964)
• after the above commit, many of the license were duplicated, instead of updated
  

  n5/src/main/java/org/janelia/saalfeldlab/n5/ByteArrayDataBlock.java

  Lines 1 to 53 in 368d964

  	/*-
  	* #%L
  	* Not HDF5
  	* %%
  	* Copyright (C) 2017 - 2025 Stephan Saalfeld
  	* %%
  	* Redistribution and use in source and binary forms, with or without
  	* modification, are permitted provided that the following conditions are met:
  	*
  	* 1. Redistributions of source code must retain the above copyright notice,
  	* this list of conditions and the following disclaimer.
  	* 2. Redistributions in binary form must reproduce the above copyright notice,
  	* this list of conditions and the following disclaimer in the documentation
  	* and/or other materials provided with the distribution.
  	*
  	* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
  	* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  	* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  	* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE
  	* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
  	* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
  	* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
  	* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
  	* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  	* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
  	* POSSIBILITY OF SUCH DAMAGE.
  	* #L%
  	*/
  	/**
  	* Copyright (c) 2017, Stephan Saalfeld
  	* All rights reserved.
  	*
  	* Redistribution and use in source and binary forms, with or without
  	* modification, are permitted provided that the following conditions are met:
  	*
  	* 1. Redistributions of source code must retain the above copyright notice,
  	* this list of conditions and the following disclaimer.
  	* 2. Redistributions in binary form must reproduce the above copyright notice,
  	* this list of conditions and the following disclaimer in the documentation
  	* and/or other materials provided with the distribution.
  	*
  	* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
  	* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  	* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  	* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
  	* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
  	* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
  	* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
  	* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
  	* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  	* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
  	* POSSIBILITY OF SUCH DAMAGE.
  	*/

• duplicate LICENSE.txt introduced 8 months ago

These can be automated and enforced, but if the headers aren't providing any benefit, It would be nice to removed them so we don't need to updated the files every year, for the git history if nothing else.

My preference is to fully remove the license header from all source files and retain a single source of truth for license information in the LICENSE.md file.

@axtimwalde let me know what you think?

[cmhulbert]

From some in-person conversation, this issue can track the effort to remove the license header from sources files, and remove the LICENSE.txt in favor of only the LICENSE.md.

Something to note, when releasing with scijava should pass in the --skip-license-update to avoid having the license added back to the header during release

[cmhulbert]

Something else to be done, there is a licenseExcludes property that can be set in the pom.xml to ensure scijava release wont prepend/update headers in the excluded files. this does not mean that the files are not covered under the LICENSE.md, but just that they should not be automatically prepended with he license headers during the release process. It should be sufficient to use a regex, something like **/*

[axtimwalde]

It's meaning is unclear to me though. By just seeing this property, I would conclude that those files are not covered by the license. Any advise @ctrueden?

[ctrueden]

I agree that the license headers are bothersome aesthetically, all for some theoretical legal benefit. I asked Claude about it:

Right now we use the license-maven-plugin to inject a license header at the top of each source file in our Java projects. This annoyingly bloats each source file, and it would be nice not to do this, but I'm wondering about the legal consequences. What are the modern best practices? What about SPDX identifiers? What's battle tested in court, and/or advised by OSS-supporting organizations?

⏺ I'll share what I know about modern licensing practices for open source projects.

Modern Best Practices

SPDX identifiers have become the recommended approach by major OSS organizations. Instead of full license headers, you use a minimal header like:

// SPDX-License-Identifier: Apache-2.0
// Copyright 2024 Your Organization

Key Considerations

Legal Requirements:

• Copyright law doesn't require headers in every file
• The full license text in your repository's LICENSE file is what matters legally
• File headers are for convenience and clarity, not legal necessity

SPDX Adoption:

• The Linux Foundation strongly promotes SPDX identifiers
• Linux kernel project converted to SPDX identifiers (5000+ files)
• Recommended by OpenChain (ISO 5230 compliance)
• Supported by major projects: LLVM, U-Boot, Zephyr, systemd

OSS Organization Guidance:

• Apache Software Foundation: Accepts short headers with license identifier
• FSF: Still recommends copyright + license notice, but acknowledges SPDX
• Linux Foundation: Actively promotes SPDX as best practice
• GitHub/GitLab: Recognize SPDX identifiers for license detection

Court Testing:

• No court cases have invalidated SPDX identifiers
• No legal precedent requiring full headers vs. short identifiers
• Copyright notice + clear license indication is the standard
• Having LICENSE file in repo + SPDX identifiers meets legal requirements

Practical Recommendation

Most modern projects use:

1. LICENSE file at repository root (full text)
2. Short SPDX header in source files
3. Copyright notices in files (optional but recommended)

This approach is legally sound, widely adopted, and significantly reduces bloat.

Unfortunately, the Codehaus license-maven-plugin does not yet have direct support for this slimmer approach. But we can use a so-called "license resolver". Here are two ways we could do it:

Option 1: Online License Resolver

Host at https://scijava.org/licenses/ or similar, and configure:
https://scijava.org/licenses

Pros: No boilerplate in downstream projects
Cons: Network dependency during builds, need to host/maintain the URL

Option 2: Classpath Resolver (Probably Best!)

There's actually a third option I missed: Since version 1.3, the plugin supports classpath:// protocol. You could:

1. Create a small Maven artifact (e.g., scijava-license-resources) containing just the license repository files
2. Add it as a plugin dependency in pom-scijava-base
3. Use classpath://license as the resolver

Configuration would look like:

  <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>license-maven-plugin</artifactId>
      <version>${license-maven-plugin.version}</version>
      <dependencies>
          <dependency>
              <groupId>org.scijava</groupId>
              <artifactId>scijava-license-resources</artifactId>
              <version>${scijava-license-resources.version}</version>
          </dependency>
      </dependencies>
      <configuration>
          <licenseResolver>classpath://license</licenseResolver>
          ...
      </configuration>
  </plugin>

Pros: No network dependency, no boilerplate in downstream projects, resources versioned with pom-scijava-base
Cons: One more artifact to maintain

I lean toward Option 2, because Maven builds already rely on Maven Central to access artifacts, and adding one more does not complexify the build infrastructure's needed sources. That said, javadoc.scijava.org is already a dependency for the javadoc portion of the build, so adding a licenses directory to https://github.com/scijava/scijava.github.io is no big deal, and slightly less complicated from a deployment standpoint (direct edit to GitHub repo takes effect within a minute or so, versus cutting a new release of the JAR file, bumping the version in pom-scijava-base, propagating to pom-scijava, bumping that version...)

@cmhulbert @axtimwalde What is your preference?

[cmhulbert]

It's meaning is unclear to me though. By just seeing this property, I would conclude that those files are not covered by the license. Any advise @ctrueden?

Part of why I explicitly stated it there is to ensure there is writing that describes what it means, but I agree the naming is unfortunate. We can avoid using it for now, but it would require us to ensure we pass the flag to --skip-license-update

cmhulbert axtimwalde What is your preference?

Personally for N5, I'm still of the opinion that the license headers provide no additional legal protection, but I'm not a lawyer, so perhaps I'm missing something. Many large open source repos however do not include header information for the license in each source file.

In general for the scijava release, I think the SPDX license identifiers is a nice middle ground, but only if we omit the second line in the example you provided

// SPDX-License-Identifier: Apache-2.0
// Copyright 2024 Your Organization

Specifically the second line since a big reason I'm not a fan of the header license info is because they contain the year, and need to be updated for all files yearly. That's a small maintenance burden, but it also pollutes the git history, especially line-by-line git blame

That doesn't seem to be at odds with the linux convention though. It seems ChatGPT may have added the second line from some other reference? All of the reference at least on this page (https://spdx.dev/learn/handling-license-info/) seem to only have a single line, un-dated reference.
Here is an example in the linux kernel
That is something I would be supportive of generally ( though still my opinion for n5 would be to omit though)