What license to pick...
kmself at ix.netcom.com
kmself at ix.netcom.com
Tue Oct 3 06:33:15 UTC 2000
On Mon, Oct 02, 2000 at 10:34:53AM +0200, Lionello Lunesu (lionello at mondobizzarro.com) 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
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
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 come, may I add) was which distribution to
> use. It appeared like the was no such thing as 'linux' but rather
> several distributions. What was even more confusing was that these
> distributions were also growing apart, thus creating some level of
> incompatibility. Yeah, way to go GPL.
This is a grossly inaccurate and incorrect assessment.
First, Linux the kernel, and a Linux-based distribution, are two wholly
different things. One is a single program, the other is an assemblage
of programs under a wide variety of licenses, including both non-free
and proprietary licenses in many cases.
Each of the distributions you were contemplating almost certainly
contained a kernel directly released by Linus Torvalds. Other aspects
of the distributions may be software licensed under GPL, LGPL, BSD, MIT,
public domain, MozPL, or other licenses. Configuration issues such as
the filesystem layout, location and format of files under /etc, location
and name of services, etc., are not subject to copyright at all.
The GPL is very simply *not* the root cause of incompatibilities between
Linux systems. Much as they're discussed, the differences tend to be
smaller than the similarities. And, IMAO, the distribution most closely
aligned with the aims of the GPL (Debian) does a rather fine job of
holding to standards.
Note that the case of the BSDs is an interesting contrast. The nominal
license (BSD) is intended to allow proprietary (or free) forking. Still
each of the BSDs strongly resembles the others in gross structure.
However the kernels are different, and follow different development
tracks. Almost the inverse of the Linux situation. Licensing has
little to do with this; group, project, and commercial dynamics far
> Another big thing is that I'm looking for a license 'just to get
> started'. I want to 'share' our code with the public as soon as
> possible, but (of course) with the necessary protection.
I think what you're looking for is a form of NDA or general developers
agreement, not a general software license, per se. Given your apparent
intent and cautions, I'd suggest you explore these alternatives. Later
you can modify this if necessary.
> But especially in this stage, the early beginning, I don't want to throw
> our precious code on the web with complete freedom.
This does suggest a need for companies and organizations which are
interested in moving toward open source but don't wish to take the
plunge completely in one fell swoop. I'd be interested in comments on
> So what am I doing here on opersource.org? I want to go "open source".
I'd call what you want "source distributed" -- you want to distribute
source. You don't want to open it completely.
Karsten M. Self <kmself at ix.netcom.com> http://www.netcom.com/~kmself
Evangelist, Opensales, Inc. http://www.opensales.org
What part of "Gestalt" don't you understand? There is no K5 cabal
GPG fingerprint: F932 8B25 5FDD 2528 D595 DC61 3847 889F 55F2 B9B0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 232 bytes
Desc: not available
More information about the License-discuss