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(_at_)levkowetz(_dot_)com> 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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf