I can agree to make a legalpad that is similar to the Phacility one.

I agree that an agreement could be useful but I don't think that the author should ever allow to re-license its work. I honestly do not want to allow my contributions to be re-licensed, since this usually means that the repository owner wants to re-license that work under a proprietary license when needed. I don't accept that. Normal volunteers do not accept that. This is probably not what we want.

In order to collaborate, an agreement should still be useful to clarify that the author releases it's work under Apache 2.0 - be nice with the others, assume vitamins, etc. and probably not much more I think.

Only users that have signed this agreement may be admitted to Blessed Committers.

In T15121#3880, @valerio.bozzolan wrote:

I honestly do not want to allow my contributions to be re-licensed, since this usually means that the repository owner wants to re-license that work under a proprietary license when needed. I don't accept that. Normal volunteers do not accept that. This is probably not what we want.

I agree with this. I can't envision any reasonable scenario in which the Phorge project needs the ability to re-license contributions. Drew DeVault wrote an interesting piece on his dislike of CLAs:

A CLA is a kick in the groin to a contributor’s good-faith contribution to the project. Many people, myself included, contribute to open source projects under the assumption that my contributions will help serve a project which continues to be open source in perpetuity, and a CLA provides a means for the project maintainers to circumvent that. What the CLA is actually used for is to give the project maintainers the ability to relicense your work under a more restrictive software license, up to and including making it entirely closed source.

The Linux Developer Certificate of Origin is mentioned at the end. I would strongly encourage something closer to that.

oh, wow.

By not signing a CLA, you'd have to explicitly set a license for each contribution you make - i.e., every single revision would have to include an explicit license, or it could not be incorporated into the main code-base.
This is technically handled by item 5 in our license, but it's reasonable to assume nobody ever reads that.

The concerns about "re-licensing into non-free license" are both protected and allowed by the current license we have - Apache License Version 2.0:

• anyone may take this work and redistribute it under an other (free or non-free) license
• the current copy is distributed under a Free license, and this cannot be revoked

so, if Phorge becomes evil and decides to re-license, we (and literally anyone else) are allowed to, but the thing we already released is still out there as Apache 2.0, and you can fork it and redistribute.

If you disagree to have your work re-licensed, you should (1) clearly and explicitly communicate it as such - e.g. by adding "This contribution is licensed under such-and-such license" and (2) not contribute to Apache-licensed projects as as Phorge, because we will not accept it.
You can fork Phorge (or Phabricator) and re-license it under GPL if you'd like.

The CLA has 2 major goals:

1. Make sure Phorge is not hit by legal action because of your contribution - that is, that you're allowed to give the code/etc. and that we (and future forks) are allowed to use it.
2. Make it easy for us to manage the codebase. It would be impractical to keep track of individual contributors and licenses for small chunks of code. The CLA allows us to group everything (or most of everything) into one big chunk.

TL;DR
Any contribution to Phorge is implicitly covered by Apache 2.0, which allows re-licensing by anyone.
The CLA is only making this explicit.

@avivey:

Make sure Phorge is not hit by legal action because of your contribution

↑ 100% agree that a Contributor License Agreement helps in mitigating this kind of legal disputes.

Premising that similar risks are usually calculated by potential damage caused by us. Right now this risk is very, very, very low since Phorge is not a company, Phorge does not deliver services, Phorge does not make profits. It's nearly impossible for a copyright troll to randomly sue open source volunteer-based projects by randomly sampling an economic loss received.

Again, a CLA is useful, but fortunately, we are in a relaxed situation.

@avivey:

It would be impractical to keep track of individual contributors and licenses for small chunks of code. The CLA allows us to group everything (or most of everything) into one big chunk.

↑ Sorry if I disagree to this block since it describes a problem that is really too distant from Phorge and with dangerous assumptions for most cases

Let's clarify a thing:

• Apache 2.0 allows lot of re-use and adaptations in a very relaxed way 👍 (yeah, for many evil purposes)
• Apache 2.0 does not allow re-license

