Subject: Fwd: I-D ACTION:draft-ietf-ipr-outbound-rights-02.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Jan 2007 00:28:02 -0500

Below is the announcement of the revision of the outbound rights document.
I have attempted to reflect accurately the WG consensus as reported 
by the chairs.

If have made mistakes, please let me know.

I have also tried to clean up the wording, in accordance with the 
discussion at the meeting and on list.  Again, if I messed up, please 
say so.  If I got the wording wrong, suggested alternative wording 
would be appreciated.

Yours,
Joel M. Halpern

>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the Intellectual Property Rights 
>Working Group of the IETF.
>
>         Title           : Advice to the IAOC on Rights to be 
> Granted in IETF Documents
>         Author(s)       : J. Halpern
>         Filename        : draft-ietf-ipr-outbound-rights-02.txt
>         Pages           : 9
>         Date            : 2007-1-23
>
>The IASA is resposible for managing intellectual property rights on
>    behalf of the IETF.  This includes the license to copy, implement and
>    otherwise use IETF contributions, among them Internet-Drafts and
>    RFCs.  The IASA accepts direction from the IETF regarding the rights
>    to be granted.  This document describes the desires of the IETF
>    regarding outbound rights to be granted in IETF contributions.

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 24 Jan 2007 10:12:04 +0100

Joel, all,

Comments on the entire document, quoted inline, below.

1.  Introduction

   Under the current operational and administrative structures, IETF
   intellectual property rights are vested in a trust administered by a
   board of trustees made up of the members of the IASA.

RFC 4371 says: "The Trustees of the IETF Trust are the members of the
IAOC", not the members of the IASA.  I don't know if this matters in
practice, though.

I also suggest to replace 'vested in a trust' with 'vested in the IETF
Trust', and include a reference to, e.g., RFC 4371.

   contributions, until it is superceded.
                                   ^
Typo, "superseded".

3. Purpose in Granting Rights

Generally, this section is very helpful for the understanding, thanks!

   The IETF's mission is to write documents that help make the internet
   work better (see [2] for more details.)

I suggest to change 'write' to 'produce', since it is actually not the
IETF itself who writes the documents, and to remove the word 'help'.
This is to make the text more consistent with RFC 3935:

