Hi Ross,
On Thu, 2011-06-02 at 12:09 +0100, Ross Gardler wrote:
> However, I do have a binding vote here and therefore I have a
> couple of questions for you:
..
> Are the goals of the TDF the same as the goals of this proposal
> to the Apache Software Foundation.
I would say they are similar. Unfortunately, due to the very checkered
history of the OpenOffice.org project, licensing is very important to me
(and others, though I don't speak for TDF). Of course I agree, in the
abstract, that being vulnerable and letting companies not contribute
back -may- result in better corporate behaviour, active contribution,
consolidation and code re-use. However, I would hope we both agree that
this is not a uniform one-size-fits-all hard and fast rule. This effect
clearly varies between projects, and it has emphatically not been my
experience where I've cared to dig deeper: both in OO.o and elsewhere
eg. linux kernel device drivers :-) Perhaps you have some more thoughts
on where it works well, and where it does not ?
Anyhow, I don't believe that the Apache license would be a good fit for
either of these specific projects. My view as to whether ASF would make
a good home is conditioned solely by that. Otherwise you're great guys
and there is much to admire in your governance, good community taste
etc. etc. :-)
> Specifically "One of our goals with this incubation project will be to
> rationalize and formalize thje coordination of these upstream and
> downstream contribution,
Sure - there are lots of nice side effects of rationalisation and so
on, it all sounds good. But unfortunately IBM's move here is not
primarily focused on that - otherwise (surely) it would work with TDF -
where it has been made clear, it would be most welcome as a senior,
leading player. Incidentally, Rob's diversity diagram is in my view
somewhat misleading: large numbers of OO.o derivatives (no matter when
they release) are already united around LibreOffice's work.
> basing it on the Apache 2.0 license,
This would be -the- primary sticking point for me; this is no part of
my vision. Though of course there are many other sticking points around
inclusion, respecting existing contributor's work, basing reality on
real developer contribution of real code vs. corporate connections[1]
etc.
> I understand there is a potential licence debate in this question. I'd
> appreciate it if we could avoid that one (remember the Apache License v2
> is, at least one-way, compatible with GPL3).
So - to me, the business questions are all around good faith and
working together. The existing community of active developers, lets call
it "everyone except IBM" (as a rough approximation), have worked hard to
include all, and hammer out a flexible licensing compromise: MPL for
IBM's needs, LGPLv3+ for everyone else's. Of course, this is just one
example of a community compromise made by those contributing - there are
lots more. To have step one of the new unified world as: trash the
existing consensus seems an odd step here; even though I appreciate
Apache's work and like their license for where it works well :-)
Apache was clearly picked, as a good match for IBM (+Oracle?)'s needs -
that much is clear. Unfortunately, doing that with a callous disregard
for the existing people actually working on the project is unlikely to
yield a great result. It would be a shame to see your passion for your
licensing harnessed against those who wrote much of the (volunteer /
external) code in question :-)
> Instead I would like to understand if this technical objective of
> breaking OOo code into reusable libraries that the various forks
> can collaborate on, is part of the TDF mission.
The underlying structure is somewhat irrelevant to the user experience
and there has been a -ton- of pointless half-done re-factorings of OO.o
in the near past - most of them resulting in a worse user-experience :-)
The licensing is critical to developer inclusion, and product features
(we already include lots of copy-left code, -and- we have eight months
of changes by ~200 developers under those terms).
I don't believe we can in any way meaningfully separate licensing from
code, or its structure, or the individuals in the community - all three
are bound together: I assume I'm not alone in thinking that.
> A follow up question to this is, again from a technical perspective,
> is whether you, as a LibreOffice contributor, believe collaboration
> on core components might be possible in the way described.
I think it is unfair to make this an individual question. I've written
a little about this here:
http://www.gnome.org/~michael/blog/2011-06-02.html
To pick off individual contributors from TDF is of course possible.
There may well be some who have no problem with corporations, that
apparently have zero respect for the will of the developer community,
and little desire to play well: taking their work without contributing
back. To pick off individuals however is a rather unfortunately
pro-active strategy, I assume you are not proposing that ?
I would hope instead, that ASF + IBM can work with TDF's governance to
try to hammer out some ( I suspect grisly to ASF ) compromise. In my
view, a key element of that needs to be copy-left licensing[2] to assure
the project's future as a focus of real community collaboration.
Regards,
Michael.
[1] - I am un-aware eg. of either Rob or Andy ever contributing any code
to OO.o (or having any broad / deep knowledge of the code-base). A
strange choice, given the apparent presence of many articulate,
competent, experienced developers on the code in each company any of
whom would have been better.
[2] - perhaps we could avoid that by mandating that every participant
merging a patch to OO.o sign a covenant that requires them to behave in
an identical fashion to a copy-left license, in perpetuity: but then,
that would further reward those who don't engage at all I guess, and ...
well - seems over-complicated to me :-) but perhaps a way out (or in)
--
michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
