Subject: Re: One copyright issue or Two?

From: [email-masked]
Date: Tue, 15 Nov 2005 14:26:27 +0000

-------------- Original message ----------------------
From: Simon Josefsson <[email-masked]>
> "Powers Chuck-RXCP20" <[email-masked]> writes:
> 
> >    As best as I can tell, folks in this discussion are doing jumps and
> > twists trying to resolve two separate issues, the
> > use/modification/derivation/etc of "code" embedded in IETF RFCs (e.g.
> > ASN.1 schemas, source code, etc), and the
> > use/modification/derivation/etc of normative text of the RFC documents.

True.

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

> 
> They could be addressed separately, but I believe many of the issues
> are similar.

Possibly, but either way, they (the issues)  are pretty simple - the issue is how to build a model that meets the existing licensing use models (GNU Copyleft, OpenSource, Artistic Use, etc) implemeted as the various types of end-use licenses that the members of this committee want to support.

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

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

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

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

> I believe it would be
> better to harmonize the legal text with how IETF standards are used.

Assuming the use models are legal...

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

If any of the lawyers involved want to formally rebuke this commentary, I suggest you think that commentary through VERY carefully - since whatever you say formally, it may possibly wind you up in front of the Cal or NY Bar Associations on an Ethics Complaint.

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

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.

Jorge - want to invalidate this commentary (I doubt it highly)...

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

Which brings us back to the IETF's refusal to protect its IP... and what that actually means as far as legal precedent goes.

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

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

Why is this so freaking complex???

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

> > it simply prevents me from
> > deriving my description from someone else's description without
> > permission. 

Again this depends on what is licensed and how. 

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

> 
> I don't think this is a realistic view of how software is developed
> today.
> 
> If you are implementing something you are normally building on someone
> else's work.  There is no reason not to, most standards have a open
> source implementation available.  These implementations all permit
> modification by third parties.
> 
> You take an implementation, make your own modification and document
> them.  The problem now is that the original implementation (which
> could be Apache, BIND, OpenSSL, LibIDN, ...)  include material derived
> from RFCs.  If you don't have the right to re-use that material in an
> implementation that doesn't implement the original protocol, there is
> a problem for the implementer.  I'm arguing that it is
> counter-productive for the IETF to cause this problem.  This harms the
> companies doing research and development on Internet protocols, which
> are the same companies who sponsor IETF attendees.
> 
> Permitting that someone from releasing his modified generally lead to
> a better working Internet.  This is how software that runs the
> Internet today has developed.  For example, Sendmail and the Cyrus
> IMAP server has been widely used by companies which make minor
> modifications (e.g., optimizations for mobile platforms), these later
> changes eventually move back into the IETF if they proved useful and
> there is a need to standardize them.  Look at what the LEMONADE WG is
> doing, and who's driving that work.  There are many other examples.
> 
> >    It seems to me that the primary desire to have this broad right is
> > based on "I want to use the RFC text", and not "I have no option but to
> > use the RFC text"
> 
> I'm not sure this is correct.  I think we are close to the second
> position, at least if you consider what is practical for most
> companies.  Many companies are basing their work on free software
> projects (look at how Mac OS X re-use parts from FreeBSD).  If you
> want to take Apache, BIND or other free software projects that include
> excerpts from RFC, you need the right to be able to modify the
> package, including any RFC excerpts.  I'm arguing that the RFC copying
> conditions shouldn't be a burden here.
> 
> > and I don't believe that is a compelling enough argument to open the
> > IETF process up to the potential issues that could result from
> > allowing folks to run wild with their own derived versions of IETF
> > RFCs. I think the downside risk is too high for the potential
> > benefit of just making it easier to draft documentation.
> 
> I believe there are more concerns than merely producing draft
> documentation.  I also believe, which Sam has argued for, that any
> harm inherent in my proposal is already inherent in the current
> system.  Folks won't run wild with derived IETF protocols just because
> the copying conditions permit that.  The experiences from the free
> software community set a strong precedent here.  In the few cases
> where a fork has happened, it has frequently made things better in the
> long run.
> 
> 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: Simon Josefsson <[email-masked]>
Date: Tue, 15 Nov 2005 16:01:39 +0100

> through simple copyright...

Sorry, I don't follow.  Copying conditions can clearly be used to
permit derivative works.  What are you thinking of here?

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

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

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

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

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

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

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

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

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

> 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