A discussion of hybrid open source and proprietary licensing models.

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

A very bright fellow from Sun Microsystems asked several additional 
questions about the precis so with his permission, I'm forwarding those 
questions with answers below.

----------------------------------------------------

Hi Onno, I just got back from working on research at Tulane and had the fun 
of evacuating from New Orleans -- fortunately, it seems to have missed the 
city but it was an odd experience.  So, to reply to your input...

At 07:54 PM 9/8/2004, you wrote:
> Hi Marshall,
> here are some comments and thoughts on this paper (finally...).
>
> In the 3rd paragraph ie says "... and cannot adapt code". Did you mean 
> "... and cannot adopt code" ?

For this part, we did mean 'adapt' since denying access to source means it 
can't be changed (although executables could be used).


> Issue - Information asymmetry
> -------------
> I want to check how to interpret the proposed solution. The permission to 
> enhance is that meant in the context of the copy of the source code that 
> the developer downloaded, or in the context of being able to make 
> modifications to the main source tree? I am assuming that it is the former 
> because anonymous check-ins seem quite risky if only from a IPR perspective.

Here, you're right that we meant permission to enhance a copy.  As to 
check-in, you're input is at a more detailed level than we wrote about.  We 
don't actually discuss things like anonymous check-in and focus just on the 
risk to a new developer with a great idea (could he or she lose this idea 
to the 'owner' of the code?).

As a practical matter, however, your point about IPR is well taken and one 
we definitely intend to deal with in any realized license.


> With regards to APIs, just a remark that the usefulness of a disclosed API 
> to a developer is not only the knowledge of the existence of that API but 
> also correct expectations on the behavior of these subroutines. Perhaps 
> off-topic...

Interesting; thx.


> Issue - Code Forking
> ---------------
> The proposed solution seems to describe Sun's SCSL in general terms?

In a way yes.  Actually, however, Stallman recently pointed out to us that 
the GPL also has the effect of discouraging (but not preventing) forking 
since follow-on work is also accessible not just the first generation.

We need to clarify out language in that we'd actually expect subsequent 
innovations to not only be "licensed back" but really "freely available" in 
which case the platform author could use it anyway as could others who 
depended on it.


> The proposed solution for this issue seems at odds with the previous 
> issue: requirement to disclose, to license to the author?

Our bad in terms of language.  What we really mean is "freely available" 
(as in previous point).

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.


> With regards to the third paragraph, the economic value to the forker does 
> not necessary need to come directly from the forking action. The forker 
> may have indirect economic motives: to disrupt a competitor, for example.

Agreed.  In fact, one of our previous papers makes a similar point albeit 
as a reason to give a good away for free rather than to fork it.

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.


> Issue - Competition & Hold-up
> ----------------
> The JCP has its own flavor of this issue, especially in the J2ME space. 
> There, much more so than in the JSE and J2EE space, various JSRs are led 
> by various companies: multiple JSRs from multiple sources are needed to 
> build a Java-enabled phone which also leads to multiparty bargaining.

Very interesting.  Can I quote you on this? :)

We really would like to be able to solve this problem and we think copyflex 
can help.


> There seems to be additional competition between the innovator and the 
> integrator in that the integrator will also be attempting to higher the 
> bar of what the integrated product or system offers. For example, there 
> are no TCP/IP stack suppliers anymore, and hardly any standalone spelling 
> checkers. Another example would be browsers and operating systems. In 
> other words, the innovator must keep innovating ahead of the integrator to 
> survive but eventually the integrator will take away economic incentive 
> for innovation in certain areas.

This is a great intuition.  Still, I think the tradeoff is more nuanced.

We agree that survival means continuous innovation.  In fact, one of our 
strongest arguments for copyflex is that this should make the entire 
business network more competitive against other business networks.  If 
Java, for example, is competing against .NET then you really really want 
this property.

This is also why any fees that the integrator earns on the innovation must 
go to the innovator, at least through the entire proprietary period.  If 
this happens, the innovator should not feel threatened by competition from 
the integrator during the proprietary period.  It's only after this period 
has expired.

As an aside, we also think that there should be slightly different 
proprietary periods and that innovators can, within reason, buy slightly 
longer times with larger royalties.  This ties the interests of the 
integrator and innovator together.

Interestingly, the growth in the business network fueled by expiration of 
the proprietary period is also what should make joining this particular 
network attractive for the innovator.  We just finished an analytic model 
that shows how the whole class of 3rd party innovators can earn more in 
future periods if they're willing to "cross-license" each other at the end 
of the proprietary period.  The advantage of copyflex is that this 
cross-licensing occurs with no negotiation costs because the business 
network gains access to each innovation in due time.


> I am wondering about the proposed solution whether it requires "must 
> do"-behavior for all participants. How I assume the solution to work is 
> that the author through its license on its source code offers the ability 
> of the proprietary period to its licensees (eg you can make and 
> redistribute modifications if you promise to release under open source 
> license after 2 years). It seems that this only works if this would be a 
> requirement not a choice, ie if a licensee could choose to forego the 
> proprietary period then s/he can basically undercut everybody else.

I'm not sure I fully understand "must do" so let me reply to 2 diff 
interpretations:

If the "must do" issue is to promise to release under a free license after 
say 2 years, then yes.  This is a hard requirement.

If the "must do" behavior is for the licensee to charge for an innovation, 
then no.  I'd always want to give an innovator the option to freely 
distribute their new work if that's his or her choice.  Then presumably no 
one gets to charge for the intrinsic value (users get this value) beyond 
the value of integration and conformance testing (which any other party 
could also offer).


