Subject: Re: One copyright issue or Two?

From: [email-masked]
Date: Tue, 15 Nov 2005 18:37:49 +0000

Simon - here is another interesting situation that is important to this WG's operations. That being what is happening with that piece of "malware" (used here as a TOA and my own description) inserted by SONY/BMG into their CD's...

http://www.the-interweb.com/serendipity/index.php?/archives/52-Is-Sony-in-violation-of-the-LGPL-Part-II.html

Please notice this is an instance where this LGPL code was indeed used without a release or otherwise anckonledgement as the LGPL license requires. Now if the code owners do nothing about this infringement - then Sony and ANYONE would have a clear precedent to claim that the original code owner 'abandoned their IP rigths to that code' in my opinion...

Which is why its so important to build good and enforceable IP rules for this organization, including ones where there is a clear legal recourse given for unauthorized use including possibly arbitration and the clear statements about attorney fees in re litigation to clean any indiscretions or violations up...

Just my two cents.

Todd

 -------------- Original message ----------------------
From: Simon Josefsson <[email-masked]>
> [email-masked] writes:
> 
> >> > In doing so, it appears that attempts are being made to resolve the
> >> > discussion with a single solution when I believe the two can and should
> >> > be addressed separately, as to me they merit very different solutions.
> >
> > They HAVE to be addressed separately, as derivative rights dont come
> > through simple copyright...
> 
> Sorry, I don't follow.  Copying conditions can clearly be used to
> permit derivative works.  What are you thinking of here?
> 
> >> Where do we draw the line between source code and text?  
> >
> > yes. Well that also is a very simple question to answer. Is FBNF a
> > programming language? Yep. Is it a modeling language for which there
> > are RPG tools to convert the models into exwecutable code? YEP... so
> > then is there really a question as to what FBNF or ASN.1 or any of
> > the other psuedocoding models that are used qualify as?
> 
> What is your answer for ASN.1 or FNBF?  To me, it isn't a simple
> question.
> 
> >> For example,
> >> is ABNF code or text?
> >
> > Code... As noted above - It is Pseudocode and as such needs to be
> > controlled with more than a copyright. It is no different than say
> > "Stage one" output of a multi-pass compiler for instance.
> 
> What control beyond copyright are you talking about here?  I thought
> this discussion was solely about copyright.
> 
> >> Secondly, the text of RFCs is widely used inside comments in source
> >> code.  
> >
> > yes but this is used in the form of commentary, and as such is
> > managed by Copyright in most instances.
> 
> I don't understand the distinction between code and commentary here.
> 
> Copyright and copying conditions apply to entire works, including both
> comments and code; there is no difference as far as the BSD or GPL
> license is concerned.
> 
> >> This is example 1 in my draft.  Several free software projects
> >> do this today (Apache, Samba, ...).
> >> 
> >> I have not gotten the impression that how RFCs are used in open source
> >> projects is something the IETF want to forbid.  
> >
> > The problem is again the IETF's Standard of Care and its
> > responsibilities to protect what it claims is its IP...
> 
> You don't have to defend a copyright to claim it.  You don't even have
> to register it.
> 
> >> I believe it would be
> >> better to harmonize the legal text with how IETF standards are used.
> >
> > Assuming the use models are legal...
> 
> I think we have several examples of illegal use of RFCs already.
> That's not my point.  My point is to try to decide what we should
> permit, and have that be reflected in the license properly.
> 
> >> >    For the other issue, that of reuse of the normative text by anyone
> >> > who wants to do so, I am still struggling to understand why there is a
> >> > _need_ to make the text of the RFCs broadly available for use in
> >> > derivative works
> >> 
> >> Example 1 and 5 in my draft is about this.  RFC text is useful as
> >> commentary in source code or documentation.  To adapt the commentary
> >> for a specific audience, you need the right to make modifications to
> >> it.
> >
> > No you dont - you need the right to make excerpts from it. This is a
> > gross misconception in what derivative rights actually pertain to
> > and documents how little this WG actually knows about IP use models
> > and the law as a whole.
> 
> Please re-read those examples.  The RFC text need to be modifiable to
> be useful in those examples.  If it is not possible to modify the
> text, it likely won't be used.  So the right to modify the text is
> important.
> 
> >> Compare the getaddrinfo man page in Solaris.  I think Sun made good
> >> decision by using the RFC text there, and that the IETF should support
> >> that behaviour.  
> >
> > The problem with this example is that Sun may not have had legal
> > right to do so under the current use license models, and if that's
> > true the IETF's negligence and gross failures in protecting its IP
> > may have invalidated any claim the IETF may have had to any of the
> > submitted IP.
> 
> Again, copyright does not have to be defended.
> 
> > Bluntly speaking - US IP Law is really simple, you dont get to make
> > rules about IP's use and not enforce them. If you fail to protect
> > the IP's you claim to control, then they become 'abandoned' or at
> > the very least the claim that 'you' *(in this case the IETF) own
> > them is invalidated for lake of maintanence, and the performance of
> > the "Standard of Care" the IETF is required to exhibit and put
> > forth.
> 
> Are you talking about patents, perhaps?  The current topic is not
> patents, it is about copyright and copying conditions.  The term IP is
> confusing, since it include so many different and completely
> orthogonal matters.
> 
> >> > and therefore risking all of the potential harm, to both the IETF
> >> > process and to interoperability, that I believe could ensue.
> >> 
> >> I believe the fear here is mis-placed.  The open source community
> >> permit free modifications, and while there certainly has been forks,
> >> none of them indicate that there is any long-term harm for the
> >> Internet.  Quite the contrary, the major forks (e.g., OpenBSD)
> >> contribute to a better working Internet.
> >
> > If your intent is that the IETF should ONLY allow opensource or
> > free-ware submissions then possibly...
> 
> That is not what I want.  We have the example of the getaddrinfo man
> page in Solaris.  My license would make it possible to do what Sun
> did.  We can't change existing RFC copying conditions, however, future
> ones will be covered.
> 
> >> > If I were to write some code which implemented an IETF RFC, and at
> >> > various points I decided that I have a better way to implement the
> >> > protocol than as defined in the RFC, then I am certainly free to do
> >> > so, and I am also free to draft man pages, comments, etc indicating
> >> > what I have done without having to use to RFC text itself as a
> >> > starting point.  
> >
> > No you are not - you only have this capability if a derivative
> > rights release is included with the submission and the intent of the
> > person 'submitting the IP originally' is to enable you to do
> > this. Otherwise the "GIFT" is invalid and the ownership of the IP
> > remains with the original submitter and those involved in any
> > vetting or otherwise, have damage claims against the IETF...
> 
> I'm arguing that I should have that right.
> 
> >> > Copyright law does not prevent me from writing my
> >> > own description of what I have done, 
> >
> > Actually it may - depending on how much of the original text you
> > modify... By the way - this gross lack of IP law knowledge is what
> > is spurring this conversation on.
> 
> By "writing my own description" I mean that NO original text is
> re-used.
> 
> >> > Since the right already exists to redistribute the IETF
> >> > document as a whole in unmodified form, then it would be easy to
> >> > indicate with my own text where my code differed from the RFC (and
> >> > presumably why) without having to use the existing RFC text.
> >
> > I would challenge the effectivity of the IETF's existing releases to
> > the point of stating that bassed in the IETF's gross failures to
> > protect any of its IP it has abandoned any onsiderations of rights
> > it might have had and the ownership of EVERY single RFC, I-D and
> > other IETF document published to date probably belongs to the
> > original submitters of those documents.
> >
> > Again - this is about what the person submitting the IP to the IETF
> > expects and under what terms they submitted it - not what terms the
> > IETF accepted it.
> 
> As above, I don't follow this, because copyright does not have to be
> defended.
> 
> Thanks,
> Simon
> 
> _______________________________________________
> 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: [email-masked]
Date: Thu, 17 Nov 2005 14:38:27 +0000

