[Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement

[Marc Deslauriers]

On 2015-01-04 03:48 PM, Scott Kitterman wrote:
> On Friday, January 02, 2015 16:38:13 Marc Deslauriers wrote:
>> On 2015-01-02 04:09 PM, Scott Kitterman wrote:
>>> On Friday, January 02, 2015 01:45:48 PM Stephen M. Webb wrote:
>>> ...
>>>
>>>> Argument:  The CLA grants more rights to Canonical than the contributor
>>>> gets.
>>>>
>>>> Response:  No, it definitely does not.  It grants to Canonical a clearly
>>>> defined subset of the rights the contributor has, yet the contributor
>>>> keeps
>>>> all his or her original rights.  The contributor loses nothing save maybe
>>>> the ability to personally control what Canonical can do with its
>>>> investment, and that's not a right but an unintended consequence that the
>>>> unethical can use to their advantage.  The premise is invalid.
>>>
>>> ...
>>>
>>> Snipped the rest, since it doesn't, IMO, need further discussion.
>>>
>>> Here you're wrong.  If Canonical releases GPL code, the GPL constrains
>>> what I can do with that code.  Since Canonical is the copyright owner,
>>> they are not constrained.  If I contribute code under the CLA, Canonical
>>> is not constrained to the GPL like I am regarding the code in that
>>> project.  They have the same rights over my code as if they had written
>>> it.
>>
>> Exactly, so as a contributor, you can't remove rights that Canonical already
>> has over the code they've developed.
> 
> Of course not and the lack of the CLA doesn't do that.

Yes it does. The lack of a CLA would prevent Canonical from re-licensing the
code, which would mean a single contributor could remove the right Canonical
already has.

  In fact, Canonical
> threw away code from external contributors that declined to sign the original 
> copyright assignment (which was replaced by the current CLA) and rewrote it 
> themselves.  That claim doesn't make any sense.

Of course it does. If you contribute code to a project but don't sign a CLA or
assign copyright, you are preventing the copyright owner from re-licensing the
code. The kernel will forever be stuck on GPLv2 even though GPLv3 is now
available which is better. Hopefully the GPL license will never get struck down
in court somewhere.

> 
>> If there was no CLA, you could prevent Canonical from relicensing the
>> software to something possibly even better or free-er than the GPL in the
>> future.
> 
> That's true, but the primary objection I've seen to the CLA is that it permits 
> proprietary relicensing.  If that were removed, I for one would find it much 
> more reasonable.

What if it removed the specific mention of proprietary licensing, but included
the possibility of re-licensing it under a BSD license? That would be a complete
equivalent, but for some reason people think that it's better :) Nothing would
prevent Canonical from re-licensing it as BSD, _not_ redistributing the source,
but then using it in a proprietary product.

I for one agree with RMS on this one, and personally believe that selling GPL
exceptions is acceptable. It's a nice way of advancing free software
development, as long as part of the exception is making sure all modifications
and improvements make their way to the GPL version also.

That being said, I'm not aware of any instances where Canonical has actually
exercised their right to re-license code to a proprietary license, but I am
aware of instances where Canonical re-licensed code to another open source
license so it could be integrated in the upstream project.

> 
>>> It doesn't matter for you, since your contributions are a work made for
>>> hire and Canonical owns it regardless, but for people in the broader
>>> community who are doing this for free in the interest of improving free
>>> software the distinction matters a lot.
>>
>> I don't understand this. How does giving Canonical the right to relicense
>> your contribution conflict with the goal of improving free software? This
>> only matters to people who exclusively contribute to GPL licensed projects,
>> right? I mean, if you contribute to something BSD or MIT licensed, you're
>> basically allowing anyone to make it proprietary. Do BSD and MIT licensed
>> projects conflict with your goal of improving free software?
>>
>> I do agree that if you're a contributor who exclusively contributes to GPL
>> licensed projects, you may have an issue with Canonical relicensing your
>> code. In which case, just don't sign the CLA and fork the project, like the
>> GPL allows you to do.
> 
> I've heard this argument before and I think it's logically unsound.  If the 
> projects in question were BSD/MIT licensed, then it would be right on target, 
> but they aren't.  

I still don't understand. What is the difference? Objections I usually hear are
in these four categories:

1- "I don't want Canonical to re-license my contributions as proprietary software".

This is a valid point. If Canonical didn't have a CLA, but only produced
software under BSD or MIT licenses, you'd have the same objection. So this
clearly isn't a CLA objection, it's a license preference objection. If you only
want to contribute to GPL licensed software because you never want your code to
be used in proprietary software, than you shouldn't sign a CLA, whether it be
Canonical's CLA or Qt's CLA.

2- "I want to have the same rights as Canonical and re-license Canonical's
software as proprietary software."

Sorry, but you can't. Canonical's software is GPL. Only Canonical has that
right, because they are the copyright holders. If you believe your contribution
should grant you the same rights as Canonical has, I'm sorry, but that's not how
that works. If you want to be able to re-license code as proprietary, you
shouldn't contribute to GPL licensed projects.

3- "I don't want to sign the CLA paperwork"

This is a very valid objection, but unfortunately, it's a fact of life. If
Canonical wants to be legally protected that the contribution you want to submit
is your own work and not the product of work for hire, or has been plagiarized,
then you need to get lawyers involved.

If the company you work for doesn't want to sign the CLA, chances are they
didn't want you to submit that contribution in the first place, in which case
Canonical could have possibly been in a bad position legally. If you're a
billion dollar company, you can probably assume the risk and rewrite any code
that came from bad or legally encumbered contributions. If you're Canonical,
accepting code without a legal agreement is a risk that can't be ignored.

4- "Canonical is evil because they have a CLA."

Yep, it's an easy target for competitors who don't have one. If Canonical got
rid of the CLA, they'd simply switch to some other reason to bash Canonical.

> 
> The issue that I've seen most people complain about (and what I think is an 
> issue myself) is the imbalance between outbound rights from contributors and 
> outbound rights from Canonical.

So you think your 100 line patch should give you the same rights as the
copyright holder of the 200k line project? Honestly, this argument is completely
ridiculous.

> 
>> Honestly, I can probably count on my fingers the number of people who had an
>> actual desire to contribute to Canonical projects but were prevented by the
>> CLA. If this was as big an issue as some Canonical competitors have made it
>> out to be, all Canonical's software would already be forked in various PPAs
>> and repositories.
> 
> SDDM basically exists because of the CLA (at least it's being used in KDE 
> because of it).  Canonical projects like Appmenu-Qt (I think that's the right 
> one) had contributors from non-Ubuntu KDE contributors before the copyright 
> assignment/CLA policies were instituted.  
> 
> Maintaining a fork is a lot of work.  Generally people aren't going to fork, 
> they're just going to use something else that it's easier to contribute to.  
> In the one case I'm familiar with, forking LightDM instead of using the 
> substantially less mature SDDM was never even considered.

Yes, and there is nothing wrong with that approach. Not only do you gain the
advantage to having your own code base, but you don't need to jump through the
hoops of getting your contributions accepted upstream.

There is absolutely nothing wrong with doing your own thing and reinventing the
wheel if you think that will be the best plan long-term.

It's hard to contribute to a project if your goals aren't perfectly aligned with
it. As an upstream, it's hard to have people contribute to your software that
don't have the same vision of what it should be. It invariably ends up in two
ways: downstream is upset that upstream won't accept patches to add the kitchen
sink, or upstream accepts everything and project turns into a gigantic mess that
includes the kitchen sink. Once a project starts accepting everything, it
becomes bloated, untestable, and unmaintainable, at which point someone starts
developing a better alternative.

More often than not, you're better off reinventing the wheel.

> 
> As far as I know, much of what Canonical produces isn't even packaged outside 
> Ubuntu, so I don't think there's a great deal of demand that would lead to 
> forks.

A lot of stuff Canonical produces is in fact packaged in other distros. bzr,
lightdm, cloud-init, upstart, for example. I don't think the CLA has anything to
do with what is packaged and what isn't.

> 
> I don't know how much of a problem Canonical's competitors claim the CLA is.  
> I can point to specific instances of it being problematic in the areas of the 
> project I'm involved in. 

I'm sure the alternative that was ultimately chosen will work out just fine.

Marc.