I genuinely wonder what all the people defending infringements on Bezos's "right" to profit from elastic (for instance) are thinking.
If it's open for you but not for him what's your problem?
If it's open for you but not for him what's your problem?
How do I know it'll stay open for me? How am I supposed to make that determination on whether or not it even is open for me in the first place?
With a standard OSI or FSF approved license, I don't have to be a lawyer to have at least some idea of what the license entails, because their lawyers - and plenty of others - have already combed through them and put together layman-accessible descriptions of their stipulations - and further, by the very nature of their approval as "open source" or "free software" licenses, I know with reasonable certainty that even something as restrictive as the AGPLv3 will always permit me to use, modify, and redistribute that software, no matter what.
Contrast with these bespoke "source available" licenses, which are specific to certain products/companies and can change at any time. One might call it "FUD" to be skeptical of 'em, but they certainly seem to leave a lot of room for fear, uncertainty, and doubt given the legal pitfalls around, say, maintaining an independent fork.
Still, at least the software itself is transparent (i.e. it can be independently audited at any time, by anyone with the requisite knowledge, for any reason), so for most cases I would certainly pick such software over anything opaque / closed source any day. The lack of contingencies should the developers inevitably go out of business (whether from buyout or bankruptcy) still pushes me to prefer, you know, actual free and open source software.
Transparency is a dependency of trust, but it ain't the only one.
Technically any license can be changed if the company holds the copyright. This is why Microsoft makes you sign a CLA. This signals a plan to potentially de-open source in the future and capitalize upon their IP.
Source available licenses are about what you can do NOW and it's usually very very clear. For example, don't set up an elastic search SAAS. Of course, you're not Amazon so you won't.
>With a standard OSI or FSF approved license, I don't have to be a lawyer
Apparently you could do with a bit of training because the thing you were most worried about is enabled by a CLA not a source available license.
You are perfectly correct to be suspicious of Microsoft's CLA when combined with their "we turned over a new leaf with OSS" marketing. I am.
>One might call it "FUD"
Not gonna lie: thats the exactly what I was thinking when I read your comment.
If a codebase uses a well-defined license - like, say, the GNU GPL or Mozilla MPL or Apache license - then unless the company is the FSF, Mozilla, or Apache (respectively), then I know with reasonable certainty that as long as they're using that license with that name, the terms won't be changing under my eyes.
The same can't be said of some product-specific "ElasticSearch License" or "CockroachDB License" or "MongoDB License" or what have you. With these, I'm back to having to read EULAs one by one, because the meaning of "$PRODUCT License" can change at pretty much any time.
That is, if you're going to jump immediately to some bald-faced snarky ad hominem like
> Apparently you could do with a bit of training
it would be a lot more effective if you actually understood and acknowledged what I'm talking about instead of going off on some tangent about Microsoft and CLAs.
Now we have to deal with examining and getting approval for umpteen oddball custom software licenses instead of just the standard FOSS ones and, yeah, that is a problem. The pain of dealing with licenses was part of what drove adoption of FOSS in the first place.
The original spirit of open source was scratching an itch and sharing your code in hopes others found it useful. The current squabbles are about large for-profit corporations trying to extract money from other large for-profit corporations, so let's call these new licenses what they are: proprietary licenses with source availability.
Your legal department's inability to keep up to date is not the fault of the open source community.
Corporate legal departments were exactly as useless, intransigent and belligerent when open source was first introduced.
Their tendency towards evil or laziness is not an excuse for anything.
>yeah, that is a problem
With your legal department. THEY need to change. JUST as they were dragged kicking and screaming into the age of open source.
>The original spirit of open source was scratching an itch and sharing your code
No it wasn't. It was about freedom of speech and freedom to do with as you will with what you have on your computer.
It's amazing the number of people I've come across today that misunderstood both the legality and the spirit of open source in a way that Google or Amazon would strongly approve of.
Not everyone has a legal department.
If I'm an independent contractor who wants to sell my ElasticSearch expertise as a service, namely by charging to setup and maintain ES instances on behalf of others, am I compliant with ElasticSearch's newfangled non-free license? Or am I "Amazon" in this context? Judging by how Elastic themselves describe their license[1], it looks a heck of a lot like I'm "Amazon" as far as they're concerned, since my labor would take the form of a "managed service" - never mind that my annual income is several orders of magnitude less than Amazon's, and probably would continue to be such even assuming my services sell like hotcakes.
----
In my opinion, Elastic is being just as selfish and exploitative as Amazon is, which is just as much as any other private for-profit company is.
What I don't like is Elastic putting out PR and pretending as if they are some sort of divine for-profit corporation that doesn't do things out of their own self-interest, but is somehow only interested in open software.
In other words, Elastic is clearly not the same thing as the Apache Foundation, but they seem to want everyone to think that they are.
There is obviously a difference between a monopolistic corporations like Amazon that is actively crushing any competition with its control of the market and a bigger tech company like Elastic that is mostly driven by technological innovation (for now).
Does not mean that one is more morally evil than the other. In fact monopolistic corporations can offer their workers much better working conditions because of the extra profits they make from abusing their position. Well Amazon is not exactly known for that but in general they do. I guess Developer are treated pretty well at least.
So again, the point is not a moral failure but the economic position and the system that creates such a situation. While the creation of big monopolies is more or less inevitable it is still a good idea to be critical of the social and economic dangers.
> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
> The license must not discriminate against any person or group of persons.
Was the DFSG misguided when it was written, or has something changed since then such that it's a good idea to restrict certain people from making use of the program?
A clear winner means more companies use it, increasing demand for it. Which makes it more valuable to master.
If the commodity software is open source, I can learn it at home for a low cost. Then use it at work, again for a low cost. Employers have an interest in using it, as do I.
So I want to encourage Amazon, and other tech companies, to use as much open source as possible! Please increase demand for my skillset!
Of course, the eternal problem is how the software gets developed in the first place. But I really don't want software that bifurcates organizations vs. individuals to become a cultural norm. Even if the impact of any single case is minimal.
The policy exists to enable collaboration and contribution, not to restrict it. These types of policies are common at companies like Amazon. Google has posted theirs publicly [1], and Amazon policies are similar. I have used the policy to contribute to more than one "upstream" open source software package, for example the Xen hypervisor [2].
Though I wish I had more recent commits, this should demonstrate that even in 2012 patches were flowing to Xen. More work on Xen by others can be found by searching for "amazon.co" in the commits [3].
[1] https://opensource.google/docs/
[2] http://xenbits.xen.org/gitweb/?p=xen.git&a=search&h=HEAD&st=...
[3] http://xenbits.xen.org/gitweb/?p=xen.git&a=search&h=HEAD&st=...
Letting the status quo continue would just ensure that Amazon gets even richer off the hard work done by Elastic while development dries up. We all lose while they suck profit out of this product.
It's not like they require elastic to survive. They're too big to fail. By being a dominant cloud provider they have a massive inbuilt advantage
Yes they are different to other cloud providers. They're big enough to throw their weight around and they do.
I'm trying to think of a good analogy. Does anyone have a good one?
How about, the software is analogous to a floor plan. I come up with a great floor plan, and allow anyone to use it for their buildings. But I add a restriction that no one is allowed to sell buildings using this floor plan except me.
So now, if I want to make money with my skills and labor, I'm at the mercy of your architectural firm, which means I'm fundamentally at a disadvantage when it comes to negotiating fair compensation for my labor.