Don, as an IP litigant I assure you that I know the difference between TM and CR law. Also between the difference between Patent, Trade Secret management, and Industrial Design Rights as well. The point was in specifically adding a TM to official IETF excerpts as part of the license to continue their protection...

Todd
 -------------- Original message ----------------------
From: Don Armstrong <[email-masked]>
> On Wed, 16 Nov 2005, todd glassey wrote:
> > No but if you dont react to people violating that copyright then you
> > lose it. Trust me on that one or better yet, ask Jorge about what
> > happens in the real world when IP protections are violated and those
> > holding those protections do not exercise them?
> > 
> > > This is covered in the Berne convention. Do you have any examples
> > > of where copyright was lost because it was not defended? I'm not
> > > talking about patents or any other IP. Only the copyright.
> > 
> > Uh how about the term xerox, which was found by a court to have
> > become common-speak after Xerox corporation tried to nail someone in
> > US Federal Court over its use in print. There are many examples.
> 
> You're conflating trademark law and copyright law. They are not the
> same. Discussions which lump them together blindly with other forms
> of "IP" (whatever that means) are fundamentally flawed.
> 
> 
> Don Armstrong
> 
> -- 
> She was alot like starbucks.
> IE, generic and expensive.
>  -- hugh macleod http://www.gapingvoid.com/batch3.htm
> 
> http://www.donarmstrong.com              http://rzlab.ucr.edu
>

---

From: "Powers Chuck-RXCP20" <[email-masked]>
Date: Mon, 21 Nov 2005 16:16:59 -0600

Simon,

Although I have yet to see anything in your arguments which indicates
that normative RFC text _must_ be used to document code, it is apparent
that you feel that it would be impossible to not do so. Therefore, on
that we must simply agree to disagree.

However, to the text of your proposal:

>     c.  The Contributor grants third parties the irrevocable
>         right to copy, use and distribute the Contribution, with
>         or without modification, in any medium, without royalty,
>         provided that unauthorized redistributed modified works
>         do not contain misleading author, version, name of work,
>         or endorsement information.  This specifically implies,
>         for instance, that unauthorized redistributed modified
>         works must not claim endorsement of the modified work by
>         the IETF, IESG, IANA, IAB, ISOC, RFC Editor, or any
>         similar organization, and remove any claims of status as
>         an Internet Standard, e.g., by removing the RFC
>         boilerplate.  The IETF requests that any citation or
>         excerpt of unmodified text reference the RFC or other
>         document from which the text is derived.

   This is a start, but does not go nearly far enough in notifying
downstream users that changes have been made, and that caveat emptor is
now a necessary rule for use, since we cannot assume that those
producing the modified works in question will adequately document where
their implementation differs from that of the RFC, risking harm to the
unwary adopter of their work. Therefore, I believe that is should be
amended as such:

     c.  The Contributor grants third parties the irrevocable
         right to copy, use and distribute the Contribution, with
         or without modification, in any medium, without royalty,
         provided that unauthorized redistributed modified works
         do not contain misleading author, version, name of work,
         or endorsement information, and that the following text
         is included in any subsequent distribution:

         "Warning: This text describes a derrivative of the
         standard defined in RFCXXXX; the reader should be warned
         that this modified work may not operate in a way that is
         compatible with the protocol defined in RFCXXXX, and that
         using this modified work could result in incompatability
         with RFCXXXX, and thus fail to interoperate properly with
         compliant implementations of RFCXXX. Therefore, the reader
         is strongly urged to carefully review this documentation
         and the code it accompanies, to determine where this
         implemention is potentially incompatible with RFCXXX, and
         determine if such differences with RFCXXXX (if they exist)
         are acceptable."

         In addition, any unauthorized redistributed modified
         works must not claim endorsement of the modified work by
         the IETF, IESG, IANA, IAB, ISOC, RFC Editor, or any
         similar organization, and remove any claims of status as
         an Internet Standard, e.g., by removing the RFC
         boilerplate.  The IETF requests that any citation or
         excerpt of unmodified text reference the RFC or other
         document from which the text is derived.

   This would allow anyone who wanted to take and run with the RFC text
to do so, while ensuring that the bar for "improving" the standard
originally defined in the RFC (and thus potentially harming
interoperability) would be high enough that those wishing to make the
change would need to have a solid reason for doing so, and would need to
convince those who might use their code that they had good reason to
make the changes, and to clearly identify where those changes have been
made. Call it the IETF warning label...

   IMO this would also solve the "Fake RFC" problem, assuming that those
wishing to fake an RFC would follow the copyright rules in the first
place.

   In addition, by the way, you must ensure that the "Contributor" is
listed among those who from whom the author of the modified work cannot
claim endorsement from; one of the primary concerns from some I have
talked to regarding this issue is that they make a contribution to an
IETF standard, and then someone else takes their text, reuses it in
modified form, and claims that it is from, or endorsed by, the original
contributor. Therefore, you cannot limit the list to only the IETF and
related organizations; it has to include the original contributor as
well.

regards,

Chuck

