[linux-elitists] [AlanMcNaught@dial.pipex.com: RE: [InChI-discuss] Re: InChI software license]
D. Joe Anderson
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
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) associated with that dictionary.
> > 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