A discussion of hybrid open source and proprietary licensing models.

[Rob Myers <robmyers AT mac.com>]

Before I respond to this document, I feel I should make my personal
position clear.

I'm excited that CC have created a list devoted to business and Open
Content. I've spent many hours discussing the CC licenses with
media professionals and trying to work out how they can benefit from
the Open Content model. I'm not a zealot, (I've also spent time talking
managers out of inappropriately Open Sourcing projects in the
past), but I do feel this is an important area. I've encountered
commercial and state projects that simply will not have a future
without Open Content.

I am however concerned about the precise stated aims of this list and
of the license being discussed. I fear they procede from false
premises, and that the emphasis on software is inappropriate for
Creative Commons. This feels like a step in the wrong direction. I
hope we can work together to get back on track.

I do believe that the Creative Commons licenses, and the CC toolset,
can be usefully examined and possibly extended by consideration
directly as business propositions. However it is important not to
approach this with an a priori belief that Open Source is
opposed to commerce, or that commerce is opposed to
community, or whatever.

Interesting case studies for Open Content and business include the OGL,
comparing h2g2.com and Wikipedia, and the film section of the Internet
Archive. In each case, it is creative thinking and willingness to
drive new models that has been the key to success (however that is
measured), not attempting to reassure the proponents of recently
developed yet already outdated models.

Right, on to the document...

On Thursday, August 19, 2004, at 11:40PM, Marshall Van Alstyne 
<marshall AT MIT.EDU> wrote:

>The goal is to create a license that captures the best of proprietary 
incentive systems
>and open source free distribution with peer review. This idea 
parallels the patent
>system wherein a right to exclude is briefly conferred. Here, using 
copyright, this
>license confers only a temporary right to exclude redistribution of 
copies.

The chilling effect of software patents on proprietary software
innovation is well known, and the Open Source community is concerned
that Microsoft (who have just patented the double-click), amongst
others, might use patents as their next attack on successful Open
Source projects. Patents are therefore not a good precedent for
creating value in software, only for excluding innovation.

>The key argument is that there exist economic reasons why a profit 
maximizing firm
>would move from a strict proprietary license in the direction of an 
open source
>license.

Like Sun, for example, who wished to resist Microsoft. Or IBM and Apple,
who need software to run on their computers. Or CA, who can no longer
afford to compete on a proprietary basis.

>Conversely, there exist reasons why a coder seeking to maximize user
>welfare would move from a strict open source license in the direction 
of a proprietary
>license.

IMHO there are not. Copyleft benefits users by benefiting developers. A 
user who
doesn't want faster time to market, reduced costs,  insurance against 
vendor
problems and absence of lock in is a peculiar user indeed. This goes 
for users
of the code as much as users of the binaries.

>Accordingly, this note articulates a meta-license that exhibits 
properties
>of both closed and open licenses but at different times.

The model proposed simply combines the disadvantages of both.

>The author of an original software work may make available a portion 
of the
>code in order that third party developers can enhance and extend it.  
In Raymond's
>catchy phrasing, many users need to scratch an itch and cannot adapt 
code
>without access to the original sources.  This process creates a 
derivative
>work in which the original author may exercise an interest.  Managing 
that
>interest, whether for public welfare or personal profit, is the 
subject of
>the enumerated tradeoffs below.

Releasing the APIs (for example for PhotoShop) drives sales of the
core product and directs 3rd party developers to making plug-ins
rather than developing alternative platforms. It's an ironised form of
lock-in and anticompetitiveness.

Microsoft's "public source" intitiative is horrendous. What's theirs
is theirs, whats yours is theirs. It makes no economic sense to
consumers. This is not better for consumers than copylaft.

>Our goal is to make this a publicly available and vetted license that
>would have benefits for firms as well as individual users, developers,
>and members of the broader open source community.

The separation of the interests of these groups is a product of
Proprietary methods. Open Source (at least Copyleft) redresses this.

>While standard open source licenses do not require developers to 
license their
>enhancements at cost, that is their economic effect.

It may or may not have been. If it has been, that will have been a
particular historical phase however. See Red Hat's new pricing 
structure.
This section also implicitly assumes that software is a valuable
commodity that must be the primary product of the company that then
distributes it. This model is not more than thirty years old, and if
applied to car manufacture would have very strange effects.

>If developers must give
>users both the enhanced code and the right to redistribute, then 
developers
>must compete with perfect zero-marginal cost copies of their own goods.

As opposed to proprietary manufacturers who must compete with cheaper
imitations and with piracy without getting any value back via copyleft.

How do companies sell bottled water? How do companies sell SUVs with
all those cheaper second-hand models out there and so many car
thieves in operation?

;-)

>Such
>markets can't sustain positive prices above transactions costs on the 
good itself.
>Although developers have attempted business models based on indirect 
compensation,
>such as services, they have not sustained prices that reflect the 
economic value of
>their innovations.  For economies not based on gift exchange, this 
leads to reduced
>social welfare characterized by under-investment in creating new 
information
>(Arrow, 1962 "Economic Welfare and the Allocation of Resources for 
Invention").

Again, this assumes that software (code) is a commodity, and that each
software commodity is developed somehow from scratch.

>One mechanism is to give developers pricing power in their 
enhancements by delaying
>the time until the right to redistribute a copy vests with users.  
This leads to
>declining pricing power over time as the open period approaches. The 
length of
>delay in rights to redistribute, i.e. a proprietary period of an 
enhancement,
>should set the area of the demand curve under developer price 
proportional to
>the size of investment one wants to call forth while also accounting 
for the
>opportunity cost of the developers time.  The key idea is that by 
allowing 3rd
>party developers to maintain certain rights in their own enhancements, 
the original
>author can attract deeper and more sustained complementary investments.

You would need to ban Open Source AND Proprietary software for this to
work. The only effect this would have is stop people aquiring the
software until it becomes free (killing proprietary sales), and to
stop developers contributing until it becomes Free (greatly reducing
the commons).

>Note that the offer of a proprietary period places no obligation on 
the developer
>to use it.  Rather it presents an option to be used at the developers 
discretion
>and he or she may choose the traditional open source gifting role, 
contributing
>back to the common code base at time zero or at any time that simply 
recovers
>costs.  It does, however, create an economic incentive for those who 
might wish
>to profit from their own innovation.

Again this assumes that software is commodity. It also assumes that
Open Source provides no benefit to the developers who give everything
away for free whilst receiving nothing in return.

Consider a different viewpoint: that having access to an incredibly 
large
and diverse library of Open Source code, which one "pays for" with
ones own code under copyleft, creates a powerful incentive to
developers, massively reduces their development costs, and reduces the
costs and delivery times for consumers (*including* other developers)

> The solution is thus to offer a public default contract, available to
>anyone, provided that developers meet other reasonable terms of the
>license.

Also known as the GPL. :-)

>Certain licenses, notably BSD, create incentives to introduce code
>versions that are incompatible.  This arises particularly in cases
>where developers are allowed to keep their code separate into
>perpetuity.  Forked code bases reduce consumer surplus via a reduction
>in standardization and network effects.

BSD does not have this effect at all. It is more a matter of
personality. You can fork just as easily with the GPL or other
licenses. You cannot go proprietary with them, though, which is BSD's
major problem.

Operating systems are modular, and consumer choice is good IIRC.
Forks are a problem, but less so than a project going
pathological (see the recent XFree86 fork for a good example of
this). Forks still compete in the same market as the original
codebase, and will be accepted or rejected on merit.

>Proposed solution: Require developers to return their enhancements to
>the open code base at a future date.

This was considered and rejected twenty years ago when the GPL was
drafted. Apple's APSL 1.0 contained such a clause and was rightly
rejected by the community.

>Note that developers can continue
>to sell if they wish but it becomes economically unattractive (see the
>1st issue above).   The original platform author can then use economic
>principles of bundling to discourage incompatible versions. These
>create barriers to competing product entry but they are not
>insurmountable.

Every little reduction in efficiency is detrimental. Free Software was
created to avoid such lock-in, and this has positive economic
effects. Reducing these positive effects to reassure reactionaries is
not in anyone's interests, least of all businesses.

>Of interest is that the fact it remains contractually feasible to fork
>the code base.  In order for this forking strategy to succeed,
>however, the economic value of the new offering must be sufficiently
>great  a developer must add sufficient functionality and offer enough
>competing bundles  that the forked alternative can survive in the
>market.  This permits a radical innovation to evolve while forcing it
>to pass a threshold test of value that has not simply been
>contractually excluded.

But this is how Open Source works anyway! The XFree86 forks weren't
easy to set up, and are competing in an open market on comparative
value proposition.

>Software permits near zero marginal cost transfer
>of the enabling technology throughout a value chain via access to
>source code.  A successful mechanism might therefore offer default
>rights to the community of developers after the developer of an
>enhancement has been compensated both for the costs of innovating and
>the opportunity cost of effort.  This simply occurs through the
>termination of the proprietary period and the commencement of the open
>source period.  The most successful or best-of-breed enhancements
>become part of the common code base while reducing economic
>distortions caused by multiparty bargaining.

This succesful mechanism is known as the GPL. Reducing its efficiency
will not increase the creation of value.

The GPL does not require you to disclose your changes *until you
distribute them* , and then you simply provide the sources publicly.
Licenses that force all changes to be disclosed, or that require that 
you
send all changes back to the code's original contributor, have been 
rightly
shunned by the market/the Open Source community as restrictive,
inefficient and error-prone.

>The creation of a public good, one that is nonrival and nonexcludable,
>simultaneously introduces incentive compatibility problems due to free
>riding.  In this case, a third party developer might wish to invest in
>an enhancement but also to dishonor the principle of releasing source
>code upon expiration of the proprietary period.

IIRC the GPL requries that if you provide/sell the binaries you must
provide the code. So even the freest of free-riders is still helping
ensure the distribution and availability of source code.

If they modify the source and don't provide it with the binaries,
they're in breach of the GPL. This exists and it works.

>Proposed solution: This could be achieved via a combination of IP and
>contract law but there is an economic solution. A platform authors
>task is to offer developers sufficient value through the open code
>base that a developer chooses to create a derivative work in
>preference to incurring the cost of a clean room.

Again, this is how Open Source works.

>This conditions the
>offer of developer profits collected during the proprietary period to
>be not less than those net of (i) the higher cost of a clean room and
>(ii) the lower cost of reusing common code.
>
>Note that another common problem of public goods, over-grazing or the
>tragedy of the commons does not arise in the case of software due to
>zero marginal cost reproduction.

Under BSD, the *future* of the commons is not ensured. Code goes
stale, technology moves on. If code gets taken from a BSD project and
improved but not released by a proprietary project, the tragedy of the
commons has occurred in all but name. That does not happen under the
GPL. This is an important point quite separate from zero marginals.

>If an author maintains a key complement as inaccessible proprietary
>code, then the author can potentially  appropriate the value of future
>enhancements via price hikes.  Once the developers enhancements become
>part of the open code base, they are relatively free but a user must
>still purchase any indispensible complement to receive his or her
>value.  Thus the original author could act as a monopolist with
>respect to the value of both his own code as well as the value he did
>not create.

Atomicity and lock-in. Even if the original author remains benign,
this reduces the creation of value.  This is why the GPL applies to 
entire
codebases. It's also one of the complaints against the OGL (atomicity)
and the KDE project (lock-in).

>Proposed solution: In order to encourage ex ante investment
>(i.e. before becoming sunk costs) by developers, the author must
>contractually commit to forgoing real dollar price hikes on any
>version of common code acquired by developers (versions of the SCSL
>don't do this for example).  This provides some assurance that on
>expiration of a developers proprietary period, forward value created
>by the developer will not simply be expropriated by the platform
>author.  The author, however, need not commit to price levels on his
>own future development.   This leaves the author free to continue
>adding value through innovation but, analogous to secondary markets in
>durable goods, future prices will be conditioned by the presence of an
>inferior substitute.  Prices on author enhancements will be
>proportional to the marginal value created rather than the growing
>stock of value created, which is socially more efficient.

This is overly complex, gameable, and is unneccessary if the software 
is just
GPL'ed or dual-licensed.

Dual licensing has its disadvantages. I'll talk about this another time.

>Note that if outside developers do not add sufficient value to make
>opening the code worthwhile, then a proprietary author will not open
>the source in the first place.  This merely restores the relevance of
>standard licensing arrangements.

No it doesn't. If the propritary developer's time to market and costs
can be reduced by using existing Open Source code, they have had
sufficient value added *before they ever start writing their code*!

- Rob.