> -----Original Message-----
> From: Simon Josefsson [mailto:[email-masked]] 
> Sent: Monday, November 21, 2005 3:46 PM
> To: Powers Chuck-RXCP20
> Cc: [email-masked]
> Subject: Re: One copyright issue or Two?
> 
> 
> "Powers Chuck-RXCP20" <[email-masked]> writes:
> 
> >> Secondly, the text of RFCs is widely used inside comments in
> >> source code.  This is example 1 in my draft.  Several free 
> >> software projects do this today (Apache, Samba, ...).
> >> 
> >> I have not gotten the impression that how RFCs are used in
> >> open source projects is something the IETF want to forbid.  I 
> >> believe it would be better to harmonize the legal text with 
> >> how IETF standards are used.
> >
> > I don't think anyone wants to, or has even implied that 
> they want to, 
> > forbid the legal use of RFCs in open source projects. But simply 
> > pointing to folks who _may_ have been using that text in 
> violation of 
> > IETF copyrights and saying "you have to let them keep doing 
> it" is not 
> > really the right approach to solving the problem, IMO.
> 
> There is no legal use of RFCs in open nor closed source 
> projects today.  Third parties have NO rights whatsoever to 
> RFCs.  Third parties are not granted a right to copy and 
> distribute RFCs, even unmodified, according to RFC 3978.
> 
> >> Example 1 and 5 in my draft is about this.  RFC text is
> >> useful as commentary in source code or documentation.  To 
> >> adapt the commentary for a specific audience, you need the 
> >> right to make modifications to it.
> >> 
> >> Compare the getaddrinfo man page in Solaris.  I think Sun
> >> made good decision by using the RFC text there, and that the 
> >> IETF should support that behaviour.  Using the RFC text 
> >> minimize accidental errors introduced by a re-write.  They 
> >> have a standard for how man pages should look, so they had to 
> >> modify the text in some ways.  That's fine too.  But there 
> >> are no legal rights granted to permit that now. That's a problem.
> >
> > I understand that RFC text can be useful in documentation; 
> but again, 
> > that doesn't mean that is it essential, e.g. "that is the only 
> > possible way to document my code" - is it a nice to have, it is 
> > awfully convenient to use, but being restricted from modifying RFC 
> > text would not prevent anyone from documenting their code, 
> whether it 
> > conformed with an IETF protocol or not.
> 
> This belittle the point of standardization in the first 
> place.  The reason for standardizing something in the IETF is 
> that it should promote a better Internet.  Making it possible 
> for implementers to use the text in their products further that goal.
> 
> If the license permit fake RFCs, that can be dealt with 
> separately, and it has -- please read my latest license text 
> -- so this is not a good argument for disallowing 
> redistribution of modified works.
> 
> >> I believe the fear here is mis-placed.  The open source
> >> community permit free modifications, and while there 
> >> certainly has been forks, none of them indicate that there is 
> >> any long-term harm for the Internet.  Quite the contrary, the 
> >> major forks (e.g., OpenBSD) contribute to a better working 
> Internet.
> >
> > Having dealt with interoperability issues in standards for a long 
> > time, I believe there is significant risk in forking of IETF 
> > protocols, particularly if the normative text of an RFC can 
> be used to 
> > document the changes, but with no obligation to clearly 
> state how the 
> > revised code differs from the original implementation. We must 
> > remember that there are those to whom a lack of interoperability is 
> > desirable, for a variety of business and tehcnology reasons, and 
> > giving them the ability to make their variants appear more 
> valid does 
> > not seem prudent to me, if it risks reducing the value of the work 
> > being done in the IETF.
> 
> Nobody wants to permit fake RFCs.  Can you describe a 
> realistic scenario in which someone could create a derivative 
> work of an RFC that is permitted through my latest license text:
> 
>     c.  The Contributor grants third parties the irrevocable
>         right to copy, use and distribute the Contribution, with
>         or without modification, in any medium, without royalty,
>         provided that unauthorized redistributed modified works
>         do not contain misleading author, version, name of work,
>         or endorsement information.  This specifically implies,
>         for instance, that unauthorized redistributed modified
>         works must not claim endorsement of the modified work by
>         the IETF, IESG, IANA, IAB, ISOC, RFC Editor, or any
>         similar organization, and remove any claims of status as
>         an Internet Standard, e.g., by removing the RFC
>         boilerplate.  The IETF requests that any citation or
>         excerpt of unmodified text reference the RFC or other
>         document from which the text is derived.
> 
> If you can't find a loophole in that text that permit fake 
> RFCs, I don't believe it is fair to use it as an argument to 
> forbid a free source compatible license for IETF Contributions.
> 
> > Alas, I still haven't seen any arguments which contradict 
> my point - 
> > that it is easy and convenient to use the RFC text for 
> documentation, 
> > but it is not _essential_ to do so in order to document one's code.
> 
> We have been over this many times.  The explanation is that 
> to be able to include excerpts from an RFC in free software 
> products, e.g. in source code, the right to make modification 
> must be granted, otherwise it is incompatible with both the 
> BSD and GPL license.
> 
> If we do not grant the right to adapt portions of RFCs in 
> products, all RFC excerpts will have to be modified from free 
> software implementations.  That is a huge task that would 
> work against the goals of the IETF; to permit a smoother 
> running Internet.
> 
> > In fact, I am not against using RFC text for documenting 
> > implementations of RFC protocols. I am, however, very 
> concerned that 
> > allowing the free use _and modification_ of normative text could 
> > result in incompatible implementations of IETF protocols 
> with no clear 
> > indication that what has been implemented is no longer 
> interoperable.
> 
> I don't disagree.  The license above is meant to prevent that 
> situation.  Could you try to improve it to make sure what you 
> are worried about cannot happen?
> 
> Thanks,
> Simon
>