Subject: WG IPR guidelines (draft-brim-ipr-wg-guidelines-00.txt)

From: John Klensin <[email-masked]>
Date: Sun, 13 Oct 2002 17:52:10 -0400

Scott,

Several comments, some trivial...

(1) Many of the problems with 2026 have been confusion about
rules intended to apply to patents and those intended to apply
to copyright (or inability to tell the difference).  I think,
given that experience, it would be useful to much more clearly
distinguish between "rights to [use] technology" (typically
patents, trade secrets, etc.) and "rights to text" (typically
copyright) in the abstract and in running text.  The note at the
end of the Introduction does not seem to me to be sufficient.

(2) In section 2, you list three IPR situations.  There is a
fourth, which should be listed if you are going to use that
style of presentation, even if the text then immediately says
that it is hopeless (which it may or may not be).  That case is:

	o An organization that does not participate in the IETF,
	but that monitors its mailing lists, drafts, and
	actions, discovers that evolving IETF work would
	intersect the organization's established intellectual
	property claims.  Rather than coming forward while the
	relevant standard is being discussed and evaluated, it
	chooses to lie in wait for the standard to be completed
	and implementation to begin, then springs up with
	infringement claims and demands for licensing and fees.

It happens.  We had best not ignore it.

(3) Under section 3, the introductory paragraph suggests that
the reader is using encumbered technology just to fetch and read
the document.   Well, not necessarily.  I can demonstrate
several ways to obtain and read a document that does not require
the reader to use anything proprietary, restricted, or
encumbered.  It is a nice story, but I'd recommend just dropping
it.

(4) At the end of 4.2, it might be worth commenting that PEM
ultimately largely failed, perhaps at least in part because the
encumbered technology, and the need to buy specific software to
implement the standard, was a bar to implementation and
deployment.

(5) In section 4.6, please consider adding something like the
following to the IDN discussion:

	In another case, patent claims were asserted that
	appeared to be derived from WG discussion and impact,
	rather than vice versa (or independent discovery).  The
	claimants were known to be following the WG's work when
	the ideas were proposed, and their patent filing was
	considerably subsequent to that time.

(6) Under 5.1, consider adding something like the following to
the discussion of copyright (since you are talking about US law
anyway):

	Current statutes provide for a very long period of
	protection.

(7) In 5.6, I don't believe that the well-known GPL fits into
any of these categories.  Instead, it is a specific grant of
rights, for no fee, but subject to a series of conditions  that
impact future work involving the technology.

(8) Also in 5.6, it may be worth adding something like the
following, after "not in this context", to the explanation of
RaND, to help clarify the difficulties with that approach:

	and, in particular, that "reasonable" and "fair" have
	sometimes been very expensive.  Also, companies have
	occasionally asserted that there were already sufficient
	licenses for a particular technology to meet
	"reasonable" multisource and competitiveness
	requirements and, hence, that refusing to grant any
	licenses to new applicants was both fair and
	nondiscrimatory.

(9) Editorial:

(i) In the first sentence of section 2, "the IETF has tried to
avoid".  We have not "avoided", as you point out elsewhere in
that paragraph and elsewhere.

(ii) In the paragraph past the bulleted items of section 2, "can
invoke, (about..." should not have that comma.  And perhaps the
parens should be eliminated -- that construction is not easy to
parse.

(iii) In 4.2, "and to prefer software sales to licensing" is not
clear to someone who doesn't know what happened.  I suggest
adding "that would permit others to produce independent software
that would implement the standard" after "licensing", which is
more or less the issue, I think.

(iv) In the second paragraph of 5.5, I can't parse the sentence
that starts "Anything a working group..."

regards,
     john

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

---

From: Scott Brim <[email-masked]>
Date: Mon, 14 Oct 2002 12:04:38 -0400

> end of the Introduction does not seem to me to be sufficient.

I agree in principle with the issue you raise, but I don't see which
note you're referring to.  Could you be more specific, and perhaps make
more specific suggestions?

> It happens.  We had best not ignore it.

Will add, with some rephrasing.

> encumbered.  It is a nice story, but I'd recommend just dropping

I'll probably get rid of it.  I think it's justifiable -- for example, I
suspect you used some kind of "Ethernet" to get the draft -- but it's
probably a distraction.

> implement the standard, was a bar to implementation and

OK

> 	considerably subsequent to that time.

I left some things out because the lessons seemed to be redundant, but I
think this would be fine.

> 	Current statutes provide for a very long period of

OK

> impact future work involving the technology.

Yes, a grant of specific rights was in there but got lost in the editing
somehow.  OK.

> 	licenses to new applicants was both fair and

I'll look for a place for this.  These bullet items were meant to just
list license scenarios, not discuss them too much.  The discussion is
supposed to be elsewhere.

> parens should be eliminated -- that construction is not easy to

OK to these

> more or less the issue, I think.

I hesitate to put my interpretation on the IPR holder's actions,
especially in a WG draft.

> that starts "Anything a working group..."

Try: Anything a working group adopts may, in the future, turn out to be
encumbered, although the encumbrance may not be discovered until years
later.

Thanks ... Scott

---

From: Scott W Brim <[email-masked]>
Date: Mon, 14 Oct 2002 14:47:02 -0400

> implement the standard, was a bar to implementation and

Did PEM "ultimately largely fail" because of IPR encumbrance?  Were
there other factors, and if so what were they?

...Scott

---

From: Robert Elz <[email-masked]>
Date: Tue, 15 Oct 2002 17:43:31 +0700

Date:        Sun, 13 Oct 2002 17:52:10 -0400
    From:        John Klensin <[email-masked]>
    Message-ID:  <9880030.1034531530@localhost>

  | (1) Many of the problems with 2026 have been confusion about
  | rules intended to apply to patents and those intended to apply
  | to copyright (or inability to tell the difference).

Be careful here.   Copyright affects the IETF (or could) in two
completely different ways.   First there's the "who owns our
documents and what can be done with them" issue, that occasionally
consumes so much time.

But there is also the possibility of the IETF standardising on
something which would require licensing of someone else's
copyrighted work to implement.

As a particularly silly example, were Shakespeare still alive
today (or more likely, were we working 400 years ago), and we wanted
to standardise an encryption technology that involved using a
copy of the Scottish play as a code book, then we would have exactly
the same kind of copyright IPR issue as we do with patents.

This one doesn't generally bother us (just as trade marks don't
often seriously bother us) as the issues rarely ever apply to
anything the IETF does.  But they're not some completely different species.

Don't be tempted to cut out copyright from the rest of the IPR
issues on the assumption that there is nothing in common.

  | (2) In section 2, you list three IPR situations.  There is a
  | fourth, [...]

  | It happens.  We had best not ignore it.

Actually, we probably should (ignore it).   Clearly there's nothing
we can do about organisations that aren't participating in the IETF,
whether or not they read IETF mailing lists.   The docs we write here
are to influence what the IETF does, and how we expect people to
operate.

Outside organisations can't be influenced by our RFCs in this area,
almost by definition, so we'd just be wasting time and effort trying
to think of what we could or should say about this.   Just ignore it.

  | (3) Under section 3, the introductory paragraph suggests that
  | the reader is using encumbered technology just to fetch and read
  | the document.   Well, not necessarily.

That's true, and perhaps that sentence goes just a little too far.
Rather than "you are using" it should say "you are probably using".

  | I can demonstrate several ways to obtain and read a document that
  | does not require the reader to use anything proprietary, restricted, or
  | encumbered.

I suspect it is possible, but I think you'd have to deliberately set
out and work hard to achieve that.   And work even harder if you wanted
truly unencumbered, and not just "used to be encumbered but the
monopoly has ended now".  Think fonts, copyright on the design of the
desk you're sitting at and the chair, paper making machines, LCD and CRT
screen technology, (even the transistor).

  | It is a nice story, but I'd recommend just dropping it.

I disagree.   I think it is important for everyone to understand that
encumbered technology is not necessarily evil, or impossible to use,
in any situation.   People should realise that they're doing it all
the time, and not just when they ignored the (old) RSA patents and
went ahead and used public key encryption anyway...

  | (7) In 5.6, I don't believe that the well-known GPL fits into
  | any of these categories.

It probably fits under the third, close enough anyway.   It is a
general "free" licence, that binds the user in some non monetary
way (just as the reciprocity form that the text mentions does).

But do note that this section is just giving generalities, it doesn't
need to precisely cover every individual case you can find.

kre

---

From: Scott W Brim <[email-masked]>
Date: Thu, 17 Oct 2002 12:17:02 -0700

> to think of what we could or should say about this.   Just ignore it.

On the contrary.  The point is precisely that we don't control what goes
on outside the IETF.  We're writing drafts to influence (guide) IETF
activities, and IETF WGs need to keep in mind that there are outside
organizations that don't have to follow any IETF rules.  It's important
to note these things, several times.

> went ahead and used public key encryption anyway...

KRE, are you suggesting that the weak sentence I had should be expanded
into a paragraph?

> need to precisely cover every individual case you can find.

I added a sentence to include it more explicitly.

...Scott

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Oct 2002 17:19:46 -0400

Scott (and others), 

Sorry for delay in getting back to this.  I'm rushing to get a
few other documents out, and it isn't, unfortunately, at the top
of my list.  Responses to comments below...

--On Monday, 14 October, 2002 12:04 -0400 Scott Brim
<[email-masked]> wrote:

>> copyright) in the abstract and in running text.  The note at
>> the end of the Introduction does not seem to me to be
>> sufficient.
> 
> I agree in principle with the issue you raise, but I don't see
> which note you're referring to.  Could you be more specific,
> and perhaps make more specific suggestions?

The "note" I'm referring to is the entire last paragraph of
section 1, where "encumbered technology contributions" are
explicitly called out.

Suggestion:

(i)	In the abstract, change "how IPR issues" to "how IPR
	issues, especially those concerned with encumberances on
	the use of technology".

(ii) Consider dragging most of section 5.2 forward into the
Introduction or problem statement.   Most of that text really
explains the problem, and the portion of it addressed in this
document, rather than giving advice to WGs (as the rest of
section 5 does). 

> Will add, with some rephrasing.

Good.  Incidentally, I agree with your response to kre's
comment: it is precisely because these things are not under our
control or within our scope to regulate that some comment about
them is important.  That WGs are not fully protected from
running into encumberances by following intra-IETF rules is, I
think, an important point to make.  Forcefully.

>> the reader is using encumbered technology just to fetch and
>> read the document.   Well, not necessarily.  I can demonstrate
>> several ways to obtain and read a document that does not
>> require the reader to use anything proprietary, restricted, or
>> encumbered.  It is a nice story, but I'd recommend just
>> dropping it.
> 
> I'll probably get rid of it.  I think it's justifiable -- for
> example, I suspect you used some kind of "Ethernet" to get the
> draft -- but it's probably a distraction.

Actually, I was handed the draft on paper, with the retrieval
and printing process carried out by someone else (whom I do not
pay or manage).  She may well have used encumbered processes,
but, "at the second" I was looking at and marking up the
document, I was reading words on paper.  That activity has not
been encumbered for some years.   This is obviously a quibble,
but, as you say, it is distracting.

>...
> I'll look for a place for this.  These bullet items were meant
> to just list license scenarios, not discuss them too much.
> The discussion is supposed to be elsewhere.

Understood, but, because we are often asked why we don't just
accept blanket RAND assertions in lieu of other, more specific,
statements, I thought it was worth being a bit more specific
about some of the reasons why RAND has fallen out of favor and
isn't a cure-all.  Just my opinion.

>...
>> (iii) In 4.2, "and to prefer software sales to licensing" is
>> not clear to someone who doesn't know what happened.  I
>> suggest adding "that would permit others to produce
>> independent software that would implement the standard" after
>> "licensing", which is more or less the issue, I think.
> 
> I hesitate to put my interpretation on the IPR holder's
> actions, especially in a WG draft.

I agree.  But I don't think I was trying to interpret their
actions.  The reality was, if I recall, quite clear: when
approached about licenses to develop software that used the
technology, their usual response (for some years) was "buy and
use our software, that is the only legal way to use the
technology".  If Jeff Schiller is following this discussion, I'd
like his input on what should be said.

>>, I can't parse the
>> sentence that starts "Anything a working group..."
> 
> Try: Anything a working group adopts may, in the future, turn
> out to be encumbered, although the encumbrance may not be
> discovered until years later.

yes, that does it. thanks.

On PEM, Christian's answer is far better than anything I could
have written.  It is why I used fuzzy language ("perhaps at
least in part...") in my suggested text, rather than making any
more specific statement.   Also, from one point of view, the
export restrictions were an IPR-like encumberance, with the US
govt asserting the rights, and they were definitely a problem
for some possible implementors and deployment strategies.  

I wonder whether the document should mention legal restrictions,
in one or more countries, on the use of a technology as
something a WG should consider.  Usually, such restrictions will
apply to all technologies that could meet a particular need, and
the principles that underlie RFC2804 would apply, but there may
be edge cases (e.g., restrictions on cryptographic technology,
but not on authentication technologies that do not have the
capability of encrypting data).

Robert Elz <[email-masked]> wrote:

>   | (1) Many of the problems with 2026 have been confusion
> about   | rules intended to apply to patents and those
> intended to apply   | to copyright (or inability to tell the
> difference).
> 
> documents and what can be done with them" issue, that
> occasionally consumes so much time.
> 
> today (or more likely, were we working 400 years ago), and we
> wanted to standardise an encryption technology that involved
> using a copy of the Scottish play as a code book, then we
> would have exactly the same kind of copyright IPR issue as we
> do with patents.
>...

I think this is absolutely right.  But, to me, it makes it even
more important that we be absolutely clear, in each of these
three documents, what we are talking about.  The suggestions
I've made about the current document don't talk about "patents"
versus "copyrights" but about "encumberances on the use of
technology".  The emphasis there is really on "use", not on
"technology" and would, I think, include kre's Shakespeare
example above (but clearly not the "who owns..." or "they stole
my words and put them in that document..." argument.
"Encumberances on the use of technology" is clearly not exactly
right... better words welcome, and perhaps a variation on the
two quoted paragraphs above actually belong in the document as a
hypothetical case (and perhaps a "lesson" that it is better to
use Shakespeare as a code book source than, say, the adventures
of Mickey Mouse (registered trademark, Disney ..., copyright
nearly forever).

best,
     john

---

From: Robert Elz <[email-masked]>
Date: Sun, 20 Oct 2002 22:16:16 +0700

Date:        Thu, 17 Oct 2002 12:17:02 -0700
    From:        Scott W Brim <[email-masked]>
    Message-ID:  <[email-masked]>

  | On the contrary.  The point is precisely that we don't control what goes
  | on outside the IETF.

OK.

  | KRE, are you suggesting that the weak sentence I had should be expanded
  | into a paragraph?

Not necessarily quite that much, but perhaps another sentence along
the lines of "It is not always the wrong choice to select encumbered
technology, if that is done knowingly, if after considering the
alternatives, and encumbrances, the encumbered technology appears to
be the best choice".

John - wrt that paper copy you were looking at, are you sure the paper
manufacturing process wasn't encumbered?  That a copyrighted font
wasn't used, that the ink to paper process wasn't patented, ...?
In our everyday lives far more things are paying some kind of royalties
than most of us ever imagine (often so small per use that we, as
individuals, also don't care).

kre

---

From: Scott W Brim <[email-masked]>
Date: Sun, 20 Oct 2002 17:23:23 -0400

> 	issues, especially those concerned with encumberances on

I can't see the usefulness of adding this text, either in the abstract
or in the last paragraph of section 1.  Working groups will only be
impacted by technology-related IPR.  That's all that will appear in
their umwelt.  Since they won't have to discriminate between
technology-related and non-technology-related IPR, adding the extra
words would just make the draft harder to digest without adding anything
useful.  IMHO.

> document, rather than giving advice to WGs (as the rest of

Yes, as usual, it was hard to take this mesh of memes and lay them out
serially.  I was trying to separate those which were pure problem from
those which helped deal with it, as well as keeping the introductory
setting up phase quite brief.

I'll add a few words to the early part, pointing out when IPR issues
might occur.  If those words aren't enough we can work out the text
at/after the Atlanta meeting.  

> like his input on what should be said.

OK, I've sent him direct mail.  I'm still doubtful about this.  If we
are going to say something specific about a IPR holder's behavior, then
we had better have all the facts and present a balanced view.  Doing so
is not easy, and I'm guessing the goal of the document can be achieved
just as well without going there at all.

> capability of encrypting data).

Very interesting thought.  In the past such restrictions did influence
how we did our work.  I can't think of a paragraph I would put in at
this time, but if you come up with something you think should be part of
our running code, pass it along.

...Scott