Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making the GPL more scary

lwn.net

Post reply on HN
Print view View original

111–120 of 151 posts

Re: Making the GPL more scary

#111

Post by trasz »

pjmlp wrote: post #71
trasz wrote: post #64

Earlier quoted context omitted.

Perhaps. But GCC lacks those same improvements from Sony, simply because Sony went with LLVM instead, doesn’t it?

That is exactly the point, with GCC the community would have enjoyed those improvements. With LLVM, Sony gets to cut down their compiler research budget, and the community sees whatever Sony feels like giving back, minor improvements without the juicy optimizer sauce that actually matters. Personally I don't care, given I use mostly commercial stuff nowadays, but I do see the return of shareware long term. Then MIT/B…

No - with GCC those improvements never got written, because the license used by GCC prevented it from happening in the first place. The decision whether to share the code usually happens before choosing the codebase to build upon, not the other way around.

Re: Making the GPL more scary

#112

Post by pjmlp »

trasz wrote: post #111
pjmlp wrote: post #71

Earlier quoted context omitted.

That is exactly the point, with GCC the community would have enjoyed those improvements. With LLVM, Sony gets to cut down their compiler research budget, and the community sees whatever Sony feels like giving back, minor improvements without the juicy optimizer sauce that actually matters. Personally I don't care, given I use mostly commercial stuff nowadays, but I do see the return of shareware long term. Then MIT/B…

No - with GCC those improvements never got written, because the license used by GCC prevented it from happening in the first place. The decision whether to share the code usually happens before choosing the codebase to build upon, not the other way around.

In this specific case, Sony would have been forced to actually spend money doing a compiler from the ground up instead of cutting costs down costs while giving a few crumbs back to keep the plebe happy.

What I find ironic with the current anti-GPL trend is the eventual return of the shareware model, then lets see how well the MIT/BSD folks will appreciate it.

Re: Making the GPL more scary

#113

Post by zzzcpan »

mindcrime wrote: post #110
msbarnett wrote: post #108

Earlier quoted context omitted.

> The phrase "Open Source" is not necessarily just the summation of the constituent words "open" and "source". "Open Source" is a unique concept with a unique meaning... and the de-facto definition of that concept, is the OSD[1]. The use of the phrase "Open Source" predates the very _existence_ of the OSD by years[1], so it's somewhat laughable to claim that people are "trying to muddy the waters and being intentiona…

Just because OSI wasn't formed as a legal entity until 1998 doesn't mean that the people involved weren't around and involved in those earlier discussions of "open source". All OSI did was formalize what was in common usage. And sure, you can cherry pick a few exceptions where individuals used the term in different ways. That has little or nothing to do with contemporary usage. And in today's vernacular (dating back…

Languages don't work like that. You don't just come up with a definition and try to force everyone to use it. People learn definitions from how they are used and mentioned in the things they encounter.

In reality almost no one is aware that OSI definition exists and those who do can't even remember what it is exactly. So, no, de-facto definition of open source is definitely not an OSI definition, but mostly literal meaning of open source software with most people presuming freely usable software as well to some degree. Take SQLite for example, it's open source, but not OSI open source and everyone is ok with that. Because this is where common meaning is. And trying to claim authority over it just invites bad PR for OSI. I guess OSI is already that irrelevant and it's pretty much consequence free to use a proper common meaning of open source.

Re: Making the GPL more scary

#114

Post by jchw »

PeterisP wrote: post #109
jchw wrote: post #21

Earlier quoted context omitted.

This won't lead to more open source code. Reading the actual clause lists a myriad of potentially implicated kinds of software, all of which must be open source licensed, and not just that but also under SSPL. Let's forget about the potential concept that GPLed software like the Linux kernel could very well be implicated, as LWN points out. Regardless, this clause is a literal legal minefield, and I would bet my life…

I'd rather bet my life savings that at least some such companies are going to reject both these options (SSPL or commercial licence) and just keep using the last MongoDB version that was released under GPL, possibly maintaining a fork of that version just as MariaDB has done.

That wouldn't really be the worst outcome, either. Well, it would be for MongoDB themselves, but to the rest of the open source community, it would mean a much less restrictive version of MongoDB would be available and maintained, which to me seems like a win.

Re: Making the GPL more scary

#115

Post by cyphar »

aequitas wrote: post #83
cyphar wrote: post #74

Earlier quoted context omitted.

It should also be noted that they require the "Service Source Code" to be provided under the terms of their license . So it's not possible for anyone to follow these restrictions even on a fully free software stack if any part of that stack is copyleft (for instance, Linux).

That was what first caught my eye as well, which would make it impossible. > The affected code must not only be released, it must be made available under the SSPL. But I think it should be interpreted that if you modify the code (mongodb) under SSPL it should be distributed under the same license, like is normal for other open source licenses.

No, while they don't have the AGPL section, the wording in section 13 is pretty clear:

> you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.

Now, this only applies if you've modified the source code. But being barred from the effective right (due to the requirement mentioned above) to use modified versions of software makes it obviously proprietary.

Re: Making the GPL more scary

#116

Post by cyphar »

weinzierl wrote: post #51

>Like Redis Labs before it, MongoDB has concluded that this license allows a bit too much. In particular, cloud providers are offering access to MongoDB instances without cutting the company in on the resulting revenue stream, and that doesn't feel right. In response, MongoDB has just announced an immediate shift to its brand-new Server Side Public License (SSPL). This paragraph conflates Redis' application of the Co…

> I see this as very much in line with the original spirit of the GPL, regardless whether MogoDB's motivation might be primarily commercial or not.

I disagree. GPL was never about relicensing other people's software. The SSPL basically requires this if you read Section 13.

> CLAs are pretty common nowadays and they can be a problem for potential contributors but pointing at MongoDB, for just doing what many other large OpenSource projects do, isn't fair.

Just because many projects do this doesn't mean it's a good thing to do -- the FSF CLA is the only CLA I would find acceptable because it's purpose is to ensure they can relicense to later GPL versions as well as have litigation rights in the US. Several other "CLAs" (like Apache's) are actually just beefed up versions of the DCO.

