Hi Noel,
On Thu, 2011-06-09 at 13:13 -0400, Noel J. Bergman wrote:
> I heard about this, myself, in some specific detail very recently.
> I will leave disclosure to the relevant parties, but while it may
> or may not be an issue for you ...
I rest my case about FUD. It seems hard for me to reconcile your
statement with the emphasis around things happening transparently on
mailing lists. Of course it is an issue for me and disclosure is the
solution for it: surely.
> > Can you comment on your plans, and/or can others comment on ASF
> > policies in this regard ? how are such issues worked through ?
>
> Rob has already stated, as quoted by you, that "Symphony has done
> IP remediation at many levels. Where we've worked around things,
> WE WILL BE ABLE TO CONTRIBUTE OUR FIXES BACK." [Emphasis mine]
Thank you for your emphasis. Let me insert mine: CLEARLY I AM AN IDIOT
(cf. my sig :-). Now let me expand on my question, I had hoped the
question(s), from the context of the preceding paragraph were clear -
apparently they were not:
> > Can you comment on your plans
This meant: does IBM (or whomever the 'we' Rob uses is) intend to
contribute these supposed remediation changes back in a way that
involves full disclosure following the best-practise template that
Tridge provided ?
*Or* - does it intend to simply submit patches that tweak, and/or
remove, and/or change features in subtle ways without advertising their
effect / rational in a way that is not transparent ?
eg. I don't expect to know all the details of why a one-line "fix Foo
Feature implementation" commit is like it is; -but- if there is some
heavy-duty legal thinking behind it - then I do. I would like to know if
IBM intend to make that detail public as they commit such work. Is that
truly an unfair unreasonable question ?
> > and/or can others comment on ASF policies in this regard ? how are
> > such issues worked through ?
This question was intended to mean:
"What is ASF's normal modus operandi here ?, how does this type
of issue get addressed ? are there guidelines on this kind of
work getting done in public ? are there pre-existing cases of
this getting done ? how are such issues worked through ?"
So far I have an assurance from Sam that everything will be done on the
public mailing list in an open way. That is great, but not 100%
satisfying: does that include a public rational for apparently trivial
code changes that have an impact in this area ? [ we would want to be
aware of these of course ].
I have an assurance from Ross that, when voted on, technical
justifications will have to be given for the inclusion or otherwise of
code changes; that is good too - but surely not every change is voted
on.
So these get closer to answering my questions above - yet I am still
concerned about such work being done in a way that is public yet
obscure, hidden in plain sight - hence my question. Unless we are aware
of the issue, we cannot be sure that we include such changes (as
separations) into LibreOffice - which is a substantial issue (at least
for us).
> ASF policy is that our code must be unconstrained, in order to be
> available for all purposes to all parties. So, yes, we should expect
> (and require) that IP remediation will happnen in our codebase.
Thank you, that is helpful.
> > * As a European, I rather resent the ethnocentric imperialism
> > implied by trying to export the (terminally broken) US patent
> > system
>
> As an American, I wish that you lot would simply up and pass
> legislation to reject all US Patents on software so that we
> can get rid of our broken US patent system.
I don't quite understand your suggestion; European jurisdiction quite
sensibly doesn't extend to the US, and my ability to influence US policy
is negligible. As I understand it US patents are not enforceable in
Europe and many other jurisdictions anyway - what more can we do ? but
IANAL so YMMV.
All the best,
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
