Gitea requires a copyright assignment for MIT licensed contributions #67

Ghost commented 2023年10月05日 20:42:33 +02:00

Please no criticism on the Gitea policy here. If you have thoughts on the matter, please bring that to Gitea discussion spaces. The focus of this discussion is how to deal with this new information in a sensible way.

---

A significant security patch was submitted as a contribution to Gitea today. It complies with the contributions guidelines and in particular:

• it is released under the MIT license
• it complies with the Gitea DCO
• all new files begin with // Copyright 2023 The Gitea Authors. All rights reserved.

It was blocked by Gitea Ltd. shareholders because it does not comply with a new requirement: copyright assignment. The decision was explained in the pull request by a rationale that is transcribed below for the record.

Forgejo is not the place to debate if such a policy is sensible or not, this should happen in the Gitea spaces. This conversation is meant to debate what Forgejo should do with this newly acquired information.

Until today there was a steady stream of contributions from Forgejo contributors and Codeberg users alike. Some of these contributions are not covered by copyright (typically a bug fix of a few lines or even a major refactor) and they are not impacted. But the most significant ones contain copyrighted code and it is no longer enough for the author to publish it under the MIT license for that code to be contributed to Gitea. The author is also required to assign their copyright, which they may or may not be willing to do.

Another consequence of the decision to block contributions pending a copyright assignment is that, as far as Gitea is concerned, the license under which a code is published does not matter. If someone was to make a large contribution to Forgejo under a copyleft license, it would be more difficult to contribute it to Gitea. In both cases, MIT or copyleft, the blocker will be the copyright assignment.

In other word, if there was copylefted code in Forgejo (which is currently not the case) and someone was to say : "I want to take this piece of code from Forgejo and contribute it to Gitea but I cannot because it is copyelft", the answer would now be: "well, you could not even if it was MIT because it has a copyright header that is not a Gitea copyright header and that you cannot remove, because you are not the copyright holder".

---

@earl-warren Is it a requirement to remove copyright notices to contribute code to Gitea?
@techknowlogick This has been explained many times already to you, and you have been warned as well in the last pull request to follow contribution guidelines. If you'd like to adhere to the contribution guidelines we'd be happy to have any contribution, however as you've shown to willfully disregard them action may need to be taken.
@earl-warren where, in the contributions guidelines, can I find the requirement to remove an existing copyright notice from a MIT licensed code?
@techknowlogick We're not asking you to remove copyright, but instead asking for copyright assignment. If each of our contributors added to the headers of the file they touched then some files could have over 1000 listings, this is clearly untenable. We don't remove copyright, for example there is places where we used code from go and kept their headers because we took that code and adhered to the license, but as you are contributing the code that's where the difference is. If you don't have the rights to do so under DCO and contribution document then that prevents us from accepting code. This is following guidance from the Linux Foundation to ensure a codebase free of any conflict.
@earl-warren I was not aware Gitea required a copyright assignment. Could you please let me know where this is explained in the contributions guidelines?
@techknowlogick For the past 7 years, Gitea has required the same policy on copyright headers; you've been told this in other PRs, and have modified your PRs to be accepted. Not adhering to it once or twice can be forgiven as an accident, however, continuing to do so, including after being warned, has to be treated as you not acting in good faith, especially in this PR for a security-related PR knowing it can't be merged as-is. Thankfully we've been working on a PR for this as well, and we were going to send it over privately once ready, so we are able to resolve this issue via a different PR without code that is tainted by copyright issues. As I've said before, we welcome all contributions as long as they adhere to the project standards, if you/Forgejo are refusing to do so that's unfortunate.
@techknowlogick blocking per comments

