Re: New Software License idea: "The Freedom License."

[Alan Mackenzie]

Karen Hill <karen_hill22@yahoo.com> wrote on 22 May 2006 16:49:50 -0700:
> Hello.

Hi from Munich!

> I have been thinking about all the problems the GPL causes.  My
> solution is a new license called the "Freedom License".  Here it is:

Hey, I know you're trolling, but heck!  After Alexander Terekhov for
month after month, a change is quite invigorating.  It's a poor newsgroup
that only has one troll.

> THE FREEDOM LICENSE

ROTFL!

> Preamble:

> What are the problems with the GPL and how does this new license solve
> them?  Many experienced software developers know about the GPL and the
> BSD style Licenses (apache, bsd, mozilla, cddl etc).  The BSD License,
> for those who don't know,  allows one to do whatever one wishes with
> the code, including relicensing it IIRC.  Frequently, a GPL coder will
> take BSD licensed code, add a modification or two and release the whole
> thing as GPL.   This new creation will be unavailable to the BSD user
> to modify as they see fit under a BSD license.

That's a very good argument to stick to the GPL wherever possible; and
further, if possible, to assign the copyright of your code to the FSF.
That will give you the hassle freeest life.

> Part 1.  SOFTWARE STANDARDS

> Code quality terms, the BSD licensed software is often of a superior
> quality compared to its GPL counterpart.

I suggest here your write "is better than".  It's shorter, and more to
the point.

I doubt it's true, though.

> Often, the GPL counterpart will break standards and include supposedly
> "enhanced" functionality which is what Microsoft does too!  And when
> they do this they claim it is better!

MS extends standards to break interoperability.  (See, I can write
8-syllable words, too).  GPL'd code, particularly GNU code, goes beyond
standards to enhance programs, as part of the normal evolution of
systems.  The difference is, GNU stuff leaves "backward compatibility"
options so as to eliminate (or at least minimise) the hassle for users of
standard or "standard" versions.

> We can see this effect in the user space tools and shells.  For
> example, on a Linux system, many of the tools do NOT function as they
> were intended, ....

Yes, even Linux stuff has bugs in it.  ;-(

> ... but are actually hacks ....

Created by some of the world's finest hackers.

> .... and extensions.  Imagine logging into a GNU/Linux system and
> getting the "sh" shell.  If you were a true blue UNIX or BSD user you
> may not suspect that it is not sh at all but really the GNU BASH
> shell!!  That they purposly hid this is scary.

"They" didn't hide this, "they" explicitly documented it.  For example,
in the bash man page:

       If bash is invoked with the name sh, it tries to mimic the
       startup behavior of historical versions of sh  as  closely
       as  possible,  while  conforming  to the POSIX standard as
       well.

They also say that if you call your shell "sh", you'll get a shell which
behaves like old Steve's one.  But why?  It's like cutting your right
foot off so as to be able to have a fair race with your uncle's grandad.

The place where this DOES matter is in shell scripts which have to be
portable over lots of Unixen.  This is done (as you surely know) by
naming the shell in a "#!" construct in line 1 of the shell.  You do know
this, don't you?

> Many commands lie and don't tell you that they are really gnu
> extentioned.  On a linux system, "make" is not really make but just a
> renamed "gmake".  Sneaky stuff with a lot of extensions built in,
> making the casual user believe those are all part of the REAL tool.

What is wrong with this?  Commands like make have evolved considerably
since 1972.  However, inside the GNU make info page you can read this:

       GNU `make' conforms to section 6.2 of `IEEE Standard 1003.2-1992'
    (POSIX.2).

So, if the `make' on your Linux system performs in a non-standard way,
that is a bug.  If you report it, it will get fixed.

> This tactic is evident throught the GPL toolset and libraries.

"Tactic"?  And what is the strategy behind this alleged tactic?

> They embrace, extend and frequently extinguish UNIX standards.

I doubt this very much.  `make' is not an example of this.  Can you give
any real examples?

> This leaves newbies unwittingly learning on a GNU system getting
> confused when they finally go to a real UNIX system and then think Unix
> tools don't operate correctly!

Well, partly this is down to the people who haven't told these newbies
that GNU's not Unix.  Even so, I don't think these newbies would suffer
more than minor inconvenience.

> When in fact it was the GNU tools that were the problem and not
> operating to standards!

Or "standards".

Has this happened to you?  You'll probably find that "real" UNIX systems
willingly adopt the GNU tools because they're better than the 1972
edition of the UNIX tools.

> You often see a newbie trying out FreeBSD for the first time not being
> able to get something to work because they don't realize that the true
> command doesn't support the extension that they had previously used in
> the Fake GPL command on their Linux box.

This isn't true.  I have never seen a newbie having this difficulty.  In
fact, I've never seen anybody trying out FreeBSD at all, other than
myself on a remote login to my ISP (and maybe to SourceForge).
Everything I've done has worked as expected.

> This hurts the other UNIX communities.

I've not heard any complaints, other than your own.

> They must now either rewrite their whole toolset to include those new
> unstandard but poplular tools or be neglected by the large userbase
> that the FSF has tricked into using GNU software.

This also isn't true.  They also have the option of replacing their old
toolset with the GNU one.  This is cheap and effective.

> It is even more hurtful when those tools that were extended were taken
> from the BSDs and embraced, extended and released as GPL.

This wasn't done.  The GNU tools were written from scratch, and were
deliberately intended to be better tools, freed from the tight speed and
memory restrictions which constrained the early Unix tools.

> Which means the BSDs cannot use them at all.

The BSDs can use them just the same as anybody else can.  Probably they
do.

> PART 2.   SOFTWARE QUALITY

> The BSD licensed software are known for high quality  (not withstanding
> the FreeBSD 5.x series fiasco).  On a typical linux machine, many of
> the "free" software that one uses and depends on is not GPL licensed at
> all.

Indeed.  X-Windows, for example.  A lot of the BSD networking code for
another example.

> This is because the quality and workmanship is so high, and the
> software so important that the GPL developers have yet to embrace and
> extend it in the manner discussed in Part 1 of this license.

They'll not be doing this.  If the quality's high and the code is free
(enough), the FSF won't be cloning it.  Why should they?

> Take for example Apache.  It is not GPL.  Nor is PostgreSQL GPL, and it
> beats GPL'd mySQL's feature and reliablity.

> OpenBSD is extremely secure and bug free.

So I've heard.

> Theo Raadt even said that the GNU/Linux kernel was a security
> nightmare and that they should fix it.

Funny, that.  I've been running Linux for over 8 years, spending
thousands of hours online.  I've not caught a single virus yet, as far as
I'm aware, the worst I've suffered being having some Asian wanker trying
to use me as a mailing relay.

By contrast, in my last (paid) job, I hadn't been there for a fortnight
before my MS-Windows 2000 had caught a "continually shutting down" virus.
It wasn't the last, by any means.

> PART 3.  SOFTWARE FORKS AND COMMERCIALIZATION

> Often the FSF and GNU people will say that the GPL prevents a company
> from taking the source of a BSD licensed project and forking it into a
> closed source version.  This line of reasoning has been the major
> influence in convincing people to go with GPL software.  It is a
> seductive form of reasoning but entirely wrong.  Commercial closed
> source software forking is of GREAT value to the project, and shut of
> the spigot closed source forking doesn't get the company very far!

Sorry, I can't even parse that.  Have you got typos in there?

> Look at X.org and XFree86.  XFree86 went too far in their restrictions
> and were made irrelevant!

> Why is that?  Because, most companies cannot fork away and get very
> far!  They need to stay close to the open code base, and usually close
> off only the business logic functions that enable them to survive
> financially.  And when they do survive financially, they tend to
> contribute to the general development making the project stronger.

Is this a bad thing in any way?

> A great example of this is PostgreSQL.  EnterpriseDB provides Oracle
> compatiblity in their closed source version of PostgreSQL.  Yet,  they
> are very active in developing PostgreSQL!  Needless to say, they make
> money in their business logic niche (oracle compatiblity), yet continue
> to make PostgreSQL better because they get the full resources of the
> community when they do!

Is this a bad thing in any way?

> Fujitsu made significant contributions to PostgreSQL making the 8.x
> branch possible.  There was no GPL compelling them to do this.  They
> provided native Windows support among other features.

> PART 4.  THE SOLUTION.

You've still not made clear what the problem is, yet.

> The Freedom License is the BSD License with 3 additional Clauses.

> Clause Number One:

> When software licensed under the Freedom License is modified and then
> relicensed under the GPL, that new derived software will be dual
> licensed with the Freedom License being the second license in addition
> to the GPL.  This preserves the Freedom to do whatever one wants with
> the software as envisioned by the BSD license.

Sounds very GPL'ish.

> Clause Number Two.

> If you link you GPL software to a Freedom Licensed software and you own
> the copyright to the GPL software, the linked result will also be dual
> licensed in both the GPL and the Freedom License.

That would probably violate the GPL.  Alex "mere compilation" Terrapin
will certainly be butting in with his, er, viewpoint here.

> Clause Number Three

> If you create derived work from the Freedom License and license it
> under the GPL, it will also be licensed dually to use both the GPL and
> Freedom License.

Fine.

Big yawn.  What are you trying to say?

-- 
Alan Mackenzie (Munich, Germany)
Email: aacm@muuc.dee; to decode, wherever there is a repeated letter
(like "aa"), remove half of them (leaving, say, "a").