But unconditional and asymmetric CLAs are the reason that OpenSolaris could become proprietary under Oracle, as well as many other horror stories in the history of free software. Many people use them, but that doesn't justify it.

Re: Making the GPL more scary

#117

Post by tlrobinson »

aequitas wrote: post #59

> "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, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, al…

> I understand they want us to buy a proprietary mongo license, but I don't see how it would even be possible to run mongo as a service without.

I think that's the point...

Re: Making the GPL more scary

#118

Post by StudentStuff »

akjha wrote: post #62
StudentStuff wrote: post #50

Earlier quoted context omitted.

Yep, and I'm perfectly fine with this. If someone wants a non-copyleft branch, they can pay me to rewrite the features I didn't author, otherwise I will exclude the added code from said pull request. Its a definite edge case, but if I can get active contributors, I am not about to ask them to sign a CLA.

Keeping track of and excluding commits authored by others seems a lot of work. I am curious if you use any kind of tooling or process to make it easier.

Not yet, but I hope it becomes an issue. IMO its not bad issue to have.

Re: Making the GPL more scary

#119

Post by AsyncAwait »

brobdingnagians wrote: post #43
brobdingnagians wrote: post #32

Earlier quoted context omitted.

That's kind of the point though. BSD is truly free, and that means there are a lot of proprietary products which benefit massively from it and create worthwhile products with clear monetization strategies and thrive. Sure, they might not contribute back, but the point of the open source was often to share code to improve the state of the art and provide useful code for people so they don't have to start from scratch.…

I think most of the commenters on my post misunderstood me very much. I think people should be free to license under GPL, AGPL, SSPL, VXMPL, or whatever the heck they want. I like BSD personally, and it meets my requirements, but someone who has a different need can do what they want. I think GPL has worked well for Linux, and I'm glad they did it the way they did; I think it is less free than BSD, but in a good way…

I don't think you were misunderstood. But, I think the way you think of freedom is that one has an absolute freedom do do whatever, including infringing on other freedoms whereas others disagree.

By analogy; if one is free to rob someone, they're more free in absolute terms than they're free if they can't do that, but then the person who is about to get robbed isn't free to feel secure. So in other words, the robber is more free, but at the expense of the robbed.

In that sense, the BSD license is more absolutely/selfishly free for the individual, whereas the GPL is more freedom-perusing for the entire community.

Re: Making the GPL more scary

#120

Post by trasz »

pjmlp wrote: post #112
trasz wrote: post #111

Earlier quoted context omitted.

No - with GCC those improvements never got written, because the license used by GCC prevented it from happening in the first place. The decision whether to share the code usually happens before choosing the codebase to build upon, not the other way around.

In this specific case, Sony would have been forced to actually spend money doing a compiler from the ground up instead of cutting costs down costs while giving a few crumbs back to keep the plebe happy. What I find ironic with the current anti-GPL trend is the eventual return of the shareware model, then lets see how well the MIT/BSD folks will appreciate it.

Only if you assume the only choices were 1. using GCC or 2. writing from scratch. Thing is, this assumption obviously doesn't match reality. Absurd assumptions -> absurd conclusions.

And no, BSD has nothing to do with shareware. Shareware was never about sharing sources; meanwhile, BSD-licensed projects are fine with respect to sharing - just take a look at Postgres, LLVM, FreeBSD, X11, or Python. GPL is an attempt to protect from a threat which was never real, and by doing so it makes life harder for everyone.

Post reply on HN