[appstream] RFC: Software Center & Copyright Assigment

Vincent Untz vuntz at gnome.org
Thu May 5 16:40:03 PDT 2011


Hi all,

During our original meeting for AppStream, one thing we discussed was
that the Software Center currently requires a copyright assignment (to
Canonical), and that it could potentially be an issue. We decided to not
block on that during the meeting, knowing that some people would discuss
the topic with Canonical.

I've been involved in several discussions with Canonical about this, and
the result appears to be that this won't change in the near future. What
might happen, but keep in mind that it's just my understanding, is a
transition to Harmony once it's ready:
  http://www.harmonyagreements.org/

For reference, you can read the current agreement at:
  http://www.canonical.com/system/files/Canonical%20Contributor%20Agreement%2C%20ver%202.5.pdf
and get more information about it at:
  http://www.canonical.com/contributors

That means we're still faced with a situation we were not really happy
with during the meeting: right now, this copyright assignment policy can
slow down development of the Software Center, and its integration with
the other bricks we're working on.

And as a matter of fact, I know of various people who either don't want
to work on the Software Center because of the current policy, or can't
work on it because, for instance, their company won't allow them to sign
the copyright assignment. So it's now time to find out how to move
forward on this topic.

Overall, I think there are three main approaches to the issue, and I'd
like to hear what people think is best. Note that I'm trying to be
neutral below, sorry if I fail at that (I'll send my personal opinion
later on).

 a) Live with it.
    The Software Center is not a dead project, and development is
    ongoing (see https://launchpad.net/software-center). So a solution
    is to simply rely on the current development team, and on potential
    new contributors who are willing to sign the contributor agreement
    to do the integration with other distros, and keep things moving.

    Things might not move as fast as we'd wish, and people who won't
    actively participate in the development might have less influence in
    the overall direction of the project (from a technical perspective)
    -- it's worth pointing out that Michael is really open, so this
    might not necessarily be an issue.

 b) Maintain a "light" fork.
    This would be an approach similar to what go-oo was doing with OOo.
    We would provide the features/integration with other distros that
    people need as a set of patches maintained outside of the main
    development tree. Anybody could work on those, but obviously,
    there'd be some cost in rebasing those patches. There's also the
    risk of accumulating patches that can't be merged in the main
    branch.

 c) Completely fork.
    This means everybody can work on the code, but the obvious cost is
    that we will not directly benefit from the work done by current
    contributors if they decide to not join the fork. And this obviously
    requires people ready to drive the development (as in, write the
    code, not give ideas).

    Of course, it'd be possible to take patches from the original branch
    at first, but with time, the two code bases will diverge and this
    would get harder.

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.
 - light fork at first, and slowly move to full fork.
 - live with it for now, and see how development is being driven in the
   direction that we'd want; fork if we're unhappy after a few months,
   or celebrate if everything goes well.
 - completely fork, and convince everyone to use this fork so we
   actually end up with only one branch.
 - etc.

So, what do people feel about this? Which approach would help you best
move our project forward?

I don't feel we need to discuss this forevern, and if needed, I'll come
with a proposal after the first round of feedback.

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 :-)

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

Thanks,

Vincent

-- 
Les gens heureux ne sont pas pressés.


More information about the Distributions mailing list