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

From: Russ Housley <[email-masked]>
Date: Mon, 10 May 2010 10:33:20 -0400

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
 * the software without specific, written prior permission.  MIT and
 * UniSoft make no representations about the suitability of this
 * software for any purpose.  It is provided "as is" without express
 * or implied warranty.
 *
 * $XConsortium: getopt.c,v 1.2 92/07/01 11:59:04 rws Exp $
 * NB: Reformatted to match above style.
 */

Are we really serving the community by preventing the inclusion of such
code components?  If we do want to allow them, how would we adjust the
rules?

Russ

---

From: Tony Hansen <[email-masked]>
Date: Mon, 10 May 2010 11:09:31 -0400

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
     [email-masked]

On 5/10/2010 10:33 AM, Russ Housley wrote:
> _______________________________________________
> Ipr-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipr-wg
>

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 10 May 2010 17:12:14 +0200

> 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.

> code components?  If we do want to allow them, how would we adjust the

This was discussed at length before RFC 5378 was published.  I argued
then, and still believes, that it should be possible to include code
components under various licenses (including free software licenses such
as the MIT license) in IETF documents.  Alas, I recall there were fairly
strong pushback from some people on this.

Hopefully time has changed and we can reconsider this decision.

/Simon

---

From: todd glassey <[email-masked]>
Date: Mon, 10 May 2010 08:48:02 -0700

> 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.

> code components?  If we do want to allow them, how would we adjust the

No of course not... we need an open transparent model allowing for the
proper outgoing licenses... and they are simply a battle we should not
fight and can preserve through our process without any pain.

> Russ

How about the following - strip the existing outgoing use rules out of
the IETF distribution for the purpose of this conversation since those
are what trip us up every time.

Then we restriict the outgoing "Use License" so there is no implementr's
rights in it, and those are codified in yet another license which is
where are the fun happens anyway.

We are all agreed that the Outgoing License can not exceed the scope of
the Incoming License Grant, especially with regard to derivative works.
And while the IETF itself can get around most of this for publication of
its originals by just claiming Research Exemption under US and other
Copyright Act's that exemption will not carry through to the IETF's
license against IP it doesn't own or have rights to redefine or for that
matter define any Right To Use Licenses (aka the Outgoing IP Licenses).
That means it doesn't matter what's in the license if the incoming and
release rights don't specifically address the different submission and
republication models the IETF wants to meet.

How did we get here?
---------------------
Bluntly - too many voices and not enough work on the specific goals to
accomplish...

I think the Goals are simple

	1) Provide for methods of bringing IP into the IETF
	2) Provide for (c) controls on IETF Vetting Efforts and Value Add
activities
	3) Provide for republication rights against IETF documents
	4) Provide for use-licensing for implementation of IETF works in the
real world.

The question is how to do this and the answer is simple... the #1 is IP
INTAKE - the Submission/IP Grant Agreement to the IETF. #2 is NOTEWELL
and the VETTING work Licenses, #3 is to allow those outside of the IETF
to reprint the IETF documents in furtherance of the IETF vetting
processes. And #4 is then the license for commercial users to both
reprint for their commercial use and to implement those protocols.

NOTEWELL is handled pretty much and so is the Submission Contract, so
the real issue is two licenses needed outside the IETF Research And
Development Work Stream which *** ALL republication work is handled by
(C) section 107 "Research Exemptions" *** and so no other license is
needed for its use within the IETF process.

What's the fix?
---------------
So three licenses instead of two...

Incoming License - includes all Grant of IP License to develop and own
any and all rights to derivatives produced through the NOTEWELL public
vetting process the IETF provides.

Outgoing Republication License - provides to commercial and private
parties outside the Standards Practice world where (c) 107 exemptions
mean no license is necessary, to reprint these works for their own uses,
as long as they are reproduced with the IETF(C) controls properly included.

