So what I hear (and for the benefit of others, let me note that you
and I have ha a fairly detailed discussion privately that I think I am
summarizing the result of) is that you want a short term solution and
a long term solution. The short term solution would be adequately
solved by using the 3978 options for most documents, and for documents
with code, the 5378 option or a letter-or-whatever sent in parallel
that was equivalent. In the long term, you would be fine with a rule
that supported all existing 3978 options plus some number (one?) that
said "this contains code, and...". Am I correct?
If so, the present dilemma can be resolved by
- the IESG rescinding its acceptance of 5378, reinstating 3978
as the rule of the day
- the IESG directing the Trust to accept legal communications
(letters, PGP-signed emails, whatever) that convey the sense of
the 5378 license for code-bearing documents as a
temporary workaround
- in the long term, the development of a 5378-bis that
* accepts 3978 options as is for non-code documents and <the
right option> for documents containing code,
* treats movement of documents to other SDOs as a special
case to be handled by the parties to the transaction
including the trust and relevant authors etc.
Close?
On Jan 9, 2009, at 3:52 PM, Joel M. Halpern wrote:
My own take has been that the code reuse problem is the dominant
problem. Document transfer outside the IETF is sufficiently rare
that I would agree with Fred that not solving that is fine.
This also means that from my personal perspective, a solution that
says (loosely based on a suggestion from someone else in a side
conversation) that
1) If you can, you grant 5378 rights
2) If you can't, you grant the old rights, as long as there is no
code in the document
3) If there is code, get the rights to the code so people can
actually use the code in the RFC to implement the RFC. (MIBs are
already covered, but we have lots of other kinds of code.)
would seem a workable path.
Yes, point 3 may hold up some work. But one could reasonably argue
that such work needs to be held up so that folks can use the code we
are giving them.
And I fully agree that we should leave all legal wordsmithing to the
trust and the lawyers. They have to do it anyway.
Yours,
Joel
John C Klensin wrote:
--On Saturday, January 10, 2009 11:07 +1300 Brian E Carpenter
<brian.e.carpenter@xxxxxxxxx> wrote:
Thanks John, I believe that is an excellent summary of the
viable options. My draft implicitly adds
(2.5) Post-5378 documents that incorporate pre-5378
materials whose original contributors have duly agreed are
posted according to 5378 rules, with no exceptions.
To my mind the main open issue is whether we want to
require authors to try for (2.5) before proceeding to (2).
I am all in favor of authors trying for 2.5 if they have the
time and inclination although, mostly, I'd rather have them
spend time on technical work (Marshall's suggestion last month
that the Trust itself should take responsibility for rounding up
old rights has some appeal here). What I'm opposed to is
requiring authors of documents that might have had a very long
history to take responsibility for claiming that they have
identified all of the original contributors. My problem with
2.5, stated somewhat more aggressively than is probably
desirable, is that it requires the submitter of a 2.5 document
to stand up and say "I have identified all of those who might
claim to have rights in this document, will take responsibility
for getting that identification right, and obtained their
consent". There is a possible 2.5bis, which would be something
like "I've
made a good-faith, reasonable-effort, attempt to identify
everyone
and have the agreements from everyone whom that process
identified, but I make absolutely no warranty that I've
identified everyone or that other claims won't come up; if they
do, it is the user's problem, not mine."
Whether that is enough different in practice from my (2) to be
worth the complexity... I don't know.
john
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf