Closed kceb closed 4 years ago
IANAL, but what problems do you foresee for users of rspec-expectations
?
I'm also not a lawyer, but my understanding is that as we don't distribute diff-lcs
we are not affected by their licensing, the whole group of gems together can/has to be considered to be dual MIT and GPL, but RSpec itself is only MIT licensed.
This is not normally a problem license wise because RSpec is a test tool, you can build other things with GPL compilers for example without the code they build being GPL. The distinction is usually in wether you include the source in your product, which is a hard distinction in a dynamic language, but I would heavily argue that as you don't typically vendor the code from gems into your project that they are as close to being statically linked as Ruby gets.
We also don't directly use the interface you mention, that doesn't mean diff-lcs doesn't use it for us under the hood though.
IANAL, but what problems do you foresee for users of
rspec-expectations
?
I'm just worried that we may develop a commercial rails api that utilizes rspec-expectations for tests. If we were to license the software used in the rails api, we might need to license it under a GPL license. That is, unless, the backend would be considered an "aggregate work".
Question is probably better suited for a lawyer, so perhaps I'll go that route. Was just wondering if you guys knew off the top of your head.
@JonRowe thanks for the explanation
I would ask your own legal counsel, but my understanding is your code is not GPL just because you use GPL tools. Your code doesn't include any portions of diff-lcs
so in this scenario you're fine.
Subject of the issue
I noticed this library depends on diff-lcs, which has three possible licenses (Artistic-2.0, GPL-2.0+, MIT). Could I get some clarification on how rspec-expectations settled on the MIT license if parts of diff-lcs are under a GPL license?
Is rspec-expectations not using
Algorithm::Diff
? Is that why it is able to be licensed under MIT?