Subject: Status summary, IPR WG - Jan 17, 2005

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 17 Jan 2006 09:57:00 +0100

Trying to summarize the situation again, hopefully having refined the 
understanding of the issues somewhat:

>From the chairs:

We believe that this is a fair summary of where the WG is today:

- The IETF at the moment DOES NOT HAVE THE RIGHT to permit derivative works 
to be produced from I-Ds or drafts outside the IETF process. The authors 
have that right, but the IETF has not been granted it.
This is a fact, and not something the WG can change, even if it wishes it 
was otherwise.
- The IETF SHOULD ask for that right in I-Ds, and MUST ask for it in I-Ds 
that become RFCs. This is what Scott's draft should accomplish.

With regard to outgoing rights - granted by the IETF to the community:

- The IETF rights are administered by the IETF trust. The WG should strive 
to encode the community's guidance to the trust, not to draft legal 
language.

- The rights that we have consensus that the trust should grant to the
  community are:

  - The community MUST be able to access, copy and redistribute RFCs
    and I-Ds freely, including permission to prepare translations and
    reformatted versions.

  - The community MUST be able to extract code and tables from the I-Ds,
    and do the modifications needed to use them in implementations of
    the standard.

  - The trust SHOULD take steps to ensure that it's clear that modifying
    an RFC or a protocol and claiming that it's the "real" RFC or protocol
    is not permitted

- The points that we have heard in the discussion that "seem like good 
ideas", but without enough discussion to be able to claim that there is a 
consensus, include:

  - The trust should permit quotations from RFCs and I-Ds, with permissions
    at least as liberal as US "fair use", and easy to figure out

  - The trust should give clear guidance on labelling excerpts from RFCs,
    for instance by recommending "extracted from RFC XXX" on unmodified
    text, and "based on RFC XXXX" for modified text (if permitted)

  - It is important that authors know, when they submit contributions to
    the IETF, which rights they are granting to the IETF, and what they
    can expect the IETF to do with them

- The points that are still under debate include:

  - Whether or not permission to use code for other purposes than to
    implement the standard should be given - this affects whether or not
    the license granted by the IETF can be GPL-compatible

  - Whether or not all excerpts from non-code text should be permitted

  - Whether or not modified versions of excerpts from non-code text should
    be permitted

  - How to define the division between "code" and "text" (C code and
    MIBs are clearly "code"; ABNF and mapping tables may be)

  - Whether or not there are more categories of stuff than "code" and
    "text" (Ted mentioned mapping tables as a special case)

  - What it means to "modify" a standard

  - What measures are helpful to forbid modification of a standard;
    whether protecting the "RFC format" is sufficient to prevent it,
    or whether other measures such as field-of-use for extracts from
    code are relevant

  - Who should make decisions on licensing, if case-by-case decisions
    are permitted or desirable

Notes that may be important:

 - "fair use" is an US legal concept, and a fuzzy one. We'd like to
   make sure everyone, everywhere in the world has the same rights.

 - one fairly heavyweight means of separating "code" and "data" is
   to have the author mark them up in the document, perhaps even
   extracting the "code" bits at contribution submission time

Does this seem like a fair summary of the discussion so far?

                  Harald and Steve

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

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 17 Jan 2006 13:30:16 +0100

> Does this seem like a fair summary of the discussion so far?

All fine, especially explaining "fair use", I don't know this
concept.  But where are John's points about the expiration of
drafts, and ways for authors to select from various CC models ?

                             Bye, Frank

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 17 Jan 2006 14:39:55 +0100

In general I agree with this status summary.

However, the summary imply to me that this WG will separate the
license for code and text, and only focus on RFC/I-Ds and not
"Contributions" as specified in RFC 3978.  I believe it is
ill-considered to move forward with that approach without more
discussion.  The presentations we had in Vancouver was for
"Contributions" and they did not separate code and text.  I see this
separation as the first step to ignore the expressed concerns of the
Debian and FreeBSD communities.  Recall that both of these communities
has concerns with the *text* in RFCs, not the code.

In other words, if we only achieve what is stated below, it should not
be seen as resolving the problems some of the WG members has.

Thanks,
Simon

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

> - The IETF at the moment DOES NOT HAVE THE RIGHT to permit derivative
> works to be produced from I-Ds or drafts outside the IETF process. The
> authors have that right, but the IETF has not been granted it.
> This is a fact, and not something the WG can change, even if it wishes
> it was otherwise.
> - The IETF SHOULD ask for that right in I-Ds, and MUST ask for it in
> I-Ds that become RFCs. This is what Scott's draft should accomplish.
>
> - The IETF rights are administered by the IETF trust. The WG should
> strive to encode the community's guidance to the trust, not to draft
> legal language.
>
> ideas", but without enough discussion to be able to claim that there
> is a consensus, include:
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 17 Jan 2006 08:56:17 -0500

SImon,
     Given the difference in the degree of consensus, it seems clear to me 
that the working group needs to determine explicitly how it wants to treat 
code and how it wants to treat text (and whether there is a third 
category.)  The conclusion may be that we want to treat them the same 
way.  (I hope not.)  But to not allow such discussion would be 
inappropriate at this stage.
     You seem (both now and with the last summary) to be trying to prevent 
the working group from considering such a decision.    I hope that I am 
misunderstanding you.
     Yours,
     Joel M. Halpern

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 17 Jan 2006 15:06:20 +0100

Joel, yes, I believe you are misunderstanding me.  I definitely _wish_
that the WG discussed this more.  By declaring consensus on separating
text and code, which is done in this status summary, we likely won't
have any discussion on the principle around this choice.

I believe we need to establish consensus around how to separate
different kind of material in RFCs *before* we can establish consensus
around the license for each kind of material.

Regards,
Simon

"Joel M. Halpern" <[email-masked]> writes:

> SImon,
>     Given the difference in the degree of consensus, it seems clear to
> me that the working group needs to determine explicitly how it wants
> to treat code and how it wants to treat text (and whether there is a
> third category.)  The conclusion may be that we want to treat them the
> same way.  (I hope not.)  But to not allow such discussion would be
>     You seem (both now and with the last summary) to be trying to
> prevent the working group from considering such a decision.    I hope
> that I am misunderstanding you.
>     Yours,
>     Joel M. Halpern
>

---

From: Thomas Narten <[email-masked]>
Date: Tue, 17 Jan 2006 09:17:11 -0500

> that become RFCs. This is what Scott's draft should accomplish.

On the latter point, is there any reason not to state it as:

   - The IETF MUST ask for that right in "IETF Contributions"
     [RFC3978].

If something is to be worked on in the IETF, as part of an IETF
activity, the IETF should have full rights. This should be clear up
front, rather than only near the end process (i.e., when the document
is about to become an RFC). I'll note that the IETF has had problems
in the past in some cases where it become clear only after a WG had
invested time and energy on a document that the author was not willing
to cede full rights to the IETF.

Thomas

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 17 Jan 2006 15:42:37 +0100

> to cede full rights to the IETF.

When typing the "SHOULD", I was thinking of I-Ds that are published under 
the "no derivative works" clause - "for information only".
The IETF has previously declared consensus that this is a valid choice for 
an I-D author to make - section 5.2 of RFC 3978.

Personally, I'd not be unhappy to remove that part of our policy, but 
that's a change to a part of policy we haven't touched so far in this 
discussion.

                           Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 17 Jan 2006 15:45:20 +0100

> drafts, and ways for authors to select from various CC models ?

The first one isn't relevant to derivative works rights (I think).

I'm not sure what to say about the second one..... isn't our current idea 
that the author entitled to license his own work to the general public 
under any and all terms of his choosing, in addition to the rights granted 
to the IETF?

I've always felt somewhat confused by that, but that's another matter....

---

From: "todd glassey" <[email-masked]>
Date: Tue, 17 Jan 2006 07:11:15 -0800

----- Original Message ----- 
From: "Harald Tveit Alvestrand" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, January 17, 2006 12:57 AM
Subject: Status summary, IPR WG - Jan 17, 2005

> - The IETF at the moment DOES NOT HAVE THE RIGHT to permit derivative
works
> This is a fact, and not something the WG can change, even if it wishes it

