Dual licensing GPL for fame and profit
blog.cerebralab.com
blog.cerebralab.com
As mentioned by others, we can't accept patches to our GPL software without a contributor license agreement (such as a paid contractor position), so make sure you're aware of this before choosing the dual-GPL/proprietary scheme for your own software. This isn't a big concern for us because in my personal experience, a patch that actually saves me time in the long run is very rare (See Quality section of https://github.com/VCVRack/Rack/blob/v1/.github/CONTRIBUTING.... You get what you pay for.) But I'm perfectly fine with doing everything myself or through hired work.
Can you say for certain that this is not directly caused by a policy of having a contributor license agreement? Have you experienced this on other projects that don't have one? It seems by having a CLA you're limiting your contributors to a subset of developers who are willing to sign one.
(Disclaimer: I personally would discourage developers from signing a CLA unless upstream is paying them to do so, since upstream is going to directly derive profit from it)
It is possible that the lack of useful contributions is due, in part, to a CLA being required.
An alternative would be to instead allow the author to keep copyright but require dual licensing (e.g. both GPL and MIT||BSD) for patches to be accepted into the main branch. The patch meets the GPL requirements, and the company can use the other license when distributing the patch with their own proprietary releases. Does that occur?
Is your main objection to CLAs copyright assignment, or that you prefer licensing to be pure GPL, or something else?
Edit: Rack say “To accept a contribution, all authors of the contribution need to: declare the patch under the CC0 license, or complete a copyright reassignment form, or perform the work under a paid agreement.”
The copyright assignment does make GPL enforcement easier by having unified copyright, since courts might require that the plaintiffs in a case own rights to a certain percentage of the work or the specific bits being infringed. But there are certainly tradeoffs involved and not all GPL-based CLAs do this.
The complication is that, if you received the source under the gpl, then you must release your patch under the gpl, too. But I think this can be worked around by the company licensing the source to you under a different license, that allows only submitting patches.
So basically, you effectively submit the same patch twice: once under the gpl, based on the public gpl'd code, and a second time under a proprietary license, based on the same code, offered to you under a proprietary license that exclusively allows sending patches.
Do you think there'd be ways to reduce (or at least assess) the time costs you encounter when accepting contributions, to the point where they'd be more manageable?
Enthusiastic developers can join a virtual meeting (on Discord and/or https://codeshare.io/ or something) where they, I, and anyone else who wants to spectate can discuss a feature from the idea phase all the way to the phase where everyone's personal tasks are designated. A 2-hour meeting is usually all that's needed to start 2 weeks of efficient offline development.
Drive-by PRs by people I've never talked to? Always a mess and never worth the time for me to even read, in my experience. It's odd how the commercial software world has developed this nearly perfectly efficient environment for teammates to work together, and it's completely ignored for many open-source projects.
tl;dr If I wanted to contribute to an open-source project, I'd prefer to work on a major 40 hour feature with the guarantee that my work will be accepted rather than 40 minutes and say "here's a surprise patch, take it or leave it".
I've worked in commercial tech most of my career and agree that industry has done a good job of making software collaboration effective.
Now I'm building applications based on open source software, and (as with commercial development using OSS) sometimes that means that clearing roadblocks or improving application functionality depends on making upstream changes.
I tend to be a bit reluctant to spend time in meetings because I find text-based conversation easier and more accurate.
Also since there are multiple dependencies and projects involved, it's tricky to divide time between developing all of those relationships. It's still valuable to do, certainly, but it can be challenging.
In this scenario, the approach I've adopted is that I'll spend time to fix the problem 'locally' (in a fork if necessary), offer the patch upstream (to feed back improvements, which aim to be generic -- but also with selfish motivations to reduce maintenance burden), and then move on.
Anecdotally, that's working fairly well so far - approximately an 80% merge rate over ~100 pull requests. I don't have great stats on how much time was spent on each, nor how complex each one was. A few definitely took some detailed puzzle-solving and investigation.
I checked out VCV rack when it was posted to HN the first time, and it seemed like a cool toy at the time. I'm blown away by the ecosystem that's built up now. Absolutely phenomenal.
You could just ask for the copyright to be assigned to your company, no? Or is this a precaution against liability from people sending you code they don't actually own?
edit I see I'm late to the party: https://news.ycombinator.com/item?id=24678007
SolveSpace (https://solvespace.com/), 2D/3D CAD app, actually also is dual licensed (GPL+CLA Sign).[0]
Initially SolveSpace v1.x was commercial proprietary[1] (including v1.8), since v1.9 it was unrestricted freeware proprietary[2] and later v2.0 released as FLOSS GPL-only licensed[3].
Few years ago CLA Sign was added by a former maintainer[4] (who bought rights for commercial/proprietary usage of SolveSpace project code from Jonathan Westhues[5]) and now it is riqured to sign CLA for contributing to project source repo on GitHub which is fully covered by GPL license[6] — this is a sorta of something wired looking for me, but idea of dual licensing (such as used for SolveSpace, VCVRack, Ardour, etc.) actually is maybe the best compromise between FLOSS & commercial proprietary software worlds.
[0] https://github.com/solvespace/solvespace/blob/master/CONTRIB...
[1] http://web.archive.org/web/20111228141027/http://solvespace....
[2] http://web.archive.org/web/20121126031632/http://solvespace....
[3] http://web.archive.org/web/20201004063615/http://libregraphi...
[4] http://web.archive.org/web/20201005020156/https://github.com...
[5] http://web.archive.org/web/20100109235957/http://cq.cx/index...
[6] https://github.com/solvespace/solvespace/blob/master/COPYING...
https://www.fsf.org/blogs/rms/selling-exceptions
bkuhn has had more first-hand experience with it. It's been disastrous. The way exceptions are sold are by scaring copyleft users with frivolous copyleft violations and offering them no recourse to correct the violation except by buying a non-free license. Oracle and Mongo are the most famous examples of vendors who bully their users with threats of copyleft violation, telling them the only way to correct the violation is by paying.
https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...
I also have first-hand experience with selling exceptions. My experience has differed markedly from Bradley's. Lots of small companies sell exceptions without any aggressive, professional, commission-driven sales team. Many publish helpful guides and FAQs on their licensing situations that clear up confusion about the (A)GPLs. Some have chosen new or different public licenses, in much plainer language, to avoid that confusion in the first place.
For what it's worth, I remember reading Bradley's secondhand report of shakedowns by MongoDB. I've never worked directly with MongoDB, either, but I was surprised. What I've heard from MongoDB employees is very different: they spent a lot of time sending out "comfort letters" clarifying that people could use AGPL Mongo in their applications without releasing the whole shebang.
I don't think Mongo sends such letters to competing cloud providers. When it comes to proprietary cloud providers, I thought the point of AGPL was to demand cloud users share alike or leave AGPL code alone.
I think Bradley and I would probably agree that big companies have given dual licensing a bad name. But we might agree they've often done the same for permissive licenses, too. I don't think little companies, especially little companies not Hell bent on becoming behemoths or getting acquired by them, deserve the bad rap.
From a business point of view, small companies are precisely where dual licensing matters. Oracle-scale companies can well afford to develop and manage differentiated open/community and enhanced/enterprise projects. If they're selling exceptions for the whole codebase instead, it's likely either dead-end code they don't want to invest in, or they're up to something else, leveraging their other BigCo advantages.
GPL incentivizes people to creates web apps instead of desktop or native mobile apps. This way they can reuse GPL pieces without open sourcing their derived works.
Developers are probably OK with that, they can charge monthly fee for a SAAS, also it’s easier to develop software for just 1 hardware configuration + one web browser (or a few browsers if you support mobile).
However, as an end user, I prefer native apps. They don’t require internet connection. I’m in full control over my data. Native apps are often faster, even smartphones have rather high count of these GFLOPs in both CPUs and GPUs, even when the servers are fast and over-provisioned, network latency often kills the performance.
Despite I never worked on modern web apps, as a user, I don’t believe it’s true. I observe broken web apps more often than desktop apps.
Browsers are incredibly complicated these days, the APIs they expose to developers are less stable than APIs exposed by operating systems. The internet between frontend and backend is a huge source of bugs (latency, end-point security, packet inspection in enterprise, public routers using custom web-based authorization forms). Some web apps collect their dependencies in runtime from all over the Internets and become broken when these third parties update something.
> frictionless install
For mobile platforms or UWP it’s equally frictionless. Windows desktops have ClickOnce, and even with traditional MSI installers clicking “I agree-next-finish” only causes minimal amount of friction.
> no gatekeepers platform
Right, on mobile that’s a very good reason :-(
Mobile gate-keepers historically do a pretty poor job and take a 30% cut for the privilege of denying your bugfix update. Can't recall the last time I had a misbehaving browser tab kill my phone's battery or harvest my contacts without consent; can't say the same about mobile apps.
At these levels of complexity, it’s impossible for these multiple independent implementations to be 100% compatible. As a programmer consuming an API, last thing I want is multiple incompatible implementations of that API.
> Web pages from 30 years ago still load just fine - that's plenty stable.
HTML as a document format is not an API, and is indeed pretty stable even over decades.
Modern SPA web apps don’t view HTML as a document markup language, instead they view HTML+CSS+JS as an API. Unlike HTML as a markup language, I don’t believe that API is stable.
> Third-party dependencies are an issue for all apps, not just the web.
With the exceptions of malware, anti-malware, and other questionable use cases, apps don’t usually download their third-party dependencies from third-party web sites each time they launch. Many web apps do.
> Can't recall the last time I had a misbehaving browser tab kill my phone's battery
Try a page that uses WebGL + web assembly.
> or harvest my contacts without consent
Very unfortunate indeed. I think that was an oversight of platform vendors. Instead of requiring user’s permissions to install apps, they should have given user choice to install the app but fake the APIs with dummy data: black frame for camera when denied, empty contact list for contacts when denied, and so on.
You don't own the copyright to that bugfix right? So how can you re-license it under a commercial license?
What about meaningful improvements instead of bug-fixes? I can see a bugfix being trivial enough. But if someone works hard to improve performance, and then some other company starts selling that work without compensation for the original author?
> You don't own the copyright to that bugfix right? So how can you re-license it under a commercial license?
The way we do it in my project, and the standard practice for Apache (where we copied it from), is tohave a CLA that gives full rights to the original owner for any patches people want to PR.
> What about meaningful improvements instead of bug-fixes? I can see a bugfix being trivial enough. But if someone works hard to improve performance, and then some other company starts selling that work without compensation for the original author?
This is a bigger problem, but in practice I assume it wouldn't happen because if someone were to actually put in weeks or months of work into significantly improving the project, why wouldn't you just hire them or pay them ? After all, the whole assumption here is that this is a model for a for-profit endevor.
This is getting a bit hypothetical, but here's a question. Lets say you're an experienced software developer and you are using an application called "A Large Well-Known Word Processor" that is dual-licensed (A)GPL and proprietary, as explained in the post.
You might really want to add a feature that would save you time for a personal project, or just for your own sense of enjoyment.
Perhaps that feature had been discussed in support forums / issue trackers, and you want to add it as a kind of pro-bono / personal achievement in spare time.
And perhaps the company wouldn't want to pay for it to be developed themselves, perhaps because it competes with a revenue-generating plugin in their ecosystem developed by a partner company.
As I say, it's a little bit "out there" in terms of use cases, but in terms of the freedom to modify, improve and have input into the software that people collectively use, it's a valid one.
Another commentor elsewhere on this thread mentions a potentially-related problem regarding jurisdictions where it's not legally possible to remove your own copyright over materials you've produced.
That actually initially strikes me as a sensible policy, since it reduces the possibility of people being pressured (knowingly or unknowingly, with or without compensation) into losing control of their work.
How do you handle that in practice with the many different law systems around the world, do you just not accept contributions from countries where authors legally cannot transfer all rights?
I am not sure how non transferability of these rights work in combination with authors right to permit those things. What exactly happens if author permits modifications of work? Does it only apply to specific modification and each modification needs to be permitted separately? If not it would seem contradicting with this right not being transferable.
I'm only familiar with Germany because I live here, but from talking to a friend about this recently, the situation is apparently similar in other countries as well. They were looking into using OSS and ran into that issue because they'd also need to look into the (at the time of contribution) home-countries of contributors to make sure that the license would "stick".
Say you work as an anonymous contributor, and all the evidences which could proof the fact got accidentally destroyed, isn't that effectively relinquished your author rights? (Moved the right away from you, the right could still be there but licensed under an non-existing entity)
No, that's just making it difficult to prove you had the rights, not relinquishing them.
However, it gets complicated quickly. For example if they decide to sell the company or take on a new investor, the author could take back the grant under some circumstances which brings its own set of challenges. Can you now simply fix it yourself by writing the same code? Either you'd violate copyright or you didn't need the whole licensing thing in the first place.
Another issue is the fee: you can agree on a fee but if it's not "appropriate", that agreement is void (to protect authors from being tricked with regards to the value of their contribution).
There's a lot of uncertainty involved, which is why companies like using commercial licenses: you can usually trust that the company selling that license has figured out all the details.
Apache is a bad example. While Apache committers do have to sign a CLA, they don't transfer copyright by doing so. A better example is the FSF whose CLA requires copyright assignment.
https://www.gnu.org/licenses/why-assign.html
Some large companies followed suit. The most interesting is Oracle, which went half way: Their agreement makes Oracle and the developer joint owners of the contribution.
https://www.oracle.com/technical-resources/oracle-contributo...
Rich Hickey later adapted their form for Clojure. I'm sure it's happened elsewhere in the Java community.
Opinions on license-versus-assignment this still differ. But other GPL-o-sphere organizations, like Software Freedom Conservancy, have done more public enforcement of late than FSF, without assignments. Especially for the Linux kernel, which has never consolidated copyright ownership in a single organization.
https://sfconservancy.org/docs/blank_linux-enforcement-agree...
When using the GPL, it comes at one huge disadvantage: you cannot accept community patches to the GPL software and use them for your closed-source branch. This is the incentive for companies, to use a more permissive license for some of the software. They can reintegrate community contributions into their closed software product. Of course, this only works out, if the closed software product adds significant value over the open sourced part, or no one would buy it.
You can if the community developers give you permission (licenses) to keep offering the whole project under both open and commercial terms. Happens all the time.
Many companies use contributor license agreements for this. Others simply ask that community contributors make their work available under permissive terms like Apache, MIT, or BSD.
If, like QT, the library is your whole product and you do not depend on the community for contributions, then GPL is great. It forces vendors of non-GPL software to acquire a commercial license, while open source projects can use your product without restrictions.
If it is not your core product and you want to encourage community contributions, BSD and MIT might be the license of your choice. You cannot prevent other companies from using the software, but neither are you prohibited of using any community contributions in your product.
Joel said it the best (in 2002!):
Smart companies try to commoditize their products’ complements.
...
Headline: Sun Develops Java; New “Bytecode” System Means Write Once, Run Anywhere.
The bytecode idea is not new — programmers have always tried to make their code run on as many machines as possible. (That’s how you commoditize your complement). For years Microsoft had its own p-code compiler and portable windowing layer which let Excel run on Mac, Windows, and OS/2, and on Motorola, Intel, Alpha, MIPS and PowerPC chips. Quark has a layer which runs Macintosh code on Windows. The C programming language is best described as a hardware-independent assembler language. It’s not a new idea to software developers.
If you can run your software anywhere, that makes hardware more of a commodity. As hardware prices go down, the market expands, driving more demand for software (and leaving customers with extra money to spend on software which can now be more expensive.)
Sun’s enthusiasm for WORA is, um, strange, because Sun is a hardware company. Making hardware a commodity is the last thing they want to do.
Oooooooooooooooooooooops!
https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
Highly recommended reading it. This blog post gave us right framework to be able to decide which components to open source without worrying about licenses (we have used Apache and Mozilla Public License so far for different projects).
Also, enforcing GPL has turned out to be not straight-forward? If you intend to make money then open sourcing your complements makes so much sense that which license you choose kind of becomes moot (in fact, you're better off choosing a more permissive license like MIT or Apache). If you're going to open source your secret sauce, it better be because you're competing with an incumbent (GitLab -> GitHub; PostHog -> Amplitude) and desire that kind of a differentiation.
Users of your code are only obliged to "Release all modifications" to you if they're distributing the code or binary with you.
This might seem like seem like nit-picking, but I can take your GPL project, work on it and sell it to a dozen companies, and you have no right to my modifications. The companies I've sold to could give you a copy if they wanted. But your rights aren't omnipresent.
They also don't stop me using your code in otherwise proprietary SaaS, again contributing nothing back upstream. AGPL targets this.
GPL is good. It's good for users in a way that few appreciate. More software should be GPL... But there are complexities, far more than I've covered above, that many releasing developers struggle to anticipate.
It's even worse than that. You can sell the software without distribution modifications to the client. You only need to give modifications if the client ask for them.
There is no interest for the client to request unless they want to break off from the software contract. If you're found to violate the GPL, the client will be unable to use the software, they have more to loose than you.
A disadvantage is that it goes against collaboration of people who don't profit from the proprietary version. They need to dual license their contributions by assigning their copyright to the organization (as FSF also requires). How many people refuse to collaborate as a result of this?
The more general pattern of "free under these public terms, else pay us" for software goes back far further. Mosaic and Navigator were early Web-enabled examples. Before that, some "shareware" traded on physical media was feature-complete and unlocked, but license-limited, on the honor system.
Outside of software, in other media covered by copyright, the model is old as the hills, and far older than the Free Software movement. Especially with noncommercial terms for free use.
Were they the first with dual licensing FOSS and proprietary though?
Yes it is. https://en.wikipedia.org/wiki/The_Qt_Company
One thing I wanted to try, but never really got to, was to ask contributors to license additions to a GPL project under the MIT license. These can be shipped under the proprietary license. As long as the original authors continue to do a large part of the work, most code remains GPL preventing proprietary forks and safeguarding your proprietary revenue model.
[edit: clarity]
That said, CLAs usually include protections that permissive licenses don't. For example, CLAs often require the contributor to guarantee they have the rights to license their contributions, and didn't lift code from someone else without proper permission. Anecdotally, CLAs are also just better licenses, in terms of legal implementation. Especially when it comes to patent rights, though no license can completely eliminate patent risk.
I do this, and contributors are fine with it. Commercial licensees don't mind complying with a combined commercial + BSD/MIT license.
All the code is GPL. The contributions are dual licensed to the maintainer as GPL+MIT, which means that the maintainer can relicense them as they please, just like the code they own the copyright for. So other than minor formalities like maintaining a list of copyright owners, the maintainer can continue to release both GPL and commercial versions unimpeded. Keeping track of which lines were contributed in this way going forward isn't really necessary (although a note in the merge commit would be prudent).
The main practical difference between a CLA and actual copyright assignment is when you are suing a violator. At that point it is a bit simpler if there is one copyright owner, rather than asking other copyright owners to join the suit, but it is important to realize that they don't have to join the suit for it to go forward (in fact, every copyright owner could sue the violator independently if they wish). Only when you are the copyright owner of a minority of the software's source code (IOW most of the source comes from contributions) do things get inconvenient in terms of a violator possibly being less motivated to negotiate with you (although that would actually be really stupid on their part).
It's also strange that having made some effort to investigate the space of open-source licensing models, the OP speculates on creating a license that allows for dual licensing but doesn't have the GPL's virality, but is seemingly not aware of the LGPL, or of the relatively common practice of giving a blanket exception for add-ons through some specific interface (such as plugins) to a GPL'd application.
Financially it works orders of magnitude better than asking for donations or individual patronage. Corporations operate on a completely different scale of money.
My favorite projects following this route are Redhat/CentOS, MySql/MariaDB and Virtualbox.
Always happy to add links to index.html: https://github.com/licensezero/duallicensing.com/
We also feature some dual licensors (under "public-private licensing") on https://indieopensource.com. PRs there at https://github.com/indieopensource/indieopensource.com.
There is no universal, be-all, end-all business model for software. But I strongly believe dual licensing gets tried far less than it should, especially by solo developers and small companies.
It's possible to have long and boring discussions about how Linux would have turned out if it had been MIT licensed, but they've been had before. for GNU, the GPL, and the FSF, it's clear that if your project can't survive while protecting the users 4 freedoms, then it does not deserve to exist.
If you want to engage GNU and the FSF (and supporters of either project) in a discussion about dual licensing and the GPL, the 4 freedoms have to be central. It's not an engineering discussion, it's a moral and ethical one.
It is open-source, but disallows commercial for-profit use.
> It is open-source, but disallows commercial for-profit use.
The NPOSL is not disallowing commercial use, it is claiming that the source of the software is a non-profit, derives no revenue from the software (including hosting), and provides no warranty for the software.
In other words, the NPOSL has modifications from the OSL that further protect a non-profit from being sued. A judge (depending on jurisdiction) might look askance at a complete disclaimer of warranty if an implied commercial relationship can be construed between the entities that provided and used the software (for example, through a donation, or perhaps by contributing employee work).
There is probably case law of non-profits being sued for something they provided for free, the NPOSL is trying to protect against that, given that compared to for-profit companies, they are likely to be resource constrained.
You thought correctly. This is usually stated as "the license may not discriminate against a field of endeavor". Besides limiting commercial use, another commonly raised desire is forbidding military or law enforcement use, but those can't be called "Open Source" either, not to mention being incompatible with the GPL.
BTW, compatibility with the GPL is a big deal even if you want a permissive license. One of the big drivers for drafting the Apache 2.0 license was that Apache 1.0 wasn't compatible with the GPL, causing quite a few headaches. Relicensing the Apache Foundation's projects wasn't too difficult, since the foundation requires copyright assignment for all contributions. OTOH, relicensing the Linux kernel from GPL 2 to GPL 3 is effectively impossible even if Linus weren't opposed to it, without tracking down all contributors and getting their permission, or replacing the affected bits of code if they (or their successors) cannot be found or refuse to cooperate.
So one thing you might consider is licensing your project as GPL 3.0 or any later version as published by the FSF, which does mean you would be trusting the FSF not to screw with the spirit of the GPL in future versions. Probably a safe bet for the next decade or two, but then again Linus didn't (and presumably still doesn't) like the changes made to GPL 3.0, so YMMV.
The NPOSL doesn’t prohibit for profit licensees, it includes a declaration that the licensor is a nonprofit, which may (where true) in some jurisdictions increase the effectiveness of warranty disclaimers.
For-profit entities can use NPOSL software freely.
For software licenses that prohibit commercial use, see:
It works fine when you're either a solo developer (or a single group) that holds all rights to the project. It gets really messy as soon as you start to get outside contributions or want to build the community (unless you're a big project like Qt where people will contribute even if they have to assign copyright to you to do so).
I'm going to go a little off topic here, but I think Open Source is being taken advantage of and needs to push harder. We've forgotten the warnings of Stallman.
AGPL does a decent job against hosted services. It's a shame cloud companies have co-opted various open source database and server products and ceased contributions back to the world. With the same hand, they lock people into their managed versions.
Another thing we need to fight against is providing software to companies that put users into walled gardens. We need licenses that require data export and right to forget. Encode the GDPR into our licenses.
Finally, we have to fight back against embrace, extend, extinguish. Apple is trying to take over computing and prevent us from running our own code on our own devices without going through their store. We should prevent them and anyone else trying to do this from using our software.
There's a lot we need to defend or we'll all wind up using opaque thin clients to access walled silos.
Just like pushing for Chrome and now crying that Web has turned into ChromeOS.
Or buying Apple hardware to develop GNU/Linux applications and now crying that macOS doesn't fulfil their use cases, no wonder.
Don't like walled gardens either. But imho the "fight against" should be done by (more flexible) political regulation and not by (rather inflexible) software licenses.
Wait, an off-shoot of the GPL that gives people permission to incorporate your code into their software that they are then allowed to sell non-GPL licenses to?
That seems... unlikely, no?
I don't want to dismiss the entire argument, it is worth consideration. But this particular problem of "chaining" is real and not easily dismissable as "oh, we can just make another license". It is indeed hard to devise a legal regime where you can get the benefits you want of open source (being able to use other people's code in your code), while still preserving your ability to monetize your code.
Corporations really hate anything GPL related and will ultimately purchase commercial licenses at high cost to get rid of GPL if they are interested enough in your product.
Note that dual licensing was first popularized by Sleepycat software makers of BerkeleyDB now absorbed by Oracle. They were profitable during their short lifespan thanks to this approach.
But why does it need to be GPL?
Why not dual license MIT/BSD plus a commercial version with more features?
> Why not dual license MIT/BSD plus a commercial version with more features?
So, what you are advocating here is combining a permissive license (eg. MIT/BSD/Apache 2/etc.) with an Open Core approach.
This can work, but it is difficult. The decisions around which features go into the core, and which are in the commercial version become higher risk. Keep too much proprietary, and the odds of someone in your community duplicating the proprietary features goes up (as it normally would for GPL+commercial), chewing up your commercial moat. But keep too little proprietary and the odds of a commercial competitor duplicating those remaining features and competing with you on price goes up instead. Even the case where they develop a different set of commercial enhancements to target another market (or another pricing model) will probably mess up your commercialization roadmap.
And I'm not sure there is ever a "just right" point between too much and too little, the middle ground will probably have you contending with some of both types of competitive pressure, and may not actually be less overall.
At which point you have to fall back to trademarks and brand recognition, as well as maintaining an edge of expertise by employing the main contributors and/or subject matter/domain experts.
This is a very customer-focused model with practically no lock-in, and can work, but leveling the playing field in that way will make attracting investment harder. Investors want to know what your unfair advantage is, and your licensing choice effectively lowers the barrier to entry instead of raising it.
The idea with dual licensing with GPL is that the user has to either open-source their code, which most corporations will not want to do, or use the paid licensing scheme.
That's part of it (and it's probably dominant when the software is infrastructural and typically has other software built on top of it), but not quite the whole story.
The other part is for software that is more of an application than a component: when your commercial version has additional features aimed at deep-pocketed customers (typically "enterprise" features like SSO, or various forms of compliance). Since these features aren't released as open source, you are the sole source of those capabilities. Someone else could duplicate those features and release them as GPL, competing against you with a completely open source offering, and nuke your profit margin, but what they can't do is duplicate the features and keep them proprietary as you are doing. So anything they release like that is now effectively free, and they don't really get any of the attractive profit margins you had, making it harder for them to recoup the sunk cost of duplicating those features.
IOW, they can fill in your moat, but then can't really dig their own.
This gets back to why big companies release software as open source: Sometimes they aren't just trying to commoditize their own complements, they are trying to commoditize someone else's core to blow their business model up (or more accurately, cause their competitor's market to evolve faster than they are prepared for). Open Source isn't the only possible play here though. A free or freemium offering as well as other tactics can have a similar effect.
I know some companies have had their software nabbed by other companies..... did they not use GPL?
I guess I’m thinking of elasticsearch but surely other companies have been turned into services by big companies?
This is totally OK with the (A)GPL which is why certain companies has tried to come up with new licenses, none of which are compatible with OSI Open Source.
(I specify OSI Open Source here since someone took the time to dig out enough references to convince me (and probably others) that the term open source was used more or less for the same idea well before OSI started using it.)
It is prohibitively expensive for non dollar-based economies to pay for USD commercial products.
Sure, we are probably not the target demographic, but we exist
Really, I think the title is the best explanation of this strategy: you want companies to pay you; you don’t really do this if you care about the freedoms that GPL is meant to preserve. In this case the only purpose of using the GPL is that it scares big companies into paying you and lets individual projects use it for free.
I mean, if this was the case, why provide the source at all ? Or why make it free to use forever ? Why not release it under a license that states usage is only permitted as long as the author allows it, i.e. for a limited trial period ?
My point here is that you can be pragmatic and say:
If some people want to build a free world, fine, I agree with that idea in principle and I will provide my work to them for free.
On the other hand, most people want a paid world, which is also fine, I might as well provide my service to them as well and benefit from it.
You're not doing as much as releasing stuff under GPL-only would, in that you're giving people that pay you an out, but it seems to be better than nothing. Plus, it's a more positive approach than GPL, in that it's not actively "hurting" people that don't want to join the open source community (by not providing them any option to use the product), it's simply giving an advantage to the open source users.
I am specifically making the argument that by doing this you don’t care about the freedoms that the GPL was intended to preserve. Being “open source” without having the other freedoms is desirable to some but I believe not in the spirit of the GPL, so what you really have is a project you claim under one license but you are distributing it on the side with principles that directly oppose it.
> If some people want to build a free world, fine, I agree with that idea in principle and I will provide my work to them for free.
Well, what I’m saying is that the two principles seem directly opposed. To me it feels like you’re operating what you call a humanitarian blood bank where 100% of donations go to people need-blind, but if you add $5 on top of your “donation” you’ll instead sell it on the black market and give me 50% of the price it fetched (let’s assume this was not illegal). If your mission is “I want to help everyone” then this directly undermines that; but if you’re OK with “but my sales on the side help me fund the entire thing so that the actual donations can exist” that’s just another perspective (and possibly a valid one) but it’s not fair to characterize yourself as purely only thinking about running it as a service to only get blood to the people who need it.
> it's a more positive approach than GPL, in that it's not actively "hurting" people that don't want to join the open source community
The GPL wants to hurt people who don’t join the open source community. Like, it actively is designed around that because it believes members of the community who do not participate violate the freedoms of the open source community, and it tries to get people to do this by leveraging one of the few things the open source community has: the projects themselves. Again, whether that is an accurate representation is up to you, but using the license as a stick to prod companies into paying you so they can do the very thing the license was designed to prevent just seems ironic and that’s what I was getting at.
RMS's thoughts on dual-licensing: https://www.fsf.org/blogs/rms/selling-exceptions
that's where there's gonna be some disagreement
And at the same time is fully open for usage that does not sell it as a service?
And there's nothing saying they won't just reimplement your service (see AWS DocumentDB).