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

Re: Please help freeing libcolt-java

Hi Thorsten!

Thorsten Glaser wrote:
Can you, or anyone really, give some detail on what exactly is the problem here (which files)?

I'm sorry for not having been more specific from the beginning. Given that you had brought up the interface aspect yourself, I thought we were on the same page.

Anyway, here my specific concern: Some types (be it implementation classes directly or Java interfaces) of hep.aida.* appear (as parameter types and/or return types) in the signatures of public functions of libcolt. This occurs in the following places:

* toTitleString (696): hep.aida.bin.BinFunction1D
* toTitleString (774): hep.aida.bin.BinFunction1D

* sort (432): hep.aida.bin.BinFunction1D

* aggregate (148): hep.aida.bin.BinFunction1D
* bin (215): hep.aida.bin.DynamicBin1D
* cube (320): hep.aida.IHistogram2D
* cube (359): hep.aida.IHistogram3D
* histogram (497): hep.aida.IHistogram1D
* histogram (508): hep.aida.IHistogram2D
* histogram (520): hep.aida.IHistogram2D
* histogram (532): hep.aida.IHistogram3D

This makes it impossible to separate the interfaces (meaning the set of signatures that the library provides) of libcolt from the one of aida. Either you keep the full signatures (the "interface") of hep.aida.IHistogram1/2/3D, hep.aida.bin.DynamicBin1D and hep.aida.bin.BinFunction1D with changed implementations - which might be a legal problem, that's what I'm not sure of. Or we use alternative parameter/return types - but that breaks the interface of libcolt: Reverse dependencies might have to be patched in order to work with the method signatures provided by the new types.

Do not bother with debian-legal on this. They are no body of Debian, just a mailing list with parties interested in discussing legal issues, not even lawyers, and often disagreeing with the formal project opinion.

Good to know, thanks.


Reply to: