This is exactly what I had in mind also.
>
> AN ALTERNATIVE APPROACH
>
> Another way to interact and support Apache OpenOffice in terms of
> collaborative contributions is as follows.
>
> 1. Establish a downstream producer, TeamX (for example), that provides
> releases of derivative software based on Apache OpenOffice.
>
> 2. Assumption #1: The Apache License Version 2 (ALv2) is honored in the
> use of Apache OpenOffice source code. Apache trademark requirements are
> satisfied in any use as part of the branding of the downstream product.
>
> 3. Assumption #2: New code and modifications to the TeamX derivative are
> also under ALv2.
>
> 4. Open-Source Good Citizenship: The ALv2-licensed fixes and repairs are
> contributed back upstream to Apache OpenOffice. Components from other
> sources would, of course, be contributed upstream to those sources.
> Contributions and joint concerns might lead to use of the OpenOffice
> bugzilla as a coordination point.
>
> 5. Opportunity. The business model, organization, and governance of
> TeamX is not of concern to the ASF.
>
> 6. Opportunity. The Apache Software Foundation requirements beyond
> honoring of the ALv2 that govern Apache projects serving the public
> interest do not apply, although TeamX could operate in a harmonious manner.
>
> 7. Opportunity. So long as there is clear separation and no comingling in
> source-code files, TeamX is not constrained from also using code or
> components from other projects, such as those using licenses such as the
> MPL or, under appropriate conditions, something like LGPL2, with
> appropriate honoring of those licenses too. However, to avoid tainting of
> upstream source-code contributions back to Apache OpenOffice, there must be
> careful management of IP and reliance on code (source or binary) under
> non-ALv2 license (and ALv2 code which is not the original work of TeamX).
>
> 8. Opportunity. Depending on how close the operation of TeamX releases
> remains to that of Apache OpenOffice, especially at the beginning, one can
> rely on the Apache OpenOffice mediawiki and openoffice.org site in large
> measure, so long as there is no confusion. Also, the Apache OpenOffice
> Community Forums are more ecumenical in how they can provide forum support
> to OpenOffice.org-lineage ODF-supporting products. How confusion is avoided
> would need to be worked out, but this provides TeamX time to develop its
> own support as that ends up having unique requirements.
>
> This is not unlike how downstream organizations rely on Apache OpenOffice
> for specialized distributions (e.g., FreeBSD, OS/2, and Solaris). There
> are other Apache projects where the downstream ecosystem is quite robust
> and the key Apache project deliverable is the source-code release and not
> so much any end-user binary distributions.
>
> - Dennis
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
