Archived
15
23
Fork
You've already forked meta
6

[Proposal] Adopt "Contributor Agreement" Process for Forgejo (Obsoletes DCA) #184

Open
opened 2023年03月01日 05:36:47 +01:00 by tallship · 1 comment

I've formulated this according to feedback from @circlebuilder on decision-making, see comment here.

Decision proposal

Background

A two month long discussion that began with a proposal by @Caesar on 26 December 2022 sparked a healthy discussion within the community regarding the particulars of re-licensing the Forgejo software product to that of Copyleft.

The ensuing weeks found many participants anxious to resolve the matter and there was some frustration with the length of time and intricate dialogs, with a seeming inability to bring the matter to resolution. Eventually, a proposal to hold a vote was met with no objections and an election is now underway collecting votes in a poll to determine which license Forgejo will use going forward.

During the discussions,another matter was raised, that of adopting a CLA over that of a DCA vehicle, pending outcome of the licensing decision. @Ryuno-Ki posited that he was not agreeable to, as a contributor, assigning Copyright of this Intellectual Property to a project, and he and I discussed the virtues of another schema here - that the QT foundation uses a "One-time, Single Click" model, similar to the CLA model, exceedingly simple to administer, track, and maintain, using a Contributor Agreement that assigns license to the project by contributors, rather than assigning Copyright of the intellectual property the contributor created - an ideal compromise that allows the contributor (and/or the project itself, depending on the evolving project policies) the ability to gift contributions to, in our case, the Gitea project, under the MIT license that they use.

The Model that @Ryuno-Ki pointed to as an example of how we can simply boilerplate (with minor edits/alterations) to incorporate this simpler and more flexible method, is here. It is recommended that interested community members familiarize themselves with this simple and flexibile schema.

During that same discussion surrounding the re-licensing of Forgejo, another issue to change this project's CONTRIBUTING.md file to accommodate our stated usage of contributions was also opened here

Proposal

