@muratmaga to echo what Andras is saying, the problem with GPL code is that it we do redistribute software in the form of Slicer and Slicer Extensions. The terms of the GPL are such that if we include even one line of GPL licensed code in our distribution, then the copyright holder of that one line could insist that all other code in the same distribution needs to be GPL. This would prevent people from using Slicer as the basis for non-public extensions (e.g. if making a medical device based on Slicer or even release binaries of pre-publication work in progress).
That’s why Andras and I and others (including the ITK community) are careful not to rely on GPL code. In actual practice it would becomes very restrictive and counter-productive. There’s a large literature on this so I won’t repeat it here, but the Linux kernel has specific clarifications about how it can be used in and redistributed and that’s one reason it’s so popular in products.
Anyone writing software that incorporates GPL code you should carefully read up on the terms and understand what obligations come with it. The code may be so good that accepting those obligations is the best solution, but other times its best to find workarounds that are compatible with the licensing.
For us, the workaround of using R and other GPL’d code as an executable or network server sounds the cleanest way to address this for now. It will allow us to make progress without raising license issues that may be hard to resolve.
Once we have the python 3 issues sorted out then users will be able to install R and R packages independently, and that will sidestep the distribution issues since it won’t be us distributing the software but the user installing it. If Slicer only provides interfaces that are compatible with R then we don’t have the license issues.
I wish this weren’t so complicated but it’s the situation we have. Fortunately the processes we have in place have worked well. As long as we are careful there are no technical or legal hurdles that will get in our way.