[Cc-bizcom] Re: Comments on "Flexible Copyright Licensing - A Precis"
Marshall Van Alstyne
marshall at MIT.EDU
Fri Sep 17 15:11:19 EDT 2004
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:
>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
>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
>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 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
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
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
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
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
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.
More information about the Cc-bizcom