Comments on minutes

I didn't attend the IPR WG meeting in Dallas, but I wish to comment
what was said there.  Hopefully this will serve to move discussions
from the meeting back to this list.

I have inferred from Todd's posts, and the comments to his posts, that
it is not good style to post several messages to this list in the same
day, so I felt urged to post this as one large message.  Please
forgive the size of this.  I hope my issues and questions won't be
unanswered because of this...

> IPR WG MEETING MINUTES: March 21, 2006, 13h00 - 15h00 local time
>
> 13h00 - 13h10: Introduction and Charter Status Update
> Harald welcomed everyone, and made the following introductory remarks:
> -	the IPR WG is about intellectual property rights as handled by the IETF
> -	it is *not* about what goes on outside the IETF
> -	it is (in some cases) about making sure the IETF does not get entangled in things that are none of the IETF's business
>
> The agenda was accepted without bashing. Ed Juskevicius was volunteered to scribe these minutes.
>
> 13h10 - 13h25: `RFC 3978 Update', presented by Scott Bradner
>
> - The purpose of this document ((draft-ietf-ipr-rules-update-03)
> came originally out of an IPR WG meeting we had quite a while ago
> where the consensus was `the IETF should ask for additional rights
> from the submitters of contributions to the IETF'.  The additional
> rights are for 3rd parties to make extracts of any kind (e.g. to
> copy pieces of IETF documents and include them in documentation, or
> on a web page)

Scott's current draft (which is -04, not -03, btw), does not grant
those additional rights for 3rd parties, as far as I can see.  I think
this gives a flawed representation of what Scott's draft would solve.

> - There was not a consensus about whether the IETF should allow 3rd
> parties to make derivative works

This suggest to me that this issue is now closed.  Is this the case?

> We have had a test case on this. The IETF would like the IEEE to
> take over the development of Ethernet MIBs, but we don't have the
> right to say (to the IEEE) `just go do that' because we did not get
> that right from the original contributors, so instead what needs to
> be done is that the original contributors have to be asked if it is
> OK to go and do this.
>
> Also, the IETF Trust was created in December 2005, and has been
> acknowledged in the update document. The update also includes some
> discussion of outbound rights and inbound rights, plus a definition
> of the term `IETF participant' (because it is used in the document).
> We probably should remove the outbound rights from this document,
> and put them into Joel's document.

I support separating inbound and outbound rights.

> The other open issues with the document are:
> -	What are we trying to accomplish with the copyright statement?
> o	What is it for, and is it needed?
> -	Should the document focus only on inbound rights?
> o	What is the definition of inbound rights in this context?
> - How do we proceed?  Do we do this as a delta to RFC 3978, or do we
> put out a revised RFC 3978? Scott hopes we agree to do the latter.

I believe we should add this open issue too:

o Should non-IETF Trust copyright notices be permitted?

I think there are good reasons for permitting this, and we've seen
little discussion on this point.

> Discussion:
>
> David Black:
> I want to confirm the only piece of this that will be moved into
> Joel's document is section 5, namely `rights granted by IETF Trust
> to third parties', and that section 4 (`rights granted by the IETF
> Trust to make the IETF operate') will stay in this document.
>
> Scott Bradner:
> I think that's an open question. My proposal is to do it that way.
>
> David Black: 
> I concur with that proposal. Harald, do you want to do something about this?
>
> Harald Alverstrand:
> I'll take that under advisement after this discussion is over.

I don't support this.  I believe it is better to separate inbound and
outbound rights completely.

I believe introducing the term "IETF participant", and consequently
creating three legal systems for 1) the IETF Trust, 2) IETF
Participants, and 3) third parties, is unforunate.  I believe 2) and
3) should be treated the same way.  The legal language can grant
certain rights for third parties conditioned on whether their
derivative work is part of the IETF Standards Process or not.

> John Klensin:
> These regular revisions to IPR statements have got to stop. It is
> pretty clear that we have two interrelated problems with 3978.  The
> successor to 3978 has to be ridiculously painfully clear about when
> it is talking about copyright, and when it is talking rights to do
> with underlying intellectual property.

I agree.  I believe doing this work as a delta will be confusing and
unclear.

> Also, our copyright notice situation, especially for internet drafts
> (I-Ds), is `muddled' (to put it politely). We might need to separate
> the material we want placed into I-Ds and the material we want
> placed into RFCs in a more fundamental way than before. We need to
> be certain we don't make claims to rights that we do not have. We
> need to focus here (and on the mailing list) on what we are trying
> to do, versus trying to outguess the lawyers.
>
> Jorge Contreras (the IETF's lawyer):
> One problem, which is easy to fix, is that RFC3978 calls for every
> document to have to have 2 copyright notices: a plain copyright
> notice with the year and name of organization (i.e. ISOC or IETF),
> plus another with some explanatory text. There is no real need to
> have two. All standards documents are works of authorship, so adding
> an explicit copyright notice on them is not actually needed. It
> would be enough to just have one copyright notice.
>
> The purpose for putting a copyright notice on a document is to
> notify the world that a certain organization thinks it has rights,
> and also because the having the notice on a document is necessary
> (in U.S. courts) to enforce those rights against certain types of
> damages.
>
> Copyright can protect many different aspects. In the IETF process,
> the ownership of the text in an I-D is retained by the author. It is
> not assigned to the IETF. It would not be correct for the IETF to
> say it owns all of the text in an RFC or in an I-D.
>
> The aspects which the IETF (or the IETF Trust) does own are:
> -	the organizational structure of IETF documents (i.e. RFCs and I-Ds are somewhat unique in how they are put together),
> -	the boilerplate text on all RFCs, and
> -	the RFC numbering series (from RFC0001 to RFC4000 ...)
>
> The naked (simple) copyright notice (that we put on documents today)
> might imply to some readers that the IETF `owns' more that it
> actually does, and that would be inaccurate.  This problem is more
> pronounced with I-Ds.  Several elements (that the IETF could claim
> ownership of) are not present in I-Ds (e.g. I-Ds do not have an RFC
> number).  An I-D, as contributed by an individual person, does not
> go through the whole IETF process. Other than the boilerplate text
> and the structure of the I-D, there are not that many copyrightable
> features in an I-D.  So a good question is `What does the copyright
> notice on an I-D actually mean?'
>
> Simon Josefsson (via Jabber): 
> Why are additional copyright notices not allowed?
>
> Scott Bradner:
> We had a number of specific instances where individuals wanted to
> put their own copyright notice on an RFC.  It was felt that would
> add confusion, especially if the individual was one of several
> authors, or the editor of a WG document (where the WG had made
> significant changes to the originally contributed I-D), so we made a
> requirement that someone who wants to put an additional copyright on
> a document needs to seek permission on a case-by-case basis to do
> that from the IAB, rather than automatically having the right to do
> so.  The only cases that I know of, where we have allowed other
> copyright notices, have been where the IETF has republished
> standards from other organizations.

There are more examples of this, see RFC 4122.  As far as I am aware,
IAB was not consulted.  This suggest this problem is not that serious
to warrant forbidding it.

> David Black:
> If the IETF was the exclusive owner of the boilerplate text and the
> RFC structure, that could be a good way to stop fake I-Ds!

The IETF _is_ the exclusive owner of the boilerplate text and the RFC
structure, as far as I know.  I agree it is a good way to stop fake
documents, and probably good enough.

> John Klensin:
> I think we have got to get over trying to fine tune this stuff over
> theories that have no legal basis. If our purpose in having a
> copyright notice is to protect the boilerplate, then that needs to
> be clarified.  Right now, the copyright notices seem to claim
> ownership for the entire document.

I agree here.  I know of several examples where people have
interpreted the ISOC copyright to mean that ISOC own the copyright on
the text.  Some RFC authors have even denied granting more rights to
their own RFC text because they believe ISOC now owns it.

> David Black:
> To violently agree with John, I think the goal is to put what
> amounts to an obvious legal hurdle in front of those who would
> create fake RFCs. It should be clear to someone who intends to
> create a fake RFC, that doing so would be violating a copyright.
>
> Harald Alvestrand:
> The required copyright notices should claim something that is
> legally defensible. There are pieces of I-Ds that we require to be
> there, but exactly how to phrase the copyright notices for those
> pieces is lawyer bait.
>
> Joel Halpern:
> We need to be clear on several things. Any copyright statement needs
> to be clear on what it covers, and what the objective is on putting
> copyright notices on RFCs and/or on I-Ds; maybe we don't need one on
> I-Ds, but we do on WG ones etc. Let's be very clear on what we need,
> and then be really crisp on how we will accomplish it.

Agreed.

> John Klensin:
> In the RFC case, it might be possible that the RFC Editor creates a
> derived work (based on what the authors put in, plus everything we
> put in, plus the editing done by the RFC Editor) where ISOC or the
> IETF Trust would want to copyright the whole thing. But that would
> violate our principle that authors retain ownership of their text in
> RFCs and I-Ds.
>
> Scott Bradner:
> The process by which we create a document is a collective work, and
> I don't think we can make a decision today on what we need to do. I
> agree with Joel that we need to crisply figure out what we want to
> do, and then do it.
>
> Harald Alvestrand:
> The copyright statement issue needs further work, both to clarify
> what we need and how to do it. So that goes to the list.
>
> Stephan Wenger:
> Is there a desire to reduce the two copyright statements in
> documents to a single one?
>
> Harald Alvestrand:
> Does anyone see a value to having a maximum of one copyright
> statement on documents? (Several people raised hands to indicate
> `yes').

I disagree with this, and I believe there are several reasons for
permitting multiple copyright statements in documents, and few reasons
to disallow it.  I'd like to see this discussed more.

> Once we get to designing a new boilerplate around these principles,
> it seems that it should only be going in one place.  From our
> discussion here today (from the list), I think there is support for
> putting all of this in a new `3978bis' rather that a
> deltas to 3978' document.
>
> Lucy Lynch:
> As an IAOC Member and IETF Trustee, I'd like to ask what your
> timeline is for a new document vs. a delta document.  The Trust is
> transferring new IPR to the IETF every three months.
>
> Harald Alvestrand:
> I don't believe there is a significant difference.
>
> Sam Hartman:
> On the outbound rights question, I think it would be simpler if all
> of the outbound rights were pulled including line 4 (`rights granted
> by the IETF Trust to IETF participants'), but I don't really feel
> strongly about pulling line 4.

I agree with Sam here.  Because the text is tentative, doing this will
give us time to really sort out what text we want too.

> Harald Alvestrand:
> OK, we have three different proposals:
> 1)	3978bis is only inbound;
> 2)	3978bis is inbound plus rights granted to IETF participants as they are participating in the IETF;
> 3)	3978bis contains inbound rights to participants and rights to non-participants

My vote for 1, although I disagree about separating 2 and 3.  I
suggest treating IETF participants and third parties the same way.  If
there is a need to grant some right only to a third party when he
publish it with the IETF, write it explicitly rather than inventing
three legal bodies and related rules.

> Scott Bradner:
> I believe 3978bis should include all rights needed for participants
> in our standards process. I do not believe it should include
> outbound rights to third parties. I think that should be governed by
> a different document that instructs the IETF Trust on what it should
> do.
>
> Ted Hardie:
> I think the implication of that is that we have to grant rights to
> everybody because implementation is a requirement for the standards
> process. Therefore we may have to do outbound rights. There are
> documents we write for which one of the outbound rights required to
> do an implementation is an outbound right to use an extraction a
> table, or something similar like a MIB.

Ted's point is important.  I believe grants must be granted to
everyone in order for IETF documents to be useful.

> Joel Halpern:
> We have to talk about rights granted to implementers in an outbound
> document. We are going to grant some rights to all
> implementers. Even the rights to work on a document here (in the
> IETF) are technically going to be granted to us by the Trust,
> according to what we ask the Trust to do, so we have to the Trustees
> (who we have put into the middle of our process) what we need.
>
> Scott Bradner:
> If we have an outbound rights document, it will need to grant the
> right licenses to people who want to implement an RFC.  I don't
> believe the outbound rights document can be an informational
> document.  We will need it to be a standards document (i.e. a BCP)
> for what we need in order to implement our standards.

Agreed, outbound rights should be part of BCP 78.

> Jorge Contreras:
> From RFC2026 and onwards, contributors would grant rights to every
> IETF participant in the IETF process. Now we have the IETF Trust. It
> is just a technicality that we now have an IETF Trust which is
> interposed between contributors to the IETF and participants who we
> grant rights to, as the Trust simply passes everything along to the
> participants. I am not sure it is accurate to call that an outbound
> license right.

