Hey everyone, thanks to the rest of the RethinkDB leadership team and the CNCF for their hard work! This wouldn't have been possible without a lot of effort from our dedicated community.
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
I'd like to point out that the OP of this comment is Mike the RethinkDB co-founder. While the company may have perished, his spirit for the project only got larger. Everyone buy Mike a beer.
Don't use it, never have. Sent a coffee anyway just to say thanks! Thanks for caring and thanks for releasing under a license that allows all to use it!
That announcement post now has its own thread: https://news.ycombinator.com/item?id=13581375. Normally, of course, we wouldn't have two threads so closely related on the front page, but the topics do seem distinct in this case and they're both pretty major.
Thanks for doing that! I think that these topics are indeed distinct, and it's important that once people see the news, they see the leadership's plan for RethinkDB. I've been really impressed with RethinkDB's leadership through this arduous (and often uncertain) process, and really looking forward to seeing where they and the community take the project!
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.
RethinkDB leadership member here: happy to answer any questions for the next hour or so.
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.
Feeling good about our decision to stick with it for our core infrastructure's next incarnation. Still very sad that they didn't make it as a company. We would have paid. RethinkDB is an unbelievable technology: better under the hood and IMHO easier to use than MongoDB, and combining NoSQL with some SQL-like features that for us are good enough. The rough edges we've found so far are minor.
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.
Yeah the change feed feature is beautiful too. It's not what sold us but once we had it it made making everything real-time almost trivial.
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.
The GNU Affero GPLv3 has been a recurring topic during RethinkDB's existence, but I cannot substantiate the same having been an issue for MongoDB. Links appreciated.
Some instances of people asking about GNU Affero GPLv3 and RethinkDB:
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.
Unfortunately, it's neither new nor surprising that a director of "Open Source" at a large company would be spreading unfounded doubt about a strongly copyleft free software license. It is ultimately against their employer's interests to be compelled to publish their modifications.
If you're playing the incentive game, you missed the obvious one: the AGPL remains completely untested in court (unlike the other one) and "FUD" is a sensible approach to managing corporate risk in the absence of established precedent. There is a lot of uncertainty about how far the AGPL's requirements will go if the license is pressed in court, and how much of a vendor's proprietary code will be "threatened" (I know this term is loaded, but think from the perspective of the lawyers).
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."
No, because there's never been a ruling on legal interpretation of some significant clauses in the AGPL, some of which can create unexpected exposure of IP in unkind interpretations. You are correct in that people licensing under the AGPL are entering into what they feel is their interpretation, but a conflict over the terms of the license has not yet been decided impartially, meaning there is still uncertainty over how such a conflict would play out if pushed. Even for most companies with a progressive FOSS policy there is still a vast ocean of proprietary code and systems, and many companies (including both large companies who have studied the issue in my own career) have decided the uncertainty of that IP exposure is enough to forbid usage of AGPL software in totality.
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).
It only recently became a big issue because in MongoDB land, you can purchase an alternative license from the company, from what I understand. In RethinkDB's case, we lost that as soon as the company shut down.
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?
To add to that: one of the great consequences of this change is that a large amount of RethinkDB source code that was previously unavailable as open-source code (including some unreleased features for RethinkDB, copious amounts of artwork and content, and build / performance scripts) will now also be steadily open-sourced.
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.
Some of the code and content was heavily used internally, but we never invested time to properly package it for public consumption.
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.
Yes this is currently in the works; going from AGPL -> ASLv2 is not as simple as a Github PR, but we should hopefully resolve it in the next week or two.
There were some interesting conversations on GitHub during past few months. In the end, everything is in it's place, I am really glad to see RethinkDB standing a chance on their own as an open source project!
This is very exciting. We've been using RethinkDB in production at Lumi for the past two years and it's been nothing short of perfect. The prospect of switching has been a nagging dread, but the continued pace of positive announcements is reassuring. We've been contributing back in small ways here and there, but plan to do so more actively now.
This is fantastic! I'm working on a little piece of fun realtime streaming database tech, and up until now I thought I'd have to implement my own realtime querying piece. Being able to lean on rethinkdb will make the whole thing way easier to implement, and provide a better experience for my users.
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!
FWIW, I would also love to be able to resume queries. For the moment I redownload the initial data, which is suboptimal (though honestly performance hasn't been a problem yet).
A work on the colours of this page: IDK if it's me only but light-grey font on white background stabs my eyes, I can't even look at it. Why is this a la mode now? Why go lighter than, say, #333 for text that's meant to be read?
Pages like this I end up having to select the text to invert it and make it readable. It works, but doesn't give feedback to the author that their color choice is a bit broken...
I think GPL did make sense before, but APL make more sense now. I do not fully understand APL though, but it seems, like with MIT, there can be hostile forks, where a competitor takes not only the code, but also the community and the business.
It's great to see commercial bodies as well as CNCF not only take interest in these sorts of things but actually push them forward for the benefit of all.
Thanks, though note that the CNCF (and our parent, the Linux Foundation) are actually a 501(c)(6) non-profit. Most of our funding comes from corporate members, though. https://www.cncf.io/about/members
OT: Man, that font is way too thin and hard to read... really wish the weight were closer to 500 instead of 300 (injected a style into head to make more readable for me).
At least they only specified the one font-family and fallback (without helvetica/arial, like a sane person)
This really bugs me. Copyleft has always been feared by lawyers and corporate people alike. Let's not forget how Ballmer called the GPL a cancer that infects everything it touches. Yet, copyleft is our only defense against abusive proprietary software and without copyleft we might not have the fertile collaboration of projects such as Linux, git, or OpenWrt.
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.
I'm very outspoken against the GPL so take this comment with a grain of salt.
> 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.
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.
You're not contradicting the_mitsuhiko. They said "it's definitely not the definition of open source". You answered "AGPL is an open source license, according to OSI".
That is true, but "frog" is still definitely not the definition of "animal", even though a frog is an animal.
A useful term to describe what it seems to me that the_mitsuhiko means is "noncentral example".
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.
I don't think your interpretation of the_mitsuhiko's words does reflect what was meant. Because if it was, the comment of the_mitsuhiko as a whole wouldn't make sense.
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 read the_mitsuhiko's comment with the same interpretation as Doctor_Fegg, and, as a native English speaker, i believe that this is the natural interpretation.
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.
I believe the English-language term is "letter of the law" for literal interpretations and "spirit of the law" for interpretations based on what something is meant to do.
When is the last time you looked at the OSI approved license list? Of the most common licenses the EPL and CDDL licenses are incompatible with GPL (I suspect it's similar for the AGPL since it's a modified GPL license). When you look through the full list you will see a lot more. Basically read https://www.gnu.org/licenses/license-list.en.html#GPLIncompa... and see all the free software licenses that are incompatible with the GPL. Most of those are OSI approved.
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]).
"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"
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.
> 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).
> 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).
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.
Note that MongoDB clarified their understanding of AGPL in no uncertain terms [0] so they would have trouble dragging someone who developed apps using their DB to court and demanding opensourcing of the app. Without such clarification from their side we would never have touched MongoDB.
That's why I said in the past that the AGPL was not a huge concern for as long as a commercial entity stands behind RethinkDB. Once that broke away who knows what individual contributors think of what the AGPL means (let alone a judge).
> 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.
> 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.
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.
This is the same text that is in the traditional GPL, and nobody has tried to claim that it requires additional libraries or programs like database drivers talking to a GPL'ed database must be GPL. This would immediately prevent anyone from using MariaDB, since it is GPL licensed.
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.
FWIW that was part of the problem since that's a walking license violation go the AGPL by many interpretations. It's just that Mingo/Rethink violate their own license there. However any other client? Unclear.
Careful with the word "violate": as a copyright holder, you cannot violate your own license. The copyright holder has intrinsic rights; licenses are permission to extend a subset of rights to third parties.
That's fine because Mongo is a company that plans on making money and holds the copyright. If it turns out AGPL is an issue they can relicense.
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.
Yeah, that would be a great example of AGPL used to FORCE many parties to PAY for a non-AGPL license.
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.
> 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 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”.
We rationally and happily chose AGPL for our platform. I advise everyone to do the same in my longer comment on this page. You can ask me why by replying to it.
Very large companies and governmental entities are using AGPL-licensed copies of OpenERP (now Odoo). In my experience, working for a company that provided services based on it, the license was never a problem.
There is little uncertainty -- the terms are in plain language. OP implied that the GNU Affero GPLv3 is an updated GPLv3 "in spirit" to reflect how today a lot of software is run on the backend, instead of distributed to clients directly. I believe this is an accurate characterization. Compare the GNU GPLv3 and the GNU Affero GPLv3 yourself [1].
> There is little uncertainty -- the terms are in plain language
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.
Deploy some game theory here. Regardless of what the drafters of GNU Affero GPLv3 intended, there are really four outcomes here (with wording since edited for clarity):
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'.
What does "interacting with it remotely through a computer network" mean?
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?
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?
> I.e. would we have been better off of Linux was BSD licenses?
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 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.
Personally, I find it hilarious that people will proclaim copyleft as the "most free", when it not only is more restrictive, but forces people who use it to open source their own contributions as well. I don't think any license should be able to tell people what to do with their own work, which yes, includes contributions to existing work.
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.
You have to open your contributions when you build upon GPL'd software, not when you use it. The GPL is very much centered around the end user, not programmers who build things. We often talk about the GPL as programmers and forget it was really built to protect the average joe from being locked out.
I suspect we talk about the GPL as programmers because the relative freedom level of a software license matters far more to us than it does to actual end users. Restrictions on what you can do with the source code only matter if you're both interested in and capable of modifying that source code. On a practical level, the Average Joe is "locked out" from modifying an application's source code by virtue of not being capable of performing that modification, not by the license. I have a lot of non-developer friends and acquaintances who use LibreOffice, and I can assure you that they're using it for the "free as in beer" aspect, not because of a philosophical attachment to free software. For most end users, freedom is contingent on data portability, not license terms: if I can open my word processing document or Photoshop file, it doesn't matter to me in practice whether the editor is open or closed source. If the application stops being developed, I can move to something else with minimal pain.
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.
> because the relative freedom level of a software license matters far more to us than it does to actual end users
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.
Sure, I get that. But that makes it a very opinionated form of free and open. While permissive licenses like Apache and MIT do have terms, they are much more akin to saying "here is a thing I made, and I'm sharing it with whoever wants to use it and whatever they want to do with it". Whereas copyleft licenses are more like "I'll share this with you, but you have to use it in accordance with my beliefs".
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.
It's just a reality that for some companies, having to release their internal source code would represent a potential loss of revenue or other business risk, or break an existing agreement or contract with a 3rd party.
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.
To add to this: not all companies have a stellar engineering team that is capable of dividing the code base in such a way that some could be open sourced while other remains private. The legal team for said companies know full well the technical debt and as a result everything remains private.
Agreed, though the FSF explicitly chose gplv3 over an agpl style license.
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.
The fear of the GPL from uncertainty certainly sounded similar to some of the arguments 'bcantrill is making against the GPL: it hasn't been tested in court, big companies lawyers' won't use it, etc. But there are big differences between the arguments. The historical worry about the GPL not being tested in court was that the GPL wouldn't hold up, that it would lead to strange outcomes like the GPL being non-enforceable because it's illegal price-fixing (or whatever), and suddenly SCO can take all the code they've distributed under the GPL and start suing people to pay commercial licensing fees.
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.
> If I run a public-facing, auth-requiring RethinkDB server, am I obligated to make source available to anyone who connects to it?
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.
> 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.
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.
> For the auth-requiring RethinkDB server, am I obligated to provide source to the entire internet because everyone can connect to it?
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.
So I think that, if that's how the AGPL defines "user", had RethinkDB continued to be AGPL, I'd be disincentivized from setting up and sysadminning a multi-tenant RethinkDB instance and more incentivized to provide scripts for people to run their own instance.
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.
> So I think that, if that's how the AGPL defines "user", had RethinkDB continued to be AGPL, I'd be disincentivized from setting up and sysadminning a multi-tenant RethinkDB instance and more incentivized to provide scripts for people to run their own instance.
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.
It also discourages people from providing hosted services based on a particular piece of software if they are in fact complying with the spirit of the GPL, but just suck at build infrastructure.
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.
Nobody said it had to be good build tooling, just functional.
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.
If you want one script that can build a whole stack then fine, but that doesn't mean you can't keep the tooling separate enough to build each component individually. You use RethinkDB with a bunch of patches? Keep that part in it's own script that gets called by your big one, problem solved.
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.
And when that's the goal, a more controlling license like copyleft makes a lot of sense. Especially in the case of a codebase from a failed startup that is no longer building a business around it though, a permissive license makes more sense.
Not a lawyer, but the challenge I see with AGPL is that it leaves room for ambiguous interpretation. My reading of it says (paraphrasing) "if you combine AGPL software with your program and that program interacts with others over the network, you must provide the source". Web applications today are often composed of dozens of services and very few interact directly with the end user. Putting a reverse proxy in front of an AGPL app certainly violates the spirit of the license. When using an AGPL database, you might argue that the end-user is "interacting" with it, but I'm not sure. There are also plenty of other use cases where a network service could do something auxiliary to the user's requests.
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."
The action that subjects you to the remote network interaction restriction at the heart of the AGPL is "modifying" the covered work.
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.
The "work" in this case would be the modified AGPL service. Using a reverse proxy, the "end user" would be the person running the reverse proxy, so you would owe source modification code to yourself, but nobody else.
There's a possibility that courts would interpret the remote interaction clause very narrowly as you suggest, allowing people to sidestep the teeth of the license easily. I think that possibility is fairly small, but you never know for sure of course.
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.
The real question is, why FSF isn't stepping up and resolving this issue once and for good?
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?
They can say what they intended to mean, and while that won't become a part of the license, a court may consider that. Especially if this would get widespread as "not tested but meant as a canon interpretation" common knowledge.
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.
NeXT's usage of BSD predates BSD being available under any open source license, and as such macOS/iOS's use of it seems like a direct consequence of that rather than it being under a non-left license.
By which metric is Linux more advanced than FreeBSD? Companies like Netflix use FreeBSD because its networking stack blows Linux out of the water. Further, how about Xorg, Apache, BIND, Nginx, etc? Significant amounts of userland tools and applications are written under more liberal licenses.
FreeBSD had "containers" aka Jails, more than a decade before Linux. Linux is merely more popular than FreeBSD, and that popularity has zero influence on its quality, I'd argue it might even have a negative impact on its quality in a statistical sense, when you take into consideration all the badly maintained SoC implementations of Linux.
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.
> it's commercially recognized as so restrictive it is an effective tool to make people pay for your software.
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.
Take a step back and ask yourself, what is the goal of the FSF?
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, software you are free to modify, change or use, without restriction
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.
> 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.
They don't want you to do that, but their definition of "free software" doesn't exclude licenses that allow it.
> Take a step back and ask yourself, what is the goal of the FSF?
> 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.
> 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.
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?
> "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.
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'm no free market expert...but wouldn't the free market sort of burn away the IP along with the org.? I would say its a bit of a tweaked/hybrid market (maybe call it libre market?), which - because it includes/allows for open/libre source - has allowed for IP to live on, whereas typical market incentives might have otherwise doomed it to "Sorry, no interest because of Can-Not-Make-Money-Off-of-It-itis".
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