All these licenses and business models

[Karsten M. Self]

on Fri, Jan 18, 2002 at 01:47:21PM +0000, David (dirvine at david-irvine.com) wrote:
> On Fri, 2002-01-18 at 13:43, Risto S Varanka wrote:

> > > My issues
> > > 1: I do not want to be a services only company, in fact I want to sub
> > > contract most services (maybe even zope type model).
> > > 2: I do want to be able to sell the system for a profit.
> > 
> > Then you probably don't want to give out too much freely. One risk
> > is that you could give a starting point to a vigorous open source
> > project that would become your competitor. 
> 
> That is the real problem for me.

This is a frequently cited concern.  IMO it's largely a non-issue.

First, any potential competitor faces an identical equation.  A
proprietary company may try to chase you from a market.  However a free
software competitor faces essentially the same problem:  you can
undercut their software sales price.

Your bytes are free regardless, if you're following a free software
model.  You're looking elsewhere for a differentiator.  *That* is going
to be a product or service which:

  - Has a significant marginal cost of production.
  - Favors a long-term credible relationship.

To most minds, this translates to services, hardware, or a marriage of
the two, in addition to software.  For the second time, I strongly
recommend you look at my comments to FSL regarding the Software 500
list, and the number of pure-play software companies in the first 20
companies on this list.

http://www.crynwr.com/cgi-bin/ezmlm-cgi?mss:7011:200201:aeaodelkpbnhblgbdfno

The answer is 1, its position is 2, its 2000 revenues are exeeded by
107% by the top-ranked firm.  Pure-play software is largely *not* a
viable strategy.  At median, it's an US$30m/yr company strategy (mixed
model median is $56m/yr).

> > You could consider GPL licensing for some parts of the system,
> > because then commercial competition can't take the code into their
> > closed prodocts. (Unless they break the law, which might happen...)
> > If you want others to develop and maintain some parts of the code,
> > so you save a bit on development costs, give those parts out as open
> > source. If you give out that code under LGPL, you can take all the
> > modifications and patches you get from community, and build your
> > proprietary components on top of the LGPLed parts.
> > 
> What do you think of GPL and having develoeprs sign an assignation of
> copyright statement that would allow GPL releases and also proprietary
> releases (similar to what SUN are trying with StarOffice).

There are varying opinions on this strategy.  The opinions that matter
are those of the developers (or their employers) you're dealing with.
There's a strong argument to be made for copyright assignment (it makes
certain aspects of copyright litigation more straightforward, according
to numerous legal authorities), but assymetric rights assignment raises
some hackles.


> > You could also give the code for free or for charge to other
> > companies, under an NDA or a limited license. You could include a
> > clause that allows the other party to treat the code under
> > GPL/LGPL after a specified period, like 2 years or so. (Think of
> > this as a kind of guarantee they get when they purchase your
> > product.) If the license is permissive enough, other companies
> > could use your product as part of theirs. 
> 
> I will look into the delayed public license again for this purpose. Does
> anyone know where this is.

It's a concept, not a particular license.  Peter Deutsche has described
this, IIRC on FSB.

Peace.

-- 
Karsten M. Self <kmself at ix.netcom.com>        http://kmself.home.netcom.com/
 What part of "Gestalt" don't you understand?              Home of the brave
  http://gestalt-system.sourceforge.net/                    Land of the free
We freed Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org
Geek for Hire                      http://kmself.home.netcom.com/resume.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20020119/bfa5206b/attachment.sig>