Slashdot Mirror
Are Large Cloud Providers a Threat To Open Source Vendors? (redmonk.com)
Stephen O'Grady, co-founder of the industry analyst firm RedMonk, asks whether open source vendors are marching towards an inevitable and damaging war with big cloud providers:
In the last twelve to eighteen months...a switch has been flipped. Companies have gone from regarding cloud providers like Amazon, Google or Microsoft as not even worth mentioning as competition to dreadful, existential threat. The fear of these cloud providers has become so overpowering, in fact, that commercial open source vendors have chosen -- against counsel, in many cases -- to walk down strategic paths that violate open source cultural norms, trigger massive and sustained negative PR and jeopardize relationships with developers, partners and customers. Specifically, commercial open source providers have increasingly turned to models that blur the lines between open source and proprietary software in an attempt to access the strengths of both, with the higher probability outcome of ending up with their weaknesses instead.
That commercial open source providers took these actions having been advised of these and other risks in advance says everything about how these businesses view their prospects in a world increasingly dominated by massive providers of cloud infrastructure and an expanding array of services that sit on top of that. The strategic decisions inarguably have major, unavoidable negative consequences, but commercial open source providers -- or their investors, at least -- believe that a lack of action would be even more damaging.
That commercial open source providers took these actions having been advised of these and other risks in advance says everything about how these businesses view their prospects in a world increasingly dominated by massive providers of cloud infrastructure and an expanding array of services that sit on top of that. The strategic decisions inarguably have major, unavoidable negative consequences, but commercial open source providers -- or their investors, at least -- believe that a lack of action would be even more damaging.
People who are concerned with the lowest up-front cost only will experience Google levels of support. Their management never looked into TCO at their low-cost business school.
These people make frustrating customers and will eventually be overtaken by competitors who understand RoI. Don't get mixed up wit the former type - there are plenty of latter-type fish in the sea and they'll be around as customers for longer.
A competent consultant knows about better alternatives to the biggest-name options. #include car-analogy
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Access culture is dangerous. But it is an nigh inevitabel consequence of a highly optimised society. That in itself is dangerous, because it introduces single points of failure. Imagine everyone using Google for everything in everyday computer work. That's not entirely unlikely. Then imagine Chrome OS and Android getting a coordinated hack and Googles entire cloud going down. Not pretty.
If you let the big-wigs control everything all the time, this is what happens. We are the last line of defense, because none of us uses any proprietary OS entirely on its own.
Curiously enough, ACS isn't all that great, there are way better and cheaper solutions out there.
It's mostly about brand presence and size.
And Elastic Search is a neat concept but implemented in Java. I'm pretty sure a good team would need only a few weeks to redo ES in some binary PL and some project that does all ES does but better, faster, cheaper and with less setup hassle.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
are a threat to everybody and everything: smaller companies, but also data security, personal privacy and liberty.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Unlike GPLv2, GPLv3 is explicitly compatible with AGPLv3. This means that a program is allowed to include both GPLv3 and AGPLv3 components, and if so, it must offer complete corresponding source code to users who interact with the program over a computer network even if the program itself is not distributed to the public. Oracle has changed the license of new versions of Oracle Berkeley DB to AGPLv3 in order to forbid its use in any program with a proprietary component. This allows Oracle to charge for exceptions.
GPLv3 does include a clause which appears to be an attempt to improve this situation.
Unfortunately, Richard Stallman also included a poison pill in GPLv3 which makes it risky for any organization to use GPLv3 if any part of their organization has a patent on anything. He wanted to use GPLv3 to kill patents, by making it so that anyone who has any patent can't safely use GPLv3 code. The result is that patents killed GPLv3 use.
Some will say "no, it's intended to mean you can't patent something in the code; you can have other patents". But that's not what it says. During the draft process we asked that it be clarified if that was indeed the intent. Stallman refused to change the wording to limit it's applicability to only contributions made by the person or company who has the patent.
Because Stallman refused to adjust the wording before releasing the version of GPLv3, this is the current situation:
I worked for a major university. Some departments in that university do a lot of research and development. The R&D is funded in part by patenting the useful results and licensing the patents to companies which make use of the R&D. If any other part of the university were to distribute GPLv3 code anywhere, at any campus, it would put all of the universities patents at risk. Someone, perhaps a competitor or perhaps someone who doesn't know anything about the patent, could invalidate the patent by contributing a module which makes use of it.
That doesn't happen with GPLv2, so any organization which has any patent on anything is safer using GPLv2 code. GPLv2 doesn't have a patent poison clause.
If GPLv4 changes the clause to say it only applies to code authored / contributed by the organization that has the patent, that would mostly fix the problem. That's what proponents of v3 *say* that that *intend*, but they haven't allowed the license to say that.
> you just need somebody else to contribute the code that violates your patent.
That's precisely the problem.
> I shouldn't have to verify that the patent-infringing code was actually ***contributed*** by company x.
Everyone is entitled to their opinion, I suppose. Some people claim, falsely, "it only applies to code the patent-holder contributes". At least you recognize that's false and you don't make that claim.
The conditions you list for invalidating a patent under GPLv3 are *almost* correct. In fact the patent-holder doesn't have to contribute at all in order to lose their patent bases on some third-party (competitor?) contributing infringing code. They need only either USE the v3 software in a customer-facing system, or provide a mirror. For example many universities provide mirrors of Linux distributions. By doing so, the terms of v3 say they lose all patent rights to anything they have patented, the moment somebody contributes infringing code to any distro that they mirror.
The problem is that's millions and millions of lines of code that nobody at the university has ever seen. They are just providing a CentOS mirror, not auditing CentOS for patent issues. By providing a mirror, they relinquish all patents to anything at all that anyone can sneak into the code.