headers
Russ Housley | 10 May 2010 16:33

Inclusion of code with its own copyright in IETF documents

RFC 5378 says:

   It is also important to note that additional copyright notices are
   not permitted in IETF Documents except in the case where such
   document is the product of a joint development effort between the
   IETF and another standards development organization or is a
   republication of the work of another standards development
   organization.

This has prevented the authors of two different documents from including
the code that they wanted in their document.

Here is the header that was part of the code that the authors wanted to
include:

/*
 * This is a copy of getopt provided for those systems that do not
 * have it. The name was changed to xgetopt to not conflict on those
 * systems that do have it. Similarly, optarg, optind and opterr
 * were renamed to xoptarg, xoptind and xopterr.
 *
 * Copyright 1990, 1991, 1992 by the Massachusetts Institute of
 * Technology and UniSoft Group Limited.
 *
 * Permission to use, copy, modify, distribute, and sell this software
 * and its documentation for any purpose is hereby granted without fee,
 * provided that the above copyright notice appear in all copies and
 * that both that copyright notice and this permission notice appear in
 * supporting documentation, and that the names of MIT and UniSoft not
 * be used in advertising or publicity pertaining to distribution of
(Continue reading)

Permalink | Reply |
headers
Tony Hansen | 10 May 2010 17:09
Picon
Favicon

Re: Inclusion of code with its own copyright in IETF documents

Russ, thanks for starting this conversation.

For completeness, what was the other example?

As more information to the list, the getopt code was part of a library 
test harness provided with the RFC. The authors of the spec had several 
choices:

*) remove the code entirely, since the test harness was not required for 
the proper function of the library routines, and hope the users of the 
code had a version of getopt they could use; or
*) provide a pointer to an earlier version of the document that became 
an RFC prior to 5378, that also had that code present; or
*) write a new (yet another) implementation of getopt that could be 
coverable by the IETF license.

     Tony Hansen
     tony <at> att.com

On 5/10/2010 10:33 AM, Russ Housley wrote:
> RFC 5378 says:
>
>     It is also important to note that additional copyright notices are
>     not permitted in IETF Documents except in the case where such
>     document is the product of a joint development effort between the
>     IETF and another standards development organization or is a
>     republication of the work of another standards development
>     organization.
>
> This has prevented the authors of two different documents from including
(Continue reading)

Permalink | Reply |
headers
Martin J. Dürst | 11 May 2010 03:44
Picon
Gravatar

Re: Inclusion of code with its own copyright in IETF documents

On 2010/05/11 0:09, Tony Hansen wrote:

> As more information to the list, the getopt code was part of a library
> test harness provided with the RFC. The authors of the spec had several
> choices:
>
> *) remove the code entirely, since the test harness was not required for
> the proper function of the library routines, and hope the users of the
> code had a version of getopt they could use; or
> *) provide a pointer to an earlier version of the document that became
> an RFC prior to 5378, that also had that code present; or

What about 'provide a pointer to another place/publication that has the 
code'? (independent of whether that was an RFC or not). There's no 
difficulty in publishing and republishing code under the licenses we are 
thinking about in this thread, if they are not already published 
somewhere anyway (as would be the case for most open-source,... projects).

There's a certain amount of "not published here" syndrome in the IETF, 
as in many other organizations, but we shouldn't take that too far, 
especially in such an edge case.

Regards,    Martin.

> *) write a new (yet another) implementation of getopt that could be
> coverable by the IETF license.
>
> Tony Hansen
> tony <at> att.com
(Continue reading)

Permalink | Reply |
headers
Simon Josefsson | 10 May 2010 17:12
Favicon
Gravatar

Re: Inclusion of code with its own copyright in IETF documents

Russ Housley <housley <at> vigilsec.com> writes:

> RFC 5378 says:
>
>    It is also important to note that additional copyright notices are
>    not permitted in IETF Documents except in the case where such
>    document is the product of a joint development effort between the
>    IETF and another standards development organization or is a
>    republication of the work of another standards development
>    organization.
>
> This has prevented the authors of two different documents from including
> the code that they wanted in their document.

I believe there are other parts of RFC 5378 which are problematic here.
I ran into the same problem when we published RFC 4648, the draft
originally contained source code for base64 encoding/decoding.

> Here is the header that was part of the code that the authors wanted to
> include:
>
> /*
>  * This is a copy of getopt provided for those systems that do not
>  * have it. The name was changed to xgetopt to not conflict on those
>  * systems that do have it. Similarly, optarg, optind and opterr
>  * were renamed to xoptarg, xoptind and xopterr.
>  *
>  * Copyright 1990, 1991, 1992 by the Massachusetts Institute of
>  * Technology and UniSoft Group Limited.
>  *
(Continue reading)

Permalink | Reply |
headers
todd glassey | 10 May 2010 17:48
Picon
Favicon

Re: Inclusion of code with its own copyright in IETF documents

On 5/10/2010 7:33 AM, Russ Housley wrote:
> RFC 5378 says:
> 
>    It is also important to note that additional copyright notices are
>    not permitted in IETF Documents except in the case where such
>    document is the product of a joint development effort between the
>    IETF and another standards development organization or is a
>    republication of the work of another standards development
>    organization.
> 
> This has prevented the authors of two different documents from including
> the code that they wanted in their document.

Yes and it will continue to as long as there is no place to review the
copyright statements for each protocol online as another WG specific
Website Content but hey that's another issue in making it easier to use
the IETF.

> 
> Here is the header that was part of the code that the authors wanted to
> include:
> 
> /*
>  * This is a copy of getopt provided for those systems that do not
>  * have it. The name was changed to xgetopt to not conflict on those
>  * systems that do have it. Similarly, optarg, optind and opterr
>  * were renamed to xoptarg, xoptind and xopterr.
>  *
>  * Copyright 1990, 1991, 1992 by the Massachusetts Institute of
>  * Technology and UniSoft Group Limited.
(Continue reading)

Permalink | Reply |
headers
Marshall Eubanks | 10 May 2010 18:21
Picon

Re: Inclusion of code with its own copyright in IETF documents


On May 10, 2010, at 10:33 AM, Russ Housley wrote:

> RFC 5378 says:
>
>   It is also important to note that additional copyright notices are
>   not permitted in IETF Documents except in the case where such
>   document is the product of a joint development effort between the
>   IETF and another standards development organization or is a
>   republication of the work of another standards development
>   organization.
This paragraph also includes
"Such exceptions must be approved on an individual basis by the IAB."
So, from a procedural point of view, could MIT be viewed as a
>  standards development organization
and a waiver applied to from the IAB ?

This, of course, would be pushing the envelope, and I am not  
necessarily proposing it, but
MIT has certainly been responsible for the development of de facto  
standards, and a IAB waiver does imply a sanity check and community  
input.

>
> This has prevented the authors of two different documents from  
> including
> the code that they wanted in their document.
>
> Here is the header that was part of the code that the authors wanted  
> to
(Continue reading)

Permalink | Reply |
headers
Stephan Wenger | 10 May 2010 19:18

Re: Inclusion of code with its own copyright in IETF documents

Hi all,

As Simon has pointed out, we had this discussion before.  At length.  From
my viewpoint, nothing substantial has changed; we simply have two more
drafts where the authors believe that the inclusion of code would benefit
the document, and where that code is (only?) available under a license
different from the license the trust has approved.

My personal position with respect to dual licensing is unchanged: the can of
worms opened through dual licensing is too big for the, in my opinion, small
benefits gained through the inclusion of source code under non
Trust-approved licenses.  IETF documents, in their vast majority are
human-readable text documents, and code components should IMO be used only
for illustrative purposes, examples, etc.  Re-implementing a short piece of
example code is IMO not too onerous.  Even better (from an illustration
viewpoint) would probably be pseudo code.

As for:

On 5.10.2010 09:21 , "Marshall Eubanks" <tme <at> americafree.tv> wrote:

> 
> [...]
> 
> s/standards development organization/standards development
> organization or other entity under license terms compatible with the
> intended licensing standards of the IETF (such as software made
> available under a BSD or similar license)./
>   exceptions must be approved on an individual basis by the IAB.
>
(Continue reading)

Permalink | Reply |
headers
Don Armstrong | 11 May 2010 03:04
Picon
Favicon

Re: Inclusion of code with its own copyright in IETF documents

On Mon, 10 May 2010, Stephan Wenger wrote:
> As Simon has pointed out, we had this discussion before. At length.
> From my viewpoint, nothing substantial has changed; we simply have
> two more drafts where the authors believe that the inclusion of code
> would benefit the document, and where that code is (only?) available
> under a license different from the license the trust has approved.
> 
> My personal position with respect to dual licensing is unchanged:

What's actually being discussed is not dual-licensing,[1] but a
combined work which has sections under one license, and sections under
another.

> I'm not convinced that we have a problem at all. That said, if the
> community consensus were different, I would suggest that the Trust
> conducts a study of commonly used open source licenses, identifies
> those with a similar (or the same) business intention as the
> Trust-approved BSD-style license, and creates and publishes a
> "positive list" of licenses deemed "similar" in Marshall's sense.
> That list could be provided as an input to the IAB, to help them
> issuing waivers.

The critical aspect is whether the right set of outbound rights is
able to be granted. Since the BSD-style licenses (and other, more
permisive licenses) which grant use, modification, and redistribution
with and without modifications without any restrictions satisfy these
requirements, there's no reason to disallow code that falls under them
for license issues.[2]

This precludes code under copyleft licenses, patent reciprocity
(Continue reading)

Permalink | Reply |
headers
Simon Josefsson | 11 May 2010 09:28
Favicon
Gravatar

Re: Inclusion of code with its own copyright in IETF documents

Don Armstrong <don <at> debian.org> writes:

> On Mon, 10 May 2010, Stephan Wenger wrote:
>> As Simon has pointed out, we had this discussion before. At length.
>> From my viewpoint, nothing substantial has changed; we simply have
>> two more drafts where the authors believe that the inclusion of code
>> would benefit the document, and where that code is (only?) available
>> under a license different from the license the trust has approved.
>> 
>> My personal position with respect to dual licensing is unchanged:
>
> What's actually being discussed is not dual-licensing,[1] but a
> combined work which has sections under one license, and sections under
> another.

I believe it is even more complicated than that: the original authors do
not mix-license their work directly, but give the document to the IETF
under the (single) RFC 5378 inbound-license, and it is the IETF that
gives an mixed outbound-license to third parties.

This model is complex and I have suggested a simpler approach: allow
authors to publish their documents under a permissive license and have
IETF publish that work, which the IETF is legally allowed to do under
the permissive license, and third parties can directly use the document
under the permissive license.  The permissive license should be
maximally compatible with all other relevant licenses, thus effectively
similar to public domain.

I still haven't seen convincing arguments why this approach would cause
significant pains for the IETF community.  Given the fuss about changing
(Continue reading)

Permalink | Reply |
headers
John C Klensin | 11 May 2010 16:25

Re: Inclusion of code with its own copyright in IETF documents

I like this idea.   It saves our having to re-fight this war and
all of the associated ones each time a new case arises, prevents
having to keep adding rules and exceptions to tune for
particular situations, and doesn't prevent authors from picking
the "just reference something else" alternative where that makes
sense.

    john

--On Monday, 10 May, 2010 12:21 -0400 Marshall Eubanks
<tme <at> americafree.tv> wrote:

> 
> On May 10, 2010, at 10:33 AM, Russ Housley wrote:
> 
>> RFC 5378 says:
>> 
>>   It is also important to note that additional copyright
>>   notices are not permitted in IETF Documents except in the
>>   case where such document is the product of a joint
>>   development effort between the IETF and another standards
>>   development organization or is a republication of the work
>>   of another standards development organization.
> This paragraph also includes
> "Such exceptions must be approved on an individual basis by
> the IAB."
> So, from a procedural point of view, could MIT be viewed as a
>>  standards development organization
> and a waiver applied to from the IAB ?
>
(Continue reading)

Permalink | Reply |
headers
t.petch | 7 Jun 2010 18:14

Missing IPR

Recently, I found a number of 'IETF' mailing lists that neither provide a
current 'Note Well' on subscription nor do so on a monthly reminder, to whit:

ietf-ssh <at> NetBSD.org
uri <at> w3.org
v6ops <at> psg.com

I posted this to the main IETF list, as some of you will have seen, and got a
response that the Trustees would look into it.  I post it here for the record
and for the benefit of anyone who does not track the main list and might have
some more ideas.

I appreciate that this WG has provided all the 'mechanics' needed and it is up
to the operational side to make it happen, but it is less clear to me who might
do what in that area.

Tom Petch
Permalink | Reply |
headers
Peter Saint-Andre | 7 Jun 2010 22:43
Favicon

Re: Missing IPR

On 6/7/10 10:14 AM, t.petch wrote:
> Recently, I found a number of 'IETF' mailing lists that neither provide a
> current 'Note Well' on subscription nor do so on a monthly reminder, to whit:
> 
> ietf-ssh <at> NetBSD.org
> uri <at> w3.org
> v6ops <at> psg.com

public-iri <at> w3.org is another one.

I mentioned this on the IESG list and someone from the Secretariat
mentioned that they had an inquiry into the W3C about it.

Peter

--

-- 
Peter Saint-Andre
https://stpeter.im/
Attachment (smime.p7s): application/pkcs7-signature, 6820 bytes
_______________________________________________
Ipr-wg mailing list
Ipr-wg <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipr-wg
Permalink | Reply |

Gmane