incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Brown <a...@the-martin-byrd.net>
Subject Re: Scope of Apache license: what needs to be covered?
Date Wed, 29 Jun 2011 00:23:30 GMT
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

Mime
View raw message