Subject: GPL and Status summary, IPR WG

From: [email-masked]
Date: Mon, 9 Jan 2006 02:11:13 -0500

Ted Hardie wrote:

> I do not think you have consensus on this.  There is consensus, I
> believe, that the community needs to be able to extract code and tables
> from the I-Ds.  "process them according to its usual process", though,
> is too vague as guidance and "incorporating them into products distributed
> under the GPL license" elides one of the problems.  If code derived
> from an RFC is GPLed, one of the rights granted by the GPL is the right
> to modify the code; it is not clear yet whether we can grant that right
> without granting the right to modify the specification.

Having talked to a lawyer about GPL issues, I know enough to be truly
dangerous ... but I am (still) not a lawyer, and this is therefore not
legal advice.  Those who assume otherwise do so at their own peril.

I concur that the issue Ted describes is not completely clear, but I am
optimistic, as it appears likely that the IETF can grant the rights
necessary to put "code" under the GPL without granting the right to
modify "the specification," but ...

... getting to a conclusion on this issue requires a fairly precise
definition of "the specification".  My view is that even for MIB modules,
where the MIB itself is intended to be relatively self-contained (and is
my working example of a code extract that is clearly not "fair use" of
the RFC), I would argue that "the specification" is the entire RFC that
defines the MIB module.  This is because that RFC includes important
explanatory text about the design of the MIB, security considerations,
etc., making the SMI source code of the MIB is a proper subset of
"the specification".

Harald's note indicated that there was rough consensus for:

  - The trust SHOULD take steps to ensure that it's clear that modifying
    an RFC or a protocol and claiming that it's the "real" RFC or protocol
    is not permitted (unless such steps interfere with the more
    important goals above).

and (IMHO) discussion on the list strongly suggests that it is acceptable
to achieve this (in part) by forbidding placement of the RFC "boilerplate"
text under the GPL or similar license (which would forbid placing any
entire RFC under the GPL or similar license).  This is not intended to be
the final word on how to address this area, but rather a "proof by example"
that it is possible to make progress here.

There is also another GPL-related issue that will need to be addressed
by the trust, namely that the copyleft provisions of the GPL can operate
in practice as a one-way "trap door" for "code" that is modified by many
hands.  There are definitely pieces of IETF "code" that are both: 
- Necessary to an implementation of the specification (e.g., many uses
	of ASN.1), and
- Candidates for future standardization if useful modifications are made.
By itself, the GPL can operate to block the latter, as the list of
"authors" who have modified the code (and hence from whom permission would
have to be obtained) can grow to intractable lengths, and it only takes
one "no" to stop the standardization.

In the extreme, if open source programmers wish to deliberately frustrate
further standardization of their work, the GPL grants them the ability
to behave in that fashion, but the GPL does not *require* them to behave
that way (NB: this conclusion is subtle - it requires careful reading of
the GPL).  There are numerous examples of the open source community taking
significant interest in interoperability of open-source code with non-open-
source systems, and hence I think it is reasonable for the IETF to ask and
encourage them to take such an interest in IETF specifications for the good
of the entire Internet, not just that portion that uses open source
software.

The means of achieving that will be less than perfect, as the additional
grant
of rights to allow future standardization MUST be voluntary, but it should
be possible to create a structure in which that grant of rights is accepted
as what SHOULD be done, and becomes what *is* done by default.  One possible
means of doing this is to "staple" a BSD license to the GPL for the "code"
extracted from an RFC, and require any programmer who wants to "remove" the
"staple" (i.e., restrict further distribution of the "code" as modified by
him/her to be under only the GPL and not the BSD license) to explicitly
"opt-out" of the BSD license in a special (or easily identifiable) history
entry of some form.  Beyond this, I would hope to encourage the open source
community to establish an environment in which such "opt-out" is
discouraged,
e.g., projects such as Debian could establish a ground rule of rejecting
contributions that "remove" the "staple".

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 09 Jan 2006 14:06:11 +0100

> modify "the specification," but ...

