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 > >