[CESG] Implementation of new CCSDS Patent Policy - ISSUES

[Shames, Peter M (313B)]

See comments, in-line.

From: Adrian Hooke <Adrian.J.Hooke at jpl.nasa.gov<mailto:Adrian.J.Hooke at jpl.nasa.gov>>
Date: Thu, 17 Mar 2011 08:04:21 -0700
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>, Mike Kearney <Mike.Kearney at nasa.gov<mailto:Mike.Kearney at nasa.gov>>
Subject: RE: [CESG] Implementation of new CCSDS Patent Policy - ISSUES

1) Once a patent issue has been identified, resolved according to the policy, and documented in a Blue Book, there is no need to repeat that same process for any other document that just references that Blue Book.
This discussion came up in the context of the LDPC standard, which is now being finalized in the second review of the Pink Sheets (CCSDS 131.0-P-1.2.  TM Synchronization and Channel Coding. Pink Book.)  The LDPC will need to have the patent issues clarified and an Annex added in alignment with the new policy on patents.  However, if this standard is now adopted within another Blue Book, such as the Prox-1 coding update that is now in discussion, there is no need to do this patent documentation process a second time.  It should be sufficient to do it and document it once, and then just reference the Blue Book where it is documented.

As Greenberg would say, yes and no. In the general case, true – providing that the mission application is the same. The problem with applying to Prox-1 is that it’s a symmetric protocol and that means that an implementer must provide an encoder and a decoder. The current LDPC spec only standardizes the encoder and it completely mute on the subject of decoder patents; that exposes a decoder implementer to potential patent infringement if he/she implements a decoder for the specified code and then gets hit with an undisclosed patent. As long as the current LDPC spec fully discloses all known decoder patents associated with the specified codes then it would work as you say. If not, then the Prox-1 application would have to disclose decoder patents and go through it own documentation process. In either case, the important thing is to tell users that there is a patent associated with a decoder design for the specified code, and that they need to either get a license (telling them how) or be very careful that their own design does not infringe on the patent.

It is ALWAYS the case that someone has to implement both the encoder and the decoder, and often they must implement both.  This is true of coding, modulation, essentially all protocols and even information exchanges like those for XML nav docs.   There is absolutely nothing about Prox-1 that makes it any different than any of these other possible applications of any of these protocols.

We need to get this clarified.  Presumably both clauses are still relevant and there is still a requirement to not only "attempt to secure the license terms", and also to "separately exercise the licensing process during the prototyping and validation process to finalize a Red Book."

There is general agreement that we need to make an attempt to nail down the actual licensing terms but at the end of the day a patent holder can always say one thing and then do another. Which is why the “quality control” text must be added to the Introduction. I personally believe that we need to keep the “separate exercise of the patent” requirement but I think that there was some CMC discord about that. Mike?

I think we are in agreement on this.  Is there an issues with the CMC?

3) There are conflicts in the new policy statements vis-a-vis whether resolution of license issues is required before finalizing the standard vs requiring this to be documented before a new doc project can even start.

I frankly can’t follow all of your screen-fulls of convoluted cut-and-splicing and I don’t think that there are any conflicts. (Generally, I do wish that you would try to be more to the point; the value of an e-mail isn’t increased by its length.) The bottom line is that you can’t start a WG without complying with the new process. Since the policy is retroactive, it needs to be folded into whatever stage the current WG are at. In the specific current case of the three channel codes, none of them can advance to Blue until they comply.

Let me try again, in as simple a form as I can.  The policy, in three different places, makes what I think are contradictory statements:

(4)   Beyond the ISO process, WG chairs should be required to *attempt* to secure the license terms from patent-holders.  However that would not be required in order to develop or approve a standard.

"ISO patent statement and licensing declaration form must be completed before any CCSDS document can be submitted
to the CMC for potential approval on the Standards track".

(2)   Document projects must have the ISO declaration form signed before they can be added to a WG’s work plan

The first of these says the WG chair should try to "secure" the license terms, but then says that this is not needed to approve a standard.  The second directly contradicts this and says that the Declaration Form must be complete before the document can be submitted to the CMC for approval.  The third says that the Declaration Form must be completed and signed before work on a new CCSDS document can commence.

It is not possible for both 1 & 2 to be true at the same time.   Or, if 1 is true then 2 must be false.  Either the form is required, or it is not.

It is not logical to require a Declaration Form to only be required before a document can be submitted for approval (2) and also to require that form to be completed before work can even be commenced (3).

(4)   Beyond the ISO process, WG chairs should be required to *attempt* to secure the license terms from patent-holders.  However that would not be required in order to develop or approve a standard.
I propose that we clarify the CCSDS adopted policy such that it is required that disclosure of patent issues is done at the earliest possible moment and
that the Declaration Form be used  to document them, but that the requirement to have a final, signed, Declaration Form on file be used as a gate for
the CMC approving release of a draft standard for agency review.  This will permit work to get started, and to proceed, in a WG, but it will ensure
that the expenditure of aggregated agency resources is constrained until any patent issues are identified, resolved and properly documented.

Is this an agreeable clarification of the policy?


Personally, I think that it already allows that. IMHO, there will be cases where we want to be strict and other cases where we understand some special circumstances and allow work to proceed pending resolution of patent issues. What will not be tolerated is someone who has knowledge of an existing or in-work patent and who holds back from disclosing that information until such time that a lot of agency resources have been expended. That would be regarded as a serious breach of professional  fiduciary responsibility to the standardization process. But in the general case we should not allow a WG to start until we completely understand the full patent picture.

I think we are in agreement here, but we need to state what the policy is in a less ambiguous form than it is now.  If the policy says "disclose at the earliest possible moment" and we use the form to do that disclosure, but do not necessarily get closure on the sign-off immediately, we will be in a position of being able to assess the impact.  If we require that we have the signed form before any work can start, then we run the risk of slowing all work that includes any patented concepts, and things are slow enough around here already without adding that burden.

And do we want to have a part of the policy that says just what the penalty is for a "serious breach of professional  fiduciary responsibility to the standardization process"?

///adrian

Peter


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/cesg/attachments/20110317/2eb0f078/attachment-0001.html