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

[Peter Haworth]

Thanks for this explanation, just demonstrates how little I know about
licensing in the open source world!

I get what you're saying about lcStackbrowser - it doesn't persist beyond
the development stage and none of its code is added to whatever executable
is created using it.

But I still need some sort of protection against someone simply copying
code out of it and inserting it into their own products, that's where it
gets hazy for me.  If my license is "open source", does that mean they
would have to release their product as "open source" since it includes my
open source code?

It's this type of thing that has prevented me form going open source up to
now.  It's a couple of minutes work for me to remove the password
protection from the code but much more time required to figure out a good
license and how to deal with not having a free demo any more.

But I am getting more and more requests from Community Edition users to
make it available to them so I think I need to bite the bullet.

OK Google - "How do I sell an open source product"

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>

On Sun, Jan 4, 2015 at 7:59 AM, Dr. Hawkins <dochawk at gmail.com> wrote:

> 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
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>