An example of the outbound rights problem

Hi, folks.  I'm not currently following the IPR working
group, but I
wanted to share a real world problem with the group as it
illustrates
some of the outbound rights issues.

Some fine folks wanted to add support for RFC 4559 to
Mozilla.  That's
not an IETF document but does rely on a lot of IETF
technology
including RFC 2743 and 2744.

RFC 2744 specifies a header file that they wanted to use. 
They were
unable because of the IETF copyright and because the IETF
copyright
did not meet Mozilla's license needs.

Fortunately there was a work around: the authors of RFC 1509
(a
previous version of RFC 2744) had donated their header to
MIT for
inclusion in MIT Kerberos.  MIT had tried to keep this
header in
approximate sync with RFC 2744 and it was close enough to be
useful to
Mozilla.

I include information I received from the  authors of the
patch:

>This bugzilla bug shows some of Mozilla discussions
about how to include
>gssapi.h as part of their distro.  The RFC Copyright was
too strict so the
>Mozilla organization stated they couldn't use the RFC
version of the header
>definitions and had to use a version from the MIT source
code instead.

>https://bugzilla.mozilla.org/show_bug.cgi?id=280792#c55

My personal opinion is that we, the IETF, definitely want
Mozilla and
similar organizations to be able to pick up their
technology.


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

Sam,

you are referring to Appendix A of RFC 2744?

I believe the current content of the -outbound draft is
clear that the 
result you want is what the WG is directing the IETF Trust
to achieve.

If, upon reading the -outbound draft, you think this is not
clear, please 
suggest how to make it clearer.

                  Harald

--On 24. juli 2007 10:22 -0400 Sam Hartman
<hartmans-ietfmit.edu> wrote:

>
>
> Hi, folks.  I'm not currently following the IPR working
group, but I
> wanted to share a real world problem with the group as
it illustrates
> some of the outbound rights issues.
>
> Some fine folks wanted to add support for RFC 4559 to
Mozilla.  That's
> not an IETF document but does rely on a lot of IETF
technology
> including RFC 2743 and 2744.
>
> RFC 2744 specifies a header file that they wanted to
use.  They were
> unable because of the IETF copyright and because the
IETF copyright
> did not meet Mozilla's license needs.
>
> Fortunately there was a work around: the authors of RFC
1509 (a
> previous version of RFC 2744) had donated their header
to MIT for
> inclusion in MIT Kerberos.  MIT had tried to keep this
header in
> approximate sync with RFC 2744 and it was close enough
to be useful to
> Mozilla.
>
> I include information I received from the  authors of
the patch:
>
>> This bugzilla bug shows some of Mozilla discussions
about how to include
>> gssapi.h as part of their distro.  The RFC
Copyright was too strict so
>> the Mozilla organization stated they couldn't use
the RFC version of the
>> header definitions and had to use a version from
the MIT source code
>> instead.
>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=280792#c55
>
> My personal opinion is that we, the IETF, definitely
want Mozilla and
> similar organizations to be able to pick up their
technology.
>
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wgietf.org
> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
>





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

I believe there are two problems in outbound-03 that makes
this unclear:

* outbound-03 should mention header files explicitly in the
list of
  code-like stuff.

* outbound-03 suggests that the trust shouldn't embark on a
massive
  effort to re-license older RFCs:

    Similarly, the rights granted for pre-existing documents
can not be
    expanded unless the holders of rights in those
contributions choose
    to grant expanded rights.  Nonetheless, to the degree it
can, and
    without embarking on a massive effort, it is desirable
if similar
    rights to those described below can be granted in older
RFCs.

  I suggest dropping ', and without embarking on a massive
effort'.  If
  that part is missing, it doesn't imply the IETF Trust
_should_ embark
  on a massive effort to do this.  But they can do so easily
if they
  want to.

  Btw, haven't the Trust already embarked on this effort?  I
recall
  seeing some e-mails about assigning old RFCs to the IETF
Trust.

/Simon

Harald Tveit Alvestrand <haraldalvestrand.no> writes:

> Sam,
>
> you are referring to Appendix A of RFC 2744?
>
> I believe the current content of the -outbound draft is
clear that the
> result you want is what the WG is directing the IETF
Trust to achieve.
>
> If, upon reading the -outbound draft, you think this is
not clear,
> please suggest how to make it clearer.
>
>                  Harald
>
> --On 24. juli 2007 10:22 -0400 Sam Hartman
<hartmans-ietfmit.edu> wrote:
>
>>
>>
>> Hi, folks.  I'm not currently following the IPR
working group, but I
>> wanted to share a real world problem with the group
as it illustrates
>> some of the outbound rights issues.
>>
>> Some fine folks wanted to add support for RFC 4559
to Mozilla.  That's
>> not an IETF document but does rely on a lot of IETF
technology
>> including RFC 2743 and 2744.
>>
>> RFC 2744 specifies a header file that they wanted
to use.  They were
>> unable because of the IETF copyright and because
the IETF copyright
>> did not meet Mozilla's license needs.
>>
>> Fortunately there was a work around: the authors of
RFC 1509 (a
>> previous version of RFC 2744) had donated their
header to MIT for
>> inclusion in MIT Kerberos.  MIT had tried to keep
this header in
>> approximate sync with RFC 2744 and it was close
enough to be useful to
>> Mozilla.
>>
>> I include information I received from the  authors
of the patch:
>>
>>> This bugzilla bug shows some of Mozilla
discussions about how to include
>>> gssapi.h as part of their distro.  The RFC
Copyright was too strict so
>>> the Mozilla organization stated they couldn't
use the RFC version of the
>>> header definitions and had to use a version
from the MIT source code
>>> instead.
>>
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=280792#c55
>>
>> My personal opinion is that we, the IETF,
definitely want Mozilla and
>> similar organizations to be able to pick up their
technology.
>>
>>
>> _______________________________________________
>> Ipr-wg mailing list
>> Ipr-wgietf.org
>> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
>>

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

I have no objection to mentioning header files in the code 
description.  I had intended to include ASN.1, as I believe
you had 
mentioned that previously, and I will add that.

The "no massive effort" text reflects the rough
consensus of the working group.

Yours,
Joel

At 02:43 PM 7/24/2007, Simon Josefsson wrote:
>I believe there are two problems in outbound-03 that
makes this unclear:
>
>* outbound-03 should mention header files explicitly in
the list of
>   code-like stuff.
>
>* outbound-03 suggests that the trust shouldn't embark
on a massive
>   effort to re-license older RFCs:
>
>     Similarly, the rights granted for pre-existing
documents can not be
>     expanded unless the holders of rights in those
contributions choose
>     to grant expanded rights.  Nonetheless, to the
degree it can, and
>     without embarking on a massive effort, it is
desirable if similar
>     rights to those described below can be granted in
older RFCs.
>
>   I suggest dropping ', and without embarking on a
massive effort'.  If
>   that part is missing, it doesn't imply the IETF Trust
_should_ embark
>   on a massive effort to do this.  But they can do so
easily if they
>   want to.
>
>   Btw, haven't the Trust already embarked on this
effort?  I recall
>   seeing some e-mails about assigning old RFCs to the
IETF Trust.
>
>/Simon
>
>Harald Tveit Alvestrand <haraldalvestrand.no> writes:
>
> > Sam,
> >
> > you are referring to Appendix A of RFC 2744?
> >
> > I believe the current content of the -outbound
draft is clear that the
> > result you want is what the WG is directing the
IETF Trust to achieve.
> >
> > If, upon reading the -outbound draft, you think
this is not clear,
> > please suggest how to make it clearer.
> >
> >                  Harald
> >
> > --On 24. juli 2007 10:22 -0400 Sam Hartman
<hartmans-ietfmit.edu> wrote:
> >
> >>
> >>
> >> Hi, folks.  I'm not currently following the
IPR working group, but I
> >> wanted to share a real world problem with the
group as it illustrates
> >> some of the outbound rights issues.
> >>
> >> Some fine folks wanted to add support for RFC
4559 to Mozilla.  That's
> >> not an IETF document but does rely on a lot of
IETF technology
> >> including RFC 2743 and 2744.
> >>
> >> RFC 2744 specifies a header file that they
wanted to use.  They were
> >> unable because of the IETF copyright and
because the IETF copyright
> >> did not meet Mozilla's license needs.
> >>
> >> Fortunately there was a work around: the
authors of RFC 1509 (a
> >> previous version of RFC 2744) had donated
their header to MIT for
> >> inclusion in MIT Kerberos.  MIT had tried to
keep this header in
> >> approximate sync with RFC 2744 and it was
close enough to be useful to
> >> Mozilla.
> >>
> >> I include information I received from the 
authors of the patch:
> >>
> >>> This bugzilla bug shows some of Mozilla
discussions about how to include
> >>> gssapi.h as part of their distro.  The RFC
Copyright was too strict so
> >>> the Mozilla organization stated they
couldn't use the RFC version of the
> >>> header definitions and had to use a
version from the MIT source code
> >>> instead.
> >>
> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=280792#c55
> >>
> >> My personal opinion is that we, the IETF,
definitely want Mozilla and
> >> similar organizations to be able to pick up
their technology.
> >>
> >>
> >>
_______________________________________________
> >> Ipr-wg mailing list
> >> Ipr-wgietf.org
> >> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
> >>
>
>_______________________________________________
>Ipr-wg mailing list
>Ipr-wgietf.org
>https:/
/www1.ietf.org/mailman/listinfo/ipr-wg


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

--On 24. juli 2007 20:43 +0200 Simon Josefsson <simonjosefsson.org> wrote:

> I believe there are two problems in outbound-03 that
makes this unclear:
>
> * outbound-03 should mention header files explicitly in
the list of
>   code-like stuff.

The particular example is clearly C code, so is covered by
the definition 
from section 6.3, which is the list the Trust is supposed to
start from and 
add to:

   IETF contributions often include components intended to
be directly
   processed by a computer.  Examples of these include ABNF
definitions,
   XML Schemas, XML DTDs, XML RelaxNG definitions, tables of
values,
   MIBs, or even classical programming code.

(as a minor edit, I'd suggest removing the word
"even").

> * outbound-03 suggests that the trust shouldn't embark
on a massive
>   effort to re-license older RFCs:
>
>     Similarly, the rights granted for pre-existing
documents can not be
>     expanded unless the holders of rights in those
contributions choose
>     to grant expanded rights.  Nonetheless, to the
degree it can, and
>     without embarking on a massive effort, it is
desirable if similar
>     rights to those described below can be granted in
older RFCs.
>
>   I suggest dropping ', and without embarking on a
massive effort'.  If
>   that part is missing, it doesn't imply the IETF Trust
_should_ embark
>   on a massive effort to do this.  But they can do so
easily if they
>   want to.

And if someone wants to fund it. But the piece is clearly
not contributing 
all that much to the sentence, so I (as participant) am not
against 
removing the piece.

>
>   Btw, haven't the Trust already embarked on this
effort?  I recall
>   seeing some e-mails about assigning old RFCs to the
IETF Trust.

I signed mine in Prague.



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

Harald Tveit Alvestrand <haraldalvestrand.no> writes:

> --On 24. juli 2007 20:43 +0200 Simon Josefsson
<simonjosefsson.org> wrote:
>
>> I believe there are two problems in outbound-03
that makes this unclear:
>>
>> * outbound-03 should mention header files
explicitly in the list of
>>   code-like stuff.
>
> The particular example is clearly C code, so is covered
by the
> definition from section 6.3, which is the list the
Trust is supposed
> to start from and add to:
>
>   IETF contributions often include components intended
to be directly
>   processed by a computer.  Examples of these include
ABNF definitions,
>   XML Schemas, XML DTDs, XML RelaxNG definitions,
tables of values,
>   MIBs, or even classical programming code.

I believe it could be argued that a C header file is not
"programming
code".  C header files describes an interface, it
normally do not
contain any programming code.

> (as a minor edit, I'd suggest removing the word
"even").

I agree.

>> * outbound-03 suggests that the trust shouldn't
embark on a massive
>>   effort to re-license older RFCs:
>>
>>     Similarly, the rights granted for pre-existing
documents can not be
>>     expanded unless the holders of rights in those
contributions choose
>>     to grant expanded rights.  Nonetheless, to the
degree it can, and
>>     without embarking on a massive effort, it is
desirable if similar
>>     rights to those described below can be granted
in older RFCs.
>>
>>   I suggest dropping ', and without embarking on a
massive effort'.  If
>>   that part is missing, it doesn't imply the IETF
Trust _should_ embark
>>   on a massive effort to do this.  But they can do
so easily if they
>>   want to.
>
> And if someone wants to fund it. But the piece is
clearly not
> contributing all that much to the sentence, so I (as
participant) am
> not against removing the piece.
>
>>
>>   Btw, haven't the Trust already embarked on this
effort?  I recall
>>   seeing some e-mails about assigning old RFCs to
the IETF Trust.
>
> I signed mine in Prague.

If the effort has already been initiated, retaining that
part of the
sentence makes no sense to me.

/Simon

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

"Joel M. Halpern" <joelstevecrocker.com>
writes:

> I have no objection to mentioning header files in the
code
> description.  I had intended to include ASN.1, as I
believe you had
> mentioned that previously, and I will add that.

Thanks.

> The "no massive effort" text reflects the
rough consensus of the
> working group.

The massive effort appear to have already started, so the
sentence
doesn't make sense to me.  I suspect reality has changed
since that
consensus was gauged.

/Simon


> Yours,
> Joel
>
> At 02:43 PM 7/24/2007, Simon Josefsson wrote:
>>I believe there are two problems in outbound-03 that
makes this unclear:
>>
>>* outbound-03 should mention header files explicitly
in the list of
>>   code-like stuff.
>>
>>* outbound-03 suggests that the trust shouldn't
embark on a massive
>>   effort to re-license older RFCs:
>>
>>     Similarly, the rights granted for pre-existing
documents can not be
>>     expanded unless the holders of rights in those
contributions choose
>>     to grant expanded rights.  Nonetheless, to the
degree it can, and
>>     without embarking on a massive effort, it is
desirable if similar
>>     rights to those described below can be granted
in older RFCs.
>>
>>   I suggest dropping ', and without embarking on a
massive effort'.  If
>>   that part is missing, it doesn't imply the IETF
Trust _should_ embark
>>   on a massive effort to do this.  But they can do
so easily if they
>>   want to.
>>
>>   Btw, haven't the Trust already embarked on this
effort?  I recall
>>   seeing some e-mails about assigning old RFCs to
the IETF Trust.
>>
>>/Simon
>>
>>Harald Tveit Alvestrand <haraldalvestrand.no> writes:
>>
>> > Sam,
>> >
>> > you are referring to Appendix A of RFC 2744?
>> >
>> > I believe the current content of the -outbound
draft is clear that the
>> > result you want is what the WG is directing
the IETF Trust to achieve.
>> >
>> > If, upon reading the -outbound draft, you
think this is not clear,
>> > please suggest how to make it clearer.
>> >
>> >                  Harald
>> >
>> > --On 24. juli 2007 10:22 -0400 Sam Hartman
<hartmans-ietfmit.edu> wrote:
>> >
>> >>
>> >>
>> >> Hi, folks.  I'm not currently following
the IPR working group, but I
>> >> wanted to share a real world problem with
the group as it illustrates
>> >> some of the outbound rights issues.
>> >>
>> >> Some fine folks wanted to add support for
RFC 4559 to Mozilla.  That's
>> >> not an IETF document but does rely on a
lot of IETF technology
>> >> including RFC 2743 and 2744.
>> >>
>> >> RFC 2744 specifies a header file that they
wanted to use.  They were
>> >> unable because of the IETF copyright and
because the IETF copyright
>> >> did not meet Mozilla's license needs.
>> >>
>> >> Fortunately there was a work around: the
authors of RFC 1509 (a
>> >> previous version of RFC 2744) had donated
their header to MIT for
>> >> inclusion in MIT Kerberos.  MIT had tried
to keep this header in
>> >> approximate sync with RFC 2744 and it was
close enough to be useful to
>> >> Mozilla.
>> >>
>> >> I include information I received from the 
authors of the patch:
>> >>
>> >>> This bugzilla bug shows some of
Mozilla discussions about how to include
>> >>> gssapi.h as part of their distro.  The
RFC Copyright was too strict so
>> >>> the Mozilla organization stated they
couldn't use the RFC version of the
>> >>> header definitions and had to use a
version from the MIT source code
>> >>> instead.
>> >>
>> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=280792#c55
>> >>
>> >> My personal opinion is that we, the IETF,
definitely want Mozilla and
>> >> similar organizations to be able to pick
up their technology.
>> >>
>> >>
>> >>
_______________________________________________
>> >> Ipr-wg mailing list
>> >> Ipr-wgietf.org
>> >> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
>> >>
>>
>>_______________________________________________
>>Ipr-wg mailing list
>>Ipr-wgietf.org
>>https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

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

