The Mer Project has "the Core" as a significant part of what it delivers.

However, I'd like to propose to the AB that Mer has two areas to manage: Core
and Collaboration.

In another universe I think this would be such an obvious decision for an open
source project that it wouldn't even need discussing.

However we have potential legal issues that present risks that should be 

By 'Collaboration' area I mean a set of services provided for the use of the Mer
Community - including both vendors and potentially end-users. Primary amongst
these services will be a Community Open Build System (c.obs) but I can see
services like Apss-for-MeeGo and community QA systems being part of this area
over time. This collaboration area will result in relatively uncontrolled
uploads and downloads of source.

There is a real concern about the risk that some kind of legal action taken
against the community services would impact our ability to continue to host,
develop and deliver the Mer Core.

The reason for raising this issue is to (hopefully) confirm that the scope of
those involved in managing Mer does include the collaboration aspect. (note
-trying to avoid saying "the Mer Project includes" since we may need to name
things differently depending on the advice we get.)

Then, if we do want to include collaboration in the scope of Mer's AB, I can be
clear on our objectives when I investigate solutions to this problem with
entities like KDE's eV and SPI.


"Don't worry, you'll be fine; I saw it work in a cartoon once..."

Reply via email to