Skip to Content.
Sympa Menu

cc-bizcom - [Cc-bizcom] Re: Comments on "Flexible Copyright Licensing - A Precis"

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
  • Subject: [Cc-bizcom] Re: Comments on "Flexible Copyright Licensing - A Precis"
  • Date: Mon, 27 Sep 2004 16:45:11 -0400

Hi Onno, a few clarifying thoughts follow:

At 08:59 PM 9/17/2004, Onno Kluyt wrote:
Couple of follow-ons inserted in the text below.

Onno.

One subtlety, however, is that we feel the platform author should get an immediate option to offer a new innovation as part of their own work such that (i) the price is no higher than that charged by the 3rd party developer and (ii) the proceeds on that piece go to the 3rd party developer. This encourages users to come to the platform author as the main supplier of all new pieces and it doesn't harm the innovation incentives because the developer gets the money anyway.
I wonder whether this works in practice. For large scale projects, say J2SE or J2EE, doesn't this become quite complex rather quickly?
If you'd have one or two contributions from other developers then it may work but does it scale?
This is generally addressed in the JCP in different ways but seldom (actually I don't know of a case) via proceeds sharing. The innovation is offered to the original author either for free or for an upfront one-off fee. The developer is then often further rewarded by public recognition for the contribution by the original author.

Ah, you raise 2 points, one on integrating complexity and the other on proceeds sharing.

Actually, I agree that the add-ons become complex rather quickly. This, however, is a key source of value provided by the integrator. Who else is in a better position to achieve the integration? It's also much more efficient to have the integrator (or someone) do this once than have lots of individual users repeat this step for themselves -- and this promotes adoption.

As to the proceeds sharing, this addresses the exact same problem that is always faced with a new innovation i.e. a market test of value. There's a reason that governments don't just buy new patents then place the idea in the public domain. No one really knows the value in advance of testing it in the market. So, how do you set the price? Answer: you let the market decide. If the individual innovator sets too high a price, he doesn't make any money.

...

I'd argue that the issue is probably not to contractually *forbid* forking of any kind since this also has the potential to retard true innovation. Rather it should be economically unattractive. A truly innovative radical innovation may still offer enough value to make forking worthwhile, but then this is precisely when forks should occur.
So, how do you make it economically unattractive?
This seems hard to do when there is substantial disparity in financial abilities between the original author and the party that is considering the fork, and the disparity being to the disadvantage of the original author. The GPL does seem to offer a defense strategy in this case because of its viral affect on other products bundled or dependent upon it.

Perhaps one needs to consider other strategies in addition to (or in support of) whatever license one puts on the original work: ie fortify the community against such actions via social and moral tools. The unwanted forking activity may then be rejected by the market on other grounds, or at least it could significantly increase the forker's costs in marketing and other activities for it overcome the resistance to its actions.

You do raise a legit argument in the financial resources of a determined Forker i.e. someone who wants to do this for private reasons, not because it's good either for the technology or the community. But for companies such as MS, this is always a potential problem.

Still the economics to prevent it can be quite strong.

We can make forking economically unattractive by using properties of bundling (which, BTW, is another reason to take the integration step suggested in the previous answer).

There are two good papers on this (one by Bakos & Brynjolfsson, the other by Nalebuff) but here's the key insight. By bundling goods together, you can make it harder for a competitor to market into your installed base. The reason is that your base probably already has your version of the component that your competitor is trying to get them to adopt, i.e. your version already came with the bundle, so they don't need another.

Nalebuff points out that when MS office first came on the market as a bundle, it wasn't best of breed in spreadsheet (Lotus was), word processing (honor went to WordPerfect), or presentation (honors to Persuasion)! But you got the whole bundle cheaply. Then if you bought it for the word processor, you didn't need to buy Lotus 'cause you already had Excel. So even though Lotus had a lot of resources, it couldn't promote adoption against any user who got a word processor (and office bundle) or a presentation package (and office bundle).

MVA




Archive powered by MHonArc 2.6.24.

Top of Page