FW: IETF copying conditions

[Lawrence Rosen]

Jorge, I would prefer to let you answer Ted's counter-rant.

Please explain to him that neither you nor I are expected to make code
contributions in order to contribute to IETF, or to have our contributions
be respected.

Then, please explain to him how the law of trademark and unfair business
practice deals properly with issues of third parties pretending that they
are publishing official IETF specifications. Please teach him that
distinguishing between text and code doesn't aid this purpose one whit.

Then, please remind him that intelligent comments--rants or otherwise--are
permitted on the IETF IPR WG. Fortunately for him, so too is sarcasm when
expressed with some talent.

Regards,

/Larry

> -----Original Message-----
> From: Ted Hardie [mailto:hardie@...]
> Sent: Wednesday, September 17, 2008 10:31 AM
> To: lrosen@...; 'Simon Josefsson'
> Cc: 'Contreras, Jorge'; ipr-wg@...
> Subject: RE: IETF copying conditions
>
> Forgive the top posting, but it seemed a shame to break up such
> a marvelous rant with in-line comments.  "terrible perversion of industry
> standards" I thought one of your better recent phrases; it paints with
> such a broad,  sticky brush.
>
> Anyway, one aim at the back of this is preventing someone taking
> the IETF's standards, changing them, and then claiming that the
> new text is the normative version.  The tools for achieving that aim
> are few, and they mainly revolve around saying "you can't have/change
> this text".  As you know, we could argue that the right choice was
> to leave it "no re-use outside of IETF".   That would, unfortunately, mean
> that folks couldn't change or re-use any code in the documents; we've been
> down that road, and agreed that code should be re-usable and modifiable.
> The split is the result.  You may not like it, but the other choice
> is worse, and engineering is all about trade-offs.
>
> You argue below that no contributor will ever sue for copyright
> infringement because text is copied.  I know of several cases
> where other SDOs have approached authors for inclusion of
> text in their standards; in some cases the authors have said yes, and
> in others no. If  text is copied into a competing spec,  without
> permission,  I think you will find yourself on the wrong side of the bet,
> "Nonsense!" or no.
>
> In any case, the working group has settled on the intent of all
> of this long ago and the rough consensus has already been judged.
> The only question on the table is whether the current language
> meets the aims set, something which the lovely rant below
> seems to ignore.
>
> By the way,  I keep looking forward to you producing some
> standards text or code in one of our technical documents, Larry,
> so I can have the obverse of whatever pleasure it is you get
> from watching engineers struggle with the law.  Please do let
> me know if you ever do produce something in that line.
>
> thanks,
> Ted Hardie
>
>
>
> At 9:53 AM -0700 9/17/08, Lawrence Rosen wrote:
> >Simon Josefsson wrote in a private note to me:
> >> We have discussed IETF copying conditions before.  Right now, the IETF
> >> lawyer doesn't feel my comments aren't qualified unless I am a lawyer
> >> with BSD license expertise, and I was hoping you could help here.
> >
> >I've been resisting joining this particular discussion again because I
> think
> >the IPR WG has decided to do something with which I firmly disagree, but
> I
> >don't see any value to keep nagging about it. I agree completely with
> >Simon's objections given in his email below.
> >
> >This entire notion that standards are separate collections of "text" and
> >"code" is a terrible perversion of the essential purpose of "industry
> >standards". It is silly to say that words in an IETF specification that
> tell
> >someone how or why to implement a standard can't be copied because
> someone
> >claims it is just text. Nonsense!
> >
> >I don't believe these distinctions make any legal or technical sense, nor
> do
> >they serve any appropriate purpose for those making contributions to
> >standards. These distinctions were imposed because some representatives
> of
> >some companies have always been reluctant to let others implement
> standards
> >freely. These people cannot identify one single reason, other than
> >proprietary advantage, that would justify withholding the right of the
> >public to copy anything at all from an IETF specification.
> >
> >One more point: I refuse to believe that anyone at IETF, who holds the
> >copyright, will ever sue for copyright infringement because someone
> copied
> >text rather than code. And the first time one of those companies that
> >submitted "text" in a contribution to IETF tries to sue for copyright
> >infringement, the hue and cry will drive them back into their cave.
> >
> >So for all purposes, I intend to treat any IETF specification, in its
> >entirety, as a BSD-licensed document, and I would recommend that anyone
> who
> >needs to implement that specification do the same regardless of the
> wording
> >in IETF policies. Sometimes, even lawyers take risks rather than obey the
> >letter of the "law." For obvious reasons, this email is not legal advice,
> >but feel free to copy it for anyone who wants a non-binding justification
> to
> >do what the IETF IPR WG has tried to prevent.
> >
> >/Larry
> >
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Simon Josefsson [mailto:simon@...]
> >> Sent: Wednesday, September 17, 2008 2:35 AM
> >> To: Lawrence Rosen
> >> Subject: IETF copying conditions
> >>
> >> Hi Larry.
> >>
> >> We have discussed IETF copying conditions before.  Right now, the IETF
> >> lawyer doesn't feel my comments aren't qualified unless I am a lawyer
> >> with BSD license expertise, and I was hoping you could help here.
> >>
> >> The IETF Trust is now close to finalizing the legal provisions, see
> >> proposal:
> >>
> >> http://trustee.ietf.org/policyandprocedures.html
> >>
> >> I have given up on trying to make the IETF use open source friendly
> >> licensing of entire documents, but my campaign has resulted in an
> >> intention to license code-parts of documents under a BSD license.
> >>
> >> Regarding section 4 of the latest document linked, I have identified a
> >> potential problem with the wording, which says:
> >>
> >>         c.  License. When Code Components are copied, published,
> >>    displayed or distributed as part of a document that is intended to
> be
> >>    read or referenced by persons, and not for direct processing by a
> >>    computer, they are licensed under the terms set forth in Section 3
> of
> >>    these Legal Provisions. When Code Components are copied, published,
> >>    displayed or distributed for direct processing by a computer, they
> >>    are hereby licensed to each person who wishes to receive such a
> >>    license on the terms of the "BSD License", as follows:
> >>
> >> My complaint is that this doesn't work since Code often contains
> >> portions intended to be read by persons: for example comments.  I
> >> believe the above text practically makes it difficult to extract code
> >> from RFCs because you need to make sure you don't copy anything
> intended
> >> to be read by humans.  This is in contrast with the IETF consensus
> which
> >> actually says that entire Code-portions should be freely licensed.
> >>
> >> I would appreciate if you have any thoughts to add on this, and whether
> >> you agree that the above text is problematic.
> >>
> >> I have proposed to simplify the paragraph into:
> >>
> >>         c.  License. Code Components are hereby licensed to each person
> >>         who wishes to receive such a license on the terms of the "BSD
> >>         License", as follows:
> >>
> >> Your thoughts on this proposal would also be appreciated.
> >>
> >> I have posted my final comments on the IPR WG list in:
> >>
> >> http://permalink.gmane.org/gmane.ietf.ipr/5532
> >>
> >> (Btw, the second concern I brought up have been addressed
> successfully.)
> >>
> >> If you have the time to review this and comment, I would appreciate it!
> >> Let me know if I can be of further assistance.  It might be a simple
> >> idea to post to the list if you want to make a public comment.
> >> Otherwise I can forward your feedback to the IETF lawyer.
> >>
> >> Best Regards, and thanks in advance,
> >> Simon
> >
> >_______________________________________________
> >Ipr-wg mailing list
> >Ipr-wg@...
> >https://www.ietf.org/mailman/listinfo/ipr-wg

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

[Ted Hardie]

At 10:43 AM -0700 9/17/08, Lawrence Rosen wrote:
>
>Then, please explain to him how the law of trademark and unfair business
>practice deals properly with issues of third parties pretending that they
>are publishing official IETF specifications.

Just to forestall Jorge spending some of his valuable time on this,
I note that I'm not confused about this point--I was talking about cases
where SDOs wished to re-publish (modified) IETF text within their own specs.
This does not mean that they that they write it down and say
"here is the text from RFC NNNN"; it means that they want to take
the text, change it, and re-publish it.

Allowing someone to say no to that is something the working group has
said it wants to retain.

                        regards,
                                Ted
_______________________________________________
Ipr-wg mailing list
Ipr-wg@...
https://www.ietf.org/mailman/listinfo/ipr-wg

[Lawrence Rosen]

Ted Hardie wrote:

> Just to forestall Jorge spending some of his valuable time on this,
> I note that I'm not confused about this point--I was talking about cases
> where SDOs wished to re-publish (modified) IETF text within their own
> specs.
> This does not mean that they that they write it down and say
> "here is the text from RFC NNNN"; it means that they want to take
> the text, change it, and re-publish it.
>
> Allowing someone to say no to that is something the working group has
> said it wants to retain.

I don't believe you can point to a vote anywhere in the IPR WG on that exact
point. Instead, you and others on the committee moved the discussion into
the misleading topic of code vs. text, and pretended that there was some
difference important to you.

Suppose you were to specifically ask whether IETF wants to prevent other
SDOs from re-publishing (modified) IETF text within their own specs? Do you
expect that the community here really wants to limit the use of IETF specs
in that way? Why on earth would a volunteer, cooperative standards
organization like IETF want to do that to other volunteer, cooperative SDOs?

/Larry

> -----Original Message-----
> From: Ted Hardie [mailto:hardie@...]
> Sent: Wednesday, September 17, 2008 11:03 AM
> To: lrosen@...; 'Contreras, Jorge'
> Cc: ipr-wg@...
> Subject: Re: FW: IETF copying conditions
>
> At 10:43 AM -0700 9/17/08, Lawrence Rosen wrote:
> >
> >Then, please explain to him how the law of trademark and unfair business
> >practice deals properly with issues of third parties pretending that they
> >are publishing official IETF specifications.
>
> Just to forestall Jorge spending some of his valuable time on this,
> I note that I'm not confused about this point--I was talking about cases
> where SDOs wished to re-publish (modified) IETF text within their own
> specs.
> This does not mean that they that they write it down and say
> "here is the text from RFC NNNN"; it means that they want to take
> the text, change it, and re-publish it.
>
> Allowing someone to say no to that is something the working group has
> said it wants to retain.
>
> regards,
> Ted

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

[Powers Chuck-RXCP20]

Market fragmentation comes to mind, just for one thing. I agree with Ted
(and the consensus of the group). I doesn't make sense for the IETF, as
a functioning standards group, to openly allow other SDOs (or anyone
else) to freely take and modify portions of their text, to integrate
into their own standards, and promote them as alternate solutions. That
opens the door to multiple, non-interoperable implementations, which is
pretty much in conflict with what the IETF stands for. If another SDO
wants to make a normative reference to an IETF standard, great, that is
in both of our best interests. But to say to an outside organization
"here take what we have written, modify it any way you want, and
republish it, even if the result is something that cannot coexist with
products based on our standards" seems, at best, ill-advised.

The IETF is a volunteer, consensus organization, and many of those
volunteers don't want to see their work undermined by another
organization that freely takes their work product, revises it to the
point of non-interoperability, and then promotes that solution instead
of the work product of the IETF. Let those folks go do their own work.

Regards,
Chuck
-------------
Chuck Powers,
Motorola, Inc
phone: [phone]
mobile: [phone]
 

