ocrd_anybaseocr
ocrd_anybaseocr copied to clipboard
OCR-D
Wrong license?
The cropping part uses lsd, and lsd.cpp uses AGPL 3. Linking AGPL 3 binaries requires AGPL 3 for the final product, too.
The problem is actually upstream in the pylsd package, so I've opened https://github.com/primetang/pylsd/issues/20.
There's an LSD implementation in OpenCV which may represent a possible alternative.
There's an LSD implementation in OpenCV which may represent a possible alternative.
Yes – the problem is that it's not nearly as good, and has next to no parameters for adaptation.
For ocrd-anybaseocr-crop, we rely heavily on this one detector in how we set detection parameters, what kind of line segment candidates we expect to get so we can group and rate them in a meaningful way. – And it's the only good cropper for historic prints we have at the moment...
It's also possible to fix the license either for ocrd-anybaseocr-crop only (maybe that would require splitting the repository) or for the whole ocrd_anybaseocr. I think OCR-D processors with GPL or AGPL may be used.
@kba, @bertsky, this is a serious legal issue which should be fixed soon. If @primetang is not willing or able to fix the problem in the original code, it must be fixed in the fork and here.
Sure, let's wait for his commentary first, then if necessary switch to AGPL for the whole lot.
Sure, let's wait for his commentary first, then if necessary switch to AGPL for the whole lot.
(But perhaps we should ask the original contributors if that's ok – @n00blet @mahmed1995 @mjenckel @khurramHashmi. Otherwise we must indeed split up the repo.)
@stweil Thanks for resurrecting this. @primetang isn't going to be able to help with the license, because the code actually belongs to @rafael-grompone-von-gioi. The only thing Gefu Tang added to the code was a hacky function to return data via a file. The original code is available here as a supplement to this journal article.
On the plus side, @rafael-grompone-von-gioi has shown some willingness to relicense code in the past for the OpenCV project, so perhaps he'd be willing to do so in this case.
I missed the fact that the immediate upstream is actually https://github.com/kba/pylsd which generates the PyPI package called ocrd-fork-pylsd (not sure why it's not included in the OCR-D org), so the license should be fixed there, whether or not the upstream license gets fixed.
Consideration might also be given to updating to 1.6 and switching to a memory-based API instead of the current file-based hack.
@tfmorris thanks for clarifying this, and for https://github.com/kba/pylsd/pull/4!
Consideration might also be given to updating to 1.6 and switching to a memory-based API instead of the current file-based hack.
Oh, I did not notice that before. (I do remember wondering why the lsd standalone tests look different from my pylsd results, but did not investigate.) Quite a significant difference! Needs to be tested thoroughly with regards to its impact on parameters and postprocessing in ocrd-anybaseocr-crop...
called ocrd-fork-pylsd (not sure why it's not included in the OCR-D org),
Agreed, would make more sense – @kba?
called ocrd-fork-pylsd (not sure why it's not included in the OCR-D org),
Agreed, would make more sense – @kba?
Sure, moving to OCR-D is not a problem, I did not realize that we would depend on this fork for so long, hence the PyPI name. Changing the license is also straightforward - thanks @stweil @tfmorris for raising this concern.
Fixing the build process and updating the API will take longer.
Is there anything new regarding this issue? If not, we should fix the license by switching to AGPL 3 soon.