What this amounts to is an attempt to solve the challenges of monetizing open source software by no longer writing open source software. The encumbrances that this license places on the downstream modification and redistribution of code largely eliminate any of the material advantages that come from the code being open in the first place. This is a terrible idea.
Open source developers tend to maintain or contribute to multiple projects at the same time, and a small set of them can be monetized with this.
This allows monetizing those, and does it targeted to large companies who can easily afford it and would happily pay a few bucks to use the software (they would likely burn more money in a meeting discussing whether to adopt the said software or to switch to a free alternative) and I think it's a good trade-off if it allows indie open source developers to pay their bills.
On the long term those developers will generate much more open source output than when working as employees somewhere and creating only proprietary software all day and struggling to create open source only when they have some spare time a couple of hours a month.
In addition, all this licensezero software will be developed in the open, which brings many of the practical benefits of open source to a vast majority of the users, and the open source ecosystem will grow as a side effect that the developers will also create other software distributed under ordinary open source licenses. Even if just a fraction of their time would be spent on those other open source projects, that can make a huge difference to the ecosystem.
L0 will offer a choice of public licenses: noncommercial and very strong reciprocal/copyleft. The reciprocal license is being revised and reviewed with OSI now.
How is your new copyleft license different from the existing ones, e.g. GPL-3 or AGPL?
As someone who's been active in a Linux distributions license team I see such activity with a lot of skepticism.
There are already FOSS licenses for pretty much every wish and many of them are redundant. License proliferation causes more incompatibilities and more work for people who have to decide whether or not something is acceptable in a FOSS environment.
If people ask me what license they should choose the number one advice I give is that they should take something more or less ordinary (Apache, MIT, GPL, CC0), avoid obscure or unclear licenses and absolutely avoid writing up new licenses.
Thanks for your distro work. Skepticism is the proper reflex.
L0-R is being revised, partly as a result of the OSI license-review process. But in general, speaking as of today, it differs from existing copyleft licenses in a few significant ways:
Reciprocity requirements trigger in even more situations than under AGPL. Use with non-OSS modifications, as a component of non-OSS, or to develop non-OSS (the most controversial) falls outside L0-R's license conditions, after a grace period. This is a big extension of AGPL's leap to triggering source provision conditions on use for remote network interaction.
Redistribution, on the other hand, is still permitted with retention or reproduction of terms and notices, a la BSD. So L0-R copyleft "hooks" into aggregated or modified _use_, instead of aggregated or modified _distribution_.
Once copyleft is triggered, L0-R is both more permissive and more strict than existing OSI-approved copyleft licensing.
On the license-terms side, L0-R permits any Open Source license terms, not just the terms of its own license, for follow-on code. That should significantly reduce intractable compatibility blocks. Essentially, it's (A)GPL-3.0 section 13 for the whole OSD roster.
On the source side, L0-R is in flux in its specific language, but aims to require source availability. Originally it was phrased in terms of "publication" of source. Current drafts fall back on the Open Source Definition, which despite itself speaks to source availability, and not just license terms.
If another license is "proliferation" in and of itself, L0-R is proliferation. But I think L0-R proliferates new ideas.
I do not agree that the current OSI-approved roster covers all bases. There is a happy collective medium somewhere between everyone having an OSD-conformant license tailored to their precise needs and preferences, and restricting the community to a very limited palette of approved forms, which is easiest on the receiving end. Open data and tooling---which I've been involved in---make it easier to identify and handle license diversity, make it a software problem. Meanwhile, licenses have fallen down addressing legal, community, and community challenges. MIT, BSD, and ISC aren't good patent licenses. Apache-2.0 isn't hacker friendly, and has its own gotchas. AGPL didn't put so much as a dent in closed-source service.
> Use with non-OSS modifications, as a component of non-OSS, or to develop non-OSS (the most controversial) falls outside L0-R's license conditions, after a grace period.
I'm trying to understand your "controversial" clause. I have doubts this is compatible with any existing definition of FOSS, but maybe I'm misunderstanding.
Does that mean everything I create with a software under that license is under the same license?
To put this into a concrete example: If I have a text processor under that license - does that mean if I use it to write my emails I have to disclose my emails to anyone who is asking, because they're now under a copyleft license?
If you're correct, it's unlikely that this license would be enforceable under current copyright law. This can only work if output contains parts of the copyrighted work (see: Bison's GPL exception).
Will the reciprocal license be GPL-compatible? That's my biggest issue with licenses like these - they effectively lock out a big chunk of the FOSS ecosystem.
Thanks for doing this, Ken. I have a similar, but slightly different, motivation.
I'm working on Noctacam (http://noctacam.com), a camera app that uses computational photography algorithms to take better photos. I would like everyone to be able to reuse my work, without having to reinvent the wheel. But while paying me. Imagine if I released the source code, with a clause saying that its use requires a payment of money to me. Say $3 per user with a cap of $1M.
I don't want to distinguish between commercial and non, because most users of a camera app will be non-commercial, and in any case, I want everyone who benefits from my effort to pay me. Is it part of the plan to make L0 more flexible so that people who adopt it choose whether to make an exception for non-commercial use?
The encumbrances that this license places on the downstream modification and redistribution of code largely eliminate any of the material advantages that come from the code being open in the first place.
You should explain this. As far as I can tell from a 1st reading, so long as I'm non-commercial, I can just treat it as BSD 2 clause.
> so long as I'm non-commercial, I can just treat it as BSD 2 clause.
No, you can't, because if it was BSD 2-clause, you could relicense it rather freely. But you can't with this, because the commercial use limitation makes it incompatible with many licenses with which BSD 2-clause is compatible. (Including GPLv3)
Also, because you have to include the full license terms (including the requirement to secure a commercial license from the agent of the original licensor) with derived versions, well, if AD ever gets competition as a licensing agent (even from someone using a compatible pseudo-open license), downstream commercial users of software which has modules with different licensing agents face the prospect of having to secure multiple commercial license from different licensing agents to see the software.
For a non-commercial end user of only the “root” software, it similar to BSD 2-clause. For developers (even non-commercial), it's much more restrictive.
It also would allow for unsavory gamesmanship due to the "license available" trigger. Wait for widespread adoption, then release a commercial license. Suddenly you have a lot of scrambling to either replace the product or buy a license. Alternatively, license cost could be inflated greatly after adoption.
I just see the terms as creating too many unknowns about the future. Maybe I missed it, but do you have to constantly monitor all your dependencies for whether they may have just released a commercial license?
The effects of the license shouldn't vary depending on some outside input (the existence or not of a commercial license).
And the 90-day "trial" period seems both too long and too short at the same time. It's long enough to make tracking a little more difficult and too short to even make it into production from testing for many uses. (I assume the 90-days starts as soon as an org begins testing the product, not necessarily starting upon shipping.)
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research."
"Non-commercial" clauses by definition make something not open source.
You can't release your code in a way that it can be used as a dependency, except by requiring your downstream users to use the License Zero payment platform. That's an encumbrance.
You also can't distribute it along with GPL code, at all, whereas combining BSD and GPL code is totally fine (the result is GPL).
Qt can be used commercially under the terms of the LGPL at no cost.
When used appropriately (i.e. dynamic linking to unmodified Qt, or, offering source for a modified dynamically-linked Qt), the commercial company is not forced to open source anything.
Qt has an optional alternative license with a cost attached, that gives you (A) a support contract, and (B) additional rights (static linking without invoking GPL virality, private modifications, ...).
I find that a strange question to be honest. Plenty of FOSS is well funded. Not sure what you mean with "truly", but in my worldview code that is under a license accepted by both FSF/OSI is "truly" FOSS. A lot of people work on such code and are well payed.
I totally see the problems. But it's not that nothing is happening and no solutions exist. OpenSSL moved from "mostly one overworked guy with little funding" to "stable funding from multiple parties". It did so by convincing some major internet players that they need to increase the funding of software important for running the Internet. That is one way that can work. It's not the only one.
OpenSSL moved from "mostly one overworked guy with little funding" to "stable funding from multiple parties". It did so by convincing some major internet players that they need to increase the funding of software important for running the Internet.
How about this for a metric for whether the system is broken or not: What's a good estimate for the monetary cost of the "convincing"? Just revoking all of the keys cost millions. I wonder what the cost of the malicious activity was?
You might be interested in looking at "Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure" study from 2016 [1], which basically shows, that this is a very common misconception and not true at all (and why it's dangerous to continue assuming this way).
Yes. It's basically impossible to start with a new idea as a gifted new coder in open source and survive. I speak as somebody who's making close to $700 a month (and this is exceptionally high!) on Patreon for coding: literally the only reason I can say even that, is because I ran a small business for ten years selling closed source software directly, and establishing my reputation and skills.
So in order to not really be able to sustainably survive, took a decade of successful work in the commercial sphere. I fully intend to go open source with my life work, hardcore, but I am also fully aware that doing so rules out my own survival as an economic actor, and I'm trying to sort of develop an existence as a 'youtube/media personality' that'll support a poverty-level Patreon in a consistent way. That mechanism ought to keep me from actually starving or being homeless, but it's about 'being seen making or explaining stuff', not the code, no matter how brilliant or important the code is.
FOSS is NOT about making even the poorest living, and never will be. FOSS is about the vocabulary of thought. Broadening the vocabulary of thought is crucially important to the world, and completely orthoganal to being an economic actor. To devote yourself to it means starving or burning through your resources until you're starving, and being left with nothing.
This is important to understand, because it's solvable. If creativity and FOSS is anti-money but hugely beneficial to the world, we simply need to unlink survival from money, and conclude that whatever money represents, it's not merit.
>I find that a strange question to be honest. Plenty of FOSS is well funded.
You'd be surprised. Even extremely popular projects are severely underfunded, to the point of begging for money, while being used left and right by huge enterprises...
>I totally see the problems. But it's not that nothing is happening and no solutions exist. OpenSSL moved from "mostly one overworked guy with little funding" to "stable funding from multiple parties". It did so by convincing some major internet players that they need to increase the funding of software important for running the Internet.
If it has to come to that -- convincing Facebook, Google, IBM, whoever etc --, surely there's something problematic?
I'd say OpenSSL is an example of how FOSS funding is broken. It took several major internet-wide security issues before it was stably funded. Something so foundational to the internet should never have been so little funded to start with.
I heard Google pays its employers quite well. Plenty of FOSS is developed by Google, for example large parts of Chrome.
I think Linus Torvalds gets a reasonable salary. So do many other kernel hackers - payed by all kinds of companies.
Red Hat seems to be doing well, they have plenty of people working in all kinds of FOSS projects.
I already mentioned OpenSSL.
React is developed mostly by Facebook employers. I guess Facebook pays good salaries.
Free software is in the interest of the users - not in anyone else's interest. So, if you need software and if that software isn't your competitive edge, you have an incentive to cooperate with other users (as a developer or as a client of developers) and a free software license is a way to regulate that cooperation.
Criticizing free software licenses for not providing a business model is missing the point entirely.
One-click micropayment donations via web/OS standards and/or cryptocurrency; centralized patronage sites that allot money to OSS projects based on various metrics; different licenses for assets and code, with assets only available to licensees? Some ideas.
I suspect that the first step is for to break down the problem a bit more. Large projects need full-time developers, plus other kinds of expertise, which means organizations. For the long tail of libraries and small tools, I don't think that the problem is funding, it's team-building. If lone maintainers had better ways of recruiting extra team members to help carry the load, there would be a lot less of an issue with burn-out.
I see an effort like License Zero less as an encroachment on existing "Free and Open Source" licenses and culture, and more as an alternative to behind-closed-door development.
I want to _sustainably_ write software, not for donations but by having people who want to use it, pay for it. If I have to go closed-source to do so, then that's what I'll do. I don't have a big company behind me paying a salary.
But I would prefer to make things in the open, sharing my process; I'd like to allow students and other individuals to benefit from my work, either freely or very affordably; and I'd like to charge for-profit companies a fair price for what they receive.
The open source community tried to trademark the 'open source' label, and failed¹, precisely because it is _too descriptive_: it sounds like a generic way of describing source code that isn't private, not a specialized term with specific ethical and legal implications. But nevertheless the 'Open Source Definition' campaign has been rather effective in limiting use of the term. So I'm not even sure what to call what I want to do: maybe "open-source-ish"?
Some of my work belongs under OSI-approved licenses, but not all of it, and I appreciate that people like Kyle are working, creatively, on alternatives.
For what it's worth, L0 absolutely expects, but does not require, that source will be available, and development will continue with many of the same tools and platforms as MIT- or BSD-licensed code. It also expects _distribution_ to work much the same way. The terms for redistribution of L0 code are more or less the same as BSD.
Long story short, L0 code belongs on GitHub, and L0 packages belong on npm. It won't be hard to extend to other open languages, package systems, and platforms.
I suspect the key problem with this isn't the one most people will think of. We had a commercial JS library that we sold for 10 years and I'd estimate the % of companies that properly read the evaluation and commercial use license was under 10%.
We open sourced the product last year and found out how many silent users there were only afterwards. When I asked why they were using the software within a company long after the 3 months evaluation period had expired, the response was always "We never sold the resulting software that we built with your software".
By "commercial use" the majority of software engineers take that to mean selling. Of course, commercial use means use within a company. Some companies just hadn't got to point of starting to sell the resulting software, but others only used it internally and didn't count that as commercial use since they didn't get money for it.
Since software engineers are likely to be the only ones who see the license in a lot of cases, and the majority of software engineers I've met are not good at licensing legalese, I think this license will simply be treated as an open source license most of the time and simply not work as intended.
From experience, the problem is not than SWE don't understand the license but that they don't like to negotiate.
When seeing the license on a project they need to use, most SWE will go tell their boss "Hey we need to pay for this" and the boss will find some convoluted way to tell him "Pay? No don't wanna".
The SWE will most likely stop negotiation at that step and has two choices: Either stop using the project and find a way to do without or continue using it.
Since they actually have a enormous pill of stuff to do by yesterday and this project will save them some time they will most probably continue to use it. And tell themselves that they are personally not doing anything wrong and that's the problem of someone else at the company.
If they feel guilty enough and you are sympathetic to them, they might throw a few bucks from their own purse but I wouldn't count on it.
If they sell a product based on your project, the SWE has some leverage since someone outside the company can take a look at it, but even then that's not a guarantee.
Source: Multiple try to convince my precious boss to pay for our fucking highcharts license
L0 isn't interested in DRM, or surveillance, or any other invasive method of rooting out unlicensed users. That's an indirect way of saying that L0's approach will accept a certain amount of unlicensed use. The same way that book publishers or music distributors who offer DRM-free files accept some unlicensed use of those products.
L0 shares the approach of the more enlightened ebook and music stores: Make it as easy as possible to do the right thing.
> That's an indirect way of saying that L0's approach will accept a certain amount of unlicensed use.
Not sure it's very wise to say this on a public forum, if any L0 user decides one day to enforce L0 in court, the people infringing on the L0 license could point to this comment by the creator of L0 that L0 "will accept a certain amount of unlicensed use". I also don't see much difference between that and a donate button.
I really, really hate doing "well, actually" on people, especially when it involves legal background. I know that feels unfair.
Courts will ask what licensors meant, and perhaps what licensees should have understood, by license terms. My comment didn't go to what the L0 licenses mean---their language is in flux, in any event---but to the practical business considerations around choosing to use their approach.
BandCamp sells DRM-free music files. I'd say bands selling through them "accept a certain amount of unlicensed use", too. That's not to say they can't sue when they find someone with unlicensed copies.
> By "commercial use" the majority of software engineers take that to mean selling.
well there aren't many open source licenses that restrict commercial use. Especially since it would violate https://opensource.org/definition part 6, well basically such definitions should be taken with a grain of salt.
however even agpl3 can be used for projects where you do not need to share the code with the outside world. if you only share the code with the users using the project you are already doing everything correct. basically internal software.
This seems antithetical to the OSS movement, almost like a "Yeah, we released our code as open source, so everyone can learn, extend, and distribute. But we've changed our mind and SURPRISE - now we want a payday!" Open source only applying to other open source? C'mon - who are you, Stallman?
If companies have to pay for licenses to OSS they will simply stop using it. It makes sense to a business to benefit from the freedom of others. If devs are expecting a payday, don't release as open source. I know that sounds like I'm saying "stop being a jerk" and I am.
The idea of OSS has been the sharing of software with limited license responsibility, but adding in a specific license for commercial use thru a command-line interface is going to be too much of a nightmare to manage.
This will end up turning into another GPL border dispute (to use Heather Meeker's term). Which code is covered by the open-source part, and what's covered by commercial? Where does my software start and yours ends? I figured that if devs don't want software used by companies, they could use the CC-NC licenses.
Many companies have no problem paying reasonable fees to license software they find useful. I don't see why they should stop paying, on some kind of ethical principle, if a developer decides to publish some or all of a product's source code on GitHub with a restrictive, noncommercial-use-only license.
Why should a developer be accused of greed for publishing code openly, but with paid licenses for commercial use? How is this not better, in absolute terms, than remaining closed source?
> I figured that if devs don't want software used by companies, they could use the CC-NC licenses.
From what I can see, this is exactly what L0 provides, with the added _option_ that if a company _does_ want to use the software for commercial purposes, they can pay for a license with a credit card.
Creative Commons has spent a while trying to pin down what counts as "commercial use" for art and data, but they'll tell you flat out that code is out of scope. Ideas like "dependencies" or "linking" are not considered by CC licenses.
Furthermore, they spent maybe close to a decade wrangling with trying to better nail down NC and, as far as I can see, basically punted. Anything unambiguously NC is mostly something that you’d hopefully never see an issue around anyway, e.g. making a print of a photo for your house. Everything else, someone will argue is commercial even if it’s not an unambiguous commercial use like an ad.
That's a good point. It seems about right that license terms are all about the cases where the code is used "commercially", for some sense of "commercial". If the code is never used commercially, there's never a reason to enforce the license.
Maybe the most effective non-commercial code license is the most popular license on GitHub: the null license.
(If someone's about to reply "You can't just use code you found on GitHub without a license, you can get into all kinds of trouble that way", that's exactly my point about using code with a "non-commercial" license.)
Paying for a binary is a model that only makes sense in proprietary software, and IMO it doesn't make much sense in that model either. Supported seats is a far more usable model.
Businesses pay for LibreOffice support (like other forms of software support). Usually as part of a distribution extension (both Red Hat and SUSE have something similar on this front), but LibreOffice themselves have some support contracts as well as a certification program.
Open source means anyone can make changes and redistribute them, not just that anyone can use the software.
Let's say Bob writes a little stub of a project. It's kind of useful, and he licenses it with L0. Then someone, let's call her Jane, using the noncommercial rights listed takes her copy, adds features, fixes bugs, and speeds up the performance. Jane's contributions far outweigh the initial contributions from Bob, but she added enhancements one at a time rather than starting from scratch. Then IBM needs 30,000 seat licenses for company desktops. The money for the commercial use of Jane's contributions goes to... Bob?
That depends on what license Jane used for her contributions. A contributor license agreement (CLA) would make that a lot clearer in the case that she submitted her contributions back to the main project. If I used L0, I would definitely have a CLA.
If she forked it and maintained her fork separately, it seems simple enough how things work if she updated the license file. You'd just end up with the combination of her new license and Bob's old license. However, it is a little unclear what it means if she didn't change the license file. How can you be sure that she just hadn't yet gotten around to updating the payment information?
So, what happens if one license 0 project (A) wants to depend on another license 0 project (B)? The way I can see it, there's three possibilities:
* project A is now commercial and has to pay project B for the license
* a commercial project that wants to use project A now has to track down and pay both the owners of A and B (and any other license zero dependencies)
* a commercial project that wants to use A pays for A and B gets nothing for it because they are being used by project A (not commercial) and only incidentally by the commercial project.
> Customers who want permission for commercial or non-Open Source uses can identify, price, and buy licenses for all License Zero dependencies of their Node.js projects, in one checkout transaction, using a free command-line tool
As an aside: The fact that we're talking about buying licenses for something plus all its dependencies, recursively, in the context of node.js is hilarious to me.
Setting aside the practical detail that not everything is node.js: Nobody would want to sell commercial software under the terms of "you have to license our software A, but it won't work unless you also license software B from someone else at the same time".
There is already plenty of commercial software that depends on other commercial middleware that needs to be licensed separately. Of course licensing each and every library is typically bit different in scale, but conceptually it is pretty much the same thing.
Presumably that's where having a single place to handle payments comes in handy.
It's (hopefully?) less "well, you have to go to this other person and license their software too" as much as "here's the total cost for a license (which happens to include both A and B)"
Huh, fascinating. Licensing software by typing in a CC# via a CLI feels like a really foreign way to pay for something. I'm curious to see if that's behavior people take to easily.
I'd like to ask Ken Mitchell if there were concrete examples that motivated this. Such as...
- Were there specific open source projects where you thought the creators got screwed out of money and therefore this license would have helped them?
- As a thought experiment in the vein of game theory, would projects with heavy commercial usage like Linux, ffmpeg, openssl, etc be in a better situation today if they only had a 90-day window for free use? (Speculate and replay history with L0 license.) My intuition is that the 90-day restriction is enough of a turn off that we wouldn't have the situation today of IBM + Google + Redhat + etc adopting Linux and contributing code back to it.
There have been many examples. Some involving people very close to me. Some involving clients, who I can't talk about.
I'd encourage you to ask maintainers themselves. They aren't hard to find online. They're often happy to tell stories, the first time and the hundredth time.
>There have been many examples. [...] I'd encourage you to ask maintainers themselves. They aren't hard to find online.
How would I know which maintainers to ask if you don't provide any examples of open source projects that would have gotten equivalent adoption by commercial entities with the L0 license? The 90-day restriction creates disincentives for use so that game theory has to be taken into account.
I mean, we can daily see how much effort is wasted on projects beholden to stockholders and business interests. In my experience, open source software is the only software that can stand the test of time; everything else will be pivoted, sunset, or bought out eventually. The problem is that it's so hard to make money doing it.
(Not that this is necessarily a good solution, mind you.)
I think it's come from the typical pattern of maintainer burnout and project abandonment after a few years, since a successful open source project typically turns into an unpaid second job.
>typical pattern of maintainer burnout [...] , since a successful open source project
Right, but that's what my "game theory thought experiment" was trying to dissect: the 90-day restriction can dissuade commercial entities from embracing that software so therefore, it's not "successful". As a result, there is no work overload and no burnout.
Which past open-source project can we confidently replay history with the L0 license and say it would have roughly the same commercial adoption and the maintainers got paid more money?
> a successful open source project typically turns into an unpaid second job.
which the maintainer voluntarily performs. If it's a burden, stop! If users of said software are asking for features/bug-fixes, and you as a maintainer can't be bothered, then ask them to pay for said fixes (either via a common-pot method like patreon, or a one time fee, or some other method). If those people asking for fixes aren't willing to pay, then they clearly don't really need those fixes.
The reality is open source developers tend to maintain multiple projects at the same time, and a small set of them can be monetized with this.
I think monetizing those, targeted to large companies who can easily afford it and would happily pay a few bucks to use the software (they would likely burn more money in a meeting discussing whether to adopt the said software or to switch to a free alternative) is a good trade-off if it allows indie open source developers to pay their bills.
On the long term those developers will generate much more open source output than when working as employees somewhere and creating only proprietary software all day and struggling to create open source only when they have some spare time a couple of hours a month.
In addition, all this licensezero software will be developed in the open, which brings many of the practical benefits of open source to a vast majority of the users, and the open source ecosystem will grow as a side effect that the developers will also create other software distributed under ordinary open source licenses.
first off, linux is free software (a subset of open source) despite being considered "toxic" GPL is actually favors the creator quite a lot. (it is my suspicion that this fact is why it is labeled as toxic in the first place, but i digress) the copyleft aspect contractually obligates you to contribute back to the original project. this means that any company that uses your tech is effectively paying their staff to contribute to your project. this is a good thing as it prevents them from extracting value from the project.
linux is a great example of how a free software project can utilize corporate support to further its goals without becoming a victim of exploitation (unlike openssl, gnupg, &c.)
Open Source to me is e.g. the ability of a farmer to hack on his modern combine. And I would think it perfectly fine if the manufacturer voids the warranty in such a case. Note that the hypothetical farmer paid for the combine.
This suggestion is missing the incentives present for software writers. Open source drives adoption and the network effects of Google-ability and stack overflow Q&A, along with prestige for the creators. Straight up removing free commercial use does some real damage to the network building - your license prevents it from getting used for many projects.
What you want is a license that allows use in "cheap" situations without giving away your right to price-discriminate against companies that have large checkbooks. So, some sort of simple price discrimination screen built into the license. Something like "Does your company have 1000 or more employees? If so, pay us. If not, you've got a free license and 90 days to get into compliance if you change categories".
The L0 public licenses come with grace periods, essentially free trials. Right now they're at 90 days, but will almost certainly shorten, perhaps to 30 days or less.
The utility of L0 is to make it possible to offer one set of public tools with, say, a noncommercial use limitation, but offer those who need to use commercially an easy way to buy the right to do that. "License Zero", as in near-zero friction.
Zero is impossible of course, because there will always be some friction in the additional step of getting a different license, versus not needing a separately license at all. But it's up to developers to decide what's best, in terms of optimizing leverage to command support, on the hand, and minimizing friction that puts a brake on adoption, on the other. Purely proprietary software with closed source is at one extreme. Hyper permissive licenses like 0BSD are on the other.
My point is that "commercial" versus "noncommercial" isn't the same distinction you want to use for "pay us" versus "don't pay us". The proper price point for many commercial uses of software products is still zero.
Agreed. Some may opt for the reciprocal public license for that reason, since it allows unmodified use for commercial purposes.
Leaving the terms behind for a moment, to focus on context: Many users, both individual and business, don't have any money to sue for. They're judgment proof. But if they make it to cash flow, they should pay. They'll almost certainly have paid for other goods and services, like AWS or SaaS, before then.
I agree that price discrimination can be a useful thing, but question the idea that only very large or wealthy companies should pay anything at all. What if licenses are low friction and affordable?
If we had a nice repertoire of flexible licenses available to play with, developers could experiment and try all sorts of ideas, including what you describe.
Non-FOSS-licensed software isn't going to play the same role in the ecosystem as FOSS software, but it doesn't have to. Plenty of room for different kinds of people/companies/software to co-exist.
>I agree that price discrimination can be a useful thing, but question the idea that only very large or wealthy companies should pay anything at all.
Because the more developers use a piece of software, the more valuable being able to use the software is. It's a classic network effect. Being able to write your commercial web app in Ruby on Rails is more valuable than being able to write it in a functionally equivalent framework with much fewer users of the software. This is straight from being able to hire developers familiar with RoR, access Q&A discussions, use third-party RoR tooling, etc.
Large companies tend to not be early adopters anyways, and they have the fattest checkbooks to raid for the value you're supplying, so it gets the most financial gain for the adoption loss you're causing.
I can see how that is true for some kinds of software. For many examples, network effects don't matter.
The first license I can remember paying for was Metafizzy's 'Isotope', a jQuery layout plugin. Great documentation and performance. I can't remember the price at the time, maybe $40 (now it ranges from $25 - $320). It was totally worth it, I was making money and clients were happy.
Kudos for giving the gist of the idea in a piece of code:
def public_license (paid_available, commercial, contributing):
if paid_available:
if commercial:
if contributing:
return 'contribution-enabling, BSD-like license'
else:
return '90-day free trial, then you have to buy a license'
else:
return 'noncommercial, BSD-like license'
else
return 'standard, Open Source, two-clause BSD'
The trouble with these code snippets is that they condense very complex and squishy social structures into what incorrectly appears to be simple binary decisions. Creative Commons spent years defining what "commercial" means.
It's obviously a commercial use if I'm using your items to make money... But, what if I'm a charity? What if it's hosted on a website that runs banner ads? What if I don't turn a profit? This was a years-long discussion that you can review https://wiki.creativecommons.org/wiki/NonCommercial
Code emphasizes what consensus we need to come to, the consensus that those complex legal documents define. For example, that's part of why the GPL is so long, it's specific.
Also, how do you define "contributing"? Is one commit enough to get perpetual use? Do I need one commit a year/month? I can't think of a single definition that wouldn't either allow users who aren't making a significant contribution to cheat or screw over some legitimate contributors.
Agreed; that was helpful in understanding how it works. However the large imbricated `if`s make it harder to understand than a refactored version with early return's:
def public_license (paid_available, commercial, contributing):
if not paid_available:
return 'standard, Open Source, two-clause BSD'
if not commercial:
return 'noncommercial, BSD-like license'
if contributing:
return 'contribution-enabling, BSD-like license'
return '90-day free trial, then you have to buy a license'
Unfortunately "contribution" is quite hard to formalize.
As they say in Russian "три яблока это куча или нет?".
(Loose translation: is three apples a lot of apples?)
It depends...
I've ended up doing the same for the other L0 public licensing option, L0-R, a stronger-than-strong copyleft license, in the Open Source Initiative license review thread. That license is still being revised, so I won't dump the pseudocode here. But pseudocode's been very useful in that discussion, too.
All the same, I don't quite feel like kudos are appropriate. I'd like to think I'm capable of writing the license terms plainly enough that regular old English speakers can understand them. But experience has taught me that I should translate to code, especially when I'm patching an existing license, rather than writing from scratch, as with https://github.com/berneout/berneout-license-kit (_very experimental_)
FWIW, I often start drafting legal code based on more structured pseudocode. Most lawyers I know who do a lot of drafting have some kind of personal boolean logic shorthand.
The pseudo code expresses the gist very succinctly, hence kudos. It's like an abstract of a scientific article. Not all important details, but the few key things.
What if "paid_available == False" the first time, but later, "paid_available == True"? Is the "standard, Open Source, two-clause BSD" license that applies at first invalidated?
This seems well intentioned but poorly thought out. Also, software distributed under this license does not qualify as free software under the GNU _or_ OSI models.
There are issues with this, but on the latter point: why are the GNU and OSI models an unquestionable religion? Do they work? Are they achieving their stated objectives? Why can't we question them?
> There are issues with this, but on the latter point: why are the GNU and OSI models an unquestionable religion?
The FSF Free Software and OSI Open Source definitions are the products of significant consideration of the logical impacts and experience of the practical impacts of software licensing (the former more heavily on the abstract, the latter on he practical, but interestingly they end up essentially identical.)
As such, deviations from those models that assert that they are both retaining the benefits and curing problems inherent to the models, while certainly not implausible, do call for careful examination.
The "Departure" section of the manifesto addresses very directly that the patch to BSD-2-Clause takes it out of the Open Source Definition:
> According to The Open Source Definition, discriminating against commerce and non-contributors is not “Open Source”. The Definition also prohibits discrimination against “fields of endeavor”, like commerce, and persons and groups, like non-contributors. That means License Zero is no longer an Open Source license, even if it remains remarkably generous, a public gift to charitable organizations, students, teachers, academics, and hobbyists everywhere.
L0-NC derives from BSD-2-Clause to make transition back to OSD-conformant terms very clear.
You're making it seem like it's just a technicality over definitions when it really is a fundamental difference. It explicitly rejects the "freedom zero" of open source, the freedom to actually run the software. It means that if I inadvertently download L0 software from npm at work, 91 days later my company is in violation of criminal copyright law. No open source license does that, not even AGPL. ("But you'd also be in violation if it were regular commercial software!" True, but in that case it wouldn't be on npm and I wouldn't have made that mistake).
If you want to position L0 as a way for commercial software vendors to distribute source, that's fine. But I strongly object to the implication that it's just a "patch" on top of existing open source licenses.
It is a patch on top of an open source license, BSD-2-Clause.
Legal terms aren't exactly like computer code, but the analogy works here. Unmodified BSD-2-Clause meets OSI's "test suite", the Open Source Definition, and FSF's test suite, "What is free software?". Patched, L0-NC fails both test suites. Passing isn't about provenance of the "raw material". It's about what the terms do.
The reason I did that, even though I could easily write a more modern and approachable permissive license than BSD-2-Clause, which is almost as old as I am, was to make automatic reversion back to open source terms very clear. The "patch" touches the header notice, and adds a third condition. The automatic waiver removes the new, third condition. That means BSD-2-Clause and some extra stuff in notice are left.
Really, what's with experienced HN users jumping to conclusions and writing comments without reading the entire post? The exact concern you raise in your comment is addressed at the bottom of the post!
There is another definition: what developers mean and understand when they say and hear "open source". It isn't hard to find OSS developers who've never heard of OSD, or DFSG, or _What is free software?_, or once they have, care much about them. "Open Source" is part of their identity. As far as they're concerned, it belongs to them.
There is also a difference between OSD conformance and OSI approval. That's been made very clear in the license-review thread for the License Zero Reciprocal Public License of late, and in many private conversations besides.
The License Zero Noncommercial Public License was never meant to be "Open Source" as defined by OSI. It may be "open source" as developers use that term today. If the latter, I'm not sure _I'm_ happy about that.
The reciprocal public license will be OSD-conformant. OSI may or may not approve it, on policy grounds. FSF may or may not opine that it's a Free Software license, or an ethical license. It may or may not be "open source" as developers use and understand that term today, or tomorrow.
All of these brands, labels, categories, and border disputes matter so, so much less than the real, underlying problems in lining up support and compensation with contribution in software. If by breaking or smudging these categories, L0 creates a clearer line of sight through to those problems, I think that's great!
> There is another definition: what developers mean and understand when they say and hear "open source".
Sure, but those devs know that 'MIT' and 'GPL' and 'BSD' are Open Source, and that being able to license the source code for eg, Windows, doesn't make Windows Open Source.
The FSF and OSI models are meant to cover the same class of software (for example, both explicitly accept both copyleft and permissively-licensed software). So far I believe they've disagreed about the status of a total of two licenses, which are rarely used.
This name is really confusing. If they called it "Shareware 90 plus other restrictions" it would at least convey a bit about what the idea of the license is trying to do.
Using "License Zero" is a really marketing oriented approach.
"License Zero" because it aims for zero marginal friction over use of permissive open source software. That's entirely attainable with good metadata, a good CLI, and a speed checkout process.
Has anyone tried simply creating a business that negotiates with companies to fund open source developers and takes a small cut? It seems like a simple proposition. The company identifies an open source project that needs help, identifies clients that depend on it, approaches those clients and the developers, and sets up a deal between them for ongoing maintenance.
It wouldn't fit every project, every client, or every developer, but when it does fit, it could be a great deal for the developer and for the client.
It would let you sign contracts that look like the sort of contracts that big companies are willing to pay 5+-figure amounts for.
I don't even know how I would get my employer (either my current one or any past one) to sign up for a Patreon. Do I ... use someone's corporate credit card? How does that even get audited? I can totally tell procurement to sign a contract with someone, though.
(I'm imagining that the amount of money needed to make a self-funded OSS developer viable is on the large side, and that a lot of companies contributing a relatively small amount to each Patreon isn't reliable enough for the developer to count on. But maybe it is, in which case maybe the corporate-credit-card approach would work.)
Exactly. As your link says, "anyone can do enterprise sales", but it surely takes time away from development. Someone stepping in and doing the enterprise sales for open source developers could fill a lot of gaps.
Part of what L0 does is offer a single set of terms for paid licenses, published online, based on Apache-2.0, the enterprise-iest permissive license. The diffs (lawyerspeak: "redlines") are right on the site: https://licensezero.com/licenses/private/diff
Patreon expects creators to advertise. The idea I had is that this business would actively seek both clients (who don't know they should be paying developers) and developers (who don't know how to get paid for their open source work).
On a purely practical point: ell zero. Probably the two worst characters to combine in this way, because in various contexts and fonts it’ll look like the wrong thing and thus be confusing to users. In uppercase, the zero looks like a capital o (L0 looks like LO), and in lowercase the ell looks like a one (l0 looks like 10).
This is an interesting idea. I'm curious how the author imagines licensing working, practically: am I paying once for a specific version/build of a library, am I paying a recurring subscription fee for regular updates/bugfixes, or am I paying once and expecting free updates?
If I'm interpreting these correctly, you pay once for a license, and get access to all future versions of the library?
Most models for building companies on OSS tend to rely at least somewhat on a service model, rather than selling a piece of software once as a product and then continuing to maintain it for free (relying, then, on continuing to sell new licenses of the same software in order to keep money coming in).
In this case in particular, I feel like this creates misaligned incentives: after someone has already paid me for a license, if they have feature requests or bug reports for me, it's actively against my financial interests to spend time addressing those rather than working on things that will help bring in new paying customers (of course, these two things will sometimes align, but not necessarily). That's presumably most easily fixed by that customer contracting me to make those changes, but at that point I've now got a revenue stream and business model that feels a bit orthogonal to the licensing idea (and would lose all the benefits of e.g. your nice integrated payment system).
Curious if you have suggestions or thoughts about bridging that gap!
Yes. There is some revision going on in the definition of "Work" under the private licensees, but the idea is that if a developer published 1.0.0 to repository A, you bought a private license, and developer published 2.0.0 there later, your private license covers both 1.0.0 and 2.0.0. If they rewrite and push to C, however, that's a new ballgame.
There's no obligation under any L0 form (or any OSS license I'm aware of) to provide any ongoing service. A developer could still offer services---training, support, maintenance, feature adds, etc.---around L0 code.
Speaking of perverse incentives, we see exactly that with pure service-based business models. Why write good doc if you're selling training? Why make it easy to deploy if you're selling installation or hosting? And so on. That _is not_ to say those models can't be done well.
In other words: how to 1) motivate the author to publish project as L0 and 2) motivate the author to keep working on it. Am I right in my understanding of what you are saying?
If "yes" then it is a reasonable question. Some complex projects have quite narrow potential audience to get sustainable cache flow (from new license buyers). But are valuable for those few who already paid.
I run an open core software company. Incentives depends on the complexity of what the software does.
In the "distro" oss companies like cloudera, red hat, us,..
there is usually a lock in component somewhere (usually in the difficulty) but sometimes in a closed source component.
We've had difficulty with "paid extensions" in real practice. The only thing that tends to work is "as a service" or "buy the proprietary part".
I won't comment on the individual developer attempting to sell a JS library. I just want to note how hard it can be for customers to even be convinced of this in the first place. The likelihood of this being a real "revenue stream" for your typical freelance OSS developer building a node library is a stretch at best.
There is still quite some amount of hubris in this.
If A writes software under L0 and gives it to B and is “nice enough” to allow B to use it privately for free, there’s some entitlement to the software.,
You’re overlooking that, in a contemporary environment, you’re standing on the shoulders of the giants (and all the small ones) who came before you. It’s absolutely presumptuous to write code in our time and not publish it under an OSS licence.
Yeah, it seems like this is better understood as "Here is an option for proprietary software that fails open" instead of "Here is an option for free software that provides revenue for the authors."
If I'm understanding this right, the agent seems to be the License Zero entity (Artless Devices), not the software author, meaning that even if the software author disappears off the face of the earth, you still have to buy a commercial license from Artless Devices. It only triggers if Artless Devices themselves disappear off the face of the earth, or voluntarily stop selling licenses, which seems like a weird thing to trust them to do.
The terms "open", "proprietary", and "free" don't have consistent meaning across our communities. It's a well ingrained instinct at this point to tease what people mean by those terms apart. If nothing else, L0 has rhetorical value in bringing those issues to the fore.
Relationships between devs and Artless Devices are all under the agency terms found here:
* "Agent" is used in its legal sense, to mean someone appointed to act on another's behalf. With licensezero.com, it's appointing AD as your agent to essentially run the back office of a dual licensing play on your behalf.
* The agency relationship isn't exclusive. Devs can sell licenses on their own, or use other agents. They could even use L0's forms to do their own deals. For large enough price tags, that makes sense, to bypass Stripe fees and L0 commission. But there are big advantages to automation and the L0 network, especially for relatively low-dollar, high-volume plays.
* It's perfectly possible to dual-license on L0 or other terms without AD/L0.
* If L0 falls off the face of the earth, devs can step in to sell licenses themselves to avoid automatic waiver back onto permissive terms. They can go to another agent, or set up their own automation.
My concern is that if the actual developers fall off the face of the earth, and AD doesn't, I'm still obligated to buy proprietary licenses from AD until such a point as you decide to stop selling them. I'm not getting any advantage from financially supporting the authors any more, but I'm still required to do that.
Now, there might be good reasons for that - for instance, I might have children I want to provide for after death, and request that AD continue to sell licenses and provide the revenue to my children, even though my children are unlikely to provide any development or support for the software. In our society, letting your heirs inherit your commercial IP rights after death seems to be as well-accepted as letting your heirs inherit just about anything else.
But in terms of mental model, that is much much closer to what currently goes by the name of "proprietary" than what currently goes by the name of "open"/"free". And because there are good reasons for AD to continue selling licenses if the dev disappears, I can't count on the fact that if the dev becomes unavailable to actually respond with technical support, you'll stop selling licenses and allow me to just fork the code and try to build a community myself.
> The terms "open", "proprietary", and "free" don't have consistent meaning across our communities.
While any community sufficiently large has some members using terms in unusual ways, Open Source and Free Software now have very clear generally accepted definitions, and “proprietary”, in the licensing context, as well (as “neither Open nor Free”.)
The weird part is that "Open Source" is well-acknowledged to mean the Open Source Definition, "Free Software" is well-acknowledged to mean the Debian Free Software Guidelines, and "Open Source" is well-acknowledged to mean something different and broader than "Free Software" - even though the DFSG and the OSD are fundamentally the same document!
(Well, I guess "Free Software" also has the FSF's Free Software Definition, but in practice that has very few differences on paper with the DFSG. There are differences in interpretation over things like firmware and invariant sections.)
My experience points to strong established connotations for "open", "free", and "proprietary", but few if any concrete denotations, across the broad swathe of developers.
Good point. If you can escape from the license by forking from it then it's worthless. Since that's obviously not the intent, then presumably a fork would still require licensing from the original source. Would it require licensing from the new source as well? If so, then forks are still theoretically possible, but the next question that raises is, are licenses compulsory? If not the original license holder still ends up with a veto over commercial use of the fork, simply by failing to give the license to anyone using the fork. Forks could conceivably carry on with purely-non-commercial licensing, but that's not a true fork.
Should the community get through this, then License 0 is going to get awfully complicated the day you decide to download the fork of the hottest new web framework that itself uses several dozen License 0 components, with arbitrary numbers of forks in them.
If licenses aren't compulsory then such a framework has the problem that suddenly there are dozens or hundreds of individuals that may decide for their own individual reasons to decline a license to someone that they may simply not like. (There is, in some sense, something to be said for greedy companies that just want your money and care nothing about you; at least they don't deny you licenses because you once gave their friend a bad interview experience, or violated some personal pet political stance.)
An option would be to just say "Yeah, these projects can't be forked." Which is a solution of sorts, but definitely one that is losing something very valuable from open source. The fact that such a license would be classified as "not open source" probably means something real, not merely that the definition is outdated.
There's an interesting idea here, but I think it's still the seed, not the fully-grown oak. But, again, let me end this with encouragement that the idea is being kicked around, and I'd like this to be seen as criticism in the spirit of refining and improving the idea, not merely being critical for the sake of being critical. There's some interesting ideas here in the service of a real need.
I have two lines of active thought around this for L0.
One is sponsored relicensing. It's possible today to set a price at which you'll relicense an L0 project onto vanilla BSD-2-Clause terms. In essence, you can put an estimate on future dual licensing revenue, discount it to present day, subtract any discount you'd apply for personal gratification in making it maximally available, and make a standing buyout offer at that price.
The other is an alternative public license for L0 projects, a very, very strong copyleft (reciprocal) license. That license should conform to the Open Source Definition. It's in review and revision with OSI now.
The reciprocal license would allow forks that meets its conditions, namely that the fork and other software that incorporates or uses it in development must be Open Source.
Dual licensing is fundamentally a privilege of initial copyright holders. When you fork, you almost always do so on the basis of your rights under the public license. If you fork under the noncommercial public license, you and users of your fork have to stick to noncommercial use, or pay for other terms on the original code.
Oooooh. I really like the idea of dual AGPLv3/commercial-if-entity-exists-else-2BSD, because that means it is free software no matter what. It's just the sort of free software that big companies will pay money to avoid, which is what you want. :-)
I originally set out to do L0 with a noncommercial license only. Then I had half a dozen good conversations with copyleft friends, who pointed out that (1) they really liked what I was doing, (2) they'd never use anything but a copyleft license, (3) even the (A)GPLs were compromise implementations of the values they really hold dear.
Open Source licenses can't discriminate against groups or fields of endeavor. But groups discriminate against Open Source all the time. A strong copyleft license could be both Open Source and nearly as effective as a noncommercial license in driving financial support to OSS maintainers. Under L0-R, companies can choose: Either they make their work available as Open Source, or they support others who do.
I like the direction where this is going. Giving adopters the option to choose between strong copyleft (e.g. AGPL) or paying. Everybody wins, except freeloaders.
What license would you provide the paid copy with? It should allow modification, linking, redistribution but only for the paying customer.
It's a Mustache templating error, fixed on master in the submodule, but apparently not in the current deploy. I moved from {{template vars with HTML escaping}} to {{{raw template vars}}} sometime back. Bad merge, perhaps. There have been quite a few changes, in response to feedback!
I wonder if the real end of open source is energy research. To be able to create without worrying too much you need physical security. Food, heat, water. Which is indirect result of energy access.
Bucky Fuller calculated that we would have the technology to provide a decent standard of living for everyone on Earth by sometime in the 1970's. We just have to deploy it efficiently. And there's the rub.
Put another way, all our problems now are psychological.
That's also part of my understanding. We live in a bubble that makes most of us think we have to do some things and do them in "that" way. Think food or transportation. For 20 years people busted me to have a driving licence. Western cities were so much about having a car .. it became an absolute.
In a way the first factor going against Fuller is consumerist capitalism. Markets aren't made for people to have enough but for companies to survive and get fat.
You probably know this, one of his books is titled "Grunch of Giants: Gross Universe Cash Heist".
He had a plan, "Design science revolution", to produce artifacts for consumers that embodied the changes needed.
The concept of the "trimtab" informed his methods.
> Trim tabs are small surfaces connected to the trailing edge of a larger control surface on a boat or aircraft, used to control the trim of the controls, i.e. to counteract hydro- or aerodynamic forces and stabilize the boat or aircraft in a particular desired attitude without the need for the operator to constantly apply a control force. This is done by adjusting the angle of the tab relative to the larger surface.
Good question. The answer: exactly as in Creative Commons' noncommercial licenses, but without the filesharing clarification, since the noncommercial condition applies only to use, and not to redistribution.
If you use this software in your company and your company makes more than $100 million per year, they should give $10.000 per year or per release to the community/person who wrote it -- otherwise do anything you want with it, view the code, edit it, ship it, etc.
Straightforward, capped (so they don't worry about you jacking up the fee), a drop in the bucket for large companies, and would allow projects to actually hire people.
As someone who works at a large company, $10k is in no way "a drop in the bucket". Sales teams might have a budget to wine-and-dine clients, but as a developer I have pretty much zero budget and every expense has to be justified.
This is probably true of any publicly traded company (as mine is) which has a legal obligation to shareholders to be careful that all expenses are worth it.
My understanding is that licensezero is essentially doing what you propose, but also addresses practicalities such as how/where to send payments, tools (for licensees) to aid auditing, flexibility in pricing (and changing the pricing as time goes by).
>As someone who works at a large company, $10k is in no way "a drop in the bucket". Sales teams might have a budget to wine-and-dine clients, but as a developer I have pretty much zero budget and every expense has to be justified.
My idea was mostly meant for stuff in the category of Nginx, OpenLDAP, Postgres, Mongo, Elm, and co -- stuff that's used as the backbone of projects or services.
So, not just what some random developer in a big company might ask for their personal use. So, not something that some developer would need to justify for their use, but something that has to be accounted for when planning for a new project ("We'll make it in the Foo framework, which costs $10K/year for a company of our size").
If that was adopted, in the end, it would be a budget item like anything else. If they can pay $$$ to IBM and Oracle, not to mention the untold millions made by widget makers, chart libs, and the like, then they can pay a measly 10K to a project they rely on.
While the principles and benefits of open source have been well established the funding has been left vague perhaps because a lot of early open source was developed by academics driven by ideology with little concern about funding.
This funding lacuna leaves open source completely open to corporate capture. Entrenched interests are adept at controlling outcomes by controlling the money.
What is missing is user organization, systems and a culture of individuals supporting open source as a matter of course which should have been thought of and built early. Without this financial support it will become corporate controlled.
There must be more transparency and social pressure on successful companies using open source and simply forgetting about it.
one of the key advantages of FOSS licenses is that we immediately know long term what the trade-offs are (except maybe the AGPL). and this means we can invest in learning to use, improve and integrate the software without a lot of negotiating with the author. without the risk of the rug being pulled out from under us
in spite of the misleading name and the allusions to open source, this license scheme fails to capture that predictability
I want to applaud the author for taking such a bold step, but I would like to disagree with the assertion in the manifesto that all forms of open source software are failing business models. I would like to encourage the author to dive deeper into the various ways that commercial companies that promote open source are finding ways to make it commercially viable.
By experience, I was founder and CEO of Codenvy, which ultimately made Eclipse Che open source workspace server. We created that with an EPL by taking the large majority of our intellectual property and open sourcing it. While Codenvy's IP was closed and commercially for sale, there were significant feature differences between Che (for workgroups) and Codenvy (for enterprises). We steered the entirety of our company's go-to-market to be Eclipse Che-first promotion, and as Che grew to 50,000 usage hours / day and 10s of 1000s of downloads, the cross-over to Codenvy was significant enough where we were able to build a nice business. It was a business that let us put more than 60% of our engineering resources into Che and we had 40 engineers. Codenvy was later acquired by Red Hat earlier this year.
I am CEO of WSO2, whose product line is entirely (well, almost) Apache licensed open source. WSO2 competes with large proprietary platform vendors like Oracle, IBM, Tibco, Software AG, and Mule Soft. Mule has an open core, but largely is still a proprietary vendor. We have 400 enterprise customers and - from what we can tell - probably another couple thousand installs of our various open source servers for identity, streaming SQL, integration, or API management. We estimate about 5 trillion transactions run through our software each year and our customers are some incredible high quality brands.
The company is 12 years old and has stayed committed to open source in this way. But we are commercially viable. We have 492 employees worldwide, offices in 5 countries, and a rich set of long-lived subscribing partners. This allows 100% (caveat below) of our engineers to work on pure open source development. Of our 492 employees, roughly 400 are technical. All of our technical people work in engineering, and then do rotations into support, consulting, training, or solution architecture / sales / marketing so that everything that we do related to our technology is witnessed by a full fledged engineer that can bring the advancements back into the product itself. And this also has an affect of building a strong ecosystem, where we have roughly 1000 other people who are certified and / or committers to our various open source initiatives. So I look at us as a healthy business, commercially viable, and found a way to make pure open source work.
The caveat - the way that we have been able to balance the trade off between a pure Apache license and the commercial viability is around subscriptions. Subscriptions offer customers specialized value for their implementation: support, indemnities, warranties, security scanning, incremental builds, and certified builds. To help us commercially, we only distribute patches, updates, and security addendums as binaries that are closed source. Customers who have a subscription get a perpetual license to the patch. Otherwise, the patch is also made into our project's code base, and at any time you can compile the code from the Apache base. Every 6 months or so, we update our open source binaries with the cumulative updates and patches. It's this sort of balance that allows us to create value for enterprises and gives them an incentive to get onto a subscription with us. And it's through those subscriptions that we have become a commercially viable company.
There are other models as well - with open core, and what I call open fringe, which are open source platforms that have closed-source "management" around it. These are all flavors of permissiveness that each company must find for itself to find an equilibrium between commercial interests and contributing to open source.
Again, I am very positive on the author's initiatives and do not want to provide a critique. But really do encourage a deeper exploration of the commercial ways many companies make OSS viable.
I welcome critique! And greatly appreciate the time you've put into this comment. I've bookmarked it to read again, in case I've missed something the first time around.
I'd also be interested in following up, publicly or privately, in a more direct way. I support what you're doing, and it sounds like you support at least the spirit of what I'm doing. We should talk.
One point I'd like to go ahead and bring up:
A common thread through the examples of success you've given is size. There are some examples of single-person, profitable operations, like Sidekiq, but they're very, very rare. Many successes boil down to economies of scale on services, information, relationships, corporate process compatibility and so on.
L0 aims to make one business model that currently involves a lot of structure---dual licensing---available to very small, independent players. As an indie developer today, sure, you can set up an LLC and start e-mailing forms off the Internet to procurement departments. But doing all that will swallow you, as well as the time you already don't have to spend developing software.
Part of making that play available to indies is automation. Part of it is standardization: one form for buyers to review. Part of it is network effects: one place for customers to get all the licenses they need, in one transaction. Part of it is recognizing a play that can, forgive me, "scale".
Dual licensing is the most direct of the well known options, in that sense. The software is valuable. Pay for the software. Where does the pay go? Into the one who'll make more and better software.
Yes, of course - happy to discourse further. tyler at wso2 dot com.
In seeing your response, it does occur to me that you may be tackling an alternative form of monetization that is suitable for micro-payments, or for open source project leaders that do not desire to oversee the more traditional commercial business aspects that you must under take to monetize a project. These are things such as support, consulting, and training. There is an investment (sweat, not monetary) that goes into thinking about how to deliver such services, meeting an SLA, and whether there are associated assets that must be created to support such a delivery. This is a lot of effort and maybe not commensurate with the time or objectives of the OSS developer. There is also the challenge of commercially transacting on such alternative forms of monetization (or value added software that is proprietary). So while these are profitable endeavors, there are any number of reasons that it may not be interesting to pursue them. It may not have to do with size of the project, but of the cost to pursue the alternative monetization strategy.
So in that case, it may be interesting for a project to have different forms of licensing at different phases of development that are more conducive to either micro-monetization or classic-monetization, for which WSO2 falls into.
And so perhaps it benefits us all to think of licensing for monetization as a spectrum to be applied given the objectives of the project leaders.
I will follow up by e-mail shortly, but can't help adding a couple things to two lines of thought in your response:
Here's an open form agreement that I wrote from scratch for contractors that allows switching from terms for "open" and more traditionally "closed" projects: https://github.com/kemitchell/switchmode Terms for either "mode" are compatible with use of OSS and collaboration with OSS communities.
I represent both open-style devs doing paid work and companies who hire them. I tried to strike a balance, in much more approachable language, with Switchmode.
L0 currently supports one kind of very dramatic licensing transition: developers can offer to relicense their projects BSD-2-Clause for a stated amount. Sponsor pays the price, developer automatically grants a BSD-2-Clause license, and takes obligations to update notices and push commits accordingly.
I like seeing things like this. There are two practical problems that come to mind (not fundamental problems):
1. Many traditional distros - Debian (and by extension Ubuntu), Fedora (and by extension RHEL), etc. - won't carry your software if it breaks the Open Source Definition in this way. If you're targeting npm modules, this isn't a problem at all, given how much technical work needs to be done to get the average npm module in one of these distros. :-) But there are lots of sizable use cases where this is a problem, and the Open Source Definition has become something of a Schelling point.
One solution in the Debian/Ubuntu case (I'm less familiar with the Fedora/RHEL side of this) is to package your software for Debian "non-free" and Ubuntu "multiverse", which are for software that can be freely redistributed but is not Free Software and therefore not officially part of the distro / officially supported to the same extent. This isn't an extremely popular choice right now, but I think that could change.
2. Sort of expanded from there, really the value of an open-source project is far more in its community, that is, in the trust that it will continue to do the thing you want it to do as your requirements and the world around it change, not in the code as it is. I don't think that the most valuable thing you have to offer is your software, and I do think that compared to ongoing support and maintenance and interaction with users, the value of the software itself is probably approximately $0, yes. As a perhaps-controversial example, consider systemd: there are plenty of other service managers with similar approaches to process supervision, and plenty of other inits, but systemd has the property that everyone expects Red Hat to continue funding full-time development on it for many years, there's a lot of people on StackOverflow who have answered questions about it, etc. That's not particularly a function of the code itself; that's a function of an entity like Red Hat standing behind it and basically every distro having adopted it.
Speaking for myself, at least, I'm unlikely to try to convince an employer that we should use some piece of software that's sorta-open-source when actually-open-source options exist, unless the support around it is so good that we might as well treat it as a normal proprietary competitor that happens to make source available to customers if they want. Mostly I'm hesitant because I don't expect other companies to do the same thing, and I therefore don't expect the ecosystem to grow.
If you can cause people to believe that License Zero software is as viable as open-source software with a similar level of functionality, that ecosystems will grow around it as well as with open-source software, etc., it definitely sounds like this model is better for long-term sustainability of the project.
Thanks for your time on these comments. I may have to eat some words about the general quality of HN discussion ;-P
Your point on OSD-gated repositories is dead on. As a practical matter, I think many of s run non-free software on Linux. I'm typing this into Chrome on Debian, and I'm sure I've enabled some non-free APT repos.
It's also interesting to see how many of the "current generation" hosts and repositories made the jump from OSD-only to "anything you're willing to have us distribute". GitHub's in that box, with npm.
There is definitely a potential holdout problem on adoption. But if there's any big, general, meta conclusion to take from Open Source in recent years past, it's that little players make independent decisions that add up to a compelling proposition, and enterprise follows the value. Niggling structural or terms objections fall away.
> I don't think that the most valuable thing you have to offer is your software
What about the OP's point that typical OSS business models don't provide an incentive to write great software, but may in fact provide an incentive to not do so? Consider the fact that great software should just work with minimal support or training.
L0 says nothing about revenue sharing or other financial arrangements of more than one player.
L0's CLI _does_ support "stacking" metadata about available private licenses. So if you start an L0-NC project, I fork it and add my own significant contributions, folks who download my fork can tell they need private terms from both of us, at the prices we set independently.
I suspect many small projects, which are effectively single-maintainer, many-contributor, will accept contributions BSD-2-Clause, or offer waivers (essentially freebie private licenses) for the project in return for contributions on BSD-2-Clause terms.
There's some exciting work being done by others on transparent, automated licensing and royalties. As an aside, I think that line of research is far more promising for the kind of "network team", "swarm of contractors" business aspiration than models tackling, say, equity stakes or 701 plans. But it's not directly in scope for L0.
If you want to release open source, don't expect to get a payday - period. If you want a payday, use a commercial EULA. Simple as that. Trying to limit the usage of open source violates the open source definition and CAN'T be considered open source.
Nothing to see here, just a non-open-source license someone decided to write and then an article with the word "manifesto" in it to make it seem like it's worth anything.
I like the physical source manifesto much better. Which actually addresses the _actual_ problem with monetizing open source: that people can just copy your project and send it to someone else.
I was thinking for a while now that a license like this was needed, the redistribution of copies seemed to me the main problem. It makes so much sense to tie the code to a physical medium.
I plan to use physical source on a future project. Thank you so much for sharing.
The name is very misleading. I was expecting something minimalist like CC0 but it's actually more restrictive than GPL. Perhaps call it "License Plus" or something.
I don't really understand what this is offering but long-term open source contribution seems like a mug's game (outside of positions where you're paid to contribute). The argument is that it will supposedly get you enough notoriety to land a job, but if the guy who made Homebrew can't get that to happen, it's certainly not happening for me.
I have landed a job by contributing to Open Source project. After three years, the company got acquired, I got a Visa, and moved to SV. Life changing event, if you ask me.
What's broken is fucking Google and Apple who think their engineers are such hot shit they deserve a platform monopoly. Die in a fire. Web Forever. #federatedcloudhosting2020