I agree with Ted and David here: I believe it is premature to declare
consensus on this.  I don't believe we can (or should) declare
consensus on separating the license for code and text yet.  As Ted
suggests, we haven't explored all the details.  I'm also optimistic we
can reach some useful goal, there seem to be plenty of wiggle room,
and the core interests of all concerns expressed so far appear not to
be obviously exclusive.

> that it is possible to make progress here.

Agreed.

> one "no" to stop the standardization.

Here, I believe you are exaggerating the importance of code.  It is
possible to rewrite any GPL code to preserve the same interoperability
properties, but under another license.  It is certainly possible to
describe the GPL code work in an abstract way, so it is possible to
re-implement it.

> of the entire Internet, not just that portion that uses open source

I agree.  However, I think this is a not so important aspect.  Any
open source programmer who want to deliberately frustrate
standardization would be simple to route around.  The IETF
specification doesn't have to include the code he wrote, and may not
have to include code at all.  Code is mostly added to illustrate
things.

> extracted from an RFC

This is called dual-licensing, and is common for free software.

> and require any programmer who wants to "remove" the "staple" (i.e.,
> restrict further distribution of the "code" as modified by him/her
> to be under only the GPL and not the BSD license) to explicitly
> "opt-out" of the BSD license in a special (or easily identifiable)
> history entry of some form.

This is always required.  Anyone who modify a work and redistribute it
must make clear under what permission she is granting others.

> Beyond this, I would hope to encourage the open source community to
> establish an environment in which such "opt-out" is discouraged,

They are discouraged in the same way as forks of projects are
discouraged.  But forbidding opt-out:s or forks legally harm how
projects evolve over time.

> e.g., projects such as Debian could establish a ground rule of
> rejecting contributions that "remove" the "staple".

I don't see any signs of that ever happening.  If the license is free
under the DFSG, it would be possible to package it in Debian.
However, since Debian is based on voluntary work, if the modified work
is of little importance (which is likely in the beginning) nobody will
do the work required.  If the modified work starts to gain popularity,
it may be packaged, but in this case I'm not sure where the dangers
are.

Thanks,
Simon

---

From: Jeremy Hunsinger <[email-masked]>
Date: Mon, 9 Jan 2006 08:32:01 -0500

I'm  not sure why we are talking about licenses for the code.  Wasn't  
Harald's point less about what the code is being released under, and  
more about what it had to be compatible with?   the code has to be  
usable in gpl'd applications, just like it has to be usable in eula'd  
applications.   I'm not sure why we are talking about a release  
license for this code and not talking about provisions of copyright  
for this code.    there should be consensus in that the code as  
released has to be universally usable and editable, but not re- 
releasable as rfc or id after that, without specific permission.

Jeremy Hunsinger
Center for Digital Discourse and Culture
() ascii ribbon campaign - against html mail
/\ - against microsoft attachments

http://www.aoir.org The Association of Internet Researchers
http://www.stswiki.org/ stswiki

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 09 Jan 2006 16:41:55 +0100

--On mandag, januar 09, 2006 14:06:11 +0100 Simon Josefsson 
<[email-masked]> wrote:

> suggests, we haven't explored all the details.

I don't think we have that yet either.... I think we have consensus 
(possibly consensus minus Ted? Not sure) that modified versions of code 
should be allowed - for at least some definition of "code" that includes 
the Kerberos ASN.1 modules - but I haven't seen consensus yet that:

- we know a sharp boundary between "code" and "text" that we can write down 
a definition of
- we need a separate license for "code" vs "text" - I've seen some 
argument, especially from Simon, that we should be as liberal with the 
"text" license as with the "code" license, but I've also seen considerable 
pushback on that.

For the moment, I'd like to act on the assumption that we separate the 
licenses, and that we should later return to the question of whether we can 
unify them again.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 09 Jan 2006 17:05:32 +0100

Harald Tveit Alvestrand <[email-masked]> writes:

> (possibly consensus minus Ted? Not sure) that modified versions of
> code should be allowed - for at least some definition of "code" that
> includes the Kerberos ASN.1 modules

Agreed.

> - but I haven't seen consensus yet that:
>
> - we know a sharp boundary between "code" and "text" that we can write
> down a definition of
> "text" license as with the "code" license, but I've also seen
> considerable pushback on that.

