Fedora Decides To Not Allow SSPLv1 Licensed Software Into Its Repositories

[rossi123]

Correct. In that respect, the AGPL is essentially identical to the GPL - it doesn't include an LGPL-style exemption for linking. It's basically an adaptation of the GPL for server applications, clarifying that someone using that server over a network counts as a user for the purposes of being entitled to the code, even though they've not technically received a copy of the software binaries.



The server license doesn't matter... even though you require it, a server is considered separate from the clients which use it.

But if you use a client library in your application (a database driver, for example), you need to comply with the license of that library, just as you would any other library you use. LGPL, Apache, MIT, BSD – they're all more or less compatible with any proprietary code you might write (GPL and AGPL are not). Alternatively, if the protocol is simply enough, such as a nicely-documented REST service, you can write your own client.



No, because client and server are separate things – even though they talk to each other, and even though the client cannot function without the server, they're separate applications. The license of the server code is unrelated to the license of the client code... but note that I say "code license". It doesn't mean that the server doesn't have conditions on using the server itself, but your code doesn't care about the server code... a GPL client can talk to a 100% closed proprietary server, and there's no conflict over the *code* licensing.

That's where the SSPL is a concern – because it's written by people who don't agree that client and server are separate things, and believe that calling a remote API is equivalent to linking code into a combined executable... you're not just using their IP, you're creating a derivative work. And there's some truth to that claim, because in the Mongo world, cloud services and microservice architectures have lately been displacing the traditional monolithic services, and open-source licensing is slow to respond to new trends.

But as-is, the SSPL is far too reaching ... it leaves that distinction between linking and Pnr Status TextNow VPN usage ill-defined , and as such, it's almost certainly going to result in court cases trying to establish what the boundaries actually are. And until that happens, this is a license that nobody in their right mind should be going near...

thank you very much for all this detail and for your answer but I have a small question please
why are the client and the server separate objects despite talking to each other? and is there a possibility of being linked ??

[tuxd3v]

I'm not a lawyer but my understanding is that, if you service a request using AGPLed code, you must make available to the requester that AGPLed code, any "derivative works" (ie. custom patches or extensions which run in the same process), and any build scripting you wrote for it.

As such, if you were running an AGPLed PHP app, you'd have to make available whatever PHP code you're running, but not the PHP runtime or any web server using a mod_php-style approach to running it, because those aren't legally considered to be derived from the programs which depend on them.)

That's where the dynamic linking comes in. By linking against a library, you're creating a derivative work.

Thanks, for the clarification.
So in this case, since MongoDB client and Server were AGPL, Mongodb were in big trouble, because they have to sue half the world, for using the client, and *NOT* providing the source code..
They needed to waist tons of money to protect AGPL, if you can look at it like that.. so they find a way, to force big companies to pay for it, becasue otherwise, the costs are too high..

[tuxd3v]

Correct. In that respect, the AGPL is essentially identical to the GPL - it doesn't include an LGPL-style exemption for linking. It's basically an adaptation of the GPL for server applications, clarifying that someone using that server over a network counts as a user for the purposes of being entitled to the code, even though they've not technically received a copy of the software binaries.

Thanks for the clarification
What I perceive is that AGPL, with the obligation to provide the server code to the client, started this situation..

Because the client is the end user now( user of a mongodb client AGPL based, that talk to the AGPL server.. ).. and so the final user has the right to the mongodb client code, providing the client is also AGPL, which happens in lots of places, MongoDB would be forced to start Litigation with half of the world, they would be bankrupt in less than nothing, while the giants out there would be rich, with the work of MongoDb developers, because the content is managed by the developers that contract that cloud services..

In regards with a Closed client, not AGPL,
I don't know, but if the client has the headers of the API,( and we know that the API is AGPL ), it is a derived work..

If the API was written from scratch,
Even then could be that its a derived work, because there are lots of parts, that need to be defined in the same way, even with different names/functions, the protocol needs to be the same, and the Compiler Toolchain Preprocessor will bring tons of code, that may be AGPL, and because its not there a LGPL restriction, and also because AGPL forces a client accessing trough the Network to get the AGPL code of the server( The server being here our Client deployed in the cloud ), it could be that the code needs to be released under AGPL too.( with GPLv2, I think this doesn't happen )..

The question here is, If its possible to create a 100% closed client without deriving work..

We have massive deployments of MongoDB and Cassandra, we pay for both( In our type of business when we have shadow zones, we buy, because disclosing technology here, is not acceptable )

Cassandra, at least some years ago,
Had a different approach, and only required a company to buy a license if the company had a revenue **above 5 or 6 Million/Year**, but I don't know if that clause persists today on not,
The Lawyers deal with that stuff.. I only know of it because I made some deployments..

But a clause like that, could be a better fit for MongoDB, and will save small groups from dealing with the new License, at same time will force larger groups to settle a fee.

[TheBlackCat]

How is MongoDB "wrong"?! Wrong in what?

Wrong in claiming it is an open-source license. People who are experts in open source consistently say that the license violates multiple, specific aspects of the definition of open source software.

[ssokolow]

Thanks, for the clarification.
So in this case, since MongoDB client and Server were AGPL, Mongodb were in big trouble, because they have to sue half the world, for using the client, and *NOT* providing the source code..
They needed to waist tons of money to protect AGPL, if you can look at it like that.. so they find a way, to force big companies to pay for it, becasue otherwise, the costs are too high..

If a company was already violating the AGPL, then the SSPL does nothing new to help MongoDB. Either way, they have to take action to enforce their license.

[ssokolow]

thank you very much for all this detail and for your answer but I have a small question please
why are the client and the server separate objects despite talking to each other? and is there a possibility of being linked ??

That's just how copyright law works. Otherwise, it'd be illegal to use Opera or Microsoft Edge to visit any website written using LGPLed, GPLed, or AGPLed components unless you could first convince their makers to release the browser under the same terms.

(Likewise, it'd be illegal for a GPLed mail client to connect to any mail server running Postfix, which uses the GPL-incompatible IBM Public License, or for a proprietary client running Outlook to connect to any mail server running Exim, which is GPLed. Do you start to see why it's so important for the license's reach to stop at the process boundary?)

As for "and is there a possibility of being linked ??", could you rephrase that? I'm not sure what you're asking.

[ssokolow]

In regards with a Closed client, not AGPL,
I don't know, but if the client has the headers of the API,( and we know that the API is AGPL ), it is a derived work..

If the API was written from scratch,
Even then could be that its a derived work, because there are lots of parts, that need to be defined in the same way, even with different names/functions, the protocol needs to be the same, and the Compiler Toolchain Preprocessor will bring tons of code, that may be AGPL, and because its not there a LGPL restriction, and also because AGPL forces a client accessing trough the Network to get the AGPL code of the server( The server being here our Client deployed in the cloud ), it could be that the code needs to be released under AGPL too.( with GPLv2, I think this doesn't happen )..

The question here is, If its possible to create a 100% closed client without deriving work..

That's what Oracle and Google are fighting over in Oracle America, Inc. v. Google, Inc.. Whether an API itself is copyrightable.

Oracle would have to win for it to be possible to AGPL the API itself but, trust me. You really don't want that to happen. It would be hugely destructively anti-competitive.

The status quo that we've been operating under until now is that the structure of an API, in and of itself, isn't sufficiently novel to qualify for copyright protection. (Yes, that is the standard. For example, a single tweet at the old length of 140 characters is probably ineligible for copyright because you can't be sufficiently novel in 140 characters to merit protection.)

You can copyright a client implementation, but, unless Oracle wins, it's always legal to implement your own alternative client as long as you don't run afoul of the DMCA's DRM anti-circumvention provision while doing it.

[tuxd3v]

If a company was already violating the AGPL, then the SSPL does nothing new to help MongoDB. Either way, they have to take action to enforce their license.

Indeed, and of course there should be zillions out there violating the license for sure, I don't know any, but for sure...with a AGPL client..

If MongoDB continues AGPL, and if they start a litigation against a Company, they receives Zero, in return, and all of us receive everything( The code adaptations made by that company will be open to all ), but MongoDB waisted tons of resources to bring that company in compliance..and received zero in return..

In the new License case, their are a very important diference...

With the new License, which Obligates them to open the infrastructure systems, ...its a not acceptable clause,
And when MongoDB start Litigation with this license, the Company not complaining when they loose the case in court, they will try to settle the case out of court, and will pay back, because no one wants to disclose its infrastructure architecture.. and so Mongodb has money in its pockets...at least that probability is bigger, if not, we all win and MongoDB burned its money to sue a company and received no money back..

So in my Opinion, they will try to sue, big entities that have a lot to loose( if they lose the case ),
and this grows exponentially the chance of Mongodb get some fee back..

Its not unusual to add clauses to GPL licenses,
Some people use a Grant only clause, for "Non-Comercial usage"( Which means that, to use commercially, the copywriter needs to agree...resuming.. receiving a fee )

[tuxd3v]

That's what Oracle and Google are fighting over in Oracle America, Inc. v. Google, Inc.. Whether an API itself is copyrightable.

Oracle would have to win for it to be possible to AGPL the API itself but, trust me. You really don't want that to happen. It would be hugely destructively anti-competitive.

The status quo that we've been operating under until now is that the structure of an API, in and of itself, isn't sufficiently novel to qualify for copyright protection. (Yes, that is the standard. For example, a single tweet at the old length of 140 characters is probably ineligible for copyright because you can't be sufficiently novel in 140 characters to merit protection.)

You can copyright a client implementation, but, unless Oracle wins, it's always legal to implement your own alternative client as long as you don't run afoul of the DMCA's DRM anti-circumvention provision while doing it.

But there I think Oracle is right,
Because Google is using the Virtual Machine Technology, without consent, which now belongs to Oracle..
And its known that even at code level Google was using Oracle code without permission, but Google was always surpassed that, because, when someone is infringing your code, after you notify him, he has 1 Year to solve te problem, if incapable, it needs to comply.

And Google has been usurping Java Technology for almost a decade or so now( Not only Google ), with great success( Even tough that they already lost some cases, but the crime is compensatory of course.. ).

In Relation to API designation or names, is a very controversial situation..
Apple even copyright device designs, Ferrari copyrighted, their colour...you cannot use a Ferrari Red colour in another car that not a Ferrari.
QNX copyrighted the amazing real time OS they have,a truly 100% real time, you cannot use that technology( Although Microsoft usurped it on Windows NT, but it needed to make adaptations, and the performance was not the same, and the BSODS were happening with some frequency )

But its also a colour.. a lot of car makers copyright names, designations, and so on, in this caos situation,
Does Oracle has the right to copyright the API names only( the technology is of course copyrighted... or should be, at least the VM )?
In a world were some can, Oracle also wants the same..

In my opinion if the API is merely explanatory, and can be remade without deriving work, with no dependency, it should not be considered restricted on usage

But in the Java case is worst than that, because what mater there is the Java Virtual Machine, the technology behind it, and Sun MicroSystems waisted so much money on it, that they improved the VM, to a very nice level,
Without it Java would be performing very badly,( like Android does, because its not using the Optimized version of the Java VM.. but a sort of a clone, without paying royalties to the Owners, now Oracle )

In this regard, Scala, compiles to bytecode, but don't have its own VM I think, Kotlin, I think its the same, but not sure..

[ssokolow]

Its not unusual to add clauses to GPL licenses,
Some people use a Grant only clause, for "Non-Comercial usage"( Which means that, to use commercially, the copywriter needs to agree...resuming.. receiving a fee )

It's either illegal or a no-op to add clauses to GPL-family licenses.

For the illegal part, the text of GPL-family licenses is licensed to you under the term "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." is "All Rights Reserved", so you modifying it without permission from the FSF is copyright infringement.

For the no-op part, GPLv3-family licenses contain a clause in section 7 (Additional Terms) which grants you explicit permission to ignore any additional restrictions imposed outside the text of the license...

All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.

...and GPLv2-family licenses are written in such a way that, if someone imposes an additional restriction, the GPL is unsatisfiable and you're left in a situation which boils down to "You may use this when X = 1 and X = 2 simultaneously.)

6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.