forgejo/discussions
49
43

Documenting copyright and licensing #431

Open
opened 2025年12月23日 00:41:03 +01:00 by Gusted · 5 comments

I think it's fair to say that Forgejo is proud to have a copyleft license, https://forgejo.org/2024-08-gpl/. Therefore I would like to explore how to assert license and copyright attribution even better in Forgejo's codebase (and possibly other Forgejo projects).

Forgejo's codebase is quite a mix of copyright attributions and licenses. There are files and code that originate from Gogs and have not been touched since (Gogs author), we have a significant amount of code from Gitea (Gitea author), and our own code that could have been licensed under MIT or GPL-3.0-or-later (Forgejo authors). There are also a handful of files that have copyright attribution to individuals (either because we incorporated their code from somewhere or introduced it via Forgejo because we don't require Forgejo authors as copyright attribution) or organizations (the soft-quota feature that Codeberg paid for). And the entire Forgejo binary is licensed under GPL-3.0-or-later.

The de facto unwritten, not checked, and unenforced way to document this is via copyright headers, using the standardized SPDX header to specify the license and "// Copyright YYYY The XXXX Authors. All rights reserved." to document attribution. However, there are many files in the codebase that do not have such a line, because they are either test data, binaries, or simply never done. I would say that in the vast majority of cases, attribution and licenses are clear if you do the extra work of using git blame, but this should not be necessary and the lines could become blurred if files have been modified between projects and/or after Forgejo has allowed GPL-3.0 or later as a license.

One way to solve this is by using https://reuse.software/. This would require all files to have a license and copyright notice, and for files where this is not possible, it can be defined in a REUSE.toml or as a /path/to/file.license file. This project includes a lint tool that will act as an enforcer that we adhere to documenting the copyrights and licenses for each file in the codebase. It even allows snippets within a file to be licensed differently.

It will be quite an operation to make Forgejo's codebase compliant with any tool/specification for documenting copyright and licenses for each file, so I suggest that when we can decide on a tool/specification, we start with one of Forgejo's other projects that is smaller in scope, such as https://code.forgejo.org/ forgejo/runner or https://codeberg.org/forgejo/docs (which generally already has good documentation).

I would like to know the following:

  • Do you agree that documenting licenses and copyright attribution in a standardized way has advantages and should be pursued for code developed by the Forgejo project?
  • What alternatives are there for documenting this?
  • Are there any reservations about using REUSE for this purpose?
I think it's fair to say that Forgejo is proud to have a copyleft license, https://forgejo.org/2024-08-gpl/. Therefore I would like to explore how to assert license and copyright attribution even better in Forgejo's codebase (and possibly other Forgejo projects). Forgejo's codebase is quite a mix of copyright attributions and licenses. There are files and code that originate from Gogs and have not been touched since (Gogs author), we have a significant amount of code from Gitea (Gitea author), and our own code that could have been licensed under MIT or GPL-3.0-or-later (Forgejo authors). There are also a handful of files that have copyright attribution to individuals (either because we incorporated their code from somewhere or introduced it via Forgejo because we don't require Forgejo authors as copyright attribution) or organizations (the soft-quota feature that Codeberg paid for). And the entire Forgejo binary is licensed under GPL-3.0-or-later. The de facto unwritten, not checked, and unenforced way to document this is via copyright headers, using the standardized SPDX header to specify the license and "// Copyright YYYY The XXXX Authors. All rights reserved." to document attribution. However, there are many files in the codebase that do not have such a line, because they are either test data, binaries, or simply never done. I would say that in the vast majority of cases, attribution and licenses are clear if you do the extra work of using git blame, but this should not be necessary and the lines could become blurred if files have been modified between projects and/or after Forgejo has allowed GPL-3.0 or later as a license. One way to solve this is by using https://reuse.software/. This would require all files to have a license and copyright notice, and for files where this is not possible, it can be defined in a `REUSE.toml` or as a `/path/to/file.license` file. This project includes a lint tool that will act as an enforcer that we adhere to documenting the copyrights and licenses for each file in the codebase. It even allows snippets within a file to be licensed differently. It will be quite an operation to make Forgejo's codebase compliant with any tool/specification for documenting copyright and licenses for each file, so I suggest that when we can decide on a tool/specification, we start with one of Forgejo's other projects that is smaller in scope, such as https://code.forgejo.org/ forgejo/runner or https://codeberg.org/forgejo/docs (which generally already has good documentation). I would like to know the following: - Do you agree that documenting licenses and copyright attribution in a standardized way has advantages and should be pursued for code developed by the Forgejo project? - What alternatives are there for documenting this? - Are there any reservations about using REUSE for this purpose?
Owner
Copy link