What is re-license (not allowed):

We are not a classic boring corporate with a weird mix of proprietary stuff that sometime should receive external contributions but that should be sold as "all rights reserved, EvilCorp ©". That EvilCorp has indeed a legal mess to do so, and it's indeed very risky for them to don't introduce heavy copyright transfers, since their goal is "group everything into one big chunk" to re-license work as the corporate want, but, it's also indeed really damn invasive.

To clarify re-use (allowed):

Nintendo® can surely re-use right now Phroge to sells cartridges of "Supher Mario" at 1 billion dollars $$$ each, consisting in Super Mario® (all rights reserved) plus Phorge (Apache 2.0) deeply integrated (AHAAH U DON'T KNOW HOW) and we should surely encourage that, as soon as it's reasonably clear that Nintendo® has just invented "Supher Mario" (under all rights reserved) and eventually added some proprietary components for Phorge, but that Nintendo® is NOT the copyright holder of the Phorge project itself (but only of specific contributions), and that "all rights reserved" does not obviously apply to Phorge itself, that was just re-used, modified, mentioning the original source code of Phorge, mentioning the Apache 2.0 text somewhere, to understand the general rights with the original version of Phorge. We do not benefit from their code expansions, but at least people know that the starting point is and was free and available elsewhere.

(If we have a doubt about that, just read the "Redistribution" section of Apache 2.0 that is quite clear, and see that "re-license" is really never mentioned as a user right of an Apache 2.0 software)

TL;DR

• Any single contribution in the upstream Phorge is explicitly covered by default by Apache 2.0
  • yes, you can do evil usages by anyone
  • yes, you can embed Phorge in your evil proprietary product
  • yes, your product continues to be proprietary
  • yes, you can expand Phorge with proprietary modules (but only if you are able to explain which parts are yours and NOT parts of Phorge)
  • no, you can't pretend that Phorge itself was "all rights reserved EvilCorp©" (come on, do you really want this evil thing? If yes, contact all the authors, good luck)
• The CLA serves as a very useful added awareness of license rights and duties, assuming that IN EVERY CASE it had been accepted, contributing to Phorge
  • no, you cannot steal code of other people and propose that in Phorge
  • no, you cannot contribute to Phorge by pretending you don't know the Apache 2.0, etc.

Sorry if this unrelated, but this is an interesting partially-related commit:

https://we.phorge.it/rPef85f49adc0714e2b1acbe9368e0da9aeb8dc854

Just to clarify that our license should really be considered explicit in the moment a contribution touches upstream Phorge. What has a different license should be clearly indicated (again, CLA is still useful, but should be clear that it is not our salvation, but a mere "added hardening").

In T15121#8063, @avivey wrote:

Any contribution to Phorge is implicitly covered by Apache 2.0, which allows re-licensing by anyone.
The CLA is only making this explicit.

If that's the case, then why is separately agreeing to re-licensing via the CLA such a pressing necessity? And if not (as @valerio.bozzolan believes is the case), why does the Phorge project need the ability to re-license anything?

As to the rest of it, I probably wasn't clear enough in my initial comment (perhaps the link to DeVault's post fed a bit of a misunderstanding): I'm not against a contributor agreement per se, just against special clauses concerning re-licensing. I don't see why it's necessary (whether Apache 2.0 "allows" it or not - Phorge doesn't need some special privilege in this regard).

From https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html

Many people, myself included, contribute to open source projects under the assumption that my contributions will help serve a project which continues to be open source in perpetuity, and a CLA provides a means for the project maintainers to circumvent that.

Assumption here is key. The entire purpose of a CLA is to remove this assumption and clarify how contributions are managed. This post and disposition is based entirely around the organization receiving contributions will behave in an adversarial manner in the future. If the organization doesn't earn your trust then why trust them with your contributions?

Additionally, contributions will remain open source and available at the point in time they are accepted however the organization needs to be able to shift and change through time. If that need arises it becomes essentially impossible shift because in order to do so might require checking with every user who contributed.

Example:

1. Phorge grows and offers a commercial hosting of Phorge
2. The net income of the hosting service is enough to pay for full-time contributors working on the project
3. Amazon swoops in, takes open-source Phorge and offers their own hosting service, wiping out income from Phorge's own service
4. Phorge decides to re-license for a still commercial-friendly license but disallows use in a competing service

This essentially played out with MongoDB who in ~2018 switched to Server-Side Public License to prevent Amazon from doing this.

From https://www.mongodb.com/licensing/server-side-public-license/faq, under Why are we changing the license for MongoDB?

The reality, however, is that once an open source project becomes interesting, it is too easy for large cloud vendors to capture all the value but contribute nothing back to the community.

Making that change to the license would become impossible without contributors agreeing to allow the organization to re-license -- for the organization to continue to survive.

Just some probably interesting notes :D

• MongoDB was nuked by the MongoDB organization ':-<
  • MongoDB started from the most-copyleft license ever, the GNU AGPL (Phorge instead has a very permissive license btw)
  • Then, Amazon expanded MongoDB in weird ways, adding very high-level APIs and other things not strictly related to the core, not triggering the GNU AGPL, and they wanted not to release anything
  • MongoDB tried to stop that, adopting an esoteric license, now declared as proprietary. MongoDB suicided: it was removed from Debian, Fedora and Red Hat Enterprise Linux distributions.
    • There's really no worst-case scenario ihih small-medium users who respect the law can't use MongoDB because it's not compatible with their open source stack; EpicEvilCorps don't share anything since they have smart lawyers
• if we had an org, its core business would be not
  • sell a re-licensed version of Phorge with "All Rights Reserved, Phorge Corp ©"
    • really, we can't without violating copyrights past author, with or without a CLA. To do that, we need that kind of invasive massive copyright transfer document that I would avoid to discuss here :D
    • this is also something that a smart customer would not buy, since the Apache 2.0 has ~zero creative business restrictions than "All Rights Reserved, Phorge Corp ©" so it's really a nonsense business product probably
• if we had an org, its core business should probably be in these already-legal (and very wide) evil creative areas:
  • offer codebase code sprints on requested features at 1500 USD per hour
  • give assistance at 3000 USD per hour
  • offer service as a software at 100 USD for every 5 accesses
  • offer on-premise installations at 1 billion USD one-shot
  • help creating ad-hoc customizations (which we should kindly release under Apache 2.0 at least for the client, so the client is always Free - not necessarily every person on Earth, just the client is Free, then the client can Free others, or not)
  • help integrating Phorge with proprietary software
  • help writing proprietary core parts in Phorge for an ad-hoc customer
  • help in putting Phorge into a bigger proprietary stuff
  • etc.

Bonus points:

How to change default license?

Example: how to migrate from Apache 2.0 to "GNU AGPL" to obstruct Amazon?

• This case is simple since they are compatible. So we can just right now say: «new contributions are under GNU AGPL. If you do not have a lawyer please consider the entire project as GNU AGPL. Past contributions before <time> are under Apache 2.0. If you need files under Apache 2.0, inspect the history of specific files, or use an old version" or something like that. Done.
• How to decrease the risk on this? CLA is good

(→ Spoiler: Amazon rewrites us from scratch)

Again, a CLA is useful, but as a non-esoteric community, authors should be the copyright holders of their code. The standard tool that allows that is a Free license. A standard CLA should not contain a copyright transfer, also because we are not creating an American film :D Also because we don't want to create a central commercial monopoly for "All Rights Reserved, Phorge Corp ©" on this community-generated film.

(I think this is a sub-task of T15022)

There is a blog post from Bryan Cantrill about why Node.js stopped using CLA's which might be of interest: Broadening Node.js Contributions.

A quick thing we can do: creating a Legalpad to accept (in a more explicit way) the terms of the Apache 2.0.

In this way, we somehow protect ourselves from the copyright troll phenomena, at least, more than now.

So, creating a Legalpad titled something like "Contributor Agreement"

With content:

== Originality ==
I have taken it to my heart's content that my contributions should not infringe on other people's copyrights.

== Copyright ==

I read the Apache 2.0 license, and I liked it very much. It therefore covers my contributions as default.

I have also taken notice of the Creative Commons BY-SA license that covers my comments, and screenshots uploaded in Phorge, by default. I love it.

Where other copyrights note applies, I write a note "otherwise indicated".

== Personal data ==

I'm really aware that, my git name, and my git email, are just public contact information to be shared as much as possible, and are not personal data to be protected with the life the lives of a thousand Klingon lawyers.

== Extra ==

I didn't kill any kitten during my code and content contributions.

Just to have something relaxed to start with.

OK just to have a stub somewhere to start with, please feel free to edit this page:

L2 Contributor Agreement (UNDER CONSTRUCTION)

But, hoping to demonstrate my good faith, I sign that document in the current version, so to already release my contents under Apache 2.0 etc. in a more explicit way.

Unrelated note, but interestingly the contributor agreement chooser (https://contributoragreements.org/) is broken. I've already sent an email to their support.

Hi all :) Bug report.

I just would like to report that the contributoragreements.org chooser is partially broken.

For example, visit this:

https://contributoragreements.org/ca-cla-chooser/?beneficiary-name=Phorge+contributors&project-name=Phorge&project-website=https%3A%2F%2Fwe.phorge.it%2F&project-email=info%40phorge.it&process-url=https%3A%2F%2Fwe.phorge.it%2FL2&project-jurisdiction=Worldwide&agreement-exclusivity=exclusive&fsfe-compliance=&fsfe-fla=&outbound-option=fsfe&outboundlist=&outboundlist-custom=&medialist=____________________&patent-option=Traditional&your-date=&your-name=&your-title=&your-address=&your-patents=&pos=apply&action=

In background it tries to contact this plaintext URL and so this and similar background requests are blocked:

http://contributoragreements.org/u2s/set/?l=https%3A%2F%2Fcontributoragreements.org%2Fca-cla-chooser%2F%3Fbeneficiary-name%3DPhorge%2Bcontributors%26project-name%3DPhorge%26project-website%3Dhttps%253A%252F%252Fwe.phorge.it%252F%26project-email%3Dinfo%2540phorge.it%26process-url%3Dhttps%253A%252F%252Fwe.phorge.it%252FL2%26project-jurisdiction%3DWorldwide%26agreement-exclusivity%3Dexclusive%26fsfe-compliance%3D%26fsfe-fla%3D%26outbound-option%3Dfsfe%26outboundlist%3D%26outboundlist-custom%3D%26medialist%3D%26patent-option%3DTraditional%26your-date%3D%26your-name%3D%26your-title%3D%26your-address%3D%26your-patents%3D%26pos%3Dapply%26action%3D

The cause is probably this config file that should have "HTTPS" and not "HTTP":

https://contributoragreements.org/ca-cla-chooser/js/config.json

Thanks for what can be done :)

In T15121#3880, @valerio.bozzolan wrote:

I don't think that the author should ever allow to re-license its work. [...] Normal volunteers do not accept that.

Oh I'd accept that sometimes, so I guess I am not a "normal volunteer". :D Two personal anecdotes:

• In another FOSS project without a Contributor Agreement, I'd love to accept a request to relicense content I've contributed from GFDL 1.2 to CC-BY-SA 4.0 but I do not believe that they/we will ever manage to contact all its >120 past contributors in order to get an OK from everyone. It's unrealistic. I naïvely believe a Contributor Agreement would have helped avoiding this situation (but noone can travel back 20 years).
• In another another FOSS project many years ago I was lucky that nearly all previous work was done by a company which required their staff to transfer copyright ownership. While this can be problematic in many many ways, it allowed their Legal department as the copyright owner to be able to give its OK to my request to re-license content contributed by their staff from GFDL 1.2 to GFDL 1.3 so shipping it together with my content under CC-BY-SA 3.0 became less problematic. (Reminder to the average reader: Copyright is absolutely not the same as Licensing.)

