Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!chi-news.cic.net!usc!sdd.hp.com!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.os.linux.advocacy,comp.unix.bsd.freebsd.misc
Subject: Re: Linux vs FreeBSD
Date: 14 Dec 1995 04:54:12 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 226
Message-ID: <4aoalk$s21@park.uvsc.edu>
References: <489kuu$rbo@pelican.cs.ucla.edu> <DJ8DMn.3oM@nntpa.cb.att.com> <4aa6k2$9et@josie.abo.fi> <4aajus$nd@dyson.iquest.net> <kevinbDJGqtq.Fup@netcom.com>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.os.linux.advocacy:30700 comp.unix.bsd.freebsd.misc:10697
[ ... Commercial compilers vs. BSD licensed compilers (BSD uses
GCC, by the way, but has its own libc), vs. GPL'ed compilers ... ]
This is a rational, reasoned argument. I disagree with some
of the conclusions you arrive at, however.
kevin@frobozz.sccsi.com (Kevin Brown) wrote:
[ ... commercial compilers ... ]
] Where there exists more than one company selling such a product,
] competition is likely to ensue, thus reducing the cost of the
] binary distribution somewhere close to the actual price of
] making sufficient profit from the product to keep the
] distributing company alive (i.e., enough to make it worth it
] to the company to distribute the binaries, but low enough to
] keep the demand high enough).
The actual target price in a commercial competition is enough to
keep the distribution company alive *plus* enough to continue to
improve the product competitively. You left out the research
and developement amortization over the product life cycle per
version.
] The consequences to the vendors themselves? Clearly, each
] must invent
And continue to reinvent...
] the ability to compile C themselves, since they have no access
] to source. Furthermore, they need to distinguish their
] compilers from the other offerings, which means that they end
] up inventing features that are incompatible with the ones
] offered by their competitors.
This is not a necessary consequence, but it is often a desirable
one. It is the "standard + extensions" argument, which is used
to lock customers into your code base, either unwittingly (in the
case of a not very bright customer), or voluntarily, in the case
of the feature being more desirable than the ability to easily
choose another vendor.
] Where a vendor wishes to include a feature offered by another
] vendor in their own compiler, they must invent it themselves.
] Now let's examine the case of free software under the BSD copyright in
] the above conditions (assume for the moment that there is a freely
] available BSD compiler).
]
] Vendors now have a choice: they can either implement the ability to
] compile C code themselves, or they can distribute binaries derived
] from the BSD compiler. It's pretty unlikely that they'll distribute
] source, since that would be an added expense.
Finally! Someone who understands that the source requirement of
GPL costs the distributor!
] Consumers also have a choice: they can either buy binaries from a
] vendor, or create their own binaries (or obtain them from some
] other free source).
[ ... ]
] ... vendors will continue to invent new features to differentiate
] their products from those of their competitors and reinvent
] features that their competitors have. If the free compiler is
] a good base, lots of derivative works are likely to pop up, but
] they're also likely to be incompatible with each other.
This is not necessarily true. See below.
] ... The longer the free compiler has been out, the longer
] commercial vendors have had to create divergent sets of
] features for that compiler, probably to the extent of making
] their offerings incompatible with the free version (since doing it
] that way reduces the competition from the free sector). If the
] consumer happens to need a feature that only the commercial vendors
] supply, then they can buy the commercial version and pay for the
] support that vendor has to offer (whether in money or in bad support,
] and the two aren't mutually exclusive :-), or they can contract out
] the work to someone who can then make the appropriate modifications to
] the free version. Since the BSD copyright allows the author of the
] derivative work to keep his modifications to himself, such
] modifications are likely to remain proprietary, and therefore the
] public version will not evolve much except through the efforts of
] people in the free sector itself.
You are ignoring the benefits that accrue to the commercial vendor
of contributing the changes back to the free sector. They are not
insignificant.
Assuming developement continues in the free sector, it is in
the interests of the vendor to contribute changes back to the
free sector. This is because it is likely that the vendor will
want to incorporate changes from the ongoing free develeopment
it their product.
If, as in the GPL case, the vendor's product is support and
response to customer needs, then the vendor will benefit in
reducing the integration overhead. He will aso win goodwill
from the free community, which will give him a pool of potential
employees with proven track records and a willingness to work
with him, as well as other benefits, such as early access to
the code, say in architectural and design decisions, and a big
hand in the productization process.
] Now let's examine the case where the only source of free software is
] GPL'ed software (assume that "GPL" refers to the appropriate choice of
] the GPL or the LGPL, depending on the context).
]
] Commercial entities which wish to write a compiler have two
] choices: do it themselves or base theirs on the free version.
] But those that wish to base theirs on the free version are
] forced to release source, thereby disclosing their efforts to
] the public. Their alternative is to do it themselves, but
] that's a more expensive proposition.
This is false. Consider the case of the company who modifies
the optimizer significantly, but whose primary product is
compiled C code.
Such a company can use the compiler internally to gain competitive
advantage resulting from the work of those who put together the
GPL'ed product, but without benefitting them, as the GPL intends.
This was very nearly the position of NeXT with Objective C.
Further, the company can compile and sell binary versions, with
source, of other GPL'ed code, including the original compiler,
if they choose to.
Thus such a company could produce a GCC that compiled code
faster than the other publically available binaries, but the
source to the binary they distribute would not be of any use
to the people who obtain it under the terms of the GPL, since
the code compiled with the optimized compiler would not have
the additional optimizations in its binary.
Another potential scenario, related to this one, is the private
implementation language.
Consider that a company creates a back end for GCC that renders
it a code translator instead of a compiler (I personally
considered one of these for a LISP machine at one time; it's
job would be to translate to LISP).
Only they define their own implementation language using one 'x'
followed by a 6 digit compile-time random number for all data
to be handled by the linker, and they mak some other tricky
assumptions so that it's almost a quad-level P-code.
Then they make a P-code to object code "compiler".
Then they "compile" GPL'ed programs into this P-code form, and
write an editor that lets them manipulate their implementation
language in an abstract form.
Then they make improvements in the implementation language
version instead of in the C source version.
And they compile the P-code and distribute binaries.
To comply with the terms of the GPL, they offer to distribute
their OIL (Obscure Implementation Language) sources to anyone
who requests them. Only without the P-code compiler, this
doesn't do you a hell of a lot of good.
So I disagree that "the *only* way they can really compete is
the support and services they offer".
A company could also "delay" use of patches by using a modified
patch tool as part of the compilation process do that the code
won't patch cleanly, but can still be used. Or they can otherwise
obfuscate the code, to enlarge their market window.
] End result? In the free sector, the compiler ends up evolving
] primarily as a result of the needs of individual consumers who
] contract someone to implement the features they need, and therefore it
] acquires the features that the consumer group as a whole desires.
] Otherwise they buy the commercial version and deal with the well-known
] consequences of that. This is likely to result in a free compiler
] that keeps up well with the commercial versions in terms of truly
] needed features.
Actually, this will result in changes without an overall
architectural "vision"... what Linus gives to Linux and the
core teams give to BSD.
I've called the programmers involved in this act "putterers",
but "frobbing" is probably a more approprate term.
I think without an overall direction, such code will meander,
seemingly aimlessly, at the whims of whoever has a free dollar
or two at any given time.
The GCC is a special case because of the investiment some people
have made in terms of commitment. And it has bought some of
them a level of market (Cygnus, for instance). But that type of
thing has to have a critical mass in the first place, or some
other infusion of capitol assets to get it to where it can
operate.
] Now let's look at the case where both BSD and GPL versions exist.
I disagree with the conclusions arrived at here for the same
reasons cited above. They *may* follow, but they do not
*necessarily* follow, from the base you have laid.
] No matter how you slice it, though, there's no question about
] it: the world is better off with free software, whether it's
] under the GPL or the BSD copyright, than without it, as my
] previous comments should make clear.
Loudly agreed!
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.