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

[Dimitri John Ledkov]

On 10 January 2015 at 18:19, Michael Banck  wrote:
> On Mon, Jan 05, 2015 at 10:01:49AM -0500, Stephen M. Webb wrote:
>> Maybe.  I contributed small patches to GCC for years before taking the
>> leap and signing my soul over to the FSF so I could get them to accept
>> more substantial pieces of work (and they could relicense it to third
>> parties to earn revenue).
>
> My understanding of the FSF/GNU copyright assignment is that in their
> part of the legal paperwork, they pledge to only relicense the code
> under a license of similar spirit.  So the above is FUD AFAICT.
>
> Now if you don't trust the FSF that much that you think GPLv4 will be a
> proprietary license, then maybe your above statement makes sense.
>
> OTOH, if you haven't understood the FSF/GNU copyright assignment, it
> might explain why you seem to be oblivious to other people's
> reservations with the Canonical CLA.

There is a wide amount of people who have the view that GPLv3 was not
in spirit of GPLv2 and should have been given a new/different name
instead.

Also the GFDL 1.3 is totally not in-spirit of previous GFDL revisions
and allows re-licence under CC-BY-SA 3.0 for a subset of 1.2 licensed
things.

Similarly the whole "Invariant Sections" bits are completely not
in-spirit of the free software.

Out of all the things that FSF do, "publishing revisions of their
licenses of similar spirit" is that bit that they consistently fail to
deliver.

Above points however are simply against FSF and that it's own
copyright assignment is just as horrible.

GNU project however, does not require copyright assignment to FSF, it
requires a copyright assignment to an entity. E.g. GNU bazaar-ng
holder is Canonical.

-- 
Regards,

Dimitri.

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Neal McBurnett]

On Sun, Jan 11, 2015 at 09:52:49AM -0500, Stephen M. Webb wrote:
> On 01/10/2015 01:19 PM, Michael Banck wrote:
> > On Mon, Jan 05, 2015 at 10:01:49AM -0500, Stephen M. Webb wrote:
> > 
> > My understanding of the FSF/GNU copyright assignment is that in their
> > part of the legal paperwork, they pledge to only relicense the code
> > under a license of similar spirit.  So the above is FUD AFAICT.
> 
> Selling GPL exceptions is not disapproved of by RMS or the FSF; in fact they 
> have even enouraged it.  Consider reading
> Richard Stallman's essay on this at the FSF [1].
> 
> It is not FUD to say they could practice what they preach, not is it not FUD 
> to point out they require total transfer of
> ownership of the copyright (which mean, in my country, extinguishment of my 
> own rights as author) as opposed to the
> Canonical CLA, which only requires a license for the same rights the author 
> continues to enjoy.  Those are simple facts
> backed up by what the FSF themselves say publicly.
> 
> [1] https://www.fsf.org/blogs/rms/selling-exceptions
> 
> -- 
> Stephen M. Webb  

Stephen, you should re-read what you link to.  If FSF wants to allow others to 
embed their work in proprietary software, they don't sell an exception, they 
use a permissive licens:

To quote:

 there are occasional cases where, for specific reasons of strategy, we decide 
that using a more permissive license on a certain program is better for the 
cause of freedom. In those cases, we release the program to everyone under that 
permissive license.

 This is because of another ethical principle that the FSF follows: to treat 
all users the same. An idealistic campaign for freedom should not discriminate, 
so the FSF is committed to giving the same license to all users. The FSF never 
sells exceptions; whatever license or licenses we release a program under, that 
is available to everyone.

Neal McBurnett http://neal.mcburnett.org/

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Stephen M. Webb]

On 01/10/2015 01:19 PM, Michael Banck wrote:
> On Mon, Jan 05, 2015 at 10:01:49AM -0500, Stephen M. Webb wrote:
> 
> My understanding of the FSF/GNU copyright assignment is that in their
> part of the legal paperwork, they pledge to only relicense the code
> under a license of similar spirit.  So the above is FUD AFAICT.

Selling GPL exceptions is not disapproved of by RMS or the FSF; in fact they 
have even enouraged it.  Consider reading
Richard Stallman's essay on this at the FSF [1].

It is not FUD to say they could practice what they preach, not is it not FUD to 
point out they require total transfer of
ownership of the copyright (which mean, in my country, extinguishment of my own 
rights as author) as opposed to the
Canonical CLA, which only requires a license for the same rights the author 
continues to enjoy.  Those are simple facts
backed up by what the FSF themselves say publicly.

[1] https://www.fsf.org/blogs/rms/selling-exceptions

-- 
Stephen M. Webb  

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Michael Banck]

On Mon, Jan 05, 2015 at 10:01:49AM -0500, Stephen M. Webb wrote:
> Maybe.  I contributed small patches to GCC for years before taking the
> leap and signing my soul over to the FSF so I could get them to accept
> more substantial pieces of work (and they could relicense it to third
> parties to earn revenue).

My understanding of the FSF/GNU copyright assignment is that in their
part of the legal paperwork, they pledge to only relicense the code
under a license of similar spirit.  So the above is FUD AFAICT.

Now if you don't trust the FSF that much that you think GPLv4 will be a
proprietary license, then maybe your above statement makes sense.

OTOH, if you haven't understood the FSF/GNU copyright assignment, it
might explain why you seem to be oblivious to other people's
reservations with the Canonical CLA.


Michael

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marc Deslauriers wrote on 05/01/15 04:45:
> ...
> 
> So you agree with me that if you don't want your code to be 
> distributed as proprietary software, you shouldn't be contributing 
> to BSD or GPL-with-CLA software?

If you think proprietary redistribution of the work you contribute to
is a bad idea, the CLA is suboptimal because it gives Canonical that
option.

If you think proprietary redistribution of the work you contribute to
is a good idea, the CLA is suboptimal because it gives *only*
Canonical that option.

However, that inefficiency for individual contributors will sometimes
be less than the cost of developing/adopting a symmetrically-licensed
alternative. This is the case for Cups, for example (where only Apple
can redistribute proprietarily), but apparently has not been the case
for LightDM (where only Canonical can).

> Because big successful projects such as MySQL and Qt have _proven_ 
> that selling GPL exceptions is a valid model that advances the 
> quality of open source software.

Similarly, it is apparently the case for the MySQL fork MariaDB (where
only the MariaDB Foundation can redistribute proprietarily), while the
contemporary MySQL fork Drizzle (where no-one can) seems to have died.

> Honestly, I wish more software was like that.
> 
> I want the _default_ license when people write software to allow 
> access to source code. I want every single application I run on my 
> Android phone to come with source code. The only way to achieve 
> that is to stop trying to prevent developers from having a revenue 
> stream with their creation.
> 
> For example, why isn't the Ghostscript model good enough for open 
> source enthusiasts? I'd gladly give a timed GPL-exception in order 
> to get high quality software that isn't developed in a basement,
> or with VC money. I'd gladly accept that a certain piece of
> software is used in some proprietary product as long as a contract
> is in place that assures me that every single improvement makes its
> way to the GPL version.
> 
> As long as people criticize models that allow developers to invest 
> money in an open source software project without being able to 
> monetize their investment, we'll always live in a world where open 
> source software is the exception rather than the norm. That is not 
> why I have spent a large part of my life dedicated to open source 
> software. I am of the opinion that free licensing is superior, but 
> every time someone tries to come up with a business model that 
> allows developers to actually get paid to develop it, it gets 
> rejected by the very same community who want to see it thrive.

All that could be true, *and still* individual contributors would
rationally prefer, all else being equal, to contribute to a symmetric
project than an asymmetric one. It might be a tragedy of the commons:
collectively we're better off with asymmetric licenses, but individual
contributors are more effective contributing under symmetric ones.

Canonical recently released LXD under the Apache License, and
therefore without CLA. This will be an interesting data point for how
much the CLA is a real disincentive, and how much it is merely a
punching bag.


- -- 
mpt

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlSrwtMACgkQ6PUxNfU6ecqGcACgyHiC9UFeqPdXWi1rywqsAWGo
Fr4AoKs9LNmYjki1EQdFO7ix986lvtEz
=Jibk
-END PGP SIGNATURE-

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Clint Byrum]

Excerpts from Marc Deslauriers's message of 2015-01-04 14:39:07 -0800:
> 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 u

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

[Scott Kitterman]

On Sunday, January 04, 2015 11:45:30 PM Marc Deslauriers wrote:
> >>> 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.>
> > 
> >
> > Ultimately, I'm sure your right.  I think it would, however, have been
> > better  for all concerned if non-technical barriers to contribution did
> > force two efforts where one would have done.
> 
> Sorry, but I'm pretty sure some other barriers would have prevented
> contributions if a simple CLA was the first thing that was blamed. Do KDE
> developers not contribute to Qt? Or is Qt only used because there is no
> valid alternative?

Snipping down to just this since I think the discussion is largely at or past 
the point of diminishing returns (we disagree on some stuff and I think that's 
fine).

I think for KDE there is a particular history that causes Canonical to be 
treated differently than whoever owns Qt at the moment.  Here's the history 
lesson for those that weren't around.

KDE/Canonical collaboration got started as part of the development effort for 
Kubuntu Karmic (9.10) [1].  It was built around the idea of joint 
collaboration.  Canonical was contributing both to it's own repositories and 
KDE upstream.

This later evolved into a joint effort on systray replacement [2].  This 
evolved into libdbusmenu-qt which had a combination of Canonical and KDE 
contributions.  Then, later in the year, the day after one prominant KDE 
contributor declined to sign the Canonical Contributor Agreement [3], without 
notification, all of the KDE contributed code was removed [4] and development 
was moved to Launchpad [5].  Since, as I've mentioned up-thread, the CA/CLA 
have never been relevant to Ubuntu (the distro), in order to prevent 
regressions with the new release, we added it all back as a distro patch [6] 
and carried the patch until the code had been rewritten by Canonical [7].

The situation with Qt is far different.  Note in this earlier post by the same 
person the distinction [8].  Also, the objections weren't about the concept, 
but about the specifics of the CA [9].  

The CLA is clearly a great improvement over the original CA, but I think for a 
number of people in KDE, Canonical is now in the once bitten, twice shy 
category.  "Hey, my agreement is better now and I promise I won't 
retroactively change conditions on accepting contributions and throw away your 
code again" is probably not going to sound attractive.

Which, at the end, gets us to the LightDM example where the CLA (with that 
history behind it) ends up being the sole reason SDDM is selected instead 
[10].  If LightDM/SDDM had been the first time this came up, I suspect it 
wouldn't have been such an issue.  It likely would have been manageable if the 
CLA had just applied to the front end and not the back end as well since KDE 
would have been using it's own front end, not covered by the CLA since it's 
not Canonical developed.

Scott K

[1] http://skitterman.wordpress.com/2009/07/17/kubuntu_ayatana_has_arrived/
[2] http://aseigo.blogspot.com/2010/04/system-tray-progress.html
[3] aseigo.blogspot.com/2010/09/copyright-assignments-gone-wild-or-why.html
[4] http://bazaar.launchpad.net/~dbusmenu-team/libdbusmenu-qt/trunk/revision/177
[5] http://bazaar.launchpad.net/~dbusmenu-team/libdbusmenu-qt/trunk/revision/180
[6] https://launchpad.net/ubuntu/+source/libdbusmenu-qt/0.6.3-0ubuntu1
[7] https://launchpad.net/ubuntu/+source/libdbusmenu-qt/0.8.0-0ubuntu1
[8] http://aseigo.blogspot.com/2010/08/copyright-assignments-of-third-kind.html
[9] 
http://aseigo.blogspot.com/2010/09/copyright-assignments-gone-wild-or-why.html?showComment=1284586036043
[10] http://aseigo.blogspot.com/2013/03/logging-into-plasma-workspaces-2.html

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Stephen M. Webb]

On 01/05/2015 09:38 AM, David Henningsson wrote:
> On 2015-01-05 14:32, Stephen M. Webb wrote:
>> On 01/05/2015 05:08 AM, David Henningsson wrote:
>>> Second; if you contribute just a one or two line fix, then probably the 
>>> biggest issue with the CLA is the paperwork. And
>>> as long as your contributions are tiny compared to the total project, sure. 
>>> One can just give the code away.
>>
>> A one or two line fix does not actually require the CLA.  Only contributions 
>> of a "substantial nature" (ie. a fix that
>> is not 10 lines or fewer or could not easily be described over the telephone 
>> to someone familiar with the code) require
>> the paperwork.
>>
>> If you're just proposing spelling fixes in the documentation or a one-liner 
>> to use the newer file name for an icon, it
>> should get accepted upstream without fuss.  If you contribute such small 
>> fixes frequently, the sum total will exceed the
>> threshold and you will need a CLA on file for additional contributions.  
>> This is a judgement call on behalf of the
>> project manager, and the goal is to balance the inconvenience (to a 
>> contributor) of the CLA against the inconvenience
>> (to Canonical) of not having the CLA.
> 
> I assume the lack of an exact and clear measure of whether a patch requires a 
> CLA makes people err on the side of
> caution, requiring CLAs for where it should not be needed.

Maybe.  I contributed small patches to GCC for years before taking the leap and 
signing my soul over to the FSF so I
could get them to accept more substantial pieces of work (and they could 
relicense it to third parties to earn revenue).
 The fact that I had to give up my first born for the big stuff never disuaded 
me from doing the small stuff.  I expect
that's different for others, especially now you can read on the Internet how 
evil Canonical's CLA is without actually
having to understand.

If fewer trivial contributions get made with the CLA than without it, more 
trivial contributions get made with the
trivial contribution exception to the CLA requirement than without it.  It's a 
net benefit.

> That is a problem for both sides, i e, not only for the project manager, but 
> also if you're contributor unwilling to
> sign the CLA, you would not write the patch in the first place if there was a 
> risk it would not get in due to the CLA
> requirement.

If someone is unwilling to ever submit a patch because of their need for utter 
control over what someone does with a
copy of their code, it's unlikely they're going to submit that code no matter 
how small it is, whether there a CLA gets
signed or not.  The condition of relicense is not changed, just the need for 
paperwork.

> There isn't a software you can feed with patches and it outputs yes or no 
> depending on whether a CLA is needed or not? :-)

No.  No robot has yet been invented that can replace human judgement in all 
cases.  Maybe next year, but I'm a sceptic.

-- 
Stephen M. Webb  

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[David Henningsson]

On 2015-01-05 14:32, Stephen M. Webb wrote:

On 01/05/2015 05:08 AM, David Henningsson wrote:

Second; if you contribute just a one or two line fix, then probably the biggest 
issue with the CLA is the paperwork. And
as long as your contributions are tiny compared to the total project, sure. One 
can just give the code away.


A one or two line fix does not actually require the CLA.  Only contributions of a 
"substantial nature" (ie. a fix that
is not 10 lines or fewer or could not easily be described over the telephone to 
someone familiar with the code) require
the paperwork.

If you're just proposing spelling fixes in the documentation or a one-liner to 
use the newer file name for an icon, it
should get accepted upstream without fuss.  If you contribute such small fixes 
frequently, the sum total will exceed the
threshold and you will need a CLA on file for additional contributions.  This 
is a judgement call on behalf of the
project manager, and the goal is to balance the inconvenience (to a 
contributor) of the CLA against the inconvenience
(to Canonical) of not having the CLA.


I assume the lack of an exact and clear measure of whether a patch 
requires a CLA makes people err on the side of caution, requiring CLAs 
for where it should not be needed.


That is a problem for both sides, i e, not only for the project manager, 
but also if you're contributor unwilling to sign the CLA, you would not 
write the patch in the first place if there was a risk it would not get 
in due to the CLA requirement.


There isn't a software you can feed with patches and it outputs yes or 
no depending on whether a CLA is needed or not? :-)


--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[David Henningsson]

On 2015-01-05 13:46, Marc Deslauriers wrote:

On 2015-01-05 05:08 AM, David Henningsson wrote:

On 2015-01-05 05:51, Marc Deslauriers wrote:

Right, but 100 lines quickly turns into 2k lines by 20 different contributors
you now have to track down or replace.


First; not all lines carry the same weight IMO. Somewhat overgeneralising now,
but when developing new features, you tend to write a lot of lines fairly
quickly. When the code is stable or near-stable, you spend a lot of time
integrating, testing and debugging, and the result might end up in just a one or
two line fix.

My gut feeling is that the newbie contributors, at least initially, fall mostly
in the second category. Their contributions are pure quality improvements, and
should be recognised and valued as such.

Second; if you contribute just a one or two line fix, then probably the biggest
issue with the CLA is the paperwork. And as long as your contributions are tiny
compared to the total project, sure. One can just give the code away.


Yes, the paperwork involved is an issue. I'd say it's perhaps the biggest issue.


It's when your contributions are larger, that things become complicated. With
all code belonging to the company, that imposes a soft limit of how far you can
rise in ranks of a project. Because you know that the final say about the
direction of the project is controlled by the company.


I'm not sure how this is different than any other project. The final say is
determined by whoever runs the project and/or has commit rights.


For many projects, the more you contribute to it, the larger probability 
you end up being among the ones running the project and having commit 
rights. That might be true for both CLAed and non-CLAed projects. But 
then if there's a fundamental clash in opinions between you and the rest 
of the people running the project, you can fork the project, go in your 
own direction. If the copyright is symmetrical, there would be two 
projects starting off a base that's equal for both parties. You might 
even be the one that can keep the original project name.


And I would argue that even if an actual fork rarely happens, the 
existence of that way out affects the power balance between the people 
working with the project, the decision making, and the final say.



Also, what if an external contributor sees a business opportunity that Canonical
would not be interested in pursuing? That would require significant refactoring
and maintenance of the product, and a big chunk of new code, so maybe Canonical
and the external party have contributed 50% of the code each? Now it is directly
unfair that all code belongs to Canonical, when Canonical and the external party
could be partners on equal footing, sharing maintainership, leading to a win-win
for both.


If that business deal doesn't require re-licensing, then there is no issue, it
can be done with the existing license. Canonical doesn't have any advantage.

If that business deal does require re-licensing, then there is a great advantage
to having the CLA. If the software was simply under GPL with no CLA, then it
wouldn't be possible for that external contributor to pursue the business
opportunity at all. With the CLA, a deal can be negotiated with Canonical.


If Canonical releases its code under the permissive license that the 
external party is required to license its code under, then it would not 
be necessary to negotiate a deal with Canonical in the first place.



ps- In case it's not clear to everyone reading this thread: I am not a Canonical
spokesperson, my opinions are my own, I have absolutely no insider knowledge of
licensing. So don't bother reporting this as news.


Good point. The same disclaimer applies to me.

--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Stephen M. Webb]

On 01/05/2015 05:08 AM, David Henningsson wrote:
> Second; if you contribute just a one or two line fix, then probably the 
> biggest issue with the CLA is the paperwork. And
> as long as your contributions are tiny compared to the total project, sure. 
> One can just give the code away.

A one or two line fix does not actually require the CLA.  Only contributions of 
a "substantial nature" (ie. a fix that
is not 10 lines or fewer or could not easily be described over the telephone to 
someone familiar with the code) require
the paperwork.

If you're just proposing spelling fixes in the documentation or a one-liner to 
use the newer file name for an icon, it
should get accepted upstream without fuss.  If you contribute such small fixes 
frequently, the sum total will exceed the
threshold and you will need a CLA on file for additional contributions.  This 
is a judgement call on behalf of the
project manager, and the goal is to balance the inconvenience (to a 
contributor) of the CLA against the inconvenience
(to Canonical) of not having the CLA.

Think of it this way:  if it ended up in court, the judge would laugh at 
someone trying to exercise their rights in the
entire code base based on a single spelling correction in a comment, and award 
all costs and penalize the complainant
for mischief.

-- 
Stephen M. Webb  

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Marc Deslauriers]

On 2015-01-05 05:08 AM, David Henningsson wrote:
> 
> 
> On 2015-01-05 05:51, Marc Deslauriers wrote:
>> On 2015-01-04 08:27 PM, Michael Hall wrote:
>>>
>>> On 01/04/2015 07:40 PM, Stephen M. Webb wrote:
 On 01/04/2015 06:44 PM, Scott Kitterman wrote:
>> 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.
> I think I should have the same rights over my 100 lines.  Personally, I 
> find
> the argument that because someone else has made a greater contribution, 
> they
> get control over my work to be ridiculous (I didn't sign any CLAs either).

 You do have the same rights over your 100 lines.   You can always take your
 100 lines and license it to whomever you
 want under whatever terms tickle your fancy.  Canonical could take their
 200k lines and do the same.  That's the right
 copyright grants you, the CLA never takes that away and the GPL is
 irrelevant to that.

 If your 100 line contribution is included in the project and you do not 
 give
 permission for Canonical to exercise its
 rights over its 200k lines, you have denied Canonical their rights and you
 have established (potentially malicious)
 control over their work.
>>>
>>> No, Canonical still retains all rights over it's 200k lines, all that we
>>> would be prevented from doing is exercising those same rights over the
>>> additional 100 lines of code that we did not write.
>>
>> Right, but 100 lines quickly turns into 2k lines by 20 different contributors
>> you now have to track down or replace.
> 
> First; not all lines carry the same weight IMO. Somewhat overgeneralising now,
> but when developing new features, you tend to write a lot of lines fairly
> quickly. When the code is stable or near-stable, you spend a lot of time
> integrating, testing and debugging, and the result might end up in just a one 
> or
> two line fix.
> 
> My gut feeling is that the newbie contributors, at least initially, fall 
> mostly
> in the second category. Their contributions are pure quality improvements, and
> should be recognised and valued as such.
> 
> 
> Second; if you contribute just a one or two line fix, then probably the 
> biggest
> issue with the CLA is the paperwork. And as long as your contributions are 
> tiny
> compared to the total project, sure. One can just give the code away.

Yes, the paperwork involved is an issue. I'd say it's perhaps the biggest issue.

> 
> It's when your contributions are larger, that things become complicated. With
> all code belonging to the company, that imposes a soft limit of how far you 
> can
> rise in ranks of a project. Because you know that the final say about the
> direction of the project is controlled by the company.

I'm not sure how this is different than any other project. The final say is
determined by whoever runs the project and/or has commit rights.

> 
> Also, what if an external contributor sees a business opportunity that 
> Canonical
> would not be interested in pursuing? That would require significant 
> refactoring
> and maintenance of the product, and a big chunk of new code, so maybe 
> Canonical
> and the external party have contributed 50% of the code each? Now it is 
> directly
> unfair that all code belongs to Canonical, when Canonical and the external 
> party
> could be partners on equal footing, sharing maintainership, leading to a 
> win-win
> for both.

If that business deal doesn't require re-licensing, then there is no issue, it
can be done with the existing license. Canonical doesn't have any advantage.

If that business deal does require re-licensing, then there is a great advantage
to having the CLA. If the software was simply under GPL with no CLA, then it
wouldn't be possible for that external contributor to pursue the business
opportunity at all. With the CLA, a deal can be negotiated with Canonical.

Marc.

ps- In case it's not clear to everyone reading this thread: I am not a Canonical
spokesperson, my opinions are my own, I have absolutely no insider knowledge of
licensing. So don't bother reporting this as news.


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Dimitri John Ledkov]

On 2 January 2015 at 12:37, Scott Kitterman  wrote:
> On Monday, December 29, 2014 01:09:57 PM Stephen M. Webb wrote:
>> Fact is, when it comes time for me to accept or reject a contribution, I
>> must outright reject any from an author who has not proven good will, and
>> that proof is the CLA.
>
> Fact is you're required to do so by your employer, so no judgment at all on
> your part is required.  Your thesis would make sense if it required a
> reciprocal grant of rights.  It doesn't.  It demands more from the contributor
> in terms of rights than it granted (I'd find the paperwork annoying, but
> reasonable if that were not the case).
>
> Fact is prior to the CLA, the type of abuses you're worried about didn't
> happen in the project.  In fact, Canonical threw away perfectly good code
> because some people didn't want to retroactively agree to the original
> copyright assignment.
>
> Fact is it's causing external groups to stay away from contributing to
> Canonical  projects (which contributes to the tautology that the CLA is
> reasonable because Canonical is the primary/sole contributor).  If you want a
> specific example, the CLA is the only reason SDDM is the KDM replacement in
> Plasma 5 and not LightDM.
>
> Canonical is free to set the rules for contributions to its projects however
> it wants, but I think you misunderstand why there is a CLA.  For Ubuntu (the
> Linux distribution) there's no CLA and it works fine.
>

A number of high-profile employees have left Canonical because of CLA.

-- 
Regards,

Dimitri.

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[David Henningsson]

On 2015-01-05 05:51, Marc Deslauriers wrote:

On 2015-01-04 08:27 PM, Michael Hall wrote:


On 01/04/2015 07:40 PM, Stephen M. Webb wrote:

On 01/04/2015 06:44 PM, Scott Kitterman wrote:

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.

I think I should have the same rights over my 100 lines.  Personally, I find
the argument that because someone else has made a greater contribution, they
get control over my work to be ridiculous (I didn't sign any CLAs either).


You do have the same rights over your 100 lines.   You can always take your 100 
lines and license it to whomever you
want under whatever terms tickle your fancy.  Canonical could take their 200k 
lines and do the same.  That's the right
copyright grants you, the CLA never takes that away and the GPL is irrelevant 
to that.

If your 100 line contribution is included in the project and you do not give 
permission for Canonical to exercise its
rights over its 200k lines, you have denied Canonical their rights and you have 
established (potentially malicious)
control over their work.


No, Canonical still retains all rights over it's 200k lines, all that we
would be prevented from doing is exercising those same rights over the
additional 100 lines of code that we did not write.


Right, but 100 lines quickly turns into 2k lines by 20 different contributors
you now have to track down or replace.


First; not all lines carry the same weight IMO. Somewhat 
overgeneralising now, but when developing new features, you tend to 
write a lot of lines fairly quickly. When the code is stable or 
near-stable, you spend a lot of time integrating, testing and debugging, 
and the result might end up in just a one or two line fix.


My gut feeling is that the newbie contributors, at least initially, fall 
mostly in the second category. Their contributions are pure quality 
improvements, and should be recognised and valued as such.



Second; if you contribute just a one or two line fix, then probably the 
biggest issue with the CLA is the paperwork. And as long as your 
contributions are tiny compared to the total project, sure. One can just 
give the code away.


It's when your contributions are larger, that things become complicated. 
With all code belonging to the company, that imposes a soft limit of how 
far you can rise in ranks of a project. Because you know that the final 
say about the direction of the project is controlled by the company.


Also, what if an external contributor sees a business opportunity that 
Canonical would not be interested in pursuing? That would require 
significant refactoring and maintenance of the product, and a big chunk 
of new code, so maybe Canonical and the external party have contributed 
50% of the code each? Now it is directly unfair that all code belongs to 
Canonical, when Canonical and the external party could be partners on 
equal footing, sharing maintainership, leading to a win-win for both.


--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[David Henningsson]

On 2015-01-04 22:03, Alberto Mardegan wrote:

On 01/04/2015 09:48 PM, Scott Kitterman wrote:

No, of course not.  I'm struggling to make sense of Stephen's original
response and it seemed to make sense from that perspective.  Qt (for
example)
is clearly now a free software project and it has a CLA.  There are
others as
well.


Qt's CLA is as imbalanced as the Canonical one, isn't it? In fact, I
would claim that's even worse, because while in Canonical's case there's
the *risk* that the software might be re-sold under a proprietory
license, with Qt you have the *certainty* that it's been actively sold.


I suspect that most contributors which choose other projects than 
Canonical's due to the CLA, will also avoid Qt for the same reason.


Nevertheless, do we actively exercise the rights given to us currently, 
and do we give examples of this publicly? Otherwise we might be looked 
upon as being fiddly for no understandable reason. In that sense, Qt is 
actually better, because people will get a better understanding of why 
the CLA is needed.


--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Alberto Salvia Novella]

Stephen M. Webb:
> That social contract is .

Stephen M. Webb:

The GPL is not a social contract, it is a legal agreement defining
the terms of use and distribution of a work of software.


I thought it would be well understood written that way, but I can be 
more explicit if needed:


The social contract, the purpose of any copy-left license, is the work 
to always remain libre; so anyone can enjoy it the way they wish. While 
the license is the legal mean for that goal.


When you give the option to re-license the work under a non copy-left 
license, the original purpose is gone. The company has privileges on the 
code over the rest of people, which concludes in a rigid development 
ecosystem where a few really own the software and the rest are the manpower.



Stephen M. Webb:
> Yes, the rhetorical techniques of vagueness ("power over the code")
> and pathos [2] ("unlimited power!!!1!") can be powerful tools, but as
> an engineer I prefer facts.

As lean system engineer, prize in physics, computer engineering student, 
and member of the club of the human resources of my university with 
about 6000 hours of training in leadership, coaching and emotional 
intelligence (and some more delusional stuff that never mattered); this 
is what I have to say:


The fact is companies where workers are the ones who takes decisions are 
by far much successful than those where decisions are made by a few.


And this is because nobody has a brain as big as it will require to 
control everything, and nobody has as expertise as accurate as all the 
people in the front lines put together.


Moreover, it's emotionally exhausting to handle such an amount of 
responsibility put on one person. Managers tend to feel attached, and 
finish paying attention to nobody; while answering pervasively to 
everything.


As specimen, the company that you pursue to imitate:



Stephen M. Webb:
> Because the power over use of copyrighted works is balanced in favour
> of the original author (as it should be), it puts any business that
> makes use of the copyrighted work at the mercy of that author. For
> example, an organization that provides a software program used to
> operate a general-purpose computer might accept a small contribution
> to improve the performance of the program on a particular device. The
> contribution is then included in the software program and distributed
> widely. Subsequently, the author of the contribution revokes or
> changes the license terms, forcing the organization to remove the
> contribution at its expense and disrupting its business, possibly
> even terminating it. This is certainly not the intended consequence
> of copyright or patent law, but certainly a very real possibility,
> and one which has been used in practice on several high-profile
> occasions.

As far as I know, it's not possible to revoke any license grant you have 
given in the past; so the license itself protects against abuse from the 
original author.


And even if this wasn't the case, it won't be necessary the contribution 
agreement to give the power to publish under any license; but only to 
the same one and subsequent.



Stephen M. Webb:
> So, you can not enumerate the abuses engendered by asking for a grant
> of license. That's OK, you simply make my point for me, thank you.

Instead of repeating myself, I'm going to ask you a question:
What do you think my purpose is?





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[phillip]

Hi,

What I don't understand is:

"2.3 Outbound License

Based on the grant of rights in Sections 2.1 and 2.2, if We
include Your Contribution in a Material, We may license the
Contribution under any license, including copyleft,
permissive, commercial, or proprietary licenses."

There is absolutely no reason to license it as proprietary software in the 
future? 

Why not just use something like:

"We may license the
Contribution under any free and opensoure license" ?

Phillip

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Alberto Salvia Novella]

Stephen M. Webb:
> Aren't you violating the GPL by requiring a copyright license for
> contributions to your projects?

As I said, this is not about the license itself; but about who owns the 
software and what kind of organization it encourages.



Stephen M. Webb:
> If you're going to contribute code under the GPL, you can't apply
> addition restrictions on how it's used without violating the GPL.

Exactly: the purpose of this conversation is nobody to be able to 
restrict the code that is published.



Stephen M. Webb:
> In fact under most jurisdictions the default is that a project is
> unable to use your contributions at all under copyright without
> express written consent.

Then having a written consent is a good idea.


Stephen M. Webb:
> The Free Software Foundation requires that express written consent be
> in the form of total transfer of copyright to themselves.

I believe that is giving bad example, using a method that only will have 
trustworthiness in foundations.



Stephen M. Webb:
> The express written consent in the form of Canonical's CLA only
> requires a grant of the same rights as the copyright holder has,
> without any change to their existing rights.

I see the point: you think there's no difference between that who holds 
the copyright to be an developer or a company, because they both could 
make the code non copy-left if they wished.


Well, there's a subtle difference: if someone owns the code he has 
written, it's a limited amount of code. But if someone collects code 
written by other people, it can be a big amount of a system.



Stephen M. Webb:
> I don't want to you be able to license you project under anything
> except the GPL if I contribute to it.

Rather I would say: I know to what I want to contribute, and that's 
different than what you are proposing.



Stephen M. Webb:
> Why should I make a contribution to your project if you're going to
> make money off it and I'm not?  You're getting the fruits of my
> labour for free, I should get a cut of your profits.

I have no complains about this.


Stephen M. Webb:
> Q: I'm not going contribute to you project unless you accept all my
> conditions.
>
> A: I'm not going to accept your contributions to my project unless
> you accept all of my conditions.  The symmetry is delicious. It's OK,
> you can continue to use my work for free.

The relationship, therefore, is based on fear.


Stephen M. Webb:
> They will simply remain in the vast ranks of those who profit from my
> work without compensating me in any way.

You don't see that compensation because the mediator is no longer the 
money, but other people also giving their work for free to you.


That doesn't mean that getting paid as much as you can isn't important, 
but that the abundance this relationship enables has value itself for 
the individual.


Speaking more clearly: a job is fulfilling when it fulfils both your 
pocket and your heart. So losing the pocket just a bit for making extra 
good makes you happier, and the person where people go to do business with.