@valerio.bozzolan, if your main concern is "re-license work under a proprietary license", then I believe a Contributor Agreement could potentially include a condition such as allowing a potential future re-licensing only to OSI Approved Licenses or such (or whatever FOSS ideology is preferred). I'm intentionally using plural ("licenses") here as dual-licensing can come handy in some situations. (General disclaimer: IANAL.)

Totally agree. Thanks for any edit in the stub.

Well, I would rewrite quite a bit, so I'll post a draft here before editing directly:

Preamble:

Before we can accept your contributions to Phorge, we need you to sign this Contributor Agreement. Please it read it carefully.

Document Body:

You accept and agree to the following terms and conditions for your present and future Contributions to the Phorge Project. You reserve all right, title, and interest in and to your Contributions.

This agreement helps the Phorge Project and the Phorge Community to avoid future risks: it makes sure that we can distribute your Contributions under a free and open source license.

Definitions

• "Contribution" shall mean any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by you to the Phorge Project for inclusion in, or documentation of, any of the projects owned or managed by the Phorge Community.
• "Phorge Project" shall mean the domain name phorge.it including its subdomains and any content hosted on these domains, including potential future domain names.
• "Phorge Community" shall mean all and any people or entities providing Contributions to the Phorge Project.

Respecting Authors, Copyright and Licenses

You respect copyright and licenses. You do not propose or merge Contributions which are third-party content under an incompatible or unknown license into the Phorge Project. You provide appropriate references when proposing Contributions taken from third-parties (for example from StackOverflow.com or from Wikimedia Commons) by mentioning the original URL and the license and the author's name, or whatever is required by the license of that third-party content.

Original Contributions

You agree that you release your Contributions under Free licenses to allow present and future collaboration:

• You agree that your code and git Contributions are by default under the Apache 2.0 license available at https://www.apache.org/licenses/LICENSE-2.0
• You agree that your other content Contributions are by default both under the Creative Commons Attribution Share-Alike (CC BY-SA) 4.0 license available at https://creativecommons.org/licenses/by-sa/4.0/ and also under the Apache 2.0 license available at https://www.apache.org/licenses/LICENSE-2.0. The latter allows additional legal compatibility (for example regarding screenshots of the Phorge Project).
• You agree that your code and git Contributions could be relicensed under a later (future) version of the Apache license and you agree that your other content Contributions could be relicensed under a later (future) version of the Creative Commons Attribution Share-Alike license.

Examples:

• by default, your Differential patches and your git commits are licensed and released under the Apache 2.0 license.
• by default, your comments (in any area of the Phorge Project), your screenshots of Phorge, your test plans, your contributions in applications with Phorge such as Phriction, Diviner, Ponder, Calendar, etc, are dual-licensed and released under both the Creative Commons Attribution Share-Alike 4.0 license and also the Apache 2.0 license.

Personal Data

You are aware that you shall not input personal data or personally identifiable information into the Phorge Project.
You agree that the following data is not considered personal data but public information:

• Your chosen author or committer name used for code patches and commits: Useful to allow other people to contact you and to ensure that there is a trail of accountability regarding your Contributions. Furthermore, rewriting the code history would cause major disruptions.
• Your chosen email address used for code patches and commits: Useful to allow other people to contact you and to ensure that there is a trail of accountability regarding your Contributions. Furthermore, rewriting the code history would cause major disruptions.
• Your email address(es) set by you for your user account in the Phorge Project: Useful to receive notifications and reset links. While these email addresses are not disclosed in public, you agree that you will not take legal action against the Phorge Community if one day the databases of the Phorge Project were hacked by malicious people and your email addresses were published by them.

Extra

You will do your best to be kind, cooperative, and to assume good faith in communication and interactions within the Phorge Community.

Eject Button

You understand that, if you breach this agreement, your user account in the Phorge Project could be removed from the Trusted Contributors group or also disabled or deleted at database level.

No brushing teeth three times a day? However it looks good to me 👍

I could not sign it if it required brushing three times a day. Removed purely due to egoistic laziness reasons.

OK OK. So what else? Maybe this (mention from https://secure.phabricator.com/p/epriestley/):

I think something like this at the bottom would lighten the mood a lot, in the pure spirit of this software. Clearly that message may not achieve that goal, but still something similar would be needed.

Would you like to go to court to defend that statement? :)

I have a problem with this statement:

You reserve all right, title, and interest in and to your Contributions.

It implies a contributor may withdraw their contribution after its been included; This isn't the case.

Having a single document describing both code (Apache) and non-code (CC2) is confusing. I don't think that just posting a comment (CC2) should require users to sign the CLA. I'd limit the CLA to "Work" contributions, with "Work" as defined in the Apache 2.0 license.

While we're here, explicitly say that the Contribution, Work, Source, Licensor, etc are defined in LICENCE, and where that puts the CLA signor (e.g., "You are the Contributor for the purpose of the license...")

You are aware that you shall not input personal data or personally identifiable information into the Phorge Project.

Language issue aside, this doesn't make sense. This means I'm not allowed to type my full name here?

Your email address(es) set by you for your user account in the Phorge Project

That is private data. Nobody can access it.

Adding a "fun" part to the CLA can actually harm the validity of the rest of the document. If we consider it "a real legal contract", we should act like it is.

"Phorge Project" shall mean the domain name phorge.it including its subdomains and any content hosted on these domains, including potential future domain names.

We explicitly host projects here that are not managed by the "Phorge Project" and are not covered by our license and CLA: Phactory: Community Projects and T15030.

Your email address(es) set by you for your user account in the Phorge Project

That is private data. Nobody can access it.

Private, until we get pwned :D

Since this is a community site maybe we can kindly ask people not to record information that we need to protect. So we have one less problem to think about. Just a tip.

I'm pretty fine with DCO (which I already do every commit via the git commit -s command) — but I'd rather not sign a CLA. (I’m pretty undecided if I will sign phorge's CLA, but phorge is not commercial entity seeking to mongodb/terraform/elasticsearch-ize the software (read: make a profit from open source, then turn it into All Rights Reserved) so I might do so… after all these incidents I'm rather wary of it.)

That "don't sign a CLA" article should be titled "don't sign away your copyrights", to be more accurate and less click-bait-y. A CLA may ask you to sign away copyrights (which I feel makes the project non-open-source) ; It doesn't have to.

That article only talks about copyrights assignment.

The CLA from Phacility, and what I have in mind, doesn't ask contributors to sign away copyrights; It provides a Copyright License to the project.

@avivey that's an excellent observation.

Would the CLA have to be signed with one's legal name?

In T15121#20192, @BlankEclair wrote:

Would the CLA have to be signed with one's legal name?

This is one of those lawyer-questions, but possibly, no? As long as there's a way to link a contribution to a contributor to a CLA, that's probably fine.
If it is required, we should be to treat the full name as PII, and only publicly link to the account.

What do other CLAs do about this?

(I'm assuming you're asking for the "want to stay anonymous" use-case)

What do other CLAs do about this?

I'm... honestly not sure, I haven't signed one before. If I had to, I'd ask the maintainers before doing so ^^;

(I'm assuming you're asking for the "want to stay anonymous" use-case)

I indeed am, but I am also asking in the case for trans people (as one's real name/chosen name does not necessarily match their legal name unfortunately, and having to sign with my deadname kinda sucks)

I think that for the "the name I use is not my legal name" use-case, I'm pretty sure it's fine to use the name that is actually used (because that's what the person is normally known as). It's probably easier to justify accepting a name that is used in real life then "internet handle", but ㄟ( ▔, ▔ )ㄏ

I think the best extra other than brush your teeth three times a day (which not everyone likes) would be review this agreement every week.