,----
|  The goal of the IETF is to make the Internet work better.
| 
|  The mission of the IETF is to produce high quality, relevant
|  technical and engineering documents that influence the way people
|  design, use, and manage the Internet in such a way as to make the
|  Internet work better.  These documents include protocol standards,
|  best current practices, and informational documents of various kinds.
`----

   RFC. this is at best cumbersome, and often much worse than that.  It
        ^

Typo.

   publication.  Changes to the iETF documentation, and document
                                ^

Typo.

   As stated earlier, this document describes the IETFs desires in terms
   of granting rights to those who read or make use of material in IETF
   contributions.  This document does not specify what rights the IETF
   Trust receives from others in IETF contributions.  That is left to
   another document.  While care will be taken by both the working group
   and the IASA to see that sufficient rights are granted to the IETF
   trust in IETF contributions, it is also the case that the trust can
   not grant rights it has not or does not receive, and it is expected
   that policies will be in line with that fact.

That's true, but not the entire story.  It is possible for the inbound
rights to give rights to third parties directly.  Thus, it is possible
for the IETF to grant third parties rights that the IETF doesn't own
itself.

   Similarly, the text for pre-existing documents can not be changed.
   Nonetheless, to the degree it can, and without embarking on a
   massive effort, it is desirable if similar rights to those
   described below can be granted in older RFCs.

I suggest to remove 'and without embarking on a massive effort, '.  It
IS desirable if the same rights can be granted to older RFCs, full
stop. Practical considerations may affect whether it is worth the time
to invest in that massive effort, and I suspect it will never happen
on a full scale, but that doesn't change that the desire to do this is
present.

5.  Recommended Grants of Right to Copy

   The IETF grants rights to copy and modify parts of IETF contributions
   in order to meet the objectives described earlier.  As such,
   different circumstances and different parts of documents may need
   different grants.

I believe that having different licenses for different parts of RFCs
is a bad idea.  I don't think the document discuss the justification
for this decision.  This decision, which may seem minor, will have big
consequences to some organizations.  The Debian community will not be
able to distribute RFCs if the entire RFC isn't available under a
permissive license.

   This section contains subsections for each such
   different grant that is currently envisioned.  Each section is
   intended to describe a particular problem / situation / usage, to
   describe how that situation is recognizable, and to provide guidance
   to the IASA as to what rights the IETF would like to see granted in
   that circumstances, and what limitations should be put on such
   granting.  As stated above, the formulation of legal language for
   granting these rights (including the determination of how many sets
   of legal language are required is largely left to the IASA.
                                                             ^

Typo, a missing closing parenthesis.

   It is particularly noted that there has been a historical issue where
   it is difficult to fix legal wording and boilerplate if the direction
   defining that boilerplate is in an RFC, and then it turns out the
   wording needs modification.  As such, this document does not specify
   such wording.  Further, it is strongly recommended that all future
   RFCs on this topic refrain from defining the precises wording of
   boilerplate.  Similarly, legal issues of how to indicate usage
   restrictions are left to the IASA and legal consel to determine.

I wonder how this will actually work in practice.  Will there be an
RFC that says IETF contributors must conform to legal rules as
specified by <some URL> which can and will be modified at any time by
the IASA?  What are the appeal paths for IETF members who disagree
with the changes of the text that goes into every RFC?

While it has its problems, fixing the legal language in a
community-approved RFC, has the advantage that it re-use the consensus
checks of last calls, and preserve the appeal paths.

   In structuring these desires, it is to be kept in mind that the autor
   has not given up his copyright in granting rights to the IETF, and
   the IETF is not attempting to transfer or relinquish the rights it
   has.  The purpose is to enable to IASA to grant people the right to
   make copies of material in RFCs in ways that fit the goals of the
   IETF.  This discussion is also separate from the rights the IETF
   itself requires in documents to do its job, as those are not
   "outbound" rights.  It is expected that the rights granted to the
   IETF will be a superset of those copying rights we wish to grant to
   others.

There seem to be a hidden assumption here.  Having the inbound rights
document require that contributors directly grant rights to third
parties is a possibility.  I'd like to see more discussions on that,
both in the WG and in the document.  This goes against how RFC 3978
works -- according to Jorge, if I understand him correctly, section
3.3 of RFC 3978 give third parties the right to code directly from the
contributor, and not via the IETF.

5.2.  Rights Granted for Quoting from IETF Contributions

   There is rough consensus that it is useful to permit the quoting
   without modification of excerpts from IETF Contributions.  Such
   excerpts may be of any length and in any context.  Translation of
   quotations is also to be permitted.  All such quotations SHOULD be
   attributed properly to the IETF and the IETF document from which they
   are taken.

I suggest changing 'to the IETF' into 'to the contributor and/or the
IETF'.  Some documents may have been written completely by a single
contributor, without having reached any IETF consensus, and possibly
even with consensus against the document.  Having a suggestion to
attribute it as a work by the IETF would be unfortunate.

5.3.  Rights Granted for Implementing based on IETF Contributions

   IETF contributions often include components intended to be directly
   processed by a computer.  These may be ABNF definitions, XML Schemas
   or DTDs, MIBs, or even classical programming code.

I suggest to replace 'These may be' with 'Examples include', as it is
not clear that the list is not intended to be exhaustive (someone else
raised this concern earlier too).  I also suggest to add 'ASN.1
schemas' since that is frequently a problematic case.

   These are include for clarity and precision in specification.
                    ^
Typo, add 'd'.

   It is clearly beneficial, when such items are included in IETF
   contributions, to permit the inclusion of such code fragments in
   products which implement the contribution.  It has been pointed out
   that in several important contexts, use of such code requires the
   ability to modify the code.  One common example of this is simply
   the need to adapt code for use in specific contexts (languages,
   compilers, tool systems, etc.)  Such use frequently requires some
   changes to the text of the code from the IETF contribution.
   Another example is that code included in open source products is
   frequently licensed to permit any and all of the code to be
   modified.  Since we want this code included in such products, it
   follows that we need to permit such modification.  While there has
   been discussion of restricting the rights to make such
   modifications in some way, the rough consensus is that such
   restrictions are likely a bad idea, and are certainly very complex
   to define.

I believe the same argumentation holds for non-code portions as well.

   Firstly, the IASA should maintain, in a suitable, easily accessible
   fashion, a list of common RFC components which will be considered to
   be code.  To start, this list should include at least the items
   listed above, ABNF definitions, XML Schemas, XML DTDs, and MIBs.  The
   IASA would add to this list as it deems suitable or as it is directed
   by the IETF.

The list above also includes programming code.  I suggest to add both
programming code and 'ASN.1 schemas' here.

5.4.  Rights Granted for use of text from IETF Contributions

   There is no consensus at this time to permit the use of text from
   RFCs in contexts where the right to modify the text is required.  The
   authors of IETF contributions may be able and willing to grant such
   rights independently of the rights they have granted to the IETF by
   making the contribution.

   As such, in crafting legal language and boiler plate, the IASA is
   also asked to resolve and indicate how code segments of IETF
   documents, which can be extracted and subsequently modified, are to
   be indicated by authors and editors as distinct from text segments,
   which can be extract but not modified.

I suggest to add something along these lines:

   The IASA is also asked to resolve and indicate how authors who are
   willing to grant the same rights as for code to the entire document
   should indicate this.

Because I assume that the naive approach of using the IASA-recommended
"<code>"-markers will not be possible to put at the first and last
line of a document.  If there is a Best Current Practice on how to
achieve this, it would allow, e.g., the Debian community to ship those
RFCs that are licensed more permissively.

5.5.  Additional Licenses for IETF Contributions

   There have been contexts where the material in an IETF contribution
   is also available under other license terms.  The IETF wishes to be
   able to include content which is available under such licenses.  It
   is desirable to indicate in the IETF contribution that other licenses
   are available.  It would be inappropriate and confusing if such
   additional licenses restricted the rights the IETF intends to grant
   in the content of RFCS.

   However, the IETF does not wish to have IETF Contributions contain
   additional copyright notices and licenses, as that introduces a
   number of additional difficulties.  Providing the correct legal
   approach to such indications is left to the IASA, as all legal
   language is.  Specifically, additional text in the document, and any
   additional license referred to by permitted additional text MUST NOT
   in any way restrict the rights the IETF intends to grant to others
   for using the contents of IETF contributions.

This doesn't reflect the current "running code" on the copyright
notice issue.  I believe it would be useful to be able to include,
e.g., code under the revised BSD license in an RFC.  That require
adding a copyright notice.  Could you expand on what the 'additional
difficulties' are?  It appears as hand waving to me.

Thanks,
Simon

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Jan 2007 09:00:47 -0500

Thank you for a number of very useful checks on wording.
A number of the issues you included in your comments are requests for 
change in the rough consensus as called by the chairs.    Unlike the 
editorial matters, I can not choose to make those changes.

One item occurs a couple of times, and seems to me to be a bit confusing:

>for the IETF to grant third parties rights that the IETF doesn't own

While we could write the inbound rights document that way, I was 
under the impression that the agreement was that inbound would deal 
with contributors granting rights to the IETF, and outbound would 
deal with the IETF granting rights to others.  As such, I don't need 
to address a hypothetical more complex interaction between the two documents.
I would expect that the required boilerplate would be based on both documents.

Yours,
Joel M. Halpern

---

From: "todd glassey" <[email-masked]>
Date: Wed, 24 Jan 2007 06:38:26 -0800

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "Joel M. Halpern" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 24, 2007 1:12 AM
Subject: Comments on draft-ietf-ipr-outbound-rights-02.txt

> IAOC", not the members of the IASA.  I don't know if this matters in

of course it matters silly.

> Trust', and include a reference to, e.g., RFC 4371.

BTW - Vested is a term with a number of meanings. The IETF also tends to 
reinvent terms used in the outside world to suit itself too, so let me ask, 
what is the "Vesting Process" as defined by the term "vested in the IETF 
Trust"

>   contributions, until it is superceded.

Depends on where its spelled.

>   work better (see [2] for more details.)

Hmm - this is someone trying to accord themselves the status of "Keeper of 
the Internet" and that is a lawsuit waiting to happen. The IETF is not 
involved in 'making better' or anything that would allow someone to sue the 
IETF for 'making the IETF better by refusing their initiative'...

What the IETF is sipposed to be per its founders, is a uniform process for 
vetting and advancing technologies such that they are robust enough to be 
accorded the award of "Standard", and nothing more.

> |  best current practices, and informational documents of various kinds.

Again the terms "Make the Internet better" are a value judgement which opens 
the IETF to litigation as it does the members of the IETF WG's who were 
involved in stomping on someone elses voice or initiative... These actions 
may and likely do IMHO constitute 'tortuous interference' with another 
party's standards initiative.

So let mer ask - I understand why some idiot author would write this but why 
would this IETF be stupid enough to allow anything that put forth a value 
judgement in language to be removed. Standards are not places for people to 
hide 'political statement's' like "Keeping the Internet Safe for Man, Woman, 
Child, and unmannned Bot", and these are inappropriate to any IETF process. 
The IETF is not the Keeper of the Internet the Governments of the World and 
the Telecom Operators' that make up the Internet are.

This group creates Standards... the why or individuals goals in the process 
documents are inapproariate.

>   contributions.

No it doesnt - this WG has no idea what the IETF membership wants outrside 
of the few that attended the last couple of meetings. The reason is that 
this Group's Work Product is not vetted by those it is supposed to govern. 
Didnt we fight a war about this a couple hundred years ago  here in the US. 
Something about no-representation?

> This document does not specify what rights the IETF
>   another document.

Again making the submission process a nightmare since no one in their right 
mind could within ten minutes figure out which documents and how they effect 
the legal issues oaf participation... No this WG has screwed the pooch 
royally and its pretty funny how incompentent the effort has been. The goals 
are simple:

o-    create a set of terms and conditions for participation that are all in 
one document and easy to understand.
o-    these t's and c's for participation must also be legally enforceable 
in the US and in the other Jurisdiction's they are to be enforced in. If 
there are conflicting laws then US law supercedes.
o-    the goal of the Internet Engineering Task Force is to be an "open and 
fair Standards Development Organization", one that is open to all for the 
development of any protocol for which there is a proposal submitted and team 
members ready to vet.

This clearly wasnt done.

>  While care will be taken by both the working group

When the policies are strewn about multiple documents it makes it very 
difficult to properly model and interpret them relative to each other.  For 
instance - when does the authority of one document leave off and that opf 
another begin.

> for the IETF to grant third parties rights that the IETF doesn't own

Simon - I disagree. If the contract to convey IP to the IETF has others 
rights tied to it, the issue of who's rights superscede becomes and issue. 
Likewise this opens the IETF to litigation again from that '3rd party' for 
any screw-ups that happen from the presentation or standards vetting 
processes IMHO.

> on a full scale, but that doesn't change that the desire to do this is

Actually - I am willing to bet than 99% of any RFC owners will tell you that 
they are unwilling to change any of the contractual trappings their RFC's 
were issued under so that this small group of people's ideas about the Trust 
can be made to occur. Further, once again, since NO general participants 
hold legal power of attorney for their sponsors, they cannot convey anything 
to the IETF, and its hysterical to think that this WG doesnt see that.

This WG claims that the IETF cannot 'send out more rights than it recieves' 
and it refuses to also put in place the necessary IP conveyance processes to 
assure proper transfer of IP's to it.

"Adhesion" comes to mind as a legal term here eh Jorge?

> is a bad idea.

Hmmm - It may be... but the author who references external IP's cannot give 
you rights to them if they dont own in them. Writing about an IP doesnt make 
it yours, especially if it was developed by someone else. In fact I can see 
the IETF being sued again because it lets someone other than the IP Owner 
file RFC's and I-D's pertaining to controlled IP's.

> I don't think the document discuss the justification

So what??? why does the IETF need to have Debian Copyrights on the IETF's 
document. The redistribution rights you are speaking to are specific to 
who's copyrights appear on the printed pages as far as I can tell.

So please answer me this - Why does Debian need the ability to put its own 
logo or copyright on these document? They are afterall the IETF's.

But if it (Debian et al) does, there is an interesting thing that Law Firms 
are doing which is to print their name and Logo's on the Right Margin's of 
their official Court Filings. This brands the filing/pleading as their own 
and looks sharp. It seems to me that the obvious answer here is to allow 
reprinting of the margin's with Private-Adopter's Marques in them.

>   of legal language are required is largely left to the IASA.

The problem with this generally is that there will also be exceptions to the 
cases.

>   processed by a computer

How about:

IETF contributions often include components intended
to be directly processed by a computer (i.e.
Types of Computer Code)

> These may be ABNF definitions, XML Schemas

Hmm... the problem here is that you have limited the types of inclusion with 
this statement.

>   These may be ABNF definitions, XML Schemas

How about:

"These inclusions are generally ABNF definitions,
XML Schemas or DTDs, MIBs, or even classical
programming code, but may include other
'Code-Types' as well"

>   products which implement the contribution.

>   It has been pointed out

Hmmm - For those instances a derivative use license is included for the 
Standards Process activities. What more is needed by the IETF?

>   modified.

A standards process is not open-source by definition - is it the IETF's 
intention that it be Open Source formatted? and if so how does this affect 
people who have participated and dont want their IP to be Open Sourced but 
rather want the IETF to apply RFC2026 rules to it.

>   Since we want this code included in such products, it
>   follows that we need to permit such modification.

Excuse me Simon what products??? - this is a standards organization and it 
doesnt produce any products. It produces standards or at least it is 
supposed to.

>   While there has

Concensus of who?  the 10 or fewer people on this WG who's commentary is 
listened to? This is a serious quesiton. The term "Concensus" has been 
bandied around like it gives one a moral right and its a "crock..." if you 
ask me.

>   be code.

No again, this causes problems for anything outside the list.

>   To start, this list should include at least the items

Likewise the external modification of Code should be done in the same 
manner. If someone wants to use an IETF standard they can, but the standard 
is a document. If someone wants to use the code the standard's 
interoperability was demonstrated with that is something that they should 
not get form the IETF but from the code owner. Otherwise the IETF winds up 
in the same position RSA was in with everyone licensing the BSAFE tool kit 
and then reimplementing it themselves from scratch.

>   which can be extract but not modified.

AHA - we admit that this is about LEGAL LANGUAGE finally...

>   willing to grant the same rights as for code to the entire document

This is a separate release which is executed at submission time. Why is this 
so complex?

>   additional licenses restricted the rights the IETF intends to grant

Then those licenses cannot exist. I dont mean they shouldnt be disclosed, I 
mean that the IETF cannot accept projects with IP constraints on them such 
that its licensing requirements cannot be fulfilled.

>   number of additional difficulties.

Like what for instance? You mean the model and template for the RFC and I-D 
may need to be revised again? Oh No....

>   Providing the correct legal
>   language is.

Funny I dont hear or see any IASA voices speaking for the IASA here.

>   Specifically, additional text in the document, and any

The those rights MUST be defined ahead of time or an informed consent cannot 
be properly documented.

> notice issue.

By running code you are referring to the externally referenced IP's right?

> I believe it would be useful to be able to include,
> e.g., code under the revised BSD license in an RFC.

Here again - the individual conveying those rights must have legal power to 
do so and in most all instances wont.

> That require

You mean "Requires" right...

---

From: "todd glassey" <[email-masked]>
Date: Wed, 24 Jan 2007 06:38:26 -0800

----- Original Message ----- 
From: "Simon Josefsson" <[email-masked]>
To: "Joel M. Halpern" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 24, 2007 1:12 AM
Subject: Comments on draft-ietf-ipr-outbound-rights-02.txt

This clearly wasnt done.

How about:

How about:

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 24 Jan 2007 16:29:13 +0100

> Comments on the entire document, quoted inline, below.

Great, thanks.  I use your quotes to add my comments.

>| boilerplate.  Similarly, legal issues of how to indicate usage
>| restrictions are left to the IASA and legal consel to determine.

s/consel/counsel/

 [URLs can be moving trgets and don't necessarily]
> preserve the appeal paths.

The document could state that they should preserve it.

>| There is rough consensus that it is useful to permit the quoting
>| without modification of excerpts from IETF Contributions.

An RFC shouldn't state "rough consensus", that's the job of the WG
Chairs or the IESG.  It also shouldn't claim that "there is rough
consensus" because that might be not more the case decades later.

How about "It is useful" or "It is at least necessary" (etc.) ?
 
> I suggest to replace 'These may be' with 'Examples include', as
> it is not clear that the list is not intended to be exhaustive

Apparently that's the case, and the IASA has to add items to this
list, plus catchall tags for other cases not in this list.

>| While there has been discussion of restricting the rights to
>| make such modifications in some way, the rough consensus is
>| that such restrictions are likely a bad idea, and are certainly
>| very complex to define.

Another dubious "rough consensus", and not something I recall.  The
discussion was about *allowing* a kind of "share alike" restriction,
and a poll resulted in a "clear tendency" to not offer that option.
 
The poll didn't examine the reasons like "certainly very complex to
define" or "likely a bad idea".   In the CC model it's not complex
to add a "share alike" to a given "CC-BY" resulting in "CC-BY-SA".

A simple fix could be to remove the complete statement, and let the
WG Chairs say something about the discussion in the questionnaire.

>| There is no consensus at this time to permit the use of text from
>| RFCs in contexts where the right to modify the text is required.

Third dubious "consensus", please let the WG Chairs state this.  The
RFC could say "At the time this document was written there was no
desire to force authors to permit" (etc.) or similar.

>| Specifically, additional text in the document, and any additional
>| license referred to by permitted additional text MUST NOT in any
>| way restrict the rights the IETF intends to grant to others for
>| using the contents of IETF contributions.

This MUSTard is new, and the intention is clear, but maybe it won't
always work as expected:

> I believe it would be useful to be able to include, e.g., code under
> the revised BSD license in an RFC.  That require adding a copyright
> notice.

Yes, if the additional restriction goes in the same direction as 5.2,
some kind of "CC-BY" by somebody else (= not the RFC author) in a
piece of quoted code or text.  The condition to quote it could be a
proper attribution.  And to quote it only with this minor restriction
(like 5.2).  That's not necessarily harmful, how about "SHOULD NOT" ?

Frank

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Jan 2007 11:15:20 -0500

While I may have been wrong, there is a reason the document refers 
repeatedly to the rough consensus.

At 10:29 AM 1/24/2007, Frank Ellermann wrote:
>Chairs or the IESG.

As editor, the rough consensus I capture in the document is the rough 
consensus determined by the chairs.  If I get it wrong, they tell me 
so and I fix it.  (And if WG members think I have made mistakes in 
capturing the agreement of the working group, they should say so 
promptly on the list.  Please, however, distinguish between cases 
where I have captured wrongly vs cases where you would like to see a 
different agreement from the rough consensus called by the chairs.)

And, when published as an RFC, this document will have gone through 
IETF last call.  It will therefore be the best we can manage at 
capturing the IETF rough consensus.

The reason I chose the wording referring to the rough consensus of 
the working group (both positive and negative) is that this document 
is intended to give direction to the trustees of the IETF Trust.  As 
such, I thought it was a useful part of that direction to actually 
capture in the document the basis for that direction.

If the working group prefers other language, I am happy to change it.

Yours,
Joel

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 24 Jan 2007 22:37:47 +0100

> editorial matters, I can not choose to make those changes.

You should read those parts as starting points for discussion.  Some
of the issues have, I believe, not been sufficiently discussed with
input from a diverse set of participants to make it possible to gauge
consensus.  My hope is that there will be input from several people on
each issue.

> While we could write the inbound rights document that way, I was under
> the impression that the agreement was that inbound would deal with
> contributors granting rights to the IETF, and outbound would deal with
> the IETF granting rights to others.  As such, I don't need to address
> a hypothetical more complex interaction between the two documents.

Sure.  It is the agreement on that you refer to which I'm questioning.
When was this discussed and consensus on the approach declared?  This
approach is against the spirit of RFC 3978.  As far as I understand
Jorge, he claims that third parties are granted rights to code
directly from the contributor by RFC 3978.  I don't see the problems
that justify changing that fundamental aspect.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 25 Jan 2007 08:37:20 +0100

> The document could state that they should preserve it.

I don't see how.  The current appeal path is conflated with documents,
a IETF last call and an IESG evaluation.  I'm not sure the current
appeal paths would apply to changes in legal text crafted by the IASA
and only published on their web pages.

There are no requirements to have notification of changes in the legal
text sent to, e.g., the ietf-announce mailing list.

> WG Chairs say something about the discussion in the questionnaire.

That paragraph may refer to an earlier discussion when some people
wanted copyright licenses for code in RFC to only apply to
implementations of the actual RFC.  Crafting such license text is
indeed difficult and likely a bad idea.

/Simon

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 26 Jan 2007 20:11:25 +0100

Joel M. Halpern wrote:
 
> the rough consensus I capture in the document is the rough
> consensus determined by the chairs.

Something's odd here.  As you said there will be an IETF last call,
and if the RFC is approved it's supposed to reflect the consensus
of the IETF, no matter how rough it was.  But you can't know that
already, unless your crystal ball is version 2.0 of my alpha 0.1.

When Harald wrote "clear tendency" I guess that's what he meant,
and if he interprets it as "rough WG consensus" he will say so in
in the questionnaire.

If you as author think that offering a "share alike" option is 
"likely a bad idea" and "certainly very complex to define", then
it's your opinion.  But I don't recall a "rough consensus" about
the reasons why folks don't want it.  E.g., Brian said that he
doesn't like viral licenses, so that's one possible reason.

Somehow an RFC talking about its own rough consensus is strange.
Maybe it's only me, but I prefer if that's decided in the future
IESG evaluation of a last call, and before in the questionnaire.
In a draft it looks like an attempt to forestall the last call.

> when published as an RFC, this document will have gone through

Yes.  When or if, but not necessarily before.  And then it's a
snapshot of the consensus at this time, but in the I-D you write
"there is" instead of "there was".

> this document is intended to give direction to the trustees of
> the IETF Trust.  As such, I thought it was a useful part of 
> that direction to actually capture in the document the basis
> for that direction.

Makes sense, but you could state it without using the magic word
"consensus".  Clumsy attempt:  "Proposals to allow restrictions
of this right were not adopted, because it was felt that they'd
result in too complex definitions".  Or maybe "the IPR WG felt",
but in some years nobody will know who that was, unless readers
dig in old WG archives.

Frank

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 29 Jan 2007 00:19:52 +0100

Frank,

> WG Chairs say something about the discussion in the questionnaire.

As chair, I've observed a number of people state that they would like to 
have some kind of restriction, and in every case, someone else has objected 
to that restriction.
In the few cases (like "you shouldn't use IETF code to implement a 
noninteroperable protocol and claim that it's the IETF protocol") where 
everyone agrees that it's a Bad Thing to do so, the discussion I've seen is 
that the cost of trying to write such a restriction is much greater than 
the benefit.

WRT the specific instance of "share-alike": Everything I've seen indicates 
that mandating share-alike for modifications to IETF code would be 
massively controversial.

                 Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 29 Jan 2007 00:23:35 +0100

Simon,

The plan to split into -inbound and -outbound is part of the WG's charter:

> The WG will produce 3 documents:
>
> - An update to RFC 3978 (BCP) that attempts to specify a complete set
> of rights with respect to derivative works granted to the IETF by
> authors, as well as technical updates necessitated by the existence
> of the Trust
> - A document (info) giving advice to the IETF Trust on what rights in
> IETF contributions it should attempt to grant to the public in order
> to retain change control while allowing open access, resolving the
> discrepancy between RFC 2026 and RFC 3978
> - A document (info) giving other advice to the IETF Trust on IPR
> handling, based on the IPR WG's experience of discussions in the area

I do not know any spirit (or letter, for that matter) of 3978 that would 
prevent such a split.

               Harald

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 29 Jan 2007 01:02:10 +0100

Harald Tveit Alvestrand wrote:
 
> As chair, I've observed a number of people state that they would like
> to have some kind of restriction, and in every case, someone else has
> objected to that restriction.

Yes, but the opposite was of course also true, everytime there was no 
restriction somebody proposed a restriction.  That's probably why you
started two polls about the issue until it was settled.

> Everything I've seen indicates that mandating share-alike for
> modifications to IETF code would be massively controversial.

My objection wasn't that you shouldn't try to determine some consensus,
my objection was that the draft tries this giving "bad idea" and "too
complex" as reasons.  If it would state that a "share alike" option
was dropped as "controversial" it would be okay.

Drafts talking about their own consensus are odd, that gives us three
kinds of consensus:  The alleged consensus in a draft, the consensus
in the questionnaire sent to the draft tracker, and finally an IETF
consensus determined in the last call.  If it's approved and somebody
would appeal it claiming that the rough consensus was too rough it's
not more obvious which consensus (s)he's talking about.

IMO "consensus" is a magic word, it's for WG Chairs, not for drafts.

And here it's merely a matter of wordsmithing, of course there was a
"clear tendency" in your poll.  Maybe it's only me, but when I read 
the first "there is consensus" in the draft I thought it's a paradox,
a crystal ball, or both.  And that first occurence isn't about the
optional "share alike" restriction.

Frank

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 29 Jan 2007 20:31:56 +0100

Harald Tveit Alvestrand <[email-masked]> writes:

> WRT the specific instance of "share-alike": Everything I've seen
> indicates that mandating share-alike for modifications to IETF code
> would be massively controversial.

I think the rules should allow WGs to make such a decision on a
case-by-case basis.  If the argument is that for patents, WGs should
be permitted to make decisions on a case-by-case basis, I believe WGs
should be permitted to make decisions to use material licensed under
the GPL or similar in a document.  If we trust WGs to make the proper
decisions regarding patents, why don't we do so for copyrights?

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 29 Jan 2007 20:36:00 +0100

>> handling, based on the IPR WG's experience of discussions in the area

Sure.  I see nothing here that would be in conflict with a rule
similar like RFC 3978 currently has that say third parties are granted
some rights directly from the contributor.

> I do not know any spirit (or letter, for that matter) of 3978 that
> would prevent such a split.

Jorge claims that RFC 3978 give third parties direct rights from the
contributor.  I haven't seen you challenge that interpretation?  Thus,
both the spirit and letter of RFC 3978 appear to be that contributors
grant some rights directly to third parties, without having those
rights go through the IETF.

/Simon

---

From: "Contreras, Jorge" <[email-masked]>
Date: Mon, 29 Jan 2007 14:39:54 -0500

> rights go through the IETF.

That's the current structure.  However, I believe the preferred approach for the updated documentation is that contributors grant rights to IETF Trust and IETF Trust grants rights to third parties.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 29 Jan 2007 21:48:32 +0000

On Mon, 29 Jan 2007 20:31:56 +0100

> decisions regarding patents, why don't we do so for copyrights?

For patents, the WG members are making individual decisions about
whether they, their employers, or (enough of) the community would
license the patent (or perhaps collectively choose to ignore it).  For
RFCs, the question is granting rights to the IETF's output.

Note that I'm not taking a position; I'm just explaining the
distinction as I see it.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jan 2007 14:20:16 +0100

> and only published on their web pages.

BCP 101 establishes an appeal path for IAOC decisions. Since Trustees
equals IAOC, we're covered.

> text sent to, e.g., the ietf-announce mailing list.

No, but failure to do so would breach the BCP 101 requirement for
openness, so would seem to be appealable. I don't think we need
microlegislation.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jan 2007 14:27:40 +0100

> Note that I'm not taking a position; I'm just explaining the

I think that's correct, but I'm willing to state my position:

I think that giving WGs the chance to debate copying and license
conditions each time would be an endless source of ratholing
and should be avoided. So I like the view that if a contributor
wants to grant *more* rights than the IETF, that should be
a matter entirely outside the IETF.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Jan 2007 15:31:18 +0100

On 2007-01-30 15:04, Simon Josefsson wrote:
> On Tue, 2007-01-30 at 14:20 +0100, Brian E Carpenter wrote:
> None of the appeal paths described in BCP 101 appear to have any powers
> over legal contract matters.  Which, when I read it, seems to include
> everything we are discussing here.
> 
>    In no circumstances may the IAB or
>    ISOC Board of Trustees overturn a decision of the IAOC that involves
>    a binding contract ...
> 
> As far as I can tell, the only body that can review the IAOC's behaviour
> related to contract matters is the IAOC itself.

I disagree with that interpretation. That clause was put in BCP 101
to protect contractors such as Neustar. I don't see how it could apply
to a general grant of license. It is of course correct that if the Trust
granted some right irrevocably, nothing anybody could do would
get that right back again - but we always have that problem.

> The IETF may have
> powers to replace members of the IAOC, however making appeal matters be
> conflated with personal considerations is in my experience extremely
> unfortunate and often leads to both hurt feelings and poor efficiency.

Sure, but it is the case that IAB, IESG and IAOC members are all aware that
we serve at the pleasure of the community.

     Brian

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 30 Jan 2007 18:32:40 +0100

Simon Josefsson wrote:
 
   [URLs can be moving targets and don't necessarily]

> and only published on their web pages.

In addition to Brian's comments, another example are the IONs defined
in RFC 4693, and RFC 4693 simply says:

| A decision by any other body than the IESG to approve an ION can be
| appealed to the IESG, in which case the IESG can nullify the approval.
| A decision of the IESG can be appealed using the common IETF appeals
| procedure, except that an IESG decision to nullify an IAB decision to
| approve an ION cannot be appealed to the IAB.

The idea of I-D.ietf-ipr-outbound-rights is that the IAOC or IASA (*1)
define the legalese, and update it when necessary.  The idea of the ION
experiment is to collect documents which are frequently updated.  

With that I'd think that the legalese could be published as ION, maybe
not yet because it's still an experiment, but later.  And for IONs we
have an appeal procedure.  The "outbound" I-D could copy the text from
RFC 4693 (mutatis mutandis).

> text sent to, e.g., the ietf-announce mailing list.

Let the I-D copy Harald's text in RFC 4693, that should be good enough.

Frank

*1:  At some point in time I'll learn what the difference between IAOC
     and IASA is.  Documents mentioning these beasts should provide a
     proper reference with acronym expansion on first usage.