I had a look at it last week, does not offer PSC the same level of flexibility as CLA. And does not seem to cover common cases (like you mentioned with an employee).
The project doing this ( https://about.gitlab.com/2017/11/01/gitlab-switches-to-dco-license/) has a very permissive MIT license, so I can see why they do not realize the flexibility benefit of a CLA. MIT code can already be used by other projects due to wide compatibility. The same developer origin approach used for a LGPL project would not be as effective in sharing. We just used our OSGeo CLA with the GeoTools project to donate some code to JTS, something we could not of done without a CLA. It maybe of interest that we have a government CLA in the works for OSGeo, waiting on legal review. This will hopefully allow organizations that are restricted to the public domain to participate more easily with open source. Open source is a very tricky balance of trust. Theses licenses provide tools to help us get along. I like CLAs as a safety value providing more options to the project teams to share and collaborate. The signed off thing is easily spoofed; we did some experiments in 2016 to see if it would work. That said just like headers at the top of the file it can be a social signal that a team cares about open source and not screwing up this game of trust. On Sun, Nov 5, 2017 at 6:25 AM Even Rouault <even.roua...@spatialys.com> wrote: > Hi, > > > > Some food for thought for our projects regarding how to deal with > contributions, triggered > > by a recent reading: > > https://lwn.net/Articles/738048/#Comments > > > > Contributor License Agreement (CLA) tend to be replaced by a Developer > Certificate > > of Origin (DCO) in a number of projects: > > https://developercertificate.org/ > > > > DCO is the mechanism required by the Linux Kernel originally, and by other > projects > > now, to accept contributions, as DCO requires less bureaucracy than a CLA > and is > > seen more friendly by open source communities: > > > > CLA tastes more like corporate requirement and can typically require an > employee to > > see his boss, make him approve the CLA, etc... > > > > An example how a project implemented DCO in their CONTRIBUTING.md : > > https://github.com/moby/moby/blob/master/CONTRIBUTING.md > > > > One thing that was no completely clear to me is how a > > Signed-off-by: John Smith <jsm...@example.com>" in a commit message means > that > > the contributor agrees to the the DCO terms. But reading the help of git > commit for the > > -s option that is used to add the Signed-off-by, I see: > > > > -s, --signoff > > Add Signed-off-by line by the committer at the end of the commit log > message. > > The meaning of a signoff depends on the project, but it typically > certifies that > > committer has the rights to submit > > this work under the same license and agrees to a Developer Certificate of > Origin > > (see http://developercertificate.org/ for more information). > > > > So this is typically a git-centric mechanism. > > > > Even > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com > _______________________________________________ > Discuss mailing list > Discuss@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/discuss -- -- Jody Garnett
_______________________________________________ Discuss mailing list Discuss@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/discuss
