Hacker News Reader

Having spent some time on the problem I agree generally with your approach, but the problem is it doesn't appreciate the history and context in which the current system has arisen and continues to exist.

There are basically 3 cases of successful FOSS projects:

1. Ideologically-driven, e.g. Emacs, GNU, etc. These tend to have licenses in the copyleft family

2. Commercially-driven, e.g. WebKit, Docker, etc. These are projects that are strategically important to one or several companies. They tend to have licenses in the MIT/Apache family

3. "Lone Wolf" or "indie developer". While a lot of FOSS is this by volume, what you discover is that by the time projects become popular they have generally evolved into one of the first two types, although they often preserve their creation story as part of the marketing material

The problem with charging money for code is that it's really a bad deal for the first two types. The ideology camp doesn't want non-commercial licenses because it's a "restriction on a field of use" which they have a philosophical objection about that you can google. In the second camp, the corporate masters derive some kind of strategic advantage from having a popular open-source project and charging money necessarily means the project would be less popular and so of less strategic value.

What this necessarily means is that if there's any legs to this plan, positioning it as "open source" or to the "open source community" is exactly the wrong approach, because basically all the people who are successful in that community will find it a nonstarter. Instead you have to hypothesize that there's some completely different set of people that can benefit from this system, writing completely new software (or releasing pre-written software that isn't currently considered 'open source', e.g., proprietary software). So your positioning needs to be something like "proprietary 2.0" or even "third way" rather than being connected with open source.

The real problem with this system is that I'm not sure there's a market on the buying side. Developers are used to getting things for free, and even if somebody wrote a source-visible-but-pay-$1k-to-use-it high-quality TLS library I'm not convinced that people wouldn't just keep wrestling with OpenSSL because it's free.

I have a whole blog post I'm drafting on this topic, if anyone reading this comment is interested, give me a shout and I'll give you a preprint.

This kind of situation where there is a common need for something, but there isn't a reasonable way to pay for it in individual transactions has a traditional solution: make the project publicly funded.

As an example, a military is a useful thing to have for protection, but paying for it as some sort of subscription or "per-invasion" billing is obviously not a realistic solution. So we fun it publicly, as a tax, which generally works[1]. Similarly, it might be useful to make a publicly-funded service that is charged with creating software infrastructure such as TLS or even libc that are difficult to fund directly.

There are a few advantages to using public funds: unlike traditional Free Software, as it uses public funds, the output would be public domain, and usable by anybody, commercial uses included. Also, as it doesn't have to worry about VC money drying up or "maximizing shareholder value", it would be easier to stick to a mandate that emphasizes quality instead of time-to-market.

On the other hand, problems with this idea would be the general concerns about corruption due to political meddling, and how to keep the NSA from pulling a BULLRUN on it like they did to NIST.

<speculation> Perhaps a "dept. of software infrastructure" could take over the "defense" side that the NSA seems to be neglecting recently. Moving all industry interaction (and trust) over to the new, open group so the NSA was known as spying-only might improve the relationship a bit... </speculation>

I'm not sure if this is a particularly good solution to the problem, but it's worth considering.

[1] Of course, there are details to argue over and bugs in the system to fix, just like any complicated project.

There's a free-rider problem if the funding is from a national funding body. Since software is generally useful globally, the funding body would have to be international.

Free-riding would be an issue, but not necessarily a fatal one. As long as the national benefit equals the national expenditure, it'll work.

Some sort of international version would be a good idea, if some reasonable plan could be created.

Regarding "free-riders", consider compatibility and interoperability. Some amount of "free riding" may be desired if it means you don't have to spend as much time and effort making things work together. These benefits may not be as important at the application level, but for infrastructure, these can be very important features.

The real problem with this system is that I'm not sure there's a market on the buying side. Developers are used to getting things for free, and even if somebody wrote a source-visible-but-pay-$1k-to-use-it high-quality TLS library I'm not convinced that people wouldn't just keep wrestling with OpenSSL because it's free.

Moreover, (far) fewer developers would base another complimentary project (open source or commercial) on that new $1K-to-use TLS library, because now their new project would be encumbered by a $1K hurdle that brought them neither revenue nor glory. So, they'd continue to wrestle OpenSSL in order to further the adoption of their own package.

I realease all of my open source work under copyfree licenses and I've never heen "hurt" by it. I don't have to trust anyone---I write code that solves problems of interest to me and I put it out there for others to use if they want to.

Adopting some complicated dual license sounds like a surefire way to stop people from using software I write, which runs contrary to my goal.

That's a fairly traditional approach for academic software: source made available but under a non-commercial/research-purposes style license, and a commercial license sold for commercial uses. It's been successful in some cases, mainly when active effort is made to sell the commercial product (e.g. through a spinoff company).

Just a standard GPL+commercial or AGPL+commercial dual-licensing route also works for some companies, without having to add on an explicit "non-commercial" restriction. Depends on the software and the market. MySQL made money doing that for years, for example. Qt also does something like that, although they further enhance the commercial version with closed-source features in the Enterprise tier (another common way of differentiating).

The mission of Snowdrift.coop, the site mentioned in the original article is to fund things specifically without relying on artificial restrictions like proprietary licensing.

Has this been proven with CC non-commercial licenses, e.g does the non-commercial license function as lead generation for commercial sales?

http://www.riverbankcomputing.co.uk/software/pyqt/intro may be a software example, seems to be one developer.

Non-commercial clauses mostly HURT adoption and cause incompatibility.