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

Elastic promises "open"—delivers proprietary

Posted Jan 31, 2021 23:38 UTC (Sun) by mjg59 (subscriber, #23239)
In reply to: Elastic promises "open"—delivers proprietary by kemitchell
Parent article: Elastic promises "open"—delivers proprietary

I think this is a much more reasonable license than SSPL. I worry about a couple of things:

1) The requirement that changes be made available to the public even if the code isn't exposed to the public in any way. This feels like something that, realistically, just results in the software not being used for that purpose rather than increasing useful contributions. It's also something Debian has traditionally had objections to, for instance in cases where software is developed to use in activities that your government may not approve of.
2) There being a bunch of argument around what "practical substitute" ends up meaning

/Personally/, I don't think these affect the freedom of the license (although others might). I think (1) would be enough for me to avoid releasing any of my code under this license, but probably not enough for me to refuse to contribute to projects under it.

to post comments

Elastic promises "open"—delivers proprietary

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

First of all: I really appreciate your candid feedback. You didn't have to read a license just because I linked to it.

Second: Are you in Oakland? If so, we're overdue for a meet-and-greet. I have a pretty good excuse these days, but still...

You were right to home in on the fact that share-alike kicks in whether you "distribute" or not. That's an important point. I'd love to discuss if you're interested, but it's definitely a deep hole. My personal take is that it's essential for strong network copyleft, the Debian Desert Island and Dissident tests are more fun to think about than coherent or useful, and some existing licenses have gone there already, most notably OSL.

I was also super impressed to see that you alerted on "practical substitute", too. Not because I'm any kind of Super Lawyer, but because it's hard to cold read a new set of terms and issue spot like that. Takes a lot of attention.

The license had to draw a line around what users can do without releasing code and what requires releasing code. We didn't want to bind strongly to any particular means of software combination—copy-paste, linking, service composition—hence the focus on APIs. But you have to catch the "proxy" case where new code essentially just wraps the API of the existing code.

PolyForm project released two restricted licenses, Perimeter and Shield, that tackle analogous drafting problems. But for Round Robin, the mental model wasn't commercial anti-competition, but anti-fork, in the sense that MPL defended against closed or differently-licensed forks, in favor of a unified open project.

Again, real pleasure reading your comment.

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 2:05 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (1 responses)

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

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.