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'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).
>
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.
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.
>>>>> It doesn't matter for you, since your contributions are a work made for
>>>>> hire and Canonical owns it regardless, but for people in the broader
>>>>> community who are doing this for free in the interest of improving free
>>>>> software the distinction matters a lot.
>>>>
>>>> I don't understand this. How does giving Canonical the right to relicense
>>>> your contribution conflict with the goal of improving free software? This
>>>> only matters to people who exclusively contribute to GPL licensed
>>>> projects,
>>>> right? I mean, if you contribute to something BSD or MIT licensed, you're
>>>> basically allowing anyone to make it proprietary. Do BSD and MIT licensed
>>>> projects conflict with your goal of improving free software?
>>>>
>>>> I do agree that if you're a contributor who exclusively contributes to
>>>> GPL
>>>> licensed projects, you may have an issue with Canonical relicensing your
>>>> code. In which case, just don't sign the CLA and fork the project, like
>>>> the
>>>> GPL allows you to do.
>>>
>>> I've heard this argument before and I think it's logically unsound. If
>>> the
>>> projects in question were BSD/MIT licensed, then it would be right on
>>> target, but they aren't.
>>
>> I still don't understand. What is the difference? Objections I usually hear
>> are in these four categories:
>>
>> 1- "I don't want Canonical to re-license my contributions as proprietary
>> software".
>>
>> This is a valid point. If Canonical didn't have a CLA, but only produced
>> software under BSD or MIT licenses, you'd have the same objection. So this
>> clearly isn't a CLA objection, it's a license preference objection. If you
>> only want to contribute to GPL licensed software because you never want
>> your code to be used in proprietary software, than you shouldn't sign a
>> CLA, whether it be Canonical's CLA or Qt's CLA.
>
> As I said above, I think BSD/MIT is different than proprietary even though many
> of the practical effects are similar. There are other similar agreements that
> don't include proprietary rights. Also, I think Qt is a bit different since it
> started as a proprietary project that was opened up. It has gotten more open
> over time.
Sorry, but I fail to understand the difference here.
So it's acceptable for Qt to have a CLA because it used to be proprietary, but
it's not acceptable for other software to have the same model? You do realize
that the reason why Qt is awesome is _because_ they can sell GPL exceptions, right?
>
>> 2- "I want to have the same rights as Canonical and re-license Canonical's
>> software as proprietary software."
>>
>> Sorry, but you can't. Canonical's software is GPL. Only Canonical has that
>> right, because they are the copyright holders. If you believe your
>> contribution should grant you the same rights as Canonical has, I'm sorry,
>> but that's not how that works. If you want to be able to re-license code as
>> proprietary, you shouldn't contribute to GPL licensed projects.
>
> I never heard anyone make this argument. The argument I've heard is that I
> should grant the same rights over my code to Canonical as I get from Canonical
> over theirs (i.e. free software license).
Why? Do you actually think most contributors care about that? Honestly, that
sounds rather far-fetched and desperate.
>
>> 3- "I don't want to sign the CLA paperwork"
>>
>> This is a very valid objection, but unfortunately, it's a fact of life. If
>> Canonical wants to be legally protected that the contribution you want to
>> submit is your own work and not the product of work for hire, or has been
>> plagiarized, then you need to get lawyers involved.
>>
>> If the company you work for doesn't want to sign the CLA, chances are they
>> didn't want you to submit that contribution in the first place, in which
>> case Canonical could have possibly been in a bad position legally. If
>> you're a billion dollar company, you can probably assume the risk and
>> rewrite any code that came from bad or legally encumbered contributions. If
>> you're Canonical, accepting code without a legal agreement is a risk that
>> can't be ignored.
>
> Why is this more applicable to Canonical upstream projects than it is to
> Ubuntu? All those same risks are present with contributions to Ubuntu (the
> distribution), yet no CLA is required.
Because Canonical is not the copyright holder of the majority of projects that
are included in Ubuntu.
>
>> 4- "Canonical is evil because they have a CLA."
>>
>> Yep, it's an easy target for competitors who don't have one. If Canonical
>> got rid of the CLA, they'd simply switch to some other reason to bash
>> Canonical.
>
> I'm not a Canonical competitor and I don't think Canonical is evil. I do
> think it's an unfortunate choice that is one reason among many that drives a
> wedge between Canonical and the rest of the free software community.
Funny how the same people who have no problem with the Qt CLA have an issue with
the Canonical CLA. That should give you a hint about what their actual
motivations are.
>
>>> The issue that I've seen most people complain about (and what I think is
>>> an
>>> issue myself) is the imbalance between outbound rights from contributors
>>> and outbound rights from Canonical.
>>
>> So you think your 100 line patch should give you the same rights as the
>> copyright holder of the 200k line project? Honestly, this argument is
>> completely ridiculous.
>
> 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. It's the 200k lines that you
didn't write that you don't have the same rights over.
>>>> Honestly, I can probably count on my fingers the number of people who had
>>>> an actual desire to contribute to Canonical projects but were prevented
>>>> by the CLA. If this was as big an issue as some Canonical competitors
>>>> have made it out to be, all Canonical's software would already be forked
>>>> in various PPAs and repositories.
>>>
>>> SDDM basically exists because of the CLA (at least it's being used in KDE
>>> because of it). Canonical projects like Appmenu-Qt (I think that's the
>>> right one) had contributors from non-Ubuntu KDE contributors before the
>>> copyright assignment/CLA policies were instituted.
>>>
>>> Maintaining a fork is a lot of work. Generally people aren't going to
>>> fork, they're just going to use something else that it's easier to
>>> contribute to. In the one case I'm familiar with, forking LightDM instead
>>> of using the substantially less mature SDDM was never even considered.
>>
>> Yes, and there is nothing wrong with that approach. Not only do you gain the
>> advantage to having your own code base, but you don't need to jump through
>> the hoops of getting your contributions accepted upstream.
>>
>> There is absolutely nothing wrong with doing your own thing and reinventing
>> the wheel if you think that will be the best plan long-term.
>
> The only advantage SDDM had over LightDM was the lack of the CLA.
> Technically, LightDM would have been a much better solution. Generally, I
> think we're better off working together on common solutions (particularly at
> the infrastructure level, which is where I'd put this) and sharing the load
> even if a bit of compromise is needed than going our own way and duplicating
> effort.
If the belief was that the CLA would prevent people who were legally encumbered
from contributing then I completely understand the position. (That would be the
#3 I listed earlier). If it was because of #1, I do understand also, although as
an Ubuntu developer, I do think a fork would have been trivial. Debian packages
are forks from upstream, and Ubuntu packages are even more so. I have a hard
time understanding why a fork would be so difficult since maintaining forks is
basically what I do for a living.
But those are two very good reasons not to use LightDM. It's quite unfortunate,
but no different than using Qt or MySQL in your project. At some point, a
decision needs to be made as to what the best solution is long-term, and as I
explained earlier, there is absolutely nothing wrong with doing your own thing.
I think the aversion to forks and the aversion to reinventing the wheel (aka
"NIH syndrome") in the open source community is unhealthy and part of the reason
why open source licensing is not as widespread as It should be.
>> It's hard to contribute to a project if your goals aren't perfectly aligned
>> with it. As an upstream, it's hard to have people contribute to your
>> software that don't have the same vision of what it should be. It
>> invariably ends up in two ways: downstream is upset that upstream won't
>> accept patches to add the kitchen sink, or upstream accepts everything and
>> project turns into a gigantic mess that includes the kitchen sink. Once a
>> project starts accepting everything, it becomes bloated, untestable, and
>> unmaintainable, at which point someone starts developing a better
>> alternative.
>
> That's unrelated to the CLA.
Not at all. The CLA is definitely a factor that enters the equation, but
pretending it's the only one is FUD.
>
>> More often than not, you're better off reinventing the wheel.
>
> That does seem to be the general Canonical approach, but I think working
> together will generally produce a better result.
I disagree.
Working together makes sense in certain situations. In other situations there
are other factors involved that make the decision difficult, such as politics,
difficulty to work with upstream, or simply a disagreement on what the project's
goals are.
Without disagreements, we wouldn't have awesome projects like Apache, or
MariaDB, or LibreOffice, or NGINX in the first place. We should embrace people
thinking differently, instead of being critical of people who don't want to
collaborate on a single bloated one-size-fits-all solution.
>
>>> As far as I know, much of what Canonical produces isn't even packaged
>>> outside Ubuntu, so I don't think there's a great deal of demand that
>>> would lead to forks.
>>
>> A lot of stuff Canonical produces is in fact packaged in other distros. bzr,
>> lightdm, cloud-init, upstart, for example. I don't think the CLA has
>> anything to do with what is packaged and what isn't.
>>
>>> I don't know how much of a problem Canonical's competitors claim the CLA
>>> is. I can point to specific instances of it being problematic in the
>>> areas of the project I'm involved in.
>>
>> I'm sure the alternative that was ultimately chosen will work out just fine.
>
> 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?
Marc.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
