Repository navigation
Licensing #139
Description
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?
Reacted by Marcin Rataj and Juan Benet
Activity
Added notes from Aug 8
flyingzumwalt commentedon Aug 11, 2016
👍 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 commentedon Aug 11, 2016
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 commentedon Aug 11, 2016
@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 commentedon Aug 12, 2016
LICENSEfile. 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)PATENTSfile is the equivalent of the Apache 2.0 patents protection. It's meant to be used withMITandBSDlicensed software.Protocol Labsbut the Go team clearly needed a legal entity with IP to bear to make the grant mean anything (Google).Protocol Labs.Google. What about other people who have contributed to Go?PATENTSfile sign off formMr0grog commentedon Apr 6, 2018
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/pmoripfs/ipfsthat specifies what licensing scheme should be used for projects going forward.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
PATENTSfile.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.mdfile; 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
LICENSEfile) 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 theipfsorg show DCO isn’t well enforced at all—there are plenty of changes that lack it.Kubuxu commentedon Apr 6, 2018
We do mention it in go-ipfs where we use DCO: https://github.com/ipfs/go-ipfs/blob/master/contribute.md#commit-messages
Kubuxu commentedon Apr 6, 2018
DCO is mostly enforced in go-ipfs because of gitcop. There are github apps that help enforce DCO org wide.
Mr0grog commentedon Apr 6, 2018
👍 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.
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 commentedon Apr 6, 2018
It is not set up on other repos.
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.
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.
Mr0grog commentedon May 7, 2018
OK, so there is now a documented policy at
ipfs/community/docs/licensing-policy.md.It does not address patents, but otherwise it should address the rest of this issue. Should we close this? (Should we make a new issue for patents?)
Mr0grog commentedon Jun 4, 2018
Pinging @Kubuxu @flyingzumwalt @jbenet @RichardLitt is there still more to do here or should I close this issue?
daviddias commentedon Oct 16, 2018
Thank you @Mr0grog, let's continue any follow up with PRs to https://github.com/ipfs/community/blob/master/LICENSING_POLICY.md