License
nikolay-ulyanov opened this issue · comments
Could you clarify, please, your work currently has MIT license, but SuperCollider has GPL license, which is more restrictive, so I have a couple of questions:
- Could your work be considered a derivative of SuperCollider? I've found reasoning about this about another sc3 library - https://scsynth.org/t/sc3-vs-supriya-as-python-scsynth-front-ends/5140/6 - does this reasoning apply to your library too?
- If it is a derivative - I think MIT license is incompatible with GPL license, right?
How is it derivative?
The sc3 library, as I understand it, was explicitly created as a translation or sclang into Python. Supriya was not created with that intention.
I mean, I'm not a lawyer, and maybe your project is not derivative of SuperCollider; but your project depends on SuperCollider, right? And from what I find in Google, this probably means, that your library also should use GPL license, but again, I'm not a lawyer and just trying to understand this stuff.
I guess it depends on what "depends" means. I don't think interacting with scsynth's OSC API counts.
If anything maaaybe supriya should have a license like sonic-pi's (https://github.com/sonic-pi-net/sonic-pi/blob/dev/LICENSE.md) which is MIT except for a couple files here and there. I would be done for that, but it's not high on my priorities to write.
Alternatively I would just remove the one cython file that knows about SC's source, leaving my MIT code intact.
Thanks!
I've read a bit more, it seems that there's actually no definite answer to this situation, e. g.
https://opensource.stackexchange.com/questions/6033/can-a-non-gpl-python-program-use-gpl-python-module
https://opensource.stackexchange.com/questions/1187/what-are-the-arguments-for-considering-dynamic-links-to-constitute-derivative-wo
So yeah, I'll close the issue then.