Dan Bricklin's Web Site: www.bricklin.com
Thinking about software licensing for a small ISV and the issue of open source
A discussion of various ideas for using open source-style licensing for products from a small software developer
Introduction
After about 8 years of working in a many-person software company, eventually ending up in a large web hosting company, I'm back to running a small (basically one person) software company. Much has changed in the years since I last developed software this way. Before releasing any software, I decided to try to understand some of those changes and see how that affects how I can go about making money.

This essay is written from the perspective of wanting to have a financially successful software small business. (By financially successful, I mean that it can provide a nice income for the employees and owner, not that it must produce great wealth.) This essay is not written from the perspective of what is best for society, the users, the individual programmer, big businesses, etc. While I have feelings in those areas, I think it is important to examine things, at least for this essay, from the perspective I've chosen. There are lots of other places to read about what is best from other perspectives.

The small software firm
The type of business I'm interested in is the small software firm, probably just one or two developers. It's the type of business that developed my two most influential applications, VisiCalc and Dan Bricklin's Demo Program. I believe that such firms are an important source of innovation for the world, and should be encouraged. I also know that there are many people who like working in such an arrangement, without being part of a larger organization, and it would be a shame for that not to be available to them as a reasonable form of livelihood.

Back in the 1980s and 1990s, when I last ran Software Garden, a common business model was to write some software, protect it through copyright (so that only the author could distribute it) and as a tradesecret (distributing only executables so as to protect the source code), and sell it through the mail or stores as a "shrink-wrapped" product. Any competition probably did the same thing.

For some simple software, there was the "shareware" model, where the software could be copied freely, but if you liked it you were supposed to send in some money to "register" your copy. This has proven to be a viable business model. Enough people did send in money to fund a variety of companies. There were variations on this theme, but in general it also only involved executable programs. You couldn't modify them nor learn from them by reading the source, etc.

What I want to do
I am planning to produce a variety of relatively simple "utility" programs and sell them to see which get some traction before continuing to enhance those into more full-featured products.

The old costs to market and distribute
In the past that strategy would have a problem because of the cost to publicize, manufacture, and distribute the products. Marketing and distribution costs are very real. An ad in a magazine can cost thousands of dollars each time it runs, and you need to run it repeatedly to keep up sales. Printing manuals, duplicating diskettes and CDs, and creating packaging all cost money -- all spent in advance of any sales. A product that brought in just a few thousand dollars in sales would be a total loss. You had better be pretty sure that your application was worth the investment, and not just have the time to invest for development, but also the seed money to get marketing off the ground. "Getting traction" for various utilities, from what I've seen, can easily take from months to a year or more, and much of that time is devoted to active marketing, not creating new products.

Push, pull, traction, and the Internet
Sales can happen through "push", where you actively sell the product and find ways to reach people and let them know why they should want your product. They can also happen through "pull", where the people realize themselves that they need your product and go to you to get it. A really good situation is when the "word of mouth" recommendations of the product create enough pull to make the company self sustaining.

In terms of getting traction, software that you don't have to pay for has an advantage over software that you do. Unless the "for fee" software has a strong pull or push to recommend it, there is a tendency for many people to try the free version first and only get the more expensive version if the free version doesn't meet their needs. A variation is using a free "trial" version of a product, but an always free (to acquire) product is better.

Today, there is the Internet with search engines, there are people comfortable with downloading with access to reasonably high bandwidth connections, and more, so the costs to market and distribute can start out much lower than in the old days. The incremental expenses per product during the time while you wait to see if interest reaches a critical mass that creates strong pull can be much lower.

The new competition
There is a problem, though, for products that, while possibly innovative in their approach to a problem, are not that complicated to code. While you are waiting for traction, or soon thereafter, someone creates a similar product (after seeing yours) and gives it away as some sort of "free" (to acquire, as in "free beer") software.

