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 considered. 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. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..."
