|
|
Log in / Subscribe / Register

Elastic promises "open"—delivers proprietary

By Jake Edge
January 27, 2021

Open-source software is famously able to be used by anyone for any purpose; those are some of the keystones of the open source definition. But some companies that run open-source projects are increasingly unhappy that others are reaping some of the profits from those projects. That has led to various efforts of "license reform" meant to try to capture those profits. So far, those efforts have just led to non-open-source licenses, thus projects that are no longer open source. We are seeing that play out yet again with Elastic's mid-January announcement that it was changing the license on some of its projects.

Elastic is switching the license of the Elasticsearch search-engine software and its data-visualization counterpart, Kibana, away from the Apache Software License version 2 (ASL) to the Server Side Public License (SSPL) starting with version 7.11. As with previous versions, those projects will be dual-licensed with the Elastic License, so that users who do not want to (or are unable to) comply with the SSPL can purchase a license from Elastic.

We have seen this movie before, of course, but this time around the disingenuous way that Elastic is presenting its move is raising hackles within the FOSS community. It is clear that the company is quite unhappy with Amazon Web Services (AWS) for turning Elasticsearch and Kibana into for-profit products that compete with Elastic's own offerings. It is less clear that the license switch really addresses the problems that Elastic is complaining about, however. Beyond that, AWS is using the components under the license that Elastic freely chose when the ASL suited its objectives. Now that the ASL apparently does not suit Elastic, it is rather ridiculous for the company to proclaim that switching to a proprietary license is "doubling down on open"—it manifestly is not.

There is obviously nothing wrong, in a legal sense, with Elastic changing the license of those products/projects. But in the eyes of many, the SSPL is simply another form of proprietary license. The SSPL was not approved by the Open Source Initiative (OSI) as an open-source license; it was withdrawn from consideration when the response made it clear that it would not be accepted. But all of the contributors to the projects have signed a contributor license agreement (CLA) that allows Elastic to relicense the code as it sees fit; it exercised that right with the announcement.

The prior releases that were made under the ASL are still freely available, of course; interested developers or organizations can fork from that point and continue maintaining the code. In what should not come as any real surprise, AWS has such an interest; it stepped right up to fork the projects. So it is possible that Elastic will not only be competing with the AWS product offerings, but also with a fork of its projects—which might just become more popular than its own versions. Elastic should have seen this coming, so it is not at all clear what it thinks it is gaining, at least assuming that the company intends to do what it said in the announcement:

We will continue to develop our code in the open, engage with our community, and publish our releases for free under the Elastic License as we have done for the last three years. We remain committed to keeping all of our free features free — we are not making any changes to which features are free and which are available in a paid subscription.

The SSPL was created by MongoDB to try to stretch the idea of copyleft to cover additional software, beyond just the code released under the license. It is a modified version of the GPLv3 that, like the Affero GPL (AGPL), modifies the section on code being used in a network service. The AGPL requires releasing any modifications to the source code from network services, but the SSPL extends that requirement to a whole raft of barely related or unrelated code ("including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software"). Furthermore, the source code for those pieces must be released under the SSPL, not simply under a FOSS license.

That clause of the license is pretty clearly written as a "poison pill" to ensure that large service providers are required to use the other half of the dual license, thus pay the licensor (MongoDB or, in this case, Elastic) for its proprietary license. The SSPL has not been tested in court, but that clause could easily be interpreted to mean that all of the code on the server must be released under the SSPL, which is well-nigh impossible for many providers. Much of that code is already available under a FOSS license (e.g. Linux), but cannot simply be released under another license.

While the GPL itself expands its reach beyond just the code it covers (to the build scripts and such, as pointed out by Matthew Garrett shortly after the release of the SSPL), that "scope creep" is far smaller and, likely, more defensible than forcing the release of completely unrelated pieces, such as, say, backup software. The SSPL clearly makes the use of this supposed open-source software fraught with legal peril, no matter whether you are some giant cloud provider or not; in effect, if you want to make money using Elasticsearch or Kibana, you will need to be able to release all of the code you are using to do so under the SSPL—or get a proprietary license from Elastic.

This shift from open-source licenses to licenses that are less so has been ongoing for some time. Projects that can be used in the software-as-a-service (SaaS) model often begin as fully open source; that typically leads to more rapid adoption, which looks great to investors. Down the road, though, those same investors may be the ones getting cold feet about users exercising the freedoms they were given, so those freedoms are curtailed. In other industries, that strategy is called "bait and switch".

The success of the strategy depends in large part on the licensor being able to turn in a proprietary direction. It needs to be able to offer new features as "secret sauce" in order to out-compete both the older version of the code and any fork(s). That kind of precludes an open-source approach, or at least makes such an approach quite difficult. It will be interesting to see if Elastic keeps its promise this time, though one guesses that few are truly banking on it.

Back in mid-2019, VM (Vicky) Brasseur nicely summed up the problems with this strategy:

These projects are not being relicensed to protect them from Amazon. Claiming that they are is at best naive and at worst wilfully lying. These companies are relicensing projects to cover for the fact that they are ignorant of how to run a successful business. They knowingly released their secret sauce under permissive licenses and have discovered that doing so means that competitors can create more compelling product offerings based upon the same technology. This is entirely in accordance not only with the licenses that these companies knowingly chose, but also with a competitive market. The only problem with this is that it came as a surprise to these “open source” companies and now they’re reacting poorly.

The reaction from the FOSS community to Elastic's announcement was swift and rather heated from some quarters. Part of the ire is due to Elastic's use of phrases like "free and open" in a deceptive way. As Drew DeVault put it:

Elastic was not having their lunch eaten by Amazon. They cleared half a billion dollars last year. Don’t gaslight us. Don’t call your product “free & open”, deliberately misleading users by aping the language of the common phrase “free & open source”. You did this to get even more money, you did it to establish a monopoly over Elasticsearch, and you did it in spite of the trust your community gave you.

He goes on to remind developers that signing a CLA sets up this kind of loophole; companies cannot relicense code if they are not granted those rights. He also suggested that Elastic, and other companies that require CLAs, have done so deliberately with the intention of making this kind of switch down the road. That's hard to judge, but companies don't ask for a CLA that they are sure they will never need—it is obviously done as type of insurance.

It remains to be seen if AWS is a better steward, however. So far, there is just the January 21 fork announcement, which does have some hopeful language:

Our forks of Elasticsearch and Kibana will be based on the latest ALv2-licensed codebases, version 7.10. We will publish new GitHub repositories in the next few weeks. In time, both will be included in the existing Open Distro distributions, replacing the ALv2 builds provided by Elastic. We’re in this for the long haul, and will work in a way that fosters healthy and sustainable open source practices—including implementing shared project governance with a community of contributors.

There is no mention of a CLA requirement (or lack thereof), but unless all of the previous contributors (including Elastic) sign a new agreement, AWS would be unable to relicense the code anyway. It seems likely, then, that the forks will operate in more of a community-open-source fashion, rather than as a corporate-open-source project.

There have been several speculative bubbles in the FOSS world along the way. There was a time when having "Linux" in your company name was enough to attract investments that were, at best, overly optimistic in many cases. More recently, "open source" as a business model has taken over as the attention-getting idea in the startup world, but as Brasseur pointed out back in 2018, "open source is not a business model". Open source is a development method that can be used by a company to make money, but it is not magic fairy dust that can turn millions of users into paying customers—no matter how many Sand Hill Road companies believe otherwise.

A sad part of the story is that many of these companies are quite successful, even while being "hampered" by sharing their secret sauce with others. They just are not successful enough, or quickly enough, to satisfy today's venture capitalists and other investors. In the meantime, though, the FOSS community gets taken on a ride with an abrupt end, which makes for a rather unpleasant journey.


