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, 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.
> 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).
> 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.
> 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.
> > 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).
> >> 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.
> 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.
> 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.
> > 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.
Scott K
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
