Skip to Content.
Sympa Menu

cc-bizcom - [Cc-bizcom] 3 Page Proposal Summary

cc-bizcom AT lists.ibiblio.org

Subject: A discussion of hybrid open source and proprietary licensing models.

List archive

Chronological Thread  
  • From: Marshall Van Alstyne <marshall AT MIT.EDU>
  • To: "Matthias Urlichs" <smurf AT smurf.noris.de>, cc-bizcom AT lists.ibiblio.org
  • Cc:
  • Subject: [Cc-bizcom] 3 Page Proposal Summary
  • Date: Thu, 19 Aug 2004 18:06:36 -0400

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://ssrn.com/abstract_id=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.
 


Archive powered by MHonArc 2.6.24.

Top of Page