Agree this is a good thing and also agree to REUSE. It will be effort and I wonder if the person that officially declares license and copyright on a file (and could possibly do a mistake) would be liable for this in a legal sense.

Agree this is a good thing and also agree to REUSE. It will be effort and I wonder if the person that officially declares license and copyright on a file (and could possibly do a mistake) would be liable for this in a legal sense.

I agree with making it REUSE-compliant. I wouldn't much worry about the act of declaring the license and copyright of a file. The situation after will certainly be better than now.

I agree with making it REUSE-compliant. I wouldn't much worry about the act of declaring the license and copyright of a file. The situation after will certainly be better than now.
Author
Owner
Copy link

@fnetX wrote in #431 (comment):

I wonder if the person that officially declares license and copyright on a file (and could possibly do a mistake) would be liable for this in a legal sense.

Yes, I think this is what the person agrees to in a DCO. I can imagine situations where the only course would be to re-implement a file or a portion of the code to avoid that liability where it might not be entirely clear or is at best dubious/debatable.

@fnetX wrote in https://codeberg.org/forgejo/discussions/issues/431#issuecomment-9163404: > I wonder if the person that officially declares license and copyright on a file (and could possibly do a mistake) would be liable for this in a legal sense. Yes, I think this is what the person agrees to in a [DCO](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/DCO). I can imagine situations where the only course would be to re-implement a file or a portion of the code to avoid that liability where it might not be entirely clear or is at best dubious/debatable.

I'd support the effort to make Forgejo REUSE compliant. 👍 My intent is for my own contributions to be GPL licensed, and I think better clear & consistent identification throughout the project to identify licensing should help communicate that intent.

I'd support the effort to make Forgejo REUSE compliant. 👍 My intent is for my own contributions to be GPL licensed, and I think better clear & consistent identification throughout the project to identify licensing should help communicate that intent.
Owner
Copy link

The codebase is already mostly REUSE compliant in a way that we luckily have appropriate copyright headers all over the place. Even not considering REUSE specifically I was already pushing during review and in my PRs for new JS/TS/CSS files to have license headers added to them, so I am in favor of implementing this. Resolving appropriate texts for files that are missing copyright headers on behalf of original authors will be a somewhat challenging task.

It should be easy to apply licenses to vendored files like Octicons. But the fate of some things is very unclear to me: fixtures and logos of 3rd party integrations.

The codebase is already mostly REUSE compliant in a way that we luckily have appropriate copyright headers all over the place. Even not considering REUSE specifically I was already pushing during review and in my PRs for new JS/TS/CSS files to have license headers added to them, so I am in favor of implementing this. Resolving appropriate texts for files that are missing copyright headers on behalf of original authors will be a somewhat challenging task. It should be easy to apply licenses to vendored files like Octicons. But the fate of some things is very unclear to me: fixtures and logos of 3rd party integrations.
Sign in to join this conversation.
No Branch/Tag specified
No results found.
No results found.
Labels
Clear labels
User research - Accessibility
Requires input about accessibility features, likely involves user testing.
User research - Blocked
Do not pick as-is! We are happy if you can help, but please coordinate with ongoing redesign in this area.
User research - Community
Community features, such as discovering other people's work or otherwise feeling welcome on a Forgejo instance.
User research - Config (instance)
Instance-wide configuration, authentication and other admin-only needs.
User research - Errors
How to deal with errors in the application and write helpful error messages.
User research - Filters
How filter and search is being worked with.
User research - Future backlog
The issue might be inspiring for future design work.
User research - Git workflow
AGit, fork-based and new Git workflow, PR creation etc
User research - Labels
Active research about Labels
User research - Moderation
Moderation Featuers for Admins are undergoing active User Research
User research - Needs input
Use this label to let the User Research team know their input is requested.
User research - Notifications/Dashboard
Research on how users should know what to do next.
User research - Rendering
Text rendering, markup languages etc
User research - Repo creation
Active research about the New Repo dialog.
User research - Repo units
The repo sections, disabling them and the "Add more" button.
User research - Security
User research - Settings (in-app)
How to structure in-app settings in the future?
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
forgejo/discussions#431
Reference in a new issue
forgejo/discussions
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?