Elastic promises "open"—delivers proprietary [LWN.net]

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 2:05 UTC (Mon) by mjg59 (subscriber, #23239)
In reply to: Elastic promises "open"—delivers proprietary by kemitchell
Parent article: Elastic promises "open"—delivers proprietary

I absolutely agree with the fact that it should not be possible for someone to simply take some code under a copyleft license, wrap it in something that calls into that code via a defined API, extends the original functionality of that code and is never under any obligation to share their modifications[1]. I assume the concern here is that "derived work" may not cover that case? You're certainly in a better position than me to have feelings about how a court might interpret the "practical substitute" language, but my gut feeling is that people would be happier if there was some more examples of cases that might or might not be considered a practical substitute.

(By the way, I *love* the option of releasing impacted code under different license terms. Even as someone who leans strongly towards copyleft, there are cases where imposing the same level of requirement on impacted code may not be the best way to encourage adoption)

[1] Although we may well differ in terms of when that obligation should kick in, and yes, once the situation has normalised somewhat I would appreciate the opportunity to discuss that

to post comments

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 2:26 UTC (Mon) by kemitchell (subscriber, #124442) [Link]

I could make legal arguments about the scope of "derivative work" in your hypothetical, but frankly, they're so deep in the weeds, not to mention arguable, that most non-lawyers would do best to just avoid the issue if at all possible. To give a sense, we don't even know for sure the full extent of what can be the "original work" a "derivative work" could be based on. If you copy and adapt the whole API, did you just create a "derivative work" of a copyrightable API design? Maybe the Supreme Court will get around to telling us next month.

As for the motive behind that drafting, it didn't have to do anything with whether an API wrapper or proxy would count as preparing a derivative work. As a practical matter, you're not going to develop, much less distribute, that kind of software without reproducing copies of the original. Which means you need a copyright license. Which can set its own terms. To my mind, it was 100% a problem of clear writing at the right level of abstraction. The language you saw was massively improved by input from others, and specifically others not irrevocably warped by legal education.

I'll never say that I originated the idea of copyleft that leaves a choice of more permissive terms, but the first time I saw it was in Parity, which I wrote for License Zero. I still go back and forth, finding hypotheticals when I'd want to require the same license terms, and also the other way around. Overall, I do think possession of source code is nine tenths of freedom, and that curtailing license-compatibility madness is a huge boon.

I've added you to my "after COVID" list. Hopefully we'll get a chance sooner than we expect.