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
>>>><[EMAIL PROTECTED]> 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
>>>>[EMAIL PROTECTED]
>>>>https://www1.ietf.org/mailman/listinfo/ietf
>>>
>>
>
_______________________________________________
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
