Re: Compare Linux and Freebsd Redux

From: John S. Dyson (toor_at_iquest.net)
Date: 05/28/04 

Date: Fri, 28 May 2004 04:29:23 +0000 (UTC)

In article <10bdcem8tdo6v2e@corp.supernews.com>,
        "Neil Bradley" <nb_no_spam@synthcom.com> writes:
> "krf" <krf@Vega.com> wrote in message
> news:pan.2004.05.28.02.21.55.238893@Vega.com...
>> By happy chance a Linux job came in over close to Dallas today (Thank you
>> MS and SCO!!!) Sorry, I have to disagree with you guys who don't like the
>> GPL controversy. I think it has been the greatest thing to happen to
>> Linux (and I assume, other non-Redmond OS's).
>
> Well, GPL and Linux are two completely separate things. My beef with the GPL
> is that it attaches politics to the license on what you can and can't do
> with the code. The BSD license truly is free.
>
When looking at the attributes of the licenses, neither
the free (e.g. BSDL) or redistribution encumbered (GPL) licenses
force the redistribution of the software. So, any rhetoric
about a license keeping the source code or binary code available
is specious.

The major thing that the licenses really do is to specify the terms
for subsequent redistribution of the programs. In the case of BSDL,
the major 'cost' of redistribution is to make sure that the
recipient has information about the copyright, license and
subsequent terms of use. Those BSDL 'conditions' for redistribution
are essentially the 'common sense' requirements that provide the
license information to the recipient. (Essentially, the BSDL
is practically the minimally restrictive true license without being
public domain.) When redistributing other people's BSDLed work,
the source code of your own, potentially costly or time consuming
add on modifications aren't encumbered and you can keep your
modifications and add-on inventions secret while continuing to
redistribute the runnable programs. Your modified versions
of BSDLed software IN NO WAY negatively impact the availability
of the original code that you started with -- so the
'freeness' of the original code is NOT impacted by the BSDL
or GPL type licenses, whether or not you keep your potentially
large source code investment secret or instead decide to let other
people have it (hopefully, under free, BSDL like terms.) There
is NOTHING magical about the BSDL, and no implication that
add on works must be licensed for free use, and no serious
conditions for redistribution of source or binary are imposed
by the BSDL.

In the case of the GPL, there are conditions upon redistribution of
runnable programs. Those conditions put the greatest burden on
developers who create significant add-on enhancements. For individuals
who are simply creating carbon copies of pre-built runnable GPLed programs,
then there is practically NO encumberance for that redistribution.
Most of the (almost NIL) redistribution encumberance for those
who only 'copy' GPLed works is to provide pointers to the original
source code locations on the net, offering copies of the software or other
similar conditions. GPL is quite nice for the CDROM marketeers,
where subsequent derived sources are strongly encouraged to be
made available (due to the effects of the GPL terms) by those
developers who invested in the add on innovation. In the case of the GPL,
the only significant cost is incurred by the add-on software
development investment that can be deemed to be 'derived' from
existant GPLed programs. (Derivation can theoretically incorporate
significantly greater investment of time and effort than the original GPLed
codebase.) Summing up the conditional freedom for redistribution
for GPLed code: similar to BSDLed code, source code can essentially
be passed from friend to friend without significant consideration.
For runnable GPLed programs, as long as the programs aren't modified,
then the programs have few effective 'restrictions', not alot
different from BSDL, but the source modifications for GPLed programs
can slightly complicate the redistribution -- and one should apriori
plan to give the source code modifications of GPLed works to those who
receive the binaries.

There are more details than the notes above, but the qualitative
difference between the 'freedom' of each license is most strongly
felt by add-on developers. Any claimed 'promotion' of the freeness
of the code is somewhat specious, because AFAIR, neither license forces
the delivery of runnable programs or source code to any third party.

The 'forced' distribution of pieces of 'software' is mostly related
to the requirement that source code be provided/offered/or pointed
to for those who are given binary copies of the GPLed work. When
doing significant upgrades to GPLed code, it is simply important to
understand that the product of that add-on development must generally
be offered to the 'customer' who receives the code. A wise developer
will do a risk assessment for the potential of the 'expensive' add-on
work being divulged to a competitor, or the customer will opt-out
of a subsequent support arrangement since he supposedly has access to
the source codebase. In some cases, the risk will be very low, the
add-on work is so customer specific as to be unhelpful for other
applications, or the customer has no interest in providing the support
himself. Admittedly, in MANY cases, this 'risk' is small, but in
some important cases, the risk can be high.

>From a philosopical standpoint, the rhetoric about GPL is well
sold to the developer community, but it is exactly the potentially
most innovative and productive add-on developer community who
incur the highest cost in the GPL scheme. On the other hand,
the marketeers, those who started the project on the 'ground floor',
and those who benefit from name recognition incur the least cost
in this scheme, and GPL is essentially a license of free software
for many individuals in each of those categories -- but cost
with relatively less benefit (but still beneficial) is incurred
by those often-unsung add-on developers.

John

Relevant Pages

  • RE: Linux GPL and binary module exception clause?
    ... you run the Linux kernel source code without creating a derived work. ... So the license that would be relevent would be a license that ... cannot compile them without agreeing to the GPL? ...
    (Linux-Kernel)
  • Re: (was) GUI With Ruby =>OT FSF and GPL
    ... The GPL was crafted so ... long as they accept and execute the terms of the license. ... Here's the section which requires source code ... cost of physically performing source distribution, ...
    (comp.lang.ruby)
  • Re: Asm For Nerds
    ... publication of full specs _and_ full BIOS source code in the ... any kind of failure. ... just an unwillingness to write code related to the GPL cause... ... I proceeded to find the BSD license, ...
    (alt.lang.asm)
  • Re: A fucking bunch of lying pussies
    ... you cannot have freeware sections integrated in a GPL program, ... GPL program could be construed as an attempt to abrogate the authors ... violating your license agreement, something you are not allowed to do ... > of the source code to my heart's content, as long as I give credit where credit ...
    (alt.lang.asm)
  • Re: Interesting Web Site on Open Source Development
    ... branch the code and release under a different license. ... But sure, you lose control of the code that you release under GPL, ... > available but restricted its redistribution in modified form as it ... Hm, restricted redistribution? ...
    (alt.lang.asm)