Monday, 5 January 2015

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

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
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel