Re: GNU licenses

[Stefaan A Eeckels]

On 4 Sep 2006 12:16:03 -0700
mike4ty4@yahoo.com wrote:

> Thanks for your input, but _WHY_ was the GPL originally made this way?

I did reply to that:

> Because the guy who wrote the GPL thinks that all software should come
> with source code, and that people should have the right to modify the
> code they use, and pass it on (in original or modified form) to whom
> they please. And he's used the rights granted to software authors by
> the current copyright statutes to control the duplication and
> distribution of their work to achieve that purpose. 
> 
> Others just wanted to write software that would be used by as many
> people (programmers and end-users) as possible, and licensed their
> code under the BSD license. Or the Artistic License. Or made it Public
> Domain where such a concept exists.
> 
> Others wanted to maintain the control over a project while still
> inviting and encouraging others to participate in its development, and
> invented the MPL. 
> 
> And there are more of these licenses, each with a particular
> objective.
> 
> Variety is the spice of life.

> *What is the rationale* for having the person GPL the combined work as
> part of the terms, which includes all the original content?

Ensure that software is distributed in source format, and with the
right to modify it and give it away. There's something pretty
attractive in this idea. If there is only source-less packaged software
à la Windows and MS Office, people cannot use that essential attribute
of a computer, its programmability.  Instead of adapting the computer
to the users, more and more we're asking users to adapt to the limits
of the programs they use. 

While this might be the best way for a non-programmer to use a computer
(the computer as device), for a programmer it's a pretty dreary
prospect. The GPL vision of software is more like how science is
practiced - make results freely available for peer review, and build on
the work of others. 

The GPL was drafted by a rather-left-of-center computer enthusiast (in
the days you could still call such people "hackers") for fellow computer
enthusiasts. Programs published like scientific articles, with
colleagues improving them and feeding those improvements back into an
ever improving and expanding body of software, with the added advantage
that you could tailor it to your specific requirements. And yes, you
weren't paid for writing the programs, but for the things you could do
with them. Pretty idealistic, and pretty academic.

In an idealised GPL world, there would be no packages like MS Word or
OSes like Windows to be sold - the core technologies would be free for
all to use, and improve upon. The added value would come from tailoring
the core technologies to the specific needs of people instead of the
"one-humongous-package-fits-all-needs" concept like MS Office.
Programmers would be paid for the customisation and improvements, and
the person paying for them could then decide to keep those improvements
for herself (there is no duty to distribute), or share them. Mutatis
mutandis, it would be a bit like how lawyers function.

It is already the case that the majority of the local economic value in
the software business is generated by secondary services - customising
MS Office, auditing existing systems for legal compliance, programs
related to local conditions etc, etc. The difference is that Microsoft
gets a staggering piece of the economic pie for very little real value,
and not all that much employment (one only has to look at their profit
margins). If all the money now going to Microsoft for licenses and
service contracts would be available for local programming work - like
tailoring GPLed or other Free Software to the specific requirements of
companies and organisations, it would mean a major boost to a lot of
economies, and give local programmers lots of rather interesting work.

Just some food for thought.

Take care,

-- 
Stefaan A Eeckels
-- 
Every modification you make to a third-party software product is just
one more thing that you have to document, maintain, reimplement with
upgrades, and explain to your co-workers.  Most of the time this is a
very bad idea. -- Russ Allbery (rra@stanford.edu)