On Mon, Oct 02, 2000 at 10:34:53AM +0200, Lionello Lunesu ([EMAIL PROTECTED])
wrote:
OK, I'll 'share' my thoughts on all of these mails. : ) Thanks for all
the helpful input by the way! I appreciate it!
LL So we (my company) have decided to make our VR-toolkit open source!
LL [...]
LL AND we don't want other people to be able to create their
LL own distribution of the toolkit.
BB These two are inconsistant - the OSD essentially requires that others
BB be allowed to created their own modified release of your code.
OK, if this is the case, then I'll have to change the plans. I don't
want to go open-source.. I think though that the license I'm looking for
is out there, somewhere. But it looks like I'll be writing my own
license agreement. Let me describe our product (the toolkit) in more
detail. If somebody knows some good agreements I must have a look at,
please let me know!
Not only will you be writing your own licensing agreement, but since the
code you're looking to release won't generally be miscable with existing
free software compatibility issues don't particularly matter. You're
stipulating conditions inconsistant with the GPL, and with the OSD.
First of all, we need the input. I guess this sounds egoistic, but I'm
not done yet. In return for the input, people can use it for their own
projects. We WANT them to use the toolkit for their own projects and I
think they'll like it too. I know it's a long shot, but I would love it
if it became a standard of some kind.
Flip this coin over. What's the developer getting? In a recent
instance, two tools, one more polished, with a head start, and on
technical merits more preferred, lost significant advantage over a
latter rival in large part because the newcomer's licensing terms both
allowed and encouraged greater participation. My only problem is I
can't remember if I had in mind mSQL/MySQL or KDE/Gnome
Why not GPL? This toolkit allows 'you' to create games (or
simulations, whatever) in no-time. It's completely object oriented and
allows you to reuse existing components. Just putting this toolkit on
the web (GPL/freeware) could certainly damage our business (we ARE a
company, remember that). This is why I plan to charge for commercial
use of the toolkit. And I think I can do this in much the same way as
Trolltech did with their toolkit Qt.
IMO, what TrollTech did with Qt was fine, as far as it went. Where the
line was crossed was with the KDE project insisting that Qt and the Qt
license were compatible with the GPL when it was patently clear that
they were not. Or at least, it was sufficiently *unclear* that this was
acceptable that several major Linux distributions excluded KDE from
their packaging.
Being a proprietary or non-free software distributor is not a bad thing
in my book. Walking the proprietary / non-free SWD walk and talking the
free software project talk is a very thin ruse. The instance that comes
to mind is Sun, a company which still hasn't settled on its strategy WRT
free software and Linux, but whose gambits trying to call "black"
"white", particularly in the case of the SCSL, still chafe. I'm not
wholly critical of Sun -- their record is mixed, and certain acts such
as GPLing (actually *triple* licensing) StarOffice are to be commended.
The lesson though is to tread carefully here. The community tends not
to favor anything which appears to be deceptive tactics.
I find two general faults with the analysis you present in reaching your
conclusions:
1. Your assessment that you cannot function as a free software
distributor in this space assumes a static market in which a
competing free software library with comparable features does not
emerge. See again my cautions WRT KDE and mSQL. In both instances,
a rival initially far less technically capable, but with more liberal
licensing terms, gained significantly, or surpassed altogether, the
first mover. Note that though I don't follow the gaming market at
all, I am aware of several companies moving toward open source
positions. I suspect this will be a growing trend.
2. Free software isn't a one-time, do-it-all-the-way, proposition.
It's possible to pursue a proprietary strategy now and adopt a free
one later. There are issues WRT incorporation of third-party code
at both stages -- third party code in a proprietary project
generally needs to either be cleared, bought, expunged, or
reëngineered, before the code can be released under a free software
license. Likewise, contributed or incorporated external code in a
free software project generally can't simply be incorporated into a
proprietary release. Maintaining all rights or ownership over the
codebase will tend to increase your options.
Why no third-party distributions? This one is based on my experiences
with linux. Some years ago I wanted to install linux on a system and the
first problem (of many to