> -----Original Message-----
> From: ipr-wg-bounces@...
> [mailto:ipr-wg-bounces@...] On Behalf Of Lawrence Rosen
> Sent: Wednesday, September 17, 2008 1:19 PM
> To: ipr-wg@...
> Subject: RE: FW: IETF copying conditions
>
> Ted Hardie wrote:
> > Just to forestall Jorge spending some of his valuable time
> on this, I
> > note that I'm not confused about this point--I was talking
> about cases
> > where SDOs wished to re-publish (modified) IETF text within
> their own
> > specs.
> > This does not mean that they that they write it down and
> say "here is
> > the text from RFC NNNN"; it means that they want to take the text,
> > change it, and re-publish it.
> >
> > Allowing someone to say no to that is something the working
> group has
> > said it wants to retain.
>
> I don't believe you can point to a vote anywhere in the IPR
> WG on that exact point. Instead, you and others on the
> committee moved the discussion into the misleading topic of
> code vs. text, and pretended that there was some difference
> important to you.
>
> Suppose you were to specifically ask whether IETF wants to
> prevent other SDOs from re-publishing (modified) IETF text
> within their own specs? Do you expect that the community here
> really wants to limit the use of IETF specs in that way? Why
> on earth would a volunteer, cooperative standards
> organization like IETF want to do that to other volunteer,
> cooperative SDOs?
>
> /Larry
>
>
>
>
> > -----Original Message-----
> > From: Ted Hardie [mailto:hardie@...]
> > Sent: Wednesday, September 17, 2008 11:03 AM
> > To: lrosen@...; 'Contreras, Jorge'
> > Cc: ipr-wg@...
> > Subject: Re: FW: IETF copying conditions
> >
> > At 10:43 AM -0700 9/17/08, Lawrence Rosen wrote:
> > >
> > >Then, please explain to him how the law of trademark and unfair
> > >business practice deals properly with issues of third parties
> > >pretending that they are publishing official IETF specifications.
> >
> > Just to forestall Jorge spending some of his valuable time
> on this, I
> > note that I'm not confused about this point--I was talking
> about cases
> > where SDOs wished to re-publish (modified) IETF text within
> their own
> > specs.
> > This does not mean that they that they write it down and
> say "here is
> > the text from RFC NNNN"; it means that they want to take the text,
> > change it, and re-publish it.
> >
> > Allowing someone to say no to that is something the working
> group has
> > said it wants to retain.
> >
> > regards,
> > Ted
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wg@...
> https://www.ietf.org/mailman/listinfo/ipr-wg
>

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

[Todd Glassey CISM CIFI]

Larry, Chuck Powers is right on this as well. My response to your retort to
Ted Hardie is below.

Todd Glassey
----- Original Message -----
From: "Lawrence Rosen" <lrosen@...>
To: <ipr-wg@...>
Sent: Wednesday, September 17, 2008 11:18 AM
Subject: RE: FW: IETF copying conditions

> Ted Hardie wrote:
>> Just to forestall Jorge spending some of his valuable time on this,
>> I note that I'm not confused about this point--I was talking about cases
>> where SDOs wished to re-publish (modified) IETF text within their own
>> specs.
>> This does not mean that they that they write it down and say
>> "here is the text from RFC NNNN"; it means that they want to take
>> the text, change it, and re-publish it.
>>
>> Allowing someone to say no to that is something the working group has
>> said it wants to retain.
>
> I don't believe you can point to a vote anywhere in the IPR WG on that
> exact
> point. Instead, you and others on the committee moved the discussion into
> the misleading topic of code vs. text, and pretended that there was some
> difference important to you.

That's because the IPR WG is a sham IMHO. The law around the transfer of IP
is not somehting that the IETF gets to rewrite to suit itself.

>
> Suppose you were to specifically ask whether IETF wants to prevent other
> SDOs from re-publishing (modified) IETF text within their own specs?
If their outgoing licensing is not compatible with the existing IETF then
they cannot do this and that either has to be agreed upon as something that
can be lived with or a proper flow-through licenesing developed for that SDO
Practice Model.

> Do you
> expect that the community here really wants to limit the use of IETF specs
> in that way?

Counsel the question here is not what this community wants but rather what
the law allows. The IETF's processes of being a trailing edge SDO are what
define how it must react to IP that is submitted to it for publication.

> Why on earth would a volunteer, cooperative standards
> organization like IETF want to do that to other volunteer, cooperative
> SDOs?

Because the IETF doesnt own or control the IP moving through it unless the
purpose of the IETF has been formally changed.

The issues are simple, the IETF is a trailing-edge standards process which
is now trying to morph into a leading edge process without adhering to the
legal requirements for managing genesis of that IP. That said the IETF needs
to respect the IP rights of the real owners of the IP submitted by third
parties.

That means that the previous IP owners rights are what they are and the IETF
needs to respect that.

>
> /Larry
>
>
>
>
>> -----Original Message-----
>> From: Ted Hardie [mailto:hardie@...]
>> Sent: Wednesday, September 17, 2008 11:03 AM
>> To: lrosen@...; 'Contreras, Jorge'
>> Cc: ipr-wg@...
>> Subject: Re: FW: IETF copying conditions
>>
>> At 10:43 AM -0700 9/17/08, Lawrence Rosen wrote:
>> >
>> >Then, please explain to him how the law of trademark and unfair business
>> >practice deals properly with issues of third parties pretending that
>> >they
>> >are publishing official IETF specifications.
>>
>> Just to forestall Jorge spending some of his valuable time on this,
>> I note that I'm not confused about this point--I was talking about cases
>> where SDOs wished to re-publish (modified) IETF text within their own
>> specs.
>> This does not mean that they that they write it down and say
>> "here is the text from RFC NNNN"; it means that they want to take
>> the text, change it, and re-publish it.
>>
>> Allowing someone to say no to that is something the working group has
>> said it wants to retain.
>>
>> regards,
>> Ted
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wg@...
> https://www.ietf.org/mailman/listinfo/ipr-wg

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



No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.6.21/1676 - Release Date: 9/17/2008
9:33 AM

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

[Ted Hardie]

At 11:18 AM -0700 9/17/08, Lawrence Rosen wrote:
>
>Suppose you were to specifically ask whether IETF wants to prevent other
>SDOs from re-publishing (modified) IETF text within their own specs? Do you
>expect that the community here really wants to limit the use of IETF specs
>in that way? Why on earth would a volunteer, cooperative standards
>organization like IETF want to do that to other volunteer, cooperative SDOs?

First,  I think we're past the point of asking for consensus on the output
documents, which are clear on this point.  You're welcome to ask the
chairs to reconsider, but with the documents past Last Call, I don't think
see it as likely.

Second, not all SDOs are supported by volunteers, and quite a few of them are
not cooperative.  I'm sure if you take the time to look out at the landscape
a bit, you'll see a fair few that are national or international bodies whose toes
dip into the same waters as the IETF.    They may have very different views
on what makes a good network, and the interactions between them and the
IETF has in the past been rocky.  Try to picture one of them as the re-users
of the text, and you may see where some of our reactions are coming through.
The threat here is not theoretical.

The last and really major point is Chuck's--this makes interoperability
harder.  When there are three different things that look largely
similar but don't interoperate because of different interior choices,
things break.  To get past that in some current domains we see
gateways that have two different flavors of the same protocol
on either side of the gateway.  That's bad and anything we can
do to minimize it is worth it.  It's better for the end users, the developers,
and the Internet when things interoperate.

                        regards,
                                Ted Hardie
_______________________________________________
Ipr-wg mailing list
Ipr-wg@...
https://www.ietf.org/mailman/listinfo/ipr-wg

[Lawrence Rosen]

Ted, none of your reasons, or Chuck's, requires the dumb solution of
distinguishing text from code in IETF specifications.

I agree, though, that we're somewhat past that point. The only hope is that
the chairs will reconsider or, perhaps better still, that the community will
ignore the "text vs. code" distinction altogether and do what I would do:
Treat all IETF specifications as if they were available for copy and wait
for some bogeyman company to try to sue for copyright infringement. :-)

Certainly most engineers in the open source community around the world won't
worry about you suing them. I doubt if many of them will actually read or
try to understand these rules anyway. The standards world is moving towards
greater openness and freedom, and IETF will get there somehow.

/Larry

> -----Original Message-----
> From: Ted Hardie [mailto:hardie@...]
> Sent: Wednesday, September 17, 2008 1:09 PM
> To: lrosen@...; ipr-wg@...
> Subject: RE: FW: IETF copying conditions
>
> At 11:18 AM -0700 9/17/08, Lawrence Rosen wrote:
> >
> >Suppose you were to specifically ask whether IETF wants to prevent other
> >SDOs from re-publishing (modified) IETF text within their own specs? Do
> you
> >expect that the community here really wants to limit the use of IETF
> specs
> >in that way? Why on earth would a volunteer, cooperative standards
> >organization like IETF want to do that to other volunteer, cooperative
> SDOs?
>
> First,  I think we're past the point of asking for consensus on the output
> documents, which are clear on this point.  You're welcome to ask the
> chairs to reconsider, but with the documents past Last Call, I don't think
> see it as likely.
>
> Second, not all SDOs are supported by volunteers, and quite a few of them
> are
> not cooperative.  I'm sure if you take the time to look out at the
> landscape
> a bit, you'll see a fair few that are national or international bodies
> whose toes
> dip into the same waters as the IETF.    They may have very different
> views
> on what makes a good network, and the interactions between them and the
> IETF has in the past been rocky.  Try to picture one of them as the re-
> users
> of the text, and you may see where some of our reactions are coming
> through.
> The threat here is not theoretical.
>
> The last and really major point is Chuck's--this makes interoperability
> harder.  When there are three different things that look largely
> similar but don't interoperate because of different interior choices,
> things break.  To get past that in some current domains we see
> gateways that have two different flavors of the same protocol
> on either side of the gateway.  That's bad and anything we can
> do to minimize it is worth it.  It's better for the end users, the
> developers,
> and the Internet when things interoperate.
>
> regards,
> Ted Hardie

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

[Jorge Contreras]

 
> Treat all IETF specifications as if they were available for
> copy

They are all available for copy.  Just not for modification.
_______________________________________________
Ipr-wg mailing list
Ipr-wg@...
https://www.ietf.org/mailman/listinfo/ipr-wg

[Brian E Carpenter-2]

> At 11:18 AM -0700 9/17/08, Lawrence Rosen wrote:
>> Suppose you were to specifically ask whether IETF wants to prevent other
>> SDOs from re-publishing (modified) IETF text within their own specs? Do you
>> expect that the community here really wants to limit the use of IETF specs
>> in that way?

Yes, undoubtedly that was the WG consensus. We don't want to see other SDOs
publishing incompatible versions of our protocols, period. And this is
not paranoia; it's evidence-based, although I don't want to point the finger
at specific SDOs, since such matters are usually handled by courteous
bilateral discussions. Using copyright protection is clearly a last
resort.

>> Why on earth would a volunteer, cooperative standards
>> organization like IETF want to do that to other volunteer, cooperative SDOs?

Becaus our primary mission is to make the Internet work better, which
requires interoperable protocols, which precludes incompatible versions.

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

[Lawrence Rosen]

> > Treat all IETF specifications as if they were available for
> > copy
>
> They are all available for copy.  Just not for modification.

Sorry, I meant "copy and modification." That must be allowed when the
modification to the text is required to describe the modified code. Or are
you suggesting that someone who changes the code can't document his changes?

/Larry

> -----Original Message-----
> From: ipr-wg-bounces@... [mailto:ipr-wg-bounces@...] On Behalf
> Of Contreras, Jorge
> Sent: Wednesday, September 17, 2008 2:10 PM
> To: lrosen@...; ipr-wg@...
> Subject: RE: FW: IETF copying conditions
>
>
> > Treat all IETF specifications as if they were available for
> > copy
>
> They are all available for copy.  Just not for modification.
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wg@...
> https://www.ietf.org/mailman/listinfo/ipr-wg

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

[Lawrence Rosen]

I'm moving this to ietf@.... There are important policy implications
here that the entire community should understand before we let the IPR WG
decide for us on a policy so opposite to open source and open standards!

I am also copying this separately to the Open Web Foundation (OWF) list,
which I believe may have some interest in ensuring that it can copy and
modify IETF specifications for its own standards any time it damn well
pleases.

/Larry

> > At 11:18 AM -0700 9/17/08, Lawrence Rosen wrote:
> >> Suppose you were to specifically ask whether IETF wants to prevent
> other
> >> SDOs from re-publishing (modified) IETF text within their own specs? Do
> you
> >> expect that the community here really wants to limit the use of IETF
> specs
> >> in that way?
>
> Yes, undoubtedly that was the WG consensus. We don't want to see other
> SDOs
> publishing incompatible versions of our protocols, period. And this is
> not paranoia; it's evidence-based, although I don't want to point the
> finger
> at specific SDOs, since such matters are usually handled by courteous
> bilateral discussions. Using copyright protection is clearly a last
> resort.
>
> >> Why on earth would a volunteer, cooperative standards
> >> organization like IETF want to do that to other volunteer, cooperative
> SDOs?
>
> Becaus our primary mission is to make the Internet work better, which
> requires interoperable protocols, which precludes incompatible versions.
>
>    Brian

*********************

Please note: There is an earlier set of emails on this thread in the
archives of the IPR WG.

/Larry

*********************

> -----Original Message-----
> From: ipr-wg-bounces@... [mailto:ipr-wg-bounces@...] On Behalf
> Of Brian E Carpenter
> Sent: Wednesday, September 17, 2008 2:15 PM
> To: ipr-wg@...
> Subject: Re: FW: IETF copying conditions

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

[Todd Glassey CISM CIFI]

----- Original Message -----
From: "Lawrence Rosen" <lrosen@...>
To: <ipr-wg@...>
Sent: Wednesday, September 17, 2008 2:02 PM
Subject: RE: FW: IETF copying conditions


> Ted, none of your reasons, or Chuck's, requires the dumb solution of
> distinguishing text from code in IETF specifications.

Sure it does - those code sections may come from other controlled IP sources
which are referenced here in IETF document's for research. That CANNOT by
that set of terms provide a derivative right to IETF's relying parties.

The IETF's submission process allows people who dont actually own or
represent the legal interests of the actual IP owners to the IETF for
publication. They may own the rights to their words as a literary work but
as a technology description, no...

In those instances like the TELNET docuements for instance, the actual power
of attorney for the real IP owners was never transferred to the IETF in any
culpable form and yet the IETF is licnesing its use for any and all
purposes. .

>
> I agree, though, that we're somewhat past that point. The only hope is
> that
> the chairs will reconsider or, perhaps better still, that the community
> will
> ignore the "text vs. code" distinction altogether and do what I would do:
> Treat all IETF specifications as if they were available for copy and wait
> for some bogeyman company to try to sue for copyright infringement. :-)
>
> Certainly most engineers in the open source community around the world
> won't
> worry about you suing them. I doubt if many of them will actually read or
> try to understand these rules anyway. The standards world is moving
> towards
> greater openness and freedom, and IETF will get there somehow.
>
> /Larry
>
>
>
>> -----Original Message-----
>> From: Ted Hardie [mailto:hardie@...]
>> Sent: Wednesday, September 17, 2008 1:09 PM
>> To: lrosen@...; ipr-wg@...
>> Subject: RE: FW: IETF copying conditions
>>
>> At 11:18 AM -0700 9/17/08, Lawrence Rosen wrote:
>> >
>> >Suppose you were to specifically ask whether IETF wants to prevent other
>> >SDOs from re-publishing (modified) IETF text within their own specs? Do
>> you
>> >expect that the community here really wants to limit the use of IETF
>> specs
>> >in that way? Why on earth would a volunteer, cooperative standards
>> >organization like IETF want to do that to other volunteer, cooperative
>> SDOs?
>>
>> First,  I think we're past the point of asking for consensus on the
>> output
>> documents, which are clear on this point.  You're welcome to ask the
>> chairs to reconsider, but with the documents past Last Call, I don't
>> think
>> see it as likely.
>>
>> Second, not all SDOs are supported by volunteers, and quite a few of them
>> are
>> not cooperative.  I'm sure if you take the time to look out at the
>> landscape
>> a bit, you'll see a fair few that are national or international bodies
>> whose toes
>> dip into the same waters as the IETF.    They may have very different
>> views
>> on what makes a good network, and the interactions between them and the
>> IETF has in the past been rocky.  Try to picture one of them as the re-
>> users
>> of the text, and you may see where some of our reactions are coming
>> through.
>> The threat here is not theoretical.
>>
>> The last and really major point is Chuck's--this makes interoperability
>> harder.  When there are three different things that look largely
>> similar but don't interoperate because of different interior choices,
>> things break.  To get past that in some current domains we see
>> gateways that have two different flavors of the same protocol
>> on either side of the gateway.  That's bad and anything we can
>> do to minimize it is worth it.  It's better for the end users, the
>> developers,
>> and the Internet when things interoperate.
>>
>> regards,
>> Ted Hardie
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wg@...
> https://www.ietf.org/mailman/listinfo/ipr-wg

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



No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.6.21/1676 - Release Date: 9/17/2008
9:33 AM

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

[Paul Hoffman-2]

At 2:43 PM -0700 9/17/08, Lawrence Rosen wrote:
>I'm moving this to ietf@.... There are important policy implications
>here that the entire community should understand before we let the IPR WG
>decide for us on a policy so opposite to open source and open standards!

Larry, I'm confused. What about the statement that "We don't want to
see other SDOs publishing *incompatible* versions of our protocols,
period" is the opposite of the policy of open standards (emphasis
added)?

Which SDOs that you participate in want to see other SDOs publishing
*incompatible* versions of their protocols?

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Ipr-wg mailing list
Ipr-wg@...
https://www.ietf.org/mailman/listinfo/ipr-wg

[Lawrence Rosen]

Paul Hoffman wrote:
> Which SDOs that you participate in want to see other SDOs publishing
> *incompatible* versions of their protocols?

Hi Paul,

Of course none of the SDOs that I work with want to see incompatible
versions. But this turns the issue on its head. Open source and open
standards deal with the freedom to do things, even though we might
discourage people to take us up on that offer of freedom.

So with respect to IETF specifications, the open source and open standards
objective is that the world is *free* to make compatible or incompatible
versions of our specifications. (This is the philosophy that neither IETF
nor Microsoft nor IBM, nor anyone else, is going to be the absolute God of
acceptable software.) I'm sure that good people everywhere will cooperate to
ensure that all good versions of our specifications are compatible, and
cooperative people will be encouraged to remain compatible by virtue of the
quality of our work.

