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

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 19:21 UTC (Wed) by pizza (subscriber, #46)
In reply to: Elastic promises "open"—delivers proprietary by kemitchell
Parent article: Elastic promises "open"—delivers proprietary

> Mongo withdrew SSPL from OSI consideration. But not because it was convinced its license wasn't "open source". Have a look at the mailing list message hyperlinked. It starts with a statement of the opposite.

Do I really have to point out that simply stating that the sky is green doesn't actually make the sky green?

"We continue to believe that the SSPL complies with the Open Source Definition and the four essential software freedoms. However, based on its reception by the members of this list and the greater open source community, the community consensus required to support OSI approval does not currently appear to exist regarding the copyleft provision of SSPL. Thus, in order to be respectful of the time and efforts of the OSI board and this list’s members, we are hereby withdrawing the SSPL from OSI consideration."

In other words, "we think the SSPL complies with the open source definition, but the community who actually makes that determination disagrees with us, so we're withdrawing it to avoid wasting everyone's time."

to post comments

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 20:30 UTC (Wed) by kemitchell (subscriber, #124442) [Link] (37 responses)

I'd invite anyone interested to have a look at the OSI review thread from the beginning. Especially if you're expecting to find a bunch of staid debate around definitional conformance and legal rigor. You'll find precious little of that, and a whole lot more invective and "What is the process, anyway?" confusion.

OSI review is a political process, not a technical one. It's just that it prefers to seem technical, especially as the dominant voices on the political front change. I understand there's a committee within OSI looking at revising the Open Source Definition right now, to try and regain some of that cover. As I recall, all the OSD-based arguments against SSPL would have disqualified other, already approved copyleft licenses. No consistency, just motivated reasoning.

To my mind, this wasn't Mongo trying to get OSI to call a closed license open. It was OSI refusing to call an open license open, or to explain rigorously why it was not. Mostly by putting Mongo, rather than SSPL, on trial.

Mongo didn't even get to speak for itself and be heard. Despite several messages explaining a consistent motive for the new terms, those who signed onto the list to "block" preferred their conspiracy theory about what Mongo really meant. But "blocking" and "consensus" don't have anything to with whether a license follows free or open principles. Copyleft licenses have never been welcomed by proprietary software firms. That's the point.

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 21:56 UTC (Wed) by mattdm (subscriber, #18) [Link] (36 responses)

I mean.... I'm not a lawyer, but it seems intentionally to violate the spirit and letter of several of the key points of the open source definition just on the face of it. Like, it's explicitly designed to not fit them, and that's not a secret, because the companies and people pushing them have outright declared their goals. That's different from "this license intends to actually be a usable free software / open source license but has some quirks." So, I can see there not being much space for a reasonable discussion about how just maybe those points don't mean anything. Whether this makes it "political" rather than "technical" is a distraction.

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 23:10 UTC (Wed) by kemitchell (subscriber, #124442) [Link] (35 responses)

You're by no means alone looking at OSD and seeing language that could be turned against SSPL. That's the primary feature of the OSD: It's a kind of mirror. Gaze upon it and see your heart's true desire.

The most compelling sections are the least specific, and legal training doesn't reveal and clear, specific meaning of them. It's not a legal document. It was a marketing pitch.

The two most common OSD-based arguments I've seen fall into two categories: "nondiscrimination" and "other software". These correspond to OSD 5/6 and 9, respectively.

The trouble with the nondiscrimination criteria, read broadly, is that they'd preclude all copyleft. Copyleft discriminates against closed source development. RMS wrote GPL to discriminate against non-free software and non-free software makers. The whole point was to use copyright against non-free software, as non-free software was using it against free. Free software, and by extension open source, taught the difference between open and closed, and came out strongly for open. "Discriminating" against closed software isn't antithetical to open source, but the point. The choice open source offered to developers was whether to effect that distinction through licensing, by choosing copyleft rather than permissive terms. Both are "open source".

The other-software arguments try to go the other way. Instead of working down from a vague criterion to an oddly specific rejection, they start from a specific criterion, OSD 9, and try to argue that it should really be vague and general.

The Open Source Definition is a thinly rebranded fork of the Debian Free Software Guidelines, an earlier statement of criteria for inclusion in Debian. Debian needed to be able to distribute software packages in gross, including on physical media. It couldn't handle packages that said they could only go on the same CDs as, say, other GPL-licensed software or other public domain software. That concern about distribution of packages that already had license terms had nothing to do with copyleft, which steps in to say what license has to apply to new code when linking, copying-and-pasting, or otherwise building on existing free software. We see this in an annotated version of the OSD that OSI published some years back:

Yes, the GPL v2 and v3 are conformant with this requirement. Software linked with GPLed libraries only inherits the GPL if it forms a single work, not any software with which they are merely distributed.

I'm not against honest argument that open source should deprecate copyleft, or that open source should set limits on how far copyleft can reach, or even what "uses" of the software can trigger the obligation to share alike. I am strongly against claims that all those points have already been settled, or that the Open Source Definition (or What is Free Software? from FSF) provides clear answers. That's begging the question.

Judging by what Mongo said to OSI, I genuinely believe they wanted to talk through those issues. The response from their loudest opponents—but by no means all their opponents—has been to derail, insult, insinuate, and generally avoid substantive discussion by all means, fair and foul. In their position, I'd prefer process to substance, too. I think their arguments are losers. Looking to the past, these kinds of licenses were welcome. Here in the present, cloud firms don't like it. They learned their lesson from the approval of AGPL, despite it being clearly targeted at Google. Now they're the hand that feeds.

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 23:42 UTC (Wed) by pizza (subscriber, #46) [Link] (10 responses)

> The trouble with the nondiscrimination criteria, read broadly, is that they'd preclude all copyleft.

Except they're not "read broadly", they're read within the context of copyright law, which narrows things down considerably.

(Restrictions in a copyright license can only apply to activities covered by copyright. So a copyright license can be _more permissive_ than the default "all rights reserved" but it can't be _more restrictive_ because, absent a separate contract, the copyright holder doesn't have the ability to restrict those activities)

> Copyleft discriminates against closed source development.

So what? "closed source development" discriminates against closed source development. Have you never read the wall of license text for any "closed-source" software you've used?

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 0:09 UTC (Thu) by kemitchell (subscriber, #124442) [Link] (9 responses)

I believe you're mixing two disparate concepts.

One is the idea that copyright licenses—setting aside the dubious hard distinction between licenses and contracts—have to regulate conduct covered by copyright. That's true. In the USA, terms license—or permit—others to do what would otherwise be prohibited for anyone but the copyright holder under 17 U.S.C. 106.

To put that more concretely, if you're going to sue someone for copyright infringement, you need to show the court that they did something with your work that involved one of the exclusive rights of copyright owners, without permission. Rights like reproducing, distributing to the public, preparing derivative works, or publicly displaying or performing. This is usually very easy to do with software, since running it usually entails copying, sharing distribution, and building on it preparing derivative works.

The other is the idea of what license terms can say, and what rules they can impose, in return for permission to do what copyright would otherwise prohibit. In other words, what you get in exchange for granting a license. In commercial context, that usually includes some money. But for either open or closed software, it almost always involves some obligations and boundaries, too.

For example, setting copyleft entirely aside, nearly all common open source licenses require passing along notices of license terms with copies of the software. That's not a part of copyright law, or specifically called out as something only copyright owners can choose not to do. It's implemented as a condition to being able to reproduce and distribute to the public.

There are some limits on what you can demand in exchange for copyright permission. The usual prohibitions on illegal terms, terms against public policy, potential competition law violations, and so on. There are also some limits specific to copyright, like the doctrine of "copyright misuse". These come up rarely, and tend to narrow in time. Copyright misuse came about largely by analogy to patent doctrine, but is currently much disfavored by the courts.

I'm afraid I don't follow your point on discrimination and copyleft. If it helps, I'm a practicing California attorney advising primarily software companies and developers. I've written, read, and negotiated countless licenses.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 1:00 UTC (Thu) by pizza (subscriber, #46) [Link] (8 responses)

> For example, setting copyleft entirely aside, nearly all common open source licenses require passing along notices of license terms with copies of the software. That's not a part of copyright law, or specifically called out as something only copyright owners can choose not to do. It's implemented as a condition to being able to reproduce and distribute to the public.

Yes. But the key here is "with copies of the software" -- If you do not make a copy of the software (or create some derivative work) then those conditions/restrictions cannot not apply to you, as all other activities (including running/using the software!) are out of scope.

(and since the ephemeral copies/adaptations made by installing/loading/compiling/etc is "an essential step in the utilization of the computer program" they can't be used as a hook to impose field-of-use restrictions)

> I'm afraid I don't follow your point on discrimination and copyleft. If it helps, I'm a practicing California attorney advising primarily software companies and developers. I've written, read, and negotiated countless licenses.

(Were these licenses you negotiated stand-alone copyright licenses or were they part of larger contracts?)

My point about discrimination is that the way you were saying it should be interpreted is so broad that it it is effectively nonsensical; any restriction at all becomes "discrimination" of some form or another. Especially copyright itself.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 1:58 UTC (Thu) by kemitchell (subscriber, #124442) [Link] (7 responses)

On license conditions: There are "public licenses" outside the open source canon that impose enforceable restrictions on manner and purpose of use. For example, Creative Commons Non-Commercial. We also see use and territory limitations in other public grants, like unilateral technology pledges. The recent Open COVID Pledge comes to mind. As far as I know, there's no rule of law that says you have to license exclusive rights of copyright holders entire, without limits. You can grant less, and draw the line in your own terms.

I believe your comment on negotiated contracts is going for a distinction between license and contract. I'd invite you to have a second look at that, from primary sources rather than commentaries. It was part of the FSF catechism, especially via Eben Moglen, for many years. Largely, I think, as a kind of rearguard action to try to influence copyright law policy, which came to naught, but also a reflection of the fact that it just hand't come up is US court yet. I'd argue subsequent legal developments went decided the other way, even setting aside countries like France where the distinction never made any sense.

Plaintiffs suing for license violations tend to make both copyright and contract claims. See, for example, all the lawsuits Artifex brought about Ghostscript. And it's unclear how a US court would interpret and apply license terms, other than by applying contract-law rules. There are some legal questions about preemption—legal double dipping—which might prevent winning both a contract claim and an infringement claim for the same conduct. But that matters largely when it comes to what you can get the court to order if you win—legal "remedies"—not whether you have the right to set rules in the first place.

Sounds like we actually agree on "nondiscrimination". I don't argue that the nondiscrimination criteria, as written, should preclude copyleft. Others try.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 3:00 UTC (Thu) by pizza (subscriber, #46) [Link] (6 responses)

> On license conditions: There are "public licenses" outside the open source canon that impose enforceable restrictions on manner and purpose of use. For example, Creative Commons Non-Commercial.

Of course! But they can still only impose conditions tied to activities that fall under the purview of copyright. That is to say, making copies or derivatives. If you don't engage in those activities (eg by making further copies), then those conditions simply do not apply.

(If I am wrong here, I would appreciate a proper explanation...)

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 4:06 UTC (Thu) by kemitchell (subscriber, #124442) [Link] (5 responses)

I'm not quite sure I know where you're coming from, but as a stab in the dark: Are you familiar with 17 USC 117, the way it differed from the CONTU proposal, the licensed-versus-sold distinction, and Vernor v. Autodesk?

So it doesn't go unsaid: I appreciate your comments. It's clear you've put time and thought into this. And I'm not any kind of guru with all the answers. Just another schmuck who's put too much time and thought in to quit.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 12:02 UTC (Thu) by pizza (subscriber, #46) [Link] (4 responses)

> Are you familiar with 17 USC 117, the way it differed from the CONTU proposal, the licensed-versus-sold distinction, and Vernor v. Autodesk?

Yes, Yes, Yes, and... somewhat. :D

That unattributed "Rightful Possessor" vs "Owner" change is still being argued over in many venues, with the "we agree this decision sucks, but we're bound by precedent, and it's up to Congress can fix this" punt in Vernor v. Autodesk appeal. Meanwhile, that "licensed vs sold" hand-wavery attempt to avoid transferring "ownership rights" (while simultaneously saying things like "own your copy today" in advertising copy) is one of the reasons laypeople have strong opinions about the legal profession.

But there can still be an effective "transfer of title" that occurs when the copy is handed over, which means the recipient is a "owner" of the copy. (see the UMG vs Augusto case, where the 9th circuit ignored their Vernor precedent. That scenario does seem more directly applicable to F/OSS than Vernor..)

What a mess, eh?

> Just another schmuck who's put too much time and thought in to quit.

Don't sell yourself short; unlike nearly everyone else here, you actually _are_ a lawyer, and have direct experience with this stuff.

So, um, thank you for sticking through this too!

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 15:15 UTC (Thu) by kpfleming (subscriber, #23250) [Link]

I know it's a divergence, but 'while simultaneously saying things like "own your copy today" in advertising copy' is such an important point.

At the same time that the major US content producers leverage the DMCA as a cudgel, and push the RIAA to act on their behalf, those same content producers loudly proclaim that you can 'own' a movie by purchasing a copy. The content delivery networks will even advertise that you can 'own' a movie by purchasing an indefinite-term access token to be able to play the movie from their service. Of course these are both BS, there is no 'ownership' involved in either transaction, and the license being granted in the transaction is revocable at any time and terminable at the will of the content provider/producer with no notice requirement and no recourse available to the licensee.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 18:52 UTC (Thu) by kemitchell (subscriber, #124442) [Link] (2 responses)

Augusto is the right citation. Thanks for poking me to read it again.

You could cite the case as weakening the conceptual case for the rule from Vernor. But it's also empirical proof positive that the courts will disparate treatment for software. They can and do treat it as a special case. It kind of is a special case.

Particularly with regard to computer software, we have recognized that copyright owners may create licensing arrangements so that users acquire only a license to the particular copy of software and do not acquire title that permits further transfer or sale of that copy without the permission of the copyright owner.

The court mentions that there were more factors to the rule in Vernor than just one. But it doesn't actually run through them systematically.

Go looking, and you can find distinctions it does make that maybe wouldn't go the same way for open software, rather than commercially licensed software. The absence of a "prior arrangement" for delivery of the copy. No attempt to keep track of specific copies. No response indicating agreement, though I'd argue open licensing is still very much "consensual". But the court's just piling on. They have the special statute about what happens when you mail unsolicited merchandise to people.

As I'm told Moglen used to say: "Don't learn copyright law from free software people." It's important to remember that we don't see copyright like other users of the system. Our policy preferences are often the opposite of prevailing and established public policy.

Software might have been covered by its own, special IP statute. We saw that for a time in Japan, for example. But it was put under copyright instead. Some of the established expectations and rules for older media haven't translated over to software. The general trend is making room for industry to monetize rights in software, as it figures out how to do that. Especially in light of how quickly and often distribution and marketing have changed.

If you mail a game critic a boxed copy of your next title and it ends up on eBay, I wouldn't be surprised to see a decision applying Augusto for the same result. But I suspect that would have as much to do with honoring long-held expectations about physical products as with any refinement of the First Sale Doctrine.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 20:31 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

> As I'm told Moglen used to say: "Don't learn copyright law from free software people." It's important to remember that we don't see copyright like other users of the system. Our policy preferences are often the opposite of prevailing and established public policy.

May I suggest you take a look at groklaw.net? Sadly, it's a cobweb site now, but a lot of us cut our "lawyerly" teeth there, and the site owner was a paralegal who made us do our homework! (The Library of Congress picked it out explicitly for archiving.)

While I'm not aware of the Nazgul actually contributing to the site, I'm pretty certain they would have been monitoring it for the SCO vs IBM case ...

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 20:34 UTC (Thu) by kemitchell (subscriber, #124442) [Link]

I read groklaw back in the day. One of many influences that lured me off the straight and narrow path of programmer to the dark side...

Elastic promises "open"—delivers proprietary

Posted Jan 31, 2021 18:56 UTC (Sun) by jejb (subscriber, #6654) [Link] (23 responses)

> The trouble with the nondiscrimination criteria, read broadly, is that they'd preclude all copyleft. Copyleft discriminates against closed source development. RMS wrote GPL to discriminate against non-free software and non-free software makers. The whole point was to use copyright against non-free software, as non-free software was using it against free. Free software, and by extension open source, taught the difference between open and closed, and came out strongly for open. "Discriminating" against closed software isn't antithetical to open source, but the point. The choice open source offered to developers was whether to effect that distinction through licensing, by choosing copyleft rather than permissive terms. Both are "open source".

The nondiscrimination criteria of OSD 4,5 aren't broad, they're specific to people or groups and fields of endeavour. Carlo Piana gave an eloquent explanation why the GPL is nondiscriminatory, which you didn't refute, in the original thread you keep referring to:

http://lists.opensource.org/pipermail/license-review_list...

I'm rather reminded of monopolists trying to argue they shouldn't be separately regulated because of the equal protection clause.

> The other-software arguments try to go the other way. Instead of working down from a vague criterion to an oddly specific rejection, they start from a specific criterion, OSD 9, and try to argue that it should really be vague and general.

To me the OSD 9 argument is simple. OSD9 says "License Must Not Restrict Other Software" GPL gets around this by only trying to restrict derivative works, which are ipso facto the same software. SSPL tries to encumber every other work used to make the service:

"Service Source Code" means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service

It's a clear restriction on other software.

Elastic promises "open"—delivers proprietary

Posted Jan 31, 2021 20:26 UTC (Sun) by kemitchell (subscriber, #124442) [Link] (22 responses)

I didn't argue with Carlo about AGPL passing the nondiscrimination criteria because he was making my point. The very broad readings of OSD 5 and 6 pushed against new, stronger copyleft licenses can't be right, because they'd have excluded older copyleft licenses, like AGPL, GPL, and even LGPL/MPL/EPL. When we apply OSD criteria, we have to do consistently. We can't read OSD 5 and 6 against SSPL today in ways that would have excluded AGPL years ago.

As for OSD 9, the original heading in DFSG is "License Must Not Contaminate Other Software". That's even more general. But we get a better sense of what was actually meant in the text, below the heading. The only change in the text of criterion 9 from DFSG to OSD was replacing "free" with "open source". It's the same old Debian distribution protection.

Ignoring the text and focusing on the vague heading is just as I said: a way to smudge out a specific criterion into something vague. Vagueness can be weaponized against new terms.

We don't know the full extent of "derivative work" in software under US law. Don't trust anyone who pretends they do. But copyleft licenses haven't just limited themselves to derivative works, either. Have a look at the definition of "Corresponding Source" in GPLv3, AGPLv3, inherited also in SSPLv1.

I agree with many critics that paragraph 1 of section 13 of SSPL could be better written. And I've collaborated on a license that I think goes to the same goal, with a much more robust and approachable language. But I don't think the functional specification for SSPL is anything but a predictable evolution of open source network copyleft. It's basically LAGPLv4.

Elastic promises "open"—delivers proprietary

Posted Jan 31, 2021 23:38 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (3 responses)

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.

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.

Elastic promises "open"—delivers proprietary

Posted Jan 31, 2021 23:44 UTC (Sun) by jejb (subscriber, #6654) [Link] (15 responses)

> But copyleft licenses haven't just limited themselves to derivative works, either. Have a look at the definition of "Corresponding Source" in GPLv3, AGPLv3, inherited also in SSPLv1.

"Corresponding Source" in the GPL family of licences means the components and scripts necessary to turn the covered source code into a binary representation, excluding all those pieces that are commonly available. It also just requires a source release and doesn't prescribe the licence of that release. Such specific scripts might not be derived works of the original but, since they're so tightly coupled to the build, neither are they other software (and they're certainly not usually distributed with the work). Calling something "Corresponding Source" in a licence doesn't make it equivalent to GPL "Corresponding Source" particularly when it tries to scoop up everything necessary to deliver the service.

I think we could have a useful conversation about what could be corresponding source when delivering a network service, and people have speculated about building a maximal copyleft licence to move closer to the line of impinging on other software. However, it seems obvious to me that "everything required to deliver the service" is way over the line wherever it happens to be.

Elastic promises "open"—delivers proprietary

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

Can you point me to some reading about the argument that Corresponding Source need not be licensed under GPLv3? I don't believe I've ever seen an argument that GPL requires conveying code without also requiring it be licensed. The requirement to offer source under section 13 or AGPL, for example, is read to trigger the requirements of section 5.

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 1:53 UTC (Mon) by jejb (subscriber, #6654) [Link] (12 responses)

I deal mostly with GPLv2 not v3. For v2 there was a discussion about this over a decade ago when Intel tried to make the kernel compatible with the icc as well as gcc. icc at the time was an intel proprietary compiler. Releasing only the Makefiles for icc was deemed good enough and a source release of icc wasn't required.

The reasoning for v2 was that the licence only attaches to the Program and section 2 only requires the program and derivatives to be under the GPL. Section 3 which mentions complete and corresponding source says nothing about the licence it should be under and does contemplate that corresponding source may be more than the Program to which the rest of the licence refers. Thus the rule of thumb that as long as we have enough information to build the binary, that's good enough regardless of the licence of the additional information.

A cursory reading of GPLv3 shows that it also seems to maintain this separation between "the Program" and its derivatives and the corresponding source which includes the build scripts.

Elastic promises "open"—delivers proprietary

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

<p>GPLv2 doesn't say "Corresponding Source", but it defines "complete source code" to include build and install scripts.</p>

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 2:20 UTC (Mon) by jejb (subscriber, #6654) [Link] (10 responses)

Well it doesn't have a definitions section like v3, certainly.

However section 2 refers to both "complete source code" and "complete corresponding machine-readable source code"

But regardless of the terminology confusions in v2 it still doesn't contemplate the scripts being released under the same licence as the program, merely the source code for them being made available.

Elastic promises "open"—delivers proprietary

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

It's not clear, to my eye:

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; ... [emphasis mine]

2. ...
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

Have you seen a specific position on this from FSF or others?

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 8:21 UTC (Mon) by Wol (subscriber, #4433) [Link] (4 responses)

Ahhhh - looking at 2(b) the source of your confusion is obvious.

It does NOT say "the Corresponding Source must be released under this licence".

It says "the Corresponding Source AS A WHOLE WORK .... EXCLUDING any sections that are identifiable and not derived works" (ie pretty much any source file you have not edited!) And if you edit a source file it becomes a derived work, and you must release your modifications to it "under this licence".

You are making the same mistake I have a habit of making - you are not READING THE FULL TEXT. It's called "taking things out of context" and it leads to exactly this sort of mistake.

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 18:01 UTC (Mon) by kemitchell (subscriber, #124442) [Link] (3 responses)

"Derivative works" aren't necessarily limited to files you edit.

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 18:51 UTC (Mon) by Wol (subscriber, #4433) [Link] (2 responses)

At which point, I just HAVE to call "troll". Either that, or you're a real copyright lawyer who doesn't have a clue about copyright - which wouldn't surprise me at all :-)

You misquote legalese. You have too many glib answers. And you've made no attempt whatsoever to address direct questions as to how you'd achieve what you say others must do!

Sorry - that's ABSOLUTELY TYPICAL troll.

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Feb 3, 2021 21:46 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

Err... derivative works are definitely not limited to files you edit. If you have a program A and you edit a dozen files and then release it again, the *whole work* is a derivative of the original, even though most of the files were not edited. (Similarly, if you edit a book and change half the chapters and then republish it, the new book is a derivative of the old even though half the chapters are unchanged.)

Elastic promises "open"—delivers proprietary

Posted Feb 3, 2021 23:17 UTC (Wed) by Wol (subscriber, #4433) [Link]

In the "Corresponding Source"?

Certainly if you edit source file A and re-release it, the resulting *binary* is a derived work, but source files B, C and D are not.

kemitchell is classic troll, relying on people like you missing that fact ... *detail* *matters*.

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 16:12 UTC (Mon) by jejb (subscriber, #6654) [Link] (3 responses)

> Have you seen a specific position on this from FSF or others?

I gave the example I know about. It has now been accepted practice for over a decade that the Linux Kernel can be built by proprietary toolchains and the FSF hasn't objected. I would imagine by now there's a strong estoppel argument against anyone trying to say that GPLv2 requires releasing the build scripts and tools under GPLv2.

Even if you overcome the estoppel problem, under section 2, you'd really have to get a court to agree that build tools and build scripts are derived from the program, because if they're not, they are "identifiable sections" that don't have to be under the licence. Given the uncertainty over linking, that sounds like a huge stretch to me.

Elastic promises "open"—delivers proprietary

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

I asked about another source for this argument, because I suspect it was either FSF gloss or kernel lore. Both of those institutions have developed a "folk law" of GPLv2 interpretation that doesn't necessarily follow from its text.

I don't think estoppel would apply so cleanly as you think. Especially if there's no written statement out there telling people they can share some parts of complete source code / Corresponding Source without licensing under GPL.

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 18:52 UTC (Mon) by jejb (subscriber, #6654) [Link] (1 responses)

> I asked about another source for this argument, because I suspect it was either FSF gloss or kernel lore. Both of those institutions have developed a "folk law" of GPLv2 interpretation that doesn't necessarily follow from its text.

I already told you I was present for the discussion: this isn't some received wisdom, it's something I remember happening. Likely we may have email archives from the time as well (although I'm not certain about how long ago it was, so finding them is going to be a pain) and I can bet intel is going to have preserved the records to make absolutely sure we have no claim requiring their open sourcing of icc.

This isn't just the kernel being different, it has been the FSF practice since the early days as well: the gnu tools were created and released under GPLv2 long before we had a usable gcc. The only way to build them in those days was with the proprietary tools on whatever unix platform you had. Most of those projects still have autoconf fragments that check for the proprietary compilers if you need written evidence.

> I don't think estoppel would apply so cleanly as you think. Especially if there's no written statement out there telling people they can share some parts of complete source code / Corresponding Source without licensing under GPL.

My understanding based on having a lawyer take me through the various estoppel doctrines for another matter is that if it becomes standard practice it may be relied on without a written promise. icc isn't the only proprietary toolchain that has been used to compile Linux: the practice is rife throughout the embedded space as well.

Plus, as I said before, the clear exclusion of identifiable sections of the corresponding source that aren't derived works of the program in section 2 means that to require the scripts and the compiler to be under GPLv2 you'll have a way to prove in court that they're derived works of the Program the licence was protecting.

Elastic promises "open"—delivers proprietary

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

I don't doubt this has come up before, or that folks involved at the time came to an understanding. But I don't think that understanding, whatever it was, flows inexorably from the plain text of GPLv2.

Nothing strange about that idea. Both FSF and the kernel have developed, and often shared, lots of understandings and expectations about how the license applies to their work. Some of that ends up documented, like the kernel user-space exception or the FSF GPL FAQs. Some of it's scattered around in mailing list archives and between devs' ears.

I'm interested in the written record of the conversation around this because that would give me a sense of the arguments deployed, as well as who, and which projects, might be held to that interpretation. If it's an FSF thing, it may not apply to the kernel, and vice versa. Or it may be the accepted norm for both FSF projects and the kernel, but not necessarily for other GPLv2-licensed projects.

It's a tangent, but on your note about build tools: Especially GPLv3 spilled a bit of ink to catch scripts, but not tools they invoke, like compilers. Which, as you point out, weren't free early on in free software history. Ref:

However, it [Corresponding Source] 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.

One of the complaints against SSPLv1 is that it threatens to reach the kernel and other system-level utilities, because it doesn't have this kind of limitation in section 13. Mongo sent a proposed revision of SSPL to the OSI mailing list that partially addressed those concerns. I suspect they initially left it out because they'd seen it was possible to argue that the definition of "Corresponding Source" in AGPLv3 "insulates" containerized services from the reach of copyleft. It's analogous to the (somewhat dubious) idea that you can "wrap" GPL code, and then invoke the wrapper in a way that avoids triggering copyleft.

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 8:14 UTC (Mon) by Wol (subscriber, #4433) [Link]

> Can you point me to some reading about the argument that Corresponding Source need not be licensed under GPLv3?

USE YOUR LAWYERLY BRAIN!!!

Pretty much ANY large GPL project will not have all its Corresponding Source licenced under the GPL. The linux kernel for one. LibreOffice for another.

What happens if you take SOMEONE ELSE'S eg MIT-licenced code and include it in your GPL project? YOU CANNOT RELICENCE THEIR CODE.

The project as a whole can only be safely distributed under the GPL - that is the intent and magic of the GPL. But each piece of the Corresponding Source is licenced according to the ORIGINAL AUTHOR, and needn't be GPL at all.

Ask yourself this simple question - "If I include someone else's NON-GPL code in my project, how do I re-licence it for release under the GPL?" The answer is YOU CAN'T.

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Jan 31, 2021 23:49 UTC (Sun) by jejb (subscriber, #6654) [Link] (1 responses)

> And I've collaborated on a license that I think goes to the same goal, with a much more robust and approachable language.

The Round Robin Licence to me actually seems very similar in intent and action to the Reciprocal Public Licence, which is OSI approved.

Elastic promises "open"—delivers proprietary

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

As much as it warms my heart to read the letters "RPL" from someone else, I must warn you, from experience, that you will make a lot more people angry than happy by mentioning it!

Fun Fact! The Technical Pursuit guys, who came up with RPL for a JavaScript web framework before anybody thought that was a thing, are still at it. I've run into a few other companies, too: ActiveAgenda, Open Justice Broker Consortium, Particular Software, Pixelglow.