A discussion of hybrid open source and proprietary licensing models.

[Marshall Van Alstyne <marshall AT MIT.EDU>]

At 04:36 PM 8/20/2004, Rob Myers wrote:
> 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.

Excellent.  I think this is also where we want to go.


> 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'd agree that software is just an element of a broader issue about access 
to information.  As to being 'on track,' that should emerge from the 
interplay of ideas presented here.  I don't think you or I should have a 
monopoly on that -- but I do look forward to working together.

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

Definitely agree here.

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

There's more common ground here than I think you realize.  I didn't plan to 
present it here but, as a sidenote, I thoroughly oppose the approach RIAA 
has been using to manage its IP.  I also applaud the 9th circuit court dcsn 
upholding a lower court, reported yesterday in the NYT "File-Sharing Sites 
Found Not Liable for Infringement"  Basically, Judge Thomas found that the 
producers of p2p can't control user behavior, also noting that the courts 
are ill suited to "fix the flow of internet innovation."  Which is exactly 
right.

I strongly argue that in this case, and for the one we are discussing, the 
key is a better business model. ... which is why we are here. :)


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

Whoa! Who said anything about 'software' patents?  There is good reason to 
believe that such patents *do not* promote innovation but retard it (see 
for example the academic writing of James Bessen on software patents).  So, 
again, I think we agree here.

They do make for a good straw man to attack though :)

Rather, I was referring to the "patent system," the constitutionally 
granted authority of congress to promote progress in science and the useful 
arts.  The sheer universality of these systems across the globe and across 
generations suggests they do perform a valuable role in innovation.

In fact, the kind of idea I had in mind is very much what Mike referred to 
in his previous post on a founders' license from Kevin Burton (repeated for 
ease of ref 
http://www.crynwr.com/cgi-bin/ezmlm-cgi?msp:8552:fjedblbemkibalcomejd )


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

OK some disagreement here.  Most of these benefits are real; but I also 
know several sophisticated programmers who choose proprietary packages over 
their open counterparts either for GUI reasons, compatibility, or for 
enhanced functionality (especially in the area of security).

Now, let me challenge you a bit.

If we accept that such users exist, can we understand what reasoning would 
make their choices rational?  I'm not a big fan of the "this or that party 
needs education" school of thought because intelligent people, when 
presented with the same facts, frequently disagree.  If we can understand 
why their choices make sense, we're more likely to find grounds for mutual 
gain.

So, is there any reason why paying for software makes sense?

The best reason I've heard is that one package offers some benefit not 
available from another package (and this applies to many things other than 
software).  But, I'm eager to hear other reasons...

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

Yep.  Agree here.

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

Now who's assuming these groups have to collide?!?


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

30 years in software years seems like an eternity.  If the biz models are 
still unstable, IMHO something's not right.


> >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?
>
> ;-)

Bottled H20 is a great example.  Clearly branding has a lot to do with it.

The SUV example, however, doesn't seem to hold up.  As a rival good, it 
can't be perfectly copied so the person with physical possession is the 
only one who gets to sell it.

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

No, I don't want to assume this.  Most novel ideas and information, 
software especially, builds on the shoulders of giants. This is why free 
information in the liberty sense is so important.

My point is different.  Suppose we were to make all intellectual property 
suddenly free in the liberty sense -- whatever it is, you have the right to 
take it, modify it, use it, and redistribute it -- and so does everyone 
else.  Then it necessarily also becomes free in the pricing sense.  You 
could never charge expressly for the value of a new idea per se.

If this were to happen, could Pfizer afford to invest in developing Lipitor 
or Glaxo invest in antiretrovirals? Could Intel invest billions in next 
generation chips?  Society loses if these investments in forward innovation 
don't happen.

The problem seems one of balance.  What's the best way to reward 
innovation?  What's the best way diffusion innovation once it's 
occurred?   The answers to these questions seem frequently in tension.


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

Don't agree here.  The idea from Kevin Burton (from Mike) is quite similar.

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

Not quite.  Rather, I assume that SW *can* be a commodity.  If the 
principal purpose of the developer who created it  was to make it a 
commodity (and this applies not just to SW), then he or she ought to be 
able to charge at least briefly for his or her output.

There are several articles examining developer motivations and at least two 
(Lerner & Tirole, and also Hann, Roberts, Slaughter, Fielding) show some 
good reasons either why or that developers can have economic motives.

These aren't inconsistent with other motives.  Diff people just give them 
diff relative weight.


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

Yes, this is actually one of its best features.

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

Disagree with the 1st claim based on the last.  When derivative works can 
remain proprietary for long periods of time, they fork.  This is a weakness 
of proprietary models that I do want to highlight.

One of the nice features of GPL, is that although you can fork, there's 
little incentive to do so.


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

Again, I like the same idea presented by Burton.

I also think the idea has to stand or perish based on a good model of the 
consequences.  Everyone's assumptions and inferences need to be put into a 
model where the limits for truth of an assertion can be tested.

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

This is a good thing.

Actually, there are other ways to make forks seem economically unattractive 
and these forces need to be understood in the marketplace.

Here are three articles using information economics that show how packaging 
can make life tough for competing products.  One is mine with a colleague, 
the others are by Bakos & BrynjolfssonNalebuff, and by Nalebuff:

1) on how free information can be profit maximizing and create barriers to 
entry for other products:
    http://papers.ssrn.com/sol3/papers.cfm?abstract_id=249585
2) on how bundling can be profit maximizing
    http://papers.ssrn.com/sol3/papers.cfm?abstract_id=231598
3) on how bundling creates barriers to entry for other products
    http://papers.ssrn.com/sol3/papers.cfm?abstract_id=185193

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

All hail the GPL!  Is there anything it can't do? :)

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

Yes, this is like the forking problem earlier.  Here's why expiration of 
the proprietary period makes sense.

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

Doesn't seem correct.  It's true that this reduces 3rd party creation of 
value.  It can, however, motivate the original author to have something to 
sell.

Again, this seems like a question of balance.  If it's a tiny project, then 
maybe 3rd party contributions aren't critical.  If it's a major project 
then maybe 3rd parties are essential.

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

Interested in hearing more about this...

MVA