If this is true then the IETF cannot possibly operate its Standards Track
since the SECOND PORT requirement would have to be licensed by the
submitters of the original IP one would think.

> to encode the community's guidance to the trust, not to draft legal

Then the TRUST is doomed. The IETF's community guidance is brain-dead at
least and has nothing to do with anything except individuals goals. This is
the problem with the structure of the wg - and Harald's commentary to simon
yesterday in re the Derviative Rights issues proves this commentary.

> - The rights that we have consensus that the trust should grant to the

I want to kill the word "RIGHTS" - what the IETF is doing is sublicensing
and there are a set of terms and conditions but these are not 'rights' per
se since they are all tied to the owner's having the legal authority to
submit the materials in the first place.

>     and I-Ds freely, including permission to prepare translations and

Why - What does this actually do for the IETF's Standards Process and the
advancement of processes within the IETF's Framework. No one to date has
answered this question at all - what does the IETF need external publication
rights for if it does not have a process for incorporating any of that
feeback into the Standards Process itself. So...

>     and do the modifications needed to use them in implementations of

I would agree - but this is specific to work within the IETF's Standards
Process - so why do these proposed rigghts have to extend outside the IETF?

>     an RFC or a protocol and claiming that it's the "real" RFC or protocol

This is a problem - the IETF is apparently setting itself up so that people
can reference its Standards Process documents outside of the Standards
Process - and the question is WHY? - this violtes the charter and intent of
the IETF and all of the processes it set up to date.

>     at least as liberal as US "fair use", and easy to figure out

Inside the IETF's Standards Process - sure... of course it should. But
outside the Standards Framework of the IETF, none of this makes any sense.

>     text, and "based on RFC XXXX" for modified text (if permitted)

This is an Excerpts Publishing commentary - and since its only used for
Standards Development, then there should be no problem with this.

>     the license granted by the IETF can be GPL-compatible

NO NO NO - No such release is in place for ANY of the materials submitted
through as current as yesterday to the IETF. The IETF is a Standards House
and not an IP Management Company, but if it wants to get sued liberally
through every pore in its body and most of the management's as well, keep
playing this game. You folks will leave the Standards Community no other
choice but to seek lititagation to prevent this nightmare from coming to
fruition IMHO.

>     MIBs are clearly "code"; ABNF and mapping tables may be)

Anything that is printed as IP and not as a program is text. Anything that
is printed as IP representing a set of stepwise processes is code.

>   - What it means to "modify" a standard

Standards are issued documents. Is the IETF claiming now that the Trust will
issue the standards?

>    make sure everyone, everywhere in the world has the same rights.

As long as those "rights" are pursuant to the creation of Global Standards.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 17 Jan 2006 16:21:19 +0100

> submitters of the original IP one would think.

Todd,

We're NOT TALKING ABOUT PATENTS.

---

From: "todd glassey" <[email-masked]>
Date: Tue, 17 Jan 2006 07:32:24 -0800

----- Original Message ----- 
From: "Harald Tveit Alvestrand" <[email-masked]>
To: "Thomas Narten" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, January 17, 2006 6:42 AM
Subject: MUST/SHOULD ask for rights (Re: Status summary, IPR WG - Jan 17,
2005)

> >> works  to be produced from I-Ds or drafts outside the IETF process.

Then the SECOND PORT License that is mandatory as part of the IETF's
Standards process has no basis either. That means that ALL of the IETF's
Standards issued to date may in fact violate the licensing granted and have
opened the IETF to litigation therein.

> >> The

No possible "Second Port" could be done without some license against the
core use of the IP. This is way beyond the reprinting rights use model.

> >> This is a fact, and not something the WG can change, even if it wishes

Does the phrase "MUST ask for" mean "MUST be granted"???

> > activity, the IETF should have full rights.

You mean to work product developed inside its process workflow... OK then
since this is all derivative works of the design submitted for
standardization, it is yet again, an instance where the IETF's standards
process MUST have derivative rights and cannot function without them.

> > This should be clear up

---

From: "todd glassey" <[email-masked]>
Date: Tue, 17 Jan 2006 07:35:05 -0800

