[linux-elitists] [AlanMcNaught@dial.pipex.com: RE: [InChI-discuss] Re: InChI software license]

D. Joe Anderson deejoe@raccoon.com
Wed Oct 5 12:07:31 PDT 2005

On Wed, Oct 05, 2005 at 04:32:10PM +0200, Eugen Leitl wrote:
> On Wed, Oct 05, 2005 at 09:07:58AM -0500, D. Joe Anderson wrote:
> > So, to cut to the chase in case a bona fide licensing wonk
> > happens by:  What's the question?
> It's about the license for InChI http://www.iupac.org/inchi/
> and this license http://www.iupac.org/inchi/license.html
> some folks (see the mail I cited, and followup on the list)
> need to use InChI parsing code, and are hampered by the 
> license. 

OK.  Let me try this again.  What you have above are statements,
not questions.  is there a question you have?

I mean, if they are hampered, they are hampered, and that's very
much not good.  My decidedly lay reading of the license is that
it's non-free, due to the conformance requirements, particularly
those in 4.1.ii and 4.1.iv.  4.1.iii is also a problem, given
that the notification requirements aren't all that unusual and
generally don't pass what the Debian folk call the desert isle
test.  The "you can't call it InChi(TM) portion" would be
acceptable, I'd think, although some might find it obnoxious (cf
use of the Apache or PHP names)

  4.1 The Licensee may:
   (i) download, copy, and redistribute any of the InChITM
   (ii) use the InChITM Protocol with his/her own software,
   provided that generation of an InChITM is consistent
   with what would have been generated had the InChITM
   Software been used;
   (iii) modify the InChITM Software for the express
   purpose of implementation on a platform other than that
   specified for the InChITM Software in the InChITM
   Material (the Licensee must notify IUPAC of any such
   modification). The output so obtained can only be
   described as InChITM if it is the same as would have
   been obtained had the InChITM Software been used as
   provided by IUPAC for the same purpose;
   (iv) incorporate the InChITM Software into another
   software program on the condition that the output is an

> > I'll also note this, that the biopolymer structure tools I
> > teach, like PyMOL, which are also going from strength to
> > strength, don't support mmCIF.  This is probably in large part a
> Interesting. I didn't realize mmCIF was license-encumbered.

Well, copyright and patent encumbered.  Our colleagues in the
field tend to ignore these sorts of things, it seems, which
makes it hard to find online references to the IUCr restrictions
on the START and CIF formats amidst all the references to mmCIF
that give not first clue to the restrictions (STAR and CIF from
which mmCIF inherits these problems), but see for example:

   To protect the STAR File and the CIF as standards for interchanging
   and archiving electronic data, the IUCr, on behalf of the scientific

   * holds the copyrights on the standards themselves,

   * owns the associated trademarks and service marks, and

   * holds a patent on the STAR File.

   These intellectual property rights relate solely to the interchange
   formats, not to the data contained therein, nor to the software used
   in the generation, access or manipulation of the data.

  Promotion of the standards

   The sole requirement that the IUCr, in its protective role, imposes on
   software purporting to process STAR File or CIF data is that the
   following conditions be met prior to sale or distribution.

   * Software claiming to read files written to either the STAR File or
   the CIF standard must be able to extract the pertinent data from a
   file conformant to the STAR File syntax, or the CIF syntax,

   * Software claiming to write files in either the STAR File, or the
   CIF, standard must produce files that are conformant to the STAR File
   syntax, or the CIF syntax, respectively.

   * Software claiming to read definitions from a specific data
   dictionary approved by the IUCr must be able to extract any pertinent
   definition which is conformant to the dictionary definition language
   (DDL)[3] associated with that dictionary.

Look familiar?

> > direct result of the licensing restrictions placed on that
> > format.  If the inchi folk think their stuff will fare any
> > better, I'd like to know why they think so.
> It's IUPAC, and PubChem drives for it to become a standard
> ID (either verbatim, or as a hash). It's better suited
> for this than normalized SMILES.

Yeah, I read about it a bit in C&EN.  My hopes for what it could
be were tempered by what I'd seen happen (or, as the case may
be, not happen) with mmCIF above.

> > They can set up an organization to vouch for the conformance of
> > implementations without such restrictions.
> I don't really understand licenses, especially format licenses. However,
> this is pretty important from a libre chemical database and tool point
> of view (and has implications on open source drug discovery, enabling
> collaborations on the Net, which might lead to routing around the IP
> issues with patented drugs), so I hope those of you with some license 
> background can help, or will pass the problem on to somebody who
> can. Thanks.

Well, I hope pointing to the mmCIF as an antecedent helps, here. 
I wouldn't be at all surprised if the creation of that format's
"protections" informed this more recent IUPAC licensing.

(for those trying to follow along at home who can't be arsed to
google/wikipedia this stuff,
 IUCr = International Union of Crystallography
 IUPAC = International Union of Pure and Applied Chemistry)

D. Joe Anderson          http://www.etrumeus.com/~deejoe
". . . we could end up with a situation where it's legal to own
hardware that automatically fires bullets really fast but
illegal to have software that automatically fires bits really
fast. -- Jenny Reiswig"

More information about the linux-elitists mailing list