Development of Creative Commons licenses

[James Grimmelmann <james AT grimmelmann.net>]

Evan Prodromou wrote:
> On Wed, 2007-24-01 at 09:15 -0500, James Grimmelmann wrote:
>
> > > But as of
> > > late, he decided to put a license on the specification document, which
> > > is to be submited to the IETF as an RFC.
> > >
> > > The license he chose was CC-BY-ND,
>
> > Net takeaway: ND is ineffectual here.  It might help prevent some drift 
> > in the official standards document, but as long as that's available 
> > someplace canonical, there's no serious worry that the 
> > description-of-what-is would drift anyway.  Given that, CC-BY seems like 
> > a perfectly reasonable license for the description.
>
> I'd have to disagree. The IETF has its own idiosyncratic copyright rules
> for RFCs and other contributions. It's worth reviewing RFC 3978, which I
> think is the latest update to these rules:
>
> http://www.ietf.org/rfc/rfc3978.txt

These rules are not quite on point.  They relate to the rights that 
contributors and editors grand to the IETF itself to copy and modify 
submissions in the process of producing and distributing standards.  The 
IETF allows contributors to state limitations (sec. 5.2), but the IETF 
doesn't attempt to enforce its own limitations through this RFC.

> The usual deal with RFCs is that they may be copied verbatim by the
> public in any medium, for commercial or non-commercial use. Derivative
> works may also be published as part of the RFC framework. This is pretty
> close to the by-nd license terms, at least in spirit, but there are some
> twists and turns that may be incompatible with by-nd.

My point was that many of the ND restrictions are unenforceable under 
U.S. copyright law, and the same applies to this statement of IETF RFC 
policies.  Certainly the positive grants can be relied on (anyone can 
make verbatim copies), but my take is also that many non-verbatim copies 
are legal.

> In other words, if you're going the RFC route, it's probably best to not
> screw around with CC licenses and just stick with the IETF's rules.

This strikes me as sensible; if you're going to the IETF, follow IETF 
rules.  Just don't expect those rules to suffice to prevent forking and 
incompatibility.

James