Hi Leslie, on 2004-12-03 6:19 pm Leslie Daigle said the following: > Henrik, > > I believe that's true of the principle, expressed this way: > > [I wrote:] > >>Taking the step back -- the principle was that the IETF should > >>retain the rights to, ability to access, and ability to move > >>the data it creates. Period. > > I (still) believe that the text that was proposed (detailing > *how* to implement that principle) is in danger of > locking us out of, say, contracting with a professional > meeting organization service that has proprietary software > for managing meeting attendee lists. (I.e., software that > could do a data dump for us, but that is not open source, > for which we will not have license to run in perpetuity, > yada yada yada). I agree that we should not lock ourselves out of the possibility to avail ourselves of services of the kind you delineate here, (something I also tried to indicate in a response to Bert on this topic earlier). But I also believe that the principle you state initially above deals only with the data, and leaves the issue of tools _developed for_ the IETF undefined; a case which is different from services bought by the IETF, provided by independently developed tools - the case you illustrate in your example. It is this distinct case I would prefer to have covered, in addition to the case for the data (on which I agree). Henrik > Leslie. > > Henrik Levkowetz wrote: >> No, I think that as a principle that prevents us from inadvertently >> or short-sightedly putting ourself into a locked-in position vis-a-vis >> a contractor, this kind of statement of principle is exactly what >> we need. >> >> Henrik >> >> on 2004-12-03 5:45 pm Leslie Daigle said the following: >> >>>Hang on... are we not getting too detailed again, at the >>>risk of over-constraining ourselves? >>> >>>As has been mentioned on this thread -- we (IETF) may well want >>>to take advantage of non-open-source software, if it's the >>>most effective & efficient choice. I'm thinking specifically >>>of contracting with a provider that has their own software tools. >>> >>>Neither should we be constraining ourselves to choose from >>>providers with open source tools, nor should we be requiring >>>that *all* features we ask to add to those tools be available >>>as open source, or freely to the IETF, etc. >>> >>>Taking the step back -- the principle was that the IETF should >>>retain the rights to, ability to access, and ability to move >>>the data it creates. Period. >>> >>>Sensible ways of achieving that include (but are not limited >>>to) working with open source tools and/or ensuring we retain ownership >>>of any software that touches that data. Others include >>>using reasonably accessible off the shelf software (one Excel >>>program is much the same as the next...), or agreeing on >>>data interchange formats. Let's not try to make the laundry list >>>in this document. >>> >>>Leslie. >>> >>>Harald Tveit Alvestrand wrote: >>> >>>> >>>>--On fredag, desember 03, 2004 10:19:23 +0100 Henrik Levkowetz >>>><henrik@xxxxxxxxxxxxx> wrote: >>>> >>>> >>>>>What about this text, (added to 2.2.6): >>>>> >>>>> "As a matter of principle the IAOC and IAD should ensure that any >>>>> contracts for IASA clearly designate that any software, databases, >>>>> and websites developed should be available to the IETF with no >>>>> restriction by the contractor. Software should be open source and >>>>> data should be made available to the IETF in machine-readable >>>>> format, also in cases where it may be inadvisable to make the data >>>>> openly available." >>>>> >>>> >>>>this works for me (my only problem is stylistic - it's somewhat long for >>>>a principle, so may fit better in the "details" sections, if a place can >>>>be found for it). >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Ietf mailing list >>>>Ietf@xxxxxxxx >>>>https://www1.ietf.org/mailman/listinfo/ietf >>> >> > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf