Adopt either the Contributor License Agreement (CLA) or the Developer Certificate of Origin (DCO)

[Relequestual]

I'm going to recommend using DCO, as it is less problematic for potential contributors.

[Relequestual]

I am going to query re the OpenJS Foundations IP Policy...

Except as may be approved by the Board:

• All new code contributions to any Project shall be made under the Project Code License accompanied by a Developers Certificate of Origin (DCO, available at http://developercertificate.org/), which will bind the individual contributor and, if
  applicable, their employer to the Project Code License.
• All outbound code files will be made available under the Project Code License.
• All documentation, image, and audiovisual files (e.g., .txt., .rtf, .doc, .pdf, .jpg, .tif, .mp3, .wav, and some .html files) (including without limitation code that is intended as sample code if included in a documentation file) will be contributed to the Project and made available under one of the following licenses selected by the Project’s technical
  governing body (the “Project Documentation License”):
  • Creative Commons Attribution 4.0 International License (CC BY 4.0) (available
    at http://creativecommons.org/licenses/by/4.0/), or
  • The MIT License (available at https://opensource.org/licenses/MIT).

Are our specification documents "code" here?
I don't think they would be "documentation".

[Julian]

I can't 100% be sure what the first line there means ("Except as may be approved by the Board:") but I think it means we can ask for an exception to all of that. If it does, I would probably love it if we did so -- CLAs are IMHO (and in the O of at least a few more knowledgeable other folks I think) at best somewhat useless and at worst actively scare away contributors. I certainly know of places where you cannot contribute to a project with a CLA if you're employed somewhere where it'd be otherwise ok.

See also e.g. (random first google links though I've seen all of these previously):

• https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/
• https://www.linuxjournal.com/content/contributor-agreements-considered-harmful
• https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html
• https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/

(If we really must, fine, but otherwise for our own purposes, I don't think we should have a reason why we want to have this. My 0.02 though.)

[Relequestual]

I somewhat agree @Julian! I don't think we would want a CLA. I do think that having a DCO avoids potential problems later.
Drew has a follow up article on DCOs: https://drewdevault.com/2021/04/12/DCO.html

CLA is "easier" for people to do, clicking a few buttons, but probably results in more people not actually getting legal involved.

DCO is "harder", but doesn't require legal involvement. Autoamtion has been made easier.
A common compliant was each commit needs to be signed, but one automation tool got updated to enable the retroactive signing of previous commits: dcoapp/app#147 - "Individual remediation commit support".

@Julian if you'd like to make a case to the OpenJS Foundation board that we should be exempt, then let's discuss.
I guess first we need to work out/find specific reasons for wanting it, and consider if we align with those situations or not.

[benjagm]

I agree in everything said. DCO will fit much better for JSON Schema. The only possible side effect of choosing DCO vs CLA is how the organization is implementing it. It can be done learning from Node.js and Electron (both Impact projects at OpenJS). They implemented DCO as simple as: "Contributor only has to add the Signed-off-by line in their commits".

• Choose DCO or CLA electron/governance#441 (comment)
• Guidance for DCO (and DCO vs. CLA) openjs-foundation/cross-project-council#387 (comment)

Git provides the -s flag for git commit, which adds the following text to your commit message:
Signed-off-by: John Doe <johndoe@acme.com>

Other findings on my research:

• CLAs tends to create a contribution-hostile developer experience.
• CLAs shifts legal blame to the party least equipped to defend against it
• Orgs choosing CLA purposely choose to prioritize minimizing legal risk vs over maximizing the project’s potential community.
• DCO offers the maintainers the same rights that they extended to the community themselves.
• The DCO gives developers greater flexibility and portability for their contributions.
• The DCO ‘fixes’ two issues with the typical CLA. Firstly, it does not contain a separate license. Secondly, the DCO does not involve a lengthy, one-time, signature process but is instead covered in every commit by the “Signed-off-by” phrase.
• The aspects of executing a DCO that make the process heavier than a CLA seem to be side-effects of how organizations implement DCOs, not intrinsic aspects of them.

References:

• https://drewdevault.com/2021/04/12/DCO.html
• https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/
• https://about.gitlab.com/blog/2017/11/01/gitlab-switches-to-dco-license/
• https://opennebula.io/switching-from-cla-to-a-dco-for-source-code-contributions/
• https://medium.com/@flamefew/clas-and-using-dco-clearly-e46b09a4c048
• Choose to use a CLA, a DCO, or neither ampproject/meta-tsc#25 (comment)
• Guidance for DCO (and DCO vs. CLA) openjs-foundation/cross-project-council#387 (comment)

[kevinswiber]

I certainly know of places where you cannot contribute to a project with a CLA if you're employed somewhere where it'd be otherwise ok.

They are relying on a gray area in case they ever want to claim ownership over and revoke their commits. A CLA makes all this explicit and clear.

• Orgs choosing CLA purposely choose to prioritize minimizing legal risk vs over maximizing the project’s potential community.

This is different when the organization is a non-profit that's community-centered. It's one thing to explicitly sign-off on rights and property transferring to a big tech company, and it's another thing when they're being transferred to the community itself.

• The aspects of executing a DCO that make the process heavier than a CLA seem to be side-effects of how organizations implement DCOs, not intrinsic aspects of them.

And the reality is... you'll probably never have an issue around this.

I would think the DCO is good for JSON Schema, and yet the CLA might actually offer better protection against unsavory litigators. Again, though, how likely is this to be an issue on a project that's run by a non-profit? That's the risk that needs to be weighed.

[gregsdennis]

How do people here know what these things are? As a person wholly uneducated on this topic, where can I find information comparing the two concepts without having to read through all of the linked literature above?

[benjagm]

How do people here know what these things are? As a person wholly uneducated on this topic, where can I find information comparing the two concepts without having to read through all of the linked literature above?

I found these 2 videos very insightful:

• https://youtu.be/M9czSZMPCMA
• https://youtu.be/TV9EhzfjepA

[benjagm]

Found this cool GitHub automation to easily implement DCO: https://github.com/dcoapp/app

Source: https://opensource.guide/legal/#does-my-project-need-an-additional-contributor-agreement

[github-actions]

Hello! 👋

This issue has been automatically marked as stale due to inactivity 😴

It will be closed in 180 days if no further activity occurs. To keep it active, please add a comment with more details.

There can be many reasons why a specific issue has no activity. The most probable cause is a lack of time, not a lack of interest.

Let us figure out together how to push this issue forward. Connect with us through our slack channel : https://json-schema.org/slack

Thank you for your patience ❤️

[littledan]

The issue here is more about minimizing liability for the organization using the licensed software/standard, not just the host org. Guaranteeing legal certainty is an important goal to promote adoption. Companies are increasingly checking the underlying IP of open source software they use. For standards, a good CLA can provide this certainty.

If the idea is to standardize JSON Schema via OpenJSF, it may be easiest to use the LF’s common schemes for publishing standards, around the Community Specification License, which uses a CLA for this purpose of ensuring limited liabilty for downstream users. The whole process can be easily automated by reusing some bots. Would this option be attractive for the group?