For Approval: Open Source Software Alliance License

Sean Chittenden sean at
Fri Sep 26 16:07:24 UTC 2003

> > A language who's core is BSD/MIT is of use to businesses.  A
> > language who's modules are all GPL is a language of little use to
> > a business that doesn't want to have to reinvent the wheel.  On
> > the other hand, a language with all of its modules that are
> > available under a BSD/MIT license, is of value.
> I suppose you mean that you are writing an interpreter for the
> language in question which is meant to be linked to other code by
> way of providing scripting or otherwise.  Such interpreters don't
> tend to be released under the GPL anyhow (can anyone think of a
> counterexample?)  but under BSD-ish licenses or mixed-status
> licenses like the LGPL or MPL.

Bah!  Who would bother with interpreters?  Why should I write
something, hack on it for a few days, and pay the price of the
inefficient language for when it gets run a billion times?  I have a
webserver that's topping out at around 60K connections per webserver
instance for static content and I'd like to get about 30-40K of
dynamic requests/sec... interpreted languages leave me at around 1-2K
rps and while C lets me hit my desired numbers, C is too intensive and
I'd like a more friendly syntax like Ruby.  The core of the language
is an actual compiler and the resulting code links to my so.  Thanks
to shared object prebinding, running programs with my language is
nearly as fast as statically compiled binaries.

> The GPLed implementation of the C and C++ languages has served
> software developers, including those who develop proprietary
> software, rather well, I think.  Unencumbered BSD would hardly be
> practical without it.

*cheers on TenDRA*

> > Quid pro quo: three single syllable words that can both be said
> > slowly, and do a halfway decent job of summarizing the OSSAL.  The
> > BSD/MIT license (which I support enthusiastically), however, can
> > almost be summarized as, quid pro throw (as in thrown into the
> > abyss without any assurance for getting something usable back in
> > return).
> I don't see how the OSSAL offers you any such assurances for your
> code in particular: I can tune it up, add amazing new features, and
> release under a fully proprietary license; you get precisely nothing
> back.  Same story with the BSD, of course.  What it does offer you
> is ecological resistance to a license you perceive as predatory.

Yup, but on the long haul, maintaining code is expensive... open
sourcing code reduces costs of maintenance and bugs and if a module is
a non-core part of a business, (with my Director of Engineering hat
on) a business or its engineering managers would foolish to keep the
non-core code in house.

I fully understand and realize the risks of BSD/MIT code and know that
OSSAL doesn't guarantee anything, it just guarantees that open source
work that is done, is usable by businesses.  Why is that so hard for
people to understand the value of this?

> > From a business's point of view, 
> I wish you wouldn't say "business" to mean "proprietary software
> development business".  It's confusing.

Fair enough, in my case, business means a "a widget producing business
that doesn't want to reinvent the wheel nor give away the plans to the

> > its ability to provide some form of quid pro quo for its efforts
> > to release code into the wild while still preserving the ability
> > for potential competitors to assimilate the code or any
> > modifications made by the public.
> But it leaves you utterly unprotected against competition from
> proprietary improvements.  Ironically, it is copyleft licenses that
> do so best, by the brute force method of making sure there are no
> proprietary improvements.  I don't see how you can have it both
> ways.

But I don't want to stifle competition by handicapping competitors.
In truth, I'm hoping that one in ten businesses lend some of their
engineering time toward open source modules for this lang and that
those are the businesses that understand the cost of software.  That
said, I also believe that being successful in business shouldn't
predicate on handicapping competitors by releasing useful tools in a
completely unusable manner.  I want to be successful in business
because I'm smarter and more nimble than my competition, so by all
means, let them improve a bit of code that they're going to have to
maintain a fork of.


Sean Chittenden
license-discuss archive is at

More information about the License-discuss mailing list