Are Large Cloud Providers a Threat To Open Source Vendors? (redmonk.com) 67
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.
Support (Score:3)
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
ROI (Score:2)
AGPLv3 (Score:5, Interesting)
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.
Re: Socialism (Score:1)
You're right mate. Nobody works in Venezuela. The oil just pumps itself out of the ground.
Re: (Score:2)
How much do the government officials pocket and in what currency?
Re: Socialism (Score:1)
Nobody works in Venezuela mate. The expert above said so.
Unfortunately Stallman poisoned GPLv3. Can't use 3 (Score:3, Interesting)
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; y
Re: (Score:1)
If it were changed to what you say, the clause would be completely worthless. There would be no guarantee of patent protection at all, because you just need somebody else to contribute the code that violates your patent. As it stands right now the wording is exactly what it needs to be: if I download program y, and company x has contributed to program y, and company x has a patent that affects program y, company x cannot sue me for using y. I shouldn't have to verify that the patent-infringing code was actu
Re: (Score:3)
> 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 fa
Re: (Score:2)
I think you're right that it's unrealistic to expect those who hold patents to check the code they distribute for their own patents, but be that as it may, I don't think it's as unrealistic as expecting those who distrib
Too late on that (Score:2)
You're STILL responsible if you're selling something that violates a patent. It's not an alternative and GPLv3 in no way relieves you of that.
Re: (Score:2)
AFAIK, you're legally responsible if you're distributing something covered by a patent, whether or not you're receiving payment. If you were taking this responsibility seriously, and ensuring that what you distribute isn't covered by anyone else's patents, then checking it for your own patents at the same time wouldn't be much extra work, relatively speaking.
Distribution is copyright (Score:2)
Patent law in the US doesn't use the term "distribution". Copyright considers if it's commercial or non-commercial distribution as one element, but this is about patents.
Many sites publish all the recent patents, which describe the invention, so clearly it's legal to distribute a description of the invention. In fact that's one of the purposes of patents.
US patent law allows the patent holder to control, for a limited time, who "makes, uses, offers to sell, or sells" the invention. I would argue that mirror
Re: (Score:2)
I'm sceptical about that. FWIW, I did a quick search and found this: Debian Community Distribution Patent Policy FAQ [debian.org]
Let's read more of that document (Score:2)
The document you linked to has more to say. ...
It states that direct infringement is making, using, selling, or offering for sale. None of which would apply to a mirror. It then explains what COULD potentially apply to distribution:
--
Liability requires proving that the party charged intended to cause a third party to infringe. Additionally, the inducer must either know the patent exists, or strongly suspect its existence and make efforts not to know.
Moreover, if the software has substantial non-infringing
Re: (Score:2)
By your legal analysis, which I remain sceptical of.
This is in the section "What is inducing infringement?", and applies only to the charge of inducing infringement.
That's a copy paste from the law, not my opinion (Score:2)
>> It states that direct infringement is making, using, selling, or offering for sale. None of which would apply to a mirror.
> By your legal analysis, which I remain sceptical of.
I'm not sure if you're talking about the first sentence or the second sentence. "making, using, selling, or offering for sale" is the exact wording of the Act, also reproduced in the link you mentioned. There is no analysis there - those are the words of the law.
If you're referring to the second sentence, which do you th
Lol, injection. Speaking of dictionary (Score:2)
I see autocorrect spat out "injection" rather than "injunction".
It STILL doesn't want me to type injunction. Maybe my phone needs
https://thelawdictionary.org/i... [thelawdictionary.org]
Re: (Score:2)
I suspect "making" would apply, as in making copies of CentOS.
AFAIK a temporary injunction can be ordered against an activity the courts suspect to be infringing, but they may later determine that it actually isn't, whereas a permanent injunction is only ordered against an activity which the courts have determined to be infringing.
Re: (Score:2)
This could have been avoided if projects chose GPLv3. It was introduced 12 years ago to solve THIS VERY PROBLEM.
But for projects like Linux this isn't a problem, the usage is exactly by design. What you call a "problem" simply depends on your point of view and the reason the GPLv3 is not widely adopted is because most project maintainers don't see this as a problem at all.
Access Culture is dangerous (Score:3)
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.
Re: (Score:2)
I don't think that's a problem with access culture itself. Access culture can be implemented almost as robustly distributed as in ownership culture, and even more so in some respects (e.g. having your car break down is far less of a personal problem if you borrowed it from the neighborhood motorpool)
The real problem is monoculture - when one problem can cripple all access sources to an important resource, you have a much bigger problem. Far more so if the monoculture is centralized so that problems can pr
Re: (Score:2)
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.
The cool thing about Elastic is all the tooling around it, like Kibana. It's nice for things like logging, and I recommend it over Splunk.
Re: (Score:2)
I've never heard this term before, and a quick search finds a whole bunch of stuff that I'm pretty sure arn't related to what you're talking about.
I think I get what you're saying based on the context, but I want to ask anyway just to be sure. What is Access Culture?
Large cloud providers (Score:3)
are a threat to everybody and everything: smaller companies, but also data security, personal privacy and liberty.
Re: (Score:2)
More like "I built my business on a castle of other people's code, and now somebody else is doing the same thing to me!"
Playing a game of commodify the complement (Score:2)
The complement of cloud services is software to run on it, and vice versa. Both sides would benefit by ensuring the other turns into a commodity [gwern.net].
Re: (Score:2)
imagine how much better F/LOSS would be if commercial users had to fund back to the project based on the income derived from that code. $50 helps.
Consider how many free programs an individual independent contractor uses. Now imagine what fraction of one's income a 50 USD per year royalty for the use of free software would represent, particularly in a country whose currency won't buy a lot of US Dollars.
Re: (Score:2)
The AGPL requires that code changes be provided back to the community, even if they aren't redistributing the code (cough google/facedbook/tweeter).
How do you enforce that in any way differently to the kind of draconian enforcement of proprietary software licenses?
OTOH, imagine how much better F/LOSS would be if commercial users had to fund back to the project based on the income derived from that code. $50 helps. $500 keeps the maintainers excited and going to local conferences. $5,000 would make a huge difference. $100,000 even more. As income increased, the F/LOSS projects would get more funding too. Cap the highest payment to be $200K
So you're suggesting license fees such that not only do you have to contribute back your changes but you also have to pay? Presumably some of that money then goes back to you as a contributor of that project then as well? I don't see such a system working particularly good for projects like Android that don't actually make any money and are just a platform on which to build products that do m
Industry FUD analyst firm RedMonk (Score:2)