[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#6247)



Dear Pierangelo, (dear Kurt),

first of all my special thanks belong to both of you for your 
contribution to the on going discussions. Secondly I want to take the 
opportunity just right now to clarify that I do not agree to your idea 
or suggestion to extend the copyright in direction of a 
dual-portion-copyright statement.

Based on my analysis of your surprisingly fast submitted code sample I 
came to the following conclusion and justification regarding my decision 
above:

Last but not least I would have appreciated it if you would have 
contacted me *before* changing the code and not to mention my copyright 
notice. Thanks Kurt for your intervention.
Besides this, as time, discussion and development has continuously moved 
on (even before your kind of "uncoordinated emergency submit") it seems 
to me that your sudden sample code does not cover any of my primary 
intentions already rudimentary contained in "now.c" and mentioned during 
the discussion:

- there's no kind of inheritance of matching rules (all are directly 
associated to generalizedTime / CSN)
- additionally the nowOrLater *and* the nowOrEarlier-rules are 
associated simultaneously to one and the same attribute (what makes no 
difference for single-valued attribute and thus could be done. On the 
other hand this leads to false positively reported valid but indeed 
invalid entries in case of multi-valued attributes - details see below).
- you have not implemented any sort of possibility to allow the 
definition of separate "syntactically standalone" attributes (derived 
from generalizedTime/CSN, by independent syntax) to limit LE/GE 
filtering for both dead center attributes. (limiting search access using 
ACLs would obviously not work because the extensible search needs to be 
allowed).
- multi-valued upper dead center timestamp attributes can not be handled 
correctly by your code. I have not investigated in deep but it is clear 
to me that in case of multiple values whereas one or more timestamp/CSN 
values are in the past, while at least one is in the future leads to the 
above mentioned false positive reporting in your code.
- It seems to me that you have not tested the behavior of your suggested 
code properly in this short period of time (your tests have only seem to 
cover createTimestamp - which btw do not make any sense in concern to 
now.c's common intention in case the createTimestamp's value has not 
been faked ;-)).
- as your code changes significantly changes the behavior and intention 
of now.c your submit also lacks any kind of documentation (besides the 
code, which I had to analyze first).

In my opinion your submit sadly does not represent a very useful 
enhancement nor a functional extension (in the sense of the original 
goal of now.c) which could be integrated without major adaptations. 
That's the reason why I'm currently not see any reason to share my 
copyright notice. Nevertheless, as I've already told you before the 
discussion with you have always been very helpful for me so I've added 
you willingly to the acknowledgments section. I hope you understand my 
explanations and it will be fine for you. Of course I'm available and 
ready for further technical discussions ...

Last but not least and from lessons learn: I think some kind of a formal 
specification (external to my head ;-)) would be very helpful to 
understand the design ideas, decisions as well as the new chances (and 
possible limitations) now.c introduces into LDAP. One or perhaps even 
more related I-Ds are currently a work in progress here at my side.

I've uploaded a new version of now.c (as tgz because it contains various 
files, e.g. a sample schema in ldif- and schema-format for easier 
testing and perhaps as a basis for on going discussions). I hope I've 
correctly updated the IPR statement according my above expressed 
intention and according the needs of the OpenLDAP foundation. Kurt could 
you please have a look on it again?

The updated version can be obtained from here: 
ftp://ftp.openldap.org/incoming/daniel-pluta-now-090815.tgz

Thanks a lot and best regards
Daniel

-------- Original-Nachricht --------
Betreff: Re: [OFFLINE] Re: (ITS#6247)
Datum: Thu, 13 Aug 2009 08:54:35 -0700
Von: Kurt Zeilenga <kurt@OpenLDAP.org>
An: masarati@aero.polimi.it
CC: daniel@pluta.biz
Referenzen: <200908131112.n7DBCYIx025879@boole.openldap.org> 
<46026.93.149.38.235.1250177284.squirrel@www.aero.polimi.it>


On Aug 13, 2009, at 8:28 AM, masarati@aero.polimi.it wrote:

> Daniel (Kurt),
>
> (Note to Kurt: as there is no affiliation between Daniel and me, we  
> did
> not coordinate anything, so we'll probably better do it now and  
> start from
> scratch, instead of polluting the ITS).

This needs to be done in two steps.

1) Daniel needs to address notices issues in his submission.
2) You need to address the notices issues in your derived submission.

Daniel should follow the instructions I provide, and then you should
follow the instructions I provide.  These steps are simple, straight
forward, and have a clear result.

> I suggest Daniel evaluates the line I'm proposing

No.  This in no way fulfills the Foundation requirements.

The line you are asking Daniel to evaluate is not a formal notice.
You actually failed to met his license, which requires you to include
a copy of his copyright notice in your work.  You copied only an
informal acknowledgement, not his copyright notice and license
statement.

> and, based on the file I
> submitted, formalizes a definitive patch with appropriate copyrights  
> and
> submits it along the guidelines of the OpenLDAP foundation.

Your submission doesn't met the guidelines of the Foundation as it
also doesn't include a notice of origin nor asserts your copyright,
and worse, it failed to met the copying requirement Daniel placed on
his submission (that his notice be included in copies).