Discussion List Archives

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

Re: Review of policy on intellectual property rights

Dear Colleagues,

	Here are my comments on Brian and Herb's document on IPR.
> 
> (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

	At the moment it is not clear that Comcifs has any authority over
DDL though it would certainly make sense that the IUCr have ownership. 
But DDL is in a different category from CIF and its ownership(s) and
Comcifs authority in approving DDL needs to be clarified. 

	In addition to the items mentioned we should also take protection
for the names of dictionaries under construction including:

		msCIF
		symCIF
		dsCIF
		rhoCIF
		sasCIF
		magCIF
		giCIF

as well as possible dictionaries that we might construct in the future

		edCIF (electron diffraction)
		nsCIF (neutron scattering)

> 
>    It is a principal objective of the IUCr to promote the use of CIF for
>    the exchange and storage of scientific data.  The IUCr's sponsorship of
>    the CIF development was motivated by its responsibility to its
>    scientific journals, which set the standards in crystallographic
>    publishing.  The IUCr intends that CIFs will be used increasingly for
>    electronic submission of manuscripts to these journals in future.  The
>    IUCr recognises that, if the CIF and the STAR File are to be adopted
>    as a means for universal data exchange, the syntax of these files must
>    be strictly and uniformly adhered to. Even small deviations from the
>    syntax would ultimately cause the demise of the universal file
>    concept.  Through its Copyrights and Patents the IUCr has taken the
>    steps needed to ensure strict conformance with this syntax.

	While the Union journals remain a primary responsibility of the
Union and therefore are appropriately mentioned in this paragraph, the
Union also has responsibility toward the crystallographic community as a
whole, coordinating many activities that are undertaken by other
crystallographic organisations.  Since the above paragraph was written (in
1990), at least three crystallographic databases have adopted CIF as an
archival format and others accept submissions in CIF.  The references to
the Union journals should be broadened to include crystallographic
databases as well as non-union journals that make use of CIF.

> 
>     1. CIFs and STAR Files may be generated, stored or transmitted,
>        without permission from or payment to the IUCr, provided
>        all of the following conditions are met.
> 
>          1.1.  Any file serving as a CIF or STAR file must strictly adhere
>          to the relevant syntax and dictionary definitions as
>          promulgated by the IUCr until the date of creation.

	Replace 'until' by 'in effect at' here and elsewhere.

> 
>          1.2.  Any file used as a Data Dictionary in conjunction with 
>          CIF or STAR files must strictly adhere to the relevant syntax
>          and dictionary definition languages as promulgated by the IUCr
>          on the date of creation, and must not contain definitions
>          which conflict with Dictionaries created by or approved by the IUCr.

	The word 'strictly' in the above two paragraphs surely adds
nothing to the legal force of the document, but it certainly leaves me
feeling on my neck the breath of the CIF guard dogs straining on their
leash, ready to pounce the moment I misplace a single character in my CIF. 
If we want to encourage use, we should make the tone friendly, while still
covering the legal aspects.  The language here (and elsewhere) is
unnecessarily forbidding. 

> 
> What will the IUCr do if I violate the IUCr Policy on CIF?
> 
>   The IUCr will vigorously protect CIF and STAR as standards for our
> community.  In most cases, we will try to talk to you and get you back on
> the right track, but, if we must resort to legal action to protect the
> interests of the community, we will do what we must.

	Let me suggest a more friendly wording:

	"When IUCr becomes aware that you are in violation this policy, it
will point out the problem and ask you to make the changes needed to
comply.  If this is not possible we will request that you refrain from
using terms such as 'CIF' that are the registered marks which imply a
strict adherence to the CIF standard.  In the event that you refuse to
comply and refuse to remove our registered service name, the IUCr is
prepared to take the legal action necessary to enforce its rights."

> 
> What does it mean to "protect CIF and STAR as standards"
> 
>We want you and your colleagues to be (able to be) confident that when you
> receive a file and it is represented to you as being a CIF or a STAR file,
> that it is, indeed a CIF or a STAR file.  So, if somebody starts
> distributing files which are called CIF or STAR, but which don't comply
> with the rules for making CIF or STAR files, and we know about it, we will
> ask them to stop doing that.

	Delete the phrase in parenthesis.

> 
> We want you and your colleagues to be (able to be) confident that when
> you work with software that claims it reads or writes CIF or STAR files,
> that indeed it does do that.  So if somebody produces what they claim to be
> a CIF or STAR application, we want to be able to take a look at the program

	replace this line with

'a CIF or STAR application, we need to be able to look at the program'

> and documentation and assure ourselves that it is.  If the program is in
> the public domain, we can do that.  If somebody wants to do something more
> restrictive, things can be worked out, but we have to be able to assure
> ourselves and you that what claims to be a CIF or STAR application is,
> indeed working with CIF or STAR.
> 

> 
> What specifically about CIF and STAR will the IUCr protect?
> 
>   We will protect CIF and STAR as trademarks and service marks of the IUCr.
> We will protect the IUCr STAR patent.  We will protect the copyright on the
> various "public" CIF dictionaries and on the DDL's.  We will protect CIF
> and STAR as effective standards for the community.

	If 'public' is sufficiently vague that it needs to be put in
quotes, it should be properly defined.  Do we mean CIF dictionaries that
are owned by (or copyright by) the IUCr?  Do we include privately
copyrighted dictionaries that are, nontheless, widely and publicly
distributed? DDL's have hardly been mentioned here.  They need further
definition (see also my comments above about ownership of DDL).  

	Here is another FAQ (or one that should be an FAQ):

'What do I do if I want to write a CIF, but some of the items I want to
use are not included in any of the CIF dictionaries? 

	'You can, of course, invent any data name that you like and
include this in a conforming CIF providing that the data name is not
otherwise defined in a CIF dictionary and it otherwise conforms to CIF
usage. This can usually be done by including the name of the laboratory or
the initials of the creator as part of the data name.  Use of such local
names is legal, but not recommended if the CIF is to used outside the
institution in which it was created. 

	'There are a number of alternatives.  If the data item is one that
is likely to be of general interest to crystallographers, you should
contact the chair or secretary of Comcifs to see if the item can be
included in the next revision of the appropriate dictionary.   If there
are a series of items that are related to a field for which a dictionary
does not yet exist, Comcifs may invite you to assist in preparing a
dictionary for this area.  If neither of these routes are appropriate, you
may register a local prefix with Comcifs.  Such a prefix would appear as
the first element of any local data name you create.  Registering it with
Comcifs will make it easier for a subsequent user to trace the
local dictionary in which the data name is defined.  Note, however, that
all the items in a local dictionary _must_ conform to the syntax and
conventions of CIF if they appear in a file that calls itself a CIF.

	'Any member of Comcifs will be able to give advice on what to do
in particular cases.'

_________

	The tone of the circulated document is much too forbidding and
suggests not only that we will crack down mercilessly on any offenders,
but that we don't really want other people breaking into our private file
structure in spite of our protestations to the contrary.  Which of these
messages comes through loudest and clearest?  In the last FAQ I indicate
the tone I think we should present - an iron hand, perhaps, but certainly
in a velvet glove.  We should be reaching out to the community and
offering them help in coming to grips with a rather complex file
structure.  My experience working with crystallographers creating new CIF
dictionaries is that the first drafts are highly non-conforming, not
through any ill-will but because writing a CIF dictionary is a real
challenge, even for those of us who have been in the game since the
beginning.  A helping hand is what is needed, not a slap on the wrist for
getting it wrong the first time. 

	Brian suggests that we form a broad consensus before we arrive in
Glasgow (but some are already on their way) and dot the i's and cross the
t's when we get there.  I see a lot more work needed in polishing the
document, even if we agree that the basic ideas are correct.  The Comcifs
meeting has a long and probably controversial agenda and we will not be
able to spend too much time on this document.  In any case I have yet to
see a committee of more than two that is able to dot i's and cross t's in
a finite length of time.  I propose we come prepared to discuss any major
shortcomings in Brian's document and delegate rewriting to a subcommittee
for presentation to the discussion group for further input and eventual
approval. I will give the gist of our discussions so far when I meet with
the Executive next Tuesday.  I will report the results at our closed
meeting.

	See you all (or most of you) next week.

				David



*****************************************************
Dr.I.David Brown,  Professor Emeritus
Brockhouse Institute for Materials Research, 
McMaster University, Hamilton, Ontario, Canada
Tel: 1-(905)-525-9140 ext 24710
Fax: 1-(905)-521-2773
idbrown@mcmaster.ca
*****************************************************