incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: Apache Incubator Proposal: Splitting the Community?
Date Fri, 03 Jun 2011 16:07:38 GMT
On 6/3/2011 10:20 AM, Florian Effenberger wrote:
> I on purpose leave out the discussion about (re-)licensing here, as others can comment
> much better about the impact of the various licenses, and how they play together, and
> ASF could to with the software grant they received, may it be with or without other
> entities. I'd love to focus much more on the community and project side of things, and
> this is the part of my initial message that I still feel is unreplied: Why do we need
> second project? From all those who propose the project at ASF, I have not heard much
> feedback on why this should happen, or otherwise said, on why TDF would be the wrong
> to do it.

I don't believe these two issues above can be separated.  I'd also remind
that the communities have been split, and the time to have initially
reached a compromise was before the fork, so there were obviously some
irreconcilable points as the TDF drew its fundamental lines in the sand.

> So, as I feel my question in the first mail has not been answered yet, I'd like to repeat
> it, and extend it on one further question, to everyone who supports the incubator proposal:
> - What is wrong about the TDF that is better at ASF, for being the home of a free office
> suite?

I don't think anyone questions the value of a "Free" office suite at TDF,
and in fact all here sort of expect one to persist at TDF with enhancements
and community around Free/Libre Software supporters and platforms.

In fact, all of the conversation in this thread suggests that there will
remain a healthy ecosystem of various packing, training, and other services
around this code base, as there has been for half a decade.

> - Why didn't those who propose this project talk to TDF about the issues that mattered
> them and tried to change it?

Because there is an ecosystem of BSD, OS/X and commercial vendors who do not
so much leverage the "Free" aspect of "Open" Source.  For this reason, some
number of Sun/Oracle customers licensed the open code from them.  IBM is one
of these.

The previous (singular) community supported both paid-commercial-closed
works and free-libre-copyleft works with their contributions and their
collaboration.  Certainly even the paid-commercial-closed side of that
world gave back much to the commons to improve the collaborative work,
through direct contribution, or subsidizing Sun/Oracle contributions
through their licensing fees, or both.

Experience with Free/Libre Open Source Communities and Projects shows that
such communities will not be flexible on licensing.  Neither will the ASF
Open Source Community be flexible.  It seems this was a binary decision...

It would appear that Oracle's OOo contribution to the ASF is meant to
extend the freedom for developers to choose to open or close fork the code
without the payment of royalties to Oracle.  This puts every consumer in
the same position as only the elite enjoyed previously, freedom to choose
between an open or closed fork, and freedom to choose between contributing
back or not.

I am now convinced this is entirely a licensing decision, so I'll ask you,
what was the probability for Oracle to convince TDF to maintain an Apache
Licensed project consisting of their copyrighted code base?  I'd politely
suggest they believed there was no realistic chance they could persuade
TDF to be the custodian of a BSD or Apache Licensed work.

As custodian/sub-licensor of the donated code, the ASF (or TDF, if that
were the case) retains the ability to modify the license.  Clearly much
of the interesting commercial activity surrounds online document services.
As the case is today, the LGPL and MPL of the TDF's works offers no
copyleft facilities for services, this would require an AGPL license.  So
given the choice between choosing a copyleft or permissive open source
custodian, I can appreciate Oracle's decision for what it was, and really
don't believe that conversations with TDF could have changed that outcome.

This suggests no criticism of the TDF, it's mission or purpose, or the
fruits of its labors, and if the ASF votes to adopt this new podling, I'm
wishing the best of success to both efforts.  I was initially sympathetic
to the option that Oracle might be trying to un-copyleft their codebase,
against the desires of a broader community.  Personally I would have
voted -1 as I would perceive this as violation of the spirit of our own
mission, effectively the pawn in corporate shenanigans.

But the fact that this was never copyleft, as pointed out to me initially
by Sam, leads me to conclude that the ASF is, in fact, a good home to
launch such an effort, and allows any actor from the general public to have
the same advantages and privileges which were once reserved for the elite
and most profitable consumers of this code.

Just want to close this observation by pointing out that IBM has been a
strongly reciprocal participant at a number of ASF projects, and I expect
nothing else.  I'm pretty certain we can conclude that Oracle will inhibit
Oracle employees from participating in a longer term way.  I also have
great confidence that IBM and other AL consumers will choose to contribute
back to an ASF based OOo for the long term, to the benefit of this shared
code base, and hope that other LibreOffice contributors also choose to do so.

So in spite of the concerns about the eventual number and diversity of core
contributors, about how the project would mesh with external projects, and
about precisely how much of the code is 'unusable' due to CC-AND licensing
or patents, I'm now prepared to support this incubation proposal and let
that podling work some of these more detailed questions out amongst
themselves.  I hope some individuals from LibreOffice also choose to become
part of this incubation effort and guide the effort in a positive direction
for all of the consumers.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message