Subject: Re: The Law... Definition of Derivative Claims...

From: [email-masked]
Date: Wed, 18 Jan 2006 17:23:37 +0000

Joel - 
 -------------- Original message ----------------------
From: "Joel M. Halpern" <[email-masked]>
> Todd,
>      An implementation of a protocol does not require any copying rights 
> relative to the description of that protocol.

Sure it does - the use of the pseudo-code mnemonics would require exactly that. They are copyrighted and possibly also trademarked (although TM'ing the Code Statements in a programming language or TCP/IP protocol could be quite expensive... still its totally reasonable.

>      You seem to be asserting that copyright transfer is required for an 
> implementation (software or hardware) of a protocol.

I am asserting that derivative rights are needed to republish in any excerpted form other than as the 'whole enchiladas'... And that if a version of the protocol is implemented using those mnemonics and notations, that it will indeed violate the copyright against that.

>      You seem to be repeating this assertion.
>      The C (or other language) implementation does not use the words of the 
> RFC.  

No, but if the workflow of the C language is implemented in the second port it does indeed need the derivative rights granted and if the protocol was to implement the model specified in the draft or RFC it most assuredly needs those derivative rights.

Re-publication rights are just that - the rights to republish under some controlled set of circumstances.

> Copyright is only required if you make use of the words of the source 
> material.  Using the ideas of the source material does not require the 
> right to copy the source material.

Depends on how they are documented. In most instances where Copyright alone was used I may agree, but here where the code is in many instances inseparble from the RFC itself, I would disagree.

>      There is an issue with regard to the use of MIBs and such like.  Which 
> we have always intended to permit.  We may, as per some of Simon's remarks, 
> have mangled that in the last revision.  The working group has already 
> agreed to fix that.

OK - I understand that you personally and many of the IETF management have intended to allow free use of those code bodies, but they may be owned outside of the IETF's process, and so it also needs a place where it can reference or publish things it is not conveying rights to moving forward IMHO.

>      But that has absolutely nothing to do with the copyright in the text 
> of the document and the question of whether multiple entities (or even one 
> entity distinct from the copyright holders) can implement that protocol.

Actually it does with regard to pseudo-code and all that ... the distinction between Copyright and Patent controls on some IP's is blurring and these are IP's like the ones that this WG deals with continuously.

> 
>     If you wish to support your contention that a software implementation 
> of a protocol needs the copyright permission to the description of the 
> protocol (apparently, according to your view, because the protocol 
> implementation is a derivative work of a protocol description), please 
> provide very specific citation so that I do not waste the time of my legal 
> expert searching for your assertion.

I think I have already but I am willing to also take the IETF to court to settle this - not as an adversary, but to help convince that this is fact and it needs to be dealt with as such. Seriously - I am not threatening to sue anyone here - what I am saying is that I am sure that the Court's are going to look at this in a very different light than many of th IESG and IETF have painted it to date. But that is just my two cents.

> 
>      Yours,
>      Joel M. Halpern
> 
> At 10:29 AM 1/18/2006, [email-masked] wrote:
> >Harald - in your zeal to bodyslam me you missed the point - the IETF's RFC 
> >and ID documents ARE descriptions of those technologies and while the 
> >technologies themselves are not protected by the Copyright per se, the 
> >descriptions of them are, and that is what we are talking about here. What 
> >is needed in the process of republishing those documents per the rights 
> >transferred.
> >
> >-----
> >
> >Harald  why not try this - take a deep breath and realize that I am in the 
> >middle of this IP mess and its going to stay that way. So rather than 
> >fight me and make me adversarial to you folks - why not ask me to 
> >demonstrate the key issues of my complaints and figure whether the risks 
> >of not addressing them are more than the cost of your distaste for me 
> >personally.\
> >
> >By the way - good morning...
> >
> >Todd
> >
> >  -------------- Original message ----------------------
> >From: Harald Tveit Alvestrand <[email-masked]>
> > >
> > >
> > > --On tirsdag, januar 17, 2006 14:25:06 -0800 todd glassey
> > > <[email-masked]> wrote:
> > >
> > > > Lets look at some law links Harald ...
> > > >
> > > > this one is for the definition of Copyright and its Claims - American Bar
> > > > Association - notice commentary on derivative copyrights.
> > > > http://www.abanet.org/intelprop/comm106/106copy.html Read through the
> > > > Derivative Licenses setion if you would.
> > >
> > > It does not seem to suport your argument about the second implementation:
> > >
> > > WHAT IS NOT PROTECTED BY COPYRIGHT
> > >
> > > Ideas, procedures, methods, systems, processes, concepts, principles,
> > > discoveries, or devices, as distinguished from a description, explanation,
> > > or illustration.
> > >
> > > _______________________________________________
> > > Ipr-wg mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/ipr-wg
> >
> >
> >
> >_______________________________________________
> >Ipr-wg mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/ipr-wg
> 

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

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 18 Jan 2006 16:36:35 -0800

> I am asserting that derivative rights are needed to republish 
> in any excerpted form other than as the 'whole enchiladas'... 
> And that if a version of the protocol is implemented using 
> those mnemonics and notations, that it will indeed violate 
> the copyright against that.

To the extent that copying an expressive piece of code is necessary for an
implementation of a functional protocol in a published standard that we
*intend* to be implemented, copyright can't prevent the copying. This is
based on the "merger doctrine," as expressed in the section of the Copyright
Act that Harald previously referenced. And when a change to that code is
required in order to achieve a functional result, that change can't be
prevented based on an exclusive right to create derivative works.

That would give long-term copyright way too much power to control
technology. The law doesn't countenance that. If you want your software
ideas not to be copied and evolved, either keep them secret or patent them;
don't expect copyright law to help you.

IETF's current procedures for in-bound and out-bound IP are not clear about
this. That's why I'm delighted that this working group is trying to clean up
those procedures.

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, technology law offices (www.rosenlaw.com)
Stanford University School of Law, Lecturer in Law
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242  *  fax: 707-485-1243
Author of "Open Source Licensing: Software Freedom and 
   Intellectual Property Law" (Prentice Hall 2004) 
   [Available also at www.rosenlaw.com/oslbook.htm]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, January 18, 2006 9:24 AM
> To: Joel M. Halpern; Harald Tveit Alvestrand; [email-masked]
> Subject: Re: The Law... Definition of Derivative Claims...
> 
> Joel -
> >      An implementation of a protocol does not require any copying 
> > rights relative to the description of that protocol.
> 
> Sure it does - the use of the pseudo-code mnemonics would 
> require exactly that. They are copyrighted and possibly also 
> trademarked (although TM'ing the Code Statements in a 
> programming language or TCP/IP protocol could be quite 
> expensive... still its totally reasonable.
> 
> >      You seem to be asserting that copyright transfer is 
> required for 
> > an implementation (software or hardware) of a protocol.
> 
> I am asserting that derivative rights are needed to republish 
> in any excerpted form other than as the 'whole enchiladas'... 
> And that if a version of the protocol is implemented using 
> those mnemonics and notations, that it will indeed violate 
> the copyright against that.
> 
> >      The C (or other language) implementation does not use 
> the words 
> > of the RFC.
> 
> No, but if the workflow of the C language is implemented in 
> the second port it does indeed need the derivative rights 
> granted and if the protocol was to implement the model 
> specified in the draft or RFC it most assuredly needs those 
> derivative rights.
> 
> Re-publication rights are just that - the rights to republish 
> under some controlled set of circumstances.
> 
> 
> Depends on how they are documented. In most instances where 
> Copyright alone was used I may agree, but here where the code 
> is in many instances inseparble from the RFC itself, I would disagree.
> 
> >      There is an issue with regard to the use of MIBs and 
> such like.  
> > Which we have always intended to permit.  We may, as per some of 
> > Simon's remarks, have mangled that in the last revision.  
> The working 
> > group has already agreed to fix that.
> 
> OK - I understand that you personally and many of the IETF 
> management have intended to allow free use of those code 
> bodies, but they may be owned outside of the IETF's process, 
> and so it also needs a place where it can reference or 
> publish things it is not conveying rights to moving forward IMHO.
> 
> >      But that has absolutely nothing to do with the 
> copyright in the 
> > text of the document and the question of whether multiple 
> entities (or 
> > even one entity distinct from the copyright holders) can 
> implement that protocol.
> 
> Actually it does with regard to pseudo-code and all that ... 
> the distinction between Copyright and Patent controls on some 
> IP's is blurring and these are IP's like the ones that this 
> WG deals with continuously.
> 
> > 
> >     If you wish to support your contention that a software 
> > implementation of a protocol needs the copyright permission to the 
> > description of the protocol (apparently, according to your view, 
> > because the protocol implementation is a derivative work of 
> a protocol 
> > description), please provide very specific citation so that 
> I do not 
> > waste the time of my legal expert searching for your assertion.
> 
> I think I have already but I am willing to also take the IETF 
> to court to settle this - not as an adversary, but to help 
> convince that this is fact and it needs to be dealt with as 
> such. Seriously - I am not threatening to sue anyone here - 
> what I am saying is that I am sure that the Court's are going 
> to look at this in a very different light than many of th 
> IESG and IETF have painted it to date. But that is just my two cents.
> 
> 
> > 
> >      Yours,
> >      Joel M. Halpern
> > 
> > >Harald - in your zeal to bodyslam me you missed the point - the 
> > >IETF's RFC and ID documents ARE descriptions of those technologies 
> > >and while the technologies themselves are not protected by the 
> > >Copyright per se, the descriptions of them are, and that 
> is what we 
> > >are talking about here. What is needed in the process of 
> republishing 
> > >those documents per the rights transferred.
> > >
> > >-----
> > >
> > >Harald  why not try this - take a deep breath and realize 
> that I am 
> > >in the middle of this IP mess and its going to stay that way. So 
> > >rather than fight me and make me adversarial to you folks 
> - why not 
> > >ask me to demonstrate the key issues of my complaints and figure 
> > >whether the risks of not addressing them are more than the cost of 
> > >your distaste for me personally.\
> > >
> > > > > this one is for the definition of Copyright and its Claims - 
> > > > > American Bar Association - notice commentary on 
> derivative copyrights.
> > > > > http://www.abanet.org/intelprop/comm106/106copy.html Read 
> > > > > through the Derivative Licenses setion if you would.
> > > >
> > > > Ideas, procedures, methods, systems, processes, concepts, 
> > > > principles, discoveries, or devices, as distinguished from a 
> > > > description, explanation, or illustration.
> > > >

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 19 Jan 2006 09:52:09 +0100

> prevented based on an exclusive right to create derivative works.

Interesting.  How much modifications are permitted?  If what you say
is true, it seems third parties already have some leeway to argue that
they have the right to incorporate ASN.1 schemas and make
modifications to them, regardless of the IETF outbound copying
conditions.

Making those rights clear is still useful, of course, because it will
educate IETF participants how their documents will likely be used.

Regards,
Simon

---

From: "Lawrence Rosen" <[email-masked]>
Date: Thu, 19 Jan 2006 11:49:11 -0800

> > To the extent that copying an expressive piece of code is necessary 
> > for an implementation of a functional protocol in a 
> published standard 
> > that we
> > *intend* to be implemented, copyright can't prevent the 
> copying. This 
> > is based on the "merger doctrine," as expressed in the 
> section of the 
> > Copyright Act that Harald previously referenced. And when a 
> change to 
> > that code is required in order to achieve a functional result, that 
> > change can't be prevented based on an exclusive right to 
> create derivative works.
> 
> Interesting.  How much modifications are permitted?  If what 
> you say is true, it seems third parties already have some 
> leeway to argue that they have the right to incorporate ASN.1 
> schemas and make modifications to them, regardless of the 
> IETF outbound copying conditions.

I do not suggest that we live with implied rights based on the merger
doctrine. We should make our rules explicit. That way your question ["How
much modifications are permitted?"] won't have to be analyzed by everyone
who wants to implement our specifications.

My note was merely intended to suggest that Todd is quite wrong when he
asserts that the exclusive right of authors to create derivative works
automatically makes IETF specifications unavailable for implementation and
modification. 

/Larry

Lawrence Rosen

> From: Simon Josefsson [mailto:[email-masked]] 
> Sent: Thursday, January 19, 2006 12:52 AM
> To: [email-masked]
> Cc: [email-masked]
> > To the extent that copying an expressive piece of code is necessary 
> > for an implementation of a functional protocol in a 
> published standard 
> > that we
> > *intend* to be implemented, copyright can't prevent the 
> copying. This 
> > is based on the "merger doctrine," as expressed in the 
> section of the 
> > Copyright Act that Harald previously referenced. And when a 
> change to 
> > that code is required in order to achieve a functional result, that 
> > change can't be prevented based on an exclusive right to 
> create derivative works.
> 
> Interesting.  How much modifications are permitted?  If what 
> you say is true, it seems third parties already have some 
> leeway to argue that they have the right to incorporate ASN.1 
> schemas and make modifications to them, regardless of the 
> IETF outbound copying conditions.
> 
> Making those rights clear is still useful, of course, because 
> it will educate IETF participants how their documents will 
> likely be used.
> 
> Regards,
> Simon