**Please no criticism on the Gitea policy here. If you have thoughts on the matter, please bring that to Gitea discussion spaces. The focus of this discussion is how to deal with this new information in a sensible way.** --- A [significant security patch](https://github.com/go-gitea/gitea/pull/27455) was submitted as a contribution to Gitea today. It complies with the [contributions guidelines](https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md) and in particular: * it is released under the MIT license * it complies with the [Gitea DCO ](https://github.com/go-gitea/gitea/blob/main/DCO) * all new files begin with `// Copyright 2023 The Gitea Authors. All rights reserved.` It was blocked by Gitea Ltd. shareholders because it does not comply with a new requirement: copyright assignment. The decision was explained in the pull request by a rationale that is transcribed below for the record. **Forgejo is not the place to debate if such a policy is sensible or not, this should happen in the Gitea spaces.** This conversation is meant to debate what Forgejo should do with this newly acquired information. Until today there was a steady stream of contributions from Forgejo contributors and Codeberg users alike. Some of these contributions are not covered by copyright (typically a bug fix of a few lines or even a major refactor) and they are not impacted. But the most significant ones contain copyrighted code and it is no longer enough for the author to publish it under the MIT license for that code to be contributed to Gitea. The author is also required to assign their copyright, which they may or may not be willing to do. Another consequence of the decision to block contributions pending a copyright assignment is that, as far as Gitea is concerned, the license under which a code is published does not matter. If someone was to make a large contribution to Forgejo under a copyleft license, it would be more difficult to contribute it to Gitea. In both cases, MIT or copyleft, the blocker will be the copyright assignment. In other word, if there was copylefted code in Forgejo (which is currently not the case) and someone was to say : "I want to take this piece of code from Forgejo and contribute it to Gitea but I cannot because it is copyelft", the answer would now be: "well, you could not even if it was MIT because it has a copyright header that is not a Gitea copyright header and that you cannot remove, because you are not the copyright holder". --- > @earl-warren Is it a requirement to remove copyright notices to contribute code to Gitea? > @techknowlogick This has been explained many times already to you, and you have been warned as well in the last pull request to follow contribution guidelines. If you'd like to adhere to the contribution guidelines we'd be happy to have any contribution, however as you've shown to willfully disregard them action may need to be taken. > @earl-warren where, in the contributions guidelines, can I find the requirement to remove an existing copyright notice from a MIT licensed code? > @techknowlogick We're not asking you to remove copyright, but instead asking for copyright assignment. If each of our contributors added to the headers of the file they touched then some files could have over 1000 listings, this is clearly untenable. We don't remove copyright, for example there is places where we used code from go and kept their headers because we took that code and adhered to the license, but as you are contributing the code that's where the difference is. If you don't have the rights to do so under DCO and contribution document then that prevents us from accepting code. This is following guidance from the Linux Foundation to ensure a codebase free of any conflict. > @earl-warren I was not aware Gitea required a copyright assignment. Could you please let me know where this is explained in the contributions guidelines? > @techknowlogick For the past 7 years, Gitea has required the same policy on copyright headers; you've been told this in other PRs, and have modified your PRs to be accepted. Not adhering to it once or twice can be forgiven as an accident, however, continuing to do so, including after being warned, has to be treated as you not acting in good faith, especially in this PR for a security-related PR knowing it can't be merged as-is. Thankfully we've been working on a PR for this as well, and we were going to send it over privately once ready, so we are able to resolve this issue via a different PR without code that is tainted by copyright issues. As I've said before, we welcome all contributions as long as they adhere to the project standards, if you/Forgejo are refusing to do so that's unfortunate. > @techknowlogick blocking per comments

techknowlogick commented 2023年10月05日 21:13:31 +02:00

Responding, as I was pinged.

1. Gitea Ltd is not require anything. This is a Gitea project policy that has existed from the start of the project.
2. This is not newly acquired information. @earl-warren was told of this many times, including a warning in the last PR
3. I was acting as a TOC member due to the bad-faith actions of @earl-warren

Responding, as I was pinged. 1. Gitea Ltd is not require anything. This is a Gitea project policy that has existed from the start of the project. 2. This is not newly acquired information. @earl-warren was told of this many times, including a warning in the last PR 3. I was acting as a TOC member due to the bad-faith actions of @earl-warren

caesar commented 2023年10月05日 21:24:09 +02:00

I was staying out of the conversation on the Gitea space but I'll respond here with a few points @techknowlogick.

• If Gitea now requires copyright assignment as you claimed, that is a new policy. It has never required that before (and to require it you will need a CLA). In the past it has only had a DCO where the contributor certifies that they have the right to contribute the code.

• Your "warnings" do not supersede copyright law or the MIT license. The license explicitly requires that the copyright header be maintained. Only the original author of the code has the right to allow it be removed or modified. Frankly, if Gitea decision-makers genuinely have such a poor understanding of copyright law as appears to be displayed in these interactions, it makes me very worried about the legality of other code that may be included in Gitea in potential violation of the original license.

• From what I have seen @earl-warren has acted purely in good faith, offering contributions upstream in a friendly and professional manner to the mutual benefit of both sides. If anything it is your own actions that have at times appeared to be unnecessarily confrontational (which is why I personally tend to avoid interacting in Gitea spaces, as I simply am not interested in wasting my time on such unpleasant interactions). To use terms such as "warning", "we will have to take action", and "bad-faith" when referring to somebody's selfless contributions is hardly conducive to maintaining a good professional relationship or a friendly and welcoming community.

I was staying out of the conversation on the Gitea space but I'll respond here with a few points @techknowlogick. - If Gitea now requires copyright assignment as [you claimed](https://github.com/go-gitea/gitea/pull/27455#discussion_r1347424833), that _is_ a new policy. It has never required that before (and to require it you will need a CLA). In the past it has only had a DCO where the contributor certifies that they have the right to contribute the code. - Your "warnings" do not supersede copyright law or the MIT license. The license _explicitly requires_ that the copyright header be maintained. Only the original author of the code has the right to allow it be removed or modified. Frankly, if Gitea decision-makers genuinely have such a poor understanding of copyright law as appears to be displayed in these interactions, it makes me very worried about the legality of other code that may be included in Gitea in potential violation of the original license. - From what I have seen @earl-warren has acted purely in good faith, offering contributions upstream in a friendly and professional manner to the mutual benefit of both sides. If anything it is your own actions that have at times appeared to be unnecessarily confrontational (which is why I personally tend to avoid interacting in Gitea spaces, as I simply am not interested in wasting my time on such unpleasant interactions). To use terms such as "warning", "we will have to take action", and "bad-faith" when referring to somebody's selfless contributions is hardly conducive to maintaining a good professional relationship or a friendly and welcoming community.

KaKi87 commented 2023年10月05日 21:25:03 +02:00

I'm sorry I don't understand, could you please summarize in layman's terms ? Thanks

I'm sorry I don't understand, could you please summarize in layman's terms ? Thanks

caesar commented 2023年10月05日 21:31:24 +02:00

I'm sorry I don't understand, could you please summarize in layman's terms ? Thanks

@KaKi87 see this conversation where Gitea Ltd shareholders requested that a copyright notice be removed from a MIT-licensed work and stated that Gitea requires assignment of copyright.

> I'm sorry I don't understand, could you please summarize in layman's terms ? Thanks @KaKi87 see [this conversation](https://github.com/go-gitea/gitea/pull/27455#pullrequestreview-1659171103) where Gitea Ltd shareholders requested that a copyright notice be removed from a MIT-licensed work and stated that Gitea requires assignment of copyright.

techknowlogick commented 2023年10月05日 21:40:44 +02:00

as I was responded to:

@caesar:

perhaps "copyright assignment" is the wrong word, I'm not a lawyer. All I know is what we have in place from the Linux foundation, if we take code we add their header, if we are given code, then what is said in the contribution document is that all new files have a specific header, and as I've said if everyone who adds code adds a header some files would have over a thousand lines of comments.

The warnings were not about not adhering to licenses but his deliberate disregard for following the information he was given, and his continuation of it after being informed of what to do.

My apologies if I came across as anything other than professional, unfortunately when responding to someone violating warnings I am unable to add emoji's etc. to soften the language.

@KaKi87: The Gitea project has had a contribution policy in place from the beginning of the project that new files must have certain headers. @earl-warren has made a habit of disregarding that and adding additional ones. As a project, we can't accept that due to having then to add 100s of new comments from everyone who contributes.

as I was responded to: @caesar: perhaps "copyright assignment" is the wrong word, I'm not a lawyer. All I know is what we have in place from the Linux foundation, if we take code we add their header, if we are given code, then what is said in the contribution document is that all new files have a specific header, and as I've said if everyone who adds code adds a header some files would have over a thousand lines of comments. The warnings were not about not adhering to licenses but his deliberate disregard for following the information he was given, and his continuation of it after being informed of what to do. My apologies if I came across as anything other than professional, unfortunately when responding to someone violating warnings I am unable to add emoji's etc. to soften the language. @KaKi87: The Gitea project has had a contribution policy in place from the beginning of the project that new files must have certain headers. @earl-warren has made a habit of disregarding that and adding additional ones. As a project, we can't accept that due to having then to add 100s of new comments from everyone who contributes.

caesar commented 2023年10月05日 21:53:16 +02:00

@techknowlogick I believe you may have misunderstood the guidance you refer to from the Linux foundation. While it is perfectly reasonable to ask contributors to accept a specific form of attribution (in this case, to be attributed as "Gitea Authors" instead of by name), that only applies when the author of the code is making the contribution themselves. A third party does not have the right to make that decision on the author's behalf.

When incorporating code from another project (whether that's Forgejo, Gogs, Go, or anything else) it is a violation of the license to remove the original copyright header. It's as simple as that. For the same reason, we would never dream of removing the Gitea license header from the Forgejo source code. The same applies both ways.

Regardless of what instructions you may have given @earl-warren, he would be acting in violation of the license if he were to remove the original copyright header without the author's permission. (And additionally, the Gitea codebase would be "tainted" with code used in violation of the license.) That legal fact, rather than the "bad faith" you are assuming, is undoubtedly the reason he was not able to do so.

EDIT: you keep referring to the idea of "having then to add 100s of new comments from everyone who contributes". This is patently false. There is a difference, as described above, between accepting original contributions and incorporating code from another project that already has its own license.

@techknowlogick I believe you may have misunderstood the guidance you refer to from the Linux foundation. While it is perfectly reasonable to ask contributors to accept a specific form of attribution (in this case, to be attributed as "Gitea Authors" instead of by name), that only applies when the author of the code is making the contribution themselves. A third party does not have the right to make that decision on the author's behalf. When incorporating code from another project (whether that's Forgejo, Gogs, Go, or anything else) it is a violation of the license to remove the original copyright header. It's as simple as that. For the same reason, we would never dream of removing the Gitea license header from the Forgejo source code. The same applies both ways. Regardless of what instructions you may have given @earl-warren, he would be acting in violation of the license if he were to remove the original copyright header without the author's permission. (And additionally, the Gitea codebase would be "tainted" with code used in violation of the license.) That legal fact, rather than the "bad faith" you are assuming, is undoubtedly the reason he was not able to do so. EDIT: you keep referring to the idea of "having then to add 100s of new comments from everyone who contributes". This is patently false. There is a difference, as described above, between accepting original contributions and incorporating code from another project that already has its own license.

techknowlogick commented 2023年10月05日 22:10:48 +02:00

@caesar, if you look at previous contributions, @earl-warren has made this change, hopefully with the author's consent, as otherwise, that'd conflict with the DCO.

I'm not asking for a license violation. As I've said previously, should we take copywritten code from elsewhere, then we add the headers, but as this code is being given to us, then the policy must be followed. If @earl-warren is not acting as a proxy for the author, then I'd be concerned with his previous contributions.

@caesar, if you look at previous contributions, @earl-warren has made this change, hopefully with the author's consent, as otherwise, that'd conflict with the DCO. I'm not asking for a license violation. As I've said previously, should we take copywritten code from elsewhere, then we add the headers, but as this code is being given to us, then the policy must be followed. If @earl-warren is not acting as a proxy for the author, then I'd be concerned with his previous contributions.

n0toose commented 2023年10月05日 22:31:35 +02:00

Gitea Ltd is not require anything. This is a Gitea project policy that has existed from the start of the project.

I think this is a major misunderstanding.

Without addressing the header policy: I seriously think that, in that thread, you said something that can be misunderstood in a very awful way. By sending you a pull request, I fall under the label of "being a Gitea author" and do not assign the copyright to anyone else, it is my understanding that it is an umbrella term meant to avoid the maintenance of lengthy copyright headers. "The Gitea authors", from my understanding, does not refer to a single body that represents all of these authors' contributions at once; using the term "copyright assignment" to "The Gitea authors", in this context, gives off the impression that I'm giving an exclusive, irrevocable license to another person / entity to do whatever they want with my change (instead of up to what is described by the terms of the MIT license).

The worst possible interpretation would be that you're retroactively saying that all of the contributions from the past 7 years belong to someone else (who gets all of these copyrights then? Has to be Gitea Ltd.?) without the contributors having signed anything that provides such an exclusive license and that this should continue being the case. At best, this looks like an excuse that barely makes any sense (simply because the term doesn't make sense) because Gitea has beef with the fork that published the open letter questioning them and does not want to recognize the fork.

I think that you're just insisting on not giving what you're likely seeing as preferential treatment, but I hope you understand what I mean by bringing up those two scenarios. It would be a great idea to clear this up in the original thread before someone drops a link on Hacker News or whatever.

> Gitea Ltd is not require anything. This is a Gitea project policy that has existed from the start of the project. I think this is a major misunderstanding. Without addressing the header policy: I seriously think that, in that thread, you said something that can be misunderstood in a very awful way. By sending you a pull request, I fall under the label of "being a Gitea author" and do not assign the copyright to anyone else, it is my understanding that it is an umbrella term meant to avoid the maintenance of lengthy copyright headers. "The Gitea authors", from my understanding, does not refer to a single body that represents all of these authors' contributions at once; using the term "copyright assignment" *to* "The Gitea authors", in this context, gives off the impression that I'm giving an exclusive, irrevocable license to another person / entity to do whatever they want with my change (instead of up to what is described by the terms of the MIT license). The worst possible interpretation would be that you're retroactively saying that all of the contributions from the past 7 years belong to someone else (who gets *all* of these copyrights then? Has to be Gitea Ltd.?) without the contributors having signed anything that provides such an exclusive license and that this should continue being the case. At best, this looks like an excuse that barely makes any sense (simply because the term doesn't make sense) because Gitea has beef with the fork that published the open letter questioning them and does not want to recognize the fork. I think that you're just insisting on not giving what you're likely seeing as preferential treatment, but I hope you understand what I mean by bringing up those two scenarios. It would be a great idea to clear this up in the original thread before someone drops a link on Hacker News or whatever.

earl-warren commented 2023年10月05日 23:02:57 +02:00

@techknowlogick the bottom line is still that code contributions to Gitea must not bear any copyright header other than // Copyright 2023 The Gitea Authors. All rights reserved.. This is a new requirement and if it is not, please cite where it has been stated in the past.

@techknowlogick the bottom line is still that code contributions to Gitea must not bear any copyright header other than `// Copyright 2023 The Gitea Authors. All rights reserved.`. This is a new requirement and if it is not, please cite where it has been stated in the past.

Ghost commented 2023年10月05日 23:31:16 +02:00

In order to keep this discussion dispassionate and civilized, please refrain from making unfounded accusations against other people (bad faith, etc.). As I stressed in the topic, here is not the place to dispute or even justify the Gitea Ltd. policy regarding copyright assignment or contribution. That would be for the Gitea spaces.

Here is the forum to figure out what to do with it and how to make the best of what it is. Only people who have the legal permission to remove copyright headers from the code they propose can contribute to Gitea. This is now clear and unambiguous, as stated by a shareholder of Gitea Ltd. (sole owner of the domains and the trademark) who is also a member of the TOC for the project. It was written in the cited pull request and confirmed here again, if there was any doubt left. The name that is given (copyright assignment, recommendation from the Linux foundation...) or the time it came into effect (7 years ago or just today) is of little consequence.

In order to keep this discussion dispassionate and civilized, please refrain from making unfounded accusations against other people (bad faith, etc.). As I stressed in the topic, here is not the place to dispute or even justify the Gitea Ltd. policy regarding copyright assignment or contribution. That would be for the Gitea spaces. Here is the forum to figure out what to do with it and how to make the best of what it is. **Only people who have the legal permission to remove copyright headers from the code they propose can contribute to Gitea.** This is now clear and unambiguous, as stated by a shareholder of Gitea Ltd. (sole owner of the domains and the trademark) who is also a member of the TOC for the project. It was written in the cited pull request and confirmed here again, if there was any doubt left. The name that is given (copyright assignment, recommendation from the Linux foundation...) or the time it came into effect (7 years ago or just today) is of little consequence.

KaKi87 commented 2023年10月06日 04:58:38 +02:00

By sending you a pull request, I fall under the label of "being a Gitea author" and do not assign the copyright to anyone else, it is my understanding that it is an umbrella term meant to avoid the maintenance of lengthy copyright headers.

That's also what I was thinking. I didn't mention it fearing it would be considered as sharing thoughts or attempting to debate, but while I don't really understand the legal parts of this discussion, I tend to understand the "Gitea authors" at gitea/go-gitea@github.com part that way. And of course, I also apply that to "Forgejo authors" at forgejo/forgejo@codeberg.org the same way.

Therefore, I'd conclude that there's no issue.

Is this reasoning making sense or missing something ?

Thanks

> By sending you a pull request, I fall under the label of "being a Gitea author" and do not assign the copyright to anyone else, it is my understanding that it is an umbrella term meant to avoid the maintenance of lengthy copyright headers. That's also what I was thinking. I didn't mention it fearing it would be considered as sharing thoughts or attempting to debate, but while I don't really understand the legal parts of this discussion, I tend to understand the "Gitea authors" at `gitea/go-gitea@github.com` part that way. And of course, I also apply that to "Forgejo authors" at `forgejo/forgejo@codeberg.org` the same way. Therefore, I'd conclude that there's no issue. Is this reasoning making sense or missing something ? Thanks

earl-warren commented 2023年10月09日 22:48:12 +02:00

For the record, with permissions from @Gusted and for the sake of keeping Gitea users safe, the Forgejo headers were removed from the security fix proposed last week. It is best described in the Forgejo blog post.

image

For the record, with permissions from @Gusted and for the sake of keeping Gitea users safe, the [Forgejo headers were removed](https://github.com/go-gitea/gitea/pull/27455/commits/73573258a5181779b55db99bc60918e3821df729) from the security fix proposed last week. It is best described in the [Forgejo blog post](https://forgejo.org/2023-10-release-v1-20-5-0/). 

wxiaoguang commented 2023年10月10日 14:52:39 +02:00

Message redacted by the Forgejo moderation team due to ad-hominem attacks.

_**Message redacted by the Forgejo moderation team due to ad-hominem attacks.**_ <!-- I think you have created too many lies to Gitea and Gitea's contributors, and really harmed Gitea. ## Why the issue title is `Gitea Ltd`? Is it really related to the Ltd? No. It seems that the Ltd becomes a weapon for you to criticize or even attack Gitea. IMO it is not a civilized behavior. The guideline is quite old and clear: [The contributing guideline has had this since 7 years ago](https://github.com/go-gitea/gitea/commit/a90b25226a4dae41c439f4d4919ef07e21b2ad43?short_path=eca12c0#diff-eca12c0a30e25b4b46522ebf89465a03ba72a03f540796c979137931d8f92055)  [And it has been updated to use SPDX format](https://github.com/go-gitea/gitea/blame/16a766cba10dcaf53cc413cee62a952031bef5bc/CONTRIBUTING.md#L430)  ## Does earl-warren really know nothing? quote: earl-warren said: "However, please understand this is news to me and do not claim .... that I could have been informed of this requirement in the past." https://github.com/go-gitea/gitea/pull/27455#issuecomment-1753251068 I do not think so. They already has not only one PR, like: * Add unit test for HashAvatar `#25662` https://github.com/go-gitea/gitea/pull/25662 * add Upload URL to release API `#26663` https://github.com/go-gitea/gitea/pull/26663 They just followed the suggestion, so it already means that they has been informed and should know the standard. Lying and keeping violating the informed standard is a kind of bad faith -- I guess most civilized people would agree. -->

fnetX commented 2023年10月10日 15:03:53 +02:00

@wxiaoguang in both pull requests you link, there was a discussion about the copyright header. It was not resolved in any of them, and in none of them was there a statement telling that it is a "hard requirement". Many other things in the contributing guidelines have seen exceptions for various situations.

The guideline makes sense in regard to developers contributing code to the software. It does not make sense for a good relationship between two projects. Forgejo has the right to develop the code with their own copyright header. And since Gitea is still developed in a proprietary walled platform, it makes sense that Forgejo forwards contributions via one account. Thank you @earl-warren for ensuring that improvements in Forgejo can also bring benefit to Gitea users. However, as discussed in the past, he is not in the position to simply remove such a header.

This is exactly what this issue is about: How should Forgejo proceed with this? There are patches that are marked to be upstreamed. I think, this is the point where the original author should be asked if they agree that the contribution is upstreamed with the modified license header. If they don't agree, the patch remains only in Forgejo - simply because Gitea has not really cared about the fork or their motivation since day one. And if they can't have a collaboration and accept such a license header, I don't see any reason to fight with them about it.

@wxiaoguang in both pull requests you link, there was a discussion about the copyright header. It was not resolved in any of them, and in none of them was there a statement telling that it is a "hard requirement". Many other things in the contributing guidelines have seen exceptions for various situations. The guideline makes sense in regard to developers contributing code to the software. It does not make sense for a good relationship between two projects. Forgejo has the right to develop the code with their own copyright header. And since Gitea is still developed in a proprietary walled platform, it makes sense that Forgejo forwards contributions via one account. Thank you @earl-warren for ensuring that improvements in Forgejo can also bring benefit to Gitea users. However, as discussed in the past, he is not in the position to simply remove such a header. This is exactly what this issue is about: How should Forgejo proceed with this? There are patches that are marked to be upstreamed. I think, this is the point where the original author should be asked if they agree that the contribution is upstreamed with the modified license header. If they don't agree, the patch remains only in Forgejo - simply because Gitea has not really cared about the fork or their motivation since day one. And if they can't have a collaboration and accept such a license header, I don't see any reason to fight with them about it.

fnetX commented 2023年10月10日 15:08:36 +02:00

I further recommend to update the issue title and remove the reference to the "Ltd.". It was clarified that the requirement comes from the Gitea project itself, not from the limited. It is a problem that such cases are not obvious, because there is a huge lack of transparency, but it is another discussion (which will not come to an agreement anyway, which is also the reason why we have the fork in the first place).

I further recommend to update the issue title and remove the reference to the "Ltd.". It was clarified that the requirement comes from the Gitea project itself, not from the limited. It is a problem that such cases are not obvious, because there is a huge lack of transparency, but it is another discussion (which will not come to an agreement anyway, which is also the reason why we have the fork in the first place).

wxiaoguang commented 2023年10月10日 15:16:18 +02:00

Message redacted by the Forgejo moderation team due to ad-hominem attacks.

_**Message redacted by the Forgejo moderation team due to ad-hominem attacks.**_ <!-- > Thank you @earl-warren for ensuring that improvements in Forgejo can also bring benefit to Gitea users. However, as discussed in the past, he is not in the position to simply remove such a header. TBH, I really worry about ~~your~~ the Forgejo's code quality, you can see how buggy ~~your~~ the PRs are (the closed ones: https://github.com/go-gitea/gitea/pulls?q=is%3Apr+author%3Aearl-warren+is%3Aclosed) Even some merged PRs, they also have bugs fixed during Gitea's review. If ~~you~~ the Forgejo don't understand programming well, just report bugs or suggest solutions, then there won't be argument. (update: "you" mean "the Forgejo", not a single person, I didn't mean to "personal attack") > .... simply because Gitea has spit on the fork since day one .... Who started thw war? Forgejo keep lying about Gitea, created the frictions. If the Forgejo guys could be civilized, stop lying, stop criticizing, there won't be any fight. -->

fnetX commented 2023年10月10日 15:27:52 +02:00

@wxiaoguang Please stay on topic. If you want to argue about code quality, create your separate discussion and also discuss the bugs and security issues that Forgejo fixes that have been missed during Gitea's code review.

Also, this is a warning in my position of the Codeberg moderation team. Please refrain from personal attacks. Statements like "see how buggy your PRs are" and "you don't understand programming well" are inappropriate. If we continue to observe this behaviour, further actions as of Codeberg's Terms of Use might follow.

@wxiaoguang Please stay on topic. If you want to argue about code quality, create your separate discussion and also discuss the bugs and security issues that Forgejo fixes that have been missed during Gitea's code review. Also, this is a warning in my position of the Codeberg moderation team. Please refrain from personal attacks. Statements like "see how buggy your PRs are" and "you don't understand programming well" are inappropriate. If we continue to observe this behaviour, further actions as of Codeberg's Terms of Use might follow.

wxiaoguang commented 2023年10月10日 15:30:53 +02:00

Sorry for the inappropriate wording. Here "you" doesn't mean a single person, I meant the "the Forgejo". I will not use this wording anymore. And I will update the comment (update: done)

Sorry for the inappropriate wording. Here "you" doesn't mean a single person, I meant the "the Forgejo". I will not use this wording anymore. And I will update the comment (update: done)

fnetX commented 2023年10月10日 15:33:25 +02:00

I also don't agree to a team being collectively dismissed as poor developers.

I also don't agree to a team being collectively dismissed as poor developers.

wxiaoguang commented 2023年10月10日 15:39:03 +02:00

I also don't agree to a team being collectively dismissed as poor developers.

I also don't agree that saying one's code is buggy is any kind of "personal attack", just like a teacher told a student "see how many mistakes you made in your homework" or "you don't understand the question, so the result is wrong".

---

Update: and you see "[Proposal] Suggest people to follow Code of Conduct forgejo/forgejo#403 " , we have already discussed that saying "don't understand" is (削除) fine (削除ここまで) not too terrible, right? So no personal attack.

> I also don't agree to a team being collectively dismissed as poor developers. I also don't agree that saying one's code is buggy is any kind of "personal attack", just like a teacher told a student "see how many mistakes you made in your homework" or "you don't understand the question, so the result is wrong". ---- Update: and you see "[Proposal] Suggest people to follow Code of Conduct https://codeberg.org/forgejo/forgejo/issues/403 " , we have already discussed that saying "don't understand" is ~~fine~~ not too terrible, right? So no personal attack.

jolheiser commented 2023年10月10日 16:57:30 +02:00

To my knowledge, none of the other projects that have contributed to Gitea have had a problem with this license header, moreover I/we don't want to make an exception for a single project, regardless of history.

It seems the current summary is to ask each PR author whether they are okay with their patch being sent upstream, which I think is fine. I certainly would hope many would do so, but I understand this is >0 friction, which is undesirable.

To my knowledge, none of the other projects that have contributed to Gitea have had a problem with this license header, moreover I/we don't want to make an exception for a single project, regardless of history. It seems the current summary is to ask each PR author whether they are okay with their patch being sent upstream, which I think is fine. I certainly would hope many would do so, but I understand this is >0 friction, which is undesirable.

earl-warren commented 2023年10月10日 17:40:55 +02:00

That's a good summary of the situation. I'm glad this is clarified and I'm sure there won't be any confusion in the future. 👍

That's a good summary of the situation. I'm glad this is clarified and I'm sure there won't be any confusion in the future. 👍

earl-warren commented 2023年10月10日 17:51:47 +02:00

none of the other projects that have contributed to Gitea have had a problem with this license header,

@jolheiser just for the sake of precision and clarity, this discussion is not about a problem with the Gitea license header, if that's what you meant by "this license", i.e.:

// Copyright 2023 The Gitea Authors. All rights reserved.
// SPDX-License-Identifier: MIT

It is fine and has been consistently inserted in all PRs I authored where appropriate, in accordance to the contribution guidelines.

This discussion is exclusively about the requirement to remove all other copyright headers. But again, now that it is clarified, everyone knows where to stand.

> none of the other projects that have contributed to Gitea have had a problem with this license header, @jolheiser just for the sake of precision and clarity, this discussion is not about a problem with the Gitea license header, if that's what you meant by "this license", i.e.: ``` // Copyright 2023 The Gitea Authors. All rights reserved. // SPDX-License-Identifier: MIT ``` It is fine and has been consistently inserted in all PRs I authored where appropriate, in accordance to the contribution guidelines. This discussion is exclusively about the requirement to **remove** all other copyright headers. But again, now that it is clarified, everyone knows where to stand.

jolheiser commented 2023年10月10日 18:36:25 +02:00

I am aware, and my statement stands. I guess I can't say for sure whether other projects added their own in the first place, so perhaps that's vaguely different. But even so, I/we wouldn't want to make exceptions for other projects that decide to add their own header, either.

I will again concede that it's >0 friction, however I don't have a better solution to offer.

---

Another option would be to have some form of agreement in place that any PRs to Forgejo are also accepting terms that the PR can be upstreamed.
However, based on the general disposition I've seen I don't think that's a realistic proposal.

I am aware, and my statement stands. I guess I can't say for sure whether other projects added their own in the first place, so perhaps that's vaguely different. But even so, I/we wouldn't want to make exceptions for other projects that decide to add their own header, either. I will again concede that it's >0 friction, however I don't have a better solution to offer. --- Another option would be to have some form of agreement in place that any PRs to Forgejo are also accepting terms that the PR can be upstreamed. However, based on the general disposition I've seen I don't think that's a realistic proposal.

earl-warren commented 2023年10月10日 19:36:54 +02:00

...some form of agreement in place that any PRs to Forgejo are also accepting terms that the PR can be upstreamed.

Such an agreement would require all Forgejo contributors to never be named as the authors of their work, even if they are so inclined. That's the only thing preventing MIT licensed code from entering the Gitea codebase. There is nothing else standing in the way.

However, based on the general disposition I've seen I don't think that's a realistic proposal.

It is indeed unrealistic, not because of a general disposition, but because it is a legal impossibility and serves no useful purpose.

Forgejo cannot require that the author of a copyrighted work is forbidden to state their name (or pseudonym) as a condition to their contribution because it is a moral right that cannot be waived. As @caesar pointed out elsewhere, it is the only thing the MIT license requires to preserve:

Copyright (c) <year> <copyright holders>
...
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

In addition, there is no rationale Forgejo could present to the contributors to justify such a unique policy on copyright headers:

• contributions are already subject to the DCO which provides a solid legal insurance for all code that enters the Forgejo codebase
• it won't make Forgejo stronger from a legal standpoint
• it does not address a copyright header proliferation that can be demonstrated anywhere to a scale that requires action
• it cannot be consistently enforced on all the codebase because it would prevent importing MIT licensed code from other projects

> ...some form of agreement in place that any PRs to Forgejo are also accepting terms that the PR can be upstreamed. Such an agreement would require all Forgejo contributors to never be named as the authors of their work, even if they are so inclined. That's the only thing preventing MIT licensed code from entering the Gitea codebase. There is nothing else standing in the way. > However, based on the general disposition I've seen I don't think that's a realistic proposal. It is indeed unrealistic, not because of a general disposition, but because it is a legal impossibility and serves no useful purpose. Forgejo cannot require that the author of a copyrighted work is forbidden to state their name (or pseudonym) as a condition to their contribution because it is a [moral right](https://en.wikipedia.org/wiki/Moral_rights) that cannot be waived. As @caesar pointed out elsewhere, it is the **only** thing [the MIT license](https://en.wikipedia.org/wiki/MIT_License) requires to preserve: ``` Copyright (c) <year> <copyright holders> ... The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. ``` In addition, there is no rationale Forgejo could present to the contributors to justify such a unique policy on copyright headers: * contributions are already subject to the [DCO](https://forgejo.org/docs/next/developer/dco/) which provides a solid legal insurance for all code that enters the Forgejo codebase * it won't make Forgejo stronger from a legal standpoint * it does not address a copyright header proliferation that can be demonstrated anywhere to a scale that requires action * it cannot be consistently enforced on all the codebase because it would prevent importing MIT licensed code from other projects

jolheiser commented 2023年10月10日 19:51:40 +02:00

It was simply an alternative, and one I expected would not be accepted for a myriad of reasons. 👍
I will discontinue unless new discussion is required in order to avoid circling too much.

It was simply an alternative, and one I expected would not be accepted for a myriad of reasons. 👍 I will discontinue unless new discussion is required in order to avoid circling too much.

earl-warren commented 2023年10月10日 21:02:50 +02:00

I think you have created too many lies to Gitea and Gitea's contributors, and really harmed Gitea.

This is an ad-hominem attack and I reported this message to abuse@codeberg.org. These are unfounded accusations, I never did and never will do anything of the kind.

quote: earl-warren said: "However, please understand this is news to me and do not claim .... that I could have been informed of this requirement in the past." https://github.com/go-gitea/gitea/pull/27455#issuecomment-1753251068

I do not think so.

They already has not only one PR, like:

• Add unit test for HashAvatar #25662 https://github.com/go-gitea/gitea/pull/25662
• add Upload URL to release API #26663 https://github.com/go-gitea/gitea/pull/26663

They just followed the suggestion, so it already means that they has been informed and should know the standard.

I always follow reviewers suggestions when I can, even if I do not fully understand the reasons. In these cases I checked the guidelines for a requirement to remove all copyright headers except Gitea. I found that it was not a mentioned anywhere. But since these PRs did not contain any copyrighted material (they both lack originality, without which you can't have copyright), I complied with the request anyway. I was not inclined to start a discussion on the contribution policy at this time and it was not required.

Did I suspect a discussion would eventually happen over these repeated requests to remove Forgejo copyright headers? Sure. Did I know about an unwritten policy that has never been articulated anywhere and never enforced before? Absolutely not. And how could I? The rationale that justifies its existence does not make any sense to me and I was quite surprised when it was clarified that it is in fact a policy to be enforced. But it is the Gitea policy and I accept it as a fact. If I was to argue about it, I would do so in Gitea spaces, not in Forgejo spaces.

Lying and keeping violating the informed standard is a kind of bad faith -- I guess most civilized people would agree.

Calling me a liar, saying I acted in bad faith is not a behavior that I tolerate. It has no place in Forgejo spaces and goes against the code of conduct. It falls in the category of derogatory comments and personal attacks:

Examples of unacceptable behavior include:

Trolling, insulting or derogatory comments, and personal or political attacks

Not only is it stressful for me to be accused in such a way, it also creates a toxic environment for everyone reading and is detrimental to Forgejo as a whole. If you think someone is lying, kindly ask for their side of the story. And, as it is the case now, you will often discover a different viewpoint that may very well change your opinion.

> I think you have created too many lies to Gitea and Gitea's contributors, and really harmed Gitea. This is an ad-hominem attack and I reported this message to abuse@codeberg.org. These are unfounded accusations, I never did and never will do anything of the kind. > quote: earl-warren said: "However, please understand this is news to me and do not claim .... that I could have been informed of this requirement in the past." https://github.com/go-gitea/gitea/pull/27455#issuecomment-1753251068 > > I do not think so. > > They already has not only one PR, like: > > * Add unit test for HashAvatar `#25662` https://github.com/go-gitea/gitea/pull/25662 > * add Upload URL to release API `#26663` https://github.com/go-gitea/gitea/pull/26663 > > They just followed the suggestion, so it already means that they has been informed and should know the standard. > I always follow reviewers suggestions when I can, even if I do not fully understand the reasons. In these cases I checked the guidelines for a requirement to remove all copyright headers except Gitea. I found that it was not a mentioned anywhere. But since these PRs did not contain any copyrighted material (they both lack originality, without which you can't have copyright), I complied with the request anyway. I was not inclined to start a discussion on the contribution policy at this time and it was not required. Did I suspect a discussion would eventually happen over these repeated requests to remove Forgejo copyright headers? Sure. Did I know about an unwritten policy that has never been articulated anywhere and never enforced before? Absolutely not. And how could I? The rationale that justifies its existence does not make any sense to me and I was quite surprised when it was clarified that it is in fact a policy to be enforced. But it is the Gitea policy and I accept it as a fact. If I was to argue about it, I would do so in Gitea spaces, not in Forgejo spaces. > Lying and keeping violating the informed standard is a kind of bad faith -- I guess most civilized people would agree. Calling me a liar, saying I acted in bad faith is not a behavior that I tolerate. It has no place in Forgejo spaces and goes against the [code of conduct](https://forgejo.org/code-of-conduct/#our-standards). It falls in the category of derogatory comments and personal attacks: > Examples of unacceptable behavior include: > > Trolling, insulting or derogatory comments, and personal or political attacks Not only is it stressful for me to be accused in such a way, it also creates a toxic environment for everyone reading and is detrimental to Forgejo as a whole. If you think someone is lying, kindly ask for their side of the story. And, as it is the case now, you will often discover a different viewpoint that may very well change your opinion.

caesar commented 2023年10月10日 22:45:49 +02:00

@jolheiser just to further clarify, since you seem to equate upstreaming of code from Forgejo with direct contributions to Gitea: there is a big difference legally. Just as Gitea contains Gogs license headers because it contains Gogs code, if Forgejo code were to be incorporated it would be a requirement of the MIT license that the Forgejo license header be maintained (unless the author of the code authorizes it to be changed).
The same goes the other way: we would not be entitled to remove the Gitea license header from the Gitea code we use, either.
It's very different from the situation where someone contributes their code directly to a project, and implicitly (or explicitly) accepts a specific form of attribution.

@jolheiser just to further clarify, since you seem to equate upstreaming of code from Forgejo with direct contributions to Gitea: there is a big difference legally. Just as Gitea contains Gogs license headers because it contains Gogs code, if Forgejo code were to be incorporated it would be a requirement of the MIT license that the Forgejo license header be maintained (unless the author of the code authorizes it to be changed). The same goes the other way: we would not be entitled to remove the Gitea license header from the Gitea code we use, either. It's very different from the situation where someone contributes their code directly to a project, and implicitly (or explicitly) accepts a specific form of attribution.

wxiaoguang commented 2023年10月11日 01:28:20 +02:00

Did I suspect a discussion would eventually happen over these repeated requests to remove Forgejo copyright headers? Sure. Did I know about an unwritten policy that has never been articulated anywhere and never enforced before? Absolutely not. And how could I? The rationale that justifies its existence does not make any sense to me and I was quite surprised when it was clarified that it is in fact a policy to be enforced. But it is the Gitea policy and I accept it as a fact. If I was to argue about it, I would do so in Gitea spaces, not in Forgejo spaces.

Calling me a liar, saying I acted in bad faith is not a behavior that I tolerate. It has no place in Forgejo spaces and goes against the code of conduct. It falls in the category of derogatory comments and personal attacks:

The definition of "lie": "an intentionally false statement" or "a statement made by somebody knowing that it is not true" (from dictionary, anyone who is interested could look it up in dictionaries)

Let's see what happens in an old PR: add Upload URL to release API #26663, https://github.com/go-gitea/gitea/pull/26663 let's read it line by line:

Hi earl-warren please remove this line, we have given this feedback to you previously

not the first time

and also is stated what new files should have in our contributing.md.

it shows the correct reference.

This is following advice given to us from The Linux Foundation.

it has a clear example, and that's how modern / civilized / great projects do.

Many others are able to contribute to the project following the contributing.md, and we don't have // Copyright Allspice, //Copyright Blender, //Copyright ... etc.. there are literally hundreds of orgs that contribute to this project.

this example is even clear: do not include other header, all orgs use the same standard.

The project appreciates you upstreaming some of the code, however, if you aren't able to follow the contribution documentation we can't make a special exception just for you. By continuously knowingly ignoring the contributing documentation we may need to take action.

everything has been explained and you have been warned kindly.

---

If a person doesn't have difficulty in reading English, I think these comments are clear enough, that's not like some of you said: it is news, not been informed, It was not resolved in any of them, and in none of them was there a statement telling that it is a "hard requirement".

Selectively ignoring the the comments and keeping acting behaviors against it but saying "not be informed", it matches the definition of "lie": "an intentionally false statement".

> Did I suspect a discussion would eventually happen over these repeated requests to remove Forgejo copyright headers? Sure. Did I know about an unwritten policy that has never been articulated anywhere and never enforced before? Absolutely not. And how could I? The rationale that justifies its existence does not make any sense to me and I was quite surprised when it was clarified that it is in fact a policy to be enforced. But it is the Gitea policy and I accept it as a fact. If I was to argue about it, I would do so in Gitea spaces, not in Forgejo spaces. > > Calling me a liar, saying I acted in bad faith is not a behavior that I tolerate. It has no place in Forgejo spaces and goes against the [code of conduct](https://forgejo.org/code-of-conduct/#our-standards). It falls in the category of derogatory comments and personal attacks: The definition of "lie": "an intentionally false statement" or "a statement made by somebody knowing that it is not true" (from dictionary, anyone who is interested could look it up in dictionaries) Let's see what happens in an old PR: ` add Upload URL to release API #26663 `, https://github.com/go-gitea/gitea/pull/26663 let's read it line by line: > Hi earl-warren please remove this line, we have given this feedback to you previously not the first time > and also is stated what new files should have in our contributing.md. it shows the correct reference. > This is following advice given to us from The Linux Foundation. it has a clear example, and that's how modern / civilized / great projects do. > Many others are able to contribute to the project following the contributing.md, and we don't have // Copyright Allspice, //Copyright Blender, //Copyright ... etc.. there are literally hundreds of orgs that contribute to this project. this example is even clear: do not include other header, all orgs use the same standard. > The project appreciates you upstreaming some of the code, however, if you aren't able to follow the contribution documentation we can't make a special exception just for you. By continuously knowingly ignoring the contributing documentation we may need to take action. everything has been explained and you have been warned kindly. ---- If a person doesn't have difficulty in reading English, I think these comments are clear enough, that's not like some of you said: `it is news`, `not been informed`, `It was not resolved in any of them, and in none of them was there a statement telling that it is a "hard requirement". ` Selectively ignoring the the comments and keeping acting behaviors against it but saying "not be informed", it matches the definition of "lie": "an intentionally false statement".

caesar commented 2023年10月11日 12:08:04 +02:00

@wxiaoguang please desist from making ad-hominem attacks in the Forgejo spaces. Your comments are in clear violation of our Code of Conduct and you have been warned repeatedly.

@wxiaoguang please desist from making ad-hominem attacks in the Forgejo spaces. Your comments are in clear violation of [our Code of Conduct](https://codeberg.org/forgejo/code-of-conduct/) and you have been warned repeatedly.

KaKi87 commented 2023年11月04日 10:29:37 +01:00

I noticed that, in some files, a secondary group of comments is added, like in this one : identicon.go

// Copyright 2021 The Gitea Authors. All rights reserved.
// SPDX-License-Identifier: MIT
// Copied and modified from https://github.com/issue9/identicon/ (MIT License)
// Generate pseudo-random avatars by IP, E-mail, etc.

The source project and its license is mentioned.

Maybe that's what could be done for Forgejo contributions.

I noticed that, in some files, a secondary group of comments is added, like in this one : [`identicon.go`](https://github.com/go-gitea/gitea/blob/da0c4b8d10cce85c854370ae3c399b542cb04306/modules/avatar/identicon/identicon.go) ``` // Copyright 2021 The Gitea Authors. All rights reserved. // SPDX-License-Identifier: MIT // Copied and modified from https://github.com/issue9/identicon/ (MIT License) // Generate pseudo-random avatars by IP, E-mail, etc. ``` The source project and its license is mentioned. Maybe that's what could be done for Forgejo contributions.

tsalin commented 2023年11月23日 14:54:55 +01:00

I just stumbled over this issue by chance, however have been in contact with similar ones in the past, so maybe my 2¢ can help a bit.

We've three major points to address here: licensing, copyright (which mainly means how to economically make or make not use of sth), attribution of authorship (which might also come with certain rights attached). A major issue is that as for most bigger projects more than one jurisdiction applies, as the contributors may fall under a different one than codeberg, the upstream submitter, than gitea, than direct gitea submitters. This means that terms like "copyright" or "attribution of ownership" can have very different meanings or interpretations.

• The licensing isn't a discussion point here, so I won't go into details.

• the copyright has been assigned to "the Gitea authors" at least additionally in the past and also in the merge mentioned in this issue, so I assume that this hasn't been an issue for anyone. As I do not imagine that any contracts about what this would mean in conflict situations exist, I guess it remains partially unclear what rights have been transferred to gitea and what stayed within other's rights. There are quite some similar situations for a lot of software though, which might give hints on what's to be expected. Also the MIT license grants vast rights to the usage of the code, so I don't think this should be a major point.

• The attribution of ownership is mostly solved indirectly by mentioning a semi-specified group of people within the copyright. I'm assuming that as long as both of the groups (Gitea authors + Forgejo authors) are mentioned, the Forgejo contributors would be fine with this, as they seem to have been before. This whole point usually is a very tricky part, as liabilities, attribution and ownership itself might be contractually or legally bound in very different ways, depending on your individual situation.

However, the required removal of the 2nd copyright notice now removes the attribution of ownership directly within the source for anyone not falling into the group of "the Gitea authors". So we're directly touching this tricky part. :) I think for most jurisdictions I'm aware of, this at least can't be done without author's consent. So I assume that this might lead to one of these different solutions:

1. the authors agree and gitea accepts the contributing authors to be included in the group of "the Gitea authors", leading to patches can continue to be provided by the forgejo project.
2. the gitea project accepts additional authors within the source of any patch in some meaningful way, leading to the same options.
3. the forgejo authors allow their attribution to be dropped in cases like this, leading to the same options.
4. only the original authors itself directly commit to the gitea project, with the forgejo project not directly acting on the source in this case. --> nothing to be solved here.
5. the gitea project acts instead of the forgejo project by integrating the source via using the MIT license. Any additional copyright notices would have to be kept, then. This is the same as gitea also seems to do / have done for files from go.

I expect that option 3) would be the most preferred for gitea, but I think it to be the least possible, as that directly touches the tricky part, and thus might block authors from contributing at all in the first place.
No preferences from my side - I'm not an author for any related sw - , and maybe I missed some options, but maybe someone finds help in my thoughts.

I just stumbled over this issue by chance, however have been in contact with similar ones in the past, so maybe my 2¢ can help a bit. We've three major points to address here: licensing, copyright (which mainly means how to economically make or make not use of sth), attribution of authorship (which might also come with certain rights attached). A major issue is that as for most bigger projects more than one jurisdiction applies, as the contributors may fall under a different one than codeberg, the upstream submitter, than gitea, than direct gitea submitters. This means that terms like "copyright" or "attribution of ownership" can have very different meanings or interpretations. - The licensing isn't a discussion point here, so I won't go into details. - the copyright has been assigned to "the Gitea authors" at least additionally in the past and also in the merge mentioned in this issue, so I assume that this hasn't been an issue for anyone. As I do not imagine that any contracts about what this would mean in conflict situations exist, I guess it remains partially unclear what rights have been transferred to gitea and what stayed within other's rights. There are quite some similar situations for a lot of software though, which might give hints on what's to be expected. Also the MIT license grants vast rights to the usage of the code, so I don't think this should be a major point. - The attribution of ownership is mostly solved indirectly by mentioning a semi-specified group of people within the copyright. I'm assuming that as long as both of the groups (Gitea authors + Forgejo authors) are mentioned, the Forgejo contributors would be fine with this, as they seem to have been before. This whole point usually is a very tricky part, as liabilities, attribution and ownership itself might be contractually or legally bound in very different ways, depending on your individual situation. However, the required removal of the 2nd copyright notice now removes the attribution of ownership directly within the source for anyone not falling into the group of "the Gitea authors". So we're directly touching this tricky part. :) I think for most jurisdictions I'm aware of, this at least can't be done without author's consent. So I assume that this might lead to one of these different solutions: 1. the authors agree and gitea accepts the contributing authors to be included in the group of "the Gitea authors", leading to patches can continue to be provided by the forgejo project. 2. the gitea project accepts additional authors within the source of any patch in some meaningful way, leading to the same options. 3. the forgejo authors allow their attribution to be dropped in cases like this, leading to the same options. 4. only the original authors itself directly commit to the gitea project, with the forgejo project not directly acting on the source in this case. --> nothing to be solved here. 5. the gitea project acts instead of the forgejo project by integrating the source via using the MIT license. Any additional copyright notices would have to be kept, then. This is the same as gitea also seems to do / have done for files from go. I expect that option 3) would be the most preferred for gitea, but I think it to be the least possible, as that directly touches the tricky part, and thus might block authors from contributing at all in the first place. No preferences from my side - I'm not an author for any related sw - , and maybe I missed some options, but maybe someone finds help in my thoughts.

earl-warren commented 2023年11月23日 17:30:58 +01:00

I find this is an excellent summary of the situation.

I find this is an excellent summary of the situation.

forgejo-moderation commented 2024年01月08日 13:03:27 +01:00

A message was deleted, send a mail to moderation@forgejo.org for more information.

A message was deleted, send a mail to moderation@forgejo.org for more information.

forgejo-moderation commented 2024年01月10日 10:06:05 +01:00

A message from an account created to circumvent a ban from Forgejo spaces was deleted, send a mail to moderation@forgejo.org for more information.

A message from an account created to circumvent a ban from Forgejo spaces was deleted, send a mail to moderation@forgejo.org for more information.

lunny commented 2024年12月15日 09:14:33 +01:00

One year later, wouldn't you have followed Gitea's contribution guide?
Have you allowed contributions to have third-party copyright?

One year later, wouldn't you have followed Gitea's contribution guide? Have you allowed contributions to have third-party copyright?