Simon
----- Original Message ----- 
From: "Simon Josefsson" <simonjosefsson.org>
To: "Harald Tveit Alvestrand" <haraldalvestrand.no>
Cc: "Sam Hartman" <hartmans-ietfmit.edu>; <ipr-wgietf.org>
Sent: Tuesday, July 24, 2007 11:43 AM
Subject: Re: An example of the outbound rights problem


>I believe there are two problems in outbound-03 that
makes this unclear:
>
> * outbound-03 should mention header files explicitly in
the list of
>  code-like stuff.

I agree - header files are in fact CODE since they are input
and 
interpreted/processed by the code compiler/interpreter ...

>
> * outbound-03 suggests that the trust shouldn't embark
on a massive
>  effort to re-license older RFCs:

I agree with this too - trying to force those pre-existing
entities to 'give 
the IETF Trust rights which it doesnt have to those efforts'
will create a 
scenario where those that have them will feel like that they
MUST give those 
rights to the IETF or suffer being prevented - either
directly or covertly - 
from new initiatives...

It also puts the IETF in the space where it will likely be
liable that it 
changed the processes underneath the relying parties - who
already have 
existing efforts in place - to file new efforts under those
original terms 
and conditions...

The reason is simple  - many of those entities who have
already issued 
licenses under the previous IETF terms and conditions will
now demand that 
their current and future filings be under those same set of
terms and 
conditions, and the IETF is going to be hard pressed to say
"No" IMHO.

The IETF has formal contracts with those people which are
capable of being 
interpreted as permanent relationship's under those terms.
Further ANY 
revisions to those pre-existing document MUST also be done
under those same 
terms or the IETF would be again liable for stifling the
upkeep and 
evolution of those efforts who would not 'turn over all
rights to the IETF's 
Trust' something that WILL get the IETF into court on
Antitrust and Fraud By 
Wire claims I am betting...

The reasoning is simple, those licenses were already issued
to people would 
likely be upset and their lawyers may be as well, that they
cannot expand or 
rework those efforts without giving them to the IETF as
well... which would 
open the IETF to direct litigation IMHO.

There is also the issue to deal with "that changing the
scope and 
requirements for an IETF initiative may also open the IETF
to litigation as 
well as litigation against those directly involved in this
process" - and 
this scares the hell out of me since we are all in this
argument together...

The bottom line is that I dont think that the IETF Trust
will withstand the 
first legal challenge to its existence whether this WG says
it will or not. 
I further dont think that Jorge will gurantee that I am
wrong either, so 
this is a real issue I think, and its an importrant one to
address.

