[Cc-bizcom] 3 Page Proposal Summary
Marshall Van Alstyne
marshall at MIT.EDU
Thu Aug 19 18:06:36 EDT 2004
Flexible Copyright Licensing An Economic Précis
Our purpose here is to set forth, as briefly as possible, the main issues
in developing a socially optimal software license. It is not intended as
an article but rather a discursive precursor to both (i) a serious research
article and (ii) an actual license available for all. The former will
develop the theory while that latter will develop the practice. 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 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. 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. Accordingly, this note
articulates a meta-license that exhibits properties of both closed and
open licenses but at different times.
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.
Beyond this note, there are 3 associated documents. The first is an
economic logic showing how free information can be used to increase profit,
available from
<http://papers.ssrn.com/paper.taf?abstract_id=249585>http://ssrn.com/abstract_id<http://papers.ssrn.com/paper.taf?abstract_id=249585>=249585
. The second is a working paper, available from Geoff Parker & Marshall Van
Alstyne, providing an analytic model of the underlying tradeoffs of this
idea. One goal is to model key tradeoffs in software so that optimal
license design becomes a kind of recursive open science. The third is the
start of a license proposal developed by folks at MIT, the University of
Michigan, and Tulane that can serve as an experiment. These terms are open
for discussion and testing. A version of this license will attach to a
real software product hosted at MIT and sponsored by Phios Corporation and
the Center for Coordination Science. Another version will attach to an NSF
sponsored project housed at the Boston University. Commentary and feedback
are not only welcome but openly invited. 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.
Issue Destruction of 3rd
party developer incentives
While standard open source licenses do not require developers to license
their enhancements at cost, that is their economic effect. 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. 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").
Proposed solution:
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.
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.
Issue Information asymmetry on behalf of licensees & the monopsony problem
There is an innovation problem for many proprietary licenses. The developer
of a new idea may need to disclose his or her concept to the original
author in order to obtain both access to the source code and permission to
create a derivative work. As owner, however, the author is under no
obligation to license and, having learned of the opportunity, may simply
refuse to license and then exploit the opportunity without the
developer. This is the monopsony problem in which the existence of only
one possible buyer creates severe problems of hold-up and inefficiently
modest levels of trade.
Proposed solution: A virtue of open source software licensing is the offer
of a default contract requiring no review by the original author. Any
person with an idea can anonymously secure both access to source code and
permission to enhance it without disclosing private knowledge. The
solution is thus to offer a public default contract, available to anyone,
provided that developers meet other reasonable terms of the license.
Note that another version of this solution exists already in the form of
applications program interfaces (APIs). Much proprietary code exposes APIs
to programmers in order that developers can execute function calls on other
software. The current proposal is to extend proprietary licenses in the
direction of open source such that subroutines can be modified and reused
and not merely called.
Issue Code Forking & Incompatibility
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.
Proposed solution: Require developers to return their enhancements to the
open code base at a future date. 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.
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.
Issue Competition & Hold-up in the Value Chain
Technology markets frequently exhibit either component competition
or systems competition. In the former, an innovator can compete on the
basis of specializing in a uniquely low cost or high value part where they
have an advantage. In the latter, an integrator competes by offering a
high value collection without necessarily offering the best-of-breed or
lowest cost for any part. The economic consequence is that specialized
providers suffer hold-up by other bottleneck suppliers in the value chain,
while integrators suffer technological obsolescence and strategic defection
by specialist suppliers from whom they purchase. The crux is that
individual firms cannot perpetually provide the best of every part but
fragmentary rights distributed among multiple innovators create welfare
losses through multiparty bargaining.
Proposed solution: 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.
Issue Free Riding by 3rd
Party Developers
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.
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. 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.
Issue Strategic Misuse of Proprietary Code by the Platform Author
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.
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.
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. Again, however, one of the main goals is to move as much
software into an open source mode as possible. Thus, code that is
currently proprietary might become more open if the business logic for
greater openness is clear.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-bizcom/attachments/20040819/fed505fb/attachment-0001.htm
More information about the Cc-bizcom
mailing list