[appstream] RFC: Software Center & Copyright Assigment
vuntz at gnome.org
Thu May 5 16:40:03 PDT 2011
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:
For reference, you can read the current agreement at:
and get more information about it at:
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
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
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.
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?
Les gens heureux ne sont pas pressés.
More information about the Distributions