to post comments

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 18:56 UTC (Wed) by kemitchell (subscriber, #124442) [Link] (74 responses)

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.

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.

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 21:24 UTC (Wed) by aszs (subscriber, #50252) [Link]

Particulars aside, this sort of thing is gonna keep happening as long as the structural reality persists that "open source is not a business model" as the article says and it's hard to get businesses to spend money on something that they can get for free. But complex software require significant upfront investment and it's hard to find that outside of big companies or VCs...
One idea to fix that is this idea of "cloud funding"? -- https://www.onecommons.org/cloudfunding -- a non-compulsory mechanism to share some of the revenue spent on cloud services with the open source projects they depend on. I hope it works!

If you won't be bound by your own license, why should we take you seriously?

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

It seems to me that everything that needs to be said about the SS Public License has already been said. I have posted twice about it and related issues. The only thing I haven't seen said succinctly, although it's been hinted at by many, is this:

There is no one on the planet yet who has agreed that they will run a project under the SS Public License and be themselves bound by the SS Public License.

That really says it all. Whatever your view about copyleft licenses generally: legitimate and well-intentioned copyleft licenses (e.g., CC-BY-SA, GPL, and Affero GPL) have many projects that use the license in an inbound=outbound contributor licensing fashion. All (two of the) SS Public License uses have a strict CLA that give the publishing entity non-SS-Public-Licensed rights to the contributions. We shouldn't take anyone seriously who promulgates a license but won't use it themselves in an inbound=outbound way. Period. I suggest we all try to not give further interest to this clearly risible licensing proposals from MongoDB and Elastic.

If there's energy to focus here, I'd say it's toward figuring out how to handle good governance of forks of these two projects. I hope folks can maintain the discipline to discern and bifricate these two very different issues.

If you won't be bound by your own license, why should we take you seriously?

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

> It seems to me that everything that needs to be said about the SS Public License has already been said.

Apologies, my links that were supposed to be embedded in that sentence didn't come through when I switched from Plain Text drafting to HTML drafting in LWN's comment interface. I had meant to link to the same two posts that Jake links to in the parent article: VM Brasseur's and Drew DeVault's articles at these URLs:

https://anonymoushash.vmbrasseur.com/2019/06/07/the-probl...
https://drewdevault.com/2021/01/19/Elasticsearch-does-not...

I didn't see much point on writing a fresh post myself after seeing those excellent pieces…

If you won't be bound by your own license, why should we take you seriously?

Posted Jan 30, 2021 16:51 UTC (Sat) by ballombe (subscriber, #9523) [Link] (2 responses)

Would you be willing to address some (perceived or real) loophole in the AGPL ?

If you won't be bound by your own license, why should we take you seriously?

Posted Jan 31, 2021 21:40 UTC (Sun) by bkuhn (subscriber, #58642) [Link] (1 responses)

> Would you be willing to address some (perceived or real) loophole in the AGPL ?

I've encouraged anyone who thinks we need to come up with better copyleft to join the copyleft-next project. I am not willing to take seriously companies who don't even bind themselves by copyleft licenses they promulgate when they disingenuously claim, as Elliot of MongoDB did, that they're attempting to make a better copyleft for end-users. Their goal is to push people from copyleft to proprietary licensing. Period.

As a matter of community priority: copyleft violation is widespread and that most devices in the world today (by a count of millions and perhaps billions) do not give users the software freedom that copyleft ensures due to copyleft violations. As such, my priority, as a copyleft theorist is to figure out why copyleft is not working to defend software freedom and what we need to do to fix it. Making a even stronger copyleft than AGPL can't be the right priority in that climate, since even the weaker copylefts, such as plain GPL, are so widely violated.

If you won't be bound by your own license, why should we take you seriously?

Posted Jan 31, 2021 21:57 UTC (Sun) by Wol (subscriber, #4433) [Link]

> As such, my priority, as a copyleft theorist is to figure out why copyleft is not working to defend software freedom and what we need to do to fix it

I think that's pretty obvious. Certainly in America, it's difficult to enforce. Copyright theft is just accepted as a fact of life.

One only has to look at Reuters - they nicked a newspaper article (where the author had basically licenced it "Creative Commons just attribute me") and when the author complained, they just said "if you kick up a fuss we'll make sure you never publish another article again!"

What you want is the European attitude - copyright theft for gain is a criminal offence in Britain (even if it's not really enforced), and given that Europe tends to emphasise preventing future breaches it shouldn't be too hard - given evidence of previous breaches - to get an injunction requiring importers to certify IN ADVANCE that their gear doesn't breach copyright.

That would pretty much kill the habit of importing something illegal and discontinuing it before you get called on it ...

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 0:36 UTC (Thu) by IanKelling (subscriber, #89418) [Link] (12 responses)

> He goes on to remind developers that signing a CLA sets up this kind of loophole

> unless all of the previous contributors (including Elastic) sign a new agreement, AWS would be unable to relicense the code anyway

This is wrong as far as I can tell. In this article, relicense seems to refer to the common loose definition of changing the effective license for future releases, and that is perfectly able to be done without any CLA for lax pushover licenses like this case with Apache v2. Just write the new code under a proprietary license which "subsumes" the lax license, see https://www.gnu.org/licenses/license-compatibility.en.html . This is a common practice in proprietary software and one of the biggest reasons to use copyleft licenses.

Elastic promises "open"—delivers proprietary

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

That changes the effective license of the combined work, but it does not change the license of the ALv2-licensed code which is incorporated into that work. Proprietary works which contain ALv2-licensed components are still required to acknowledge that fact and reproduce the license text and copyright notices. This isn't much of a bar, of course, since it doesn't require source code disclosure, but it is not true that the ALv2-licensed works have been 'relicensed'.

Elastic promises "open"—delivers proprietary

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

It's more than enough of a bar to cause big companies severe discomfort - we didn't know it at the time, but the reason AT&T got crucified in court over Unix was they managed to - *seriously* - be in breach of the BSD licence!

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Feb 4, 2021 0:41 UTC (Thu) by nix (subscriber, #2304) [Link] (6 responses)

I must have missed that one. How?! (Was this the advertising clause version, and they didn't attach the attribution that clause requires?)

Elastic promises "open"—delivers proprietary

Posted Feb 4, 2021 1:16 UTC (Thu) by Wol (subscriber, #4433) [Link] (5 responses)

Bear in mind that this is the real BSD licence - as in you must credit Berkeley...

But what happened was that, as part of their claim that Berkeley infringed AT&T copyrights, AT&T claimed ownership of utilities like vi. Berkeley promptly brought evidence that, not only was vi written at Berkeley not AT&T, but that the reason AT&T mistakenly claimed it was that they had deleted all evidence as to who owned the copyright!

That was why they capitulated so quickly, and wanted it all sealed - if they mistakenly claimed stuff that clearly belonged to other people, then they had no way to prove they owned anything, and even worse that lack of proof was down to the fact they themselves had destroyed it.

The settlement should be available on Groklaw somewhere - someone made a Freedom of Information request for it and sent it to PJ. In hindsight everyone was surprised no one had tried that earlier ...

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Feb 4, 2021 1:23 UTC (Thu) by Wol (subscriber, #4433) [Link]

I should have added this was what killed the SCOG case - it proved that SCOG had no valid claim to any part of Unix before SysV and all they had was the stuff written by Novell and themselves.

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Feb 4, 2021 1:40 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

Now the unanswerable question, of course: was this incompetence (which I can *easily* see), or malice backfiring (attempts to claim stuff as their own that really wasn't)...

Elastic promises "open"—delivers proprietary

Posted Feb 4, 2021 9:48 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

Bear in mind that - in the US - they weren't part of Berne until 1984. It was therefore assumed that software was covered by contract and trade secret, not copyright. Also, when was GNU founded? Early 80s? Nearly all software prior to Berne/mid-80s was open source, as in when you bought a computer you got the software AND THE SOURCE to the software.

At some point late 70s early 80s I guess, especially given that AT&T was governed by the anti-trust rules that they weren't allowed to compete in the software business, it was *company* *policy* that all software should be supplied without copyright notices (seeing as it was believed copyright didn't apply).

Problem was, Unix as supplied by AT&T contained a LOT of code from three University sources - Berkeley who claimed copyright, that Australian university who's name I always forget, and University College London, for whom the latter two copyright definitely DID apply.

So the Judge's guidance before making a ruling said "AT&T have deleted the copyright notices, therefore it's down to AT&T to prove they own the code". Seeing as I guess they didn't have a decent and long-standing backup system to prove where the code came from, they threw in the towel pretty quick, rather than have the Judge rule that they couldn't prove they owned it therefore they didn't. Hence the extreme secrecy over the settlement ... the Emperor had no clothes ...

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Feb 4, 2021 10:02 UTC (Thu) by amacater (subscriber, #790) [Link]

Possibly University of New South Wales - John Lions was there. https://en.wikipedia.org/wiki/John_Lions

Elastic promises "open"—delivers proprietary

Posted Feb 5, 2021 20:56 UTC (Fri) by flussence (guest, #85566) [Link]

Where AT&T (and SCO) failed was in not obfuscating the fraud well enough, and choosing to make an enemy of a large, well-organised group instead of trampling individuals. For a success story, see VMware.

Incidentally, this sort of scam is now the main business model of the “music rights societies” (a euphemism if there ever was one) feeding off of Youtube's automated system. Make a throwaway shell company with a name that looks like it was algorithmically generated itself, upload recordings of white noise, covers of other people's music, microphones pointed at bird feeders, and monetise, monetise, monetise. The system they abuse is built to be a death march for anyone coming in at the other side (Google will do anything to avoid employing real humans to support their products), so this is virtually consequence-free.

Elastic promises "open"—delivers proprietary

Posted Feb 4, 2021 21:12 UTC (Thu) by robert.berger (guest, #69236) [Link] (2 responses)

I am not a lawyer but also thought that Apache 2 does not require a CLA to be changed to a proprietary license. This might also be a reason why its usage is on the rise while copyleft license usage is declining.

Elastic promises "open"—delivers proprietary

Posted Feb 5, 2021 15:13 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

Does Apache 2 allow re-licencing? PROBABLY NOT.

Does it allow mixing with closed code? I think it does.

So no you probably can't *change* Apache 2 to closed, but there is no bar to inluding Apache 2 code in your closed project.

Okay, nit-picking, but get the legal nits wrong and it can be nasty - nits bite!

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Mar 12, 2023 9:10 UTC (Sun) by robert.berger (guest, #69236) [Link]

relicensing:

Here[1] it says: ". What are the Apache License terms & conditions?
The Apache License is a permissive open source software license - so you can release your modified version of the Apache licensed product under any license of your choice..."

"... However, you are required to release all the unmodified parts of the software under the same license (the Apache License)..."

[1] https://www.mend.io/resources/blog/top-10-apache-license-...

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 6:38 UTC (Thu) by kirschner (subscriber, #62102) [Link] (4 responses)

Thanks Jake for the article.

One addition about a detail of the article: you write that open source (or Free Software) is not a business model, but if we want to sharpen our thinking we should also consider questioning seeing it as development model.

In my talk at FOSDEM 2020 "core values of software freedom" I also quickly talk about why Free Software / open source is not a development model (see around minute 06:00).

At the FSFE we made the experience that differing between open development models and Free Software helps people taking better strategic decisions for their businesses and organisations.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 9:26 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (3 responses)

OSI certainly describes "open source" as a development methodology. See their mission statement.

The FSF(E) is obviously entitled to decide what "Free Software" means (it's their movement!), but purporting to speak on behalf of the open source side of things is IMHO questionable.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 9:56 UTC (Thu) by kirschner (subscriber, #62102) [Link] (2 responses)

Where in the OSI's mission statement do you read that? The part: "Open source enables a development method..." just underlines the point that Free Software enables certain open development models.

Beside that, the FSFE's considers "Free Software" and "Open Source Software" as different terms for the same software. See https://fsfe.org/freesoftware/freesoftware.html#synonyms for a short version and https://fsfe.org/freesoftware/comparison.html for the longer.

Both terms are used by people who talk about software freedom, while -- as we see in the article -- the terms are also used by some people to promote their proprietary software, and just want to make people believe it is Free Software / Open Source Software to benefit from its good reputation. Something many argued we as software freedom community should not accept.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 19:21 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

There are at least four possible things you could mean by "open source":

1. The open source software itself.
2. Open source licenses (which I *think* is what OSI means by "open source enables...").
3. The open source development methodology (the "development method" that OSI is referring to).
4. The people who practice it (the "open source movement").

"Free software" can refer to any of the above, or:

5. The free software ideology (four freedoms etc.). Open source has no directly comparable ideology.

Please, can you clarify which of those five things you are referring to? Or if you are referring to a sixth thing, can you define it?

Elastic promises "open"—delivers proprietary

Posted Jan 29, 2021 6:04 UTC (Fri) by kirschner (subscriber, #62102) [Link]

Sorry, I thought that is quite clear in the talk and the links I provided, but to make it explicit:

  • When I write about "Free Software" or "Open Source Software" I mean the same software.
  • When I write "Free Software movement" or "Open Source (Software) movement" I mean the same movement for software freedom, or I talk about "Free Software contributors".
  • When I write about "Free Software license" or "Open Source license" I mean the same licenses defined by the FSF and the OSI.

Please let me know if you have suggestions where to improve the FSFE's Free Software page or our article about the different terms in this area.

I would not write about "open source development methodology", at least not in the sense that this is then resulting in "open source software" as we are convinced it prevents better understanding. One example: A hundred universities can develop software together in the public with hundreds of students and professors participating in the development. If the software license says that you can just use this software for academic purposes, it does not fulfill the FSF and OSI requirements.

Therefor I call development models with many stakeholders and public development an "open development model". Calling it an "open source development model" in our experience misleads people to believe the resulting software meets the FSF and OSI requirements.

Although depending on the discussion it might even be better to specify if the code development is done by e.g. just one person or company in the public, or by many different stakeholders but without public repositories, or by many stakeholders in public repositories, and clarify if and how others are allowed to commit to those repositories.

You can develop software which meets the FSF and OSI requirements, but which followed a very closed development model = small amount of contributors or non-public repositories.

And the development model / practice for a certain software can change over time in both directions.


Copyright © 2021, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds