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 usually hear are
> in these four categories:
>
> 1- "I don't want Canonical to re-license my contributions as proprietary software".
>
> This is a valid point. If Canonical didn't have a CLA, but only produced
> software under BSD or MIT licenses, you'd have the same objection. So this
> clearly isn't a CLA objection, it's a license preference objection. If you only
> want to contribute to GPL licensed software because you never want your code to
> be used in proprietary software, than you shouldn't sign a CLA, whether it be
> Canonical's CLA or Qt's CLA.
>
> 2- "I want to have the same rights as Canonical and re-license Canonical's
> software as proprietary software."
>
> Sorry, but you can't. Canonical's software is GPL. Only Canonical has that
> right, because they are the copyright holders. If you believe your contribution
> should grant you the same rights as Canonical has, I'm sorry, but that's not how
> that works. If you want to be able to re-license code as proprietary, you
> shouldn't contribute to GPL licensed projects.
>
> 3- "I don't want to sign the CLA paperwork"
>
> This is a very valid objection, but unfortunately, it's a fact of life. If
> Canonical wants to be legally protected that the contribution you want to submit
> is your own work and not the product of work for hire, or has been plagiarized,
> then you need to get lawyers involved.
>
> If the company you work for doesn't want to sign the CLA, chances are they
> didn't want you to submit that contribution in the first place, in which case
> Canonical could have possibly been in a bad position legally. If you're a
> billion dollar company, you can probably assume the risk and rewrite any code
> that came from bad or legally encumbered contributions. If you're Canonical,
> accepting code without a legal agreement is a risk that can't be ignored.
I think that's an incomplete statement. I have definitely dealt with
companies that won't sign or approve employees signing any CLA's, but
have at least approved contributing code under a very limited set of
licenses because there was a large amount of pressure to do so. So in
some cases it's not "if they don't want you to sign the CLA, they don't
want you contributing" but rather "if you can find another option that
doesn't have a CLA, you can save virtually eons of time and miles of red
tape."
So, for the sake of completeness, I think you also missed a variant of (3):
3.1- "There is another project that is good enough for my needs but
doesn't put any obstacles in my way when I want to get my patches merged
upstream."
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