But if anyone, anywhere, for any reason, wants to take an IETF specification
and modify it, open source requires that he be free to do so.

The current proposed IPR policy seems to allow that for "code" but not for
"text" in our specifications. What a burden that imposes to protect people
from freedom!

/Larry  

> -----Original Message-----
> From: Paul Hoffman [mailto:paul.hoffman@...]
> Sent: Wednesday, September 17, 2008 3:19 PM
> To: lrosen@...; ietf@...
> Cc: ipr-wg@...
> Subject: RE: FW: IETF copying conditions
>
> At 2:43 PM -0700 9/17/08, Lawrence Rosen wrote:
> >I'm moving this to ietf@.... There are important policy implications
> >here that the entire community should understand before we let the IPR WG
> >decide for us on a policy so opposite to open source and open standards!
>
> Larry, I'm confused. What about the statement that "We don't want to
> see other SDOs publishing *incompatible* versions of our protocols,
> period" is the opposite of the policy of open standards (emphasis
> added)?
>
> Which SDOs that you participate in want to see other SDOs publishing
> *incompatible* versions of their protocols?
>
> --Paul Hoffman, Director
> --VPN Consortium

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

[Ian Jackson-2]

Paul Hoffman writes ("RE: FW: IETF copying conditions"):
> Which SDOs that you participate in want to see other SDOs publishing
> *incompatible* versions of their protocols?

The Debian project has published a small (by IETF standards) but
significant body of work specifying the interoperation and behaviour
of the various parts of what they regard as a modern Unix system,
particularly as regards the behaviour of package management systems
and the interoperation between separately-maintained packages.

The Debian standards documents (the core of which I originally wrote
but which have been greatly expanded and enhanced and are now
maintained by others) are released under a licences which permit
modified redistribution with a definite expectation that derivative
systems might want to do things differently.

That a different system might do things differently would not be good
for Debian so we don't encourage it.  We would prefer to keep Debian
and its derivatives as close as possible so that we can share
development work (particularly, so that we can all benefit from each
others' improvements).

However, the whole point of Free Software (and thus the point of
Debian) is that people are free to modify it.  If that means that they
are free to cause it to run to incompatible standards, so be it.  And
that freedom needs to be practically exerciseable collectively as well
as individually, so must include the freedom to properly communicate
within their own project what they are doing.  So we do not use the
law to prevent our derivatives from using modified versions of our
standards documents if they regard it as necessary.

Debian is a not insignificant organisation.  There are around 1000
members with voting rights.  Many of Debian's choices both at a
technical and political level have been influential in the relevant
fields.

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

[Black_David]

Larry,

> Paul Hoffman wrote:
> > Which SDOs that you participate in want to see other SDOs publishing
> > *incompatible* versions of their protocols?
>
> Hi Paul,
>
> Of course none of the SDOs that I work with want to see incompatible
> versions. But this turns the issue on its head. Open source and open
> standards deal with the freedom to do things, even though we might
> discourage people to take us up on that offer of freedom.
>
> So with respect to IETF specifications, the open source and open

standards
> objective is that the world is *free* to make compatible or
incompatible
> versions of our specifications. (This is the philosophy that neither
IETF
> nor Microsoft nor IBM, nor anyone else, is going to be the absolute
God of
> acceptable software.) I'm sure that good people everywhere will
cooperate to
> ensure that all good versions of our specifications are compatible,
and
> cooperative people will be encouraged to remain compatible by virtue
of the
> quality of our work.
>
> But if anyone, anywhere, for any reason, wants to take an IETF
specification
> and modify it, open source requires that he be free to do so.

I think "requires" is a stretch.  There are a large number of non-IETF
standards implemented in open source for which copyright does not permit
arbitrary modifications, so I think "requires" is incorrect.  Copyright
provisions that do not grant derivative works rights and have
distribution
terms far less permissive than IETF's are common in other standards
bodies,
some of whom rely on charging money for copies of standards to fund
their
budgets. IETF has chosen not to charge for standards for many good
reasons.

Encouraging people who want to modify standards to talk to the people
who
developed the standards is a "good idea", and to the extent that
copyright
terms encourage people to do so, that's beneficial.  An example of the
benefits of this sort of discussion is RFC 4595 "Use of IKEv2 in the
Fibre
Channel Security Association Management Protocol" (I'm an author).  When
I started working on this, my initial belief was that an IETF RFC and
use
of IANA-allocated values was highly unlikely (e.g., IKEv2 for FC does
not
run over IP) and I was pleasantly surprised that the IETF Security Area
wanted to see the FC values and usage documented in an RFC.

OTOH, of the various arguments made for use of RFC text, the one I'm
most
sympathetic to is documentation - code comments, manuals, online help,
etc.,
where the ability to selectively quote from the RFC that is implemented
can be very useful.  This would need to be controlled, as blanket
permission for arbitrary selective quoting can be dangerous - it's
fairly easy to change a standard to be non-interoperable via selective
quoting.  For an (amusing) extreme example from another domain, see:

http://www.legis.state.wi.us/senate/sen10/news/FrankensteinVeto.pdf

While I doubt that anyone would ever resort to something that bizarre in
quoting from an RFC, I hope the underlying concern is clear.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
black_david@...        Mobile: [phone]
----------------------------------------------------
_______________________________________________
Ipr-wg mailing list
Ipr-wg@...
https://www.ietf.org/mailman/listinfo/ipr-wg

[Ted Hardie]

At 11:00 AM -0700 9/18/08, Ian Jackson wrote:
>
>That a different system might do things differently would not be good
>for Debian so we don't encourage it.  We would prefer to keep Debian
>and its derivatives as close as possible so that we can share
>development work (particularly, so that we can all benefit from each
>others' improvements).

Thanks for your considered reply to the issues.  In the section above,
you hit on one of the crucial issues:  what's the cost of a fork?

It's actually highly variable.  In many instances, a fork doesn't
actually create interoperability problems at all, but instead carries
two different code bases forward in different directions, while
still allowing bits and pieces from the two code bases to be passed
back and forth at will.  The cost there is low.  In other instances, it
does create two new systems, each of which continues to evolve
separately but without the ability to freely move code from one to
another.  Both instances may limit the benefit each group may have from
the other's efforts, but it is clearly the latter case which is the
most troubling.  

In the IETF, the lack of interoperability is
not simply expressed in the re-use of code, but in the compatibility
of the wire formats and thus the ability to pass messages among
the actors who share the net.  In the IETF, interoperability is one the
key measurements of  success; without it, no protocol is a success
in our terms.  There are things which must also happen, but it
is the foundation of all the protocol work that happens here.
The contortions we engage to maximize that often look
strange, but they fall out of a very basic principle:

The Internet must not fork.

To remain "the Internet" and not simply an internet, we
must do everything we can to prevent it.  There are a host
of local optimizations which could be made in specific environments,
and there are extraordinary temptations at times to make
them and gateway at the border of those regions.  It's almost
always a mistake.  Every time we have broken the core
interoperablity of the network in order to achieve some
local optimization, the system as a whole has been hurt.
Sometimes so severely that we are still recovering.

No one objects to the code implementing a protocol from being
changed, modified, or, yes, forked.  Maintaining a frankly
ugly distinction between "code" and "text" is an
expression of our willingness to see those modifications.
But our willingness to see the protocols drift into
a non-interoperable mess should approach zero.  It hurts
the net too much, by isolating those whom the net should
connect.

Speaking only for myself,
                        regards,
                                Ted Hardie






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

[Harald Alvestrand]

Lawrence Rosen wrote:

> Ted Hardie wrote:
>  
>> Just to forestall Jorge spending some of his valuable time on this,
>> I note that I'm not confused about this point--I was talking about cases
>> where SDOs wished to re-publish (modified) IETF text within their own
>> specs.
>> This does not mean that they that they write it down and say
>> "here is the text from RFC NNNN"; it means that they want to take
>> the text, change it, and re-publish it.
>>
>> Allowing someone to say no to that is something the working group has
>> said it wants to retain.
>>    
>
> I don't believe you can point to a vote anywhere in the IPR WG on that exact
> point. Instead, you and others on the committee moved the discussion into
> the misleading topic of code vs. text, and pretended that there was some
> difference important to you.

Larry, that is your claim.
I don't dispute the claim that we haven't taken a vote, because the IETF
does not vote.
But I will assert two things:

- The discussion of permitting change to text was extensive and repeated.
- The consensus of the working group was the compromise position now
documented.

I assert that if you want to claim that either of these two statements
are false, YOU back it up with evidence. As it stands, you are making
statements that I personally, as the WG chair who's tried to shepherd
this process for the last 3 years, find to be crossing the border
between uninformed speculation and assertions that I would have to take
personal affront at.

Some breadcrumbs from the archives - both the meeting minutes, the
ticket server and the email archives are online, and you should be able
to find them easily to verify:

The issue tracker shows #1169: "Modified excerpts", with the first text
"Should modified versions of excerpts from non-code text be permitted?".

https://rt.psg.com/Ticket/Display.html?id=1169

The resolution, as of November 13, 2007 (I was lame in my tracker
updates), says "Resolved as of Chicago (not)".

The July 2007 minutes of the physical meeting in Chicago show:

Consensus in room that the other issues have been resolved: #1166,
1167, 1168, 1169, 1175, 1199, 1237, 1246, 1337, 1400

http://www.ietf.org/proceedings/07jul/minutes/ipr.txt

My archive search shows that this occurs in multiple messages to the list:
June 27, 2006, "Ticket status, June 27, 2006":


#1169 Modified excerpts
   Consensus that modifications to make use of code in implementations
are OK.
   No consensus on modifications to non-code.
   Not clear if consensus exists on reuse of code for other purposes
than standards implementation

March 27, 2007, "DRAFT minutes from Prague IPR meeting":

III - matching issues to resolutions
  Harald reviewed issues from issues list and the resolutions
.......
    1169 Modified excerpts
        Resolution: Permitted for code, not permitted for non-code


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

[Simon Josefsson-2]

Harald Alvestrand <harald@...> writes:

> Lawrence Rosen wrote:
>> Ted Hardie wrote:
>>  
>>> Just to forestall Jorge spending some of his valuable time on this,
>>> I note that I'm not confused about this point--I was talking about cases
>>> where SDOs wished to re-publish (modified) IETF text within their own
>>> specs.
>>> This does not mean that they that they write it down and say
>>> "here is the text from RFC NNNN"; it means that they want to take
>>> the text, change it, and re-publish it.
>>>
>>> Allowing someone to say no to that is something the working group has
>>> said it wants to retain.
>>>    
>>
>> I don't believe you can point to a vote anywhere in the IPR WG on that exact
>> point. Instead, you and others on the committee moved the discussion into
>> the misleading topic of code vs. text, and pretended that there was some
>> difference important to you.
> Larry, that is your claim.
> I don't dispute the claim that we haven't taken a vote, because the
> IETF does not vote.
> But I will assert two things:
>
> - The discussion of permitting change to text was extensive and repeated.
> - The consensus of the working group was the compromise position now
> documented.
>
> I assert that if you want to claim that either of these two statements
> are false, YOU back it up with evidence.

Your two assertions are not in contrast with what Larry wrote, if you
read it carefully, so I think you are talking past each other.

The problem in the WG has been that the discussions of separating text
and code licenses were managed, by the chairs, as discussions of whether
to permit changes to text.  That is not the same discussion.  By
treating it as a 'permit-changes-to-text?' discussion, you make an a
priori assumption that there is a difference between text and code that
is relevant in this context.  If you move the discussions like that,
you'll end up with different licenses, which results in unwarranted
complexity.  I believe this is what Larry refers to, and I agree with
that.

> Some breadcrumbs from the archives - both the meeting minutes, the
> ticket server and the email archives are online, and you should be
> able to find them easily to verify:
>
> The issue tracker shows #1169: "Modified excerpts", with the first
> text "Should modified versions of excerpts from non-code text be
> permitted?".
>
> https://rt.psg.com/Ticket/Display.html?id=1169
>
> The resolution, as of November 13, 2007 (I was lame in my tracker
> updates), says "Resolved as of Chicago (not)".

This is a fine example of were arguments against separating licenses for
code and text were regarded as a discussion of whether to allow changes
to text, see my original e-mail which is quoted in the tracker.  That
summary was missing the point.

> The July 2007 minutes of the physical meeting in Chicago show:
>
> Consensus in room that the other issues have been resolved: #1166,
> 1167, 1168, 1169, 1175, 1199, 1237, 1246, 1337, 1400
>
> http://www.ietf.org/proceedings/07jul/minutes/ipr.txt
>
> My archive search shows that this occurs in multiple messages to the list:
> June 27, 2006, "Ticket status, June 27, 2006":
>
>
> #1169 Modified excerpts
>   Consensus that modifications to make use of code in implementations
> are OK.
>   No consensus on modifications to non-code.
>   Not clear if consensus exists on reuse of code for other purposes
> than standards implementation
>
> March 27, 2007, "DRAFT minutes from Prague IPR meeting":
>
> III - matching issues to resolutions
>  Harald reviewed issues from issues list and the resolutions
> .......
>    1169 Modified excerpts
>        Resolution: Permitted for code, not permitted for non-code

As far as I understood Larry, these issues are not related to what he
referred to.

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

[Lawrence Rosen]

Harald Alvestrand wrote;

> - The discussion of permitting change to text was extensive and repeated.
> - The consensus of the working group was the compromise position now
> documented.
>
> I assert that if you want to claim that either of these two statements
> are false, YOU back it up with evidence. As it stands, you are making
> statements that I personally, as the WG chair who's tried to shepherd
> this process for the last 3 years, find to be crossing the border
> between uninformed speculation and assertions that I would have to take
> personal affront at.

Harald,

I certainly meant no insult to your efforts to shepherd an IPR group with a
*flawed charter* [1] to a conclusion with which I disagree. You and I
discussed this many times in-channel and back-channel, and you remember my
frustrations and my sympathy for your position then and now.

Indeed, we just wasted another thread arguing about the nonsensical
distinction between code and text and again heard some people assert it is
somehow relevant to the goal of pushing the IETF brand and seeking
consistency on standards.

The proposed IETF IPR policy allows the public to modify the code present in
IETF specifications but not to use that same specification to create
modified text to document that modified code! Does anyone here honestly
believe this is justified?

You admit: The working group took no vote. Nobody ever does in IETF. It is
thus possible for a small group of people who have the stomach to attend to
boring IPR discussions to come to an irrational conclusion.

Since there was never a vote, I retain the right to repeat my concerns.
You'll notice I've not tried to dominate this thread, but I was invited to
comment once again--and I did.

-1.

/Larry

[1] Failure to address patents; failure to identify the goals for IETF of a
revised copyright policy; failure to weigh benefits and costs to the public
of various alternatives.

P.S. I moved this back to ietf@.... Even though some people there find
these battles over legal issues boring and distracting, this policy is the
guts of why we're here. It should be the entire organization that debates
the charter and results of a policy working group, not the working group
itself.

> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@...]
> Sent: Wednesday, September 24, 2008 10:22 PM
> To: lrosen@...
> Cc: ipr-wg@...
> Subject: Re: FW: IETF copying conditions
>
> Lawrence Rosen wrote:
> > Ted Hardie wrote:
> >
> >> Just to forestall Jorge spending some of his valuable time on this,
> >> I note that I'm not confused about this point--I was talking about
> cases
> >> where SDOs wished to re-publish (modified) IETF text within their own
> >> specs.
> >> This does not mean that they that they write it down and say
> >> "here is the text from RFC NNNN"; it means that they want to take
> >> the text, change it, and re-publish it.
> >>
> >> Allowing someone to say no to that is something the working group has
> >> said it wants to retain.
> >>
> >
> > I don't believe you can point to a vote anywhere in the IPR WG on that
> exact
> > point. Instead, you and others on the committee moved the discussion
> into
> > the misleading topic of code vs. text, and pretended that there was some
> > difference important to you.
> Larry, that is your claim.
> I don't dispute the claim that we haven't taken a vote, because the IETF
> does not vote.
> But I will assert two things:
>
> - The discussion of permitting change to text was extensive and repeated.
> - The consensus of the working group was the compromise position now
> documented.
>
> I assert that if you want to claim that either of these two statements
> are false, YOU back it up with evidence. As it stands, you are making
> statements that I personally, as the WG chair who's tried to shepherd
> this process for the last 3 years, find to be crossing the border
> between uninformed speculation and assertions that I would have to take
> personal affront at.
>
> Some breadcrumbs from the archives - both the meeting minutes, the
> ticket server and the email archives are online, and you should be able
> to find them easily to verify:
>
> The issue tracker shows #1169: "Modified excerpts", with the first text
> "Should modified versions of excerpts from non-code text be permitted?".
>
> https://rt.psg.com/Ticket/Display.html?id=1169
>
> The resolution, as of November 13, 2007 (I was lame in my tracker
> updates), says "Resolved as of Chicago (not)".
>
> The July 2007 minutes of the physical meeting in Chicago show:
>
> Consensus in room that the other issues have been resolved: #1166,
> 1167, 1168, 1169, 1175, 1199, 1237, 1246, 1337, 1400
>
> http://www.ietf.org/proceedings/07jul/minutes/ipr.txt
>
> My archive search shows that this occurs in multiple messages to the list:
> June 27, 2006, "Ticket status, June 27, 2006":
>
>
> #1169 Modified excerpts
>    Consensus that modifications to make use of code in implementations
> are OK.
>    No consensus on modifications to non-code.
>    Not clear if consensus exists on reuse of code for other purposes
> than standards implementation
>
> March 27, 2007, "DRAFT minutes from Prague IPR meeting":
>
> III - matching issues to resolutions
>   Harald reviewed issues from issues list and the resolutions
> .......
>     1169 Modified excerpts
>         Resolution: Permitted for code, not permitted for non-code

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