search

IUPAC-InChI / InChI

Main InChI repository
https://iupac-inchi.github.io/InChI-Web-Demo/
MIT License
69 stars 9 forks source link

remove references to previous inchi license #33

Closed giallu closed 3 months ago

giallu commented 4 months ago

As mentioned https://github.com/IUPAC-InChI/InChI/issues/8#issuecomment-1953631931

the INCHI-1-SRC/LICENCE.pdf file should be removed

Additionally, here is a list of places to review and eventually have the license replaced/removed

> grep -rl "InChI-Trust Licence" *
INCHI-1-DOC/misc/announce.txt
INCHI-1-DOC/misc/banner-v105-from-alan-2016-02-18.txt
INCHI-1-DOC/misc/banner-v105-final-2016-02-18.txt
INCHI-1-DOC/CHANGELOG.md
INCHI-1-DOC/FAQ/html/inchi-faq.html
INCHI-1-DOC/FAQ/doc/inchi-faq.doc
INCHI-1-DOC/External-contributors/External-contributors
INCHI-1-DOC/readme.txt
INCHI-1-SRC/INCHI_BASE/redundant/aux2atom.h
INCHI-1-SRC/INCHI_BASE/src/sha2.c
INCHI-1-SRC/INCHI_BASE/src/sha2.h
INCHI-1-SRC/INCHI_API/demos/inchi_main/readme.txt
INCHI-1-SRC/INCHI_API/demos/mol2inchi/readme.txt
INCHI-1-SRC/INCHI_API/demos/mol2inchi/src/moreutil.c
INCHI-1-SRC/INCHI_API/demos/mol2inchi/src/mol2inchi.h
INCHI-1-SRC/INCHI_API/demos/mol2inchi/src/moreutil.h
INCHI-1-SRC/INCHI_API/demos/mol2inchi/src/mol2inchi.c
INCHI-1-SRC/INCHI_API/demos/python_sample/readme.txt
INCHI-1-SRC/INCHI_API/demos/readme.txt
INCHI-1-SRC/INCHI_API/demos/test_ixa/readme.txt
INCHI-1-SRC/INCHI_API/demos/test_ixa/src/moreitil.h
INCHI-1-SRC/INCHI_API/demos/test_ixa/src/moreutil.c
INCHI-1-SRC/INCHI_API/demos/test_ixa/src/test_ixa.h
INCHI-1-SRC/INCHI_API/demos/test_ixa/src/test_ixa.c
INCHI-1-SRC/readme.txt

Please note, the license of files with no explicit text defaults to the one included in the package so removing all the license info from headers is an option to avoid this kind of issues in the future

nbehrnd commented 4 months ago

@giallu A supporting «+1» from my side because this compilation could help the maintainers to remove the obstacles which prevent an update of the inchi executable in Debian (package tracker). This then would propagate into Debian's relatives (Ubuntu, Mint, etc), too. See the corresponding ticket over there, filed by July 17th.

giallu commented 4 months ago

@nbehrnd yeah, as a (former) Fedora package maintainer I am very much familiar with issues like this...

@JanCBrammer would you consider a PR with these changes implemented?

giallu commented 4 months ago

So, there is a little complication here in sha2.h/c because they are are Copyright (C) Brainspark B.V.

Someone has to contact the copyright holder and get permission to relicense or, alternatively, a new implementation should be added.

JanCBrammer commented 4 months ago

@JanCBrammer would you consider a PR with these changes implemented?

Absolutely!

kiddr commented 4 months ago

I have some correspondence from 2010 where we previously got agreement from the copyright owner to change the licence to the text below (including the proviso that it only applies to the InChI implementation). As this includes the reference to the MIT license (e.g. to dual license), I need to dig a bit further to find out why we didn't go through with this at the time, and updated the bespoke license

Change the text in the file 'readme.txt' in the INCHI-1-API archive/directory (directory with source files).

Currently it is: "The portion of this distribution, the files sha2.c and sha2.h are Copyright (C) 2003-2006 Christophe Devine and are distributed under the terms of the GNU Lesser General Public License, version 2.1 as published by the Free Software Foundation (see heading comments in these files).

LGPL text is included (the file LICENSE) in this distribution."

Suggested replacement: "The portion of this distribution, the files sha2.c and sha2.h, were originally written by Christophe Devine who then transferred the copyright to Paul Bakker for PolarSSL library (http://www.polarssl.org/).
As allowed by Paul Bakker and Christophe Devine, these files are distributed with the InChI software under the terms of either the GNU Lesser General Public License, version 2.1, or MIT license. Note that this licensing is only valid in combination with the InChI software package and not for the files sha2.c and sha2.h in its own.

LGPL and MIT license texts are included (the files LICENSE and MIT-LICENSE) in this distribution."

3

Place the text of MIT license (from http://www.opensource.org/licenses/mit-license.php) in the file MIT-LICENSE in the INCHI-1-API archive/directory (directory with source files).

4

Change the heading comments in the files sha2.c and sha2.h.

Currently it is: /*

Suggested replacement: /*

flange-ipb commented 3 months ago

I'm wondering whether InChI's SHA-256 implementation could be replaced with a library call (e.g. from libcrypt) or with a less problematic implementation.

Implementations I found so far:

kiddr commented 3 months ago

OK, I have reviewed the discussions from 2010. At the time, we shied away from dual licensing as at that point it wasn't easy for others to contribute to the open source code, so individual fixes may not have been donated back to the codebase. We are no longer in that position, so it sounds like either: a) we use the existing implementation, which would require some text acknowledgement as suggested/agreed above (obviously removing the LGPL references). readme.txt and in the headers of the sha routines? b) we replace the implementation - was also suggested back in 2010, but not with any specifics. Presumably comes with a testing overhead

Let me know if you wish me to reconfirm text in a) with the copyright owner

giallu commented 3 months ago

Implementations I found so far:

Also https://github.com/amosnier/sha-2 has a very liberal and compatible license.

djb-rwth commented 3 months ago

OK, I have reviewed the discussions from 2010. At the time, we shied away from dual licensing as at that point it wasn't easy for others to contribute to the open source code, so individual fixes may not have been donated back to the codebase. We are no longer in that position, so it sounds like either: a) we use the existing implementation, which would require some text acknowledgement as suggested/agreed above (obviously removing the LGPL references). readme.txt and in the headers of the sha routines? b) we replace the implementation - was also suggested back in 2010, but not with any specifics. Presumably comes with a testing overhead

Let me know if you wish me to reconfirm text in a) with the copyright owner

I would definitely opt for solution a). The reason is simple: how can one know if the licences of the above proposed new solutions are not be changed (or that these GitHub repositories will not just be deleted by the author), and that SHAx .c/.h files/sections will not have to be rewritten each time that happens? Revising a licence seems less time wasting than rewriting the same code all over again so it could fit a new licence and/or GitHub solution.

giallu commented 3 months ago

I would definitely opt for solution a). The reason is simple: how can one know if the licences of the above proposed new solutions are not be changed (or that these GitHub repositories will not just be deleted by the author), and that SHAx .c/.h files/sections will not have to be rewritten each time that happens? Revising a licence seems less time wasting than rewriting the same code all over again so it could fit a new licence and/or GitHub solution.

This is a sensible concern; I think one long term solution is to get those files (with their current license) and add them to the repo replacing the current implementation. You need to do this exactly once unless at a later point in the future you want to get some updated code where they actually changed the license (which seems unlikely, at least with the repo I linked)

Since there is a nice regression test suite in inchi this change looks also not that risky, given it can be checked against an arbitrary number of compounds

kiddr commented 3 months ago

Update on the SHA code:

Copyright was sold to ARM and now expressed in the Mbed-TLS project - which is dual licensed as Apache or GPL SHA code here

I believe Apache is compatible with MIT - although the Mbed-TLS code is newer than the one we are reusing, is it sensible/acceptable to bring across the Apache license to the SHA code? I can ask inchi-discuss for more comment if we need more views.

nbehrnd commented 3 months ago

@kiddr Debian compiled a survey about programs licenses acceptable here within Debian, which includes Apache (subsection 3), GPL (subsection 12), and MIT (subsection 14). They equally appear here among the ones used in the main section.

@merkys Because of maintainership in Debian, do the changes proposed qualify as «good enough» for an eventual update in Debian?

giallu commented 3 months ago

I believe Apache is compatible with MIT - although the Mbed-TLS code is newer than the one we are reusing, is it sensible/acceptable to bring across the Apache license to the SHA code? I can ask inchi-discuss for more comment if we need more views.

As far as I know yes, they are compatible but the implementation needs to be updated to the one with the correct license, you can't just stick the new license to the old implementation.

Of course everything needs to be tested for regression so I guess the amount of work to do is the same as any other replacement code. At this point it seems someone needs to approve one of the implementations mentioned

kiddr commented 3 months ago

Thanks @giallu @nbehrnd - I can see the issue of applying a new license to old code.

I guess ahead of any investigation/swapping of replacement code, we could apply the text agreed in 2010 but not used. which I think is what is there in your latest update

giallu commented 3 months ago

I guess ahead of any investigation/swapping of replacement code, we could apply the text agreed in 2010 but not used. which I think is what is there in your latest update

Correct. I have used the text you provided in https://github.com/IUPAC-InChI/InChI/issues/33#issuecomment-2255659013 to update the license of those two files.

I am not sure how the additional restriction "this is valid only in conjunction with the Inchi library" is going to fly with the legal teams usually behind larger distros, but the current text is a blocker so I would start from merging this change

djb-rwth commented 3 months ago

Closed with PR #34.

nbehrnd commented 2 months ago

@kiddr Thanks to work by @merkys, InChI 1.07.1 was admitted today into Linux Debian's branch testing (note by Debian's package tracker, the monitor by repology). The contents of this branch prepares the next release of Debian 13/trixie itself; other distributions closely related (e.g., Ubuntu, Mint) typically benefit from this, and update their repositories within a couple of days, too.

The many others may prepare an update when deemed suitable for them.

Packaging status

merkys commented 2 months ago

Thanks a lot for making the update of InChI library possible! By the way, some files under INCHI-1-SRC/INCHI_API/demos/python_sample/ still contain the previous InChI Trust license.