Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of andy@the-martin-byrd.net
 designates 204.16.46.2 as permitted sender)
Message-ID: <4E0A7082.1090406@the-martin-byrd.net>
Date: Tue, 28 Jun 2011 17:23:30 -0700
From: Andy Brown <andy@the-martin-byrd.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: Scope of Apache license: what needs to be covered?
References: <BANLkTimtwv7wa=w1mzQnkWpe-3vGdreYVg@mail.gmail.com>
	<BANLkTimMPOojov6+0LDeAsuqFDF-Pfef4w@mail.gmail.com>
	<1309302355.2098.67.camel@jean-laptop15>
	<BANLkTi=9qE3cTtnGhiArhVKO18sgottejA@mail.gmail.com>
 <BANLkTinHA49AEy9jmkWfhue9oCDnmZjhbg@mail.gmail.com>
In-Reply-To: <BANLkTinHA49AEy9jmkWfhue9oCDnmZjhbg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Rob Weir wrote:
> On Tue, Jun 28, 2011 at 7:17 PM, Alexandro Colorado <jza@openoffice.org> wrote:
>>
>> Sorry for jumping in but it seems there is an missunderstading between Rob
>> and the ODFAuthor project. I think the ODFAuthor was in the position of many
>> quasi-independent groups like the OOo NGOs and others.
>>
> 
> It is possible that I an confused, but I think I am mainly concerned
> about fragmenting the project into many "quasi-independent" groups.
> I'm not absolutist in this, but I can see clear risks.
> 
> Let me give you an extreme example.  Suppose we decided to stop
> writing word processor text alignment code,  Instead we relied on
> group A, which owned and developed left alignment code, group B which
> did all the center alignment work and group C did the right alignment
> code.
> 
> (OK, the example is ridiculous technically, but bear with me please)
> 
> Because, in this fanciful example, the Apache project had other groups
> own essential portions of the project, this means that anyone who
> tries to put together an actual product based on Apache OOo would need
> to access the three alignment libraries produced by groups A, B and C.
>  This is true whether one was making an open source release, or a
> proprietary release.  Whoever tries to release a version of OOo
> binaries, if they wished to have a viable product (from a user
> perspective) would need to negotiate with groups A, B and C, in terms
> of functionality, schedule, support, localization support, etc., as
> well as license.
> 
> Compare that to a situation where the core alignment code is all in
> the Apache OpenOffice project, under the Apache 2.0 license.  That
> gives downstream users of our releases, open source and commercial,
> the maximum flexibility to repackage the release.  They can add code,
> subtract code, do whatever they want.  But we don't send them to track
> down dozens of 3rd party dependencies owned by other organizations.
> 
> Another example, with translations.  Suppose the translation files for
> OOo were owned by a bunch of different groups and were not part of the
> Apache project, under the Apache license.  Then, if someone wanted to
> take the AOOo sources and make a special version, say a Portable Apps
> version, or a special educational version, or whatever, then they
> would need to negotiate access with external groups for their
> translation files.
> 
> I think we need to be careful about this kind of fragmentation since
> they prevent downstream consumers of our releases from making
> effective use of our releases.  It hurts the downstream ecosystem.
> 
> I think we should have a clear idea of what the essential, core
> OpenOffice product is, and ensure that those parts of it are developed
> in the AOOo project, under the Apache 2.0 license, and under PMC
> oversight.
> 
> Of course, there may be parts that are not essential, core release
> components, and those could be done anywhere.  In fact, we should
> encourage extensions, additional documentation, plugins, etc., as part
> of the overall eco system.  That is a good thing.  But we need to have
> a clear idea of what the core is as well, and ensure that the core is
> developed in one place.
> 

So we start up a subproject to deal with user documentation and start
from scratch.  Trying to build up a group of people that have no
interest in learning a new, less efficient, process.  Or have infra
build a system that works for the contributors.

Andy