[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 
developer’s 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 
developer’s 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 author’s 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 developer’s 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