Skip to Content.
Sympa Menu

cc-bizcom - Re: [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: "<cc-bizcom AT lists.ibiblio.org>" <cc-bizcom AT lists.ibiblio.org>
  • Subject: Re: [Cc-bizcom] 3 Page Proposal Summary
  • Date: Sun, 22 Aug 2004 11:02:37 -0400

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




Archive powered by MHonArc 2.6.24.

Top of Page