I agree the situation is unclear.  That's I believe the new idea of
granting rights to 'IETF Participants' is a poor one.  Instead, grant
rights to third parties, and when required, restrict them to be within
the IETF Standards Process.

> Harald Alvestrand: 
> Should outbound rights granted to participants in the IETF process be:
> - in a 3978bis document?
> - in the outbound rights document?
> ** 3 people raised their hands for 3978bis (including the IETF's lawyer)
> ** 5 people favored in the outbound rights document (not including our lawyer)
>
> Harald Alvestrand:
> *** Let's take this to the list as *unresolved*.

As above, I propose to abolish this particular "outbound" rights
completely.  It confuses things further.

> Now, switching to "outgoing rights" (at 13h47)
>
> Harald Alvestrand:
> The outgoing rights are the rights granted to the IETF Trust, and
> administered by the IETF Trust in how they are granted to
> participants and non-participants in the IETF.
>
> Lucy Lynch:
> There is now a website which will move to trust.ietf.org, containing
> all documents signed on Dec 15, 2005 and the Trust FAQ. In addition,
> we are making a quarterly transfer now from ISOC to the Trust of
> RFCs being lublished with the old footer text in place, and we are
> working on licensing for language for things like marks (like the
> one you saw this week for IETF@20). Another thing on the website are
> our operating procedures, which confirm we agree to be bound by the
> RFC/BCP that dictates the behaviour of the IAOC.
>
> Joel Halpern:
> Simon Josefsson sent some very nice comments which will be
> incorporated into the outgoing rights document. The document is a
> whole lot of 'this is the situation' and 'here are the topics' but
> not very much meat under many of them right now. The current
> organization is merely because we need some sort of structure to
> start with.
>
> Harald Alvestrand:
> The issues that have been raised against the outgoing rights draft and which have made it to the issues tracker are:
>
> #1166: Quotations from RFCs and I-Ds, what should be permitted?
>
> #1168 Should all excerpts from non-code parts of RFCs and I-Ds be permitted?
>
> #1169 Should modified excerpts from non-code be permitted?
>
> #1167 Should there be rules for how excerpts (modified/unmodified) from RFCs and I-Ds are labeled?
>
> #1175 How can code be distinguished from non-code?
>
> BCP78, as written now, actually makes the code/non-code
> distinction. There are rights which are granted to the IETF in code
> that are not granted for non-code. The issue is should we continue
> that distinction or not.

The distinction is subtle, and the distinction between code and
non-code is not that clear.  For example, it is not clear whether C
source code would apply.  Look at how 5.6 of BCP 78 is phrased.

> Discussion:
>
> Brian Carpenter:
> Am I correct in thinking that the way BCP78 is written means people
> agree with outbound rights by submitting things to the IETF? Does
> the word IETF (in BCP78) already include the IETF Trust?
>
> Jorge Contreras:
> No. The definition of IETF in RFC 3978 would not include the Trust.
>
> John Klensin:
> There is a piece of this process which is not included: our shrink
> wrapped "Note Well" licensing (that comes into play when you walk
> physically or virtually into the door here) may be more important
> than all of the copyright text dance we are doing now
>
> Ted Hardie:
> Can I confirm we are talking about 3.3(3) for code/non-code?  That
> references section 5 is this NOT a solved problem?
>
> Harald Alvestrand:
> I agree this is not a solved problem
>
> Kurt Zeilenga:
> What outgoing rights are you trying to grant which are not
> inherently there via `fair-use'? For example, why do we have to
> grant a right (explicitly) for quotations? What rights are in here
> that are not inherently granted already by fair-use?

For example, ASN.1 and C source code.

> David Black:
> MIBs are a counter example: the amount of a document you need to extract to compile a MIB easily exceeds `fair-use'.
>
> Sam Hartman:
> I am here today as an implementer. As an implementer who ships a
> product that incorporates IETF standards and that is used by people
> with a lot of different licenses, my really hard requirements are:
> 1)	I need all the rights I have independent of any claims of fair-use;
> 2) For any code I use in a product, I need the right to distribute
> that code under a license that is GPL compatible (and licenses that
> are much more liberal than the GPL), because some people who use my
> code (and thus IETF standards) ship GLP'd stuff and they can't ship
> my code unless it can be distributed under GPL.  The reason I need
> more liberal rights is because I have people who want to ship things
> under the BSD license.
> 3) I'd really like the ability to distribute RFCs as part of my
> documentation, both whole RFCs and extracts.

I have similar needs.

> Jorge Contreras:
> Fair-use in the US is pretty limited (e.g. to pure research,
> education, parodies), and it is pretty unlikely you would be able to
> claim fair-use for commercial implementation of something, even it
> is limited to just a small piece of code.
>
> In the license grant from contributors, the license is granted to
> the IETF (which means all of its participants and that does not
> include the Trust) but the license is also granted to ISOC, which
> once a quarter will be transferring all of its rights to the Trust,
> so the IETF Trust will end-up with all of these inbound rights from
> contributors, through the assignment from ISOC.
>
> Joel Halpern:
> We need to spell out what we want to grant, in English, so we
> understand it.  When we are done, if the lawyers then say `Oh, that
> piece that you have asked for is covered by technique x and that
> other piece is covered by technique y, OK'. I need to know what we
> are trying to do.  Until we can agree on what we want, and until we
> can write that into the outbound rights document, we will not get
> anywhere, and there is significant disagreement about what we want.
>
> Kurt Zeilenga:
> We have a lot of documents that have been published, we'll have a
> problem making rights changes retroactive.
>
> Harald Alvestrand:
> We will not restrict rights that you currently have.  The issue of
> granting more rights than you currently have to the old RFCs is a
> problem that we have to address.
>
> Kurt Zeilenga:
> I guess I disagree that we don't have the rights necessary to pull
> ASN.1 out of 2251 and implement LDAP.  I think we have the right to
> do that.

Lawyers are telling me that I don't have this right.

> Thomas Narten:
> There is disagreement over this.  We don't have agreement.

Right.

> Harald Alvestrand:
> The statements that exist now are *not* clear. This is proved by
> people who have different beliefs about what the current rules
> say. We know the current rules are unclear. We want clear rules.
>
> Brian Carpenter:
> There are people whose readings of the GPL say it is incompatible to
> take code out of an RFC and stick it in GPL'd code. There are people
> who disagree with that assertion. Both views are strongly held.

Huh?  Who claims that taking code from an RFC and put it into GPL code
is legal?  The FSF has said that the RFC 2026 and RFC 3978 license is
incompatible with the GPL.  I believe it is fairly obvious that the
licenses are incompatible, and don't recall seeing anyone who strongly
thought otherwise.  Could you give a reference for this?  I think this
gives a false representation of the current discussion and problems.

> Stephan Wenger:
> I have a suggestion. I don't believe the one-size fits all approach
> designed by this WG will work. I think they are very viable cases
> where we want to make large parts of non-code excerpts from an RFC
> possible. I believe there are cases where the IETF should keep full
> control over every letter in an RFC, and I don't think the IPR
> working group can make an informed decision here.
>
> I believe that the technical WGs are be in a position to make
> informed decisions, but they probably would not like to do so
> because it would make them worry about legalese.  Even so, a
> solution would be to have technical working groups tag which parts
> of which RFCs can be granted outbound rights, and for the rest, you
> have no rights to take anything from it.

This may be true.  It creates a lot of complexity...

> Harald: The personal opinion of the Chair is this is an instance of
> passing the buck. I would like to have you specify the specific
> use-case (with draft name and section number) because the abstract
> can not be argued about. Specify at least one case where you think a
> WG should make this specific distinction and tell us why. On the
> list, please.

See section 5.2 of draft-ietf-dnsext-rollover-requirements-00.txt and
the rather long discussion of this in the DNSEXT WG.

> Ted Hardie:
> Simon Josefsson has sent me a draft for me to sponsor as an
> individual submission where he has put forward a license to the
> parts of the work which are his work, where he grants additional
> rights beyond those which are required that essentially translate
> into `do ye as ye will'. I think that's a workable solution on a
> draft-by-draft basis, but I don't think we can pass the buck to say
> that's what has to happen on every draft. We need to have the
> minimum understanding of what the outbound rights the IETF may
> always grant are, or we have no mandatory to implement'
> here. We'll lose, very quickly, real technical work to amateur
> lawyering in technical WGs, so passing the buck on this is not a
> good idea.
>
> Scott Bradner:
> I fully agree. We have running code on this. We have some RFCs where
> individual authors have granted that kind of `do ye as ye will'
> rights and we know it can actually work.

I agree that passing the buck on this is not a good idea.  Some WG's
are not educated on these issues, and probably doesn't want to be, and
we shouldn't force this down the throat.  The solution is to grant the
rights needed for third parties to implement standards and use the
specification as part of the manual.

> Harard Alvestrand:
> I think we have a claim that is running code and current practice,
> but let me check that this is what we want.
>
>    `Author can put into RFCs text that gives more
>     permissions to stuff in the RFC than the IETF
>     normally grants, and that's OK'
>
>   Who agrees?  10 people (raised their hands)
>   Disagrees?  ½ of John Klensin

I agree too.

However, it is unfortunate if this needs to happen frequently.  Then
it is better to revise the generic outbound rights license.

> Joel Halpern: 
> There is a more basic issue. We have before us a set of requests for
> a consistent policy that is arguably more that the policy we have
> had until now, and that will apply to all documents, and we don't
> have rough consensus on what our consistent policy is yet. We need
> to spell-out for both code fragments and non-code fragments what we
> want to require as the consistent policy for everybody, even if we
> allow some authors to grant more liberal rights (but never fewer
> rights).

I believe separating code and non-code leads to more complexity, that
does not help solve to the problems I've raised.

> Thomas Narten:
> Does an author have the ability to grant more rights in a collective
> work, where it's unclear where all the text comes from?

Legally speaking, no.  He must own the right to be able to grant it to
others.

> Scott Bradner:
> If you have multiple authors, how do you ensure that all the authors
> have agreed?  Of the (two) particular cases that we have published,
> it is not clear that all of the authors agreed in one case.

Then you can't publish it.

> Harald Alvestrand:
> I want to put this issue into the tracker afterwards, and suggest a
> resolution to the mailing list. Let's wordsmith that there. I think
> the sense of the room is clear, but the details are not. So let's
> take this to the list.

I'd be interested in seeing this discussed.

> John Klensin:
> I want to explain the 1/2 in the hopes it will change the sense of
> the room. As soon as you say authors can grant more rights but not
> restrict, somebody is going to have to evaluate every author
> copyright statement to make certain it does not restrict. This is
> one of the reasons why we have not done this before and not
> permitted it before. Unless you want to get into the business of
> lawyers evaluating every I-D that is posted, you have to be very
> careful about this.

No, no.  There should not be any room for interpretation here.  The
IETF copying condition must be clear that they always apply, even if
there is some auxiliary copying condition that says something that
could be interpreted as conflicting.  This should be simple to solve.

> Kurt Zeilenga:
> I would add that if an author wants to release his works with
> additional rights, that he has the option of publishing it
> elsewhere. He could publish it separately on his own website if he
> wants to give more rights than he gives to the RFC Editor when he
> lets them publish it.

This will not work.  People will want to take the ASN.1 schema out of,
e.g., RFC 4120, and use it in their implementation.  The authors of
that RFC have not published the ASN.1 schema somewhere.  This forces
me as implementer to track down the authors and all contributors and
try to get them to agree to release some more rights to the schema.
This makes implementing RFCs infeasible quickly.

> David Black:
> I want to agree with Kurt that having separate publication is
> probably the cleanest way to do additional rights grant, but I am
> going to disagree with the miasma that John paints. I believe that
> with the right language, carefully written by a lawyer, in the
> master copyright you can guarantee that subsidiary copyrights could
> not restrict it.

I agree with David's second point here.

