Sure. But as an engineer, I can also think of many worst-cases that result for computer users if we commit to only using permissive licenses. In particular, there's no guarantee that a user will ever be given the source code for a product they buy. So there's suddenly a reduced ability for people to become self-taught programmers or to fix their own computers and devices. And the ultimate worst case is that we move to a fully proprietary world built on the ashes of all of these projects trying to be permissive because they "didn't care about making money".
Many new projects are designed around being networked and interacting through networked protocols. It would be facetious to claim that there isn't an issue with the current state of licenses which make no attempt to handle this situation. The AGPL attempts to do so.
And yes, I know you were never a fan of the original GPL, and that you've always been anti-AGPL. But clearly you see the benefits of copyleft because you've spent a majority of your life working on a copyleft codebase (illumos)!
> As further evidence: there are a few projects that have started as AGPL, but moved away from it as they have needed broader adoption
There are also examples of projects which are not that way. Such as ownCloud and NextCloud. Interesting that you fail to mention the success stories of the AGPL. Several ISPs in Europe have started to set up NextCloud servers for their customers and thanks to the AGPL those customers can request the source for the ISPs modified version of NextCloud. That would not be possible under other licenses.
We need the GPL now more than ever. Free software is in everything, yet users are less free than ever. Almost everything users interact with on their phone is proprietary software built on permissively licensed free software. If you think the GPL is no longer needed, then user freedom was never your goal.
Having extensive experience with unicode and how text is usually rendered, I knew exactly how to fix the issue; the fix was likely as simple as injecting an SO that hijacks a specific system library function. However, because the phone was locked down, I was unable to fix the problem myself. All important system apps including SMS and the browser displayed gibberish.
It was the most expensive brick I ever bought.
This experience taught me the true value of the GPL and why user freedom far outweighs the freedom of developers.
I must stress that I do not blame developers for not catering for a language they do not speak, and I can't blame I company for not supporting a group of people if it doesn't make business sense.
I do, however, hold a grudge against a company that prevents me from fixing an issue in a product I payed for and own. More so when the fix is for a issue that renders the device useless and is incredibly easy to fix.
It seems increasingly clear to me that this is true, albeit in the sense that the revolutionary aims of the FOSS movement (if we can genuinely lump things together) have been for the most part utterly defeated, and the handful of people who are sincerely concerned about them are now engaged in a tattered and obviously doomed rear-guard action.
Open source as an engineering approach is doing fine, of course: Its practical benefits turn out to provide a great deal of leverage for centralizing and consolidating power.
a) open source as a technique and a body of work has become indispensable (or at least, for the moment, quite important) to a lot of industry and to the structure of the existing network that enables it. I don't think anyone very credible on the issue would seriously dispute this.
b) open source as a technique and a body of work has been instrumental in giving players like Google, Amazon, Facebook, Apple, Twitter (etc. ad infinitum) the leverage to build a service-oriented / centralized / siloed model of networked computing which is antithetical to the aims of user control and freedom expressed by the Free Software movement and a broad set of more-or-less related ideological impulses.
By some measures, the health of the open source ecosystem seems quite robust. By others, we're plainly fucked and I'm not sure what to do about it.
The economic aspects are not just cheap access to software, but also the benefits of increased competition result from access to the code, which allows the creation of data-compatible competitors.
These missions have failed for anyone but software developers, because so much of today's software runs on servers where the GPL does not enforce sharing of code, and because the community has become dominated by commercial players and permissive licenses like MIT. As a metaphor: the bakers are all happy because the flour and yeast are free. But bread is as expensive as ever, and most people eat in restaurants, anyway.
This is very demeaning and insulting. The revolution is alive and well.
Me too. :)
I'm not giving up - and I agree that both as an end user and a developer, there's plenty to appreciate right now. Still, I think there are a lot of hard, complicated thoughts to be had about the distribution of power and the direction things are headed.
I think this is the fundamental disagreement we have. I prioritise the needs of users to have software that they have the right to control and modify (which allows for "software mechanics" to fix bugs and so on).
Upstream contribution is not, and has never been, a goal of the GPL. The concept of "upstream" is a development workflow which is entirely separate to what license you use. Some people do attempt to force others to follow a workflow by using the GPL, but I think such attempts are doomed to fail in most cases. Others (such as Linux) do it by making their software move at a very fast pace to make out-of-tree maintenance hard, which actually works much better.
The GPL has always been a license for the benefit of users, not developers (though of course, developers are users too). So the focus on contribution and wide-spread use is IMO missing the point of the GPL. Yes, you get contributions (in general) from it, but that's because it just so happens that upstream contribution is one of the few viable workflows with free software. It's got nothing to do with the GPL.
I completely understand why you're prioritising contribution and creating a healthy community, but in my opinion building a community around the base of "I want this software to have a community around it so that the software works well for the community." isn't really as fulfilling as saying "I want this software to set users free from proprietary alternatives, and the community that has formed shares in these ideals." Of course, each to their own and all that.
I think this is really the core of the issue. For someone to "adopt" my software but not contribute in any way (whether that be patches, documentation, support, financial, repetitional, etc.) it's not an especially desirable outcome. I suppose there is something to be said for merely living generously (and I do license quite a bit of code that way) but as a society we have unfortunately not yet solved how to sustainably develop software projects without the sticks and carrots in the general case.
It is fair to look at whether e.g. AGPL limits adoption, but I think it is equally fair to ask if it makes sense that a software developer in a broom cupboard is donating his time to AWS, or whether AGPL allows software to be written that might otherwise not exist, or might not exist in the open.
I wouldn't hold my breath for that, frankly. My experience in working for a few large companies has shown that they actively discourage contributions, since it opens the doors for lawsuits (frivolous or not), further contribution and maintenance expectations. To them, the cost is not worth the benefits.
There are, of course, the exceptions to this rule - but that's all they are, exceptions.
For one great example, look at the plight of OpenSSL. Before it broke way open, how many companies really contributed to it? And how many just used it, not giving a second thought to using it unless there was a CVE?
So you think there were a large number of companies privately fixing bugs in OpenSSL? Or how would a less permissive license forced companies to contribute to a project they weren't actively improving?
And on your earlier points, keeping changes private likely requires more future contribution and maintenance expectations
That assumes 1) the other software exists (GPL/AGPL has much more effect for software without viable competitors), 2) the license causes more of a problem than switching does, 3) you don't sell an alternative license that costs less than switching does.
In short: of course not. Or at least "not at any cost".
Open source projects do loads of things that reduce the potential ecosystem. People choose to work on projects that aren't web browsers, for example. Or they choose languages that aren't the #1 most popular. They target a platform that has less than 50% marketshare. All of those things turn away potential users in exchange for authorial convenience of some form or another.
It is a foreign concept to me to write e.g. a developer tool for a minority environment and then all of a sudden worry about the license being some major barrier.
But more broadly your position is very strange to me in its wider implications. Let us say that some voice actor could donate some spare reel to Disney. Or that some author could donate a manuscript to Penguin. Or that some musician could donate their track to Sony. Do you believe they should do so, under the theory that this in some way "grows the ecosystem" for their work?
They don't give back code, but they do give resources.
For instance, company I work in develops software for a customer that later sells it to various corporations, big and small. Were I to include an GPL dependency in the code, and were it to pass unnoticed by my boss and our customer, it could quickly turn out into a legal clusterfuck with damages orders of magnitude larger than my salary. So we do have a list of open source licenses that are allowed for dependencies of projects for our customer, and GPL/AGPL are prominently not on that list.
Now if there was some critical piece of code we absolutely need and there's no non-GPL alternative, I could ask my boss to talk to his boss to talk to the lawyers to figure something out. But in 99% of cases, you'll be asked to "Google harder", and then you'll find something with a "better" OS license - so it's easiest for the management to ban GPL by default (or, in our case, create a whitelist of allowed licenses).
(I desperately tried to get WTFPL on the whitelist list, but failed :(.)
Even if it was AGPL... and even if the customer modified the library, and even if they did get sued.... all three of which are vanishingly small probabilities... still all you'd have to do is release your modifications to the AGPL library. The notion that the AGPL will force you to open source your proprietary code is, as far as I can tell, completely spurious.
I really think that it's just a cultural "screw the hippies" kind of a thing, which you're buying into by making these sound like rational fears. There's nothing rational about it, it's just "oh my, we'd need just thousands of lawyers for that!" bogeymen.
It sound to me that the only code allowed in the product is code you have written yourself, code you have hired someone to make so its yours, code you bought so its yours, or code which license make it indistinguishable from code you own.
It's a common occurrence in my experience in companies over 1k or so employees. Under 1k, getting hit with the GPL would probably just be a death knell.
Lots of permissively licensed software exists that is mainly corporate contributed code, or which is produced by projects which are primarily corporate funded (by corporations which use the code.)
You can't get free maintenance on your code by using permissively licensed open source if what you use diverges to far from what your free labor force has, after all.
Why is this weird? As the author of the software, surely I get to decide how I prefer to be compensated?
If I'd like patches and user freedom, then your only decision is whether the software is worth that for you. Not whether my license is "weird" or "not open source".
This way people still add features and upstream bugfixes, but a) it doesn't get forked to hell like the 200 Linux kernels that each Android manufacturer has to publish and b) you get much wider adoption faster, with more people being paid to fix bugs and add features to your code because it is being used alongside proprietary code.
Sure, it doesn't give you a nice stick-it-to-the-corporations dose of righteous satisfaction, but it feels to me far more pragmatic, and healthy for the project in the long run.
GPLv2 says very little directly about patents, only touching on the topic by saying that they're not an excuse for not complying. That implies some things for patent holders on relevant topics but isn't explicit about it.
GPLv3 basically makes those implications explicit, stating clearly that if you hold or license any relevant patents you must be able to freely license them downstream.
To me that stuff is implied with copyleft, because how else could it work? Since patents restrict my ability to legally redistribute the code, and the whole point of copyleft is to ensure my ability to legally redistribute the code, I don't see how they're separable as long as software patents remain being a thing.
The "copy" in Copyleft gives you your answer - it ought to be about sharing copyrights to code, not patents. You don't have to grab patents (which expire in twenty years.) Copypatentleft is what we really have, instead, with GPL, and that's a whole different beast.
So, it is of course logically possible to confer the copyright to code that exploits a patented idea without conferring the patent rights at the same time. That would mean that not everyone could use some shared code, without a license, even though they have a copyright license and can share and examine it. The patent holder would retain their patent rights. Why respect patent rights? Because the majority of value in American businesses is IP - trade secrets and patents being the bulk of that. GPL is therefore a non-starter in the corporate world, more often that not. You don't have to share patents. If you insist, then your code gets duplicated under another "more permissive" open software license at enormous expense, that's all.
If you want my work on your community code, great! If you want my ideas - my patented ideas, um, no.
I'm specifically thinking about sub-pixel font rendering, for which FreeType contains code which is disabled by default due to patents:
That would imply that it's the latter. Which, of course, is still an issue for the user. But it does point to the GPL not requiring the patent clause in order to meet its copyleft goals.
FreeType wasn't created by Microsoft, obviously. It has no license for M's patented tech so it can't include the code live, period. I presume that FreeType is trying to skirt the law by making it easy for users to break the law without, they hope, being seen as breaking the law themselves. I don't know what the court would decide if Microsoft sued. Presumably FreeType would say that the code was there just to help future programmers catch up when the patent expires. I'm guessing they wouldn't win that one.
So, I'm going to say it's not a sufficient example.
So you might ask, why does Google use the Linux kernel? Perhaps because they don't have to modify the kernel to accommodate inventions they wish to preserve, for public software such as Android; but more importantly the kernel is useless by itself and the license doesn't extend to libraries (Google spent billions recreating the GNU libraries to be sure of that), so the license for the kernel has no practical importance. The rights granted are "stranded", as it were. Clever on the part of Google. But in most cases, the GPL or MPL can't be gotten around in that manner.
The googleable rubric for GPL2 is "GPL's Implied Patent Grant." In sum, the GPL seizes all relevant patent rights from any contributor (regardless of whether those contributions related to their patents, IIRC) and any distributor. In some cases that doesn't matter - in other cases, it does. If you want to retain control of who gets to use your patents, and patented tech, that's a big problem. If your invention is a hardware invention, the GPL still scoops it up - their language doesn't exclude rights to hardware inventions - so you may actually have the right to build any such patented hardware as long as you put Linux in it: if the patent owner touched Linux. It would take a court case to be certain this wasn't a risk.
This also seems to mean (even for GPL2) that if you explicitly license one entity to use GPLed software with your patented tech (hardware or software), then you've just given a free license to every soul on earth to do the same, with no royalties. In some cases, that might not matter. In many other cases, it does.
"In contrast, a GPLv2 licensee, under the doctrine of implied patent license, is free to practice any patent claims held by the licensor that cover “reasonably contemplated uses” of the GPL’d code, which may very well include creation and distribution of modified works since the GPL’s terms, under which the patented code is distributed, expressly permits such activity.
Further supporting this result is the Federal Circuit’s pronouncement that the recipient of a patented article has, not only an implied license to make, use, and sell the article, but also an implied patent license to repair the article to enable it to function properly, Bottom Line Mgmt., Inc. v. Pan Man, Inc., 228 F.3d 1352 (Fed. Cir. 2000). Additionally, the Federal Circuit extended that rule to include any future recipients of the patented article, not just the direct recipient from the distributor. This theory comports well with the idea of Free Software, whereby software is distributed among many entities within the community for the purpose of constant evolution and improvement. In this way, the law of implied patent license used by the GPLv2 ensures that the community mutually benefits from the licensing of patents to any single community member."
For example: the FSF's stance on certain provisions of the GPL, like the ones on linking, is as far as I know completely untested in court and at odds with what appear to be both established legal and common-sense/intuitive notions of what constitutes a derivative work. And I'm not speaking from inexperience there: the Django project had to go many rounds on this because the maintained MySQL driver modules for Python are all GPL. Does this end up GPL'ing Django since it supports MySQL as an option and, thanks to the nature of Python's import system, will share address space with a GPL'd module if you use MySQL as your database? Or does the fact that it's an end-user choice and Django is simply shipping code to normalize API access to any of multiple drivers on multiple DB engines (leaning heavily on PEP 249, which itself is a normalized API for Python DB drivers to expose) avoid that? Nobody seems to be able to give a clear answer, because there is no clear answer, legally, on when the GPL's derivative-works clause is invoked or even if the GPL's derivative-works clause is legally sensible.
In contrast to uncertainty, I think we can be quite certain that django works without mysql (I personally run several sites with postgresql). Modules for django would likely not work without django, so they are likely derivative of django and not the other way around. I also vaguely recall fsf stating that they don't consider the linking guidelines to be that relevant for software written in languages without linking, which would include python programs.
Is your problem with the license that FSF as an organization has an opinion on how derivate works can be identified for software?
My problem is that the FSF's opinion on what constitutes a derivative work is horribly broad, and has never to my knowledge been tested in court. So despite all the reasonable intuitive opinions in the world, who knows?
Is there a freeloader problem? How do we know if people just aren't that interested in the software?
If one puts something out there for "free" then one is not entitled to a return. It's the model which is broken, not the users!
Regarding your "peek and return" scenario, GPL actually lets you do that, and I wouldn't consider you an actual "user".
It would be more convincing if you gave a clear example. (that wasn't functionally an attempted end-run around software freedom.)
While I differ with you on the choice of pejorative descriptions, one really has to study projects like Ghostscript to see what the problem is with GPL and open core. The GPL is actually used to restrict freedom rather than promote it because the non-free side of the project is a free rider on the free side.
What happens is that nobody contributes in such an unbalanced situation. As a business you have to maintain a product where many people are using it for free, but nobody is encouraged to hand you contributions for nothing. If you want to use (A)GPL in your product, you need a business plan that ensures freedom for your users, so that they are encouraged to join you.
If you want open-core (as rethinkDB apparently does) then you need a license that levels the playing field so that other non-free-software entities are willing to collaborate with you. Non-permissive free software licenses effectively block those contributions and so you are left with a lose-lose situation. Of course, if you are motivated by software freedom, you really don't care about this... but then you wouldn't be doing open-core.
Sadly, I doubt the FSF will ever write such a license, given how they discourage use of even the LGPL unless absolutely necessary.
Setting up a web service with GPL code doesn't meet the bar for distribution, so that situation does not require the code to be made available. That's what the AGPL addresses, network use triggers the requirement to make the code available.
For example, the vast majority of the code I write is AGPL-licensed (derived from an AGPL licensed work by a third-party), yet you won't find a copy of it on the Internet. That's because we only have to provide that source to our customers, and while it's fully within their rights, they have no inclination to share it with anyone.
The obvious case where that wouldn't work is a project like Linux with many contributors and no copyright assignment. But others like Clojure organize themselves differently.
In any case, I think it's important to move past these issues ASAP in a way that unites the community, and move forward with the project. RethinkDB may not have been successful as a business, but it seems very promising to me as an open-source project. I'm very excited to see it bloom in its new life (and will try to contribute myself if/when time permits).
I agree, not just in principle but because I've seen it happen. Where we might disagree is that I don't assume that's a bad thing. Who are the people/companies who will reject something because of AGPL? Would they have contributed under a different license? Overwhelmingly no. Whatever changes they made, if any, wouldn't have been available to the project anyway. If they want to pay for the software, or support etc., then they'd probably do so even if it's completely proprietary. For them there's dual licensing.
Anyone who might have wanted to contribute still has a way to do so. Ditto for anyone who might have wanted to pay. So, who's left? Those who might use but neither contribute nor pay. Are such users a net positive? They're good for the ego, but the support load associated with such users can kill a resource-constrained project. I've seen that happen too. Keeping them away might not be a bad thing. Maybe AGPL is "toxic" in the same way that chlorine is, keeping the pool clean without harming the swimmers. And yes, some people are extra-sensitive to either. ;)
Let me first say that I respect you and RethinkDB immensely.
Rather than comment on toxicity, I'll state a fact: in the company I work for, which makes heavy use of open source software, is relatively sophisticated, and is legally cautious and conservative, AGPL software is verboten. It's a non-starter. Do not pass go. Do not collect $200.
So, in the absence of a company that can actually offer a valid license to the product, there's no chance of considering it, let alone using it. This may seem overly cautious and FUD inducing, but it is how things work in our litigious world.
- Does your company contribute to any of the non-AGPL pieces of software it uses, either in code or money?
- Does it have propietary patches to these software that it does not contribute back?
- Has it published any open source packages of its own?
AGPL is an immediate no; GPL requires written approval from chief in house counsel and he will almost certainly say no.
It is unfortunate that some users, such as yourself, must be left out, with no apparent remedy. But this does not mean RethinkDB cannot succeed elsewhere.
See also https://www.gnu.org/licenses/licenses.html#AGPL
There are so many gray areas. Does a SPA JS application communicating with a REST API of an AGPL application count as "linked"? We don't know. To a jury that sure might look like the same application. Say that it does, does something then like a AWS Lambda "serverless" pipeline that utilizes that same REST API count as linked? We don't know. Maybe, maybe that counts as "mere aggregation" and at this point for the GPL there's a sort of well understood DMZ around that weasel term, because there have been enough "mere aggregation" situations over a couple decades, some of which were even litigated in a court of law, to sort of set up some fences of what that possibly means. For the AGPL no such DMZ has been established, at least not in a well-understood, applicable to every use of the license, manner.
The way the AGPL is directly written, in order to be as infectious as possible, as an intentional goal of its writing, we as a developer community have absolutely no idea how far the infection rabbit hole goes. The concern that the AGPL is toxic is as much the fear that we can't explain that infection rabbit hole to a jury in a court of law. We mostly know this because as developers a lot of us have already had a very hard time even explaining this rabbit hole to software company lawyers that may even be technically versed on both sides of the fence.
Tell that to the original author of libevhtp, who is currently homeless. To paraphrase him, "the ideals behind BSD are great until someone derives massive profits from your work and doesn't share."
Yes, there are other issues contributing to his being homeless; my point is that putting careful thought into your licensing is important, if only because you can't always change it later. Being clear on IP ownership is also quite important, especially with the threat of someone with an army of lawyers landing on your doorstep.
EDIT: Fixed name of library, thanks for the check.
The person you're talking about is the author of libevhtp, a small HTTP library built on top of libevent. Apparently, Chromium uses or at some point used libevhtp.
Not sure how "small" it is. Seems like a significant work to me, worth some appreciation, including a financial one.
In fact, many people will simply re-host re-licensed work, in an effort to keep the "free" version available.
Can you cite your sources for this claim? I checked the Wikipedia article for Libevent. The original author, Niels Provos, appears to work for Google.
He basically had two choices:
- BSD style license where people can use it without paying him, and modify without contributing back
- GPL or proprietary: it's highly unlikely anybody would have used his library. Even LGPL would probably have limited usage significantly.
How would a different license (say, AGPL) have helped? He could have gotten paid for his work via a dual license. Putting code out there under a BSD style license effectively eliminates that option from the table; what corporation is going to pay for something that's legally and morally free?
Like a startup, writing open source requires that you find customers (or employers) who will pay, or you do it as a passion project. In an ideal world people would have basic income and could write open source all day long, but that's not our world.
Well, there were no customers who would pay the original author. Chromium still required developers to incorporate and maintain the library. Money was spent on the library, it's just that none of that money was given back to the original developer.
> or you do it as a passion project
Doing a "passion project" doesn't mean that you need to give everything away. If there's the chance my passion project could make money, why deprive myself of that chance before I even begin?
Lots of passion projects licensed GPL which make money; and lots of passion projects licensed BSD which don't have a single user.
Depends on your goals, I imagine. Making a living, or making a name?
I like RethinkDB a lot, but A) I have no time to contribute and B) my ability to use and enjoy databases does not automatically confer the ability to write them. I think most people who liked RethinkDB are in a similar boat to me. I'd love to see this project take off. But I didn't have money or time for it before and I still don't. I don't have those things for Postgres either but it doesn't seem to need them as direly.
If code would be Apache licensed, I personally would consider to start new company around it. Maybe it would not 'scale', but it would be enough to pay my bills.
- No way to operate under Apache foundation or other umbrella
- AGPL is simply banned in many corporations
- No way to create 'enterprise' proprietary version
- No way to charge for extended customer support (patches only for subscribers after free support runs out).
Legal risk is basically a tax -- it is a cost that is born by the end-user but which does not go to the supplier. A selective tax on one product as opposed to alternatives absolutely can kill it.
Open-RethinkDB is not going to fail because of AGPL, IP issues or litigation. It's going fail because of lack of users, developers, and growth. And that's sad. But it isn't going to fail for political or legal reasons.
AGPL (which is an IP issue and is a source of perceived risk of litigation) is a contributor to lack of users, which is a contributor to lack of developers.
You are treating deeply linked issues as if they were orthogonal.
That's fine though; ultimately, you will be able to blame RethinkDB's death on this non-problem and you'll have a clean conscience. It's easier to point to this as the cause of death than the much harder problem of getting people interested in the product in the state it's currently in. I think this is like blaming a cancer death on a lack of handwashing. Sure, washing your hands is important. But it won't cure cancer.
Stating a specific reason to doubt the dismissal of it as a serious and potentially fatal concern is neither preoocupation nor stating a belief that it is "the biggest" problem.
> Sure, washing your hands is important. But it won't cure cancer
Which is not to say failing that kind for basic hygiene doesn't make you more likely to die sooner with a cancer that has already left you immunocompromised -- more dangerous in that condition than for the average healthy person.
Which is pretty much a perfect analogy for where I think the licensing issue fits into the space of problems facing RethinkDB.
Software is protected as works of literature under the Berne Convention, yet a work of literature is not patentable. We don't patent underlying methodologies of writing a story. We don't have hundred of patent with slight different wording of the concept of "hero and villain", nor trolls trying to sue every time someone writes a successful book. We don't have patents of "every day concept, but this time its a book". That would be a total waste, caused by over-reaching lobbyists that get to write their own laws if they just spend enough money on the winning candidate.
That is fine, but then replacing GNU libraries is not waste, but investment. The authors of GNU libraries give their work for free, and would also like to be able to use other people's (potentially patentable) work in return.
Blink itself is derived from WebKit.
That's funny. How much waste has there been due to people having to work around patents? Is waste only a problem if nobody can profit from it?
Yes, one can avoid that by paying the price of the patent; but the same is true with the GPL, you can follow the license. It's just a price in another kind. The waste resulting from not wanting to pay it applies to both cases.
Open source wasn't originally about creating waste and duplication. Let's not do that; since the bonus of encouraging innovation with financial reward doesn't happen, just the waste.
And not everyone is willing to donate their free time to enrich somebody else. You're not entitled to free code.
All the patent ills you're attributing to the GPL apply to the Apache License too, btw. AL2 is where GPL3 took its cue on patents.
It seems that the company between RethinkDB is shutting down, but trying to let the project be continued by the community. Some context I found here: https://rethinkdb.com/blog/rethinkdb-shutdown/.
This is simply untrue, and bad advice to anyone thinking of using the product in a way that's inconsistent with the license. Is the author actually suggesting people should do that?
One way of getting around that is to be the owner of the original IP, whereby you could relicense it under something that wouldn't limit stewardship options. It seems that's not a possibility, because:
"One of the creditors owns the IP and IMO they're unlikely to sell it unless the project raises fairly substantial sums of money"
So, basically, they will have to sort out stewardship with fewer options than what would be optimal.
There seems to be a "far left" and "far right" view on the thread. The "far left" is that the issues above somehow don't matter at all. The "far right" view is that they are showstoppers for any kind of stewardship solution.
The truth is somewhere in the middle.
I'm not sure any of this has been well tested in court.
1) He's the original founder and should be respected out of courtesy.
2) He just gave you an amazing opportunity to not worry, so take it.
I explore more of my thoughts on Open Source license and the post-mortem on this just-released The Change Log podcast episode - https://changelog.com/podcast .
One of the things that we are doing is making sure to always license our code as MIT or ZLIB or Apache 2. This is a promise (and a legal one too) to developers that the ideals and values of Open Source will always be there, first and foremost. In fact, the license was determined by a community vote (see here: https://github.com/amark/gun/issues/17 ).
People have asked why others (like us) won't shut down in the same way Parse and Rethink have, I think the answer is simple:
5 billion new people are coming online by 2020 and the technical challenges of creating scalable systems still exists. So the opportunity is enormous and proportional to how scalable your system can be - which means decentralized tools will win out over time compared to their centralized alternatives.
Second, unlike attempts to sell support licenses or DBaaS or crippleware premium upgrades, we're taking the approach of partnering with developers/companies that build industry transformational product and solutions for governments and enterprises. We believe that if we can enable others to be able to create answers for the needs of large organizations, then we both can mutually benefit by creating revenue shared partnerships. This is already happening with several companies, and we're rolling out to a government (but I can't disclose who/what/how yet).
We think this will work, and it will pave the pathway for other Open Source vendors that a real business model can work, without any of the unfortunate alternatives strategies others have taken (open core crippleware, unlikely support licenses, struggling DBaaS). This creates the best "win-win-win" environment, where startups get to piggy back for free while governments and enterprises pay for the much needed technology solutions to handle the coming transformation.
What transformation am I talking about? Again, the 5B new people, the advent of IoT and every autonomous car or burrito delivery drone, and the demand for doing machine learning on the whole system, at a global scale - see this article on distributed machine learning with gun: http://myrighttocode.org/blog/artificial%20intelligence/part... .
This transformation won't succeed unless it can be built on top of truly Open technology, and that is why license is important.
I don't have anything against the AGPL, but it seems like you're just saying "The AGPL isn't a problem because RethinkDB's founders are nice smart people". And then you explain how it's a great thing that a project yours is using a less-restrictive license like the AGPL critics are hoping for.
Initially, that might be scary, but Slava /also/ said people shouldn't spend a dime on it or distract from the amazing momentum of carrying RethinkDB forward (RethinkDB fits certain solutions that GUN isn't optimal for, so it still has an important niche and place).
You guys are here to do this as a community, for the benefit of all. If you are afraid the IP owners (when they said they won't) will capitalize on your success after the community has overcome the challenge... then the intent and motive is in the wrong place, and that isn't conducive to anybody.
Worse case scenario: So what if they do? The community won't be forgotten, everybody would still win. Losing momentum is far more dangerous.