Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Review of policy on intellectual property right

  • To: Multiple recipients of list <comcifs-l@iucr.org>
  • Subject: Re: Review of policy on intellectual property right
  • From: Brian McMahon <bm@iucr.org>
  • Date: Mon, 26 Jul 1999 13:45:53 +0100 (BST)
This from Peter Murray-Rust (sorry, Peter, that your current email address
isn't recognised - I'll try to fix that this afternoon - Brian)

At 16:10 23/07/99 +0100, Brian McMahon wrote:
>Intellectual Property Rights

Hope the following is useful...

>(a) Should the IUCr pursue registered trademark protection for STAR File, CIF
>    and other such designators? If so, what should go in the full list? I
>    nominate the following acronyms or designators:
>            STAR File
>            CIF
>            CBF
>            mmCIF
>            pdCIF
>            imgCIF
>            DDL

I support the application for a trademark in principle (subject to cost).
[My first-hand knowledge is limited to application for European trademarks.] 

>1. Purpose of defending IPR
>The IUCr developed CIF to preserve structural data in a format that could
>reliably be transferred across computer systems and be interpreted
>unambiguously and in perpetuity. Its most clearly defined policy with
>respect to CIF is to *encourage* its adoption as a *standard* within the
>scientific community. Both emphasised words have equal weight. It is to
>safeguard the integrity of the standard that the IUCr has publicly asserted
>its ownership of the underlying intellectual rights; but an arid standard
>that no-one uses is of no benefit. In an increasingly litigious age, there
>are individuals who have been *discouraged* from adopting and working with
>files in CIF format, and this runs entirely counter to the Union's
>objectives. So it seems appropriate to review and if necessary modify the
>wording of the official policy on the use of CIF to reassure the community
>that their interests are best served by adopting its use wholeheartedly.

I think trademarks and copyright are appropriate protection for
software/informatics works rather than patents (there is strong feeling
against software patents in many quarters). [I have gone through this in a
non-crystallographic field of informatics]. The positive aspects are that a
trademark can help to promote an image of quality which is entirely
appropriate for an International Union, and to emphasise the technology in
a non-confrontational way. Trademarks are also very suited for validation
and quality control.

Both profit and non-profit organisations are increasingly seeing the
benefit of informatics standards and these might be required when
purchasing goods (e.g. equipment of information).
>Copyright law is complex, obscure and varies across jurisdictions. The

. and unlikely to become simpler ...

>declarations of copyright should be made against some appropriate
>legislative instrument, such as the UK Copyright, Designs and Patent Acts
>(1988). It is debatable whether the CIF syntax restrictions could be
>effectively defended in a copyright lawsuit, and it is not clear that this
>is the proper instrument to enforce such restrictions.
>The copyright on the CIF dictionaries is much more straightforward: these
>are documents with identifiable content. However, an author of a "local"
>dictionary (i.e. one defining datanames prefixed with a string registered
>with the IUCr) would hold the copyright on that dictionary.

As always, this is ultimately testable in court. The organisation and
layout of information is also copyrightable as well as the content and it
could be argued that part of the copyright remained with the designer of
the layout (though it could be difficult defend). Thus if the CIF
dictionary is converted to a GIF, it could infringe the GIF IPR (actually a
>3. Extending the scope of legal protection: trademarks
>One of the essential elements of promoting and defending a standard is that
>any object claiming to adhere to that standard must be identifiable as
>such. For this reason, the IUCr is proposing to seek registration of "CIF"
>and certain other terms or acronyms as trade or service marks. Then a file
>can claim to be a CIF only if it can meet the criteria establishing its
>identity as a particular type of object reserved for trade (or, more
>relevantly, service) purposes by the rights owner.

I approve of this motivation. We have had far too many 'mutant' file types
in molecular science ("PDB-like files") and there is a lot to be gained by
having examples of ones that are monitored and where there is a stick and
carrot to enforcement. In particular it puts an onus on suppliers of goods
to be sure that they are honouring the standard rather than guessing or

>There are two issues here. The first is that "CIF" is an acronym already
>in other fields - there is a widespread CAD graphics file format, and
>other less familiar manifestations. It is therefore possible that there may
>be legal obstacles in the attempt to register such trademarks. However,
>trademark legislation allows for the reservation of distinctive marks or
>names in specific contexts; and a successful application could have the
>benefit of removing confusion by requiring that users of the acronym in
>domains where confusion is possible must explicitly acknowledge its
>crystallographic provenance when that is appropriate.

Trademarks can be registered for certain classes and within the first year
(in Europe) other trademark holders have the right to object to the use in
specific domains.

>The second issue (technical rather than legal) has to do with the provision
>of a means to validate that a file claiming to be a CIF (or mmCIF, imgCIF,
>or other registered trademark) may actually be considered as such. For
>in the TeX world, there is a program called TRIP that must produce identical
>output from any modified version of TeX if that version is still to be called
>TeX. Perhaps something similar should be considered for CIF and friends. As a
>first step in this direction, I that Star_Base and vcif be
>advertised as reference syntax validators for STAR File and CIF respectively,
>while CYCLOPS be the reference validator for data names. However, we should
>consider whether additional software might be commissioned to validate at a
>deeper level against dictionaries; and we might consider the more thorny
>question of whether validation is required of the physical meaning of the
>content; in other words, if a file contained an _atom_site loop with a
>series of entries (i.e. not corresponding to a real structure), could or
>should the resultant file be able to be called a CIF?

I think this is very valuable. In the Internet world there are services for
validating HTML (and shortly, XML). Some of these can be accessed remotely
(e.g. uploading of documents to a server for analysis). Also there are
conformance-testing sets - files which test whether software is compliant.
A tool that purports to read CIF should be tested against a wide spectrum
of conforming (and also deliberately non-conforming) test documents. There are
many "special cases" which occur occasionally and which are important to
>4. Licensing issues
>If we protect the intellectual property rights of the IUCr through patent,
>copyright and trademark law, we run the risk of appearing protectionist and
>frightening people away from any use or development of CIF. It is
debatable to 
>what extent that is a real concern. It seems to me that there is a
>between writing a program and incorporating into it a series of subroutines
>written as a library by someone else, and writing a program to input and
>subsequently process data from a file described by someone else's
>specification. However, debating the fine point of distinction may happily
>and lucratively keep lawyers employed, but does not necessarily help us
>towards our purpose of promoting development and dissemination of tools
>for CIF.
>Herbert has suggested that there is something to be gained from trying to
>promote the Open Source software development model:
>  (a)  You provide a copyright notice in your software
>  (b)  You give people a limited license to copy, modify and distribute the
>software which requires them to provide source and to impose the same
>license terms upon those to whom they distribute copies.
>He suggests "We are all used to the normal practice of copyright transfer
>forms when we submit papers to journals.  We could set up a similar practice
>for CIF software distributed through the IUCr web pages, and then couple an
>IUCr Software Public License Agreement to distribution of that software."
>The intention would be to phrase the license in such a way that it does
>indeed encourage use - and reuse - of code for the common purpose.

I am a supporter of OpenSource (and distribute much of my software this
way) but don't feel this is not incompatible with trademarks - especially
from a non-profit org.


>All and any feedback will be most welcome.