Please clarify the license that covers this code

[fedorov]

The license file says GPL, but the bottom of the README file says Apache-2. Which one is it?

[fedorov]

FYI @kirbyju

[skim2257]

We'll address this right away. Thank you for letting us know.

[fedorov]

Thank you.

I have to say that I was hoping the right license would be Apache-2. The choice of GNU is unfortunate, as it will significantly limit the adoption of this library. Speaking for myself, given it is GNU, I cannot even consider it as an option.

I see you do have a bunch of other repositories in your org distributed under MIT, which is a much friendlier license. Why GNU for this one?

[skim2257]

First of all, thank you for your interest and truly appreciate your thoughtful questions.

We chose our licenses based on each project/package's scope and implications. In the case of med-imagetools, our package exists to help researchers create end-to-end reproducible medical image processing pipelines, that can be shared publicly and transparently. This was the specific use case we envisioned our package to be solve, within our lab's mandate of open science.

Would you mind sharing with us a use case that's restricted by GPL-3 that could benefit from a more permissive license?

[fedorov]

The overall use case is that we, medical imaging scientists, in general, are interested in developing solutions that will ultimately be implemented in commercial products that will help patients in the clinic. The tricky part is that in general, it is not possible to tell if, how or when a specific piece of code may be helpful in a product. What we do know however is that if a certain piece of code is shared under GPL, it is highly unlikely to be touched by any entity developing commercial code because of its constraints (any modifications must be shared under the same license, source code must be shared, ...).

I am not a legal expert to explain or even understand in detail all of the terms of this lengthy GPL license. But I encourage you to look at the prominent open source medical imaging projects that many in our community will agree did made a dent (e.g., ITK, VTK, 3D Slicer, DCMTK, MITK, OHIF, pydicom, Plastimatch, dcm2niix, pyradiomics, nnU-Net, TotalSegmentator ... PyTorch, MedSAM) - none of them uses GPL licenses, and instead use MIT, Apache-2 or 3-clause-BSD license.

I have a feeling (it may be wrong) that developers of open source tools adopt GPL because they just assume GPL means "good". It is not. I have yet to see evidence of that. I would strongly encourage you to consider a non-restrictive standard license instead. IMHO, medical imaging software distributed under a GPL license is unlikely to have a bright future. There will always be exceptions, I agree, but I am struggling to find even one relevant here. Among the various tools that are recognized, perhaps ITK-SNAP and Horos come to mind that are under GPL, but what was the last time you used a tool developed on the basis of those, or used them as a component of something you built yourself?

Disclaimer: I have not evaluated your tool, I don't promise I would recommend or use it if you switch the license! It was mentioned to me by someone else, and before doing anything, I always check the license first, and GPL is a non-starter for me.

[skim2257]

@fedorov We really appreciate your insight and are happy to move to the MIT license! It is now merged and our official license. Thank you.

[fedorov]

@skim2257 thank you for your consideration and for revisiting the license!

I will try to make the time to review the functionality, and will reach out separately if I have any related comments.