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)
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?
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.
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.
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.
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.
> 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.
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.
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.
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.
> 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.
[+] [-] vortico|5 years ago|reply
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.
[+] [-] cycloptic|5 years ago|reply
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)
[+] [-] jka|5 years ago|reply
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?
[+] [-] polytely|5 years ago|reply
[+] [-] reitzensteinm|5 years ago|reply
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.
[+] [-] MaxBarraclough|5 years ago|reply
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
[+] [-] adzm|5 years ago|reply
[+] [-] app4soft|5 years ago|reply
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...
[+] [-] jordigh|5 years ago|reply
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...
[+] [-] reitzensteinm|5 years ago|reply
[+] [-] kemitchell|5 years ago|reply
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.
[+] [-] Proven|5 years ago|reply
[deleted]
[+] [-] Const-me|5 years ago|reply
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.
[+] [-] wffurr|5 years ago|reply
[+] [-] vortico|5 years ago|reply
[+] [-] phoe-krk|5 years ago|reply
[+] [-] rocqua|5 years ago|reply
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?
[+] [-] george3d6|5 years ago|reply
> 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.
[+] [-] saagarjha|5 years ago|reply
[+] [-] _ph_|5 years ago|reply
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.
[+] [-] kemitchell|5 years ago|reply
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.
[+] [-] auggierose|5 years ago|reply
[+] [-] doomlaser|5 years ago|reply
[+] [-] ignoramous|5 years ago|reply
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.
[+] [-] oliwarner|5 years ago|reply
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.
[+] [-] user5994461|5 years ago|reply
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.
[+] [-] Fnoord|5 years ago|reply
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?
[+] [-] kemitchell|5 years ago|reply
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.
[+] [-] pjmlp|5 years ago|reply
[+] [-] raverbashing|5 years ago|reply
[+] [-] geertj|5 years ago|reply
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]
[+] [-] kemitchell|5 years ago|reply
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.
[+] [-] pornel|5 years ago|reply
I do this, and contributors are fine with it. Commercial licensees don't mind complying with a combined commercial + BSD/MIT license.
[+] [-] l3s2d|5 years ago|reply
[+] [-] webmaven|5 years ago|reply
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.
[+] [-] pornel|5 years ago|reply
Financially it works orders of magnitude better than asking for donations or individual patronage. Corporations operate on a completely different scale of money.
[+] [-] jitendrac|5 years ago|reply
My favorite projects following this route are Redhat/CentOS, MySql/MariaDB and Virtualbox.
[+] [-] kemitchell|5 years ago|reply
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.
[+] [-] delusional|5 years ago|reply
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.
[+] [-] tannhaeuser|5 years ago|reply
[+] [-] auggierose|5 years ago|reply
It is open-source, but disallows commercial for-profit use.
[+] [-] seba_dos1|5 years ago|reply
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).
[+] [-] echelon|5 years ago|reply
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.
[+] [-] pjmlp|5 years ago|reply
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.
[+] [-] emteycz|5 years ago|reply
[+] [-] chappi42|5 years ago|reply
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.
[+] [-] jrochkind1|5 years ago|reply
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.
[+] [-] symisc_devel|5 years ago|reply
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.
[+] [-] pjmlp|5 years ago|reply