[appstream] RFC: Software Center & Copyright Assigment

Thu May 5 23:20:09 PDT 2011

On 06.05.2011, at 01:40, Vincent Untz wrote:

> 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 a lot Vincent for you analysis. The copyright assignment situation is very unfortunate. It´s sad that canonical doesn´t seams to care enough about outside contributions enough.

I want to add a 4th option.

d) We could use the other existing appstream client.
Inside the Bretzn project we developed an client for application installation which is compatible with the appstream architecture. The Bretzn client is using OCS for the application data and packagekit for the package installation. 
Bretzn is build on top of the MeeGo Installer and is using Qt/KDE libraries. The KDE dependency is only a small dependency at the moment. It was developed by KDE, MeeGo and SUSE guys earlier this year and we don´t have a copyright assignment of course.
The client is 90% done and just needs a little bit of polish.
http://www.socialdesktop.org/bretzn/
https://gitorious.org/+opensuse-appstore/meego-garage/opensuse-appstore-garage-client-services

So this our third option IMHO.

Regards
Frank

--
Frank Karlitschek
karlitschek at kde.org