> You would also have to work out how it relates to the previous issue. If 
> the author has a "license back"-requirement for innovations and also 
> offers this proprietary period to its licensees then should the author 
> also commit to not fold back the innovation back into the common code base 
> until after the proprietary period?

We envision this as allowing the integrator to offer an à la carte option 
to users of including the innovation at whatever price the innovator 
chooses.  As noted above, the integrator gets to charge the same price as 
the innovator with the money going to the innovator.  This simply 
represents a 'pass through' with the integrator having permission to 
collect fees and pass them through to the innovator.  Of course, the 
innovator can also make the new code available but he's not worrying about 
competition because he sets the price and he gets the revenues on his piece.

For similar reasons, this 'pass through' also reduces the integrator's fear 
of forking since he can always offer a fully functional version.  But, the 
integrator does not get to make money on the 3rd party innovation.  He 
didn't create it.  Rather, the integrator benefits from having a more 
valuable business network as a whole.

But, we're *completely* open to alternative suggestions.


> Issue - Free Riding
> ----------------
> The opening paragraph seems to talk about forking and not contributing the 
> fork to the community. The proposed solution seems to talk about creating 
> incentives that favor derivative works over clean rooms. Aren't these 
> different things?

Here, rather, we're talking about "incentive" compatibility not "code" 
compatibility so it's not quite forking.  The idea here is to give someone 
making a derivative work enough reason to make a *derivative* work, and so 
be bound by the license.

One can imagine that a business network becomes so valuable that some firms 
prefer to attach to the network but not ever give up their innovation.  As 
in the case of the Phoenix bios, it's possible to put a chinese wall 
between developers and the competing source code and so create a whole new 
system that is not bound by the license.  ( This would be a fork but in 
property rights only and not technology since the code should be 
compatible, else it won't attach to the network )

Firms will be less motivated to choose the clean room if they perceive that 
they get enough value from the licensing terms that behaving honorably is 
also economically rational.


> What is "the tragedy of the commons"?

It's econ-speak for a public goods problem.  Imagine a public commons or 
park where everyone has the right to graze their cattle.  Then you tend to 
get over grazing since each person can fatten his cows as much as he 
wants.  If you do this, the externality is the cost to other farmers more 
than the cost to yourself.

This is less of a problem for truly nonrival goods since each person can 
'consume' a free zero cost copy.


> Issue - Strategic Misuse
> -----------------
> "Prices on author enhancements will be proportional ..."
> I fear I don't understand this sentence (a long time since my Economics 
> 101 class...).

Good question.  I admit to having originally written this note for myself 
as a way to record ideas rather than convey them so apologies for lack of 
clarity.

There are 2 ideas here:  (1) after-market product competition (2) total 
value versus marginal value.

So, here comes a bunch of econ...

The first idea comes from durable goods like books, cars, and washing 
machines but it applies especially well in markets where you can make 
perfect copies (e.g. information).  In a durable goods market, you can 
re-sell a product after you've grown tired of it (assuming it still 
works).  So, for example Amazon can offer used books for sale on its 
website to compete with the new ones.  This "after market" in fact raised a 
huge stink among publishers who feared that it might lower prices on new books.

One very interesting phenomenon due to aftermarkets is that they can lead 
to prices like those in competitive markets even for goods where the 
original manufacturer holds a monopoly.  With a few caveats, aftermarkets 
limit price gouging because they create an effective alternative source 
even when there is only one original manufacturer.

The way we make use of this in copyflex is to address the problem of an 
indispensable complement -- some piece of code that you must buy in order 
for the whole system to work.  A clever integrator could try to keep a few 
indispensable complements proprietary in order to raise prices later on.

If total value of the system is the sum of all the indispensable 
complements and all the subsequently free innovations, then an integrator 
might be tempted to set the price of the indispensable complements at the 
value of the whole system.  That would be wrong.  It would also discourage 
3rd party innovators.  So we should require the platform author or 
integrator to either (i) contractually commit to no price hikes on the key 
pieces or (ii) allow an aftermarket alternative source at no more than the 
original price.  Then there will not be future price gouging and there will 
be greater willingness to contribute innovations.

Interestingly, GPL actually has this property more than most licenses 
because every user can become a supplier in the aftermarket.

FWIW, I think this is one of the main flaws with the current SCSL in that 
it does not commit Sun in future periods, and this limits contributions in 
the current period.

But, solving this commitment to not raise prices can introduce another 
problem in that the integrator should also be encouraged to innovate.  The 
value of each incremental innovation, whether by a 3rd party or the 
integrator, *should* be rewarded.  This is the marginal value of one piece 
as distinct from the total value sum of all contributions.

The integrator (as well as any innovator) should be free to set a price, 
however briefly, on any new innovation they create.  So the aftermarket 
clause that creates future alternative sources should only bind on the 
stock of existing code, not the new marginal value contributions.  It is 
after a proprietary period elapses that new innovations later become part 
of the code stock as distinct from the new marginal value.

> I wonder whether there's a different angle to the last paragraph. Aren't 
> many open source projects created just so to stave off modifications or 
> innovation by others? The proliferation of *my* code base vs somebody else's?

Honest answer is that I don't know.  You may have more real data on this one.

I'm sure this happens but I'm skeptical that it staves off 3rd party 
innovation.  It would crowd out other code but if code becomes truly free 
then although you may have supplied it, anyone else can mod it.  Then the 
question is how do your mods compete with those of others.

This just brings us back to the innovation, pricing, and adoption issues, 
which is what we're trying to manage with the copyflex style license! :)

So, thoughts and critiques are welcome.

MVA