> Harald Alvestrand:
> So, looking at the list of outgoing rights issues, I don't know if
> there is anything here that is completely un-controversial. Does
> anyone want to make an assertion that one of the issues is not
> controversial, and we could decide on it now?
>
> Scott Bradner:
> Issue #1199 shouldn't controversial. It is traditional that anyone
> can publish whole RFCs and translations thereof. I don't see why
> that should be controversial. We have done it since day zero.
>
> Harald Alvestrand:
> The actual ticket is wider than the sub-bullet. I think the
> sub-bullet is un-controversial.
>
> Scott Bradner:
> Can we agree that we grant the right to reproduce unmodified + translations?  
>
> Harald Alvestrand:
> Yes. That goes into the document.
>
> David Black:
> I think we have agreed on the sub-bullet under #1199 but not all of #1199.
>
> I suggest a similar partial attack on #1175 (`how can code be
> distinguished from non-code?'). I would suggest that we list the
> obvious suspects (i.e. MIBs, ASN.1, LDAP, C-headers and other
> obvious ones) on the mailing list in a few days, and then we provide
> a tagging mechanism so that anyone who thinks they have something
> weird could tag it explicitly and say `this is code'.

This could be a start, and I'd be really interesting to dive into a
details of an actual proposal that does this.  I don't think it is a
practical approach, but it is possible to prove me wrong on this.

> Harald Alvestrand:
> That seems sensible to me.  So we list the obvious cases, and we say
> if you want to label something as code, then put `this is code' or
> whatever. That seems possible to settle this one.
>
> Kurt Zeilenga:
> I assert that anything that we characterize as a formal language
> should be considered `code'.

This doesn't address the problem of using excerpts from RFCs in
manuals.

> Scott Bradner
> Coming out of the last IPR BOF that led up to my delta document,
> everyone seemed to agreed that excepts, `as is' and independent of
> size, should be allowed to be republished, as long as their genesis
> is noted. I don't think anyone objected to that (for issue #1166).

Agreed.

> Lucy Lynch:
> If you can resolve #1167, then most of these become NO-Ops if there
> is a way to annotate where the excerpt came from and if the excerpt
> is unchanged.  Only the derived excerpt would be questionable
> (modified extracts or non-code).
>
> Kurt Zeilenga:
> Does an excerpt have attribution, and a quotation does not?  What is
> the distinction?
>
> Harald Alvestrand: This is my English.
>
> Scott Bradner: That an artifact.
>
> Harald Alvestrand:
> We seem to have consensus that excerpts with labeling should be
> permitted, any size, any time (ie. quotations).  We'll take
> suggestions for how to mark them on the mailing list.  Lucy, if you
> remember the right page of the Chicago manual style, please post if
> that is a fair-use of that particular work.

I'd be interested in seeing a decision on such recommended markers.

> Scott Bradner:
> In the draft which I did, which Joel will be free to take text about
> outbound rights from or ignore, there is text saying that excerpts
> of any size from documents are OK, and whole documents and
> translations are OK too. I felt when doing it that it would was good
> to have both (sets of words) to make it absolutely clear what is
> allowed.
>
> Harald Alvestrand:
> We have got one (open issue resolved)! The answer to #1167 (`should
> there be rules?') is `Yes. More or less, all excerpts should be
> permitted.'
>
> Just checking: `Should there be rules for how to mark excerpts?' 
>
> Thomas Narten:
> Who does the marking? I don't understand the question you are asking.
>
> Harald Alvestrand:
> The person who does the quoting. 
>
> Brian Carpenter:
> Let's make this a `should' not a `must' (for ways to label
> excerpts).  There may be places where you use excerpts where it
> would be ridiculous to use a particular way of labeling those
> excerpts.

This is very important.  Sometimes, like in the documentation for a
function, which is one or two sentences, citing the source of the text
in a specific way is annoying.  If you have an API of 500 functions,
the text can't be quoted freely under fair use.  It seems sufficient
to mark the source once, in auxiliary files.

> * Brian then read aloud some text from a draft GPL v3 license *
>
> Scott Bradner:
> We should say `It must be clear what the origin was', and not make
> any more rules than that, re: #1167.  I don't think we should say
> `Here are the words you must use' or anything else like that.

I believe suggesting _recommended_ text would be valuable.

> Harald Alvestrand:
> We have to take the issue of `modified non-code' back to the list. I
> think that is the big open issue where we don't have the basis of a
> suggested resolution for that right now. On the other issues, I'll
> try to suggest resolutions, and Joel will try to suggest text.

Looking forward to it.

Thanks,
Simon

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