RethinkDB Relicensed under Apache 2.0
joyent.com
joyent.com
You can read the announcement on RethinkDB's blog to find out about the project's next steps: https://rethinkdb.com/blog/rethinkdb-joins-linux-foundation/
We've had a lot of folks ask if they can donate to support the project. Stripe has generously offered to match up to $25k in donations (which will help fund server costs and future development.) You can learn how to contribute to the project with OSS contributions or donations here: https://rethinkdb.com/contribute
Thank you for being one of the most amazing communities around :)
(I'm the former community manager btw).
Bounceback message:
Hello REDACTED,
We're writing to let you know that the group you tried to contact (oss) may not exist, or you may not have permission to post messages to the group. A few more details on why you weren't able to post:
* You might have spelled or formatted the group name incorrectly. * The owner of the group may have removed this group. * You may need to join the group before receiving permission to post. * This group may not be open to posting.
If you have questions related to this or any other Google Group, visit the Help Center at https://support.google.com/a/rethinkdb.com/bin/topic.py?topi....
Thanks,
rethinkdb.com admins
You can also always reach out to me directly: mike [.at] rethinkdb . com
One thing to note, this was not an easy process; our team has spent months working daily on a solution. This was definitely our Plan A result, but we never expected LF to step up and provide the sponsorship funding as well. Huge thanks to LF/CNCF for helping close things in the end!
If you use RethinkDB please make sure to give a leadership member a hug if you happen to be in SF/NYC/Nashville/Philly/etc.
We used PostgreSQL before and while excellent on a single node it's deeply painful to cluster. You need a full time DBA to make sure you're doing it right, as GitLab discovered, and when it fails it gives error messages that seem more cryptic than C++ template errors. Amazon RDS was insanely pricey compared to bare metal (our load is both CPU-bound and disk-IO-heavy bare metal on OVH is >10X cheaper than Amazon) and Redshift didn't have pgsql syntax yet. Even now that it does I'm not sure I want to be bound to it as I have an instinctive aversion to cloud lock-in.
I think the big thing for us is that everything about RethinkDB screams quality from a technical POV. It's powerful but not over-engineered. The code is pretty clean looking. It "just works" without hiding wads of chewing gum and duct tape in Docker containers or requiring 10-step setup processes. When you do bang on it ChaosMonkey-style it holds up very well.
Some instances of people asking about GNU Affero GPLv3 and RethinkDB:
(2014-11-16) https://github.com/rethinkdb/rethinkdb/issues/3347
(2015-06-16) https://groups.google.com/forum/#!topic/rethinkdb/g5UEck3sqM...
(2016-10-10) https://sagemath.blogspot.com/2016/10/rethinkdb-must-relicen...
(2017-01-09) https://github.com/rethinkdb/rethinkdb/issues/6221
http://lists.openstack.org/pipermail/openstack-dev/2014-Marc...
For the record, I personally think that this is 100% pure FUD (the thinking behind it is described as "preposterous" later in the thread). Nevertheless, if someone with the title of "Sr. Director Of Open Source, Open Standards" at a company the size of Yahoo can buy in to this FUD, then most smaller companies have no chance of distinguishing between fact and fantasy, and many will steer clear as a precaution.
I realize every hacker on the planet feels that they have the finer points of AGPL interpretation under firm mastery and are in a position to explain contract and licensing law to lawyers, but a vast number of lawyers at the large shops have looked at AGPL now and advised caution in dealing with it nearly across the board. If you want to characterize that as "unfounded doubt" (which I've translated to FUD for you instead of pressing you on what "unfounded" means without precedent), you're not technically wrong, but it polarizes what is otherwise a reasonable position of uncertainty on a significant amount of corporate risk. There are people who spend their entire lives managing risk, and hackers are very quick to dismiss such concerns -- even beyond AGPL, a number of various risks could rapidly unravel an entire corporation, and I'm often in conversations where the solution seems obvious to an engineer.
The term FUD itself is dangerous, because very often uncertainty is a perfectly valid approach to a legal problem such as licensing. Belittling uncertainty by equating it to fear creates the flawed impression that we should all act rashly all the time. Sometimes caution is good, even if it's the other side of a debate you feel passionately about, and polarizing it will not help you win over the cautious folks. Understanding their concerns and meeting them at the table will go much further.
Knocking open source groups at large shops with scare quotes like that is a bit weird, too. So Yahoo! starts an open source team, speaks openly about their thinking around licenses, generally invests a lot of thinking in license compliance and how to contribute back (Yahoo! is one of the bigger contributors to FOSS that I can think of -- hello, Hadoop?), and then after all that, free software advocates make comments like this one and cast some aspect of the work as hostile to free software. That seems self-defeating to me and I wish this whole conversation were less polarized, given that most companies don't even have an "Open Source Intern."
This is not uncommon in the industry. To preempt that this attitude entails a hatred of free software or GPL-style licenses, I should point out that the same legal teams often approve GPLv3 software (which can be equally contentious).
Although I wanted to use RethinkDB for new stuff I was very hesitant to introduce a probably discontinued product. Using a Linux product with Apache 2 instead makes the decision to introduce RethinkDB much easier.
Is somebody already working on a operator for kubernetes like coreos did for etcd [1]? What is your recommended kubernetes deployment for RethinkDB?
I use RethinkDB with Kubernetes in production using the above project and have been very happy.
Ross, the project creator, is also a RethinkDB leadership member and is stellar at responding to any questions concerning the project.
We felt that it was too important to let the work we created have a life of its own and establish its own life in the open-source community. It's wonderful to see this finally happen.
We also briefly had a closed-source version of RethinkDB that has a few useful features for larger teams: we're excited to be able to merge these back into the project.
https://github.com/rethinkdb/rethinkdb/commit/b0ec8bc5a874d5...
https://www.cncf.io/blog/2017/02/06/cncf-purchases-rethinkdb...
My concern has been that there's a few missing features in rethinkdb - I want to be able to resume query after a client gets disconnected without re-downloading the result set. (If the data hasn't changed) and I want deeper integration with rethinkdb's versioning system. But I've been too nervous about making those changes myself and build on top of rethinkdb because of license taint. Now this has all been solved. Its starting to look like a good time to crack open the code and submit some patches! Thanks everyone who's made this happen!
(I'm the CNCF executive director.)
At least they only specified the one font-family and fallback (without helvetica/arial, like a sane person)
The AGPL is just an updated GPL. Back when software mostly came in boxes, the GPL was as feared as the AGPL is now. Now that software mostly comes from the internet, the AGPL is there to address this new distribution method. Now the AGPL is the new cancer.
Overzealous lawyers trying to "protect" copyrights have indoctrinated an entire generation of hackers that sharing code is a danger and the AGPL is the prime threat. I have spoken to too many Apple, Microsoft, Facebook, or Google employees that are convinced that sharing their source code would be tantamount to death. The result is a world where their secret software controls the news we read, the ads we see, the people we talk to, and even the emotions we feel.
"Open source, but licensed under the AGPL.", says the article. There is no "but" here. The AGPL is the very definition of "open source", because it defends openness. If you have nothing to fear from open source, you have nothing to fear from the AGPL.
> The AGPL is just an updated GPL.
The AGPL is significantly more than an updated GPL and there are loads of companies which have a blanket policy in place to not even get anywhere close to AGPL code because of the uncertainties about how it actually works.
> The AGPL is the very definition of "open source", because it defends openness.
Maybe it's the definition of free software but it's definitely not the definition of open source. Many of us in the open source community see our work as something that should be open for everybody to use.
AGPL is an open source license, according to OSI, the only authority on what constitutes open source. https://opensource.org/licenses/AGPL-3.0
You say "open for everybody to use". Both open source licenses and free/libre licences guarantee that the software is open for use. You're actually talking about freedom to combine with closed source/proprietary software, not about end-users freedom to use the software.
That is true, but "frog" is still definitely not the definition of "animal", even though a frog is an animal.
The red-eyed tree frog [1] is an animal, but it is a noncentral example of an animal, i.e., it is not the typical thing you think of when you think "animal". To the_mitsuhiko, the AGPL is a noncentral example of an open source license.
The term comes from the noncentral fallacy [2], which is about abusing noncentral examples.
[1] https://en.wikipedia.org/wiki/Agalychnis_callidryas
[2] http://lesswrong.com/lw/e95/the_noncentral_fallacy_the_worst...
This is an interesting example for the difference between "reading by the word" and "reading by the meaning" (there's not a good English word for this, but in Germany we call this "sinnentnehmendes Lesen".)
I also believe it makes sense. Perhaps i can restate it. the_mitsuhiko made five assertions:
1. The AGPL is not just an updated GPL, but expands the scope of the GPL's 'infective' property considerably.
2. Some people are uncertain about what exactly the consequences of using AGPL'd software are.
3. Because of this uncertainty, there are companies which will not use AGPL'd software.
4. The AGPL is an open source license, but it is neither the only nor the most representative open source license.
5. Some people wish to license their software in a way which maximises the number of people who can use it. That means not using the AGPL, because of point 3.
Or freedom to combine with software using any other non-copyleft, open source license.
Which non-copyleft OSI-approved license are you having difficulty combing with AGPL?
Well, sure, but 10th- and 16th-most common (1% and <1%, respectively) isn't actually very common at all[0]. Which applies to the AGPL as well.
The potential for conflict between EPL and AGPL, or CDDL and AGPL, code in projects is tiny.
For that matter, the GPL was around first, and is the 2nd most popular license. Shouldn't the EPL and CDDL have been modified to be GPL compatible (the Apache Software Foundation managed to work this out with the FSF, over the Apache v2.0 and GPL v3.0 licenses, after all[1]).
[0] https://www.blackducksoftware.com/top-open-source-licenses
[1] http://www.informationweek.com/enterprise/apache-foundation-...
But that "to combine" is exactly "to use", especially if it is a software library.
The developer who wants to combine with closed source can contact us and work out a special deal. It's only fair. They want to be compensated for spending their time, then so do we.
I don't know of anyone using agpl'd code to build software people use.
> For example, imagine Digital Ocean using MongoDB to store server configurations. AGPL would force them to open-source their whole infrastructure. All of it. Or pay to get a different license.
AGPL licenses aren't transitive, things that touch AGPL'ed software over the network aren't suddenly required to be AGPL licensed (otherwise the whole purpose of it would fall apart, since a large chunk of the initial design was for Free Software web-applications which could still be run in proprietary web browsers).
AGPL means if you decide to fork a project and add new features, then sell it as a hosted service ala AWS/Azure then you also have to provide anyone that connects to it your modified source code. I'm actually debating using the license right now in a couple of projects I've been prototyping - I don't want to prevent people from being able to make money offering hosted services, but at the same time I don't want hostile SaaS forks that could rip off my work without contributing their changes back (I like the BSD license for libraries, but I'm starting to appreciate the GPL/AGPL more for applications for community-related reasons rather than free software righteousness).
That is not necessarily true in the case of the database due to how the drivers work. This would need to be tested in court. It's unclear by the license terms alone.
> 13. Remote Network Interaction; Use with the GNU General Public License. > > Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph. > > Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.
Users interacting with the modified program over the network have a right to access the modified source, there's absolutely nothing about the client software (database drivers, web browsers, etc) accessing it being considered part of a combined work. You can access a AGPL licensed database or whatever from a proprietary application with absolutely no issue, you just can't modify the AGPL'ed work, expose it to users other than yourself, and not share your modifications.
Do yourself a favor, grab https://www.gnu.org/licenses/gpl-3.0.txt and https://www.gnu.org/licenses/agpl-3.0.txt and run `diff` on them, this is literally the only substantive difference in the entire license text.
No, but there is a definition of corresponding source which includes code beyond the direct scope of the AGPL in case of mongodb: "Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work."
This is one point of contention that was brought up by multiple people in the past because it puts client libraries into the scope.
Literally the only delta between the GPL and AGPL is the Remote Network Interaction section, it doesn't extend the reach of the GPL license in regards to database drivers, etc.
https://github.com/mongodb/mongo-c-driver/blob/master/COPYIN...
[they] violate their own license
The worry with RethinkDB was (at least mine and people I talked to) that it can become a liability if the AGPL turns out to be an issue since some third party owns the original copyright and then who knows what happens with future contributions.
For example, imagine Digital Ocean using MongoDB to store server configurations. AGPL would force them to open-source their whole infrastructure. All of it. Or pay to get a different license.
I don't have a moral argument to make here -- just making sure people realize the actual trade-offs. AGPL is theoretically for a world where closed source software is simply not allowed to co-exist with opensource, even if you don't distribute it, but simply run it / host it / use it. But that world doesn't exist, so it does the opposite: it is actually used to make sure some of your users have to pay. It enables a business model.
I don't think that's correct. From MongoDB the company[0]:
> Note however that it is NOT required that applications using mongo be published. The copyleft applies only to the mongod and mongos database programs. This is why Mongo DB drivers are all licensed under an Apache license. You application, even though it talks to the database, is a separate program and “work”.
Citation needed.
Just because a license says something does not mean that everybody interprets it the same way or that the clauses are valid in it. The "Remote Network Interaction" section has never made it to court and there are countless different interpretations one can draw from this.
Precondition: Take a GNU Affero GPv3 product, modify it, and expose it over a network, directly or by proxy, over a network, for users to use.
Your four possibilities:
(1) If you provide source, and the courts uphold the 'Remote Network Interaction' clause: you're fine.
(2) If you don't provide source, and the courts uphold the 'Remote Network Interaction' clause: you're screwed.
(3) If you provide source, and the courts don't uphold the 'Remote Network Interaction' clause: you're fine, but you would've been fine not providing the code in retrospect.
(4) If you don't provide source, and the courts don't uphold the 'Remote Network Interaction' clause: you've defeated the GNU Affero GPLv3 in court.
You can absolutely make the argument for or against the business risks of releasing source code, but you can't make the argument for 'uncertainty'.
If I take some caching algorithm from RethinkDB and put it in my fork of OpenSSL, do I have to make it possible for everyone who connects to my SSL server to download the source of my fork? Do I need to start stuffing the URL of corresponding source into my certificate?
I'd hope the answer is no, but what in the license makes it clear that the answer is no?
As the AGPL hasn't been tested in court, we're all mostly guessing.
I'm curious as to why. The GPL has manifestly built the modern internet (cloud servers are mostly Linux, most IT startups use Linux, etc.)
There are other open source licences which are also widely used (Apache, BSD, MIT). So I think the key thing to this wide-spread success is open source in general, and not the license in particular.
Would you say that the GPL is negative? I.e. would we have been better off of Linux was BSD licenses? If so, why? If not, why be against the GPL?
For the most part it does not matter if Linux is GPL or not because GPL functions very differently for operating systems than for libraries and applications. However the GPL is causing issues for Linux as well and there are some ongoing lawsuits involving the GPL in the context of the Linux Kernel which will be interesting to see.
I do not know what a world looks like where the GPL does not exist so I won't judge that. The GPL was and is amazing to help the Open Source movement however it's becoming less and less relevant for new projects.
> why be against the GPL?
It's a very complicated license, impossible to evolve and means that you can build something that you cannot ship on another platform because that platform is GPL incompatible. For instance you will never see GPLv3 code running on iOS because you just can't have it there. The mechanics of the license are very complex and I do not agree with the "force people to contribute" approach. Good contributions come anyways, the bad ones I do not care. If someone wants to fuck over a license holder over they can do it regardless (for instance by providing close to unreadable GPL code :)
That would be a case against iOS, take it up with the masters of your walled garden.
That is hard to say. Some contributors only contribute to GPL projects, since they want that derivative works of their work to stay open-sourced. I think they should have a right to require that.
Even though I personally believe in open sourcing everything possible, when all else is equal, I would always choose something that isn't copyleft over something that is. Because I shouldn't really have to be bothered by copyright infringement concerns when using open source software.
It's most free for end users.
But if we're talking about tools for a developer audience--like RethinkDB, and frankly a whole lot of other open source software--then developers are the end users, and so the license really does matter. I've long thought that one of the strengths of the GPL is that it's more restrictive from a developer standpoint, rather than less. If I was trying to build a company around open source software, the (A)GPL would be attractive expressly because it makes it more difficult for competitors to build on. If the company goes away and there's no way for someone to buy a commercial license with a different set of restrictions, that can become an issue, as we've seen with RethinkDB -- but the (A)GPL isn't necessarily an impediment to strong community development, as we've seen with, well, a lot of other software over the last two decades.
Nah, it's not that simple.
Ever saw a giant chorus singing "oh almighty developers please make this and that" for tiny features? I think every other product support forum is just like that. And I also saw situations when someone on the outside had hacked features that weren't provided by original developers. Both free software projects and proprietary software.
So freedoms actually matter to the "common folk", they just don't consciously recognize that and surely they don't know the terminology.
While I accept that the OSI definition of "open source" is pretty much universally accepted and probably isn't going to change, I personally don't really feel like copyleft should qualify because of that level of control it exerts.
So, a fair amount of the opposition to using AGPL software isn't based on some deep rooted belief that's it's somehow evil or a cancer. Just a reasonable belief that using APGL software internally might open up unreasonable risk.
I would think that the FSF would be okay with that. Companies that are unwilling to comply with the AGPL avoiding it entirely, versus using APGL software and not abiding by the license. There are certainly companies that contribute back to open source, but only for a subset of the available open source licenses.
My two cents:
The irony is that the GPL was meant to protect users' freedom, and cloud services are a giant unforeseen loophole in the GPL that is even more abusive of user freedoms than old school proprietary software (NSA, ad trackers, forced upgrades, censorship, mass deletions, etc).
There is more money in closed source centralized services, and the FSF was afraid to stand up for the principles it was founded on.
I hope the industry eventually rebuilds itself on the AGPL (and BSL + AGPL for active, commercially developed stuff), but the fight will be at least as hard as mainstreaming the gpl was.
That's not the worry about the AGPL. It's clearly a valid license; nobody is claiming otherwise. The worry is that it's too valid, and nobody has defined exactly what interacting with it over the network means. If I run a public-facing, auth-requiring RethinkDB server, am I obligated to make source available to anyone who connects to it? If my build system sucks (and most build systems do suck), am I legally liable for not providing a working build script that a third party can use, even if every patch I have is in a public bugtracker?
The lawyers who worry about the AGPL aren't lawyers who worry about FOSS in general, as was the case with the GPL. These are lawyers who encourage use of GPL software, who usually oversee release of code under the GPL, etc. The AGPL is different, or at least is seen differently by lawyers who accept every other OSI-approved license. Calling it "just an updated GPL" may well be ideologically true, but it makes it difficult to address the actual objection to the AGPL that's not an objection to the GPL.
We know, now, that we have "nothing to fear" from open source, but also that commercial software companies should care about the difference between e.g. simple permissive licenses and the GPL. The entire iOS app ecosystem, for instance, runs on a rich community of MIT/BSD-licensed libraries. Nobody "fears" the GPL, but everyone knows not to use it.
In the same way, it's entirely reasonable for organizations to determine that for a specific use case, both simple permissive licenses and GPL-style licenses are fine, but AGPL-style ones aren't.
Yes, that is precisely what the AGPL means. If you have some proprietary web application that is the user of RethinkDB that your users connect to instead, then no, since the modifications are only used internally by you.
The goal here is to prevent SaaS-ification of AGPL'ed applications, if you host an application under the license and make it available to others you can't hide your changes just because the users aren't directly installing the binaries.
> If my build system sucks (and most build systems do suck), am I legally liable for not providing a working build script that a third party can use, even if every patch I have is in a public bugtracker?
The A/GPL does require you provide the neccesary tooling or instructions to build the source, so, yes.
> In the same way, it's entirely reasonable for organizations to determine that for a specific use case, both simple permissive licenses and GPL-style licenses are fine, but AGPL-style ones aren't.
If you're trying to make money off the backs of GPL'ed software by making modifications to it and then throwing it behind a service so you don't technically have to redistribute your changes then, yes, you should be wary of the AGPL. You should also feel ashamed of yourself.
That being said, there's some projects licensed under the AGPL that have given me pause, like GhostScript. I've had to yank that out of projects, because even though they are used internally-only, we are linking to the code which means the project as a whole becomes AGPL licensed. Things like MongoDB/RethinkDB are non-issues since they are only being accessed over the network, the client can be licensed under whatever they damn well want.
For the auth-requiring RethinkDB server, am I obligated to provide source to the entire internet because everyone can connect to it?
> The A/GPL does require you provide the neccesary tooling or instructions to build the source, so, yes.
The GPL does not require me to provide build tooling / instructions to people who merely use the product, only recipients of the built code. If I don't distribute it, I'm not obligated to do a good job with my build tooling.
If I port RethinkDB to some proprietary OS where I'm not allowed to redistribute the build tooling, am I effectively forbidden from running it in a public-facing way?
Does that conflict with "the freedom to run the program as you wish, for any purpose"?
I'm fine with being ashamed. None of the four freedoms, none of the requirements of the open source definition, require me not to be ashamed. I'm fine with assuaging my shame by donating money or resources as needed. But the AGPL seems to be constraining my technical decision-making by saying that I either have to put non-AGPL layers in front of AGPL code or I have to use a good-quality, free software build toolchain.
Anyone who can use it must be granted the source. Whether the ability to open a socket connection counts or not is up for debate. Note, the GPL doesn't require you provide the sources gratis, you can charge reasonable cost of distribution so you aren't eating the bandwidth bill. You could also just provide a link to your github repository.
> The GPL does not require me to provide build tooling / instructions to people who merely use the product, only recipients of the built code. If I don't distribute it, I'm not obligated to do a good job with my build tooling. > > If I port RethinkDB to some proprietary OS where I'm not allowed to redistribute the build tooling, am I effectively forbidden from running it in a public-facing way?
With the AGPL users are effectively recipients of the built code. So, yes, if you are unable to provide your build scripts (note, the tools you call to build do not have to be open source, but the instructions/scripts used to build must be) then you are forbidden from using the product.
> Does that conflict with "the freedom to run the program as you wish, for any purpose"?
The A/GPL is designed to protect the freedoms of users, the AGPL changes the definition of user from "the person executing the binary" to "the person interacting with the software". The change of this definition doesn't conflict with that, it clarifies the intent of this freedom when a project chooses the AGPL over the traditional GPL license.
There are reasons that's good (in theory, users will have more control over their own computing), but also reasons that's bad (you don't get economies of scale, you don't get someone dealing with security updates for you, you probably have to pay more, etc.).
And it seems to me that if we want to encourage designing systems a certain way, a legal document is probably not the tool for it. I think it'd be much better for free software if we spent time building tooling for non-AGPL software to serve its own complete corresponding source by default.
Why would it? The AGPL isn't designed to disincentive people from providing hosted services based on a particular piece of software, but to ensure those that do it can't make proprietary modifications that break the spirit of the GPL while technically being in compliance.
You aren't asked to do anything beyond what the GPL already requires, it just defines that users accessing the covered software over the network have the same freedoms as those who instally it locally do.
> There are reasons that's good (in theory, users will have more control over their own computing), but also reasons that's bad (you don't get economies of scale, you don't get someone dealing with security updates for you, you probably have to pay more, etc.).
Again, the AGPL doesn't impair any of these. The only addition to the GPL is you can't turn a GPL'ed program or binary into a "service" and bypass the spirit of the GPL while still being in technical compliance.
Sure, if what you want your differentiation to be is proprietary value-added features then you're going to be in a sore spot - but again, that's breaking the spirit of the license.
> And it seems to me that if we want to encourage designing systems a certain way, a legal document is probably not the tool for it. I think it'd be much better for free software if we spent time building tooling for non-AGPL software to serve its own complete corresponding source by default.
Put it up on github and link to it, it's as simple as that. The GPL and the AGPL don't have overly strict requirements on how the source code is distributed, only that you must make it available. Most AGPL'ed web applications I've seen provide a link in their footer to the source code, if you modify the source you must provide your users a way to gain access to your modifications.
As a note: I'm not some cultist that blindly follows the FSF. I usually prefer BSD/MIT licenses in anything I work on, but as someone who is looking at starting some projects that could potentially be SaaS-ified the AGPL is a very appealing choice in some ways - applications and libraries have different licensing requirements in my eyes, when it comes to a library I just want people to be able to not re-invent the wheel, when it comes to applications I want users of the software and the community around it to not be at risk of a proprietary vendor destroying the community.
In particular, if I have custom patches to RethinkDB, I submit them all upstream, and I'm using some awful in-house build system because that's how everything is required to work at my company, I'm obligated to release the build system, even if any discrepancy between my awful in-house build system and the upstream one is a bug on my end. The one that's actually live is the corresponding source.
In theory this is good, because it means that if my awful in-house build system is, say, picking up some patched high-performance library, I'm obligated to distribute that library too.
In practice, that's much less likely to happen than just not having a great build system that does the same thing as the upstream build process, just worse. A legal obligation to have good build tooling is a weird barrier.
You use a 1000 line shell script to do a bunch of shit, that's fine, there's no requirement in the GPL that it has to be "./configure && make && make install" - just that you provide the accompanying scripts used to build the software.
This shouldn't be hard, you shouldn't make it hard on yourself or developers working on your project to create a local build. I honestly don't even see the issue.
Releasing this script would involve releasing a ton of metadata about everything anyone at the company works on.
I have my differences of opinions with our build infrastructure rather frequently, as it happens, but I think it makes it easier to create a local build; you don't have to learn n different build systems for n different upstream projects. But it's a local build designed for developers who are my co-workers, not for the general public.
Again, this isn't hard.
When I built the Qbix Platform[1] my vision was to re-decentralize the social web. Like Wordpress but to disrupt walled gardens of Facebook, Google+, etc.
I envisioned a community of developers freely building apps on this platform and organizations installing them like Wordpress.
Thus I wanted to open source it. But our company was funded by investors and we had big dreams of being the main supplier of our software.
We didn't want to put it out there and have it be immediately forked and taken away from us by Facebook or Google, who would then roll it out to all their users.
I wanted a way to all indie developers be free to develop and contribute to the long tail of apps on this platform. While at the same time not giving a free gift to the giant corporations who I felt could abuse it and take it over, like they have done with so many other things.
I met with Eben Moglen, lawyer for the FSF. The meeting was quite strange. But in the end he answered my main question:
"Use the AGPL. The corporate giants have policies not to touch it with a thirty foot pole."
So that's what the default license is for our platform today.
When our ecosystem is large enough, we may change it. But for now, free software is good. It is why linux runs on toasters. It is why wikipedia has more articles than any private encylopedia. If only medical breakthroughs were developed this way.
In the past MongoDB has argued that using their AGPL database without providing source code is fine, Neo4j has argued the opposite. As strictly interpreted it seems like as long as you don't expose the AGPL app to end users you're not in violation. Maybe the license authors intended this, maybe they intended "if you use an AGPL application that in any way affects an end user's interaction, you must provide the source to that end user."
Modification is defined exactly the same in the AGPL as in the GPL. I don't think putting a reverse proxy in front of an AGPL app means much of anything in terms of either the letter or the spirit of the license.
Mongo's separation of Apache-licensed drivers from the server is about making it so that applications don't have to link to the AGPL'd server code, thereby avoiding "modifying" it. Without a modification, the network interaction section isn't triggered at all.
Still, my main point was that the route taken by Mongo is intended to remove this kind of uncertainty: normal applications using it don't modify or include any AGPL code, so the question of just how far "remote interaction" goes never comes up.
They must've heard about the problem. Why won't they make a statement about intended reading of AGPLv3 and publish AGPLv4 that has improved wording that avoids any possible ambiguities?
why FSF isn't stepping up and resolving this issue once and for good?
Sure, they could change the wording, but unless there's a court verdict to establish precedent, there will always be ambiguity.
To put it in other words, clarifying won't hurt, even if it could have no real effect.
But, yeah, the real way to fix is AGPLv4. And FSF surely can do this.
Why would this be the case? FreeBSD and SVN were developed without copyleft. GPL is not necessary to get people to contribute to open source.
It wasn't, so they weren't and didn't.
In which case I think it's somewhat (if not completely) misleading to say that "FreeBSD ... [was] developed without copyleft.".
People use it; but it seems the majority of people using it aren't actually contributing to the community; they're just also offering commercial licensing; that is to say, it's commercially recognized as so restrictive it is an effective tool to make people pay for your software.
The FSF enforces the GPL to 'ensure that free software distributors respect their obligations to pass on the freedom to all users, to share, study and modify the code.'
...but when your tools are used to drive commercial decisions and people are paying you for compliance, you're not facilitating free software any more; you're just another pay-for-subscription vendor.
How does it do that?
Speaking from personal experience, there are multiple companies making tens of millions a year from selling products based on my GPL'd software. In every case, they have additional proprietary work in addition to the GPLd software that makes a "product", and not just a "tar.gz" download.
There are companies offering free downloads of GPLd versions of their software, and paid downloads of their proprietary software.
And nothing forces a company to use GPL software. If they don't like the GPL license on my software, they're free to write their own, or find a BSD licensed replacement.
A lot of the anti-GPL complaints I've seen amount to "I can see the software, but I can't use it under terms of my choosing, so I'm mad at the authors for choosing a 'bad' license." Which seems to be the case here.
Free. Software.
Not 'make life easier for some people who use GPL software'.
Not 'enforce GPL license agreements'.
Not 'prevent some people from using some software unless they agree to some license'.
Free. Software.
That is, software you are free to modify, change or use, without restriction and without having to pay for it.
People who are 'pro-GPL' pull out all of these crazy business reasons about competitive advantages and changing the way people do things to encourage commercial entities to contribute to open source and be good community members; but I've come to the conclusion it's all a load of rubbish.
I believe in free software, and I'm happy to make my software free.
...but the GPL isnt free and doesn't support the community.
So... if you use it, and like it... go for it; but community is important, and I, for one, have gone from zero interest in rethinkDB to be interested in using it and being a contributor.
So; take what I said worth a grain of salt; but the anti-GPL people out there aren't all business people angry they can't make their LOB apps with an AGPL dependency; there are also people, like me, who care about free software, and think that the GPL harms the community and actively discourages community contributions.
THAT, is a failure for the FSF.
The FSF has a different definition of "free software". They don't want you to get software for free, and then modify it, turn around and restrict it's distribution for other people.
> there are also people, like me, who care about free software, and think that the GPL harms the community and actively discourages community contributions.
The only proof you've shown is that people like you don't like the GPL. That's all well and good as a personal opinion, but it doesn't show that the GPL harms the community or actively discourages community contributions.
They don't want you to do that, but their definition of "free software" doesn't exclude licenses that allow it.
> Free. Software.
The name suggests that, but the substance of their advocacy and actions suggests something slightly different; their goal is not to promote Free software, instead, it is to fight against non-Free software.
Which is why they generally argue that licenses which they recognize as Free but which allow non-Free derivatives are dangerous: more Free software is not their goal, less non-Free software is the goal.
...and open source developers using every other license there is.
Can you make a counter-argument to this? Let's even just focus on Facebook and Google core's core offerings: What benefit would Google get from open sourcing their indexer, ranking algorithms, and core search software? What benefit would Facebook get from doing the same with their ad-matching and timeline/recommendation software?
claim: "source code is [not necessarily] tantamount to death"
you provide several counterexamples where (it seems) you think it would be tantamount to death.
But regardless of your number of examples, there only needs to be one case where it's not tantamount to death for the author's point to be valid.
If you want the project to be openly collabrative but quasi-free, calling it Open Source would be hijacking the term. Call it Social Justice Licence or something.
I've used rethinkdb quite a bit and I was wondering if anything thinks its suitable for time series data?