Subject: Re: Dwyer, FRB, Economics of Open Source
From: Frank Hecker <>
Date: Sun, 28 May 2000 22:03:18 -0400 wrote:
> My point being that Mozilla didn't proceed very far until this rewrite
> occurred, and that the rewrite itself was a significant task.

I agree on this point.

> > On the opposite side, many people have commented that the most
> > reasonable way to add a proprietary extension to an MPLed program is to
> > put your proprietary code in separate files (per MPL requirements) and
> > then to call that code from the existing MPLed files via a defined API
> > (existing or new). If you can use existing public APIs in the MPLed code
> > or have your new API be adopted into the mainstream MPLed code then you
> > can avoid the "stupid tax" of having to continually reintegrate your
> > code into future versions of the MPLed code.
> Hypothetical -- if a party could pay the "stupid tax" and were bent on
> mangling the source, it's possible that an intentionally convoluted but
> highly desirable modification could be made.  This would be a high-stakes
> and rather expensive game -- not likely to happen in the course of casual
> development, but more plausible in a standards war.

As you say, hypothetical. I guess we'll have to wait and see whether
anything like this ever happens in practice.

> > Based on this some might claim that the MPL actually promotes modular
> > design rather than the opposite. I won't make quite that strong a claim,
> > but I do think that the MPL (or any license for that matter) is not a
> > major factor in promoting poor design.
> I'd argue quite the opposite -- particularly if the license is
> proprietary.  Cf:  Varian and Shapiro [1] -- there is a strong incentive for
> a proprietary market-leader to create tangled code with undocumented
> features.

When I made my comment about "any license" I was thinking of libre
software licenses in the context of public development. I agree that
proprietary licenses and closed source development are different cases;
even apart from any incentives to deliberately create tangled code,
there are arguably fewer incentives not do so so.

Frank Hecker            work:        home: