An alternative to "dual licensing"?
freakboy3742 opened this issue · 11 comments
A frequent refrain for open source's funding problems is to adopt dual licensing. In some situations, this definitely works (Sidekiq is a clear example). The model is usually stated in a way that requires that the "Free" version to be GPL'd as an mechanism to make the code impractical to commercial interests, forcing their hand into buying a commercial license.
This can definitely work, but the GPL does impose a very specific set of requirements on code that might be incompatible with broader project goals. It also creates (or encourages) a walled garden approach to "Pro" content.
However: a software license is granted, not an absolute property of the software that has been developed. While convention is that FLOSS licenses are offered to all without restriction, is there any reason that they have to be offered unconditionally?
As an analog - if I write proprietary software, I'm not required to sell it to anybody who asks - I can refuse to sell to certain individuals. This usually happens because they can't afford to pay, but it could also be because I don't like what you're going to do with the software. For example, I've personally been on the receiving end of vendors refusing to sell software to me because they thought that I was going to develop a competing product, and they didn't want to give me an easy way to match their feature set.
So - would it be possible to license software under any license (GPL, BSD, whatever), but only grant that license to companies under certain conditions - for example, "If you generate revenue > $X/month, you must pay to have this license."
Theoretically, you could also use this as a basis for restricting on ethical grounds.
This would seem to appease free software purists who don't want a license restriction preventing redistribution, by tackling the problem at who gets the software in the first place.
Here are the obvious objections I can see:
The free software definition requires that software is usable by all!
No, the free software definition says that you have (0) the freedom to run, (1) the freedom to study, (2) the freedom to redistribute, and (3) the freedom to modify. It doesn't say that I, as the author, have to give you the software in the first place. This is the the core tenet that makes dual licensing possible - I'm not required to give you a license - I just can't restrict your freedoms once I've given you a license.
I can, however, refuse to give you a license for future versions.
What about software redistributors?
This is the biggest problem I see with this approach - I can't give my software to Redhat without restricting their right to redistribute. The two responses to this I can see to this are:
- Granting a license to redistributors on the basis that they impose the same restrictions on ownership. This probably wouldn't be plausible in practice - Debian, for example, has a history of rejecting "creative" licensing deals and/or requests.
- Don't worry about it, and accept that your software won't be packaged with the OS. Depending on the software, this might not be a problem. For example, if you're writing a Python library, "pip install" is generally the preferred installation mechanism anyway. It could even work to your advantage, as you know that the OS vendor isn't going to b*gger up your code (Ubuntu packaging of Python, anyone?)
What stops a commercial entity from giving away their copy?
Stricly, nothing. But, a large commercial entity that has paid a lot for software is unlikely to start giving away something that they've paid big money for.
Why would a commercial entity honour this license? Won't they just play games, get an employee to download the code privately, and get them to provide it internally?
The lesson of the RIAA and MPAA over the last 20 years is that if you provide a way for people to do the right thing, they'll do the right thing. Provide a way for people to get access to music and movies legally, and piracy will evaporate to the point nobody cares.
This approach isn't about trying to stop all piracy, or stop all freeloading. It's about providing a channel by which it is possible to ask someone for money on a basis other than donation. Small companies will probably ignore the license requirement - but they probably also don't have the money to pay. Large companies need to be able to validate to their accountants that there's a reason why they've got an expense on their balance sheet. Huge companies have legal departments who will look at the legal agreements they've got, and panic if they're not completely above board. But it's also the large and huge companies that we want to pay, because they're the ones with the biggest capacity to pay.
Can't I do an end run around this by setting myself up cloning the repository and giving it away for free?
Well, sure. But, again, see the previous point - this is about making it easy to do the right thing.
As an added enforcement, you could also use the project Trademark - refuse to license the use of the name to anyone redistributing in a way that undermines the revenue stream. This is effectively the approach that Mozilla used leading to Iceweasel (although dispute was over code modifications, not revenue/redistribution).
What about code from contributors?
That comes down to project contribution guidelines. You could use copyright assignment, CLAs, or tacit agreements that all code contributed to the project comes with a license to redistribute as the project sees fit.
I think that in principle this is possible. I also think it's a really exciting idea: rather than granting a licence to everyone in the world under the BSD conditions, you grant a licence to a certain class of the public under those conditions.
There is a bit of nuance in how this is done. You have to figure out how you deal with growing companies (making the licence automatically terminate on the threshold being crossed is an initial suggestion). You would also probably want the licence to be "infectious" in the same way as the GPL, so as to prohibit re-licensing. This should also (at least in law) prevent the problem of someone else cloning the repository and giving it away.
If this is something you'd like to progress, let me know. I'm an IP lawyer and I'd be happy to be involved in drafting something up.
EDITED: The lesson of the RIAA and MPAA over the last 20 years is that if you provide a way for people to do the
rightlegal thing conveniently, they'll do therightconvenient thing
Sharing culture is an morally good thing to do. In all cases, people are doing whatever is convenient as well as generally being moral (most people recognize that sharing culture is not "piracy" at all, it's sharing, and it feels good and right).
But yes, convenience is the big thing here. Yes, make things convenient, people will go along.
Anyway, of course you can limit who you give FLO licenses to. And, of course you can't stop them from redistributing to others, but you can ask them not to. You can also ask people to donate. In other words, you can have a FLO license openly but say "I am asking you to donate if you get this software, even though you aren't legally obligated to". Various forms of requests work.
The issue here is that you don't build a commons with widespread participation by limiting who gets a FLO license.
@wolftune The catch, though, is that some measure of legal obligation makes it much easier to raise money. One thing that has been reinforced for me with multiple companies is that if you want to get money, you have to provide something they wouldn't get otherwise.
Dual licensing achieves this by putting a commercial license terms, but requires something to prevent commercial entities from using the "free" product - like the GPL.
Donations can work, but they're a lot more effort. Any payment that is optional is indistinguishable from a donation. If I'm not compelled to pay, why should I pay? That's why donations usually come of of marketing budgets, not engineering budgets - because donations are done for marketing visibility, not for engineering reasons.
I agree that this isn't a very sociable way of looking at things - or even a long sighted way - but it's the way someone from a large corp looking to validate their expense claim needs to look at things. "I got something that I couldn't get otherwise." The barrier to use doesn't have to be high - it just has to exist, so that someone can validate their expense/budget claim.
Yeah, absolutely. But there's a potential slippery slope where if we play the "special access" card, we risk turning to proprietary thinking and lose sight of the whole point of why we care about funding FLO in the first place.
FWIW, I think as a longer term strategy, if we can convince more companies to stop spending their engineering budgets on proprietary software, it could leave more for FLO… so I don't want to see things that discourage companies from going FLO or that reduces the advantages of FLO which thus makes it less strong competitor to proprietary…
I do like the idea proposed here -- or the following variant: "if you have more than $1,000,000 in revenue and neither a non-profit nor a worker-owned cooperative you must pay to use this software within 12 months of its release date" after 12 months you can use it according to MIT/BSD/GPL. All large companies using the software who wanted to get bugfixes would have to pay.
I would not be bothered if, for example, Django used this kind of license provided all contributors got some say in how the money was distributed.
@ariddell and if "All large companies using the software who wanted to get bugfixes would have to pay." is true, then you threaten the entire core aspect of Open Source development where existing users can contribute bug fixes etc. and have an ecosystem like that. And could end up with a fork like MySQL / MariaDB etc. because the community wants to participate and doesn't want this sort of half-assed situation.
@wolftune That assumes that companies are actually contributing back bug fixes, which in my experience is a big if. Most companies seem to fork internally, and never contribute back fixes, if they use any non-stock modifications at all.
@ericholscher are you considering in that the case of individuals who use something at their company and contribute back their fixes? At any rate, my point is that if a license actually stops big companies from getting the updates, then it will also hamper the non-big-company community. If, on the other hand, you say "we aren't going to give big companies the updates, but we aren't stopping others in the community from sharing", then that's weak but feasible. Look at Ardour — they block downloading of the binary unless you donate (and that could be adapted to discriminate for various types of users), but since it is FLO still, people can get it other ways such as through repos that others share. The concern is: how much does this hamper adoption vs encourage donation? Reducing the size of the audience isn't great. Even big companies using something can be part of general awareness and adoption. And certainly the last thing we want is to encourage big companies to keep funding the proprietary competition because they feel weird about the terms for some sorta-FLO software. The more the proprietary competition is funded, the harder it is for FLO to compete.
Whether or not this threatens the "entire core aspect of Open Source
development where existing users can contribute bug fixes etc." strikes
me as an empirical question. How many of Django's bug fixes would likely
not have been contributed under this system? I think plenty of the bug
fixes would have been contributed.
If the alternative-to-dual-licensing-license did elicit a lot of
blowback from the relevant community then one could also revert back to
the standard open source license. It seems like the only people who it
would piss off would be the stockholders of large companies. I'm not
sure why employees/developers (those who are not stockholders) would
care about this provision.
p.s. I'm making the assumption here that at some point the code does get
released under a standard open source license (e.g., after 1 year). I
would never support using a license that didn't have this kind of
provision.
On 12/04, Aaron Wolf wrote:
@ariddell and if "All large companies using the software who wanted to
get bugfixes would have to pay." is true, then you threaten the entire
core aspect of Open Source development where existing users can
contribute bug fixes etc. and have an ecosystem like that. And could
end up with a fork like MySQL / MariaDB etc. because the community
wants to participate and doesn't want this sort of half-assed
situation.--- Reply to this email directly or view it on GitHub:
#61 (comment)
@ariddell My concern with the "open source after 12 months" is that you don't want to incentivize behavior that disadvantages desirable behavior. The "cheapskate" response to that license policy would be "wait 12 months before you update", which would mean insecure systems in the wild - which could lead to a reputation of a tool/library being insecure (because so many of the installs are vulnerable!).
@freakboy3742 I see your point. I think the "sunset provision" here would be worth it because it would be a strong signal of commitment to the underlying ideals of of FLOSS. Perhaps a compromise would be to have different "options" à la the Creative Commons licenses (BY-CC, BY-CC-ND, BY-CC-SA,...).
In any event, I think that this approach has considerable promise since we know that a similar approach, dual-licensing, has raised significant amounts of money (even if we don't like the idea of dual licensing). It also seems like the approach might potentially involve less work than mounting donation drives.
There also seems to be a minor groundswell of interest in articulating a different kind of license that specifically responds to the paying-the-piper question. There's the Fair Source License, the Peer Production License, to name two examples.
My concern is the overhead of managing a legal entity that would collect money and deal with the CLA (which seems required in this case). Might be difficult for small/medium projects to do this.