I don't think the later will be settled without detailing the former
more precisely than we have done so far.

> licenses, and that we should later return to the question of whether
> we can unify them again.

Please don't!

I see no basis for deciding this now.

There have been two serious proposals to solve the outbound rights so
far, IIRC, my document and David Black's proposal with a "field of
use" restrictions.  Neither separate text and code.  My document cover
"Contributions", as defined in RFC 3978, which include more than RFC
texts.

The idea of separating text and code was discussed briefly on-list
after the Vancouver meting.  I updated my document to discuss this
issue in -04, and presented situations where this would solve problem.
If you haven't read that section, I'm including it below for easy
reference.

Exactly what motivation do you see on the list for pushing for this
separation?

To make things clear: I am not opposed to separating the license on
code and text.  I have started writing a document to explore that idea
further.  I have talked with the FSF about this approach, and they
agreed to a specific license text that I proposed.  I have e-mailed
the Kerberos 5 authors if they would be willing to re-license the
ASN.1 module in the RFC, to have a useful example in my document.

Please don't kill the discussion on the code vs text separation.

Thanks,
Simon

7.  Separating the license for code and text

   It has been suggested that the license should be separated to cover
   code and text separately.  The intention is supposedly that code can
   use a free and GPL/BSD-compatible license, whereas the text portion
   will not.

   We argue that this solution is sub-optimal, and in particular it
   would prevent scenarios including the following:

   1.  Excerpts from RFCs included in source code comments.  This is a
       common example, many free IETF implementations embed excerpts
       from the RFC text in source code comments.

   2.  Teaching material derived from RFC texts.  University teacher may
       want to modify RFCs to illustrate a point and as an
       implementation exercises, and include the resulting work in
       freely available online course material.

   3.  Documentation for IETF implementations.  Both FreeBSD and Sun has
       shipped a getaddrinfo man page that is derived from the RFC.  I
       believe being able to inherit that text from the RFC helped
       getting getaddrinfo implemented and utilized.  If implementations
       are not permitted to do this, adoption of IETF protocols will
       likely be slower.  If we believe the IETF is producing standards
       that, if adopted, would benefit the IETF, I believe we should
       make sure they can be implemented as fast and as widely as
       possible.

   For these reasons, we argue that the same license should be used for
   both code and text.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 09 Jan 2006 17:52:53 +0100

> If you haven't read that section, I'm including it below for easy

Approximately 40 messages; slightly more than "briefly" ("one issue or two" 
and "separation" threads).

> Exactly what motivation do you see on the list for pushing for this

The fact that I see relatively clear consensus for allowing "modified 
code", but no consensus whatsoever for allowing "modified text".

I don't see consensus for *dis*allowing "modified text" either, but I'd 
like to establish the pieces of consensus that we have, so that we don't 
have to loop around *those* endlessly.

                     Harald

---

From: "Stephan Wenger" <[email-masked]>
Date: Mon, 9 Jan 2006 19:34:29 +0200

Folks,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf  Of Harald Tveit Alvestrand
> [...]
> 

Can't we just leave the distinction between "frozen" text and "modifiable
text" to the author and/or the working group?  They should have both the
expertise and the authority to decide which parts of a forthcoming RFC need
to be modifiable in the intended application.  Authors and WGs could allow
modifications of all text (perhaps except the boilerplate), or forbid any
modifications, or choose an appropriate mix...  as necessary.

To implement this proposal, we would need a copyright/licensing statement
disallowing all modifications (except translations, reformatting, ...)
except for those parts of the text marked with a token (say: BEGIN OPEN ...
END OPEN).  Marked text would be "open" -- one can do with it whatever one
wishes.

Of course, it would also be possible to have levels of protection in between
the two extremes.

Following the proposal would:
- defer fruitless discussions towards a generalized solution here to the
WGs/individual authors, where they would be handled according to the local
situation
 - burden those WGs/individual authors, at least initially (but that could
be alleviated somewhat by providing guidance by this WG)
- take care of difficult definitions (what is "code", what is a MIB, ...)
- perhaps allows us folks following the IPR WG to focus a bit more on
technology instead of meta-discussions...

Stupid idea?

Regards,
Stephan

---