.
>
>    Similarly, the rights granted for pre-existing
documents can not be
>    expanded unless the holders of rights in those
contributions choose
>    to grant expanded rights.  Nonetheless, to the
degree it can, and
>    without embarking on a massive effort, it is
desirable if similar
>    rights to those described below can be granted in
older RFCs.
>
>  I suggest dropping ', and without embarking on a
massive effort'.  If
>  that part is missing, it doesn't imply the IETF Trust
_should_ embark
>  on a massive effort to do this.  But they can do so
easily if they
>  want to.
>
>  Btw, haven't the Trust already embarked on this
effort?  I recall
>  seeing some e-mails about assigning old RFCs to the
IETF Trust.
>
> /Simon
>
> Harald Tveit Alvestrand <haraldalvestrand.no> writes:
>
>> Sam,
>>
>> you are referring to Appendix A of RFC 2744?
>>
>> I believe the current content of the -outbound
draft is clear that the
>> result you want is what the WG is directing the
IETF Trust to achieve.
>>
>> If, upon reading the -outbound draft, you think
this is not clear,
>> please suggest how to make it clearer.
>>
>>                  Harald
>>
>> --On 24. juli 2007 10:22 -0400 Sam Hartman
<hartmans-ietfmit.edu> wrote:
>>
>>>
>>>
>>> Hi, folks.  I'm not currently following the IPR
working group, but I
>>> wanted to share a real world problem with the
group as it illustrates
>>> some of the outbound rights issues.
>>>
>>> Some fine folks wanted to add support for RFC
4559 to Mozilla.  That's
>>> not an IETF document but does rely on a lot of
IETF technology
>>> including RFC 2743 and 2744.
>>>
>>> RFC 2744 specifies a header file that they
wanted to use.  They were
>>> unable because of the IETF copyright and
because the IETF copyright
>>> did not meet Mozilla's license needs.
>>>
>>> Fortunately there was a work around: the
authors of RFC 1509 (a
>>> previous version of RFC 2744) had donated their
header to MIT for
>>> inclusion in MIT Kerberos.  MIT had tried to
keep this header in
>>> approximate sync with RFC 2744 and it was close
enough to be useful to
>>> Mozilla.
>>>
>>> I include information I received from the 
authors of the patch:
>>>
>>>> This bugzilla bug shows some of Mozilla
discussions about how to 
>>>> include
>>>> gssapi.h as part of their distro.  The RFC
Copyright was too strict so
>>>> the Mozilla organization stated they
couldn't use the RFC version of 
>>>> the
>>>> header definitions and had to use a version
from the MIT source code
>>>> instead.
>>>
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=280792#c55
>>>
>>> My personal opinion is that we, the IETF,
definitely want Mozilla and
>>> similar organizations to be able to pick up
their technology.
>>>
>>>
>>>
_______________________________________________
>>> Ipr-wg mailing list
>>> Ipr-wgietf.org
>>> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
>>>
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wgietf.org
> https:/
/www1.ietf.org/mailman/listinfo/ipr-wg 


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

--On 24. juli 2007 21:35 +0200 Simon Josefsson <simonjosefsson.org> wrote:

>>   IETF contributions often include components
intended to be directly
>>   processed by a computer.  Examples of these
include ABNF definitions,
>>   XML Schemas, XML DTDs, XML RelaxNG definitions,
tables of values,
>>   MIBs, or even classical programming code.
>
> I believe it could be argued that a C header file is
not "programming
> code".  C header files describes an interface, it
normally do not
> contain any programming code.

I would feel completely ridiculous making such an argument.

I also dislike the idea of making judgments based on how
source code is 
organized into files (there's often inline code in C++ .h
files, for 
instance, and Java doesn't have header files as such at
all); I believe the 
intent of the group was to include anything that's written
in a programming 
language intended to be processed by a compiler, and will be
happy to take 
suggestions on how to accurately reflect that into the
text.

             Harald





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

--On 24. juli 2007 21:39 +0200 Simon Josefsson <simonjosefsson.org> wrote:

>> The "no massive effort" text reflects the
rough consensus of the
>> working group.
>
> The massive effort appear to have already started, so
the sentence
> doesn't make sense to me.  I suspect reality has
changed since that
> consensus was gauged.

With "massive effort", we were thinking about
stuff like attempting to find 
the owners of copyrights of deceased authors, going into
prolonged 
negotiations with corporate lawyers and the like. What the
Trust has 
started is far short of that.

After thinking about it, I think I support letting the
"no massive effort" 
stay.


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