[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Concensus and oversight for bad decisions...

Harald - what if the consensus puts in place something that is not legally defensible? What I mean is what if the WG member's decided to do something that was illegal per se... how is oversight addressed???

This is an important question to ask of a bunch of engineer's (me included) who are drafting contract language itself.

Todd

----- Original Message ----- From: "Harald Tveit Alvestrand" <harald at alvestrand.no>
To: "Simon Josefsson" <simon at josefsson.org>; <ipr-wg at ietf.org>
Sent: Tuesday, July 24, 2007 1:42 PM
Subject: Re: Review of outbound-03: Major issues




--On 24. juli 2007 19:45 +0200 Simon Josefsson <simon at josefsson.org> wrote:

Hi again.  These are my two main objections to this document right now.
I'm still on vacation, so I didn't see the last call notice before;
hopefully this note will still be useful even though the deadline has
passed.

* Don't separate licenses for text and code.  (section 6.3)

  Generally, this leads to legal complexity when two licenses has to be
  maintained.  There is legal difficulty in making it clear that
  different parts of a document is available under different licenses.
  This will undoubtedly lead to delays in the IETF process when people
  need to learn about this complexity, and negotiate how to solve it.

  By having a license (the non-code license) that is incompatible with
  both free and non-free software licenses, this will harm the adoption
  rate and interoperability of IETF standards.  If non-code portions
  cannot be used by implementers, those portions will have to be
  rewritten, and we all know that rewriting technical standards always
  leads to subtle error.

  The license on non-code portions of RFCs will make it impossible to
  distribute RFCs via popular free operating systsms, such as Debian or
  Ubuntu.  I believe this will ultimately harm the IETF.

  As far as I see, there is no good justification for this complication.
  The decision to go this route was made early on without understanding
  what the consequences would be, and an unwillingness to discuss or
  reconsider.

I believe this is a request to reopen a previously closed issue (#1169).
I believe the group has discussed this issue for a long time, and I have seen no sign that consensus has moved.

If you wish to claim that I have not accurately reported the consensus of the WG, please appeal; if you believe that the consensus of the IETF is (or will be) different from the consensus of the WG, please raise the issue at IETF Last Call.

Otherwise, please stop beating this drum. We've all heard you.

* Permit additional license notes
  and additional copyright notices (section 6.5)

  I believe the current text goes beyond RFC 2026, RFC 3978 and the
  running code of the IETF.  Several code examples have been included
  into IETF documents with special license notes.  RFC 2026 and RFC 3978
  permits additional license notes (but not additional copyright
  notices).

  A lot of source code that is useful to include in RFCs are available
  under liberal licenses, such as the BSD license.  That license
  requires that the license notices are preserved.  It is helpful for
  technical documents to include such source code.  I believe the
  outbound document should not stand in the way here.

  There also doesn't seem to be a good justification for the text.  What
  problem is it aiming to solve?

Please identify exactly which section you mean. I do not know if this is a duplicate of #1282 or not.

               Harald


_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg 


_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg