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.