The License Zero Manifesto

https://writing.kemitchell.com/2017/09/12/The-License-Zero-Manifesto.html

by vjeux • 9 years ago

190 185 9 years ago

writing.kemitchell.com

bskap• 9 years ago

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.

evancox10• 9 years ago

Well project A is using B for a commercial purpose, namely the business of licensing out A. So it seems like it would be your first option, right?

h34t5• 9 years ago

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

rspeer5• 9 years ago

Setting aside the practical detail that not everything is node.js: Nobody would want to sell commercial software under the terms of "you have to license our software A, but it won't work unless you also license software B from someone else at the same time".

lazerwalker4• 9 years ago

Huh, fascinating. Licensing software by typing in a CC# via a CLI feels like a really foreign way to pay for something. I'm curious to see if that's behavior people take to easily.

jpk• 9 years ago

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.

dsr_• 9 years ago

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

jerf• 9 years ago

Good point. If you can escape from the license by forking from it then it's worthless. Since that's obviously not the intent, then presumably a fork would still require licensing from the original source. Would it require licensing from the new source as well? If so, then forks are still theoretically possible, but the next question that raises is, are licenses compulsory? If not the original license holder still ends up with a veto over commercial use of the fork, simply by failing to give the license to anyone using the fork. Forks could conceivably carry on with purely-non-commercial licensing, but that's not a true fork.

Should the community get through this, then License 0 is going to get awfully complicated the day you decide to download the fork of the hottest new web framework that itself uses several dozen License 0 components, with arbitrary numbers of forks in them.

If licenses aren't compulsory then such a framework has the problem that suddenly there are dozens or hundreds of individuals that may decide for their own individual reasons to decline a license to someone that they may simply not like. (There is, in some sense, something to be said for greedy companies that just want your money and care nothing about you; at least they don't deny you licenses because you once gave their friend a bad interview experience, or violated some personal pet political stance.)

An option would be to just say "Yeah, these projects can't be forked." Which is a solution of sorts, but definitely one that is losing something very valuable from open source. The fact that such a license would be classified as "not open source" probably means something real, not merely that the definition is outdated.

There's an interesting idea here, but I think it's still the seed, not the fully-grown oak. But, again, let me end this with encouragement that the idea is being kicked around, and I'd like this to be seen as criticism in the spirit of refining and improving the idea, not merely being critical for the sake of being critical. There's some interesting ideas here in the service of a real need.

kemitchell31• 9 years ago

I have two lines of active thought around this for L0.

One is sponsored relicensing. It's possible today to set a price at which you'll relicense an L0 project onto vanilla BSD-2-Clause terms. In essence, you can put an estimate on future dual licensing revenue, discount it to present day, subtract any discount you'd apply for personal gratification in making it maximally available, and make a standing buyout offer at that price.

The other is an alternative public license for L0 projects, a very, very strong copyleft (reciprocal) license. That license should conform to the Open Source Definition. It's in review and revision with OSI now.

The reciprocal license would allow forks that meets its conditions, namely that the fork and other software that incorporates or uses it in development must be Open Source.

Dual licensing is fundamentally a privilege of initial copyright holders. When you fork, you almost always do so on the basis of your rights under the public license. If you fork under the noncommercial public license, you and users of your fork have to stick to noncommercial use, or pay for other terms on the original code.

geofft6• 9 years ago

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.

kemitchell31• 9 years ago

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

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.

splitbrain• 9 years ago

How exactly is "commercial" defined?

kemitchell31• 9 years ago

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.

nine_k3• 9 years ago

You are a commercial entity (a business and don't have a non-profit status), serve customers, and use the software in question to extract profits?

IANAL; I'd love a link / quotation of an exact legal definition.

Sir_Cmpwn• 9 years ago

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.

schoen• 9 years ago

The FSF and OSI models are meant to cover the same class of software (for example, both explicitly accept both copyleft and permissively-licensed software). So far I believe they've disagreed about the status of a total of two licenses, which are rarely used.

api• 9 years ago

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?

nailer3• 9 years ago

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.

dragonwriter4• 9 years ago

There are issues with this, but on the latter point: why are the GNU and OSI models an unquestionable religion?

The FSF Free Software and OSI Open Source definitions are the products of significant consideration of the logical impacts and experience of the practical impacts of software licensing (the former more heavily on the abstract, the latter on he practical, but interestingly they end up essentially identical.)

As such, deviations from those models that assert that they are both retaining the benefits and curing problems inherent to the models, while certainly not implausible, do call for careful examination.

mirabilos4• 9 years ago

Nor is it Ⓕ Copyfree compatible, and none of the BSDs would ever touch it either.

So that leaves you with adaption by unwashed unorganised masses who wouldn’t care about licence terms at all.

nine_k3• 9 years ago

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'

kemitchell31• 9 years ago

I've ended up doing the same for the other L0 public licensing option, L0-R, a stronger-than-strong copyleft license, in the Open Source Initiative license review thread. That license is still being revised, so I won't dump the pseudocode here. But pseudocode's been very useful in that discussion, too.

All the same, I don't quite feel like kudos are appropriate. I'd like to think I'm capable of writing the license terms plainly enough that regular old English speakers can understand them. But experience has taught me that I should translate to code, especially when I'm patching an existing license, rather than writing from scratch, as with https://github.com/berneout/berneout-license-kit (_very experimental_)

FWIW, I often start drafting legal code based on more structured pseudocode. Most lawyers I know who do a lot of drafting have some kind of personal boolean logic shorthand.

nine_k3• 9 years ago

The pseudo code expresses the gist very succinctly, hence kudos. It's like an abstract of a scientific article. Not all important details, but the few key things.

nobodyorother• 9 years ago

The trouble with these code snippets is that they condense very complex and squishy social structures into what incorrectly appears to be simple binary decisions. Creative Commons spent years defining what "commercial" means.

It's obviously a commercial use if I'm using your items to make money... But, what if I'm a charity? What if it's hosted on a website that runs banner ads? What if I don't turn a profit? This was a years-long discussion that you can review https://wiki.creativecommons.org/wiki/NonCommercial

Code emphasizes what consensus we need to come to, the consensus that those complex legal documents define. For example, that's part of why the GPL is so long, it's specific.

kemitchell31• 9 years ago

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

TheCoelacanth• 9 years ago

Also, how do you define "contributing"? Is one commit enough to get perpetual use? Do I need one commit a year/month? I can't think of a single definition that wouldn't either allow users who aren't making a significant contribution to cheat or screw over some legitimate contributors.

hk__2• 9 years ago

Agreed; that was helpful in understanding how it works. However the large imbricated `if`s make it harder to understand than a refactored version with early return's:

    def public_license (paid_available, commercial, contributing):
        if not paid_available:
            return 'standard, Open Source, two-clause BSD'

        if not commercial:
            return 'noncommercial, BSD-like license'

        if contributing:
            return 'contribution-enabling, BSD-like license'

        return '90-day free trial, then you have to buy a license'

kemitchell31• 9 years ago

Thanks for this. I did, actually, laugh out loud.

Pity me, brother. For functional programming ruined my young mind. And then I went to law school ;-P

shabbyrobe• 9 years ago

What if "paid_available == False" the first time, but later, "paid_available == True"? Is the "standard, Open Source, two-clause BSD" license that applies at first invalidated?

geofft6• 9 years ago

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.

kemitchell31• 9 years ago

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.

mwcampbell• 9 years ago

I don't think that the most valuable thing you have to offer is your software

What about the OP's point that typical OSS business models don't provide an incentive to write great software, but may in fact provide an incentive to not do so? Consider the fact that great software should just work with minimal support or training.

segphault• 9 years ago

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.

forsaken2• 9 years ago

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

sukilot• 9 years ago

https://en.wikipedia.org/wiki/Business_models_for_open-sourc...

liotier• 9 years ago

Scratch your own itch !

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.

hannob5• 9 years ago

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.

jdietrich• 9 years ago

https://news.ycombinator.com/item?id=10863901

archagon2• 9 years ago

One-click micropayment donations via web/OS standards and/or cryptocurrency; centralized patronage sites that allot money to OSS projects based on various metrics; different licenses for assets and code, with assets only available to licensees? Some ideas.

sjellis• 9 years ago

I suspect that the first step is for to break down the problem a bit more. Large projects need full-time developers, plus other kinds of expertise, which means organizations. For the long tail of libraries and small tools, I don't think that the problem is funding, it's team-building. If lone maintainers had better ways of recruiting extra team members to help carry the load, there would be a lot less of an issue with burn-out.

mirabilos4• 9 years ago

Just find something that brings bread on the table. Doesn’t even have to be software-related, could be, idfk, gardening.

kemitchell31• 9 years ago

L0 will offer a choice of public licenses: noncommercial and very strong reciprocal/copyleft. The reciprocal license is being revised and reviewed with OSI now.

hannob5• 9 years ago

How is your new copyleft license different from the existing ones, e.g. GPL-3 or AGPL?

As someone who's been active in a Linux distributions license team I see such activity with a lot of skepticism. There are already FOSS licenses for pretty much every wish and many of them are redundant. License proliferation causes more incompatibilities and more work for people who have to decide whether or not something is acceptable in a FOSS environment.

If people ask me what license they should choose the number one advice I give is that they should take something more or less ordinary (Apache, MIT, GPL, CC0), avoid obscure or unclear licenses and absolutely avoid writing up new licenses.

ryukafalz• 9 years ago

Will the reciprocal license be GPL-compatible? That's my biggest issue with licenses like these - they effectively lock out a big chunk of the FOSS ecosystem.

kartickv• 9 years ago

Thanks for doing this, Ken. I have a similar, but slightly different, motivation.

I'm working on Noctacam (http://noctacam.com), a camera app that uses computational photography algorithms to take better photos. I would like everyone to be able to reuse my work, without having to reinvent the wheel. But while paying me. Imagine if I released the source code, with a clause saying that its use requires a payment of money to me. Say $3 per user with a cap of $1M.

I don't want to distinguish between commercial and non, because most users of a camera app will be non-commercial, and in any case, I want everyone who benefits from my effort to pay me. Is it part of the plan to make L0 more flexible so that people who adopt it choose whether to make an exception for non-commercial use?

stcredzero2• 9 years ago

The encumbrances that this license places on the downstream modification and redistribution of code largely eliminate any of the material advantages that come from the code being open in the first place.

You should explain this. As far as I can tell from a 1st reading, so long as I'm non-commercial, I can just treat it as BSD 2 clause.

chungy• 9 years ago

That's the point, it violates the open source definition.

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.

dragonwriter4• 9 years ago

so long as I'm non-commercial, I can just treat it as BSD 2 clause.

No, you can't, because if it was BSD 2-clause, you could relicense it rather freely. But you can't with this, because the commercial use limitation makes it incompatible with many licenses with which BSD 2-clause is compatible. (Including GPLv3)

Also, because you have to include the full license terms (including the requirement to secure a commercial license from the agent of the original licensor) with derived versions, well, if AD ever gets competition as a licensing agent (even from someone using a compatible pseudo-open license), downstream commercial users of software which has modules with different licensing agents face the prospect of having to secure multiple commercial license from different licensing agents to see the software.

For a non-commercial end user of only the “root” software, it similar to BSD 2-clause. For developers (even non-commercial), it's much more restrictive.

bluetwo• 9 years ago

Ah, good old Shareware.

coldtea4• 9 years ago

Yeah, those days when a programmer could make a living, even a killing, from their work.

c-smile4• 9 years ago

Could you just define what does it mean "open source software" for your? And what is primary goal of software to be open?

alien_2• 9 years ago

Open source developers tend to maintain or contribute to multiple projects at the same time, and a small set of them can be monetized with this.

This allows monetizing those, and does it targeted to large companies who can easily afford it and would happily pay a few bucks to use the software (they would likely burn more money in a meeting discussing whether to adopt the said software or to switch to a free alternative) and I think it's a good trade-off if it allows indie open source developers to pay their bills.

On the long term those developers will generate much more open source output than when working as employees somewhere and creating only proprietary software all day and struggling to create open source only when they have some spare time a couple of hours a month.

In addition, all this licensezero software will be developed in the open, which brings many of the practical benefits of open source to a vast majority of the users, and the open source ecosystem will grow as a side effect that the developers will also create other software distributed under ordinary open source licenses. Even if just a fraction of their time would be spent on those other open source projects, that can make a huge difference to the ecosystem.

lazerwalker4• 9 years ago

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?

kemitchell31• 9 years ago

https://licensezero.com/licenses/private

https://licensezero.com/licenses/waiver

https://licensezero.com/licenses/relicense

lazerwalker4• 9 years ago

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!

mirabilos4• 9 years ago

There is still quite some amount of hubris in this.

If A writes software under L0 and gives it to B and is “nice enough” to allow B to use it privately for free, there’s some entitlement to the software.,

You’re overlooking that, in a contemporary environment, you’re standing on the shoulders of the giants (and all the small ones) who came before you. It’s absolutely presumptuous to write code in our time and not publish it under an OSS licence.

jasode3• 9 years ago

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.

woolvalley2• 9 years ago

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.

jasode3• 9 years ago

typical pattern of maintainer burnout [...] , since a successful open source project

Right, but that's what my "game theory thought experiment" was trying to dissect: the 90-day restriction can dissuade commercial entities from embracing that software so therefore, it's not "successful". As a result, there is no work overload and no burnout.

Which past open-source project can we confidently replay history with the L0 license and say it would have roughly the same commercial adoption and the maintainers got paid more money?

chii• 9 years ago

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.

xj9• 9 years ago

first off, linux is free software (a subset of open source) despite being considered "toxic" GPL is actually favors the creator quite a lot. (it is my suspicion that this fact is why it is labeled as toxic in the first place, but i digress) the copyleft aspect contractually obligates you to contribute back to the original project. this means that any company that uses your tech is effectively paying their staff to contribute to your project. this is a good thing as it prevents them from extracting value from the project.

linux is a great example of how a free software project can utilize corporate support to further its goals without becoming a victim of exploitation (unlike openssl, gnupg, &c.)

archagon2• 9 years ago

I mean, we can daily see how much effort is wasted on projects beholden to stockholders and business interests. In my experience, open source software is the only software that can stand the test of time; everything else will be pivoted, sunset, or bought out eventually. The problem is that it's so hard to make money doing it.

(Not that this is necessarily a good solution, mind you.)

kemitchell31• 9 years ago

There have been many examples. Some involving people very close to me. Some involving clients, who I can't talk about.

I'd encourage you to ask maintainers themselves. They aren't hard to find online. They're often happy to tell stories, the first time and the hundredth time.

jasode3• 9 years ago

There have been many examples. [...] I'd encourage you to ask maintainers themselves. They aren't hard to find online.

How would I know which maintainers to ask if you don't provide any examples of open source projects that would have gotten equivalent adoption by commercial entities with the L0 license? The 90-day restriction creates disincentives for use so that game theory has to be taken into account.

eternalban• 9 years ago

Open Source to me is e.g. the ability of a farmer to hack on his modern combine. And I would think it perfectly fine if the manufacturer voids the warranty in such a case. Note that the hypothetical farmer paid for the combine.

ChristianBundy• 9 years ago

Ken Mitchell

I'm not sure who that is, but I'm sure you could contact Kyle Mitchell[0] instead.

[0] https://kemitchell.com/

foo1012• 9 years ago

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

kemitchell31• 9 years ago

Everything is on the website:

https://licensezero.com/licenses

Everything is also being revised. So much good feedback!

whipoodle2• 9 years ago

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• 9 years ago

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.

woolvalley2• 9 years ago

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

kemitchell31• 9 years ago

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.

hathawsh3• 9 years ago

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• 9 years ago

In what ways would this differ from Patreon?

hathawsh3• 9 years ago

Patreon expects creators to advertise. The idea I had is that this business would actively seek both clients (who don't know they should be paying developers) and developers (who don't know how to get paid for their open source work).

geofft6• 9 years ago

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

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

agumonkey3• 9 years ago

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.

carapace2• 9 years ago

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.

agumonkey3• 9 years ago

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.

dragonwriter4• 9 years ago

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

kemitchell31• 9 years ago

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!

BFatts2• 9 years ago

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.

h34t5• 9 years ago

Many companies have no problem paying reasonable fees to license software they find useful. I don't see why they should stop paying, on some kind of ethical principle, if a developer decides to publish some or all of a product's source code on GitHub with a restrictive, noncommercial-use-only license.

Why should a developer be accused of greed for publishing code openly, but with paid licenses for commercial use? How is this not better, in absolute terms, than remaining closed source?

I figured that if devs don't want software used by companies, they could use the CC-NC licenses.

From what I can see, this is exactly what L0 provides, with the added _option_ that if a company _does_ want to use the software for commercial purposes, they can pay for a license with a credit card.

rspeer5• 9 years ago

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• 9 years ago

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.

colejohnson663• 9 years ago

While I agree with your comment, there are at least two big OSS projects that manage to disagree with this remark:

If companies have to pay for licenses to OSS they will simply stop using it.

Qt and Red Hat Linux.

cyphar5• 9 years ago

And SUSE. And Canonical. And LibreOffice. And OwnCloud. And NextCloud. And any number of other projects.

TylerJewell2• 9 years ago

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.

kemitchell31• 9 years ago

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.

TylerJewell2• 9 years ago

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.

BFatts2• 9 years ago

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.

davidjgraph• 9 years ago

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.

kemitchell31• 9 years ago

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.

patrickaljord2• 9 years ago

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.

staz• 9 years ago

From experience, the problem is not than SWE don't understand the license but that they don't like to negotiate.

When seeing the license on a project they need to use, most SWE will go tell their boss "Hey we need to pay for this" and the boss will find some convoluted way to tell him "Pay? No don't wanna".

The SWE will most likely stop negotiation at that step and has two choices: Either stop using the project and find a way to do without or continue using it.

Since they actually have a enormous pill of stuff to do by yesterday and this project will save them some time they will most probably continue to use it. And tell themselves that they are personally not doing anything wrong and that's the problem of someone else at the company.

If they feel guilty enough and you are sympathetic to them, they might throw a few bucks from their own purse but I wouldn't count on it.

If they sell a product based on your project, the SWE has some leverage since someone outside the company can take a look at it, but even then that's not a guarantee.

Source: Multiple try to convince my precious boss to pay for our fucking highcharts license

merb2• 9 years ago

By "commercial use" the majority of software engineers take that to mean selling.

well there aren't many open source licenses that restrict commercial use. Especially since it would violate https://opensource.org/definition part 6, well basically such definitions should be taken with a grain of salt. however even agpl3 can be used for projects where you do not need to share the code with the outside world. if you only share the code with the users using the project you are already doing everything correct. basically internal software.

barkingcat• 9 years ago

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.

kemitchell31• 9 years ago

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.

mirabilos4• 9 years ago

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

ThrustVectoring3• 9 years ago

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

kemitchell31• 9 years ago

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.

ThrustVectoring3• 9 years ago

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.

h34t5• 9 years ago

I agree that price discrimination can be a useful thing, but question the idea that only very large or wealthy companies should pay anything at all. What if licenses are low friction and affordable?

If we had a nice repertoire of flexible licenses available to play with, developers could experiment and try all sorts of ideas, including what you describe.

Non-FOSS-licensed software isn't going to play the same role in the ecosystem as FOSS software, but it doesn't have to. Plenty of room for different kinds of people/companies/software to co-exist.

ThrustVectoring3• 9 years ago

I agree that price discrimination can be a useful thing, but question the idea that only very large or wealthy companies should pay anything at all.

Because the more developers use a piece of software, the more valuable being able to use the software is. It's a classic network effect. Being able to write your commercial web app in Ruby on Rails is more valuable than being able to write it in a functionally equivalent framework with much fewer users of the software. This is straight from being able to hire developers familiar with RoR, access Q&A discussions, use third-party RoR tooling, etc.

Large companies tend to not be early adopters anyways, and they have the fattest checkbooks to raid for the value you're supplying, so it gets the most financial gain for the adoption loss you're causing.

x0x0• 9 years ago

Nothing is stopping anyone from granting a license for $0

nqzero• 9 years ago

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

h34t5• 9 years ago

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

kemitchell31• 9 years ago

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.

cestith• 9 years ago

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• 9 years ago

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.

slavik812• 9 years ago

That depends on what license Jane used for her contributions. A contributor license agreement (CLA) would make that a lot clearer in the case that she submitted her contributions back to the main project. If I used L0, I would definitely have a CLA.

If she forked it and maintained her fork separately, it seems simple enough how things work if she updated the license file. You'd just end up with the combination of her new license and Bob's old license. However, it is a little unclear what it means if she didn't change the license file. How can you be sure that she just hadn't yet gotten around to updating the payment information?

hasenj• 9 years ago

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

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

https://git.daplie.com/Daplie/daplie.com/blob/db7a9d0a72fa34...

SteveBash• 9 years ago

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.

erikpukinskis• 9 years ago

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

chrismorgan• 9 years ago

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

vortico• 9 years ago

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.

averagewall• 9 years ago

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.

coldtea4• 9 years ago

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• 9 years ago

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

coldtea4• 9 years ago

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• 9 years ago

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.

The License Zero Manifesto

Related Stories