Hacker News new | past | comments | ask | show | jobs | submit login

It looks like it is, but is there any official word that the SSPL is proprietary? As far as I know MongoDB claims it isn't, and it hasn't been reviewed officially by either the FSF or the OSI. Is it in license purgatory?



Seems redhat lawyers have reviewed it, here's the announcement wrt fedora: https://lists.fedoraproject.org/archives/list/devel@lists.fe...


Bruce Perens feels “it manifests a lot of ignorance about Open Source and utter contempt for our community.”

https://opensource.org/LicenseReview122018


That Perens quote refers specifically to Sunil Deshpande's article about the SSPL and Open Source, not to the SSPL itself. But it's not far off either way…

The reaction on the OSI's license-review list is more varied. Lawrence Rosen and Ken Mitchell argue that the license should be approved. Everyone else is criticizing that it clearly violates the spirit of Open Source software (no discrimination against fields of endeavour!), and that the license is too broad and too vague in the critical section (Rosen agrees with the latter part). Carlo Piana points out that the goal of the license seems to be to create so much legal uncertainty that any serious user would be forced to buy a proprietary license from MongoDB.


I also criticize the way SSPL was drafted. The legal talent they have can do far better. The choice to patch AGPL cuffed them.

Here's me announcing an attempt at a plain-language, SSPL-style license from scratch:

https://writing.kemitchell.com/2019/01/12/Shared-Component-L...

The latest license text is at:

https://github.com/kemitchell/shared-component-license


Thanks for the insightful summary.


I don't know if it can be called free. But section 13 of the SSPL is certainly incompatible to RHEL's distribution model, or any other linux distribution I know of.

In particular it requires you to license "the Corresponding Source for all programs that you use to make the Program or modified version available as a service" under the SSPL. That naturally includes the linux kernel which is licensed under the GPL - and cannot be simply relicensed.


But they don't make it available as a service. They distribute binaries and perhaps source code.


Free software must be free for all its users. The most common example of this is a license that restrict fields of endeavor.

E.g. I could make a license exactly like the GPL except with a clause saying fuzzy2 on HN can't use my software without paying me.

Even though RedHat and Debian aren't fuzzy2 on HN, and 99.99...% (or 100%) of their users aren't that user either, they'd still refuse to distribute it. That license would be non-free.


I think the parent was commenting that since Red Hat did not offer a service, there is no legal restriction in distributing the code. In other words, if Red Hat decided to change its stance on distributing only free software, they could do so legally. I'm glad they didn't, but I think the parent is correct.

Edit: Usually don't complain about down votes, but I'd be happy to hear why the parent is incorrect if I've got it wrong. Are they not legally able to distribute for some reason?

Re-Edit: I read the initial query incorrectly. Yes, the parent's post is unrelated to the query. Sorry!


There is plenty of non-free software that a distro can legally distribute.

They still usually don't, because it would break the automatically trouble-free property of their distribution. If users have to check the license of software before using them, there is little point in packaging all of it together and automatically installing, so there is little point on making a distro at all.


If I understood that message correctly, it seems that Debian decided to remove MongoDB from its main repository as well: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915537#15


It's really not clear to me as he kind of backtracked in the next message by saying that he was writing under the role in the FTP team, rather than as Project Leader of Debian. My interpretation of that is that it is his opinion, but not a statement of policy. I'd be pretty surprised if they allow SSPL in Debian, but I don't think this is the statement that disallows it.


The FTP team is the body that ordinarily makes binding policy decisions about licenses in Debian. It's not typically the project leader's job, so I read this statement as saying "despite the .signature, I'm speaking in my role as a member of the FTP team, not the project leader overruling the FTP team."


The FTP team performs a license check before a package is moved into the archive, so they do get to decide what goes in and what doesn’t.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: