
The License Zero Manifesto - vjeux
https://writing.kemitchell.com/2017/09/12/The-License-Zero-Manifesto.html
======
segphault
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.

~~~
forsaken
So, what is your suggestion for funding truly open source software, then?

~~~
hannob
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.

~~~
atomashpolskiy
> Plenty of FOSS is well funded

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...](https://www.fordfoundation.org/library/reports-and-
studies/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/)

~~~
Applejinx
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.

------
h34t
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.

1\. [https://opensource.org/pressreleases/certified-open-
source.p...](https://opensource.org/pressreleases/certified-open-source.php)

~~~
kemitchell
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.

------
davidjgraph
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.

~~~
kemitchell
Thanks for sharing this.

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.

~~~
patrickaljord
> 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.

~~~
kemitchell
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.

------
BFatts
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.

~~~
rspeer
CC-NC is not a license for code.

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.

~~~
ghaff
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.

~~~
rspeer
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.)

------
cestith
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?

~~~
andybak
This comment crystallizes my concerns.

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.

------
bskap
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.

~~~
h34t
I believe L0 makes your second option painless:

> 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

~~~
jpk
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.

~~~
slavik81
I suppose you'd need to pay to update if anything in the dependency tree added
a new L0 dependency. I wonder how that would affect development.

------
jasode
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.

~~~
woolvalley
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.

~~~
chii
> 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.

~~~
alien_
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.

------
ThrustVectoring
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".

~~~
kemitchell
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.

~~~
ThrustVectoring
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_.

~~~
kemitchell
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.

------
nine_k
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'

~~~
nobodyorother
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](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.

~~~
kemitchell
L0-NC uses CC's language defining "commercial".

------
Sir_Cmpwn
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.

~~~
api
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?

~~~
nailer
They're not, but it's important to distinguish Open Source from other types of
licenses, and avoid statements like:

> 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.

~~~
foo101
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!

~~~
nailer
\- It's better to avoid making misleading comments in the first place rather
than retroactively correcting them.

\- 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.

~~~
kemitchell
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!

~~~
nailer
> 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.

------
barkingcat
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.

~~~
kemitchell
My marketing plan at this point is stickers.

"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.

~~~
mirabilos
It’s misleading because it pretends that you need zero licences for it.

------
hathawsh
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.

~~~
nix0n
In what ways would this differ from Patreon?

~~~
geofft
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.

This post by 'patio11 on selling software is relevant:
[https://training.kalzumeus.com/newsletters/archive/enterpris...](https://training.kalzumeus.com/newsletters/archive/enterprise_sales)

(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.)

~~~
hathawsh
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.

~~~
kemitchell
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](https://licensezero.com/licenses/private/diff)

------
chrismorgan
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).

------
lazerwalker
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?

~~~
kemitchell
[https://licensezero.com/licenses/private](https://licensezero.com/licenses/private)

[https://licensezero.com/licenses/waiver](https://licensezero.com/licenses/waiver)

[https://licensezero.com/licenses/relicense](https://licensezero.com/licenses/relicense)

~~~
lazerwalker
Thanks for those links!

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!

~~~
kemitchell
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.

------
dsr_
Doesn't mention forking at all, and that's a big thorny problem.

~~~
geofft
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.

~~~
kemitchell
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:

[https://licensezero.com/terms/agency](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.

~~~
dragonwriter
> 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”.)

~~~
geofft
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.)

------
dragonwriter
So, the linked license itself[0] has at least one typo in clause 3:

> 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.

[0]
[https://licensezero.com/licenses/noncommercial](https://licensezero.com/licenses/noncommercial)

~~~
kemitchell
Nice catch! And fixed.

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!

------
agumonkey
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.

~~~
carapace
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.

~~~
agumonkey
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.

~~~
carapace
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.

~
[https://en.wikipedia.org/wiki/Trim_tab](https://en.wikipedia.org/wiki/Trim_tab)

no real point, just wanted to mention it. Cheers.

~~~
agumonkey
I didn't know actually, so thanks. Let's hope my toread list dissolves fast
enough :)

------
splitbrain
How exactly is "commercial" defined?

~~~
kemitchell
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.

------
coldtea
How about a license that says:

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.

~~~
drewfish
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).

~~~
coldtea
> _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.

------
throw2016
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.

------
nqzero
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've written a license that attempts to capture more of a balance:
[https://github.com/db4j/pupl](https://github.com/db4j/pupl)

------
TylerJewell
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.

~~~
kemitchell
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.

~~~
TylerJewell
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.

~~~
kemitchell
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](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.

------
geofft
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.

~~~
kemitchell
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.

------
foo101
I am having a hard time finding the actual legal text of the license. Can
someone share it here?

~~~
kemitchell
Everything is on the website:

[https://licensezero.com/licenses](https://licensezero.com/licenses)

Everything is also being revised. So much good feedback!

------
woolvalley
How does this work in a project with multiple contributors, how does the money
get distributed?

~~~
kemitchell
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.

------
BFatts
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.

------
vortico
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.

------
hasenj
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.

[https://daplie.com/articles/physical-source-an-honest-
altern...](https://daplie.com/articles/physical-source-an-honest-alternative-
to-open-source/)

EDIT: seems link is dead, here's an alternate url:

[https://git.daplie.com/Daplie/daplie.com/blob/db7a9d0a72fa34...](https://git.daplie.com/Daplie/daplie.com/blob/db7a9d0a72fa340ee13fd1de0936a5886746223b/posts/physical-
source-an-honest-alternative-to-open-source.md)

~~~
SteveBash
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.

------
averagewall
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.

------
whipoodle
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.

~~~
dpc_pw
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.

------
erikpukinskis
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

