I am forwarding the following open request from OpenEye through the
InChI-discuss list. Now that gthe details are clear I would be grateful if
the critical aspects could be re-reviewed.

There is an issue for me and a co-author and I'd like to know
authoritatively what the implications of re-licensing are. If they are
compelling for relicensing I will probably need little persuasion - if they
are not, I'll consider.

FWIW it highlights the problem of multiple authors. The permission of all
authors is required, and of course they may not be locatable.


---------- Forwarded message ----------
From: Alan McNaught <[email protected]>
Date: Fri, Jul 30, 2010 at 5:23 PM
Subject: [InChI-discuss] Licensing of InChI software
To: [email protected]


 IUPAC and the InChI Trust have received the following request from OpenEye
concerning licensing of the InChI software. We would welcome comments on
this before proceeding further.



Alan McNaught



_______________________________________

*From:* Joe Corkery
[mailto:[email protected]]<%5bmailto:[email protected]%5d>

*Sent:* 30 July 2010 16:27
*Subject:* InChi Dual Licensing



To whom it may concern,



I am writing on behalf of OpenEye Scientific Software to inquire as to
whether it would be possible to use the InChI library under a different
license than the LGPL (e.g. the MIT or BSD licenses). While we understand
and appreciate the rationale for using the LGPL as a means to make it
possible to use the InChI library in closed source/proprietary applications,
there are still certain restrictions in the LGPL which can make integration
with LGPL code challenging at best if the desired usage is static linking
against the InChI library. I direct your attention to section 6(a) of the
LGPL 2.1 license which states that any developer who wishes to link the
InChI code statically would have to:



    a) Accompany the work with the complete corresponding

    machine-readable source code for the Library including whatever

    changes were used in the work (which must be distributed under

    Sections 1 and 2 above); and, if the work is an executable linked

    with the Library, with the complete machine-readable "work that

    uses the Library", as object code and/or source code, so that the

    user can modify the Library and then relink to produce a modified

    executable containing the modified Library.  (It is understood

    that the user who changes the contents of definitions files in the

    Library will not necessarily be able to recompile the application

    to use the modified definitions.)



As you can see, this section is quite explicit in that for any executable
using LGPL code the developer must provide the "work that uses the Library"
as either object code or source code so that the end user can modify or
replace the LGPL code to create a new executable. This is also nicely
detailed in the following Wikipedia article:



http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License#Differences_from_the_GPL



The requirement to distribute (or at a minimum to offer to distribute) all
of the object code as well as the mechanisms to rebuild the executable make
the LGPL difficult to comply with for software vendors that require static
linking of the library for the integration to be feasible. It is my
understanding that the goal of the InChI Trust is to widely promote and
enable broad usage of the InChI and it is our belief that sole licensing
with the LGPL is a significant obstacle towards achieving that goal.



As an alternative to dual licensing, if the above requirement to enable the
end user to be able to replace and rebuild the executable with an alternate
version of the LGPL code were removed in an updated license issued by the
InChI Trust, that should enable all software vendors to distribute their
software without the concern for having to release their own code and build
mechanisms but still would require them to reference their use of the LGPL
code and distribute any changes made to said code.



I hope that you will receive this request favorably as we think it is one
with minimal downside and a large opportunity to increase the exposure and
utility of InChi. Please do not hesitate to contact me directly if you have
any specific questions.



Sincerely,



Joe Corkery





--

Joseph Corkery, M.D.

Vice President, Business Development

OpenEye Scientific Software

[email protected]







------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
InChI-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/inchi-discuss




-- 
Peter Murray-Rust
Reader in Molecular Informatics
Unilever Centre, Dep. Of Chemistry
University of Cambridge
CB2 1EW, UK
+44-1223-763069
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Blueobelisk-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Reply via email to