The License Zero Manifesto
writing.kemitchell.com
writing.kemitchell.com
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.
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.
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?
For example?
Is that a serious question? Ok...
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.
That doesn't scale…
No.
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).
[1] https://www.fordfoundation.org/library/reports-and-studies/r...
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.
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?
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.
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.
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?
Copyright law does not work that way, even if the license says otherwise.
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?
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.
See https://opensource.org/definition :
"6. No Discrimination Against Fields of Endeavor
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 also can't distribute it along with GPL code, at all, whereas combining BSD and GPL code is totally fine (the result is GPL).
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, ...).
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.
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.)
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.
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.
1. https://opensource.org/pressreleases/certified-open-source.p...
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.
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.
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.
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.
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.
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
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.
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.
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.
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.)
> If companies have to pay for licenses to OSS they will simply stop using it.
Qt and Red Hat Linux.
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?
I use and write open source because software is clay, not shiny spheres.
People often need to blend and mould code.
Tracking which bits of clay end up where is a huge burden.
Those fragments of code that Oracle sued Google over? That's where this leads.
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?
* 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
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)"
leftPad $$$
- 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.
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?
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.
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.
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.)
(Not that this is necessarily a good solution, mind you.)
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.
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'm not sure who that is, but I'm sure you could contact Kyle Mitchell[0] instead.
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 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.
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.
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.
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.
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.
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'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.
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.
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'Pity me, brother. For functional programming ruined my young mind. And then I went to law school ;-P
> License Zero is based on the two-clause BSD License, a classic permissive Open Source license, with two key additions:
> Commercial use is limited to 90 days
Which makes it seem like this is Open Source when it isn't.
> 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.
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.
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.
- There's already been extensive discussion on this shared source license on Twitter in the last 24 hours.
- The author keeps saying 'OSD compliant' rather than 'Open Source' as if there's another definition of Open Source other than the OSD. There isn't.
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!
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.
Please don't insinuate that someone hasn't read an article.
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.
So that leaves you with adaption by unwashed unorganised masses who wouldn’t care about licence terms at all.
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.
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.
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.
This post by 'patio11 on selling software is relevant: https://training.kalzumeus.com/newsletters/archive/enterpris...
(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.)
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!
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.
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 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.
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.
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.
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.
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.
What license would you provide the paid copy with? It should allow modification, linking, redistribution but only for the paying customer.
They're based on Apache-2.0:
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.
Relationships between devs and Artless Devices are all under the agency terms found here:
https://licensezero.com/terms/agency
A few points:
* "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.
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.
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”.)
(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.)
> must be limited to a period of 30} consecutive calendar days.
The stray “}” is clearly a typo, and if the description in the Manifesto is correct, the “3” should be a “9”.
This is kind of critical stuff to get right in a license.
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!
Put another way, all our problems now are psychological.
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.
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.
~ https://en.wikipedia.org/wiki/Trim_tab
no real point, just wanted to mention it. Cheers.
IANAL; I'd love a link / quotation of an exact legal definition.
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.
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).
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.
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.
in spite of the misleading name and the allusions to open source, this license scheme fails to capture that predictability
i've written a license that attempts to capture more of a balance: https://github.com/db4j/pupl
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'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.
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.
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.
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.
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.
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.
https://licensezero.com/licenses
Everything is also being revised. So much good feedback!
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.
https://daplie.com/articles/physical-source-an-honest-altern...
EDIT: seems link is dead, here's an alternate url:
https://git.daplie.com/Daplie/daplie.com/blob/db7a9d0a72fa34...
I plan to use physical source on a future project. Thank you so much for sharing.