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
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.
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!"
--- Most topics have many sides worth arguing, allow me to take one opposite you.
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.
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.
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.
All you need to know is, RedMonk receives funds from Black Duck which is funded by Microsoft to engage in open source 'research'.
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 actually ***contributed*** by company x.
> 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.
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.
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 make money.
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 distribute code to check it for everyone else's patents, which is the alternative.
As someone in the financial world told me once "profit is a matter of opinion" ROI requires you to attribute investment to an incresased profit. Since every - insert favorite currency here - spent shows up in the books as an investment, you know "CAPEX!!", it is seen as added value. Regardless of any effects it actually has on the business. Correlation not being causation and such, these kind of exercises are the prime reason why vendors can sell million dollar solutions with licensing that is often more expensive than the actual implementation and operational cost of in house solutions. I'm not underestimating the capacity of development teams to deliver a bad solution either. In the end, it all comes down to making intelligent decisions and Free and OSS must at least be systematically considered as an alternative.
How much are the oil workers paid and in what currency?
How much do the government officials pocket and in what currency?
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
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.
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 mirroring CentOS is not "making, using, or selling" it. Therefore you would not violate a patent by distributing code which describes its implementation. No need to look for patents before distributing, only making, using, or selling.
See 35 U.S. Code S 271
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 uses, it is not contributory infringement to provide it, even if it is subsequently used in an infringing combination
--
So yeah if you KNOW that it infringes a patent, AND you know it can't be used in a way that doesn't infringe, best not to distribute that package.
An injunction, by the way, is an order to stop doing something. In this case, to stop mirroring the software. It's not a penalty and doesn't assume liability for past acts.
>> 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 think apply? Do you think a free mirror of CentOS Is selling CentOS? Offering it for sale? Do you have a dictionary handy?
>> An injunction, by the way, is an order to stop doing something. In this case, to stop mirroring the software. I
> AFAIK that's true of a preliminary injunction, but the section I quoted was talking about a permanent injunction.
What so you think a permanent injection is? Again, do you have a dictionary handy?
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...
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.