Licensing

[RichardLitt]

IPFS has a lot of repositories; each one has, or should have, both a LICENSE file and a License section in the Readme.

The Licensing has been ad-hoc, and not standardized. Some repositories are licensed to individual authors - @jbenet or @whyrusleeping, while others are licensed to IPFS (which isn't an entity), and so on. I think we should have the same Licensing applied to each repo. How should we best do this?

Related to #35, #45, and #124.

[flyingzumwalt]

👍 This is super important. Related: You need to have a serious conversation with your lawyers and other open source projects about whether to require CLAs from all committers. This can really burn you in the long run if you don't do it right.

[flyingzumwalt]

For reference, I brought up this exact question about CLAs at a Hydra Meeting in 2010 -- "Should we be requiring CLAs from all the committers?". That triggered two years of conversations between the legal offices of 4 institutions, including Stanford (no strangers to software licensing). They were unanimous about one thing -- you definitely need CLAs from all contributors -- meaning your PR doesn't get merged until you've signed a CLA. The back-and-forth revolved around figuring out which legal entity the licenses should be assigned to. They cooked up a temporary legal hack that lasted for 4 years and then asked DuraSpace (an independent nonprofit that works in the libraries & archives space) to take over stewardship of the licenses.

[Kubuxu]

@flyingzumwalt We are currently using the developer certificate of origin (at least in go-ipfs, it should be probably done in all other projects).

The same process is used by multiple big projects for example Linux and Docker.

The main difference between it and CLA is that the project owner doesn't hold the copyright over the code, meaning we can't for example change the license, but as we already are using very liberal license so it shouldn't be much of a problem and holding rights is problematic as you said (you need an entity for that).

[jbenet]

• Thanks this topic is ultra important
• Yes all projects should bear a LICENSE file. We should be able to re-license to something like "The IPFS Authors" or "InterPlanetary Foundation" (once it exists). I'll check with legal if "The IPFS Authors" can be defined as a legal entity without too much trouble. (wonder what Go did)

CLA or DCO

• Yep, we're covered by the DCO (developer certificate of origin). It's like a CLA but without assigning the copyright over.
• Yes the DCO SHOULD happen in all repos. It's super annoying to have to do it on every commit and thus check it with gitcop/CI. the issue though is that our legal team has said that "there needs to be an explicit step" that expresses intent, meaning we can't just have a file in the repo that says everything merged is fine. So actionable thing out of this:
  • setup DCO checks in all repos

Patents

• The Go PATENTS file is the equivalent of the Apache 2.0 patents protection. It's meant to be used with MIT and BSD licensed software.
• We actually need an equivalent of this patents file in all repos -- would be nice not to have to involve Protocol Labs but the Go team clearly needed a legal entity with IP to bear to make the grant mean anything (Google).
  • So for now, rewrite it as Protocol Labs.
  • I'll ask PL Legal Team if we can make the clause broader: include others who contribute. I'm bothered that that file only says Google. What about other people who have contributed to Go?
• To add this PATENTS file to a repo we will need to get a signoff from all contributors of that repo to date, and include the signoff list in the commit (either via link to IPFS or embedded). We can collect signoff with a google form. This can be a bit painful.
  • Create PATENTS file sign off form
  • Collect signatures for each repo so far.

[Mr0grog]

I created ipfs/ipfs#319 yesterday before I had seen this — should I close it, or is it worth keeping open because its scope is a little narrow than all the issues discussed here? Given the profusion of projects and licensing schemes, I think it’s helpful to have a document here or in ipfs/pm or ipfs/ipfs that specifies what licensing scheme should be used for projects going forward.

I'll check with legal if "The IPFS Authors" can be defined as a legal entity without too much trouble.

Did that ever happen? What should we be using in ipfs-inactive/docs#65 ?

Re: patents, did anything happen with that? As far as I can see, no repos have a PATENTS file.

Re: DCO (apologies if these are obvious, this project is my first encounter with DCO):

• Does the actual DCO (https://developercertificate.org) need to be reproduced or at least mentioned & linked somewhere in the repository source? (e.g. Docker does it in the CONTRIBUTING.md file; a quick check of Linux and Chef show they do, as well.) We don’t appear to do that anywhere.

• Our DCO signoff template includes a license name (seems unusual). Do we have to ensure that license name matches the one the project as a whole is licensed under (i.e. the LICENSE file) or is it licensing the changes in the commit, in which case it just needs to be permissive enough to to be distributed under the project’s license (so MIT would probably always be OK)?

• What does it mean if signoff isn’t enforced? It seems pretty well respected in ipfs/go-ipfs, but you can tell which commits to master where made through the GitHub UI because they all lack a DCO signoff (does that matter? Seems like it might). That said, a cursory inspection of plenty of other projects in the ipfs org show DCO isn’t well enforced at all—there are plenty of changes that lack it.

[Kubuxu]

We do mention it in go-ipfs where we use DCO: https://github.com/ipfs/go-ipfs/blob/master/contribute.md#commit-messages

[Kubuxu]

DCO is mostly enforced in go-ipfs because of gitcop. There are github apps that help enforce DCO org wide.

[Mr0grog]

We do mention it in go-ipfs where we use DCO

👍 and I see I missed a similar link in the common guidelines in this repo. Guess I was looking for the text and missed that there were links.

DCO is mostly enforced in go-ipfs because of gitcop. There are github apps that help enforce DCO org wide.

Totally, and it seems to be working reasonably well there. Not sure if it’s not set up or just not paid attention to on all the other ~400 repos (if you are counting across orgs). And even in go-ipfs, most merge commits lack it (this Chef blog post would seem to indicate those commits should have multiple signoffs).

[Kubuxu]

Not sure if it’s not set up

It is not set up on other repos.

most merge commits lack it

Merge commits are done via GH UI so the don't have it, from another side I don't really see a reason for them to have signoffs. Merge commits are just saying "join those N changes" and those changes are signed-off.

multiple signoffs

The case of multiple sign-offs is multiple developers working on one commit which is very frequent in Linux as commits are moved via email as patchsets and are modified directly.

In our case we are mostly adding another commits not modifying old ones.