Why does this happen? Often the other software is "open source" software, and the developer of that software creates it because your software is not open. This may happen for philosophical reasons (they believe in open source and want open versions of as many useful tools as possible and donate their time to that cause) or for practical reasons (they need a particular feature and can't get your source to make modifications, so write their own and release it, with the expense justified by their known benefit after using yours). With the type of simple products I'm envisioning, that might meet my needs but may be slightly off from meeting other people's needs, this is a likely scenario.

So, the problem I foresee (and that other developers worry about) is that they'll develop something only to see someone else take over that market niche.

Open source as a defensive marketing move
An alternative, of course, is to write open source to begin with and make it as likely as possible that many no-fee copies of your product will be distributed and that your product is the one that others recommend and takes over its market niche. This makes considering open source a defensive move for marketing purposes. In addition, releasing a product as a form of open source has many other marketing benefits and can lead to greater user satisfaction and wider use. The question is, of course, can you make money that way?

What is open source?
The term "open source" has been used for a variety of different licensing schemes. In almost all cases the software is protected by copyright law and the owner of those rights lets others use and distribute the software only under terms of a particular license. There are several popular licenses, and they have different effects. They have names like GPL, LGPL, Artistic license, BSD license, and Apache License. The particulars matter, especially to what we'll be discussing here.

In pretty much all cases of open source, the user of the software gets access to the source code used to create the software. Differences are in what the user can do with that source. In many cases they can make modifications to the software and use the software so modified. In some cases they can distribute the changes, in other cases they can only let the original owner know of the changes to be possibly added to the next release. In some cases the users can distribute the software (with or without changes) as they please, in others they can only distribute it under certain conditions, such as without fee and with public access to the modified source.

Some of the desirable "freedoms" for the software from the user's viewpoint include (see The Free Software Definition from GNU):

The freedom to run the program for any purpose
The freedom to study how the program works, and adapt it to your needs
The freedom to redistribute copies
The freedom to improve the program, and release your improvements to the public

Some of the restrictions that people put in their software licenses include:

Requirements to maintain the attribution to the original author(s) along with the software
Restrictions on the type of license that may cover redistribution
Restrictions on the type of licenses that may cover other software included with the software when redistributed
Restrictions on the uses of the software, such as non-commercial only

There are many arguments about the reasons why various combinations of rights and restrictions should be in a given license. While one may argue about which are "better" for society as a whole or for the company in particular, there is a choice to be made and creators of new software can make them as they please.

The question here is: What type of license will work for the type of endeavor that I am planning?

Benefits to the software author
There are various benefits to the company distributing the software that are often cited for aspects of open source that one should consider:

Having access to source lets a user adapt software better to their needs without the original author needing to be involved, saving the author those costs and resulting in satisfied users.
Improvements made by others can make the software more desirable to all, increasing distribution and "pull".
Open source gives you a world of people finding bugs and fixing them in your code.
Being freely distributable means you can be on CDROM distributions of compendiums of software thereby increasing distribution.

With the type of software I am planning to create it is not likely (from some people's experience that I've heard) that anybody will spend time finding and fixing bugs other than normal users of the product, and most of them cannot program. The benefits to bug fixing probably won't be too much more than one normally gets from a user population even in proprietary software. This is probably not the case for some other type of software, such as operating systems, but I believe it is for the utilities I plan. It should be true, though, that the increased number of users stemming from a no-fee distribution should increase the number of potential bug reporters and users with suggestions compared to a non-open source release.

It is also unclear, in today's world with easy software downloading and the ability of others to just link to Internet download sites, whether the CDROM compendium will have the importance that it does for something like a Linux distribution, especially for my target audience that includes many Windows and Mac users as well as Linux ones.

How "Open Source" brings in revenue
The term "Open Source" (with caps) sometimes refers to software whose license meets the requirements set forth by the Open Source Initiative. It includes requirements of free redistribution with no fee, allowing modifications to the source, and no discrimination in use (such as "non-commercial only"). For such licenses, how, then, does the developer get paid if no fee can be charged?

Frank Hecker lists some of the ways frequently cited in "Setting Up Shop":

"Support Sellers," in which revenue comes from media distribution, branding, training, consulting, custom development, and post-sales support instead of traditional software licensing fees
"Loss Leader," where a no-charge open-source product is used as a loss leader for traditional commercial software
"Widget Frosting," for companies that are in business primarily to sell hardware but which use the open-source model for enabling software such as driver and interface code
"Accessorizing," for companies which distribute books, computer hardware and other physical items associated with and supportive of open-source software
"Service Enabler," where open-source software is created and distributed primarily to support access to revenue-generating on-line services
"Brand Licensing," in which a company charges other companies for the right to use its brand names and trademarks in creating derivative products
"Sell It, Free It," where a company's software products start out their product life cycle as traditional commercial products and then are continually converted to open-source products when appropriate
"Software Franchising," a combination of several of the preceding models (in particular "Brand Licensing" and "Support Sellers") in which a company authorizes others to use its brand names and trademarks in creating associated organizations doing custom software development in particular geographic areas or vertical markets, and supplies franchises with training and related services in exchange for franchise fees of some sort

Some of these ways have been shown to work in the marketplace, especially the first four. Unfortunately, none of them fit the small development firm I envision. I don't want to provide support -- that will take away from the time I could be spending creating new software unless I grow the company and increase my economic exposure. I have no other products to sell that would be under a different license. Having open source funded by proprietary software does not seem right, plus how do you decide which product to use with which license? I like the idea of generally making the source available, and anyway, much of that software may be written in scripting languages like Perl that are usually shipped as source. I'm not selling any hardware, franchising my brand, etc., so those options aren't available.

More input
So, it looks like the traditional open source licenses won't work for providing ongoing revenue for my business. What should I do?

I'm trying to craft a license that gets as many appropriate benefits as possible from open source, but still brings in money to put food on the table.

I've looked at a variety of licenses and read lots of philosophical essays. Here is some more of the input:

Movable Type
The company SixApart has made the Movable Type program available under a license that provided source so you could make your own customizations, but did not allow redistribution. It didn't even allow you to install it for somebody for a fee (they reserved that for themselves). They charged no fee for non-commercial use, a fee for certain commercial use, and did not allow other commercial use (the type that might compete with services they planned).

I like the idea of identifying those who benefit financially from a product and have a business model of their own which involves income and expenses, and then having those people pay -- that is the case when charging a fee for commercial use. I don't like, though, the restriction on redistribution that keeps the product from being improved or distributed by others. As a potential licensor, at one point, the restriction on use (even if a payment was made) kept me from being able to license it. From this I learned that I like more freedom with the source, dislike the restrictions on distribution and use, but found less problem with the payment, and I like that it did provide them income and that payment was apparently acceptable to others, too.

Apache license
The Apache 1.1 license allows copying and redistribution of the source, and does not discriminate against others using the software together with commercial, proprietary software.

I have released software under a similar license, and like it (wearing the hat of the proprietary developer building on that software -- some of whom I hope will adopt my new software and make it popular). It doesn't, though, provide a way to get payment to put food on the table.

Semi-free software
Even the more ardent Free Software adherents have some good things to say about a licensing scheme that involves some payment but provides source code for learning and modification. Calling it "semi-free software", they feel it's much better ethically than proprietary software, but has problems if the semi-free software needs to be part of a Free operating system or other Free package. That is true, but in the case of my utilities, I plan to have them stand more on their own, at least at first, and some payment (as opposed to none) will offset the loss (to me) due to not being included in various packages. If the popularity of a product gets so much that other means of financial support arise (such as charging for service or selling versions with non-open source redistribution licenses like MySQL does), then switching to a more Free license may become appropriate and perhaps financially desirable.

Fairness
An issue that comes up frequently is the issue of fairness. From what I've read, in general the original creator of a program is often viewed differently than others who are exploiting that creation. The idea of having financial reward go to that person is not as "unfair" as having others downstream add a little bit and then charge a lot. Eric Raymond, a frequent commentator on open source, covers the special status of creators in various ways in his "Homesteading the Noosphere" and other essays. The structure of a small software developer is usually such that the money mainly goes to the programmer who created the original software, not some anonymous "corporation" or its executives.

From my viewpoint, someone who finds a way to increase usage of the product in a way that benefits the original creator in the same way the creator wanted is adding to the product in their own right, whether that increase comes from improved functionality or better marketing. With a goal of wide usage, marketing that increases usage is adding value. If that secondary creator makes money from doing it, fine, as along as the original creator gets what they planned from that extra usage.

Eric also makes some claims about the tendency of projects not to "fork" the source code into more than one lineage. Most people defer to the code base from the originator (or the maintainer they pass it on to) if the product is not abandoned. This would be very good for the small software developer if such a tendency would keep them the main source for upgrades to their product. How this will play out with semi-free software is something we'll need to learn.

Other details
Looking at the reaction to an early Apple open source license, it is clear that there are what may seem to be petty details that do make a philosophical and maybe even a practical difference. One example is having a licensing requirement that involves interaction with the original creator. What happens if the creator is no longer in business or doesn't respond to those required interactions? Does that block usage or distribution? This is not something a non-lawyer might think about at first, but matters when you decide to build a dependence upon a piece of software. To open source purists trying to build solid foundations on software, an issue like this could make an otherwise well-meaning attempt at a license be labeled as having "fatal flaws", though for practical purposes to most users of simple tools like I am planning, it is not a concern. One reason I'm posting this essay is to surface such problems earlier.

Making sure there is a likelihood of payment
If you are going to differentiate between different users and have different fees, you need to make sure that you understand your users. A product that has little potential commercial use is not a good candidate for fees charged only for commercial use. Likewise, one with mainly commercial use will get little distribution benefit from having non-commercial use be fee-free. Definitions of what is for fee and what is not need to be easy to understand and seem "fair".

Payment often requires cooperation from the user to help with the differentiation. There are users who would rather "cheat" if they could and find a way to avoid payment. There are those who are very careful to follow the requirements to the letter and will pay even if cheating is easier. And, finally, there are those who probably don't mind paying, but may need a little prodding. You must make sure that all concerned know the particulars of the restrictions, so that those that should pay do. It would be a loss if those that would gladly pay didn't know that they should. You can have undesirable technological restrictions, such as copy protection or access keys, that make cheating hard and prod the fence sitters. For open source with easily modifiable code, this is not a practical solution. The proportions of the users that fall into the three categories can be very important to the financial success of the product. If there are many fence sitters, then how you prod them can affect the revenues, but it also affects the use. Too little reminder and there will be less revenue. Too much nagging, and the product in general will be disliked.

An attempt at a useful license
With all this input, I'm now trying to create an appropriate license to try. Here is the first attempt. It consists of two parts, a Software License, and a companion Commercial License. These do not have a full complement of legal stuff to cover every contingency. I wrote these and "I am not a lawyer".

First is the Software License. It is inspired by the Apache 1.1 license.

SOFTWARE GARDEN SOFTWARE LICENSE

This software is Copyright (c) Software Garden, Inc. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. This software may not be used for Commercial Purposes nor Distributed Commercially unless the terms of the companion Commercial License are met. The details of such license for this software, which includes payment requirements and the definitions of the terms "Commercial Purposes" and "Distributed Commercially", may be found on the Software Garden website, http://www.softwaregarden.com, or may be obtained from the postal address below.

2. Redistributions in source code must retain the above copyright notice, this list of conditions, and the following disclaimer.

3. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution.

4. The end-user documentation included with the redistribution, if any, must include the following acknowledgment:

"This product includes software developed by Software Garden, Inc. (http://www.softwaregarden.com)."

Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear.

5. The names Software Garden, Inc., and Dan Bricklin must not be used to endorse or promote products derived from this software without prior written permission from Software Garden, Inc., or Dan Bricklin, respectively.

6. The right to distribute this software or to use it for any purpose does not give you the right to use Servicemarks or Trademarks of Software Garden, Inc. or Dan Bricklin.

7. If any files are modified, you must cause the modified files to carry prominent notices stating that you changed the files and the date and nature of any change.

Disclaimer

THIS SOFTWARE IS PROVIDED BY SOFTWARE GARDEN, INC., "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF INFRINGEMENT AND THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL SOFTWARE GARDEN, INC. OR DAN BRICKLIN BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE DISTRIBUTION OR USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Software Garden, Inc., and Dan Bricklin do not condone the use of this software for unlawful, malicious, harassing, disruptive, or abusive purposes.

Additional Software

In some cases this software is distributed with additional software copyright by others for the purpose of installation and execution. The above license for redistribution and modification does not apply to such additional software.

License version: 1.90/2004-04-25

Software Garden, Inc.
PO Box 610369
Newton Highlands, MA 02461 USA
www.softwaregarden.com

The companion Commercial License
Next is the companion Commercial License. It sets forth the definitions of Commercial Use and tells you when and how to make payment.

It adds the concept of "Commercial Distribution". This is when the software is resold by others, or used as part of a service for which payment is received. The license attempts to make this activity trigger normal commercial use payments on each "sale" or use for pay. The desired affect is to allow others to resell the product for whatever they want, and still have the original author receive revenue as if the ultimate user had bought the original. The reseller may have improved the product, and charged more than the original, but that extra is theirs. It also allows others to improve their services through use of the product on behalf of customers without the original author feeling that they have lost a sale.

SOFTWARE GARDEN COMMERCIAL LICENSE COMPANION TO THE SOFTWARE LICENSE

Software licensed by Software Garden, Inc., that states that it may not be used for Commercial Purposes nor Distributed Commercially unless the terms of the companion Commercial License are met (the "Software") is subject to the following additional license requirements for use or distribution:

Definitions

"Commercial Purposes" means you are a business with annual sales or revenues greater than $25,000 and use the software as part of that endeavor. (A "business" files business tax returns, including the personal Schedule C, or should if it was in the USA.) Non-profit educational institutions are not considered businesses for this license, nor are U.S. 501(c)(3) tax exempt organizations. Use for training purposes in an educational setting within any business is not considered use for Commercial Purposes.

"Distributed Commercially" means a charge is made for the distribution, installation, training, etc., of the Software or the Software is used as part of a service or product for which payment is made or required.

Requirements

Payment of a License Fee to Software Garden, Inc., is required if the Software is used for Commercial Purposes. The current amount of the License Fee and method of payment is listed on the Software Garden, Inc., website, http://www.softwaregarden.com, or may be obtained from the postal address below.

Before payment of the License Fee, the Software may be used for Commercial Purposes during a single 30-day Evaluation Period in order to determine whether or not the Software meets the intended needs and performs satisfactorily. After that Evaluation Period, a License Fee must be paid or else use of the Software must cease.

Multiple copies of the Software require one License Fee for each simultaneous user of the Software, but no more than one License Fee per person who uses it (i.e., a single individual may run multiple simultaneous copies on multiple computers on behalf of a single company while paying only one License Fee, but if five users each are using it at the same time five License Fees must have been paid).

All use of the Software that is Distributed Commercially is considered use for Commercial Purposes, even if such use would not be considered commercial otherwise (e.g., use by an educational institution, or personal use). Also, in such case, the 30-day Evaluation Period does not apply. The responsibility for making sure that payment is made to Software Garden, Inc., rests with the distributor.

In the event that Software Garden, Inc., has ceased to exist, has officially released users of this Software from this Commercial License requirement through public notice, or is unresponsive to reasonable attempts to be paid, then these Commercial License requirements are waived.

License version: 0.9/2004-04-25

Software Garden, Inc.
PO Box 610369
Newton Highlands, MA 02461 USA
www.softwaregarden.com

Next steps
I realize that there are readers who know more about each aspect of this area than I do, so I am looking for some feedback (especially based on real world experiences), and then will settle on the license to use for my first, simple product. Then I'll see how it goes. Send comments to "license" at bricklin.com. Make sure that the comments relate to the needs of the small independent developer.

-Dan Bricklin, 25 April 2004
© Copyright 1999-2018 by Daniel Bricklin
All Rights Reserved.