Making the GPL more scary • Hacker News Board

Re: Making the GPL more scary

#101

Post by jbeard4 » Thu, Nov 01, 2018, 4:40 PM UTC

tannhaeuser wrote: post #99

jbeard4 wrote: post #90

I wonder why the RPL isn't more popular for this. It's an OSI-approved license that is meant to fix the "SAAS loophole": PREAMBLE The Reciprocal Public License (RPL) is based on the concept of reciprocity or, if you prefer, fairness. In short, this license grew out of a desire to close loopholes in previous open source licenses, loopholes that allowed parties to acquire open source software and derive financial benef…

Interesting. I guess the RPL however is as toothless as the AGPL when it comes to extend its scope to the provisioning software cloud providers use to run your AGPL-licensed software for their customers, which is the problem I believe MongoDB, Inc. wants to target.

IANAL, but I guess this comes down to the interpretation of "Required Components".

1.12 "Required Components" means any text, programs, scripts, schema, interface definitions, control files, or other works created by You which are required by a third party of average skill to successfully install and run Licensed Software containing Your Modifications, or to install and run Your Derivative Works.

You have to make the source of the required components available under the RPL (section 6.0-6.1).

Would provisioning software to operationalize a database within a cloud environment be considered a "required component"? Maybe. If the cloud provider made modifications to the db source to get it to run well inside of their cloud environment, and did it in a way that made it impossible to run the modified db outside of their cloud environment, without using their custom provisioning scripts, then I would argue that those provisioning scripts would be considered "required components" under the definition in 1.12. But if they are able to run the db without making modifications to it, so that it is the same as upstream, and a third party developer does not need the provisioning scripts to run the modified db, then the provisioning scripts would not be considered required components.

So, the RPL is perhaps stronger than the AGPL, but not strong enough for MongoDB or Redis Labs.

Re: Making the GPL more scary

#102

Post by mindcrime » Thu, Nov 01, 2018, 4:54 PM UTC

msbarnett wrote: post #94

hannob wrote: post #45

Earlier quoted context omitted.

> 1. MongoDB has the right to do whatever they like Well, no, obviously not. They have to stay within legal bounds. But of course they can have any obscure license that is legal if they want. The thing they get flak for is trying to deceive the public. > 2. This License Means More Open Source Code This license is only open source in a very obscure interpretation of the word. It's basically doing a lot of legal gymnas…

> This license is only open source in a very obscure interpretation of the word. It's "open source" in the dead-obvious meaning "the source code is open for inspection". I'd argue it's all of the extra baggage that the OSI have read into the words "open" and "source" that are considerably more obscure. Neither the word "open" nor "source" implies "free for commercial exploitation to all and sundry"

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].

Similarly, there are are de-facto terms for the "the source code is open for inspection" (but not otherwise Open Source) models: things like "Source Available"[2] and "Shared Source"[3].

People trying to muddy the waters are generally being intentionally disingenuous because they want the general goodwill and positive buzz associated with being Open Source, without actually, ya know, being Open Source.

[1]: https://opensource.org/osd-annotated

[2]: https://en.wikipedia.org/wiki/Source-available_software

[3]: https://en.wikipedia.org/wiki/Shared_Source_Initiative

Re: Making the GPL more scary

#103

Post by tomjen3 » Thu, Nov 01, 2018, 4:56 PM UTC

jbeard4 wrote: post #90

I wonder why the RPL isn't more popular for this. It's an OSI-approved license that is meant to fix the "SAAS loophole": PREAMBLE The Reciprocal Public License (RPL) is based on the concept of reciprocity or, if you prefer, fairness. In short, this license grew out of a desire to close loopholes in previous open source licenses, loopholes that allowed parties to acquire open source software and derive financial benef…

Has the requirement to share source code to other programs ever been tested in court?

For example, based on that could I release a web server and then sue anybody who wouldn't provide source code to their browser to me?

Re: Making the GPL more scary

#104

Post by binomialxenon » Thu, Nov 01, 2018, 5:15 PM UTC

msbarnett wrote: post #94

hannob wrote: post #45

Earlier quoted context omitted.

> 1. MongoDB has the right to do whatever they like Well, no, obviously not. They have to stay within legal bounds. But of course they can have any obscure license that is legal if they want. The thing they get flak for is trying to deceive the public. > 2. This License Means More Open Source Code This license is only open source in a very obscure interpretation of the word. It's basically doing a lot of legal gymnas…

> This license is only open source in a very obscure interpretation of the word. It's "open source" in the dead-obvious meaning "the source code is open for inspection". I'd argue it's all of the extra baggage that the OSI have read into the words "open" and "source" that are considerably more obscure. Neither the word "open" nor "source" implies "free for commercial exploitation to all and sundry"

This is why "Open Source" is terrible terminology for Free/Libre software.

Re: Making the GPL more scary

#105

Post by binomialxenon » Thu, Nov 01, 2018, 5:20 PM UTC

platz wrote: post #70

SSPLV2: If you want to use my software freely, you must open source every piece of software you've ever touched or been in contact with, even if you don't own it, or I get to sue you. QED

The SSPL is what Ballmer thought the GPL was.

Re: Making the GPL more scary

#106

Post by sseveran » Thu, Nov 01, 2018, 5:21 PM UTC

antirez wrote: post #95

sseveran wrote: post #79

Earlier quoted context omitted.

Individuals interpretations of this are unlikely to matter much until such a clause is tested in court. The interpretation that the license is as broad as Mr Kuhn claims may be true, but it may not be. Personally I think that both Mongo and Redis doing this is great as it shows the danger posed when a company can just relicense a project at will, which IMHO is the greater issue here. If Mongo felt the need they could…

"Redis doing this" -> Redis is BSD licensed, but Redis Labs modules that were never part of Redis itself changed license. Note btw that when something is BSD can be relicensed by everybody, both the original copyright owners or anyone else.

I have never used Redis so I cannot comment on what is in Redis vs whatever Redis Labs modules are. I did observe that when the license was changed there was much gnashing of teeth about the license change so clearly at least a subset of potential users were surprised or upset about the license change.

I do think much of conversation about license changes is missing what I think the main risk of taking a dependency on an open source project where the license can be changed by the primary contributors with little to no oversight from anyone. And indeed Oracle has demonstrated that this is an issue for software that while proprietary has been free.

It may still be the right thing to do to use Redis or MongoDB or the Oracle JVM. Users may be fine with the new licensing terms. Maybe things fork and go their own way. Maybe people wake up to the risk they actually run when signing a contributor agreement (depending on what it contains). I just think there is too little real analysis of the true risks that exist when taking a dependency on a component which might not be supported under the expected licensing terms in the future.

Re: Making the GPL more scary

#107

Post by binomialxenon » Thu, Nov 01, 2018, 5:22 PM UTC

kaddio wrote: post #41

yarrel wrote: post #24

Way to run with the anti-GPL FUD, LWN.

The GPL has more than run its course and it’s time to move on. Many people recognise that, and that’s what we’re seeing.

This is just typical "people are saying" weasel words. The GPL and similar licenses still definitely have a role to play in the current state of software.

Re: Making the GPL more scary

#108

Post by msbarnett » Thu, Nov 01, 2018, 5:34 PM UTC

mindcrime wrote: post #102

msbarnett wrote: post #94

Earlier quoted context omitted.

> This license is only open source in a very obscure interpretation of the word. It's "open source" in the dead-obvious meaning "the source code is open for inspection". I'd argue it's all of the extra baggage that the OSI have read into the words "open" and "source" that are considerably more obscure. Neither the word "open" nor "source" implies "free for commercial exploitation to all and sundry"

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]. Similarly, there are are de-facto terms for the "the source code is open for inspection" (but not otherwise Open Source) models: things like "Source Available"[2] and "Shared Source"[3]. Peopl…

> 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 intentionally disingenuous" for simply not complying with the OSI's attempt to retroactively redefine the phrase to mean something other than the conventional and obvious meaning.

[1] The OSI was formed in February of 1998. The OSD had been drafted 9 months prior, in mid 1997. If, as claimed, the meaning of the phrase "Open Source" sprung forth from the ether with the OSD, then why, pray tell, is it dead easy to find uses prior to 1997 in which people are obviously referring to the ability to see the source-code and obviously _not_ referring to the ability to exploit it commercially?

For instance, here's a post from 1993 on comp.os.ms-windows.programmer.win32 (https://groups.google.com/forum/#!msg/comp.os.ms-windows.pro...):

> If a developer wants money for shareware, paying the fee should automatically grant the user a copy of the source code for their personal use. Restrictions could prohibit modifying and redistributing binaries, but should allow distribution of "deltas" for bug fixes, etc.

> Anyone else into "Source Code for NT"? The tools and stuff I'm writing for NT will be released with source. If there are "proprietary" tricks that MS wants to hide, the only way to subvert their hoarding is to post source that illuminates (and I don't mean disclosing stuff obtained by a non-disclosure agreement). Open Source is best for everyone in the long run.

Or this email from 1996 (http://www.xent.com/FoRK-archive/fall96/0269.html):

> Caldera Announces Open Source for DOS.

> ...

> Caldera believes an open source code model benefits the industry in many ways.

> ...

> Individuals can use OpenDOS source for personal use at no cost. Individuals and organizations desiring to commercially redistribute Caldera OpenDOS must acquire a license with an associated small fee.

I guess somebody should travel back in time and tell them they're "muddying the waters and being intentionally disingenuous"?

Or maybe, just maybe, it's the OSI that muddied the waters by trying to redefine a term to add their own ideological baggage to it.

Re: Making the GPL more scary

#109

Post by PeterisP » Thu, Nov 01, 2018, 5:48 PM UTC

jchw wrote: post #21

amingilani wrote: post #9

I'm probably going to get a lot of flak for this, but here's an opinion supporting the MongoDB license. Two things: 1. MongoDB has the right to do whatever they like ------------------------------------------------------ The creator of a product: 1. Has a rational interest in maximizing their returns 2. Owns all the rights to their products (barring existing IP restrictions) And if they choose to open source their co…

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.

Re: Making the GPL more scary

#110

Post by mindcrime » Thu, Nov 01, 2018, 6:13 PM UTC

msbarnett wrote: post #108

mindcrime wrote: post #102

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]. Similarly, there are are de-facto terms for the "the source code is open for inspection" (but not otherwise Open Source) models: things like "Source Available"[2] and "Shared Source"[3]. Peopl…

> 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 to at least 2000 or so) the de-facto definition is the OSI definition. A few lone-wolf dissenters don't change that.