Outgoing Implementation License - This is a Derivative Works License
that the principals in any Vetting Effort within a WG would convey to
the Trust allowing the Trust to actually provide the commercial rights
to use this IP.

The Implementor's License
-------------------------
Wow - how simple eh? "An Implementor's License" for the Protocol which
will really meet the needs of all of the IP Submitters.

That Implementor's License would be slightly different for each
submission model that is supported and will go a much longer way to
properly documenting IETF IP licenses which are meant to also create
free or open product technologies.

This release and license model will allow for OpenSource,
CreativeCommon's, MIT style licenses, BSD style licenses and for that
matter any other including Commercial ones to be implemented.

Todd

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 10 May 2010 12:21:24 -0400

>   republication of the work of another standards development
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.

> Here is the header that was part of the code that the authors wanted  

This is in RFC 4634 - can't they just quote that RFC ? Or point to it  
by reference ?

There are similar terms in (at least)
RFC 1147 and 1470 and, also, RFCs 1144 and 1977 (at least) have code  
that is copyright by the "Regents of the University of California"

It seems like a simple fix would be to change the text to something like

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. Such

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.

> code components?  If we do want to allow them, how would we adjust the

This is not a BSD license, or an MIT license (http://www.opensource.org/licenses/mit-license.html 
), but is more or less along the same lines (without a warranty clause).

I admit it would make me nervous to start including random license  
terms in Trust documents, as poorly written terms might get us into  
trouble down in the road.

Regards
Marshall

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 10 May 2010 10:18:32 -0700

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" <[email-masked]> wrote:

> [...]

The difficulty here is to identify what would qualify as a "similar"
license.  In the example that started this discussion, the license involved
are the MIT license and the simplified BSD license.  I would agree that
those licenses, in their implications to both rightholders and rightusers,
as very similar.  Dual licensing with the Trust-approved BSD-style license
and the MIT license seems uncritical to me.

However, many open source licenses provide terms that are substantially
different than the BSD and MIT licenses.  Some open source licenses
explicitly forbid dual licensing.  Others explicitly grant patent rights.
Still others require re-contribution of code changes to the project (a part
of the copyleft concept).  Allowing dual-licensing with the Trust-approved
BSD style license and any of those licenses, IMO, opens the mentioned can of
worms.  I could re-iterate the argument against it here, but they can easily
be found in the archives as well.

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.

If we were so inclined, we could also go through the more heavyweight
process of re-opening RFC5378, to capture a similar mechanism.  (Please not
:-)

In the absence of new arguments, I plan to speak against any proposal that
goes further.

Regards,
Stephan

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 11 May 2010 10:44:15 +0900

> 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.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Don Armstrong <[email-masked]>
Date: Mon, 10 May 2010 18:04:30 -0700

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.

> 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
licenses, or any other set of restrictive licences which the community
has objected to.

Don Armstrong

1: dual-licensing refers to the practice of having an entire work
available under two (or more, as in triple-licensing) licenses. See
perl or Mozilla for examples of large projects using dual or triple
licensing.

2: The technical reasons to avoid including code are something that
should be handled elsewhere.
-- 
What I can't stand is the feeling that my brain is leaving me for 
someone more interesting.

http://www.donarmstrong.com              http://rzlab.ucr.edu

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 11 May 2010 09:28:17 +0200

> combined work which has sections under one license, and sections under

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
license headers in documents, this thread, and other issues, it seems
clear that the current solution have caused pains for the IETF
community.

> requirements, there's no reason to disallow code that falls under them

I agree.

/Simon

---

From: John C Klensin <[email-masked]>
Date: Tue, 11 May 2010 10:25:35 -0400

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
<[email-masked]> wrote:

>>   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.
> 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 is in RFC 4634 - can't they just quote that RFC ? Or
> point to it by reference ?
> 
> RFC 1147 and 1470 and, also, RFCs 1144 and 1977 (at least)
> have code that is copyright by the "Regents of the University
> of California"
> 
> 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. Such
> 
> 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)./