Python Is Really Middleware

Tim Daneliuk tundra at tundraware.com
Thu Aug 2 19:45:09 EDT 2001


Chris Barker wrote:
> 
> Tim Daneliuk wrote:
> 
> > It depends on what you mean by "enclosure".  Per the point above,
> > organizations, like people, need to enforce their property rights.
> 
> "need" is arguable. I think a whole lot of organizations keep their code
> restricted for no good reason. Of course, some folks have good reason:
> Microsoft could be a successful company if it opened up it's products,
> but it would be no where near as rich!

That's right.  And as a leader in any company with investors, public
or private, you have an ethical obligation to maximize their return
on investment using any (ethical) means at your disposal.  
"Ethical Means" should be read to mean "any activity which
does not involve Fraud, Violence, or Threat Of Violence). 

In this same vein - "I think a whole lot of individuals keep their
money in bank accounts that are hard to get into.  If they would
just open up their bank accounts and let me have some of their
property, they'd still have some money left." 

Property is property, regardless of the medium it which it is
expressed.  Property Rights are fundamental to any civil society.

> 
> > If a particular technology makes this impossible or very hard,
> > that technology will be met by huge opposition.  I once was in
> > the position of having to authorize buying Sun's 'C' compiler
> > rather than using the GPLed GCC for exactly this reason.  Even though
> > I, and all the engineers who worked for me, preferred GCC, I could
> > not in good conscience expose my company to the possibilty  of
> > being forced to reveal the inner workings of a product that
> > was our key competetive distinction in the market we served.
> > This sort of thing is not unusual.
> 
> Why in the world was this a possibility??? I can see that paranoid
> non-lawyer non-techie execs might think so, but while the GPL can be
> considered a virus, it is not very contagious. It only acts that way if
> you want to include GPL'd code in your code base, not if you want to use
> the output from an executable that happens to be built from the GPL.
> This is very well accepted. If you wanted to add functionality to gcc
> itself, and keep that private, that's another question, but I don't
> think Sun would let you do that either: unless you gave them a LOT of
> money!

At the time, the GNU 'lesser' license had not yet been hammered out.
The license as written could have been construed to mean that software 
compiled w/GCC had to be distributed in source form.   We were a 
software vendor and this was an unacceptable risk, in my judgement.
(Because I was fulfilling my obligation to the investors to try to maximize
their return on investment.)

> 
> > This, BTW, is why the GPL is under attack and people are looking
> > for alternatives.
> 
> Not exactly. There is no problem with using a GPL'd tool to run any part
> of your business. The only thing you can't do is include GPL'd code
> itself in a proprietary product. That, of course, is a good reason for
> libraries and other components that you might want to include with
> proprietary software (such as Python) not to be GPL'd. Even if the
> CPython interpreter were to be GPL'd you could still develop proprietary
> software with it, but you could not include the interpreter, or part of
> it in your own app. This ability, of course is very useful, so it's a
> good thing it has a more liberal license.
> 
> By the way, even the FSF acknowledges this, which is why the LGPL
> exists.
> 
> -Chris
> 


I have no problem with Open Source authors stipulating the terms
of distribution of their work.  This is, after all, *their* property
and their rights thereto ought to be protected like anyone elses.

As I mentioned above, the problems I have encountered in this area
are pre-LGPL and may well no longer be an issue.

-- 
------------------------------------------------------------------------------
Tim Daneliuk
tundra at tundraware.com



More information about the Python-list mailing list