Project Browser vs App Browser (was "script scope variables inexplicably becoming unset")

[Dr. Hawkins]

On Sat, Jan 3, 2015 at 6:04 PM, Peter Haworth <pete at lcsql.com> wrote:

> Nothing I can do about the latter but any help in finding a dual license
> template would be most welcome.  Plus, how can I ensure people agree to the
> license terms since they can easily disable whatever code I put in there to
> display it?  Or maybe that's too paranoid?
>

I'm not sure it's something for which dual licensing makes sense.

Your product basically "does something." and then it is done.  People pay
for getting that something done.

LiveCode, as an example, sticks around with the finished product--by using
a viral license on the community version, the license attaches to the
finished code, which itself must remain under that license.

Livecode hopes to keep its commercial market, and get more overall
exposure, leading to more commercial market.  It also hopes to get back
changes/fixes/improvements that can also go into the commercial code.

But the economic key is that the community version cannot substitute for
the commercial.

With a tool or utility that does not necessarily become part of the end
program, I don't see the benefit to you.  For that matter, what would you
be offering in the commercial version other than support and hanging around
to write more useful things?

Your SQL tools, though, *would* make it into the commercial product.  As
such, a commercial license would be needed to legally ship.


Anyway, there are two broad classes of license:  public and viral. Public
licenses pretty much let people do whatever with the code, including
closing it back up, as long as the copyright is acknowledged.  Viral
licenses, such as the GPL, attach themselves to any changes in the code,
keeping the changes open-sourced (at least if the changes are passed on to
any third party).

Public licenses (MIT/BSD/X etc.) make no sense if you're trying to sell the
product.  They make sense when you need the *existence* of the
product--Apple & Darwin, IBM & Apache, and so forth.  It cost less for IBM
to fund/contribute to a webserver than to keep its own.  Similarly for its
support of Linux.  But IBM's product isn't "webserver software" but "served
pages".  The price it can charge doesn't change based upon the underlying
server, and it wouldn't be harmed by Sun repackaging Apache as "Navajo" and
selling it at a price.

Dual licenses are useful when you are going to sell an enhanced version
(StarOffice/OpenOffice) and can get market share/traction/code back.  The
other big example is Netscape/Mozilla.  Both illustrate what can go wrong:
folks getting fed up with the founders and wandering off with the virally
licensed version--and making changes that *don't* make it back into the
commercial product.  LiveCode itself doesn't face this risk, as a salable
standalone cannot be made from the community version.  I can't think of a
successful dual-license offhand, but there probably are some.

Viral licenses are useful when you need or want the thing to exist, and
don't want someone else to be able to make a better version without sharing
it back to you.  Some can be used with other licenses, and only try to
control changes to their own code, while others try to glom on to and
absorbe other code into their licenses (the GPL's "all your code are belong
to us").

Hmm, that was more than I meant to write.  If you do a web search for
"hawkins economics open source software" you'll probably find a
pre-publication version of my paper.  I can't hand it out anymore due to
the copyright assignment, but it was the seminal paper on the actual
economics of open source software.

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462