Definition of open source

[Michael R. Bernstein]

On Sat, 2004-11-06 at 06:31, Alan Rihm wrote:
> 
> Example: Open source your software (assuming you don't want to manage a
> new fork), then try to charge for the hosted version of the same. What
> is to stop 100 other companies from doing the same. What happens if a
> company with more money and resources starts to compete? The originator
> just became a worthless entity.

I'll note that this question "How do I make money and avoid being
crushed in the marketplace if I make my software open source?" isn't
really a licensing question. (Aside: Does anyone know of a mailing list
that *does* focus on discussion of FOSS business-models?)

There are a number of solutions to this that have been mentioned on this
list before, but I'll (breifly) recapitulate them.

But first, a disclaimer: I'm not going to give you (or your customers)
business advice because we haven't entered into an consultant-client
relationship. So please don't cite this as an official business opinion,
merely as an interpretation given by a fellow entrepreneur. ;-)

In the case of a business model where you distribute software to
customers, a strong copyleft license (such as the GPL) ensures that a
competitor cannot enhance the software and distribute it without making
their enhancements available under the same license. So, you are able to
leverage their contribution in your own business and offer the same
features they do.

Note that this does not mean that they won't still have an advantage in
the marketplace due to greater resources (marketing, for example), but
at least you won't be facing *unfair* competition.

Further, you are able (as the copyright-holder on your own code) to
create proprietary derivatives of your code with additional features,
and distribute them as closed-source software (this is usually referred
to as 'dual-licensing'). Your larger competitor cannot do the same.
Note, though, that you *cannot* take your competitor's code for
enhancements and roll it into your proprietary product unless they
assign the copyright to you (which you might require, if they want their
modifications to be included in the 'official' project). In practice,
this means that you each potentially have something the other wants, and
an amicable and mutually profitable arrangement can be reached.

In the case of software-as-service, the GPL does not prevent a larger,
better funded competitor from creating proprietary enahncements to your
software and keeping the source private, because no distribution occurs.
However, there are licenses that close this 'web-app loophole', such as
the AGPL which condition reciprocity on making the application available
for use over a network (in addition to software distribution), in which
case the business model once again applies.

I hope this was somewhat useful.

-- 
Michael R. Bernstein <webmaven at cox.net>