In other words: Don't do open core?
Dual licensing, more than any other common open source business model besides paid development, maintains the link between value of software produced and value for which customers pay. If a customer can't use the software under its public license, perhaps because the license requires release of code they want to keep closed, they pay for a license. The value of the software they become able to use, under paid license, sets the price you pay. Meanwhile, all the development work the vendor's people do goes into the product for which customers pay a price.
The article seems to imply that dual licensing is all or the crux of Mongo's business model, when it's only a relatively small part of their package offering. That can be hard to see, since both under AGPL and under the new SSPL, Mongo's choice of public license doesn't prevent developers from creating closed, proprietary applications using Mongo as data store. As they seem to intend it, Mongo dual licensing covers only platform developers who offer Mongo itself as-a-service to application developers. I hear tell the company has actually spent substantial time sending letters to users clarifying that they didn't need to buy a separate license to use Mongo in their closed apps under AGPL.
Isn't this by itself an oxymoron? Open source isn't shouldn't be one's marketing stunt to gain attention, if you want to charge your software make it proprietary and charge people for license. Using open source as a last resort bait isn't cool.
My only jab at Amazon is that they should give back their code to the community or they need to be forced to do so, not that they can't make money from OSS software, if that is what license at the time, permits.
Presumably that's why, in the words of the parent poster, the dream is dead.
https://licensezero.com/licenses/parity
It also has a patent license, unlike many permissive ones. They shouldnt even qualify as open source if you can get sued under patent law for using that software. Need some patent protection in license.
Can I call my program "Open Source" even if I don't use an approved license?
Please don't do that. If you call it "Open Source" without using an approved license, you will confuse people. This is not merely a theoretical concern — we have seen this confusion happen in the past, and it's part of the reason we have a formal license approval process. See also our page on license proliferation for why this is a problem.
Is <SOME LICENSE> an Open Source license, even if it is not listed on your web site?
In general, no. We run all licenses through an approval process to provide an accepted standard on which licenses are Open Source, and we list the approved ones. Be dubious of claimed Open Source-ness for licenses that haven't gone through the process. See also the license proliferation page for why this matters so much.
No, it isn't: https://opensource.org/licenses/alphabetical
A few issues:
> 3. Contribute software you develop, deploy, monitor, or run with this software.
That goes farther than the OSI, FSF, or DFSG allows, extending into software that is not in any way derived from the licensed software.
It's also not obvious from the license that it allows private modifications that aren't distributed to anyone.
> To contribute software, publish all its source code, in the preferred form for making changes, through a freely accessible distribution system widely used for similar source code
This requires that you publish your code publicly, rather than just providing it to those you provide binaries to.
Parity conforms to the Open Source Definition as written. "Is it open source?" and "Has OSI approved it?" are related, but distinct, questions, as acknowledged by OSI process.
OSI-approved copyleft licenses already sweep broader than derivative works of the licensed software.
OSI has approved copyleft terms requiring contribution back of private changes.
That's less important than another realization I've had since we last talked about licenses. I've determined that most OSS/FOSS licenses actually oppose freedom in practice. You get less software freedom and high-quality software with source over time following those models due to their built-in weaknesses. I wrote specifics in one comment and a follow-up replying to Cantrill's recent analysis:
https://lobste.rs/s/0h98nl/it_s_not_okay_pretend_your_softwa...
https://lobste.rs/s/kbcjnx/open_source_confronts_its_midlife...
The OSD is the popular, widely used definition, as opposed to simply "source available". In general, I've found a roughly 100% correlation between people who try to say that "open source" should mean something other than the OSD and people who have a vested interest in pushing something that the OSD wouldn't permit.
> The goal of copyleft is supposed to get modifications shared.
Under an open source license. Otherwise it's just an incompatible proprietary ecosystem that happens to encourage sharing within its walls. That doesn't help or contribute to the open source community at all.
> They need to update their requirements to match reality
Proprietary software vendors come and go, and they often think that the requirements should change to accommodate them. The world goes on, and people whose requirements include open source licensing continue to ignore software that doesn't meet those requirements. This is not new; there has been a steady progression of custom non-open licenses that try to blur the line for just about as long as FOSS has existed. Long before there was "commons clause" and "license zero" there was Microsoft's "shared source". It failed then, and it'll fail now.
I've already seen a number of conferences this year with talks on the agenda about the problems of non-open licenses that attempt to pretend to be open, and how to work around them.
Regarding the comments you linked to, "License Zero" is even more blatantly non-open. And multiple people already provided detailed issues with those comments, to which I have little more to add.
"open source" is a bright true/false line for a reason, much like "non-toxic" or "food safe". If you want to build something proprietary, go ahead, but trying to pretend it's open is harmful FUD.
Remember I shifted to talk about Parity license which forces all modifications to be shared regardless of intent or distribution model. As in, every change is available to anyone who wants it. Whereas, your open source licenses have led to many "incompatible, proprietary ecosystems" that used their code to build such things. Parity leads to more open code than open source given it tries to allow no loopholes to build walled gardens or hide code.
""open source" is a bright true/false line for a reason, much like "non-toxic" or "food safe". If you want to build something proprietary, go ahead, but trying to pretend it's open is harmful FUD. "
It's not, though, because it's built on a legal system that isn't true or false. Quick example where we'll apply a modern strategy to older times:
1. UNIX spread everywhere. Your goal is to make a UNIX application that every gets and benefits from under open source license. You do that.
2. AT&T sues you for copyright infringement. They claim API's are copywritable. They win. Your app is now illegal and you owe money.
3. They promise to sue other people who didn't buy app-building licenses from them.
Is your open source app really meeting the goals of open source if you (a) can't legally use it, (b) can't legally share it, and (c) anyone who tries might get sued? I don't think so. Next example:
1. 3G is invented. Some company patents it. Telecoms standardize on it.
2. Your goal is to write open-source stack for cellphones. Folks want 3G. You develop and release as open source a 3G stack people start integrating.
3. You and many of them get sued in patent courts that determine you're infringing on a patent. Note that patent law says you not only can't distribute patented works: you can't even create a duplicate. You have to stop distributing it immediately, pay damages, and, if wanting use to continue, negotiate a licensing package with them with upfront, annual, and/or royalty costs.
Is your open source app meeting the goals of open source if you (a) can't legally write it, (b) can't distribute it, and (c) anyone who uses it might get sued? I don't think so.
Now a big picture example. Microsoft and Apple use BSD-licensed code to help build their proprietary platforms that rake in billions of dollars. Then spend millions of that bribing politicians to strengthen copyright and patent laws in a way that facilitates lawsuits against competitors, including OSS developers or companies. They set things up so building compatible products is either illegal or financially dangerous. They also push for the patent laws to stay allowing broad, non-really-built inventions that exist only on paper to make lawsuits numerous and easy to win. The open source code has actually facilitated a reduction in software freedom across the board by sending piles of money to evil companies opposing software freedom who actively change the law to support their goals.
So, you have lobbyists, courts, and patent law attacking software freedom. Whoever has the most money on that gets more ground over time. The good folks maximizing freedom need piles of money to fight back (see Oracle vs Google). Within this environment, you are pushing licenses that mostly send money to the folks opposing freedom while only giving a trickle to those supporting it. You're also pushing licenses that allow them to hoard software in many cases that generates this wealth. Those licenses not only don't help the goal overtime: they erode it by giving the other side power and ability to build walled gardens. Obviously, something needs to change to reduce the fortunes evil companies can build off of software to send more of that money (or at least opportunities like w/ code changes) back to the good guys.
The loophole-filled licenses that you're pushing already led to laws and court rulings that worked against freedom. Folks were warned. FSF had right idea but tried to be too soft on commercial side. Look what happened. Now, you're still acting like the licenses aren't contributing to the problem while saying your goal is more software available with source for more people with less walled gardens. Parity forces source to always be shared with no walled gardens possible. I don't see how you talk about proprietary and walled gardens in relation to Parity if it makes them impossible, but the licenses you push already led to a ton of them.
I mean, feel free to reject Parity for any flaw in it achieving its goal of opening and sharing software. Just don't make stuff up like how forcing release of source code creates walled gardenes. Maybe you were thinking about Prosper, which is proprietary with its own benefits. Since you're an OSS guy, I was highlighting Parity since it's more in line with your goals. With no loopholes benefiting companies fighting against software freedom.
Apart from that, this is nothing that hasn't been seen in every past "it's hard to make money on Open Source" argument. Meanwhile, people are busy making money on Open Source.
Please don't build random non-open licenses and call them open. If you'd like to call your license open, go get OSI to call it open.
They might come up with something. License Zero author has done a remarkable job of focusing on root causes and simplicity to prevent that. When he worries about commercial use, he says commercial use triggers the requirement. When he wants changes released, his license says any change has to be released. Use, changes, and combining with other works in an app are about as all-encompassing as you can get in a simple license. Whereas, Open Source and Free Source focused on linking and distribution which have plenty of complexity that corporate imaginations might work around. Which they did to tune of billions of dollars and plenty unshared improvements.
"What rulings are you referring to that "worked against freedom"?"
Oracle's API ruling, risk of patent suits, and next string of problems lobbyists and lawyers invent. Stuff would've been worse if we didn't luck out with giants IBM and Google paying for the legal battle. With [F]OSS-centered lobbying, we might have even got better laws and protections on these issues. [F]OSS sends most of the money to the opposition, though, with their main licenses and strategies.
"hasn't been seen in every past "it's hard to make money on Open Source" argument. "
I said you can loose money if they patent sue you or pull some stuff about API. These are real things in real court cases. I said it isn't really open and free to distribute if that risk exists. So, we have to mitigate it. I don't believe you when you say it's what open source discussions have always involved if my comments are the only ones I've ever seen here bringing this stuff up. Most comments about money and open-source are about making it profitable to the developers, not funding work in Congress and courts to protect our freedoms.
"If you'd like to call your license open, go get OSI to call it open."
I call mine shared source or source available per your prior advice on that. (Thanks again btw.) Prosper is shared source. Parity is free with source-sharing with maximum copyleft and some patent-suit protection. Looking at OSD, Parity appears to meet every requirement except No 9. That one specifically facilitates proprietary software and walled gardens built on top of or alongside open source code. Since Parity has copyleft for bundles, it can't be open source under that definition. Debian has that same provision, too.
It does have the four freedoms in a mandatory way that kicks in on any change, not distribution models or other guesswork. So, it's Free as in Speech Software that forces all freedoms to happen on derivatives of and bundles with the software with some patent protection. More freedom-preserving than OSI licenses in more situations. So, you're right that it shouldn't be called open source since those are less free and allow more corporate damage than Parity.
That's where we fundamentally disagree. People who are building and contributing to FOSS are not "the opposition" just because they're large companies; on the contrary, it's a huge success story of FOSS that it's powering billion-dollar industries, both by supplanting proprietary software and by enabling use cases that don't even exist in proprietary software. The size of the whole pool is growing.
> I said you can loose money if they patent sue you or pull some stuff about API.
There are multiple licenses that address that, such as by including an explicit patent grant; that prevents the "submit code and then sue people who use it" problem. And there's absolutely nothing you can do to prevent patent lawsuits from people who aren't subject to the license, short of reforming the patent system (which, please, by all means do if you can).
And regarding API, similarly, some licenses include provisions that would prevent someone from suing over code they submitted, and beyond that you can't protect against people outside your ecosystem suing you or others inside your ecosystem.
> not funding work in Congress and courts to protect our freedoms.
There's a substantial and constant conversation going on regarding how to better improve laws to support FOSS.
> I call mine shared source or source available per your prior advice on that. (Thanks again btw.)
Thank you, I really appreciate that.
Steam and the major app stores take 6X that much (30%) just for distribution!
If Unreal is better than Unity, then it seems worth paying for.
I guess only when developing their own engine is cheaper for them.
The real competition is not Unreal vs. Unity, but both Unreal and Unity vs. e.g. Blender. (Which was actually funded as an open source project by its users, back in the day. But at a relatively low 'valuation', compared to Unity!)
This is just not true in reality. Open source projects cost generally the same as closed source projects. Companies like mongo and unity employs about the same amount of engineers to work on it and the idea of high cost savings due to thousands of randos contributing code is vastly exaggerated. Same cost + no profit + having to develop a secondary core competency in a competitive commodity business like support and hosting = dangerous and non-scalable model.
Also never heard of a game using the Blender game engine...
https://www.linux.com/publications/estimating-total-cost-lin... (mind you, that's 2008 data. I couldn't find more recent estimates)
Mongo is quite unrepresentative here - not least, because they're selling the very same software (MongoDB) under both OSS and proprietary licensing! A better comparison in the database space would be e.g. PostgresSQL - the latest versions of which, BTW, are including "NoSQL"-focused features that make it quite competitive with the likes of MongoDB.
https://finance.yahoo.com/quote/RHT/
Market Cap 31.055B
S&P 500 Component
Responding to some of the other comments, Red Hat revenue is nearly all from providing enterprise support for completely open source software. This is critically different from "services", ie consulting. These are yearly contracts that provide clients insurance if/when they have a production issue, a new major vulnerability is disclosed, etc, that someone knows the technology from the ground up and also knows the details of their deployment and can get them back into a good state. Our support+engineering teams are top notch, so retaining customers year over year is relatively easy.
I work in Red Hat Consulting, which is a much smaller share of overall revenue. It doesn't scale nearly as well, since you only get revenue periodically for weeks to months at a time, with a lot of overhead to sell and manage assignments.
Paul Cormier has it right - "We're an enterprise software company with an open source development model". Not an open source company.
However, you're correct. Red Hat's value prop is in top notch support.
More on unity: https://arstechnica.com/gaming/2019/01/unity-engine-tos-chan...
Here's the main difference between unreal and unity. Unreal costs 5% royalty per sale, meaning their product is extremely expensive to the developer if sales are high. Unity is generally royalty free and relies on "support and services" to make money. This is why Unreal will always encourage the growth of the ecosystem while Unity jealously guards the actual profit centers of the business, because Unity makes nothing on its core product!