[clfswm-devel] CLFSWM licence change?

[madnificent]

Sigh.

Hello Stayvoid,


I guess it boils down to: do you want to share, or do you want to try
to be shared with.  When I write software which I publish, I want to
share.  I hope other people are willing to share back.

I'm not making any new important claims in this email, it's mostly
just an answer to Stayvoid.  Anyone is free to comment though.  Maybe
something new will come out of it.


On Sat, Jan 14, 2012 at 10:04 AM, Stayvoid <stayvoid at gmail.com> wrote:
> Hello!
>
>> No one suggested Clear BSD so far.
>> No one talked about this.
> I've posted those because the "BSD" term is ambiguous.

Yes well, that's OK.  Without context it can indeed be so.  When
people talk about licenses for software projects and they talk about
the BSD license they generally talk about the 2- or the 3-clause BSD
license.  The FSF does indeed use different names for these licenses.
For as much as I've seen it when there is talk about both BSD and MIT
as licenses, the BSD license generally means the 3-clause license
(which includes "acknowledge that I wrote this"), and MIT as the
equivalent to the 2-clause BSD license.  In these license schemes the
FSF generally uses the name of a project in which they have been used
instead.

>> I don't know the inner details of the X11 license, they claim it's
>> similar to MIT, I haven't checked.  It seems more complex than need
>> be.
> There is no such thing as the "MIT license."
> http://www.gnu.org/licenses/license-list.en.html#X11License
> "This license is sometimes called the MIT license, but that term is
> misleading, since MIT has used many licenses for software."
> How can you talk about something that you haven't checked?

There is as much an MIT license as there is an X11 license.  The names
aren't explicitly in the license itself, so both names are, indeed, to
some extent void.  MIT created multiple licenses.  That's why the FSF
doesn't want to use MIT as its name.  However, the consensus is that
the MIT license is what the FSF calls the Expat license.  Whether one
should follow the naming of one organization which spent research on
it, being the FSF, or the naming that's omnipresent elsewhere is up
for debate.  But let's not discuss it here, please.  Feel free to
perform a find and replace in my mails and replace MIT with Expat for
your viewing pleasure.

>> Simplicity is rarely a bad thing.  I see no legal tricks which can be
>> pulled on me if I use or publish MIT code.
> Please read this article:
> http://www.gnu.org/licenses/quick-guide-gplv3.en.html
> "We update the GPL to protect its copyleft from being undermined by
> legal or technological developments. The most recent version protects
> users from three recent threats:
>        •       Tivoization: Some companies have created various different kinds of
> devices that run GPLed software, and then rigged the hardware so that
> they can change the software that's running, but you cannot. If a
> device can run arbitrary software, it's a general-purpose computer,
> and its owner should control what it does. When a device thwarts you
> from doing that, we call that tivoization.
>        •       Laws prohibiting free software: Legislation like the Digital
> Millennium Copyright Act and the European Union Copyright Directive
> make it a crime to write or share software that can break DRM (Digital
> Restrictions Mismanagement; see below). These laws should not
> interfere with the rights the GPL grants you.
>        •       Discriminatory patent deals: Microsoft has recently started telling
> people that they will not sue free software users for patent
> infringement—as long as you get the software from a vendor that's
> paying Microsoft for the privilege. Ultimately, Microsoft is trying to
> collect royalties for the use of free software, which interferes with
> users' freedom. No company should be able to do this."

That's why I tend to support the EFF, instead of the FSF.  But there
too, I see what they say, then pick my stance.  Don't blindly follow
others.  I disagree that a software license should try to solve all
issues with software.  In my opinion we are solving the wrong problems
at the wrong level.  See, if enough lobbying occurs then maybe open
source software will be banned, regardless of what license we used,
it'll be illegal.  If you want to stop bad legislation, then stop bad
legislation.  Open your mouth, go protest, become an open source
advocate where it matters.  I doubt you're going to stop software
patents in this discussion though.  The software license has little to
do with bad legislation.  Yes, you can try to make it less bad, but
you should fix it where it's broken.  Furthermore some people that
support free software find that some of these things shouldn't be
blocked.  The Linux kernel, a key ingredient, is kept in GPLv2 for
instance.  And tivoization, for instance, isn't frowned upon
everywhere.  The opinions of the FSF are the opinions of the FSF.  It
is not the bliss of the Greek gods that has just descended upon us.

Furthermore, I might like some of the things the FSF is protecting me
from.  Without Tivoization, the TiVo may not have existed at all, for
instance.  Perhaps I, as a user, would prefer a locked TiVo over no
TiVo at all.  I personally prefer devices which can be freed, but I
don't think it's rightful to require all other people to share my
opinion.

>> The GPLv3 is in fact the
>> one trying to pull legal tricks on companies which have distributed
>> software under the GPLv2 or later.
> Could you provide an example?
> "In addition to clarifying the rules about licenses that are already
> GPL-compatible, GPLv3 is also newly compatible with a few other
> licenses. The Apache License 2.0 is a prime example."
> http://www.gnu.org/licenses/quick-guide-gplv3.en.html
> http://www.gnu.org/licenses/quick-guide-gplv3-compatibility.png
> "Arrows pointing from one license to another indicate that the first
> license is compatible with the second. This is true even if you follow
> multiple arrows to get from one license to the other; so, for example,
> the ISC license is compatible with GPLv3. GPLv2 is compatible with
> GPLv3 if the program allows you to choose "any later version" of the
> GPL, which is the case for most software released under this license."

I was hinting at the well known Novell and Microsoft deal for which
the FSF put a specific clause in the GPLv3 in order to stop its
execution.  Novell and Microsoft made a perfectly valid, though
somewhat sickening, deal.  It was legally sound though.  The FSF added
a clause in the GPLv3 to make this kind of deal completely different
than what it originally was.  The FSF tried to receive patent immunity
for all GPLv3 software Novell shared, regardless of the distribution
channel.  Let's step aside from the argumentation of whether or not
this is a good deed, as it's quite irrelevant to the point I'm trying
to make here.  By making such changes to the GPL license I'd argue
that the FSF is the one playing legal tricks.  One could say that the
FSF was bullying the bully, certainly something funny, but perhaps not
just.  They tried to play a legal move to make us (the open source
community) immune from any patent Microsoft might have against said
GPLv3 software.  And they tried to make it knowing that that was
completely not what was intended in the agreement between Microsoft
and Novell.  That, is a prime example of playing legal tricks.

I have pasted the image you link to in my earliest mail in this
thread.  Please realize that the arrow only points one way.  The GPL
is not willing to share back to MIT, it is only there to take over
what others have published in a license which is much more free.  Like
the MIT license.  In that sense I find the GPL to be a very aggressive
license.  It tries to take freedom away from me.  You are obviously
free, as many others have done, to take MIT software and relicense it
as GPL software.  Though I'd still be wary of releasing it under GPLv3
or any newer version, you might put yourself open to lawsuits in the
future.

>> The GPL *currently* grants you some rights which are presumably
>> included in the long license.  The 'or later' clause makes such
>> statement void though.  The FSF can make incompatible changes.
> "GPLv2 is compatible with GPLv3 if the program allows you to choose
> "any later version" of the GPL, which is the case for most software
> released under this license."
> "We update the GPL to protect its copyleft from being undermined by
> legal or technological developments."
> This may happen with the third version.
> That's why it's important to use the “any later version” part.

I don't think you get my point here.  If you are willing to place all
your trust, forever, in the FSF, then it is a sane decision.  It's
similar to becoming a monk, you devote everything to a single cause.
Looking at history, I see that many people have been deceived by many
great organizations.  While I believe the FSF may be doing many right
things right now, history teaches me that I probably shouldn't assume
that they will do that forever.  That I should trust them to always
defend my rights.

Now if I don't add that clause and I do agree with their next license,
I can manually upgrade the license of my project to the new license.
But I'd like to evaluate the agreement before accepting it.  Just in
the same way as I'd like to see what I'm going to war for, before I
catch a bullet. The GPLv2 and the GPLv3 are incompatible: this means
that I'm essentially allowing my users to do things which I initially
explicitly didn't allow, without me having anything to say about it.
The FSF has effectively lowered the rights I, the developer, have.

>> The license holds in the way a judge will interpret it, not in the
>> way we interpret it.
> That's why the "complexity" of the GNU GPL is better then the
> simplicity of the other licenses.
> That simplicity is ambiguous.

Ambiguous seems to be an odd word here.  The MIT license has clearly
shown that it is not ambiguous at all.  It states what can and can not
be done in terms that a human understands.  I doubt a judge will
interpret it differently than me.  The GPL goes through great lengths
to define what can and can not be done and it tries to find some, in
the FSF's eyes sensible, boundary.  But this has much more ambiguity
to it than the whole MIT license.

An example of ambiguity in the GPLv3.  I quote from [1] "GPLv3 has
adjusted the definition of System Library to include software that may
not come directly with the operating system, but that all users of the
software can reasonably be expected to have.".  "Reasonably expected
to have"...  Well, is a lisp compiler reasonably expected to have?  I
don't know, I certainly don't know how this will be translated by
judges in the various parts of the world.  And is it then allowed,
because the software is ran within that compiler, or maybe more of an
environment.  From a legal point of view these things behave
differently than from a technical point of view.  Seemingly
unimportant details make the interpretation change.  Complex legal
documents tend to create ambiguity.  In the same way as complex
spaghetti code tends to introduce bugs.  The fact that the GPL needs
to be trialed in various countries before we know its real legal value
implies at least some ambiguity on a legal level.

>> RMS states that the interpretation of a
>> judge also suprised him a bit.
> That's why we have the third version. Because it does the job even better.

It'll take us a few years to realize the ramifications.  I think it's
early to say that it does the job better.  Further more, whether it
does 'the job' better is open to interpretation.  The fact that
projects stay under the GPLv2 explicitly indicates that, at least some
developers, tend to disagree on it.

>> The 'or later' clause seems to be, from a legal point of
>> view, the most jarheaded option I've ever seen.
> RMS: "The GNU licenses are the only ones that give developers the option
> of NOT accepting future versions.  Other licenses that have versions
> generally automatically include future versions."

Do you see something about that in the MIT license?  Something about
versions and upgrading.  I think not.  This claim is both extremely
broad and not based on what's currently common in the open source
community.

Aside from that, I find little trust in the following:  RMS is
virtually saying "But...but...but...the others are even worse!", that
still doesn't make it good.  Furthermore, /providing/ the option isn't
necessarily bad, but /taking/ it is.

> You will have an ability to choose the third version if you are
> unhappy with the fourth version.

The license is an agreement between two parties: The user (or
distributor) and the developer.  As a user, I will have a choice.  But
as a developer, I'll be forced to give the user that choice.  I don't
want to be forced.

> "The Free Software Foundation may publish revised and/or new versions
> of the GNU General Public License from time to time. Such new versions
> will be similar in spirit to the present version, but may differ in
> detail to address new problems or concerns.
> Each version is given a distinguishing version number. If the Program
> specifies that a certain numbered version of the GNU General Public
> License “or any later version” applies to it, you have the option of
> following the terms and conditions either of that numbered version or
> of any later version published by the Free Software Foundation. If the
> Program does not specify a version number of the GNU General Public
> License, you may choose any version ever published by the Free
> Software Foundation."
> http://www.gnu.org/copyleft/gpl.html (14. Revised Versions of this License.)

'The spirit of the license' is in itself ambiguous.  If it weren't, we
could just put 'the spirit of the license' in the license and then
state that we need to follow that.  GPLv2 didn't talk about software
patents or locks by hardware restrictions for instance.  At least some
people, like those that built the TiVo, found it to be sane to put a
lock on their device.  It seemed like the code itself would have to be
free forever.  A TiVo competitor could make the same hardware and use
the source of the TiVo whilst doing it, seems like a sensible thing to
do.  The FSF, at least, finds it not to be just.  Other examples exist
though.  Would it be in the spirit of the GPL to require the same
warranties to hold when you run modified code on the hardware which
you bought?  I don't know what your opinion on it is, but it may vary.
 Some will say yes, others will say no.  And of both sides some will
assume that their opinion is in the spirit of the GPL.  The spirit of
the GPL may evolve into something I thoroughly dislike.  So no, I do
not trust any future version of the GPL, nor its spirit, until I've
seen what it contains.  No license which states "we can do everything,
but we'll try to be good" seems reasonable to me.

As a last point it might, perhaps, be interesting to read works which
weren't commissioned by the FSF.  If I'd be in church all day, I'd
undoubtedly believe in God, if I'd only read pamphlets of the Ku Klux
Klan, I'd probably become a racist.  A few works of interest may be
[2], which links to [3].  [3] could be seen as somewhat biased, in the
sense that it doesn't try to defend the GPL, but it does hint at the
tactics which the FSF is willing to take.  Another one is [4] which,
although the title hints at it, doesn't actually portray a strong bias
towards the BSD license.  I'm not assuming either of these works will
make your opinion change, but it may give a bit more perspective.


>
>
> Kind regards.
>


Best regards,

Aad Versteden


[1] http://www.gnu.org/licenses/quick-guide-gplv3.en.html#less-source-to-distribute-new-system-libraries-exception
[2] http://www.itworld.com/it-managementstrategy/233753/gpl-copyleft-use-declining-faster-ever
[3] http://www.itworld.com/mobile-wireless/196001/fsf-uses-unproven-compliance-issue-promote-gplv3
[4] http://www.freebsd.org/doc/en/articles/bsdl-gpl/article.html

> _______________________________________________
> clfswm-devel mailing list
> clfswm-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/clfswm-devel