Considering the likelihood that the Forgejo community will adopt a Copyleft license moving forward, it is prudent to work in parallel to prepare for the adoption of whatever license is chosen and if a Copyleft variant is chosen, then prepare to accommodate the enactment which will occur on 15 April 2023.

  • Adopt the Schema used by QT project here and make the minor retooling necessary to accommodate our contributors and workflow.

  • Some tooling should be built into Forgejo, and preferably before 15 April 2023, to facilitate simple management of Contributor Agreements by both contributors AND if neccessary, their employers (it's the identical agreement), with respect to provenance and to ensure an unencumbered code base in the Forgejo Project. Currently, the QT project uses Gerrit, a FOSS product, yet it would be preferable to build the One-time, One-Click workflow to accommodate the Contributor agreement into Forgejo.

Who is affected?

  • Forgejo community members, users of our software that benefit by virtue of a product unencumbered by intellectual property claims by other third party entities
  • The Gitea companies, teams and projects - a seamless way is provided by this schema to provide gifted patches to that project by the Forgejo project or individual contributors to Forgejo.
  • Forgejo Contributors - They are merely assigning a license to Forgejo, and not relinquishing their own intellectual property rights by virtue of assigning their Copyright to the Forgejo project.

NOTE: This will alleviate the need to sign each commit when contributing patches, making merge requests in the form of Pull Requests, Etc., under the current "DCA" method - although there's also nothing that prevents us from requiring signing each commit either.

DURATION - Scope of Time:

This issue should remain open until such time as a decision is finalized and adopted or rejected by the community, and should also be resolved by 15 April 2023 (the date we enact a Copyleft License for Forgejo - if we do).

In any case, I recommend this approach since I and others believe it is a good idea for a large project and can be used with any license that Forgejo adopts moving forward, yet I intend to close the issue even if not resolved before 15 April 2023, unless there is a compelling reason to keep it open.

Who can vote?

Anyone who takes note of the Decision Proposal can put up their vote.

I've formulated this according to feedback from @circlebuilder on decision-making, see comment [here](https://codeberg.org/forgejo/meta/issues/168#issuecomment-811470). # Decision proposal ## Background A two month long discussion that began with a proposal by @Caesar [on 26 December 2022](https://codeberg.org/forgejo/meta/issues/86) sparked a healthy discussion within the community regarding the particulars of re-licensing the Forgejo software product to that of Copyleft. The ensuing weeks found many participants anxious to resolve the matter and there was some frustration with the length of time and intricate dialogs, with a seeming inability to bring the matter to resolution. Eventually, a proposal to hold a vote was met with no objections and [an election is now underway](https://codeberg.org/forgejo/meta/issues/183) collecting votes in a poll to determine which license Forgejo will use going forward. During the discussions,another matter was raised, that of adopting a CLA over that of a DCA vehicle, pending outcome of the licensing decision. @Ryuno-Ki posited that he was not agreeable to, as a contributor, assigning Copyright of this Intellectual Property to a project, and he and I discussed the virtues of another schema [here](https://codeberg.org/forgejo/meta/issues/86#issuecomment-807560) - that the QT foundation uses a "One-time, Single Click" model, similar to the CLA model, exceedingly simple to administer, track, and maintain, using a **Contributor Agreement** that assigns license to the project by contributors, rather than assigning Copyright of the intellectual property the contributor created - an ideal compromise that allows the contributor (and/or the project itself, depending on the evolving project policies) the ability to *gift* contributions to, in our case, the Gitea project, under the MIT license that they use. The Model that @Ryuno-Ki pointed to as an example of how we can simply boilerplate (with minor edits/alterations) to incorporate this simpler and more flexible method, is [here](https://www.qt.io/community/legal-contribution-agreement-qt). It is recommended that interested community members familiarize themselves with this simple and flexibile schema. During that same discussion surrounding the re-licensing of Forgejo, another issue to change this project's `CONTRIBUTING.md` file to accommodate our stated usage of contributions was also opened [here](https://codeberg.org/forgejo/meta/issues/160) ## Proposal ### Considering the likelihood that the Forgejo community will adopt a Copyleft license moving forward, it is prudent to work in parallel to prepare for the adoption of whatever license is chosen and if a Copyleft variant is chosen, then prepare to accommodate the enactment which will occur on 15 April 2023. * Adopt the Schema used by QT project [here](https://www.qt.io/community/legal-contribution-agreement-qt) and make the minor retooling necessary to accommodate our contributors and workflow. * Some tooling **should** be built into Forgejo, and preferably before 15 April 2023, to facilitate simple management of Contributor Agreements by both contributors **AND** *if neccessary*, their employers (it's the identical agreement), with respect to provenance and to ensure an unencumbered code base in the Forgejo Project. Currently, the QT project uses [Gerrit](https://www.gerritcodereview.com), a FOSS product, yet it would be preferable to build the One-time, One-Click workflow to accommodate the Contributor agreement into Forgejo. ## Who is affected? * Forgejo community members, users of our software that benefit by virtue of a product unencumbered by intellectual property claims by other third party entities * The Gitea companies, teams and projects - a seamless way is provided by this schema to provide gifted patches to that project by the Forgejo project or individual contributors to Forgejo. * Forgejo Contributors - They are merely assigning a license to Forgejo, and not relinquishing their own intellectual property rights by virtue of assigning their Copyright to the Forgejo project. #### NOTE: This will alleviate the need to sign each commit when contributing patches, making merge requests in the form of Pull Requests, Etc., under the current "DCA" method - although there's also nothing that prevents us from requiring signing each commit either. ## DURATION - Scope of Time: This issue should remain open until such time as a decision is finalized and adopted or rejected by the community, and should also be resolved by 15 April 2023 (the date we enact a Copyleft License for Forgejo - if we do). In any case, I recommend this approach since I and others believe it is a good idea for a large project and can be used with any license that Forgejo adopts moving forward, yet I intend to close the issue even if not resolved before 15 April 2023, unless there is a compelling reason to keep it open. ## Who can vote? Anyone who takes note of the Decision Proposal can put up their vote.
Contributor
Copy link

Thanks for bringing this up, @tallship!

As I mentioned in the referenced issues, I have reservations towards CLAs.
Actually, I'm happy with a DCO for the most part.

But let me give you some background where I'm coming from.

In the beginning (as junior breaking into the industry) I haven't spent much thought on Intellectual Property. After all, companies almost always force you to sign away your IP towards them.

The majority of projects I contribute to don't have a CLA in place. The copyright remains with the respective authors. Their code is licensed under the project's terms.

Now when I've read about Ubuntu's init system parting ways with Debian in
https://www.pro-linux.de/news/1/20689/debatte-%C3%BCber-contributor-license-agreements.html (German, use a translation service) I have changed my mind.

Short detour: Check out https://harmonyagreements.org/ and/or https://mjg59.dreamwidth.org/29160.html

I'm sick of loosing all my rights on the work I gift to others. That feels so much like exploitation. I don't want to do that any more.

When I was looking into desktop program development I took a look into Qt, since it announced a wrapper for Python (PySide) shortly before. There's a community project called PyQt which has book coverage.
The company behind it also requires a CLA but goes out of their way in actually explaining the implications.

I can understand that there are circumstances that make a CLA necessary. But the terms have to be chosen carefully and explained to potential contributors.

I hope this helps forming an opinion on the subject at hand.

Thanks for bringing this up, @tallship! As I mentioned in the referenced issues, I have reservations towards CLAs. Actually, I'm happy with a DCO for the most part. But let me give you some background where I'm coming from. In the beginning (as junior breaking into the industry) I haven't spent much thought on Intellectual Property. After all, companies almost always force you to sign away your IP towards them. The majority of projects I contribute to don't have a CLA in place. The copyright remains with the respective authors. Their code is licensed under the project's terms. Now when I've read about Ubuntu's init system parting ways with Debian in https://www.pro-linux.de/news/1/20689/debatte-%C3%BCber-contributor-license-agreements.html (German, use a translation service) I have changed my mind. Short detour: Check out https://harmonyagreements.org/ and/or https://mjg59.dreamwidth.org/29160.html I'm sick of loosing all my rights on the work I gift to others. That feels so much like exploitation. I don't want to do that any more. When I was looking into desktop program development I took a look into Qt, since it announced a wrapper for Python (PySide) shortly before. There's a community project called PyQt which has book coverage. The company behind it also requires a CLA but goes out of their way in actually explaining the implications. I can understand that there are circumstances that make a CLA necessary. But the terms have to be chosen carefully and explained to potential contributors. I hope this helps forming an opinion on the subject at hand.
Commenting is not possible because the repository is archived.
No Branch/Tag specified
readme
No results found.
Labels
Clear labels
[Decision] Building proposal(s)
We're in a decision-making process, buiding one or more proposals to address the shared aim based on the criteria
[Decision] Gathering criteria
We're in a decision-making process, gathering criteria, considerations and needs
[Decision] Integrating concerns
We're in a decision-making process, working with a proposal, trying to integrate concerns and create modifications/support such that the proposal works for everyone
Accessibility
Relates to Accessibility (a11y) of product, project and process.
Agreement proposal
Forgejo agreement proposal, following a discussion
Communication
Relates to all channels, social media, website, blog posts.
Election
Process of appointing a person into a role or team (if choosing people just for a specific one-time task, use the Entrustment label)
Entrustment
Process of choosing/approving specific people to do a critical/high-impact one-time task (if choosing people for an ongoing role/team, use the Election label)
Governance
Relates to processes, procedures and decision-making.
Meeting
An upcoming team meeting
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
2 participants Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
forgejo/meta#184
Reference in a new issue
forgejo/meta
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?