We (https://vcvrack.com/) do this and it works great for us and our users. Wouldn't give up the licensing scheme for the world. We'll soon release a proprietary fork (Rack for DAWs) of our GPLv3 software (Rack) as a new funding source. It's the perfect funding scheme and has no major disadvantages. The author makes profit from a fork of the software, which requires/causes the GPL version to be actively maintained (since new functionality and bug fixes of the proprietary fork often derive from modifications of the GPL software). And the user has a choice of using the open-source/free software, which they can freely run, review, modify, and share, or purchase the proprietary software. By Economics 101 theory, a "trade" is always mutually beneficial if the user's intrinsic value of the software is greater than the purchase price.
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.
>in my personal experience, a patch that actually saves me time in the long run is very rare
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)
Adding on to this, I personally have improved versions of open source software projects that I just forked for personal use because pushing the improvements upstream would mean having to sign a CLA which is something I am completely unwilling to do.
It is possible that the lack of useful contributions is due, in part, to a CLA being required.
In my very limited experience, CLAs require the assignment of copyright to the company (or foundation).
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.”
Widely used CLAs vary on the copyright assignment issue. The FSF requires one, but for example the pattern originated by the Apache Software Foundation and also used by many corporate open source sponsors including Google does not. It does, however, grant them permission to use and relicense/redistribute your contribution outside the bounds of the Apache license that other recipients get.
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.
I'm no lawyer -- what about a dual gpl/proprietary license, where the proprietary license is granted only to the company recieving the patch, but is indefinite, non-revokable, transferable. Basically, you grant the public the rights of the gpl, and the company the right to do as they see fit. This seems better to me than MITing it, because you don't lose the benefits of the gpl.
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.
We freely accepted contributions without a CLA during the first year after initial release. I can recall one PR that was worth my time, the others would have been easier if I wrote it myself. After learning my lesson, all code has been replaced since then.
That's a thoughtful setup for a project and licensing; it's making me question and consider a few assumptions about open source projects.
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?
Yes, actually. The idea is to imagine the best environment a new intern can experience in a team at a software company and then apply the same principles to treating open-source contributors (if they are willing to dedicate several hours of their time).
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".
Thanks a lot, this is an interesting conversation.
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.
Just want to say thanks for working on VCV Rack, it made modular synthesis accessible to the masses and I have gotten a lot of joy out of it. Keep up the great work!
Off topic, but I'm wondering if you have any plans to have some kind of demo functionality for your commercial plugins? For instance adding them to your account for an hour, or have everything have a demo scene where they're functional but you can't modify connections or add modules (just play with the knobs).
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.
> we can't accept patches to our GPL software without a contributor license agreement (such as a paid contractor position)
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?
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.
Stallman was hesitant but in favour of this. He called it selling exceptions. His reasoning is that selling exceptions merely permits someone else to create non-free software, but that weak free licenses like the MIT license already allows this, therefore, selling GPL exceptions wasn't worse than weak licenses, in his view.
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.
I read the whole thing waiting to get to an example of what a "frivolous" violation is. I probably agree with him or her but it does hinge on that and it's an important detail to leave out.
Best short summary of Stallman's published position I've seen. Nice.
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.
GPL is hardly the primary factor driving web over native. A true write once, run anywhere, frictionless install, no gatekeepers platform has a lot going for it.
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.
Web APIs go through a standardization process and have multiple independent implementations. Can't say that about any operating system API except POSIX. Web pages from 30 years ago still load just fine - that's plenty stable. Third-party dependencies are an issue for all apps, not just the web.
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.
I've developed web apps for years and don't remember any time when I needed to use GPL software anywhere in the web stack. Pretty much all tools are BSD/MIT-like. So I'd say this isn't a contribution for web apps being developed instead of local software.
Which is kind of why the GPL should probably be obsoleted by the AGPL (or even something much stronger, that makes the situation with services being constructed out of libraries and then used two levels indirect more clear).
Great comment: more in general, dual licensing favors (or at least, does not stand against) the development of proprietary software -- so it may be ok for current users of the GPL licensed product, but it definitely impacts the direction of innovation
How does dual licensing work with 'downstream contributions'? If some user finds a bug in your GPL code, fixes it, and pushes that code to your repo?
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?
> How does dual licensing work with 'downstream contributions'? If some user finds a bug in your GPL code, fixes it, and pushes that code to your repo?
> 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 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.
> 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.
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?
In many EU countries author has inalienable rights: right to be recognized as author and name to be appropriately stated if author desires it, right to permit or prohibit modifications of the work, right to revoke the work, but doing so requires author to compensate for the losses revocation causes.
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.
Germany. You can license your works, but you can't relinquish your author rights ("Urheberrecht").
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)
> 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?
No, that's just making it difficult to prove you had the rights, not relinquishing them.
IANAL, but my understanding is that, while you can never ask anyone to give up authorship, you can ask them to transfer copyright. I.e., you are still the author of your patch, your name should be visible as a contributor (should you want to), but you transferred the rights of that patch.
I'm not a lawyer either, but from what I understand: the rights you can transfer are limited, and you can generally only give usage rights, potentially exclusive usage rights that also exclude the author from using the patch.
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.
> 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.
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.
Most dual licensing companies I've seen use contributor license agreements, not copyright assignments. Based on published materials, FSF's peculiar desire for assignments stemmed from some early concerns about court procedure for license enforcement:
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.
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.
Dual licensing is a very fine method to make code available as open source and keep it a commercial product too. The GPL is a license which has worked for this, QT is a good example. This works best, when the dual-licensed software is the large part of your product.
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 cannot accept community patches to the GPL software and use them for your closed-source branch.
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.
Many people are unwilling to sign CLA. I wanted to submit patch fixing blatant and ugly typo in README. After I got notification about requirement to sign pages of legalese I switched to doing something else and decided to never contribute to this project in any way.
I think, and I tried to express that with my post, there is no one ideal license. It completely depends on the situation.
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.
> Why can Google develop TensorFlow? Because they can make a lot more money from selling/renting TensorFlow optimized hardware.
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.
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.
It's not good that articles about GPL still can't get the terms right. It's important to understand your position as a developer.
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.
>> 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.
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.
Who pioneered this? Was it TrollTech with Qt? (Author mistakenly calls it QT.) Or actually FSF themselves?
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 canonical "founding father" of free/open software dual licensing among FOSS wonks is L. Peter Deutsch, of Ghostscript fame. His companies ran a number of business models in their early days, dual licensing among them. The canonical "popularizer" is probably MySQL AB, followed by Trolltech/Qt. These days, Open Core is riding high. Dual licensing also had its day, and may again.
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.
I know Qt changed ownership (including being bought by Nokia). Qt Group for sure did not pioneer it as they didn't exist in the 90s. Not the same company as TrollTech.
Were they the first with dual licensing FOSS and proprietary though?
The common solution to the ‘contribution problem’ inherent in dual licensing is a CLA. That never really appealed to me. It makes it harder to accept occasional contributions, while I also find it somewhat dubious to ask people to transfer copyright to a for profit entity without paying them for the work they did.
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.
Echoing others: There's nothing wrong with taking contributions to a copyleft project under compatible permissive license terms.
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.
> In this scenario, how do you track which parts of each file are GPL and which parts are MIT?
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).
Nice article, though the analysis is a bit simplistic (Facebook and Google's motivations for making Pytorch and Tensorflow open source are much more strategic than reduced training costs and revenue from hardware).
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.
I did this for some of my projects and it worked quite well. I think it's a nice balance between supporting free software community, and avoiding being a sucker who does free labor for corporations.
Financially it works orders of magnitude better than asking for donations or individual patronage. Corporations operate on a completely different scale of money.
I also support dual licensing the projects. It allows companies to release reasonably good part of their product in public domain, while still catering the needs of enterprise clients. Mostly they also release some part of awesome enterprise features in gradual timeframes. we can fork and release community versions according to our needs(respecting IP and trademarks of company). We can also contribute upstream changes by dual licensing our contributed code with GPL and to their proprietary contributor license.
My favorite projects following this route are Redhat/CentOS, MySql/MariaDB and Virtualbox.
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.
Cool article. I like the topic, and I think it makes some fair points. I do have to question the use of the quote from GNU, because it doesn't engage with the GPL where the GPL is. The GPL is not a guide for how to create a software project that survives. It's not a license optimized towards maximizing funding for project. The GPL exists as a tool to protect the 4 essential freedoms.
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.
I'm probably stating the obvious, but GPL licensing (AGPL, even) hasn't worked so well for MongoDB, Redis, and many other projects/products in these times of SaaS. In fact, the proliferation of SaaS business models can be seen as a direct consequence of the abundance of F/OSS software.
> 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.
Thank you for correcting that! I read the license more careful now, and you are indeed right. I confused licensor with licensee. I was wondering about it, because I thought that open-source must allow commercial use under the OSI definition.
> I was wondering about it, because I thought that open-source must allow commercial use under the OSI definition.
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.
Idk I thought the problem isn't so much self-hosting by end-users (commercial or not) but "cloud vendors" able to provide services build by others in aggregations and at price points those others can't meet, precisely because of their development costs.
As far as I understand the NPOSL-3.0, cloud vendors would definitely count as for-profit, and therefore not be allowed to use the software, even in an aggregated way. They would have to obtain a separate license.
> As far as I understand the NPOSL-3.0, cloud vendors would definitely count as for-profit, and therefore not be allowed to use the software
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.
Yes, but the sweet spot for many services is the ability to offer hosting while allowing self-hosting, free dev licenses, and third-party integrations. It's a particularly good no-brainer sales story to contrast with self-hosting dominated by admin/HR, and possibly hardware/data center costs.
I don't think this idea is as pragmatic as the author thinks it is.
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).
> It's a nice compromise for moving towards a more open world, without having to live in Stallman's communist utopia.
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.
Yes, this is the correct way to fight Apple and such (even though I don't think they are a threat to open source). Don't let them use the software if they don't want to do it our way, just like they don't let us use the hardware if we don't want to do it their way.
> 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.
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.
I don't understand why should we work hard to get all (or half, but that's still billions) people in the world to do this if we can simply write it into the license terms and use the already existing legal framework made exactly for this purpose. I also don't understand the claimed inflexibility, IP rights are one of the most flexible pieces of legislation I know, and your license can be as flexible as you wish too. On the other hand, what in the hell is flexible about laws made only for this purpose?
> Still, this seems like the kind of problem that could be fixed by an off-shoot of the GPL meant for just this use-case.
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.
At PixLab, we believe this is the right approach to license SDKs & C Libraries. We did this with our embedded Computer Vision Library (https://pixlab.io/downloads) and it did works quite well.
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.
I also think this is the best approach, it allows for commercial use, and anyone that doesn't want to pay for it, gets the same commercial benefits as they are willing to give upstream.
> 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.
This is addressed in the article, if you license your software as MIT, whoever uses it is in their right to do essentially whatever they want with it, including using it for profit without paying you a dime.
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.
> 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.
Certain companies have complained because other companies made a profit from selling hosting of their (A)GPL software.
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.)
There is a lot of daylight between the extremes of hobbyist programmers and google in terms of making money on open source without gpl dual licensing. Two immediate examples that come to mind are sqlite (for profit) and the zig foundation (non profit).
Small players are still free to use the software under the terms of the GPL. What if the software were only available under the GPL with no commercial licensing option? The small players would be in the same scenario.
From an entirely moral perspective, dual licensing GPL never really felt right to me. You’re basically giving the people who are the most likely to not care one bit about the license an “out” where they don’t have to respect it anymore. If you claim your project is GPL but I’m using an device with some derivative of that project’s code in it but I can’t get the source, then I’m not getting the benefits of it being GPL.
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.
> you don’t really do this if you care about the freedoms that GPL is meant to preserve
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 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 ?
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.
I think you're right in that it is somewhat against the spirit of the GPL. That said, I'd like to offer another perspective: Dual-licensing with the GPL allows for the open sourcing of programs that would otherwise have been proprietary. I think this benefit greatly outweighs the moral quandary. The potential for forking alone is a huge boon to the open source community.
Slightly tongue-in-cheek, perhaps: the people who benefit from a paid world might want a paid world, while they might also want to continue to reduce their costs.
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.