[Cc-bizcom] Re: Comments on "Flexible Copyright Licensing - A Precis"
Onno Kluyt
Onno.Kluyt at Sun.COM
Thu Sep 23 16:28:06 EDT 2004
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
More information about the Cc-bizcom
mailing list