|
|
Log in / Subscribe / Register

Elastic promises "open"—delivers proprietary

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 18:56 UTC (Wed) by kemitchell (subscriber, #124442)
Parent article: Elastic promises "open"—delivers proprietary

You've faithfully reproduced exactly one side here.

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.

Then have a look at the actual review thread, and tell me what the license review process is. What are the criteria? If you're expecting an expert panel of dispassionate lawyer-reviewers making technical arguments about legality and compliance, you'll be very disappointed. It's overwhelmingly political. A lot of people shoving straw into Mongo's mouth, about its own goals and intentions, and then "winning" arguments against the straw man they've created.

As for the SSPL, I see no reason it shouldn't count as open source. Unless "open source" really just means permissive now, with the GPLs and weak copyleft licenses held over because nobody wants to pay the political price of saying otherwise.

There's nothing new about copyleft reaching more than the originally licensed code. That's exactly what happens when you build a GPL-licensed library into a larger program. When copyleft applies just to "derivative works" of the licensed code under copyright law, that's not a clear boundary, either. Under US law, I'd expect it to sweep broadly. A copyleft license written to cover "derivative works" can be just as broad or broader than one that helpfully tries to spell out what is covered in technical rather than legal terms. OSI has approved lots of those.

There's nothing new about copyleft reaching network services, either. AGPL does it most famously, and most infamously, due to the very hackish way it was written. Mongo listed its reasons for dropping AGPL---potential loopholes defeating copyleft when composing applications out of network services, especially containerized network services---in its messages to OSI. Some of those might have been avoided by a different approach, like that of the Open Software License, also OSI-approved.

Finally, there's nothing new about a license that's permissive for some use cases and copyleft for others. We have LGPL. There's been talk---and until SSPL, only talk---about an "LAGPL", as well. That's essentially how Mongo used AGPL: their page on AGPL long made clear that they wouldn't enforce copyleft for mere applications. Their new FAQ for SSPL says the same. You don't have to do a deal with Mongo or Elastic to use their SSPL releases for your web apps. You can use it to offer the DB as a cloud service, but if you do, you have to release your service under like terms.

Maybe it's fun for a bunch of folks who work at charities to browbeat Mongo and Elastic about their business acumen. Fact is, they're siding with Amazon, a proprietary cloud platform, against firms that have actually made their core products open source. Whose business model's really asking for OSI help here? Why is OSI blocking (and badmouthing) licenses that use copyleft to push open further up the stack of cloud services? They've turned out in force against licenses addressing "the Amazon problem". They went the other way when AGPL and OSL addressed "the Google problem". They cheered when earlier firms, like Mongo, Trolltech, Sleepycat, and company-driven foundations like Eclipse used copyleft to defend themselves against proprietary competitors.

As for the fork, of course Elastic saw it coming. Announcing a fork the same week is easy. Maintaining that fork over time, to compete with the company where all the lead developers work, is the hard part. Game on.

It's not hard to see the other side of this if you read the other side of this. I'd encourage everyone to read what Mongo and Elastic have said, rather than what their opponents say they "really" mean.

to post comments

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 19:14 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (25 responses)

This is disingenuous. AGPL does *not* reach through network connections in the same way that GPL reaches through linking. If I stick a reverse proxy in front of an AGPL'd origin server, the reverse proxy is not required to be AGPL. I (probably) still need to offer the origin server's source code to my end users, of course, but that's where the obligation ends.

The OSL 3.0, which you claim to be different, is not:

> 5) External Deployment. The term "External Deployment" means the use, distribution, or communication of the Original Work or Derivative Works in any way such that the Original Work or Derivative Works may be used by anyone other than You, whether those works are distributed or communicated to those persons or made available as an application intended for use over a network. As an express condition for the grants of license hereunder, You must treat any External Deployment by You of the Original Work or a Derivative Work as a distribution under section 1(c).

There is simply nothing in this language which can be read to extend from the origin server to the reverse proxy. On the other hand, the SSPL not only (probably) extends to the reverse proxy, but expressly includes "without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software." That is an extraordinarily expansive set of demands going up and down the entire software stack. No other purportedly open source license is anything like that. In practice, these requirements are basically impossible to meet unless I own the copyrights to all of those pieces of software, since the vast majority of those products are not available under the SSPL (e.g. I'm not aware of any SSPL-licensed backup software, so either I have to roll my own, or go without backups!).

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 19:59 UTC (Wed) by kemitchell (subscriber, #124442) [Link] (12 responses)

This is disingenuous. AGPL does *not* reach through network connections in the same way that GPL reaches through linking.

How "disingenuous"? Mongo made just this point when proposing SSPL, as primary motivation for new terms.

The GPLs, and by extension AGPLv3, embody implementation choices and underlying assumptions that in retrospect arguably limit their copyleft to some means of software combination, and not others. A lot of us are building applications these days by composing services "linked" by HTTP API calls, often with each service in its own OS container. AGPL acknowledges services as a means of software delivery, but not as a means of software composition. It doesn't reflect any awareness that was possible.

Have a closer look at OSL. It shared the "solve the Google problem" goal of AGPL, but took a clean-slate approach to design and drafting of legal terms. As a start, OSL copyleft triggers when you offer a network service, whether you "modify" or not. It doesn't bend over backward to avoid saying "if you use this software to provide a network service, then..." as AGPL did, for various doctrinal reasons peculiar to FSF. OSL also defines the reach of copyleft more directly in terms of copyright "derivative works", without extra GPL-style verbiage like the definition of "Corresponding Source". Which is to my point about the breadth you see, in licenses like SSPL, versus the breadth that's hidden behind legal terms, like "derivative work". Upshot: There's nothing essential about the quirkly limitations AGPL self-imposed, intentionally or unintentionally.

Every new strong copyleft license has addressed new means of software combination or software delivery. Every new strong copyleft license has faced "slippery slope" arguments about the scope of what must be shared back. That's what it takes to remain "strong", to apply in the circumstances that matter for the industry and end users.

Sometimes projects have gone out of their way to publish a free exception to allow closed use in cases where the license would arguably require release. For examples: the kernel user-space exception, Mongo's AGPL application exception. Those exceptions implicitly acknowledge the broad reach of copyleft as written, and, once upon a time, OSI and FSF approved.

I'm personally not terribly impressed with how section 13 of SSPL turned out, either. It could be much improved. Mongo acknowledged this, floating a revision of SSPL adding more clarity and flexibility around existing open source in the stack under different licenses, akin to the "System Libraries" exception to "Corresponding Source" under *GPLv3. But by the time they did, "review" had devolved to "pillory" so far that they essentially left that olive branch on the table as they made for the door. The process, such as it was, didn't help. It was too caught up in denouncing the license, or rather, denouncing Mongo as a company, to improve it.

The question about a new copyleft license isn't just whether it does something more or something different than older copyleft licenses. If it doesn't, the concern is proliferation—lack of novelty—and you might as well pick the already-approved license.

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 22:11 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (11 responses)

> Every new strong copyleft license has addressed new means of software combination or software delivery. Every new strong copyleft license has faced "slippery slope" arguments about the scope of what must be shared back. That's what it takes to remain "strong", to apply in the circumstances that matter for the industry and end users.

Are there any copyleft licenses that are broadly accepted as free software that go beyond "derived work" when addressing software combination? Section 13 of the SSPL isn't a logical extension of the GPL's requirements in this respect, it's a far greater reach (to the point where it's probably impossible to satisfy under any real world conditions)

Elastic promises "open"—delivers proprietary

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

*GPLv3 are by far the best known licenses that explicitly reach beyond "derivative work". SSPL and other license that reach beyond that have to argue to do so.

I believe those arguments will prove very strong, on the merits. Free software wasn't about accepting copyright concepts as moral truths. Quite the opposite. Copyleft was designed to give the proprietary industry some of their own medicine, and proprietary licenses don't hobble themselves the way some open source license drafters have. Nor were open source or free software principles wedded to specific models of software development or delivery. They were more general than that, even universal. If you used a system, you needed all the source and rights to hack it. No matter what language or means of combination was used to develop it.

The early FSF licenses strained to speak in specific copyright terms because less of copyright law was clear back then, including whether such a license could be enforced as a general matter. That was a long time ago. There's no longer any reason to "implement" the copyleft in self-limiting terms that only clearly apply to copying and pasting or linking compiled software.

Please don't let any of this lull you into thinking lawyers know just what "derivative work" means in software. There's a statutory definition in 17 U.S.C. 101:

A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a “derivative work”.

But beyond that, it's case law—court decisions. Which there isn't a ton of in software. If we get more soon, in the form of an Oracle v. Google decision that endorsed copyright protection for APIs, "derivative work" is going to expand, to clearly include derivatives of works that are APIs. It's a very dynamic situation.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 0:38 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (9 responses)

> *GPLv3 are by far the best known licenses that explicitly reach beyond "derivative work"

In terms of the Installation Information requirement? I accept that there's an obligation placed on you that stretches to things other than the covered work itself, but there's no requirement that those also be provided under the terms of the GPL - it's intended to ensure that a user has the practical freedom to modify the work. If we extend that to the SSPL situation, it feels like we'd end up with a section 13 that required that it be possible for the user to be able to stand up a modified version of the covered work on the same infrastructure running the service - so, we could imagine (say) Amazon running an Elasticsearch instance inside a container and communicating with other Amazon components, and the license requiring Amazon to permit users to swap out that container with a modified one and run a competing service.

What the SSPL actually requires, though, is more akin to a GPL variant that requires *all* code in a User Product be provided under the terms of that license if a single component is under that license. This isn't just a difference of degree, it's a difference of kind - the requirement is no longer about enabling the user to have practical exercise of their freedoms, it's about ensuring that the user has the same freedoms for every component in the system.

And ensuring that users have additional freedoms is good! But that doesn't seem to be the goal of the SSPL - it's described in terms of requiring that beneficiaries of the freedoms granted be required to contribute back to the wider community, not in terms of ensuring that users of a service have a practical mechanism to benefit from the four freedoms.

So what is section 13 supposed to achieve? The final sentence implies that the intent is to require that the service vendor provide everything required to run a local instance. In Amazon's case that's presumably not just the code running on the machine providing the service, it's also every other component the service relies on - so Amazon would have to hand over the code to Route 53, S3, and a whole lot of other components. And in order to actually bring up the local instance of the service, I need to bootstrap all of that infrastructure locally. This is, to put it mildly, impractical. Regardless of any nominal freedoms embodied by the license, I have no way to make a modification to the original work and deploy it in an equivalent way. Instead I need to rebuild Amazon's infrastructure first. And that's ignoring the fact that Amazon can't do this anyway, given that (for instance) they'd somehow need to relicense Linux under the SSPL first.

So, as written, section 13 doesn't feel like something that's intended to grant practical user freedoms. Instead it feels like it's deliberately written to be impossible to meet, thus coercing anyone using the covered code to provide a service to pay for a proprietary license instead. And in that respect it definitely meets the stated goal - users of the code have to pay for the privilege. But this doesn't result in users gaining more freedoms. Instead, I'm now forbidden by the license from running a small public Elasticsearch service on top of Linux.

I think the problems the SSPL aims to solve are real and we do need to provide solutions to them. But I don't think the SSPL is a sincere attempt to grant freedoms to users, and as a result I don't think it counts as open source.

Elastic promises "open"—delivers proprietary

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

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.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 1:59 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (3 responses)

> I'm not sure whether we agree that the intended functionality of SSPL would make an open license.

I think that depends on what the intended functionality of SSPL actually is.

Elastic promises "open"—delivers proprietary

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

Completely fair.

The tragedy here is the communication breakdown. The sides have squared off and don't talk in earnest. When they happen to catch a word, they assume hostility or duplicity. Increasingly, they're right.

I for one lay that first at OSI's feet. They tolerated, even welcomed, ad hominem attacks on the company, rather than holding discussion to the license. Whatever reason someone had to oppose either company or license---not good for their business, not drafted through their process, not motivated by their politics---they were free to wreck the assumption of good faith, backchannel as well as publicly.

It's not actually fair to say the license review process failed. It was never allowed to start earnest. Filibustered or shouted down, not really debated. But some can chalk it up as a "win", because their interest lies in the outcome, and not the process.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 2:59 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (1 responses)

It's not hard to see why people would conclude that section 13 in its original form was effectively impossible to comply with, and that's effectively a pretty obvious violation of the fields of endeavour criterion. The modified version is much better in that respect, but as you say I think people had already made up their minds at that point. But I think it's still fair to question the motivation - quoting from the original rationale:

"Many open source developers are struggling with a similar reality, and some of our competitors have moved to proprietary licensing models. The alternative, to be blunt, is for us to be that last standing unpaid open source database developer for cloud providers, who sell access to our software for significant fees, but may not adequately contribute back to our community."

Even in version 2, section 13 would appear to require Amazon to hand over a significant amount of code that wouldn't have benefited the MongoDB community - the greatest beneficiaries would be other large cloud providers. Again, the easy way to go from the rationale to the license terms is to assume that most vendors will find the terms overly onerous and will pay for an alternative license.

So, what /is/ the intended functionality of the SSPL? Is it intended to increase the amount of free software in the world, or is it intended to support the business model of the authors?

Elastic promises "open"—delivers proprietary

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

I don't doubt the honesty of your reading at all. I do worry about standards. We may be more familiar with seeing "Corresponding Source" in GPLv3 or "derivative work" in a bunch of licenses. But when someone comes to me for legal advice about what, exactly, they have to release, I've rarely got a 100% answer. Usually we can find some approach that works, mixing good faith, a willingness to communicate, and a little conservatism (in favor of release). But line drawing can be hard even under licenses that took pains to make it easier, like MPLv2. Implementation-wise, our best tools look a lot more like SSPL, which used industry terms for what has to be shared, rather than more copyright law esoterica.

I also see—not speaking of your comments here—a willingness to hide behind the "impracticality" of compliance. In my mind, the fact there isn't a world-famous, pure-open-source cloud provider yet isn't SSPL's problem. It's a movement problem, and something we ought to be agitating for. Neither is it relevant that a particular cloud vendor won't share such-and-such code. That's taking the proprietary part of their business model as granted, instead of a call for advocacy. To my mind, the whole concern is whether a developer or company fully willing to share their work as required can feel confident in compliance. The readings that involve SSPL'ing all the firmware blobs for your rack server strike me as motivated stretches to failure.

I was glad to see that quote from Mongo's submission statement again. It's important. SSPL wasn't Commons Clause. It was an attempt to get some of the effect of Commons Clause by using the if-then of copyleft, and conceding the maybe-someone-will of copyleft, rather than the hard "no" so common in proprietary licensing.

I'm guessing that sounds like a big admission. I do suspect the primary motivation for SSPL was just what they said: defense against Amazon. But if the people involved didn't gain meaning in work from broader movement principles, I don't think they would have tried to address their goal under open source limitations. It's so much easier to draft and administer a flat restriction, as in Commons Clause. And Mongo had a ton more leverage than the startups who announced Commons Clause to do it.

In short, I don't think the motivation question is either-or. It should be both-and. The hope for free software in business was that advancing "freedom" could also be good for business. And in fact we've repeatedly seen commercial firms carrying the torch of the latest, strongest copyleft license. MySQL and Sleepycat in the early days. MongoDB for AGPL, which was actually written for Affero, another company. There have been some activists licenses that really only activists used, and some upstart company licenses that really only the companies themselves used. But the heydays, as I see them, were all periods when activists and upstart companies backed each other up. The coalition on the permissive side—anti-IP activists and companies who like free stuff—hasn't wavered. Plenty of permissive licenses have been drafted by corporate lawyers with no thought to end-user service or software-freedom ideology.

A small nit on dual licensing: Mongo continues to tell folks that SSPL doesn't require sharing applications that use Mongo for a database. Just offerings that provide Mongo as a service. They did the same for AGPL before that. It's analogous to the user-space exception to GPLv2 from the kernel. I don't know the terms of deals they've done with cloud providers. But looking at their application-developer offerings, it's all hosting and open core. I don't think they'd call themselves a dual licensing company.

I've really appreciated your messages. Thanks.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 16:25 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

> The thing you must provide and license under *GPLv3 is "Corresponding Source". Here's the relevant part of the definition:

Picking on you because you admit to being a lawyer :-)

See my other post, but you wrote "provide AND LICENSE". Delete the words "and license" because YOU DO NOT HAVE THE RIGHT TO DO SO!!!

ABSOLUTELY NO Open or Free licence I am aware of gives you the right to re-licence somebody else's code.

Cheers,
Wol

Elastic promises "open"—delivers proprietary

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

<p>GPLv3, section 5, subsection c:</p>
<blockquote><p>You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.</p></blockquote>

Elastic promises "open"—delivers proprietary

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

"Entire Work" and "Corresponding Source" are two different things.

If part of the "Entire Work" is derivative of GPL, then, as a *single derivative item*, it can be licenced under the GPL.

But if the "Corresponding Source" contains large chunks of my MIT-licenced work, you can NOT licence the corresponding source as GPL because I didn't give you permission to relicence my work. What you CAN do is distribute the entire corresponding source AS IF it was GPL.

Note that the terms "Entire Work" and "Corresponding Source" imply that the two are completely separate items (linked by the fact that if you pass the "corresponding source" through a compiler/linker, you get the "entire work" as said separate item).

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 16:21 UTC (Thu) by Wol (subscriber, #4433) [Link]

> What the SSPL actually requires, though, is more akin to a GPL variant that requires *all* code in a User Product be provided under the terms of that license if a single component is under that license. This isn't just a difference of degree, it's a difference of kind - the requirement is no longer about enabling the user to have practical exercise of their freedoms, it's about ensuring that the user has the same freedoms for every component in the system.

Snag is, any licence that requires that IS NOT OPEN SOURCE. In fact, it's probably not legal. This is what bugs me about many many many discussions of copyright.

What it should have said is "is more akin to a GPL variant that requires *all* code in a User Product be provided AS IF under the terms of that license if a single component is under that license." - because that is actually the magic of the GPL.

Let's say I write some nifty code and release it as MIT. You then include it in your niftier GPL version. The GPL *does not* require you to relicence my code to GPL because you CAN NOT. What the GPL requires is a guarantee that - by complying with the terms of the GPL - you are also complying with the terms of the MIT licence that I applied to my oode. So when the GPL is applied to collaborative code it is NOT a guarantee that all the code is GPL, but it is a guarantee that if you comply with GPL then you are also complying with all the other myriad licences that may apply.

(So actually, if you really meant what you wrote, that's another nail in the coffin of the SSPL, because it's trying to enforce the impossible ...)

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 20:05 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (11 responses)

> This is disingenuous. AGPL does *not* reach through network connections in the same way that GPL reaches through linking.
AGPL is pretty vague on that (it actually says nothing about what exactly is a derived work). Even basic questions are not answered. E.g. if you provide a web mail service and want to use an AGPL-ed PDF renderer in an iframe, then will AGPL propagate to all of the software?

SSPL on the other hand does limit it to:
> offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 20:33 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (10 responses)

> (it actually says nothing about what exactly is a derived work)

It *can't* say what is a derived work. Derived work (or more commonly "derivative work") is a term of art in copyright law. Judges decide what it is; licenses don't.

The FSF has taken the position that dynamic linking creates a derivative work; they may even be right about that. But legally, it would be up to a judge to decide on a case-by-case basis, or up to a national legislature to codify explicitly. If dynamic linking does not create a derivative work, then there's no substantive difference between the GPL and the LGPL, never mind the AGPL.

> if you provide a web mail service and want to use an AGPL-ed PDF renderer in an iframe, then will AGPL propagate to all of the software?

There is nothing in AGPL which suggests that the answer should be "yes." You would not need to modify the renderer in order to do this, and the extra AGPL obligations (in section 13) attach at time of modification. If the software is unmodified, the AGPL is materially identical to the GPL.

Even if the software *is* modified, however, the normal GPL limitations in section 0 still apply, particularly this:

> To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.
>
> To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

In other words, the AGPL does not have a different "test" for what counts as "modification" than the GPL; they both use exactly the same set of legal definitions, right down to limiting "conveying" to *not* include "mere interaction [...] through a computer network." The AGPL is almost entirely identical to the GPL, in fact. Section 13 is pretty much the only difference, so if your hypothetical does not implicate section 13, then you can analyze most of the legal consequences in the same way you would analyze the GPL. If section 13 is implicated, it still has to be analyzed in the context of the rest of the GPL, because that's what the AGPL is - the GPL with an extra section.

In short, the AGPL probably doesn't cover your hypothetical.

> SSPL on the other hand does limit it

"It" in this context does not refer to "derivative work." It refers to "making the functionality of the Program or modified version available to third parties as a service," which is a contractual term, not a copyright term. You can define and limit contractual terms in whatever way you like.

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 22:42 UTC (Wed) by himi (subscriber, #340) [Link] (8 responses)

I'm actually curious about exactly how the SSPL can be in any way enforceable given the constraints imposed by copyright law (particularly the fact that it only "infects" through copying or derivation, and simply communicating with a service seems like a pretty solid boundary). Wouldn't any unenforceable clauses in the license simply be made null, and only the enforceable clauses would remain? Leaving the whole thing potentially even more open than a plain GPL license would . . .

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 23:52 UTC (Wed) by Wol (subscriber, #4433) [Link] (7 responses)

> I'm actually curious about exactly how the SSPL can be in any way enforceable given the constraints imposed by copyright law (particularly the fact that it only "infects" through copying or derivation, and simply communicating with a service seems like a pretty solid boundary)

You are missing a very crucial point, which is that in order to run software YOU HAVE TO COPY IT. At which point, COPYRIGHT BITES.

The GPL quite explicitly grants unrestricted rights to copy and use. Because they are needed!

So if you want to put SSPL software onto your server to provide a service, you need to copy it. And if the SSPL does not give you unconditional rights to copy and run, then you have to agree to the licence.

Cheers,
Wol

Elastic promises "open"—delivers proprietary

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

> You are missing a very crucial point, which is that in order to run software YOU HAVE TO COPY IT. At which point, COPYRIGHT BITES.

In the US at least, this has explicitly not been a copyright violation for about 40 years.

If you legally acquired a copy of the software (ie the person who gave it to you did so legally) then you are free to *use* it to your heart's content, at least as far as copyright is concerned. Copyright can only restrict the creation of further copies or derivative works.

(This is why the AGPL's terms only kick in if the software is modified)

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 0:08 UTC (Thu) by himi (subscriber, #340) [Link] (2 responses)

I thought this was still an issue at least up to the DMCA and some way beyond it - I recall it being a significant matter for discussion during the various flame wars that happened when the idea of "open source" as a distinct concept was being developed, as well as later on during the discussions around tivoisation which happened after the DMCA came into effect. Do you know what the case law or legislation was that explicitly carved out that exception?

Elastic promises "open"—delivers proprietary

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

> Do you know what the case law or legislation was that explicitly carved out that exception?

https://itlaw.wikia.org/wiki/Computer_Software_Copyright_...

(I'm sure there's plenty of nuance involved in the case law that followed, and the DMCA's anti-cirvumvention stuff threw a big monkey wrench into everything, but the original intent does seem clear...)

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 23:27 UTC (Thu) by himi (subscriber, #340) [Link]

Okay, reading through other parts of this discussion I've realised what my niggling issue/misunderstanding is here: if the /use/ of the code doesn't provide an avenue for copyright law to bite, how does a person running a service using this SSPL licensed code, assuming they acquired it entirely legally (i.e. they received all the necessary source and so forth), become in any way bound by the terms of the license? They're providing a service, not distributing the code, so how can they end up bound by the terms of a copyright license?

Unless there's some other kind of contract involved, in which case how would that kind of contract obligation be created?

I'm sorry to be asking what are probably dumb questions here, but this really is something that's hard to understand just by trying to read up on it in your spare time . . .

Elastic promises "open"—delivers proprietary

Posted Jan 31, 2021 19:14 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

> In the US at least, this has explicitly not been a copyright violation for about 40 years.

Then how does trial-ware (aka "if you like it pay for it") work? You can freely copy and share it, but in order to actually use it "for real" you're expected to pay for it. The licence is quite clear ...

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Jan 31, 2021 20:48 UTC (Sun) by pizza (subscriber, #46) [Link]

That has always "worked" via the honor system.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 0:02 UTC (Thu) by himi (subscriber, #340) [Link]

Okay, yeah, you're right. This isn't any kind of "infection" of other code by SSPL covered code, it's an outright "you can only use this code if..." which means there are no constraints beyond whatever limitations are imposed on contracts or similar.

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 1:31 UTC (Mon) by ras (subscriber, #33059) [Link]

> Derived work (or more commonly "derivative work") is a term of art in copyright law. Judges decide what it is; licenses don't.

I presume that's the correct legal stance. But in my experience, when legal theories clash with reality, it's the legal theories that bend.

The reality in this case is some very prominent open source projects define what they consider a derivative work to be, and it would be a very game lawyer who took that on. For example, the prime distinction between the GPL / LGPL / AGPL is their definition of what a derivative work is. The kernel has also drawn their own line in the sand on the subject.

Maybe your answer is "they can weaken the definition of derivative work (ie, define less things to be derived), but not strengthen it beyond what it means in law". If so "Judges decide what it is; licenses don't" isn't the clearest way of saying that. Licenses have been defining it for years now, and from what I can tell doing so very successfully.

The interesting thing for me is how they draw this line. They don't use legal terms. They use terms that to us are clear and well defined, "linking", "header files", "kernel API" and so on, thus providing certainty about what is covered and what isn't. It proves you don't need difficult to reason about / need to be decided by a Judge definitions to achieve useful outcomes.

This clause looks to me to fall squarely in the "difficult to reason about / need to be decided by a Judge" definition:

> offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version

Lawyers can have a field day defining what "derives value from" means. Does a backup program derive value from the data it is backing up? Does the kernel derive it's value from the applications it runs?

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 19:21 UTC (Wed) by pizza (subscriber, #46) [Link] (38 responses)

> 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."

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.

LWN has journalistic integrity

Posted Jan 28, 2021 0:35 UTC (Thu) by bkuhn (subscriber, #58642) [Link] (3 responses)

> You've faithfully reproduced exactly one side here.

Attacking the journalist integrity of the LWN folks in that manner is just “going low” unfairly. I know that it's become increasingly popular to do that in politics in the last four years or so (but I was hoping that era might be over now 😩). I, for one, appreciate that LWN covers stories from multiple angles and clearly marks opinion pieces as a opinion and news as news, and that the news pieces cover all relevant sides of the story. (In this case, Jake literally said that there was “nothing wrong” with Elastic's actions, a statement that I obviously disagree with, but which is appropriate to say in a fair journalistic piece about this recent news.)

Furthermore, LWN also provide this forum for anyone who wants to share their opinion and have the comments posted unmoderated on their own site (as you have literally done) — which allows anyone to easily rebut anything they like, and as quickly as they like. Thus, to attack LWN in that very forum is just dirty politics.

I felt compelled to point this out because it's likely awkward for Jake and the other LWN folks to politically defend their obvious journalistic integrity themselves when attacked like that.

LWN has journalistic integrity

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

I didn't question anyone's integrity. I subscribe here. The side that Jake portrayed, he portrayed accurately.

Even OSI threw in a paragraph along the lines of, "Well, it's their software. Sometimes licenses change." That's obviously not a point from Mongo, Elastic, or any of those supporting the new terms or their choice to use them. It's not even about whether SSPL is open.

LWN has journalistic integrity

Posted Jan 28, 2021 16:35 UTC (Thu) by bkuhn (subscriber, #58642) [Link]

To rework a famous old quote you lawyers often like: “When the law is on your side, pound on the law. When the facts are on your side, pound on the facts. When neither is on your side, pound on the table” … or maybe just accuse the media coverage of being one-sided.

LWN has journalistic integrity

Posted Jan 29, 2021 2:14 UTC (Fri) by devkev (subscriber, #74096) [Link]

> Attacking the journalist integrity of the LWN folks in that manner is just “going low” unfairly. I know that it's become increasingly popular to do that in politics in the last four years or so (but I was hoping that era might be over now 😩).

There's a difference between "This article tells only one side of the story" and "LWN is biased/one-sided". Also, drawing parallels between kemitchell's post and Trumpian cries of "Fake News!" is hardly accurate.

> I, for one, appreciate that LWN ... clearly marks opinion pieces as a opinion and news as news ...

I can't see where this article (or any article on LWN) is marked as news or opinion. Am I missing something?

You seem to be suggesting that this piece should be considered news, but the last paragraph in particular belies it being quite opinionated.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 4:51 UTC (Thu) by flussence (guest, #85566) [Link]

The only “other side of this” that matters is that Elastic's CEO cashed out one hundred million dollars of shares immediately before the bait and switch announcement. Here's the literal receipt: https://www.sec.gov/Archives/edgar/data/1707753/000120919...

Long-time readers may remember Intel's CEO did the same in more spectacular fashion before Spectre/Meltdown dropped, and the company has been in an accelerating downward spiral since.

This isn't some indie developer getting bullied by Amazon. It's a billion-dollar company making bank off openwashing and CLAs to enrich one greedhead at the top, just like the rest of them. Don't lie to the internet. They will find out, and they will make you pay.

Elastic promises "open"—delivers proprietary

Posted Jan 30, 2021 2:58 UTC (Sat) by timrichardson (subscriber, #72836) [Link] (2 responses)

"Maintaining that fork over time, to compete with the company where all the lead developers work, is the hard part."

I think an alternative lesson is that a maintaining a commitment to open source when all the lead developers work at one company is the hard part (for that company's shareholders).

Elastic promises "open"—delivers proprietary

Posted Jan 30, 2021 18:01 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (1 responses)

For a publicly owned company, sure. $DAYJOB has been privately held since the beginning and recently went 100% ESOP (employee-owned) to avoid the fate of these FOSS-oriented IPO companies which tend to wreck the culture either internally or with the wider community of its projects and to keep the company focused as it has been.

Elastic promises "open"—delivers proprietary

Posted Jan 31, 2021 5:06 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

Since you said several times that you're one of the CMake developers, I can guess which company you're working in. Thank you for your work, it helped me a lot when I was working on scientific visualizations!

Elastic promises "open"—delivers proprietary

Posted Feb 8, 2021 9:52 UTC (Mon) by emorrp1 (guest, #99512) [Link]

Wow, thank you for all the prose you've spent time writing, I did read the OSI thread about SSPL originally but I'm inherently biased to trust Debian's approach. Thank you for providing a fascinating, well-argued perspective engaging in all the objections and keeping the discussion human leading to some some great quotes.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds