Elastic promises "open"—delivers proprietary
Elastic promises "open"—delivers proprietary
Posted Jan 28, 2021 1:38 UTC (Thu) by kemitchell (subscriber, #124442)In reply to: Elastic promises "open"—delivers proprietary by mjg59
Parent article: Elastic promises "open"—delivers proprietary
Howdy, Matthew. Hope you're doing alright.
The thing you must provide and license under *GPLv3 is "Corresponding Source". Here's the relevant part of the definition:
The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work’s System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. ...
The requirements to convey and license "Corresponding Source" are in section 6 and section 13 of AGPLv3.
*GPLv3 "invokes" the copyright concept of "derivative work" elsewhere, in the definition of "modify":
To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.
With legal X-ray glasses on: The phrase "requiring copyright permission" will catch "preparing derivative works" of the software under United States Code title 17, section 106, the list of exclusive rights of copyright holders in the Copyright Act. The phrase "based on" appears in that section, as well as the Copyright Act definition of "derivative work".
For what it's worth, I think we agree on implementation. SSPL, especially section 13 of SSPLv1, could be a lot better written. The v2 improvements, which Mongo proposed before fleeing the OSI scene, were an improvement, though still not great. Personally, I think forking AGPLv3 probably doomed them to confusion from the start. I suspect the lawyer who did the forking knew that, but could not convince their client. Having seen the difference between OSI process as perceived and OSI practice as practiced come crashing right down on their heads, it was just another bit of feedback they were done hearing, maybe even came to suspect as Trojan Horse.
I'm not sure whether we agree that the intended functionality of SSPL would make an open license. I certainly do. Partly out of frustration with the decision to start from AGPL, and then out of further frustration with the "review" process, which achieved no improvement to the v1 and couldn't be expected to, I drafted and shopped around a license we eventually called "Round Robin". More in an effort to depersonalize the proposal and the issues than anything else.
I don't know how to allocate responsibility for the total unproductive waste that was the OSI thread on SSPL. I see with just two eyes. Mongo definitely contributed, but they were hardly the only one. More naive than evil, methinks. In any event, I'm disappointed to see arguments that judge Mongo (or Elastic) rather than the terms. MIT and BSD certainly weren't drafted with "software freedom" in mind. It was at best one line of input to MPLv2 and EPL. But in the end, licenses are just tools. Especially when others not the drafter start using them.
The LWN site is currently under high scraper load, so comment display has been suppressed for anonymous users. If you are a human, you may read the comments by clicking the button below:
Note: you can avoid this step in the future by logging into your LWN account.