Harald - for ANYONE to take a statement of design and implement a physical
protocol from it MANDATES that they have DERVIATIVE LICENSING for said same
protocol. So how does the IETF's process wherein the key milestone is TWO
INTEROPERABLE PORTS being implemented, deal with the actual coding and
implementation of that second port.

Seems to me that this is a Catch 22 that has endangered EVERY SINGLE
STANDARD issued to date.

Sorry - but IP law is what it is.

Todd

----- Original Message ----- 
From: "Harald Tveit Alvestrand" <[email-masked]>
To: "todd glassey" <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 17, 2006 7:21 AM
Subject: Re: Status summary, IPR WG - Jan 17, 2005

> >> This is a fact, and not something the WG can change, even if it wishes
it

---

From: Thomas Narten <[email-masked]>
Date: Tue, 17 Jan 2006 10:44:59 -0500

> an I-D author to make - section 5.2 of RFC 3978.

Right. This is a valid choice, but I don't consider these to be "IETF
Contributions" in the normal sense. They are not (normally) intended
to be adopted by the WG and further modified by the WG. But going back
and looking at 3978, I see that the term "IETF contribution" is not as
clear as I had thought.

What I think is adding to (at least my) confusion here is a lack of
better/clearer terminology. We need a name for IDs that are the
"normal" case. I.e, those that the IETF has the right to produce
derivative rights with, those that that a WG has (or would have) the
right to adopt and otherwise use, etc. This covers 99% of the IDs we
have today and is what we encourage people to submit. It would be nice
if our IPR documents could refer to these as the normal case, and have
exceptions called out, rather than have "IETF documents" include all
the exceptions, so that every usage of the term needs caveats to be
sure it explains which cases it is covering.

E.g.,  something like:

       IETF document - One that the IETF has full rights to [and maybe
           be explicit]. Only "IETF documents" are allowed to be WG
           documents. It is expected that the vast majority of IDs are
           of this form.

       IETF input - an ID that is being made available to the IETF for
	   limited consideration. (or some such). There are caveats
	   associated with this type of ID, such as no derivative
	   rights, no permission to publish as an RFC, etc. Such
	   documents cannot me adopted as WG documents without first
	   being made "IETF documents"

> that's a change to a part of policy we haven't touched so far in this 

I don't see the need to address this point here/now. But I think it
would be helpful to have better terminology so we all know what kind
of documents we are talking about w.r.t. IPR requirements.

Thomas

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 17 Jan 2006 16:44:56 +0100

[expiration of I-Ds]
> isn't relevant to derivative works rights (I think).

Possible, I think that it is relevant, but not necessarily
here.  Maybe it's an issue limited to "techspec" (IETF I-D
vs. non-IETF I-D) and "tools" (archive of I-Ds including
expired I-Ds).

There should be a way to submit non-IETF I-Ds intended for
RfC editor contributions, BCP 78 mentions this possibility.

 [CC]
> I'm not sure what to say about the second one.....

Nor me, but if authors could pick a single line boilerpolate
for simple cases in their I-Ds based on CC or similar models
it would be nice.

More verbose boilerplates for the complex cases are okay, but
IANAL, I've difficulties to understand the boilerplates as
they are.  They might say that authors promise that what they
submit is their own idea giving proper credits and references
(= not stolen), and that they have submitted any IPR claims
they're aware of.  Readers knowing or thinking that that's
not the case are asked to send their info to ipr@ietf.  Ideas
in a draft might be bogus, dangerous, and harmful, and in the
US THAT HAS TO BE SAID IN UPPER CASE, AND IT MEANS "YOU LOSE".

> isn't our current idea that the author entitled to license
> his own work to the general public under any and all terms
> of his choosing, in addition to the rights granted to the
> IETF?

How would he do this, pick the most restrictive boilerplate
for the IETF, and then override it by a pointer to CC-BY-SA ?

> I've always felt somewhat confused by that, but that's

...I prefer something that's less confusing, at least as an
option for simple cases.  If CC-BY-SA makes everybody happy,
author, reader, IETF trust, and RfC editor, then it should be
supported.

Apparently Simon would pick a bit more because "share alike"
might fail in a "desert island" test, and John could pick a bit
less, e.g. when it's the point of his draft to be ignored and
to expire, or when it's limited to derivative work by the IETF.

And I want to have it clear that it's my fault if I publish a
broken CRAM-MD5 procedure, not John's because he wrote the RfC,
and not Simon's because the bug was in my B64, not in his 3548.

                                Bye, Frank

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 17 Jan 2006 16:04:55 +0100

Agreeing unreservedly that the way forward is to treat the two separately - they
may merge again later but I see separation at this point as sound engineering -
I did encounter another example of (what I see as) code, namely most of RFC4134
Examples of S/MIME Messages, most of which I would expect to be fed straight
into a computer (or else a cure for insomnia:-)

I wonder too if code etc should be stored on a separate web site, in a easy to
use by computer form, headers and footers removed.  That would make it clear
just what was covered by whatever conditions are attached to code, should they
be different from those attached to text.  It would also make it easy to attach
something like
'By clicking on this to download, you agree to the following conditions ....."

Tom Petch

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 17 Jan 2006 10:33:26 -0500

In message <[email-masked]>, Frank Ellermann writes:
>concept. 

"Fair use" is a deliberately-vague concept in U.S. copyright law that 
allows people to use copyrighted material in certain ways, without the 
consent of the copyright owner.  Among the factors that are considered 
is how much of the work is being used, what the purpose of the copy is
(commenting on the copyrighted work is looked upon more favorably than 
just trying to make money by using it), what effect the excerpt is 
likely to have on sales of the copyrighted work, and more.  

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

---

From: "todd glassey" <[email-masked]>
Date: Tue, 17 Jan 2006 08:27:50 -0800

Scott I noticed that the process workflow is not described in any detail
beyond the high-level roles descriptions. From these, the actually Vetting
Pool was missing, as was the work-flow that they are to take to perform the
vetting that makes up the IETF's Standards Process. I dont think this was
cleaned up in BCP78 or BCP79 either

---------------------

2.4  The Vetting Team
===============
All "IETF Initiatives"** are vetted within the IETF's WG's. This vetting is
accomplished through active discussion and debate on  the WG's Mailing List
that is acting as a home for any specific initiative. Within each WG, the
"vetting teams" are established by the WG Chair or AD's responsible for that
WG.  The actual project plan and a Minimum Activity Commitment is produced
by the Sponsoring Individual or Entity, and submitted for review and
approval of the WG's Chair.

In all instances, Vetting Team's actions are to comply with the larger IETF
ethical mandate and be fair and open to all. In some instances where a group
of individuals has come together for the specific purpose of implementing a
protocol, then those groups are

To more fully facilitate this process, the steps to be undertaken in the
Initiative's vetting process are to be defined at the start of the
Initiative's project to create an IETF Standard.

2.4.1 Vetting Team Management
---------------------------------
The Vetting Team is generally lead or managed to some extent by the role
defined as the WG's "Document Editor" for any given IETF Initiative. This
leadership role is also often tied to the contributor to manage the
protection of their IP rights in the Standards Efforts that make up the
Vetting and Second Port Implementation and Interoperability Testing
processes.  See Section 2.3 of RFC2028 for more detail.

2.4.2 Team Size
----------------
The size of the Minimum Number of Vetting Participants in any given
Initiative is set by the Initiative's Sponsor and the IETF's WG' Chair in
their setting up the Initiative's Standards Run. In all instances a Vetting
Team must be equal to a minimum of four individuals. Vetting pool members
may also be transitory but at all times all vetting initiatives must have a
minimum of two members to be considered active. In the event that any
imitative drops below this minimum membership status, it is suspended for 1
IETF meeting cycle and then if no more members join in, it is hibernated
indefinitely until such time as its membership picks up and meets the
Initiative's Minimum Activity Commitment.

2.4.3 Team Records Keeping
------------------------------
In all instances, all materials whether submitted through the mailing list,
or off-list through those agreed upon project participants, would be
disclosed to the WG Chairs as part of the process of "turning the Vetting
History for each Initiative over to the IETF/IESG" as part of its periodic
and standard's compliance petition.

-------------------

** an IETF initiative does not necessarily have to be a Standards
Initiative, but could rather be a Best Current Practice or other IETF
Document. The process flows are adjusted as necessary since BCP's will not
likely have a Second Port and Interoperability Testing requirement like a
Standard's Initiative would.

----- Original Message ----- 
From: "todd glassey" <[email-masked]>
To: "Harald Tveit Alvestrand" <[email-masked]>; "todd glassey"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, January 17, 2006 7:35 AM
Subject: Re: Status summary, IPR WG - Jan 17, 2005

---

From: "todd glassey" <[email-masked]>
Date: Tue, 17 Jan 2006 08:33:22 -0800

Tom this would change the fundamental structure of the I-D and RFC document
and what they contain I think. It also STILL doesnt address that the IETF's
Standards Process MANDATES a second Interoperable Protocol be built by one
of the parties involved in the Initiative... and without the Derviative
Rights no one can legally claim that they have the right to implement that
instance of that protocol.

Todd
----- Original Message ----- 
From: "Tom Petch" <[email-masked]>
To: "Harald Tveit Alvestrand" <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 17, 2006 7:04 AM
Subject: Code and notcode was Re: Status summary, IPR WG - Jan 17, 2005

works
it
> > - The IETF SHOULD ask for that right in I-Ds, and MUST ask for it in
I-Ds
> > - The IETF rights are administered by the IETF trust. The WG should
strive

---

From: "todd glassey" <[email-masked]>
Date: Tue, 17 Jan 2006 08:36:49 -0800

Sorry there was a typo in the orig.

----- Original Message ----- 
From: "todd glassey" <[email-masked]>
To: <[email-masked]>; "Scott Bradner" <[email-masked]>
Sent: Tuesday, January 17, 2006 8:27 AM
Subject: in Re 2028 wording

> protocol, then those groups are to operate as such, but in all instances,
they
> would be open to external participants.
>

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 17 Jan 2006 11:54:18 -0500

>Sorry - but IP law is what it is.

I first saw this concept proposed about 25 or 30 year ago.  As 
best I can tell, it's never gotten any traction.  Please cite a 
recognized *legal* source for your interpretation of copyright law or 
drop it.  You've posted the same argument at least 4 times between
7:11 AM PST and 8:36 AM PST.  Even if you're right -- and again, please 
come back with citations to court cases or peer-reviewed legal articles 
-- posting the same thing that many times within 1.5 hours is too much. 
Please stop -- now.

---

From: "todd glassey" <[email-masked]>
Date: Tue, 17 Jan 2006 09:08:59 -0800

----- Original Message ----- 
From: "Steven M. Bellovin" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Harald Tveit Alvestrand" <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 17, 2006 8:54 AM
Subject: Re: Status summary, IPR WG - Jan 17, 2005

> best I can tell, it's never gotten any traction.

You mean traction from the technical people this would be a threat to - is
it any wonder?

> Please cite a
> drop it.

How about Paul Goldstein's "Copyright" - its worth reading. BTW - Larry
Rosen ought to know of Paul, Professor Goldstein is one of the cornerstones
of Stanford's Law School.  But this is really a no-brainer... and there is
other case law about the issuance and use of derivative rights.

>  You've posted the same argument at least 4 times between

Try this link which is a discussion of rights and their basis.
http://www.debate-central.org/topics/2005/LINKS/individual.html

or this one http://www.bitlaw.com/copyright/scope.html  - Note the
discussion of Derivative Works under US Copyright Law.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 17 Jan 2006 21:47:21 +0100

Steven M. Bellovin wrote:
 
> "Fair use" is a deliberately-vague concept in U.S. copyright
> law that allows people to use copyrighted material in certain
> ways, without the consent of the copyright owner.  Among the
> factors that are considered is how much of the work is being
> used, what the purpose of the copy is (commenting on the
> copyrighted work is looked upon more favorably than just
> trying to make money by using it), what effect the excerpt is

Thanks for info, apparently a concept also known in Germany:

Citations are okay, and there's more leeway for educational
purposes.  Private copies used to be okay, the usual battles
about this, laws constantly changing, fights also on the EU
level.  But nothing to wory about from the POV of I-D or RfC
authors as far as I can judge it (= not at all).  Bye, Frank