Delta Competition (see http://distributedcopyright.org ) By Clark C. Evans

When software evolves from innovation to widespread acceptance, it should be owned by those who have invested in and have come to rely upon it. It should not be owned by its original creator.

Why? In emerging markets, software competition is largely based upon each product's qualifications. However, in an established market, these qualifications become less important as the complementary products and services become the primary factor in a purchase decision. This leads to a loss in price elasticity for the established software product, which, coupled with a negligible marginal cost, creates highly concentrated markets and monopolies.

One alternative presented thus far, free software, asserts that copyright law is broken and that software should not have owners. Although this business model may be sufficient to prevent future monopolies, I do not believe that it is necessary to discard copyright law (and with it developer compensation) just because it is being applied in an unfair manner.

To help find a balance, let us compare a software program to a home. Since it is the occupant who will desire improvements and require the freedom to make changes to their liking, a house will be better enjoyed if it is owned by the people who live in it, rather than the architect who designed it or the builder who laid the bricks. Therefore, we seek a method that, while still amply compensating the developer, will allow for the gradual transfer of ownership to the user community. I propose something similar to a land contract, where a developer offers a new home to a buyer with both a total price and an installment amount. The buyer makes periodic installments until the total price is reached, whereupon the buyer has full control over the purchased property.

In this model, we start with a product ready to be brought to market. The product is offered with an installment amount and a total community price. When a new user licenses a copy of the software for the installment amount, they also acquire a share of the software's ownership. The model proceeds as people and organizations join the user community, buying up the shares of ownership. If the product is popular, the sum of the installments will soon surpass the total community price, and the initial creator is paid off. At this point, the community could continue to charge additional users with a reduced installment where money collected goes to rebate those members who have made prior installments, distributing the total community price evenly across every user. Eventually, the average price will become negligible compared to the administrative overhead, and the software is put in the public domain.

For illustration, assume a program is offered for a $100 installment amount with a $100,000 community price. After 1,000 users have bought into the user community, the original developer is paid off, and the community of users wholly owns the program. At this point, assume 1,000 additional users license the product. At the end of the fiscal year, the average investment amount would be calculated, in this case, $100,000 for 2,000 users, which is $50 per user. The wholesale price of the program on the market could then be dropped to $50, and a rebate of $50 issued to those first year users. If, in the second year, the product became even more popular, attracting a total of 10,000 users, then the average user investment would drop to $10. This may be low enough so that the software becomes public domain and a final rebate of $40 is issued to all users.

For composite products, such as integrated software, programs built using libraries, office suites, and other bundles, the above pattern is applied as expected. The composite's installment amount and community price is the sum of of the installment amount and community price of its components. For example, assume an office suite is composed of a word processor, spread sheet, and drawing program. Also assume that the community price and installment amount of these components are $150K/$50, $200K/$75, and $50K/$125 respectively, then the community price and installment amount for the suite is $400K/$250. A composite is then just a packaging convenience, not a separate identity. Thus, if the spreadsheet became very popular, so much so that the developer were paid off, then buyers who have purchased the composite product would receive a rebate as if they had purchased the spread sheet separately. But wait, are not suites usually cheaper? Yes, they can be. The above example assumed that the packages were completely distinct, this is usually not the case. Suppose, that the word processor and the spreadsheet shared a spell checking library for $50K/$25, and all of them shared a graphic library for $20K/$10. In this case, the composite product would be less, instead of $400K/$250, it would be $310K/$205. Thus, the community price of a composite becomes an over-estimate of the actual price to be paid by the composite's user community, since individual purchases or other products using the same libraries would also be taken into account.

Upgrades work in a similar way. Instead of thinking that an upgrade is a new product, think of it as derived product, more specifically, as the a composite of the original product with its changes. These changes are often submitted in a series of 'patches', I call a set of patches which convert one stable product to another stable product a delta product. An upgrade is then a derived product which is managed financially as a composite of the original product with the delta product. In this model, competition occurs not for the product, but for these delta products.

In the current system, when faced with an upgrade, users are at the mercy of what and when the original software developer provides. With this system, since the community of users owns the product, upgrades (as delta products) are responsive to the community's needs. Any developer can propose an upgrade, the community will decide which path it prefers, by granting the derivative work a version of the the trademark. In most cases, if the incumbent has presented a fair upgrade, the user community will grant the trademark, however, if the proposed upgrade is not reasonable, then the user community has the option to move on to another steward in the marketplace. This is possible since the source code is published and anyone can build upon it. Code sharing also allows for increased modulization, easier entrance into specialized markets, tighter compliance with open standards, and also facilitates product convergence. In this way, not only is there competition for the improvement of established programs, there is also competition for specially tailored derivative works. Thus, it can be said that this model achieves delta competition, or competition for the changes in a product.

In conclusion, let us contrast this model with the current model of proprietary licensing. Suppose that a corporate buyer has the choice between a product with a $500 installment amount and a reasonable community price, or an alternative product which is available only through a $50 proprietary license. If the buyer, after consulting the trade magazines, decides to choose the $500 installment amount, they may receive in a few short months a rebate for $490 as the product becomes popular. Moreover, the corporate buyer now has several software organizations competing for upgrades, ensuring the best evolution of the product. In the current situation, the corporate buyer not only pays the $50 rent, but lets the original developer keep ownership. By doing this, the purchaser has moved themselves from a free product market into a monopolistic upgrade market, allowing the original developer to increase the price for the next round, extracting extraordinary rent from value primarily provided by the product's complementary market.

Certainly, as you add patents, trademarks, legal issues, thousands of products, large pricing aggregations resulting from upgrades, etc., the model gets far more complex. However, I think the the result here could very well be a balanced environment where the software organization is adequately compensated for their work and the user community owns the software products and standards they become dependent on. This opens the channel for not only complementary services, but also for differentiated upgrade paths, since the original creator must compete on equal footing for future changes. The result is much like a home owner freely contracting for additions and repairs, rather than the renter's choice to move out or put up.

I named the model Distributed Copyright, since the central idea is to distribute the ownership of the software from the creator to the user community. I use a scale as a logo to represent a balance between the creators and the users of software. I titled the paper delta competition since the economic argument centers around making the software market competitive by moving the focus from product competition, to competition for the changes in a product. Your comments are more than welcome. Please visit http://distributedcopyright.org

Clark Evans ([email protected]) 2-MAY-99

This is definately a work in progress, and your help in developing and refining the model would be great. First, I'd like to thank Richard Stallman and Eric Raymond for starting the free software movement. It must be said that Richard disagrees with the direction of this proposal, and encourages people to stick with Free software.

Richard's GNU Manifesto is wonderful and provided the basis of this essay, his focus on freedom should not be discarded as idealistic, since any free market depends upon the freedom with which he speaks so clearly. Especially interesting in his Manifesto is his discussion of Government funding for software, although this is where we disagree, it is this section which gave me the mission: Make a system that keeps the freedom with which he speaks, but allows for free market competition, the heart of capitalism.

Besides these two individuals, I must give thanks to the entire open-source community. I've been in hundreds of licensing discussions, especially in the JOS community and the JavaLobby community. Most of the ideas in this paper are a synthesis of these discussions, without them, I would have spun into philosophical recursion.

I'd also like to thank ACM for letting me participate in the Reflections-Projection's panel. Although I'm not very well known, the opportunity was wonderful. I especially enjoyed the chance to talk with Bjarne Stroustrup, my childhood idol. He explained to me very clearly that committees approve standards, and that they don't do a very good job of creating them. He also explained how trademark's are used to mark a standard. Hence, the necessity for the community of users to also own the trademark, so that it can be used to mark the standard path.

Also to the NSF, by providing me the freedom to think without a daily job over my head. To Prasanth Nair, for our long discussions and his insight into the business man's mind. I'm not that great of a writer and can loose confidence easily, without my friends Mark, Janet, and especially Claudia, this paper wouldn't have made it out of the starting gates.

Finally, I'd like to thank Dan Palanza, who asked me the key question: "So, how much does Windows cost the community?" The community perspective is elusive, especially in our individualistic world, yet it is exactly that "Other side of your reasoning" that allows for such a simple solution to a seemingly impossible problem.

Just because the copyright law is broken (life+50=forever) doesn't mean that its underlying phlisophy is. In fact, distributed copyright adds the community price to the competitive equation, this price becomes the limit mentioned in the constitution. Rather than dictate the limit, as legislatures do, I feel, like any good capitalist, that its determination should be subject to competition. I also believe that the source code must be available immediately upon publication so that we have competition for the change in the software as well, thus 'open-source', but not for 'gratis'. Some legaleaze may be needed to obtain the source code, but I'm sure we can find a reasonable balance.

Intellectual competition = competition for change. If those changes introduce products, then the concept reduces to the familiar product competition. However, we can also have competition for the change in a product. And this makes all the difference.

Many of the hybrid licenses that I have seen are pretty bad. They do not gaurentee freedom to change the software, which is essential to any solution. Some of them have a dual proprietary / free aspect where it is free for some uses, but proprietary for others. Others have proprietary 'advanced' versions. These solutions, although novel, are not workable, in fact, they do open source and free software disservice, they attempt to attach proprietary software onto the free software bandwagon. Candy coated parasites anyone?

This model is not just a license, but an ownership transfer mechanism from the creators to the user community. It is this way because it is the users who are the stake holders, and therefore, should be the owners. As for developers, this license may very well offer better economic return on investment, and as long as your upgrades are competitive (or you have no competition), then you will have no problem maintaining your product's name.

No. Realistic. The idea of an infinite profit is idealistic.

It is the complementary market which makes a software program successful, and that market is not of the developer's creation. The idea of extracting rent on something which one does not create is not only idealistic, but wrong.

Even so, if you are not an extremely large player in the market and if your software product is really good, in the current proprietary market, you will eventually have two options: (a) sell out to what a large player thinks your software is worth, or (b) get demolished as the FUD brings the value of your product to $0. I wouldn't call this 'unlimited'.

The community price is the asking price for your product, if you ask too high, then your competitors may under bid you. If you ask too low, then you may not make a good profit. Sounds familiar hunh? Kinda like a competitive market?

It's really just one, the community price. However, until the software is sold to the people who use it, you can't address its community. Thus, you have a chicken and egg problem. So, to overcome the problem, the creator offers his product in chunks, which I call 'installment amounts'.

After the product is announced with its community price and installment amount, the total price could certainly be dropped at any time. The installment amount could be dropped with the current user base receiving the appropriate rebate before additional compensation flowed to the seller.

As for raising the amounts, I suppose this could be possible, but it would require 100% "YES" by all members who have joined the user community. I doubt that this could happen in practice.

Certainly non-profit or educational pricing plan could be figured into the model, since those environments are substantially different from the free market environment. Furthermore, a 'professional' version of the product (with additional features) could be sold for a different price, since it is a different product. However, most other types of differentiation are strictly forbidden in this model. This kind of price differentiation is usually called price discrimination, it is a monopolistic practice. The goal of Distributed Copyright is to restore competition to the software market, not assist monopolies.

Easy. It is now becoming standard practice to sell support and manuals separate from the shrink-wrap package. Microsoft and other industry leaders may include simple installation support, but they often charge per incident for anything substantial. Red Hat, for instance, supplies technical support for products that are open-source or free. In any case, I feel this is a separable issue, and can be handled in current conventional ways. There is nothing saying that Zac Development could not offer installation and support contracts bound up in a pretty package sold side-by-side with the shrink-wrapped product. Alternatively, the user may want to get technical support from someone other than the original developer, perhaps one who assembles the computer and gets all of the software working together on a particular piece of hardware. In any case, technical support is a service sold in addition to the software program.

Marketing expenses would have to be figured into the asking price like any other expense, much like a housing developer will include all of the related expenses to build the house in the price of the house.

The trademark used to market the product, not the trademark by which the developer goes by. Thus, "Quicken" is the trademark that would be part of the sale, "Intuit" would be retained, since it identifies the development organization and not the product.

In addition to the copyright and trademark, any other patents or contractual rights needed to freely build upon the work would be required.

The goal of the model is to provide a point where the developer is 'paid off' for their product, and it goes into the public domain. Assuming that the software product is shrink-wrap and sold in a store, there may be users who buy the product after the developer is paid off. There are several options here, and rebate to all users seemed the most likely. Alternatively, the money could be given right back to the 'lucky' winner who bought the first free copy, or the money could be donated to charity, etc. I guess one could also have the price dynamically looked up, but this seems like it would be a computational nightmare, so the yearly rebate seems the most reasonable, computational simple way to handle the situation.

If the rebate scenerio is taken further, the question then happens, what happens at year end, do you reduce the price of the product, or make the product free... at this point, the question of fairness happens, would you buy the product in December if it might be free in January? I woudn't, so I figured having the rebate thing go for a while woudn't hurt things too much, in fact, it may help to refund those early birds who had a higher risk.

Eventually, I assume there will be a 'freedom level' , either arbitrarly set, or reached by a time period, or perhaps more likely when the collection/distribution costs outweigh the benifits. At this time, the software would be put into the public domain, or a GPL license (if it was modified to be compatible).

Like open source, fragmentation rarely occurs, and then only for good reason. In this model, the user community holds the trademark, thus, it acts as a standards body, blessing the next version.

I see this model being more like open source, only with compensation as an additional element. As such, great architects like Larry Wall or Linus, will emerge, and competition won't be so much between the architects as it will be for hacker's attention of the architect. By default, the user community would grant the trademark to what ever upgrade that the current architect, or 'steward' provides. However, if the architect starts doing a poor job, wants to retire, or any other way should be replaced, the user community has the power to grant the trademark to products created by another competing architect.

If there was competition between development organizations or architects, then trade magazines could provide detailed reviews for each potential upgrade and every user would then be in the familiar situation of picking the products which best fit their needs and wants. In the ideal situation, the competition will not only be at the user level, but will be at the programmer level, where product architects pick and choose the best modules and alterations from the market as they assemble their entry for the trade magazine lineup. Some of the changes may even be contributed for free, much like the world of open-source software works. In any case, the new version will be chosen by competition, and not by a monopolistic dictatorship.

Trademark ownership is one of the frequently overlooked items in open source, and often the trademark is more valuable than the source code...

This is an exceptional, albeit necessary case to handle in the model. I define an architect as one who assembles the product and makes all final product decisions. Each software product would have a registered architect (or steward if you will). By default, the current steward would be granted the right to the trademark for the next version, much like it is in open source today aka Larry Wall or Linus Torvalds. In the open source spirit, competition mainly occurs for the attention of the architect who shapes the product, not competition between architects.

To get back to your question, let us assume that everyone gets a license number. If they do not register the product (via e-mail or http), then there is not much more we can do. When they register, they can choose a "representative" from a list of people who have agreed to vote on every issue according to a published policy, thus, we could have representatives for "small business", "education", etc. There is much to work out here.

Then, assume that a challenger registers an official contest. At this point, the user community would have a period of time, say 4 weeks, to decide if the challenger should take over the trademark. After a week or so, most trade magazines (slashdot, etc.) would publish the challenge if it was serious. At the two week mark, all representatives must have cast their votes. If a representative made a serious diversion from previous voting history, I am sure the trade mags would pick up on this and make it well known. Then, in the last two weeks, individual users can vote. They can do this by casting their vote directly, changing representatives, or by doing nothing -- thus affirming the vote of their chosen representative. In this way, if people are busy, they don't have to monitor every vote -- they pick a representative, and when the representative deviates in a large degree from their chosen vote, then user action would have to happen. In any case, to make a change, a majority of the votes, cast directly or indirectly, would have to be for the challenger for the change to be official.

Privacy is an important concern. I am not positive about the implications in this area, although I'm sure that they are not as bad as what Microsoft wants to do... require full registration (with name, address, telephone number, etc.) for a license to be valid.

In this case, there are three reasons to maintain ownership information: (a) for use in trademark voting, (b) for rebate distribution, (c) for composite pricing adjustments.

First, to benefit by any of the above items, the user would have to register, this can be as simple as a made up identifier and a password. An optional e-mail address would be available for 'push' notifications, however, no rights would be lost for those not providing e-mail. Any other information would be strictly optional, since the user could pull information from the administrative system instead of having the system push information to the user. Perhaps PGP could be used in some novel way to help protect the owner?

Second, when a product share is registered, the record of its ownership would have to be attached to one of these identifiers.

To participate in trademark voting, the user would have to choose a representative and/or vote directly on issues using their identifier. Votes would be anonymous for those people who are not representatives.

To receive a rebate distribution, the user would ask for a check to be sent out and/or a credit on a visa or bank account. Alternatively, the system may allow the balance to be used as a "discount" against future purchases. Records would most likely have to be kept verifying who and how the money was distributed. I'm not sure about what legally needs to happen with these records.

If someone is very insecure about the privacy problem created, they could register their products for the benefit of a charity, where the charitable organization would then benefit from the rebates and would have the voting power. Somehow these 'transfers' would have to be marked and the physical paper share would then be non-registerable, but would still retain the licenseure for usage.

In order to benefit from composite pricing adjustments, things must go one step further. Each individual user must have a separate identifier, since each software share is given on a per-user basis. If a user purchases a word processor and a spreadsheet separately, and if both of these products use a shared library, then the user would have purchased the right to use the library twice. If composite pricing adjustments were brought into the model, then this situation would have to be detected, so that the user could be reimbursed for the over billing. Once again, an individual could donate the benefit to a non-profit organization, perhaps one that helped to build software.

Privacy is a large concern, if it is found overwhelmingly to be a problem, then the charity donation method could become the primary method of doing things, where all rebates would go to a grant giving organization, and all voting power could be donated to various software advocacy groups.

An important benefit of this system is that it allows for product convergence, eliminating the current phenomena of a 'dead' product. Assume that two word processors have emerged, each with very different characteristics. Also, assume that at least one of them is very popular so that it's average investment is negligible. Then, the essential characteristics of the 'industry standard' word processor could be easily included in the not-so-standard word processor, until, eventually, the users of the not-so-standard word processor would be completely compatible with the industry standard. Thus, the convergence could be done over several versions, so that the users of not-so-standard word processor aren't left stranded.

There is nothing saying that 'nice' open source licenses couldn't be used as building blocks for distributed copyright software. It'd would be a bit tricky though, since any modification would have to also carry the license, and instead of entering the public domain, the code would have to be returned to the license.

If things went really well, perhaps Richard Stallman would help bullet-proof this license so that it could be the CGPL, or 'commercial GPL'. Where GPL code could be used within this model, adding a 'freedom' level for each piece of code where upon it would be returned to the GPL license. This would then remove the GPL or not to GPL debate, since commercial products could be build on top of GPL as long as they followed this model. Frankly, I'm more for this option, and would love to hear what Stallman has to say. I really feel that I've tried to make software in this model 'free'.

Assume that a special interest group, say attorneys, have specific needs in their word processor that the average citizen does not. A smart architect could use the industry-standard word processor as a starting place, and specializing it for attorneys. This developer would then offer upgrades closely following the upgrades to industry-standard word processor. In this case, an attorney would be not only a member of the standard word processor community, but also a member of the specialized community. Call it product inheritance if you will.

The Artistic license doesn't play nicely like the GPL. Also, it (like the GPL) doesn't address the serious concern of trademark management. A trademark names a standard, and having the standard owned by a single person (Linus or Larry) is a serious long-term problem. It may be fine now because they are both reasonable and benevolent dictators, but it is still a dictatorship -- and thus is prone to abuse if they have a change of heart, retire, pass away, or in some other way give control to another soul, who may not be as benevolent.

This is why the trademark is considered part of the software product in this model, thus it must be distributed as well. The user community has a vested interest in letting people like Larry and Linus "use" the trademark as long as they do it in the best interest of the user community, however, these people should not "own" the trademark, as it should be owned by the community of users who have invested in and have become dependent upon the standard.

This license is very close to just being "public domain", with the authors and/or funding institution being named as the creator of the software. If the community price is $0, then this license should be compatible with the DC model, since the DC model is also concerned with credit recognition -- the central focus of these types of licenses. I'm not sure about how this would work, the user is receiving 'compensation' in the form of name recognition. In any case, the administration of this type of software should be low since money is not involved.

Before the first user pays an installment amount. Thus, the code could be kept private until it was published -- by sale.

First, a few factors would help out immensely:

#1) The development community. Currently, in open source software projects form developer communities which protect these kinds of rights with social norms. I would expect the same pattern to occur here.

#2) If the offender copied the code into proprietary software, we are left with the same problem as GPL enforcement, however, it is shown that projects with open source code move many magnitudes faster, thus the proprietary product would have a hard time keeping up in the marketplace. And, if it did keep up, and it could be shown that infringment had occured, then legal action would be forthcoming.

#3) The limited ability of "architects" to be able to "screen" valid contributors. Each contributor may in fact have to give away source code for 'free' until he/she proved themselves to the community developing the source code. In a development community, those not proven will be suspect and examined more closely, those that have proven themselves have too much too loose by cheating. :)

As far as legal teeth, you could add a real life document to be signed for developers to agree in order to have access to any source. Thoughts?

In general, I don't see the bulk of the programming community as cheats. It's just the 1% that gives us a bad name, and I feel with the source easily available they will show up very clearly.

Software is inheritanly modular, thus I would think that products in this model would quickly become large composites, with many many authors. Thus, no single developer or development organization would be in the position to administer this, so a independent neutral third party would have to deal at arms length to administer the contract.

For each developer, the organization could sum all of the installments made, and deliver a royalty to the contributors. For each user, the organization could pool all of the refunds together from many products, thus many $5 refunds could quickly total several hundred dollars. This is a significant challenge, but I believe it is can be solved.

It will be a registry of deeds, as such, it would have to be a trans-national, non-profit, non-governmental organization. Thus, it would have to have democratic elections, terms, and all of that sort of governmental stuff. Not much more detail is known beyond this, your ideas and help would be great!

First, let's remember the rebate process. Let's say Zac Development offers a new software program, Logo-Right, for a $100 installment amount with a $100,000 community price. After 1,000 users have bought into the user community, Zac Development is paid off, and the community of users wholly owns the program. Then, assume 1,000 additional users join. At the end of the fiscal year, the average investment amount would be calculated, in this case, $100,000 for 2,000 users, which is $50 per user. The price of the Logo-Right program on the market could then be dropped to $50, and a rebate of $50 issued to those first year users. If the program became horribly popular, attracting a total of 10,000 users in the following year, then the installment could be reduced further to $10 per user, and an additional rebate for $40 issued.

When the developer offers up for sale a software product, they include not only the copyright but also any patent rights and trademarks needed to advertise and use the product. Certainly, this will increase the community price, but, owning the copyright does little good if the name recognition is not included, or separate patent licenses are required for use of the product. As part of the sale agreement, the souce code is made freely available for anyone to build upon, but the usage of any derived product must include the compensation to the original product.

With a good software product, it is plausible to consider developers who would gladly agree not to compete with the current version, if they can download the source code and begin to prepare tutorials, books, manuals, modules, add-ins, feature patches, upgrades, or other complementary products and services. The second generation of the product would then be a fight for the best derived products available in the marketplace. Trade magazines could provide detailed reviews for each potential upgrade and every user would then be in the familiar situation of picking the products which best fit their needs and wants. In the ideal situation, the competition will not only be at the user level, but will be at the programmer level, where product architects pick and choose the best alterations from the market as they assemble their entry for the trade magazine lineup. Some of the changes may even be contributed for free, much like the world of open-source software works. In any case, the new version will be chosen by competition, and not by a monopolistic dictatorship.

In some of these upgrade situations, the original product's user community may have a vested interest in a single upgrade path, may feel that the market is fragmenting too much. At this point, the community may decide to bless a particular derived product with the trademark of the original product. In most cases, if the original product's developer has presented a fair package for an upgrade, then they will be chosen, however, as soon as the original's developer fails to offer a decent upgrade, then the user community has the option to move on, giving the brand name to the product's successor.

For those products defeated by the market mechanism, the author may lick their wounds by making sure that the best parts of their product are re-packaged in a modular way so that a winner or upcoming challenger may incorporate their changes. This should serve to increase the modularity of software by bringing the economic motivation to do so. Venture capitalist who fund derived products could then liquidate a failed challenge by selling off the modules created. In the model, a bit of forethought is required to make sure that the product is issued to the market as a composite of modules, instead of a hudge bundled single price product.

Anyway, let's continue this example. After a year passes, and Logo-Right becomes horribly popular, upgrade season comes along. Zac Development present a minor upgrade with a few small features. A single developer, Roshell Black, presents an upgrade that adds a LogoPlot module. Another organization of developers, Alice and Bros., surprises the industry with a completely new interface, integrated word processor, and other very nice features. With the announcement of the competition, Roshell publishes an installment amount and community price she would like for her module. Alice and Bros., seeing the opportunity to add plotting to their feature list, sign the standard non-competition and non-disclosure agreement, and quickly integrate Roshell's changes into their Logo Challenger. Then for the ensuing battle, Alice announces their installment amount and community price. After a few short weeks, the reviews are out, and Alice's product is the clear leader: a better product, great price, clear upgrade path, even backwards file compatibility! After a majority of the early adopters from the Logo-Right 1.0 user community upgrade to Alice's derived product, the user community may blesses Alice's derived product as Logo-Right version 2.0, however, this blessing is more of an after-the-fact record of the market's choice and it serves to mark the standard.

For this to work, each new derived product would create it's own user community. Membership in the derived community would require membership in the original community, but not vice versa. Thus, a user would upgrade by picking a derived product and paying the appropriate installment to join that derived product's community. For new users, two installments must be paid, one for the original's community and one for the derived product's community. This complexity can be managed to maintain simplicity for the new user. It becomes apparent that it is important for old communities to eventually dissolve, perhaps with a time limit or when a particular average investment is reached, so that the composition hierarchy does not become too unmanageable. This is also consistent with the constitutional philosophy that a copyright should only be granted for a limited time.

To continue with this example, suppose the upgrade from Logo-Right 1.0 to Logo-Right 2.0 is offered by Alice is for a $50,000 community price, and a $50 installment amount. Let us assume that there are currently 2,000 users, so that the installment amount for Logo-Right 1.0 is $50. Upgrade users would have to pay $50 installment to join the Logo-Right 2.0 community. New users would have to pay $100 for Logo-Right 2.0, since they have to make two installments, one for the Logo-Right 1.0 community, and another for the Logo-Right 2.0 community.

This is a simple upgrade, the upgrades that could become more popular may be much more fractal in nature, where a well known 'architect' such as Larry Wall or Linus Torvalds, take control of a software product and the user community continually blesses the architect's upgrade decisions. As before, as soon as the architect starts to do a poor job of assimilating a decent derived product at a reasonable price, some other soul will be happy to step up and assume the trademark. If the state of open source has anything to show, this fractal (and more realistic) version of the model would be much more stable than the above, highly contrived example. I would assume that cultural norms would arise, as they have in open source software where an architect would name his/her successor. The assignment by the user community of the trademark at that point being a necessary formality.

(c) 1999 Clark Evans, Reproduction in whole or part is granted without fee, provided the source is clearly marked and, where appropriate, this copyright maintained.