[appstream] RFC: Software Center & Copyright Assigment

[Ben Finney]

Vincent Untz <vuntz at gnome.org> writes:

> Overall, I think there are three main approaches to the issue, and I'd
> like to hear what people think is best.

Thanks for soliciting community input.

>  a) Live with it.
>     The Software Center is not a dead project, and development is
>     ongoing (see https://launchpad.net/software-center).

It is nevertheless community-hostile for Canonical to insist on a
one-sided agreement: as a condition for contributing, Canonical insist
on special exclusive rights to distribute the work under proprietary
terms. Projects for which Canonical insist on such extra rights are not
community projects.

    <URL:http://blogs.computerworlduk.com/simon-says/2010/08/on-contributor-agreements/>
    <URL:http://www.fsf.org/blogs/rms/assigning-copyright>

I think that's not a situation with which we should live, but one which
should be actively resisted and loudly protested.

So I think a fork of some kind is necessary.

>  b) Maintain a "light" fork.
>  c) Completely fork.

I think the difference between these two is partly determined by how
intractable the upstream's community-hostile position is.

Though the Go-OO project was a hopeful effort conducted well, it turned
out to be somewhat wasted effort since OpenOffice.org just moldered
upstream. It is now eclipsed by the complete fork that is LibreOffice,
which I think is so rapidly successful only because it makes a complete
break with the clearly community-hostile Oracle.

Of course, for such a full fork to work, the surviving fork must have a
strong core development team; preferably the majority of active
developers from the original project. So treading carefully is also
necessary, in order to convince the developers to join willingly.

In the case of Canonical, their insistence on special proprietary rights
in the work is a matter of long-defended public policy, so we should not
hold out much hope that they will agree to a level playing field.

A complete fork will be painful, but will make the contribution terms
clearly level for everyone, and I expect it to be less painful than
trying to work long-term across the divide imposed by Canonical's terms.

> Of course, there can be a mix of those. For instance:
>  - light fork at first, and if Harmony takes off and everybody is
>  happy with it, merge everything back.

This might be a reasonable option *if* Canonical showed signs of
actually wanting a level playing field for contributions. As it is,
though, I think it's clear current Canonical policy rules out their
agreeing to terms which don't leave them in a privileged position on
“their” projects.

For example, Mark Shuttleworth is well aware of the advice from RMS to
drop the community-hostile requirements, but chooses to misinterpret
<URL:http://www.markshuttleworth.com/archives/671#comment-352309> as
though RMS's advice endorsed Canonical's behaviour.

(Note, please, that I'm not resting my position on RMS as some kind of
authority; it's his arguments in this issue that I support.)

>  - light fork at first, and slowly move to full fork.

If that's less painful than a full fork, I'm not against it; so long as
it's clear the goal of achieving a full fork as soon as feasible.

> Btw, it's not my intention to discuss whether Canonical is right or
> wrong to require a copyright assigment for this project, or whether
> Harmony will provide a good framework for that or not, so please do not
> focus too much on this in the thread :-)

Well, my position on which route to take is driven in large part by that
argument, so I hope it's acceptable to discuss it to that extent.

> Let's try to stay on-topic, and the topic is: which path do we choose?

Thanks again for kick-starting this discussion.

-- 
 \       “One of the most important things you learn from the internet |
  `\   is that there is no ‘them’ out there. It's just an awful lot of |
_o__)                                            ‘us’.” —Douglas Adams |
Ben Finney