And getting paid for something doesn't mean getting paid for everything. 
Much of my work is given freely, because it's something I have done for 
my own needs and I'm unwilling to make a business of all. So I give that 
to other people so they can enjoy it too, while I put my earning where 
it's more profitable (both economically and emotionally).



Stephen M. Webb:
> I am entitled to use your work for free and to be able to decide what 
you do to provide it to me, because I benefit from it and I want it.


Not my way of thinking. In fact I would never considered this kind of 
people in my target audiences, do you?



Stephen M. Webb:
> You're evil and you're leeching from the creators and users of Free
> software!

I don't think so. What I think is this particular decision is a mistake.


Stephen M. Webb:
> [1]http://www.gnu.org/licenses/gpl-faq.html#DeveloperViolate

GPL FAQ - Developer Violate:
> Strictly speaking, the GPL is a license from the developer for others
> to use, distribute and change the program. The developer itself is
> not bound by it, so no matter what the developer does, this is not a
> “violation” of the GPL.

GPL FAQ - Developer Violate:
> However, if the developer does something that would violate the GPL
> if done by someone else, the developer will surely lose moral
> standing in the community."





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Alberto Mardegan]

On 01/04/2015 09:48 PM, Scott Kitterman wrote:

No, of course not.  I'm struggling to make sense of Stephen's original
response and it seemed to make sense from that perspective.  Qt (for example)
is clearly now a free software project and it has a CLA.  There are others as
well.


Qt's CLA is as imbalanced as the Canonical one, isn't it? In fact, I 
would claim that's even worse, because while in Canonical's case there's 
the *risk* that the software might be re-sold under a proprietory 
license, with Qt you have the *certainty* that it's been actively sold.


Ciao,
  Alberto


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Marc Deslauriers]

On 2015-01-04 08:27 PM, Michael Hall wrote:
> 
> On 01/04/2015 07:40 PM, Stephen M. Webb wrote:
>> On 01/04/2015 06:44 PM, Scott Kitterman wrote:
 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.
>>> I think I should have the same rights over my 100 lines.  Personally, I 
>>> find 
>>> the argument that because someone else has made a greater contribution, 
>>> they 
>>> get control over my work to be ridiculous (I didn't sign any CLAs either).
>>
>> You do have the same rights over your 100 lines.   You can always take your 
>> 100 lines and license it to whomever you
>> want under whatever terms tickle your fancy.  Canonical could take their 
>> 200k lines and do the same.  That's the right
>> copyright grants you, the CLA never takes that away and the GPL is 
>> irrelevant to that.
>>
>> If your 100 line contribution is included in the project and you do not give 
>> permission for Canonical to exercise its
>> rights over its 200k lines, you have denied Canonical their rights and you 
>> have established (potentially malicious)
>> control over their work.  
> 
> No, Canonical still retains all rights over it's 200k lines, all that we
> would be prevented from doing is exercising those same rights over the
> additional 100 lines of code that we did not write.

Right, but 100 lines quickly turns into 2k lines by 20 different contributors
you now have to track down or replace.

> 
>> Canonical would either need to expend resource removing the controlling code 
>> or replacing it
>> with some clean-room reimplementation in order to exercise their rights once 
>> more.  An up-front CLA is just easier;  you
>> either agree to it or you do not get your contribution accepted.  Everybody 
>> knows where they stand from the start,
>> everyone is treated equally and without prejudice, and no one loses any 
>> defined rights.
>>
> 
> Projects without a CLA don't often have difficulty knowing where each
> contributor stands. Given the massive number of open source projects in
> existence, I could name on one hand the number that have had an issue
> like this.

Projects don't often re-license. When they do, it's because they did have a CLA,
_have_ managed to track down every single contributor, or they simply rely on
the copyright statement on the top of the source file, which is legally pretty
dubious.

As I've said earlier in this thread, if you're a billion dollar company, you can
assume the risk yourself. If you're not, you'd be crazy to bet the farm on code
contributions you don't have a copyright assignment/CLA for.

Marc.



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Marc Deslauriers]

On 2015-01-04 06:44 PM, Scott Kitterman wrote:
> On Sunday, January 04, 2015 17:39:07 Marc Deslauriers wrote:
>> 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.
> 
> It only prevents relicensing of the contributed code to the extent the 
> licenses are incompatible.  It has no impact on existing code.  Admittedly, 
> in 
> the case of something like the Linux kernel there are so many contributors 
> that's a difference without distinction.  In the case of Appmenu-Qt where the 
> contributed code was removed and re-written that clearly could have also been 
> done later if there as some need to relicense.

Re-licensing code to a compatible license is pretty much an exception. What
license can you re-license GPLv2 code to?

I think we've pretty much learned with experience that having to replace code to
re-license it is something that should be avoided at all costs. Unless you
assume that any contribution to your project will always be trivial and
replaceable, I think it's been pretty much a given that a CLA is necessary.


> 
 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.
> 
> I understand that distributing BSD/MIT licensed code without source is less 
> free than including source distribution, it's not however a proprietary 
> license.

Huh? Once you distribute it without the source, it's pretty much proprietary.

  I think that's a reasonable distinction that the "this only makes
> sense if you only contribute to GPL projects" argument misses.  I, for one, 
> enjoyed seeing RMS in the copyright/license holders for Windows (I think it 
> was 95).

So you agree with me that if you don't want your code to be distributed as
proprietary software, you shouldn't be contributing to BSD or GPL-with-CLA 
software?

> 
>> That being said, I'

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

[Michael Hall]

On 01/04/2015 07:40 PM, Stephen M. Webb wrote:
> On 01/04/2015 06:44 PM, Scott Kitterman wrote:
>>> 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.
>> I think I should have the same rights over my 100 lines.  Personally, I find 
>> the argument that because someone else has made a greater contribution, they 
>> get control over my work to be ridiculous (I didn't sign any CLAs either).
> 
> You do have the same rights over your 100 lines.   You can always take your 
> 100 lines and license it to whomever you
> want under whatever terms tickle your fancy.  Canonical could take their 200k 
> lines and do the same.  That's the right
> copyright grants you, the CLA never takes that away and the GPL is irrelevant 
> to that.
> 
> If your 100 line contribution is included in the project and you do not give 
> permission for Canonical to exercise its
> rights over its 200k lines, you have denied Canonical their rights and you 
> have established (potentially malicious)
> control over their work.  

No, Canonical still retains all rights over it's 200k lines, all that we
would be prevented from doing is exercising those same rights over the
additional 100 lines of code that we did not write.

> Canonical would either need to expend resource removing the controlling code 
> or replacing it
> with some clean-room reimplementation in order to exercise their rights once 
> more.  An up-front CLA is just easier;  you
> either agree to it or you do not get your contribution accepted.  Everybody 
> knows where they stand from the start,
> everyone is treated equally and without prejudice, and no one loses any 
> defined rights.
> 

Projects without a CLA don't often have difficulty knowing where each
contributor stands. Given the massive number of open source projects in
existence, I could name on one hand the number that have had an issue
like this.


Michael Hall
mhall...@ubuntu.com

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Stephen M. Webb]

On 01/04/2015 06:44 PM, Scott Kitterman wrote:
>> 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.
> I think I should have the same rights over my 100 lines.  Personally, I find 
> the argument that because someone else has made a greater contribution, they 
> get control over my work to be ridiculous (I didn't sign any CLAs either).

You do have the same rights over your 100 lines.   You can always take your 100 
lines and license it to whomever you
want under whatever terms tickle your fancy.  Canonical could take their 200k 
lines and do the same.  That's the right
copyright grants you, the CLA never takes that away and the GPL is irrelevant 
to that.

If your 100 line contribution is included in the project and you do not give 
permission for Canonical to exercise its
rights over its 200k lines, you have denied Canonical their rights and you have 
established (potentially malicious)
control over their work.  Canonical would either need to expend resource 
removing the controlling code or replacing it
with some clean-room reimplementation in order to exercise their rights once 
more.  An up-front CLA is just easier;  you
either agree to it or you do not get your contribution accepted.  Everybody 
knows where they stand from the start,
everyone is treated equally and without prejudice, and no one loses any defined 
rights.

-- 
Stephen M. Webb  

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Scott Kitterman]

On Sunday, January 04, 2015 17:39:07 Marc Deslauriers wrote:
> 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.

It only prevents relicensing of the contributed code to the extent the 
licenses are incompatible.  It has no impact on existing code.  Admittedly, in 
the case of something like the Linux kernel there are so many contributors 
that's a difference without distinction.  In the case of Appmenu-Qt where the 
contributed code was removed and re-written that clearly could have also been 
done later if there as some need to relicense.

> >> 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.

I understand that distributing BSD/MIT licensed code without source is less 
free than including source distribution, it's not however a proprietary 
license.  I think that's a reasonable distinction that the "this only makes 
sense if you only contribute to GPL projects" argument misses.  I, for one, 
enjoyed seeing RMS in the copyright/license holders for Windows (I think it 
was 95).

> 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.

Since most (all other than the "the paperwork is annoying") arguments I've 
heard against the CLA relate to the option to use a proprietary license, it 
doesn't make sense to me for Canonical to keep it if they don't plan to use 
it.  It causes friction in the community for no apparent purpose (Note: I 
believe people when they say Canonical doesn't plan to use a proprietary 
license, I just don't get why keeping the right to do so is so important).

> >>> It doesn't matter for you, si

Re: [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 CL

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

[Scott Kitterman]

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.  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.

> 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.

> > 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.  

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.

> 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.

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.

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 get that it doesn't matter to you, but that doesn't make it invalid.  I
> > know a lot of reasonable people at Canonical that believe that the
> > broader community shouldn't be so concerned about the CLA as it is today
> > (which is - for the record - a vast improvement on the first iteration),
> > but many people are.
> > 
> > I guess if I look at your reply as meaning Canonical funded projects
> > aren't
> > really free software projects, just c

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

[Marc Deslauriers]

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.

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.

> 
> 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.

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.

> 
> I get that it doesn't matter to you, but that doesn't make it invalid.  I 
> know 
> a lot of reasonable people at Canonical that believe that the broader 
> community shouldn't be so concerned about the CLA as it is today (which is - 
> for the record - a vast improvement on the first iteration), but many people 
> are.
> 
> I guess if I look at your reply as meaning Canonical funded projects aren't 
> really free software projects, just corporate software development that 
> happens to be done largely in the open and that currently has free licensing, 
> I can see the point, but I hope that's not the way I should be looking at 
> what 
> Canonical is doing.

Canonical projects are free software projects. Perhaps you have some special
definition of free that excludes CLAs.

Marc.


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Scott Kitterman]

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.  

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 get that it doesn't matter to you, but that doesn't make it invalid.  I know 
a lot of reasonable people at Canonical that believe that the broader 
community shouldn't be so concerned about the CLA as it is today (which is - 
for the record - a vast improvement on the first iteration), but many people 
are.

I guess if I look at your reply as meaning Canonical funded projects aren't 
really free software projects, just corporate software development that 
happens to be done largely in the open and that currently has free licensing, 
I can see the point, but I hope that's not the way I should be looking at what 
Canonical is doing.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Stephen M. Webb]

On 01/02/2015 07:37 AM, Scott Kitterman wrote:
> 
> Fact is it's causing external groups to stay away from contributing to 
> Canonical  projects (which contributes to the tautology that the CLA is 
> reasonable because Canonical is the primary/sole contributor).  If you want a 
> specific example, the CLA is the only reason SDDM is the KDM replacement in 
> Plasma 5 and not LightDM.

Yes.  Canonical is aware of this cost of doing business.  Some people don't 
mind contributing in kind in return for all
the wonderful stuff they get for free from Canonical.  Others are adamant that 
their entitlement to gratis product must
grant them additional benefits or they will boycott its use.  Lots of different 
opinions.  People do what they feel they
must.

> Canonical is free to set the rules for contributions to its projects however 
> it wants, but I think you misunderstand why there is a CLA.  For Ubuntu (the 
> Linux distribution) there's no CLA and it works fine.

I don't believe I do misunderstand why there is a CLA.

Ubuntu is a downstream user of Free software developed by Canonical: Ubuntu 
uses code released by Canonical projects
under the GPL. Bringing it up as an argument against an upstream project having 
a CLA for contributions is specious.
Irrelevant.

I think it's been well established why Canonical requires a CLA.  A huge 
proportion of projects producing software
available in Ubuntu require a CLA (eg. Tomcat, Spam Assasin, Apache) or worse, 
a total copyright transfer (GNU libc, the
GCC toolchain, ld.so the runtime link-loader used to start all applications).  
Evidently few people object to CLAs in
general; what they seem to object to in the Canonical CLA is the clause 
licensing to Canonical of the original copyright
holder's right to license the work any way they wish, maybe even for a fee.

This thread started as a demand that that clause be removed.  I have yet to see 
a clear and valid convincing argument
backing up that demand.  Here's a summary of arguments I've seen so far.

Argument:  I received software in Ubuntu under the GPL. It is wrong for 
Canonical to require a CLA before they accept
any change to the upstream project from which that code came.

Response:  You received in Ubuntu under the GPL.  The GPL entitles you to 
modify that software and distribute the
modifications to others, and requires the modified software to continue to be 
licensed under the GPL.  There is nothing
in the Canonical CLA that prevents this. The CLA does not apply to downstream 
development, just as the GPL does not
apply to upstream development.  There is no connection between the premise and 
the conclusion, therefor the argument is
invalid.

Argument:  A work of software is free and the code belongs to the world not to 
a group of individuals.  Canonical can
not decide what it can do with the works it creates.

Response:  Under copyright law the expression of software in the form of source 
code belongs to its authors.  In fact,
the GPL relies on this copyright law to be effective.  It would be great to 
live in an idealized society with communal
ownership of all things and from each according to their ability, to each 
strictly according to their needs but until
the revolution comes the premise is invalid and does not lead to the 
conclusion.  The argument is invalid.

Argument:  Trying to leverage an investment in software development to generate 
revenue is abusive.

Response:  Still not clear on the reasoning behind this.  Not clear on what the 
abuse is.  Not clear on who the victim is.

Argument:  Requiring a CLA means people who object to a CLA will not contribute.

Response:  Unfortunately it's true.  That is a cost of having a CLA.  On the 
other hand, providing all this splendid
stuff for free has a definite cost.  Without that clause in its CLA Canonical 
will likely go the way of every other
organization that has tried to create quality consumer products for free.  
We're trying something different, maybe it
will work this time.  The argument is valid and clear, but not convincing.

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.

Argument:  Canonical should not require the CLA for what it's doing because 
other people succeed with what they're doing
without a CLA.

Response:  Other people are not doing the same thing as Canonical.  The premise 
is not valid.

Argument:  I want to use Canonical software and I don't approve of the 
Canonical CLA, so Canonical must change.

Response:  That's nice, but it's a statement of personal preference

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

[Marc Deslauriers]

On 2015-01-02 01:37 PM, Philipp Kern wrote:
> On 2015-01-02 13:37, Scott Kitterman wrote:
>> Fact is it's causing external groups to stay away from contributing to
>> Canonical  projects (which contributes to the tautology that the CLA is
>> reasonable because Canonical is the primary/sole contributor).  If you want a
>> specific example, the CLA is the only reason SDDM is the KDM replacement in
>> Plasma 5 and not LightDM.
> 
> And the reason why an annoying refresh bug on Nvidia hardware is not yet fixed
> in compiz. (It's much much harder to sign a CLA when legal departments are
> involved.)
> 

It's fixed now:

https://launchpad.net/ubuntu/+source/compiz/1:0.9.12.0+15.04.20141210.2-0ubuntu1

Marc.



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Philipp Kern]

On 2015-01-02 13:37, Scott Kitterman wrote:

Fact is it's causing external groups to stay away from contributing to
Canonical  projects (which contributes to the tautology that the CLA is
reasonable because Canonical is the primary/sole contributor).  If you 
want a
specific example, the CLA is the only reason SDDM is the KDM 
replacement in

Plasma 5 and not LightDM.


And the reason why an annoying refresh bug on Nvidia hardware is not yet 
fixed in compiz. (It's much much harder to sign a CLA when legal 
departments are involved.)


Kind regards
Philipp Kern

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Scott Kitterman]

On Monday, December 29, 2014 01:09:57 PM Stephen M. Webb wrote:
> Fact is, when it comes time for me to accept or reject a contribution, I
> must outright reject any from an author who has not proven good will, and
> that proof is the CLA.

Fact is you're required to do so by your employer, so no judgment at all on 
your part is required.  Your thesis would make sense if it required a 
reciprocal grant of rights.  It doesn't.  It demands more from the contributor 
in terms of rights than it granted (I'd find the paperwork annoying, but 
reasonable if that were not the case).

Fact is prior to the CLA, the type of abuses you're worried about didn't 
happen in the project.  In fact, Canonical threw away perfectly good code 
because some people didn't want to retroactively agree to the original 
copyright assignment.

Fact is it's causing external groups to stay away from contributing to 
Canonical  projects (which contributes to the tautology that the CLA is 
reasonable because Canonical is the primary/sole contributor).  If you want a 
specific example, the CLA is the only reason SDDM is the KDM replacement in 
Plasma 5 and not LightDM.

Canonical is free to set the rules for contributions to its projects however 
it wants, but I think you misunderstand why there is a CLA.  For Ubuntu (the 
Linux distribution) there's no CLA and it works fine.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Gunnar Hjalmarsson]

On 2014-12-30 21:15, Alberto Salvia Novella wrote:



This cross-posting to multiple lists is annoying. Can you please stop that?

-- 
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Please, consider reflecting on the Canonical Contributor Agreement

[Neal McBurnett]

[Please don't cross-post to lots of lists, folks!]

Stephen, thank you for helping ground the conversation with quotes etc.  I 
think you've demonstrated that CLAs are quite defensible in terms of the GPL.

But I hear a larger question, framed in the actual subject line - to *consider 
reflecting on* the Canonical CLA.
I.e. what are the benefits to Canonical, to you, to contributors, to the whole 
ecosystem, to humanity ("Ubuntu philosophy") of a CLA?

I've heard two very helpful perspectives on this over the years.

The first, from 2011, was from Mark, on why giving more leverage, via CLAs, to 
projects and companies in general is helpful to the whole ecosystem:

 Mark Shuttleworth on companies and free software [LWN.net]  
https://lwn.net/Articles/442782/

This summer, Simon Phipps nicely framed a different view tuned to the trends of 
frictionless distributed development that he calls "Permissionless governance":

Governance for the GitHub generation | InfoWorld
 
http://www.infoworld.com/article/2608195/open-source-software/governance-for-the-github-generation.html

I highly recommend both reads.  Perhaps the two models may make sense in 
different circumstances, e.g. with CLAs for polished application code, and 
permissionless governance for more infrastructure-related software.

Of course the nice thing about free software and open source software is that 
we each benefit, and we each get to choose how to participate.
And our choices can reflect our own perspectives, enriched by the perspectives 
of others.

Happy new year, all :)

Neal McBurnett http://neal.mcburnett.org/

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Stephen M. Webb]

On 12/29/2014 09:08 PM, Alberto Salvia Novella wrote:
> 
> Instead of repeating myself, I'm going to ask you a question:
> What do you think my purpose is?

I don't feel particularly compelled to do your work for you.  I will, however, 
address the usual concerns an a FAQ-like
format.


Q: You use the GNU Public License (GPL) when you distribute your software, and 
the GPL prevents you from placing
additional restrictions on contributed code.  Aren't you violating the GPL by 
requiring a copyright license for
contributions to your projects?

A:  No, the GPL prevents you from placing additional restrictions on 
distributed code, not on contributed code.
Accepting a contribution always requires additional restrictions, be they 
quality and applicability restrictions or in
the case of an organization like the Free Software Foundation, full and express 
transfer of all authorship rights as far
as legally possible in the local jurisdiction of the contributor.  The CLA 
addresses upstream contribution, the GPL
addresses downstream distribution.

The Free Software Foundation themselves expressly agree that the GPL applies 
only to downstream distributions, not
upstream contributions [1].

  Strictly speaking, the GPL is a license from the developer for others to use,
  distribute and change the program.  The developer itself is not bound by it,
  so no matter what the developer does, this is not a “violation” of the GPL.

Q: If I let you use some of the code I write, I should have a say in how you 
use it., including whether you use it to
make money.

A: Well, yes and no.

If you're going to contribute code under the GPL, you can't apply addition 
restrictions on how it's used without
violating the GPL.  Sections 7 and 10 of the GPLv3 explicitly state that.

Copyright law, which is the framework on which the GPL is enforced, does allow 
you to make such additional restrictions.
 In fact under most jurisdictions the default is that a project is unable to 
use your contributions at all under
copyright without express written consent.  The Free Software Foundation 
requires that express written consent be in the
form of total transfer of copyright to themselves.  The express written consent 
in the form of Canonical's CLA only
requires a grant of the same rights as the copyright holder has, without any 
change to their existing rights.

Q: I don't want to you be able to license you project under anything except the 
GPL if I contribute to it.

A: That's nice.

Q: Why should I make a contribution to your project if you're going to make 
money off it and I'm not?  You're getting
the fruits of my labour for free, I should get a cut of your profits.

A: Sure.  You're already getting a good deal of value from the fruits of my 
labour for free.  I'd like to see you give
something back in return, but I don't require it. It's nice that you'd 
contribute to my further development of the
software you're using, and I appreciate being able to feed and clothe my 
family.  If you think the exchange is unfair
and you're entitled to more value than you're already receiving, you can try to 
use that contribution to generate your
own revenue directly.

Q: I'm not going contribute to you project unless you accept all my conditions.

A: I'm not going to accept your contributions to my project unless you accept 
all of my conditions.  The symmetry is
delicious.  It's OK, you can continue to use my work for free.

Q: Requiring a CLA for contributions is destroying people's willingness to 
contribute.  Aren't you concerned you're
going to kill the goose that lays the golden eggs?

A: Nice allegory.  I always liked folk tales.

Some individuals refuse to compensate in kind for the free stuff they're using 
because of the CLA.  They have their
varied and various reasons.  Nobody is going to force them to contribute.  It 
makes me sad when some individuals with
something potentially good to contribute refuse to do so for whatever reason, 
but I defend their right to do so.  They
will simply remain in the vast ranks of those who profit from my work without 
compensating me in any way.

Also, removing the CLA would kill the allegorical goose even faster.

Q: The CLA is discouraging people from using your software.  Can't you just get 
rid of the CLA?

A: The vast, vast majority of people using my software have no idea what a CLA 
is.  Getting rid of the CLA would not
change that.  Getting rid of the CLA would not force me to accept more upstream 
contributions either.

Q: I am entitled to use your work for free and to be able to decide what you do 
to provide it to me, because I benefit
from it and I want it.

A: That's not a question.

Q: You're evil and you're leeching from the creators and users of Free software!

A: Well, I am a creator and user of Free software.  You use my work for free 
and you seem to derive value from it
without giving anything back.  What was your question again?


[1] http://www.gnu.org/licenses/gpl-faq.html#Develop

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

[Stephen M. Webb]

I have removed most of the CC: on this discussion because I don't believe such 
spam is appropriate (and it fills my
mailbox with list rejections).

On 12/29/2014 09:54 AM, Alberto Salvia Novella wrote:
> Stephen M. Webb:
>> I think you will find that there is no conflict between any vaguely
>> defined "social contract" and the requirements for acceptable code
>> submission to a software project.
> 
> That social contract is .

The GPL is not a social contract, it is a legal agreement defining the terms of 
use and distribution of a work of
software.  It deals exclusively with downstream distribution of software and 
expressly does not mention how upstream
projects are to be run.

If you wish to reference a social contract from the Free Software Foundation, 
you would be better off using the GNU
Manifesto [1] which explicitly enumerates a set of rights and entitlements the 
Free Software Foundation believes are a
part of the social contract between individuals.  Please read it closely:  I 
believe you will not find among those
enumerated rights any kind of entitlement that your changes must be accepted 
upstream.  If you can find such a right
enumerated, please let me know; I have some tasteless "easter eggs" I want to 
add to some widely-used programs
distributed by the FSF.

As I said previously, all upstream project have a set of conditions, express or 
implied, they require any contribution
to fulfil before acceptance.  Your arguments that having any such set of 
restrictions contravenes "the social contract"
or is invalid under the GNU General Public License still remains to be made.

> Stephen M. Webb:
>> If you truly believe that the original works of an author or authors
>> belong not to them individually but to some larger collective, you
>> would probably be more effective talking to legislators to get the
>> copyright and patent laws in your local jurisdiction struck down, and
>> best of luck with that.  Mean time we will continue asking the
>> authors of contributions to agree to share the specific rights in
>> their work if they want it accepted into a Canonical-led project.
>> That's the best way to guarantee fairness for everyone.
> 
> Putting the agreement under the United Kingdom law wasn't my objection, but 
> to take nearly unlimited power over the code.

Yes, the rhetorical techniques of vagueness ("power over the code") and pathos 
[2] ("unlimited power!!!1!") can be
powerful tools, but as an engineer I prefer facts.  Here are some of the facts 
involved when I decide to accept or
reject a contribution in any of the several Canonical-led projects for which I 
am responsible.

In almost all jurisdictions copyright law grants the original author of a work 
a set of rights over the use of that
work, including the right to license or restrict the use of that work, either 
for free or for a fee, to another legal
person (which could be an individual or a business entity).  Other users of the 
copyright work do not have such rights,
even if they have been granted permission by the author to use the work.

Because the power over use of copyrighted works is balanced in favour of the 
original author (as it should be), it puts
any business that makes use of the copyrighted work at the mercy of that 
author.  For example, an organization that
provides a software program used to operate a general-purpose computer might 
accept a small contribution to improve the
performance of the program on a particular device.  The contribution is then 
included in the software program and
distributed widely.  Subsequently, the author of the contribution revokes or 
changes the license terms, forcing the
organization to remove the contribution at its expense and disrupting its 
business, possibly even terminating it.  This
is certainly not the intended consequence of copyright or patent law, but 
certainly a very real possibility, and one
which has been used in practice on several high-profile occasions.

The effective alternatives to preventing this very real threat to a business 
attempting to use Free or open source
software are: (1) accept absolutely no outside contributions ever or (2) 
require a non-revokable symmetric grant of
copyright powers from the original author of outside contributions (such as the 
CLA).  A third alternative is that the
business investigate the individual contributor with background checks and 
judge them individually as worthy
contributors, but nobody wants that and ain't nobody got time for that.

Remember, at no time does the CLA remove or restrict any enumerated rights of 
the original author nor does it accrue
more rights to the licensee than the original author already has. The CLA 
simply grants similar rights as the original
author to the licensee.  It does restrict the malicious use of the original 
author's enumerated rights with respect to
the licensee, and that's the point.  I can see how some selfish people would 
object to that re

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

[Alberto Salvia Novella]

Stephen M. Webb:
> I think you will find that there is no conflict between any vaguely
> defined "social contract" and the requirements for acceptable code
> submission to a software project.

That social contract is .


David Alan Gilbert:

I don't think any reading of Alberto's mail is objecting to code review.


Exactly.


Stephen M. Webb:
> If you truly believe that the original works of an author or authors
> belong not to them individually but to some larger collective, you
> would probably be more effective talking to legislators to get the
> copyright and patent laws in your local jurisdiction struck down, and
> best of luck with that.  Mean time we will continue asking the
> authors of contributions to agree to share the specific rights in
> their work if they want it accepted into a Canonical-led project.
> That's the best way to guarantee fairness for everyone.

Putting the agreement under the United Kingdom law wasn't my objection, 
but to take nearly unlimited power over the code.



Stephen M. Webb:
> If you could enumerate the abuses engendered by asking for a grant of
> license I'd be happy to address them individually.

As I said, this is like telling a autocracy is good because their 
drivers have never done something bad.


It's something that elicits distrust itself, and usually finishes with 
people working less and less for the project; even when they are paid 
for it.






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Dr. David Alan Gilbert]

* Stephen M. Webb (stephen.w...@canonical.com) wrote:
> On 12/28/2014 09:50 PM, Alberto Salvia Novella wrote:
> > 
> > But there's a problem with that, which is it overrides the social contract 
> > with people to code to belong to the world
> > not to a group of individuals; making the system abusive by design.
> > 
> > It's like telling that an autocracy is better because its drivers have 
> > extra flexibility to do whatever will be needed
> > in future, which is also a proven method for sinking projects and 
> > communities.
> > 
> > So please address the root causes that let to this issue, so we have a 
> > healthy environment for everyone.
> 
> I think you will find that there is no conflict between any vaguely defined 
> "social contract" and the requirements for
> acceptable code submission to a software project.  If you could enumerate the 
> abuses engendered by asking for a grant of
> license I'd be happy to address them individually.
> 
> In order to accept code contribution to a Canonical-led software project a 
> small number of conditions need to be
> satisfied.  Among these conditiona are a strict minimum level of demonstrable 
> code quality (we do no want buggy code),
> applicability (we do not want irrelevant code), and the same rights as the 
> author (an explicit rights grant, also known
> as the CLA).

That's very misleading.  I don't think any reading of Alberto's mail is 
objecting to code review.

> You will find upon a close reading of the various source code distribution 
> licenses that they do not harbour any
> requirements that arbitrary code contributions must be accepted upstream.  In 
> fact, you will not find any examples of
> Free or open source software projects anywhere that unconditionally accept 
> arbitrary code contributions.  It's just not
> a thing.

CLAs are indeed common practice; however ones that allow relicensing of
contributions under arbitrary commercial licenses are much rarer and those
are objectionable, and I think you realise that's what Alberto was objecting to.

> If you truly believe that the original works of an author or authors belong 
> not to them individually but to some larger
> collective, you would probably be more effective talking to legislators to 
> get the copyright and patent laws in your
> local jurisdiction struck down, and best of luck with that.  Mean time we 
> will continue asking the authors of
> contributions to agree to share the specific rights in their work if they 
> want it accepted into a Canonical-led project.
>  That's the best way to guarantee fairness for everyone.

Of course we're all free to fork the canonical code to a project that
doesn't have the same CLA, so it's not a vast issue; but as is I can
not contribute to a subproject that requires contributions under the
current CLA.

Dave

> 
> -- 
> Stephen M. Webb  
> 
> ___
> Mailing list: https://launchpad.net/~ubuntu-bugcontrol
> Post to : ubuntu-bugcont...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol
> More help   : https://help.launchpad.net/ListHelp
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\ gro.gilbert @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Please, consider reflecting on the Canonical Contributor Agreement

[Alberto Salvia Novella]

Hi, this is Alberto; who is currently coordinating Ubuntu papercuts quality.

I wanted to bring up a topic which I have been thinking about five 
months from now, and after speaking with the appropriate people and 
deliberating about it; I conclude it really needs to change.



Canonical Contributor Agreement (http://tinyurl.com/q2lwggl):
> We may license the Contribution under any license, including
> copyleft, permissive, commercial, or proprietary licenses.

Probably this has been done for keeping code copy-left while being able 
to charge telephony manufacturers for using libre software, instead of 
just giving it freely to leechers under a non copy-left license.


But there's a problem with that, which is it overrides the social 
contract with people to code to belong to the world not to a group of 
individuals; making the system abusive by design.


It's like telling that an autocracy is better because its drivers have 
extra flexibility to do whatever will be needed in future, which is also 
a proven method for sinking projects and communities.


So please address the root causes that let to this issue, so we have a 
healthy environment for everyone.


Thanks for your understanding.






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

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

[Stephen M. Webb]

On 12/28/2014 09:50 PM, Alberto Salvia Novella wrote:
> 
> But there's a problem with that, which is it overrides the social contract 
> with people to code to belong to the world
> not to a group of individuals; making the system abusive by design.
> 
> It's like telling that an autocracy is better because its drivers have extra 
> flexibility to do whatever will be needed
> in future, which is also a proven method for sinking projects and communities.
> 
> So please address the root causes that let to this issue, so we have a 
> healthy environment for everyone.

I think you will find that there is no conflict between any vaguely defined 
"social contract" and the requirements for
acceptable code submission to a software project.  If you could enumerate the 
abuses engendered by asking for a grant of
license I'd be happy to address them individually.

In order to accept code contribution to a Canonical-led software project a 
small number of conditions need to be
satisfied.  Among these conditiona are a strict minimum level of demonstrable 
code quality (we do no want buggy code),
applicability (we do not want irrelevant code), and the same rights as the 
author (an explicit rights grant, also known
as the CLA).

You will find upon a close reading of the various source code distribution 
licenses that they do not harbour any
requirements that arbitrary code contributions must be accepted upstream.  In 
fact, you will not find any examples of
Free or open source software projects anywhere that unconditionally accept 
arbitrary code contributions.  It's just not
a thing.

If you truly believe that the original works of an author or authors belong not 
to them individually but to some larger
collective, you would probably be more effective talking to legislators to get 
the copyright and patent laws in your
local jurisdiction struck down, and best of luck with that.  Mean time we will 
continue asking the authors of
contributions to agree to share the specific rights in their work if they want 
it accepted into a Canonical-led project.
 That's the best way to guarantee fairness for everyone.

-- 
Stephen M. Webb  

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel