Hi Rob,
In the deluge of drivel I lost this gem in your response to
my scepticism about how quickly you could provide a binary release:
On Fri, 2011-06-03 at 10:31 -0400, robert_w...@us.ibm.com wrote:
> But one thing not to lose track of is that Symphony has done IP
> remediation at many levels. Where we've worked around things, we'll be
> able to contribute our fixes back. Could we have missed something? This
> is always possible. But I know with certainty that we've fixed things
> that LO has missed. (I'm talking patents, not the MPL/LGPL dependency
> issues).
You seem to assert that you have patent remediation patches for
problems that others are unaware of, that you can provide, but you are
choosing not to (yet) ? There is a nasty nucleus of potential future FUD
here, so it would be interesting to firm this perennial rumour up.
Is that what you are saying ? if so, my /show me the code/
request gets quite a lot louder. Assuming that is what you're saying,
I suppose this holding of key changes back is another un-expected
side-effect of the pure-joy of non-copy-left licensing.
Naturally, if there are changes to improve the product in this area,
I'm eager to be merging them for LibreOffice, and I am certain our team
is too. I would -hope- that open discussion of these things, would follow
IBM's best-practise template of Tridge's excellent work in the (copy-left)
linux kernel eg.
http://lkml.org/lkml/2009/6/26/313
and http://lkml.org/lkml/2009/6/26/314 pwrt. Q5 and onwards
IMHO this is vastly preferable to some smoke and lawyer (IANAL)
filled room that issues edicts to remove features and veto patches
without a clear public rational on a public list (cf. the above).
Can you comment on your plans, and/or can others comment on ASF
policies in this regard ? how are such issues worked through ?
> I think we'll all be in a stronger position, IP-wise, once (and
> if) we can all get working from the same repository.
My hope would be of good public disclosure following Tridge's
pattern that also allows substantial clarity around the issues, and
thus does not require blindly working from the same repository: and
indeed is a benefit to all free software office suite hackers.
Furthermore - another key issue of the LKML approach is that the
functionality is still present, but compile-time disabled. That seems to
me to have a number of positive virtues:
* As a European, I rather resent the ethnocentric imperialism
implied by trying to export the (terminally broken) US patent
system, and I resent the idea of permanently depriving the
whole world of good software primarily to make Americans
happy (until expiration)
+ separation can help avoid this general problem,
* removal of features without a clear explanation is a recipe
for people to jump in and fix eg. the FAT file-system issue
they have, while being unaware of the mine-field they
tap-dance into thus wasting time & destroying motivation
+ much better to have the feature present but separated
in some clean way.
So - in summary, what is really being suggested here ? and how
does it fit into the ASF way ?
Thanks,
Michael.
--
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
