[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Individual|Corporate] Contributor License Agreement



Hi Ian, Ole, Ben,

I wanted to thank you for the quick and clear answers which are very helpful,
as I'm not very comfortable with legal stuff, all the more in english with
legal wording :) . So it's good to have people here to advise.

My confusion came due to my misunderstanding of the contribution back aspect
for instance of a patch, which is not the same as making a patch :) which is
indeed, still allowed, and not subject to specific terms other than the GNU
LGPL v2.1 (sorry for the previous erronous naming).
I now clearly get the DFSG compliance of those.

Though, as Ian mentionned, and as I intuitively felt, I still think there are
unpleasant conditions in this agreement, in respect to the social contract will
of giving back to the community, amongst others.
It's a real stymie.

My best option is, indeed, to ask to remove those agreements from the source.

F.

On Wed, 7 Sep 2016 17:01:21 +0100, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> Frederic Bonnard writes ("[Individual|Corporate] Contributor License Agreement"):
> > I'm wondering if an agreement meets the DFSG during the packaging
> > process of a library called libvecpf. It's under GPLv2.1+ but there are
> > 2 additional files which are agreements.
> > Depending if you are an individual contributor or a corporate one :
> > - https://github.com/Libvecpf/libvecpf/blob/master/ICLA.txt
> > - https://github.com/Libvecpf/libvecpf/blob/master/CCLA.txt
> 
> Agreeing to such a "contributor licence agreement" is not necessary if
> one is simply a downstream, using, or developing, the code.  The code
> itself is licenced under the GNU LGPL v2.1, as stated in the README
> and LICENCE files.
> 
> The point at which signing the CLA is required, is when one makes a
> submission to upstream.  That is, upstream will refuse to accept
> patches which come without a signed CLA from the contributor.
> 
> 
> CLAs vary, and there are different views within Debian about CLAs.
> 
> Looking at this particular CLA, it is the worst kind: it is an
> asymmetric setup, which (if the contributor signs it) grants the
> upstream the right to make proprietary versions, while downstreams are
> bound by the copyleft.  Personally, I would not sign such a CLA.
> 
> I think it is consensus within Debian that contributors to Debian
> should not be required to sign such CLAs.
> 
> And of course, contributors to Debian need to be able to make changes
> to the code, including the "upstream" parts of the code, and share
> them with other Debian users and with our downstreams and with peer
> distros.
> 
> 
> But that does not mean that the package cannot be in Debian despite
> the CLA.  (There are other packages in Debian whose upstreams impose
> unpleasant CLAs.)
> 
> If you as the prospective maintainer are prepared to commit to extra
> work, then Debian's needs (and those of our downstreams, users, and
> collaborators) can be met.
> 
> Effectively, I think you would need to take on the role of upstream,
> as regards Debian:
> 
> You would need to take and carry, indefinitely, all technically
> suitable patches provided by those Debian contributors who refused to
> sign the CLA.  Where the Debian version of the package exhibits bugs,
> it might be necessary for you to investigate them, since upstream
> probably wouldn't want to work on the Debian version.
> 
> You should collaborate with any other distros etc., so that other
> downstreams can share patches which are un-upstreamble for CLA
> reasons.
> 
> Perhaps eventually the version with the un-upstreamable Debian patches
> will become the most widely used version, displacing the original
> upstream.  If not, then there will be merge work to be done in
> perpetuity, as Debian's version would effectively be a fork.
> 
> If you are prepared to do all that, then as far as everyone else is
> concerned, the program is free software.
> 
> 
> > If so, what could be changed to make it DFSG compliant ?
> 
> Of course it would be much better if upstream dropped the CLA.  It may
> be worth asking.
> 
> But some CLA-imposing upstreams have deliberately decided to have a
> CLA, because they feel that their business interests are best served
> by putting themselves in a position of power over their users and
> downstreams.  Such (unethical) upstreams are unlikely to agree to get
> rid of the CLA.
> 
> Ian.
> 
> 
> -- 
> Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.
> 
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
> 


Reply to: