5 ms·

An alternative solution could be to innovate in licenses. I think a lot of the problem is the idea that MIT/BSD-licensing is the ideal solution because it prom

by mwhite 12y ago

An alternative solution could be to innovate in licenses. I think a lot of the problem is the idea that MIT/BSD-licensing is the ideal solution because it promotes freedom the most. Clearly, using restrictively licensed components under currently existing restrictive licenses often isn't practical for businesses, but that doesn't mean that having everything be MIT/BSD is the end stage in the evolution of open source licensing. MIT/BSD-licensing promotes freedom for businesses, but hurts open source developers by requiring them to trust that they can be adequately compensated for their work by a reputation economy that's subordinate to a corporate system that we don't ultimately control. What if the open source community adopted a norm of dual-licensing open source libraries with the choice of a restrictive non-commercial open source license (basically, AGPL with an added non-commercial restriction) or a license that permits commercial use if you pay? The key would be that this dual-license would require that any derivative software also be licensed under the same dual-license. Wouldn't that preserve freedom as in free, while ensuring that open source developers are compensated for their work at levels that ensure and incentivize an optimally robust open source software base? The devil would be in the details but I bet there's a way to do this that preserves everything that's good about FOSS now and incentivizes better software.

walterbell 12y ago
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 http://www.riverbankcomputing.co.uk/software/pyqt/intro may be a software example, seems to be one developer.
- quadrangle 12y ago
  Non-commercial clauses mostly HURT adoption and cause incompatibility.
burntsushi 12y ago
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.
_delirium 12y ago
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).
- quadrangle 12y ago
  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.
drewcrawford 12y ago
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.
- pdkl95 12y ago
  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.

by mwhite 12y ago

walterbell 12y ago

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 http://www.riverbankcomputing.co.uk/software/pyqt/intro may be a software example, seems to be one developer.

quadrangle 12y ago
Non-commercial clauses mostly HURT adoption and cause incompatibility.

burntsushi 12y ago

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.

_delirium 12y ago

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

quadrangle 12y ago
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.

drewcrawford 12y ago

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.

pdkl95 12y ago
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.