forgejo/discussions
49
43

Upgrade v9.0 license to GPLv3+ #201

Closed
opened 2024年07月25日 10:20:24 +02:00 by Ghost · 19 comments

There are pull requests that have copyleft code and they are blocked because they depend on updates of the documentation, repository and website for the transition. I will propose pull requests for that because I want to add GPLv3+ code to Forgejo as soon as possible.

There are pull requests that have copyleft code and they are blocked because they depend on updates of the documentation, repository and website for the transition. I will propose pull requests for that because I want to add GPLv3+ code to Forgejo as soon as possible. - Agreement to allow GPLv3+ contributions to Forgejo https://codeberg.org/forgejo/governance/src/branch/main/AGREEMENTS.md#licensing - ~~https://codeberg.org/forgejo/docs PR~~ - https://codeberg.org/forgejo/forgejo/pulls/4684 - https://codeberg.org/forgejo/website/pulls/464

There is no reference to the Forgejo license in the documentation. The documentation itself is released under its own license https://codeberg.org/forgejo/docs. There is no need for an update.

There is no reference to the Forgejo license in the documentation. The documentation itself is released under its own license https://codeberg.org/forgejo/docs. There is no need for an update.

I'd like to raise an issue with this change. There are people who'd like to contribute (and already do in tests) under EUPLv1.2.

This license is not compatible with or later variants of GPL.

pinging @algernon and @Gusted who I believe have PRs with EUPL in tests open.

I'd like to raise an issue with this change. There are people who'd like to contribute (and already do in tests) under EUPLv1.2. This license is not compatible with `or later` variants of GPL. pinging @algernon and @Gusted who I believe have PRs with EUPL in tests open.

There is a discussion on this topic at #192

There is a discussion on this topic at https://codeberg.org/forgejo/discussions/issues/192

@thefox @Beowulf there has been a standing agreement that allows for GPLv3+ to enter the Forgejo codebase for over a year. It is unambiguous and clear in that regard.

If someone wants to use a license and has reason to believe it is not compatible with GPLv3+, it certainly is a discussion worth having and #192 is a good forum for that. But it is not a compelling reason to block GPLv3+ code from entering Forgejo and go back on an existing agreement. Specially given how many weeks it took to reach this agreement.

Can we continue this discussion on #192 and keep this one focused on the implementation of the existing agreement?

@thefox @Beowulf there has been a standing agreement that allows for GPLv3+ to enter the Forgejo codebase for over a year. It is unambiguous and clear in that regard. If someone wants to use a license and has reason to believe it is not compatible with GPLv3+, it certainly is a discussion worth having and https://codeberg.org/forgejo/discussions/issues/192 is a good forum for that. But it is not a compelling reason to block GPLv3+ code from entering Forgejo and go back on an existing agreement. Specially given how many weeks it took to reach this agreement. Can we continue this discussion on https://codeberg.org/forgejo/discussions/issues/192 and keep this one focused on the implementation of the existing agreement?
Member
Copy link

My reaction was based on the fact that it is confusing if we make a blog post now and change the license and then write a few weeks or months later, oh no license has changed again.

And based on #192 there are the following main points:

  1. The decision is partly confusing.
  2. There is a consent that at least EUPL-1.2 should be allowed - and there is already code pending, which is licensed under EUPL-1.2 (which is incompatible with -or-later)

To cite @Gusted:

The addition of -or-later seems like to not have a strong motivation
[...]
Given now that we're actually making use of this agreement, it doesn't seem to live up to the intention of the agreement as it's causing more problems than it should.

If you want to go that way, ok, I I just think it will lead to more chaos. 🤔

My reaction was based on the fact that it is confusing if we make a blog post now and change the license and then write a few weeks or months later, oh no license has changed again. And based on #192 there are the following main points: 1. The decision is partly confusing. 2. There is a consent that at least EUPL-1.2 should be allowed - and there is already code pending, which is licensed under EUPL-1.2 (which is incompatible with `-or-later`) To cite @Gusted: > The addition of -or-later seems like to not have a strong motivation > [...] > Given now that we're actually making use of this agreement, it doesn't seem to live up to the intention of the agreement as it's causing more problems than it should. If you want to go that way, ok, I I just think it will lead to more chaos. 🤔

A thought: these changes are a noop and can be removed by anyone cloning the repository, because they do not match anything published under GPLv3+ in the codebase. But they are a necessary for GPLv3+ code to be merged in the codebase. And as soon as it happens, they will no longer be a noop. That's an interesting situation 🤔

A thought: these changes are a noop and can be removed by anyone cloning the repository, because they do not match anything published under GPLv3+ in the codebase. But they are a necessary for GPLv3+ code to be merged in the codebase. And as soon as it happens, they will no longer be a noop. That's an interesting situation 🤔
  1. There is a consent that at least EUPL-1.2 should be allowed - and there is already code pending, which is licensed under EUPL-1.2 (which is incompatible with -or-later)

I think the reasoning here is incorrect, and the reason for that is the main point that makes all of this seem so complicated.

  1. EUPL-1.2 can be relicensed to GPL-3.0-only (Compatibility clause)
  2. GPL-3.0-only is compatible with GPL-3.0-or-later. (See GNU compatibility matrix)

So, EUPL-1.2 is compatible with GPL-3.0-or-later, but the license produced by combining EUPL-1.2 and GPL-3.0-or-later code will be GPL-3.0-only.

#192 goes into great detail about this, #192 (comment) in particular.

> 2. There is a consent that at least EUPL-1.2 should be allowed - and there is already code pending, which is licensed under EUPL-1.2 (which is incompatible with `-or-later`) I think the reasoning here is incorrect, and the reason for that is the main point that makes all of this seem so complicated. 1. `EUPL-1.2` can be relicensed to GPL-3.0-only ([Compatibility clause](https://joinup.ec.europa.eu/sites/default/files/custom-page/attachment/2020-03/EUPL-1.2%20EN.txt)) 2. `GPL-3.0-only` is compatible with `GPL-3.0-or-later`. ([See GNU compatibility matrix](https://www.gnu.org/licenses/gpl-faq.html#compat-matrix-footnote-2)) So, `EUPL-1.2` _is_ compatible with `GPL-3.0-or-later`, but the license produced by combining `EUPL-1.2` and `GPL-3.0-or-later` code will be `GPL-3.0-only`. #192 goes into great detail about this, https://codeberg.org/forgejo/discussions/issues/192#issuecomment-2099254 in particular.
Member
Copy link
  1. There is a consent that at least EUPL-1.2 should be allowed - and there is already code pending, which is licensed under EUPL-1.2 (which is incompatible with -or-later)

I think the reasoning here is incorrect, and the reason for that is the main point that makes all of this seem so complicated.

No, because this suggest to change the resulting license to GPLv3+ (e.g. forgejo/forgejo#4684/files) -> EUPL not allowed

> > 2. There is a consent that at least EUPL-1.2 should be allowed - and there is already code pending, which is licensed under EUPL-1.2 (which is incompatible with `-or-later`) > > I think the reasoning here is incorrect, and the reason for that is the main point that makes all of this seem so complicated. No, because this suggest to change the resulting license to GPLv3+ (e.g. https://codeberg.org/forgejo/forgejo/pulls/4684/files) -> EUPL not allowed

My mistake, I thought you were referring to the compatibility of having both licensed in the same project, not the license that this PR introduces.

My mistake, I thought you were referring to the compatibility of having both licensed in the same project, not the license that this PR introduces.

@Beowulf I'd be happy to debate this with you in #192. And you are welcome to engage in the decision making process to amend the current agreement. But you cannot block its implementation based on hypotheticals.

If that was to happen, the entire decision making process would be ineffective. For instance I could raise concerns about the pull request merge requirements and their potential impact on the future of Forgejo. If by doing so I could stop pull requests to be merged, that would not be a good outcome. Forgejo can only move forward if the agreements can be relied on in a durable way. If they are fragile and can be blocked at any time, there would be no point in having them in the first place.

@Beowulf I'd be happy to debate this with you in #192. And you are welcome to engage in the decision making process to amend the current agreement. But you cannot block its implementation based on hypotheticals. If that was to happen, the entire decision making process would be ineffective. For instance I could raise concerns about the pull request merge requirements and their potential impact on the future of Forgejo. If by doing so I could stop pull requests to be merged, that would not be a good outcome. Forgejo can only move forward if the agreements can be relied on in a durable way. If they are fragile and can be blocked at any time, there would be no point in having them in the first place.
Owner
Copy link

I know this adds additional effort, but I recommend to split this in two chunks:

  • update communication to be honest to end users and indicate our license is subject to change (e.g. "we are currently licensed under MIT" and similar)
  • announce the actual license once the discussions have settled down a little

It will allow being transparent and honest to users earlier, while not discouraging contributors. I believe that a big aspect of current heat is that there are some people moving forward with implementation (such as opening this issue), while others still feel a need to talk more, and moving forward is likely to give a feeling of being disregarded.

I know this adds additional effort, but I recommend to split this in two chunks: - update communication to be honest to end users and indicate our license is subject to change (e.g. "we are **currently** licensed under MIT" and similar) - announce the actual license once the discussions have settled down a little It will allow being transparent and honest to users earlier, while not discouraging contributors. I believe that a big aspect of current heat is that there are some people moving forward with implementation (such as opening this issue), while others still feel a need to talk more, and moving forward is likely to give a feeling of being disregarded.
Owner
Copy link

Further, I recommend to also do this:

I had a lengthy chat with a person considering to move from Gitea to Forgejo. They are active in an ecosystem that is mostly permissively licensed and concerned about copyleft. I think it is not sufficiently on our radar that there are such communities around, because they don't have much contact points with Forgejo at the moment.

Their primary concern seems about implications due to strict copyleft licenses, some of them also originating from misunderstanding to my knowledge.

Whatever we do, we should try to write a good explanation of what this means to our users. We cannot do legal advice of course, but we should try to clarify some common misunderstandings (and find out about them in the first place). I believe this is crucial to make Forgejo accessible to a community that avoids copyleft not due to a strict ideological stance, but simply because they don't know about the implications and don't want to "take any risk" in terms of licensing.

Further, I recommend to also do this: I had a lengthy chat with a person considering to move from Gitea to Forgejo. They are active in an ecosystem that is mostly permissively licensed and concerned about copyleft. I think it is not sufficiently on our radar that there are such communities around, because they don't have much contact points with Forgejo at the moment. Their primary concern seems about implications due to strict copyleft licenses, some of them also originating from misunderstanding to my knowledge. Whatever we do, we should try to write a good explanation of what this means to our users. We cannot do legal advice of course, but we should try to clarify some common misunderstandings (and find out about them in the first place). I believe this is crucial to make Forgejo accessible to a community that avoids copyleft not due to a strict ideological stance, but simply because they don't know about the implications and don't want to "take any risk" in terms of licensing.

Let's wait for #192 to be concluded. That will be smoother.

Let's wait for #192 to be concluded. That will be smoother.

As #192 is going to take time, I'd like my future contributions to be GPLv3+ from then on, taking advantage of the standing agreement, which is something I've been meaning to do for a year. And now I find is a good time to do so.

As #192 is going to take time, I'd like my future contributions to be GPLv3+ from then on, taking advantage of the standing agreement, which is something I've been meaning to do for a year. And now I find is a good time to do so. * Forgejo pull request * Updating licensing information https://codeberg.org/forgejo/forgejo/pulls/4737 * GPLv3+ code https://codeberg.org/forgejo/forgejo/pulls/4698 * Website pull request https://codeberg.org/forgejo/website/pulls/467

forgejo/forgejo#4698 is my first GPLv3+ contribution. Only the tests are GPLv3+, the rest is not copyrightable (lacks originality). It can only be merged if forgejo/forgejo#4737 is merged first. The binaries are not impacted by the license change but the license of the repository and the artifacts that contain the repository are because they contain the source files.

https://codeberg.org/forgejo/forgejo/pulls/4698 is my first GPLv3+ contribution. Only the tests are GPLv3+, the rest is not copyrightable (lacks originality). It can only be merged if https://codeberg.org/forgejo/forgejo/pulls/4737 is merged first. The binaries are not impacted by the license change but the license of the repository and the artifacts that contain the repository are because they contain the source files.

IMHO, LGPLv3+ is better choice even for application. Because LGPL code also can't be closed or "relicensed". And it can be copy-pasted to other LGPL project. You can't copy-paste GPL code to LGPL project.

IMHO, LGPLv3+ is better choice even for application. Because LGPL code also can't be closed or "relicensed". And it can be copy-pasted to other LGPL project. You can't copy-paste GPL code to LGPL project.

It can if it's networked, same as GPL. But it would be better if you shared your opinion in the actual discussion on amending the existing agreement

It can if it's networked, same as GPL. But it would be better if you shared your opinion in [the actual discussion on amending the existing agreement](https://codeberg.org/forgejo/discussions/issues/192)

There is a standing agreement to allow GPLv3+ contributions to Forgejo https://codeberg.org/forgejo/governance/src/branch/main/AGREEMENTS.md#licensing and the following pull requests are (i) documenting this decision and (ii) merging the first GPLv3+ code in the source tree.

I have read all discussions related to licensing and understand there are diverging opinions on how Forgejo's future will look like. I also believe there are no blockers to carry on with the current agreement, in the way proposed in these pull requests. I am convinced they are clear, unambiguous and future proof. However, I also get the impression that some Forgejo contributors have strong feelings on the matter and for that reason I would like to give them the opportunity to block the current agreement before these pull requests are merged.

To do so, please articulate a logical reasoning based on hard facts, as clearly as possible.

The Forgejo decision making process is the cornerstone of its governance and when an agreement is reached, every user and contributor can rely on it to be durable and usable. However, if there is overwhelming evidence that an existing agreement is undermining Forgejo, common sense dictates that it is blocked, for the good of the project.

If such reasoning is not presented within two weeks, I will keep moving forward based on the current agreement and Forgejo license will be upgraded from MIT to GPLv3+.

That step will not be the end of the discussion and I will advocate that the Forgejo license needs to evolve. I fully expect this discussion will take a very long time, no less than a year, maybe two or three. Because it is a difficult topic for which no Forgejo contributor claims a legal expertise. And also because it is grounded in our personal philosophical views and reaching a consensus in that context is a unique challenge. So difficult in fact that I don't know any other Free Software project that managed to do that. Is there even one that tried? I trust the Forgejo community is capable of such an extraordinary achievement and very much look forward to these discussions.

There is a standing agreement to allow GPLv3+ contributions to Forgejo https://codeberg.org/forgejo/governance/src/branch/main/AGREEMENTS.md#licensing and the following pull requests are (i) documenting this decision and (ii) merging the first GPLv3+ code in the source tree. > * Forgejo pull request > * Updating licensing information https://codeberg.org/forgejo/forgejo/pulls/4737 > * GPLv3+ code https://codeberg.org/forgejo/forgejo/pulls/4698 > * Website pull request https://codeberg.org/forgejo/website/pulls/467 I have read all discussions related to licensing and understand there are diverging opinions on how Forgejo's future will look like. I also believe there are no blockers to carry on with the current agreement, in the way proposed in these pull requests. I am convinced they are clear, unambiguous and future proof. However, I also get the impression that some Forgejo contributors have strong feelings on the matter and for that reason I would like to give them the opportunity to block the current agreement before these pull requests are merged. To do so, please **articulate a logical reasoning based on hard facts, as clearly as possible**. The Forgejo decision making process is the cornerstone of its governance and when an agreement is reached, every user and contributor can rely on it to be durable and usable. However, if there is overwhelming evidence that an existing agreement is undermining Forgejo, common sense dictates that it is blocked, for the good of the project. **If such reasoning is not presented within two weeks, I will keep moving forward based on the current agreement and Forgejo license will be upgraded from MIT to GPLv3+**. That step will not be the end of the discussion and I will advocate that the Forgejo license needs to evolve. I fully expect this discussion will take a very long time, no less than a year, maybe two or three. Because it is a difficult topic for which no Forgejo contributor claims a legal expertise. And also because it is grounded in our personal philosophical views and reaching a consensus in that context is a unique challenge. So difficult in fact that I don't know any other Free Software project that managed to do that. Is there even one that tried? I trust the Forgejo community is capable of such an extraordinary achievement and very much look forward to these discussions.

There is a standing agreement to allow GPLv3+ contributions to Forgejo https://codeberg.org/forgejo/governance/src/branch/main/AGREEMENTS.md#licensing and the following pull requests are (i) documenting this decision and (ii) merging the first GPLv3+ code in the source tree.

The pull requests were approved & merged. Forgejo is now GPLv3+.

> There is a standing agreement to allow GPLv3+ contributions to Forgejo https://codeberg.org/forgejo/governance/src/branch/main/AGREEMENTS.md#licensing and the following pull requests are (i) documenting this decision and (ii) merging the first GPLv3+ code in the source tree. > > > * Forgejo pull request > > * Updating licensing information https://codeberg.org/forgejo/forgejo/pulls/4737 > > * GPLv3+ code https://codeberg.org/forgejo/forgejo/pulls/4698 > > * Website pull request https://codeberg.org/forgejo/website/pulls/467 > The pull requests were approved & merged. Forgejo is now GPLv3+.
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
6 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#201
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?