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: Onno Kluyt <Onno.Kluyt AT Sun.COM>(by way of 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: Thu, 23 Sep 2004 16:28:06 -0400

Couple of follow-ons inserted in the text below.

Onno.

On Sep 16, 2004, at 2:30 PM, Marshall Van Alstyne wrote:
[snip]

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



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




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? :)
Sure, this is a known issue.


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



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

I think my point also was that technologies or features go through an other kind of value appreciation as well:
from differentiating feature to common to check-off item to a commodity.
With the example of TCP/IP, there is no economic value anymore to try to compete on tcp/ip implementations. The companies that had tcp/ip products either found other lines of business or are indeed now out of business.


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:
I had to re-read my email to understand myself. I believe I meant the first interpretation :-)


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.
Thank you. Great explanation. I like the last sentence especially.



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.
Thanks, this helps.


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.
Yeah, what I guess I meant was that source code is a very valuable good in many ways. One of the motivations to make one's source code available under an oss license is to aim for the center of the universe position. The motivation isn't necessarily the enabling of innovation by others, it is to maximize the number of developers that gravitate around you. This is seen to lead to several competitive and commercial benefits:
- opportunities to sell tools, training and other services to that crowd.
- being perceived as thought leader, as innovator, which may lead to improved sales opportunities for the companies other products, services.


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.
I wasn't thinking so much of "my modifications are better than yours" but more "my system is better than yours" (eg Eclipse vs Netbeans; Apache Geronimo vs JBoss)
In the case of Eclipse (probably the same would go for Netbeans) an important part of the play is the grab for developers. How many open source IDEs can the available developer pool bear? Assuming that the answer is "not that many" then you could come to the conclusion that after first Netbeans and then Eclipse there's less ROI for Oracle or Borland in open sourcing their IDEs.

Now that I wrote this down I'm thinking that this is a little off-topic from the copyflex license...


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! :)
Exactly!


So, thoughts and critiques are welcome.

MVA






Archive powered by MHonArc 2.6.24.

Top of Page