Developer here. We wrote Maria 6 years ago, and this fall I accepted a ClojuristsTogether grant to bring it back into active development. We hope to simplify/modernize the codebase to make it something people can hack on top of to add features & apply to new use-cases.
I see an effort like License Zero less as an encroachment on existing "Free and Open Source" licenses and culture, and more as an alternative to behind-closed-door development.
I want to _sustainably_ write software, not for donations but by having people who want to use it, pay for it. If I have to go closed-source to do so, then that's what I'll do. I don't have a big company behind me paying a salary.
But I would prefer to make things in the open, sharing my process; I'd like to allow students and other individuals to benefit from my work, either freely or very affordably; and I'd like to charge for-profit companies a fair price for what they receive.
The open source community tried to trademark the 'open source' label, and failed¹, precisely because it is _too descriptive_: it sounds like a generic way of describing source code that isn't private, not a specialized term with specific ethical and legal implications. But nevertheless the 'Open Source Definition' campaign has been rather effective in limiting use of the term. So I'm not even sure what to call what I want to do: maybe "open-source-ish"?
Some of my work belongs under OSI-approved licenses, but not all of it, and I appreciate that people like Kyle are working, creatively, on alternatives.
For what it's worth, L0 absolutely expects, but does not require, that source will be available, and development will continue with many of the same tools and platforms as MIT- or BSD-licensed code. It also expects _distribution_ to work much the same way. The terms for redistribution of L0 code are more or less the same as BSD.
Long story short, L0 code belongs on GitHub, and L0 packages belong on npm. It won't be hard to extend to other open languages, package systems, and platforms.
I agree that price discrimination can be a useful thing, but question the idea that only very large or wealthy companies should pay anything at all. What if licenses are low friction and affordable?
If we had a nice repertoire of flexible licenses available to play with, developers could experiment and try all sorts of ideas, including what you describe.
Non-FOSS-licensed software isn't going to play the same role in the ecosystem as FOSS software, but it doesn't have to. Plenty of room for different kinds of people/companies/software to co-exist.
>I agree that price discrimination can be a useful thing, but question the idea that only very large or wealthy companies should pay anything at all.
Because the more developers use a piece of software, the more valuable being able to use the software is. It's a classic network effect. Being able to write your commercial web app in Ruby on Rails is more valuable than being able to write it in a functionally equivalent framework with much fewer users of the software. This is straight from being able to hire developers familiar with RoR, access Q&A discussions, use third-party RoR tooling, etc.
Large companies tend to not be early adopters anyways, and they have the fattest checkbooks to raid for the value you're supplying, so it gets the most financial gain for the adoption loss you're causing.
I can see how that is true for some kinds of software. For many examples, network effects don't matter.
The first license I can remember paying for was Metafizzy's 'Isotope', a jQuery layout plugin. Great documentation and performance. I can't remember the price at the time, maybe $40 (now it ranges from $25 - $320). It was totally worth it, I was making money and clients were happy.
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.
> Customers who want permission for commercial or non-Open Source uses can identify, price, and buy licenses for all License Zero dependencies of their Node.js projects, in one checkout transaction, using a free command-line tool
As an aside: The fact that we're talking about buying licenses for something plus all its dependencies, recursively, in the context of node.js is hilarious to me.
Setting aside the practical detail that not everything is node.js: Nobody would want to sell commercial software under the terms of "you have to license our software A, but it won't work unless you also license software B from someone else at the same time".
There is already plenty of commercial software that depends on other commercial middleware that needs to be licensed separately. Of course licensing each and every library is typically bit different in scale, but conceptually it is pretty much the same thing.
Presumably that's where having a single place to handle payments comes in handy.
It's (hopefully?) less "well, you have to go to this other person and license their software too" as much as "here's the total cost for a license (which happens to include both A and B)"
Huh, fascinating. Licensing software by typing in a CC# via a CLI feels like a really foreign way to pay for something. I'm curious to see if that's behavior people take to easily.
I built this because I was totally new to writing parsers, and I liked Instaparse but wanted a faster feedback cycle. I was also excited to use CodeMirror with ClojureScript, two of my favorite tools. More broadly, I'm interested in the future of browser-based coding - I think there's a bright future in small, problem-specific coding environments in which the language, editor, and UX are carefully mapped to a particular problem.
Just as Excel is primarily graphical but allows power users to write formulas, with CodeMirror and Instaparse one can imagine designing a small language and mini-editor to expose advanced functionality within an app. (Here I expose options as an editable Clojure map instead of with a GUI.)