From: John C Klensin <[email-masked]>
Date: Mon, 09 Jan 2006 12:49:10 -0500

Stephan,

Stupid?  No, of course not.

But it seems to me that this is just a different way to
implement the "separate 'code' and text and license them under
different terms" model.  It may well be a more practical idea
than the one I suggested, and the idea of resting the
responsibility for determining which is which, going forward,
with the relevant WGs is probably very useful.  But, otherwise,
it would seem to share most of the strengths and weaknesses of
those models.

    john

--On Monday, 09 January, 2006 19:34 +0200 Stephan Wenger
<[email-masked]> wrote:

>> From: [email-masked]
>> [mailto:[email-masked]] On  Behalf  Of Harald Tveit
>> Alvestrand
>> [...]
>> 
>> The fact that I see relatively clear consensus for allowing
>> "modified  code", but no consensus whatsoever for allowing
>> "modified text".
>> 
>> I don't see consensus for *dis*allowing "modified text"
>> either, but I'd  like to establish the pieces of consensus
>> that we have, so that we don't  have to loop around *those*
>> endlessly.
> 
> Can't we just leave the distinction between "frozen" text and
> "modifiable text" to the author and/or the working group?
> They should have both the expertise and the authority to
> decide which parts of a forthcoming RFC need to be modifiable
> in the intended application.  Authors and WGs could allow
> modifications of all text (perhaps except the boilerplate), or
> forbid any modifications, or choose an appropriate mix...  as
> necessary.
> 
> To implement this proposal, we would need a
> copyright/licensing statement disallowing all modifications
> (except translations, reformatting, ...) except for those
> parts of the text marked with a token (say: BEGIN OPEN ... END
> OPEN).  Marked text would be "open" -- one can do with it
> whatever one wishes.
> 
> Of course, it would also be possible to have levels of
> protection in between the two extremes.
> 
> - defer fruitless discussions towards a generalized solution
> here to the WGs/individual authors, where they would be
> handled according to the local situation
>  - burden those WGs/individual authors, at least initially
> (but that could be alleviated somewhat by providing guidance
> by this WG) - take care of difficult definitions (what is
> "code", what is a MIB, ...) - perhaps allows us folks
> following the IPR WG to focus a bit more on technology instead
> of meta-discussions...
> 
> Stupid idea?
> 
> Regards,
> Stephan  
> 
> 
>

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 17 Jan 2006 15:02:54 +0100

Harald Tveit Alvestrand <[email-masked]> writes:

> Approximately 40 messages; slightly more than "briefly" ("one issue or
> two" and "separation" threads).

I re-read those threads now, and I urge others to do the same.

I see nothing resembling consensus in them.  It was one $.02 idea
tossed out for consideration, and various more or less relevant
comments.

> code", but no consensus whatsoever for allowing "modified text".

By establishing that consensus, I believe you are seriously harming a
useful discussion.

If we wish to make the Trust recommendations simple, beginning the
discussion by separating "text" and "code", two terms which we have
not defined or are even close to being able to define, and which have
not been separated before within the IETF process (as far as I am
aware), seem counter to the goal of simplicity.

> I don't see consensus for *dis*allowing "modified text" either, but
> I'd like to establish the pieces of consensus that we have, so that we
> don't have to loop around *those* endlessly.

You agreed that we don't have consensus on how to separate "code" and
"text", but still you wish to continue down that road.  I don't
understand the motivation for that.  It seems like short-cutting the
interesting discussion on principles in order to achieve some
milestones that doesn't solve the expressed problems, results that may
even further complicate the license situation.

Regards,
Simon

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 17 Jan 2006 15:36:33 +0100

Simon,

> even further complicate the license situation.

I'm ruling you out of order here.

It's perfectly OK for you to argue that we need to treat text the same way 
we treat code.

But as far as I can tell, you are the only person arguing that we should 
not be conducting the discussion by considering them separately - and I 
consider THAT to be likely to derail the debate.

Welcome to "rough" consensus.

                      Harald

---

From: "todd glassey" <[email-masked]>
Date: Tue, 17 Jan 2006 07:25:01 -0800

> Welcome to "rough" consensus.

You mean a concensus of two... or three...