Fedora Decides To Not Allow SSPLv1 Licensed Software Into Its Repositories

[Maddo]

The SSPL is, literally, a restriction on software usage, which directly violates the Freedom 0 of the FSF, you will not be able to run the program however you wish unless you do this, which is a restriction in my vocabulary. Linking this https://www.gnu.org/philosophy/progr...om-to-run.html

[tuxd3v]

Yes, that's the bit that bothers me. The viral aspects of the GPL are fine with me, because they're very limited in scope – you mix GPL code with your code, and the combined code must be made available under the GPL.

The SSPL is far more ambitious, because on the face of it, the license amounts to "if you use MongoDB as a database backend for your application, you must release not only your application under the SSPL, but also, 'without limitation' every single piece of infrastructure that might be needed for the user to create their own installation of your server-based application." Seriously, look at that list... monitoring software, backup tools, everything... and all because your application functions as a MongoDB client, without using a single line of their code in your application.

I haven't read much about it, but this licence is based in the AGPL,
Which states that, if your application uses, in some way MongoDB, and you can't have your application running without it, it means it uses mongodb API somewhere..

And so, your end application code needs to be released under AGPL.

Apart from that,
It target's Cloud Companies, that are making tons of money, providing VMs/Containers for Mongodb, and this Companies contribute nothing back to the Community

So Cloud Companies have Software, that targets MongoDB, for backups, installation process, and so on...the question is...does this software works without mongoDB?
A lot of them don't,
And so, you don't have an alternative, and so, your backup, installation, and all stack software, that manage Mongodb Should also be released under AGPL( providing that you can't run your stack without Mongodb components.. )
This is my way of see AGPL..

This new license, extends AGPL to the OS services and others, that are not part of the Mongodb stack..

But a better educated person on the mater can clarify better AGPL License.

[L_A_G]

thanks to the other poster which seekd for https://www.gnu.org/philosophy/progr...om-to-run.html because i was too lazy doing so for persons like you which don't understand the idea behind opensource

English clearly isn't your first language (it isn't mine either), but let's see if I can finally get trough to you here:

The incompatibility here doesn't come from MongoDB itself, it comes from the users and other software not being free enough to be compatible with MogoDB's new license because they don't want/allow for all of the source code to be made free/open. We're really talking about a situation where people and organizations don't want to free/open software what that's required by MongoDB's license.

Open source, or free software, is all about putting the source code out there for other people to use and the issue here is that not everyone is ready to actually do that when MongoDB's new license mandates it. The fact that you mandate something doesn't mean that you're not free/open, no, actually doing that means you're free/open and that's what people who don't like that are resisting.

[skeevy420]

Well, bad example, because using non publicly reviewed crypto (i.e.: non open-source crypto) is pretty bad idea, you could be making critical mistake that will enable an attacker to steal your data - mistakes that a review by other specialists would have helped point out and fix.

You'd want your crypto stack to be as widely reviewed as possible and releasing it under an open-source license is pretty much what you would want (or you could be using publicly available code under GPL or BSD to begin with).

You missed the point. It could be the compression algorithm you developed to store text files for your site "document-hub.com", but because some junior dev went and used MongoDB, you have to open source your compression algorithm, all your web code, that script that adds .$DATE to file names...

Sony is working on an online game streaming service where you click play and you just start playing a game off their server. If they used MongoDB, they'd have to open source all of that...technically, they might also have to open source the games...I'm not sure at what level someone is allowed to keep code closed; like, does it cover just the server operator/owner or do users of the server fall under that provision too (which could allow for loopholes).

I can see the good points of this license, but at what point does something go from source code to advanced configuration? Would some MongoDB user have to open up their dot files because, say, they're using some advanced ZSH setup and it has an auto-magic script that ensures all characters in a file name are UTF-8 or they're using BTRFS and added in a cp reflink alias?

Technically scripts and dot files can be code and can contain code. Void Linux mainly uses shell scripts for their programming so it is a valid concern.

At what point do you have to stop opening up your code? It's a shitty license because of questions like that.

Like I said, I do see the good intentions it wants to bring. I'd love it if Sony and/or AMD had to share all their work on the BSD kernel used on the PS4.

[L_A_G]

...

Oh for crying out loud... Is this really that hard to understand?

If you can't publish the source for something you're working on or with, then what made you have to do that is not what isn't free/open enough, it's ether you, the developers/owners of that third party code or both.

The whole "Oh you can't change the license terms on anything that already has users!" is the same idiotic logic that tax dodgers and people arguing on their behalf use to argue against closing loopholes they're using. If you don't want to publish your source code or find that the new license is incompatible with what you're using, just get a commercial license for it, after which you don't need to publish anything. Because this clearly meant to force freeloaders to move to either pay for using MongoDB or contribute back to the project.

Seriously, if you don't know what your dependencies are pulling then you've clearly got way bigger issues than not being compliant with the licenses of all the third party software you're using. You going on about how this is some kind of doomsday scenario for projects using MongoDB leads me to believe you probably didn't even know about the proprietary versions that don't include any open source obligations. You're also probably mixing up MongoDB with Apache Derby, JavaEE Persistence implementations like Hibernate or something because MongoDB is a high performance database used with some pretty damn huge datasets and has a feature set that definitely doesn't fall under the description "tiny".

Also, you really need to work on your use of punctuation because your use of run-on sentences it's just painful to read what your writing.

[ssokolow]

I haven't read much about it, but this licence is based in the AGPL,
Which states that, if your application uses, in some way MongoDB, and you can't have your application running without it, it means it uses mongodb API somewhere..

And so, your end application code needs to be released under AGPL.

Only if your application code is using an AGPL-licensed client library. The AGPL, like the GPL, only applies to "derived works" as defined by copyright law and it's a settled matter that the GPL does not extend to other processes which communicate with GPLed binaries through sockets.

MongoDB is a server which is accessed by applications using sockets. That means that, if you patch or write an in-process plugin for an AGPL-licensed version of MongoDB, you must share those changes. However, if you write an application that accesses MongoDB over a network socket using a client library that's MIT or Apache licensed, the AGPL license on the server does not extend to the client.

That's why you can link to MariaDB as your storage backend without being forced to GPL your creation if you distribute copies of it. MySQL's client and server libraries are both "GPL or paid proprietary"... but the client libraries are small and simple, so it wasn't difficult or time-consuming for the the MariaDB developers to write new LGPLed replacements for the GPLed client libraries when they forked MySQL.

[L_A_G]

so am i free to use that software where i even not intend to touch it's source or not?
if not it's license is not free - it's really that simple douchebag

As I keep trying to explain to you, over and over again, the any lack of software freedom/openness stems from everyone except than the MongoDB developers. In other words; The only "douchebags" here are the developers and owners of software that isn't free/open enough for MongoDB.

Seriously, by that logic GPL isn't "free" either as it isn't compatible with quite a lot of proprietary licenses. Hell, nothing GPL-based or even similar to it is free if we go by down this rabbit hole of "if it clashes with some other license it can't be free".

personally i don't give a shit about MongoDB at all to make it clear but pretending it's a real free license is just plain stupid, otherwise distributions which don't allow non-free software won't throw it out of their repos and no matter if you believe it Fedora legal has laywers knowing more about lincenses as we two togehter

Again, when the issue is that other licenses aren't free enough to with with the free/open edition of MongoDB claiming that it's somehow not free is completely stupid. This issue is that it's too free/open, not that it isn't free/open. Trying to act tough and going on about how you don't "give a shit" about something in the comments to a news story about it that has over 40 comments and about half of those are yours is just plain silly.

If you didn't "give a shit", then you wouldn't have bothered to write a single comment, but here we are.

[tuxd3v]

Only if your application code is using an AGPL-licensed client library. The AGPL, like the GPL, only applies to "derived works" as defined by copyright law and it's a settled matter that the GPL does not extend to other processes which communicate with GPLed binaries through sockets.

MongoDB is a server which is accessed by applications using sockets. That means that, if you patch or write an in-process plugin for an AGPL-licensed version of MongoDB, you must share those changes. However, if you write an application that accesses MongoDB over a network socket using a client library that's MIT or Apache licensed, the AGPL license on the server does not extend to the client.

That's why you can link to MariaDB as your storage backend without being forced to GPL your creation if you distribute copies of it. MySQL's client and server libraries are both "GPL or paid proprietary"... but the client libraries are small and simple, so it wasn't difficult or time-consuming for the the MariaDB developers to write new LGPLed replacements for the GPLed client libraries when they forked MySQL.

First of all thanks for the clarification..
The ideia I have was that the Mariadb Server was released as GPLv2, and the clients has LGPL... no problems with LGPL, since you can dynamic link against..

AGPL, at least for me, is more complicated, seems not clear, because if you have a Library, released under AGPL, even having a client that is dynamic linked with that Library, turns your code in AGPL, I think..

The only way this could eventually work out, seems to be,
If I have a AGPL server + LGPL client library( dynamic linked with my proprietary software..), and I deploy it in a server, so that a user can access it..

But I am now sure if I have to provide my source code, since users will retrieve information trough it from AGPL server.. , and without the AGPL server my code doesn't work..

[Delgarde]

This new license, extends AGPL to the OS services and others, that are not part of the Mongodb stack.

Yeah, that's the problem.

The AGPL is essentially a small extension to the GPL, covering what was perceived as a loophole around the SaaS model... that if a user accessed an application online without any local installation, they had no rights to the source code, because the application had not been 'distributed' to them. So under the AGPL, someone using a copy of MongoDB provided as a cloud service had rights to the code (including any modifications made by the cloud host), something that would not have been covered if MongoDB had been under the GPL. It's essentially a clarification around what it means to "use" the application, and therefore who has rights.

The problem with the SSPL is that it's far more all-encompassing. The Mongo folks are basically arguing that any use of an API counts as creating a derivative work, because calling that API is essentially the modern equivalent of linking a library - even though not a single line of their code is present in your code, the mere use of the API is sufficient. But that means that if I build a server-based app that happens to use a MongoDB backend, my server has to be SSPL as well - which means that anyone else wanting to use my APIs has to be SSPL, and so on... even though they might have no idea that my app is backed by MongoDB (an internal implementation detail of no interest to my users).


See the difference? The AGPL recognises separation between server and client... anyone writing a client is merely a user of the server, and are explicitly not subject to any restrictions on how they use it (restrictions on usage being forbidden by GPL and AGPL)... however as users they do gain rights to the server code.

By contrast, the SSPL opens up a huge can of worms by erasing that distinction - by arguing that accessing the server is considered creation of a derivative work instead of mere use, the license terms of the server end up propagating *everywhere*. And that's why there's a lot of fuss over it being discriminatory and imposing usage restrictions – *technically* it doesn't restrict use, but only because they've redefined "use" in a way that much of the open-source community clearly rejects. And so it's seen as a deliberate attempt to claim open-source credentials while discouraging open (i.e. unpaid) use, rather than as a good-faith attempt to resolve a real problem with existing open-source licenses.


Personally, I'm amazed Oracle have never tried something like this... screwing around with license issues is their kind of game. Although this *does* remind me of the Oracle/Google case and the rulings around copyrighting APIs... those rulings, and Mongo's views on API use, are a very unpleasant combination.

[ssokolow]

First of all thanks for the clarification..
The ideia I have was that the Mariadb Server was released as GPLv2, and the clients has LGPL... no problems with LGPL, since you can dynamic link against..

AGPL, at least for me, is more complicated, seems not clear, because if you have a Library, released under AGPL, even having a client that is dynamic linked with that Library, turns your code in AGPL, I think..

The only way this could eventually work out, seems to be,
If I have a AGPL server + LGPL client library( dynamic linked with my proprietary software..), and I deploy it in a server, so that a user can access it..

But I am now sure if I have to provide my source code, since users will retrieve information trough it from AGPL server.. , and without the AGPL server my code doesn't work..

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.