[clfswm-devel] CLFSWM licence change?

[madnificent]

Hello Philippe Brochard,


On Sat, Jan 14, 2012 at 12:11 AM, Philippe Brochard
<pbrochard at common-lisp.net> wrote:
> Hi,
>
> First I've made CLFSWM under the GPLv2 and then GPLv3 because CLFSWM is
> based on Stumpwm (GPLv2 or later), Eclipse (GPL) and Tinywm (Public
> Domain).
> As explained before, it do not share too much code with Stumpwm and none
> with the two later.

I find it to make total sense to keep the original license around
whilst developing, at least if the license is remotely sane.  Aside
from the "or later" clause, I think it is sane.  Furthermore none of
us are lawyers, so even a bad choice would be easily excused.  It's
like blaming a chipmunk for starting a global nuclear war: I'm fairly
certain the chipmunk didn't know what the impact of his actions were
going to be when he started it.

> My point of view on licence:
>
> I like the GPLv3 because, as a user, it gives me the four freedoms and I'm
> sure to keep them. My code can't be converted in proprietary software. Every
> developer is *constrained* to share its code with us.
>
> The 'or later' close is good for me (as a user) because if the new
> licence version gives me more freedom I can apply the new version
> immediately but if I don't like it, I can use the software in its current
> version.

The 'or later' clause is great as a user!  But I don't intend to only
play the role of user.

> As a developer, the GPL grants me that my code will be always free with
> the four freedoms. I'll not waste my energy with the fear to have my
> code used by others in proprietary software and not shared with us.

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.
Furthermore I think we both understand the license to some extent and
realize that we'll just have to believe what lawyers tell us about it.
 The license holds in the way a judge will interpret it, not in the
way we interpret it.  In [1] RMS states that the interpretation of a
judge also suprised him a bit.  And that comes from someone who's been
rather closely involved in it.  So as a developer, I personally feel I
know fairly little right now, even though FSF likes me to *think* I
know a lot.

> On the 'or later' close, please, read this if not already done:
>  http://www.gnu.org/licenses/gpl-faq.html#VersionThreeOrLater

Yes I have.  Read it too, the ramifications are amazing.  Under the
presumption that the FSF is always right, from now to eternity, it's
just a plain sane choice.  But let's keep in mind that they might not
always be so right, they are human beings.  The FSF can tell you you
should do things differently.  Not only does that give you more
potential to have unfree code, it also opens you up to legal action.
Let me give you an example.  The FSF likes the GPL and they may find
other licenses to be unworthy of existence.  Not everyone would agree
with them, but it's a sane opinion.  A perfectly valid clause in the
GPLv4 would be to state "You are not allowed to dual-license your
code".  I personally wouldn't find that to be all that funny.  But
they *could* state it.  And once someone downloads it, they can say
"hey, I'll pick that".  *BAM* You're not allowed to distribute /your
own/ code in MIT form anymore.  You suddenly have a contract with a
user which states you're not allowed to do this anymore.  The FSF has
shown that they are willing to go through great lengths to make the
world look the way *they* want it to look.  The FSF could also go the
other way and say "You know what, we were wrong all along, we're going
to let everybody do anything with your code." and again, it's not what
you likely had in mind.  It may not be worse, but it's not what you
intended.  The 'or later' clause seems to be, from a legal point of
view, the most jarheaded option I've ever seen.  The only way it could
possibly work is by making naive good people pick it without realizing
the rammifications of their choice.

There is a problem with using the references of AnyCompany(TM) when
talking about the products of AnyCompany, they rarely state the bad
things.  What the FSF has shown us (rightfully) is that making
incompatible changes is something they are willing to do.  They have
also shown that they are willing to change the license to block a
company which they feel is doing something bad (admittedly i disliked
what they did too, but it is still creepy).  As a *user* it is very
fair, but as a *developer* I have no idea what I'm getting myself in
to.  The lawyers at Microsoft/Novell didn't realize what they were
getting themselves into, and as it was about a patent deal, I think
they were rather involved.  Please keep in mind that it is not because
AnyCompany tells you that they are not evil, and that you currently
believe them to be so, that they will /always/ be so in your opinion.
People were once convinced Hitler was doing really good things for
them, many of those people changed their mind later on.

> Maybe a problem with CLFSWM under the GPL is that you have to run CLFSWM
> under a GPL compatible Lisp implementation. But CLFSWM is made to run
> under free software like GNU/Linux or BSD.

You're currently only disallowed to distribute it with said lisp
environments though.  I think it's valid to *run* CLFSWM under a
non-free implementation.  I don't know for sure, a lawyer should take
a look at it (it is scary we need lawyers for such a simple thing as
this).  I don't particularly see a moral problem in distributing
CLFSWM with a non-free lisp either though.  But your opinion on that
may vary.  I guess my main motivation is to help people, regardless of
what they'll do with it later on.

> As stated before I'm not against proprietary software user: do what you
> want. So this restriction may be too heavy.

Not being GPL does *not* mean you're using proprietary software.  It
is all too often implied, but it as far from the case.  FreeBSD, for
instance, is *not* proprietary software.  Wikipedia says [3]:

Proprietary software is computer software licensed under exclusive
legal right of the copyright holder. The licensee is given the right
to use the software under certain conditions, while restricted from
other uses, such as modification, further distribution, or reverse
engineering.

If either MIT or GPL would fall in that category, I'd say the GPL was
the one to fall under it.  The FSF often talks about the badness about
proprietary software and then poses the GPL as an alternative.
Whether or not they do it consciously, it seems to make people believe
that it is either A or B.  So at list the press releases of the FSF
seem to hint toward "You're either with the GPL, or your with evil big
proprietary companies".  But that's simply not true.  It seems very
similar to how the American public gradually started to believe Saddam
Hussein was directly involved in 9/11 without any proof of that being
true.

> This is why I've placed some other Common Lisp projects under the LLGPL
> licence.
>
> On the other side, I like the BSD/MIT licence because they're more
> simple and gives all freedoms to the developer. The 'do what you want
> with the code but keep my author name' is appealing.

The main reason why I like them is because they are so simple.  I can
*understand* them.  I also like the freedom I get in them, both as a
user and as a devolper.  One thing to note about the three clause BSD
license (that's the one which states: keep my name on it) is that it
is incompatible with the GPL (at least with GPLv2, I should
double-check for GPLv3).  The GPL doesn't allow you to require your
name to be always in there.  Fun fact: the GPL license isn't valid for
the license text of the GPL itself either.

> In conclusion: The GPLv3 is good for me (of course :) ) but an other
> licence is maybe acceptable if there is a lot of request in this
> direction.

I think I would publish code under the GPLv3, but with some concerns
over what I'm doing.  I see myself giving in on that front.  I do not
see myself giving in on the 'or later' clause.  I can obviously keep
my edits local and simply not upstream them.  That may make me sleep
better at night.

> Another thing. At its beginning, I've stated that CLFSWM will be
> developed in a fork based method because it's really very personal:
> "Fork it and do what you want with it". There is no configuration file
> at this time and the configuration has to be done with grep on the code :)
> I've changed to a more conventional method because the fork based method
> do not ease the version upgrade: it's hard to follow.

Nice thing about the MIT license is that forking can be done without
legal hassle.  You don't need to think about it: it's all ok.
Virtually the same thing holds with the BSD license, though you must
still think for a second when distributing it in binary form also (ie:
we'd have to add a menu option somewhere which displays the authors of
CLFSWM so it can easily be packaged for binary distributions).


> Best regards,
>
> Philippe

Best regards,

Aad Versteden


PS: It would be great if we could hear from the other authors also, as
they really are the ones that matter.


>
> madnificent at gmail.com writes:
>
>
> [...]
>
>> Dear list,
>>
>>
>> The license change was a request on my end.  I'll try to give a short
>> overview of my understanding of the options and my personal
>> preference.  This is legal stuff, so it takes a while to read through
>> it.  I'm not trying to start a flame war.  Legal issues are complex, I
>> don't claim to know all about it.  If you are a lawyer or judge, feel
>> free to enlighten me.
>>
>>
>>
>> The contenders
>> --------------
>> - GPLv2
>>   GPLv2 basically states that the code itself must be free and must
>> remain free when licensed to others.  It requires that all code which
>> links to this code (in terms of lisp, that's all code in the image) is
>> released under a compatible license.  AFAICT this means you can only
>> use the code in lisps where only code is loaded under a GPLv2
>> compatible license [2]. [1] contains an exemplary case.
>>
>> - GPLv3
>>   GPLv3 basically states that the code itself must /really/ be free.
>> Except, it doesn't really do that.  It also removes your right to use
>> any patents on the software you have provided the license for. I don't
>> see a statement which explicits that this only holds for the portions
>> of the code you wrote yourself, nor do I see something stating that it
>> only holds to patents which you hold yourself.  It's a tad vague for
>> me as a non-lawyer.  Though at least the talks RMS gave about it talk
>> about aggressors and non aggressors, so I guess you might be safe.  I
>> may be missing it, IANAL.  The GPLv3 also clearly shows that the FSF
>> is ready to attack single individual companies by changing the GPL
>> according to their needs.
>>
>> - AGPL
>>   AGPL basically holds itself to the rules of its underlying GPL
>> license but also states that if the software is ran on a server (and
>> it's not distributed), that the source code must also be released.  At
>> least, that's what I make of it.  So this means that you're /really/
>> really free, I guess.
>>
>> - LGPL
>>   LGPLvX drops the requirement that applications which link to your
>> application need to be under the same license.  But this doesn't work
>> for lisp for one reason or another, therefore it seems we need to pick
>> LLGPL to get the same effect.  The LLGPL hasn't had any tests in court
>> AFAIK, but at least someone with some legal knowledge has thought
>> about it.
>>
>> - 3 clause BSD
>>   Both BSD and MIT licenses take a different stance on copyright.
>> Instead of requiring that the code is free, they require that the
>> coder is free.  3 clause BSD states that you can do whatever you want
>> with the software, given that you say where you got it from and that
>> you don't use the names of those that helped write it in the promotion
>> of your product.  It's incompatible with any GPL license, as it puts
>> restrictions on how you can distribute it (being, you can't promote it
>> with the names of the authors).  As a non-lawyer, I think I understand
>> this license.  I can comprehend the letters which are in there and
>> convert them into a logical system.
>>
>> - 2 clause BSD / MIT
>>   In short this says: here's the code, have fun with it.  It doesn't
>> actually require much of anything, you just get the code.  This is the
>> easiest license to understand.  I'm fairly certain that it won't come
>> back and haunt me.
>>
>> - (GPLvX) or any future version
>>   The "any future version" qualifier states that when the FSF creates
>> a new GPL license, whichever shape or form it takes, the user may pick
>> that license as well.  This sounds like a smart idea, because it means
>> that users can get the benefits of any future version of the GPL.
>> Stop.  This means that *users* can pick any future version of anything
>> that the FSF deems fit later on.  Contemplate on this for a second.
>> It means you'll have to comply with anything the FSF makes up for you
>> in the future.  Like say, you, the programmer, must defend the code in
>> any copyright claims or lawsuits placed against those using the code.
>> Or, just for the whack of RMS's dream, all other code you write must
>> be released under the same license.  Perhaps a future version of the
>> GPL will state that MIT was good enough all along.  Maybe the FSF is
>> in need of funding and finds it funny to require money from you in
>> their later licenses.  Perhaps it'll state that the BigCorp which
>> bought the FSF feels that they are entitled to the code without giving
>> anything back.  Or just, to give you a choice, all your base are
>> belong to us.  Anything goes.  IANAL, but that's basically what you're
>> saying.  Anything.  The free software foundation has (perhaps
>> rightfully, yet still) targeted individual contractors in their
>> licenses.  What this states is that, if RMS goes whack, you're
>> prepared to go mental with him.  I have yet to meet the first person
>> with whom I agree on everything, every time.  A common answer is "but
>> it won't get that far", yet sadly written agreements are only
>> important when things go wrong.
>>
>>
>>
>> What we have now
>> ----------------
>>
>> Currently CLFSWM is released under the in my opinion ludicrous GPLv3
>> or any future version.  I have stated my dislike for the 'or any
>> future version' portion in the previous section, I think I have made
>> my point there (you are free to disagree).  While this license
>> certainly has the marketing and legal machine of the FSF behind it,
>> many big projects have explicitly chosen to stay away from it.  One
>> notable project is the Linux kernel, but there are many many others.
>>
>> There are several issues with the GPLv3 for us.  None of the code in
>> the project can, AFAICT, be distributed in non-free lisps.  Though
>> again the subject is a bit hazy as any code "which users are
>> reasonably expected to have" do not need to fall under the same
>> license, seriously I have no idea where that line is drawn.  Even if
>> the users would want to share the code to get CLFSWM working on those
>> lisp implementations, they are not allowed to do so.  I don't use
>> non-free implementations myself, but I prefer to have the choice.  I
>> want to be left free as a programmer.  Again, I'm not certain of this,
>> I don't fully understand the GPLv2, let stand the GPLv3.  Just look
>> online about the vast amount of writing there is on the interpretation
>> of the GPLv3, it's normal that I don't.  That probably means that it
>> has been researched, but it also means that I don't know what I'm
>> getting into.
>>
>> And that's my main issue against the GPL.  I don't understand the
>> license.  It is *way* too complex for my tiny little brain to
>> understand.  I thought I understood, but then I read [1] and suddenly
>> I realized that I don't understand it at all.  The last thing I want,
>> is give code /for free/ to people I don't know and get sued for things
>> I don't understand.  It scares me.  It really does!  I don't even know
>> what I'm allowed to do in the contributions directory.  I don't want
>> to get sued in the future for the code I write and I don't even know
>> if I'm actually allowed to release under the MIT license in there.
>> You may think you know, but I'd prefer to hear it from a seasoned
>> lawyer before I take my bet on it.
>>
>> Lastly, I don't think you really have to hold a gun against someones
>> head and shout at them "NOW BE FRIENDLY BIATCH!", you can learn to be
>> friendly and share with each other without the odds of getting tasered
>> in the sack.  In fact, I don't think they really call it sharing when
>> you ask for someone on the street to 'share' their iPad with you when
>> you're pointing a gun at them.
>>
>>
>>
>> What I prefer over all else
>> ---------------------------
>>
>> I prefer to understand what I'm opening myself up against.  And that
>> means that I prefer the MIT license.  I understand the MIT license.
>> If there were anything simpler than that which allows others to use,
>> extend and share tho code, I'd probably pick that.  Chances are
>> extremely slim that a company is going to get rich on the code base of
>> CLFSWM.  So why limit the options of our users?  Why raise the chance
>> of getting sued for something you don't understand?  I don't see the
>> benefits of a less liberal license here.  Your opinion may obviously
>> be different.
>>
>> Perhaps it pollutes the ideal of a world full of GPL software.  I
>> personally believe that a lot of great ideas would never be formalized
>> into software, if they'd need to open up their source.  The
>> proliferation of online services is a hint towards this.  Obviously,
>> it is nothing more than an assumption.  I have no studies to back it
>> up.  I also believe that companies do give back to the community when
>> their changes don't provide them with a tactical advantage.  It is
>> simply more cost-effective to send patches upstream.  Monetary gain is
>> something companies tend to understand, risk is something they tend to
>> avoid.  Though again, CLFSWM will most likely not be confronted with
>> this issue anyways.
>>
>> Given that users are more inclined to /share/ extensions than to keep
>> them for themselves, it may even help the development of CLFSWM
>> itself.  Say that the hook system is separated into a standalone
>> library.  Other players which don't use CLFSWM may use it in their
>> systems, even if they were proprietary.  The advancements which they
>> make into the hooks system can, and likely will, still be shared and
>> thus make CLFSWM better than what it is.  This is obviously not
>> exclusive to CLFSWM.
>>
>> Lastly, I really want the users to be free.  If they want to
>> spray-paint tables with it: enjoy!  I don't care what you do with it.
>> If you want to print it and flush it down the toilet: fine!  I hope it
>> makes you smile.
>>
>>
>>
>> The complex legal situation
>> ---------------------------
>>
>> Given the fact that some code has been used from the stumpwm project
>> and some other code has been used from other projects, you have to
>> thoroughly consider what needs to happen in order to keep everything
>> working and legally sound.  Or at least something that seems legal.
>> Any change (including the one in which you pick GPLv2 libraries and
>> put them in a library which is under the GPLv3) needs to be studied
>> before claiming that you can just pick the code and alter the license.
>>  It could be that some parts need to be rewritten or split off.
>>
>> Splitting things off brings us to another interesting subtopic.  Due
>> to QuickLisp it has become a lot simpler to split up a single
>> application into multiple systems and packages (besides, it could be a
>> single tarball to download without QuickLisp too).  Currently most of
>> CLFSWM seems to be in a single package, everything is in one system.
>> Various systems can have various licenses.  Perhaps this could ease
>> the transition towards a more liberal licensing scheme and perhaps it
>> could make us use and share more open code (like Alexandria).
>>
>>
>>
>> A common ground
>> ---------------
>>
>> As I have heard, some of the users on this list are heavy proponents
>> of the GPL.  A common ground is obviously the LLGPL, as it at least
>> gives users the freedom to have a bit of freedom in what they want to
>> do with the libraries.  I don't fully understand the license and thus
>> it still scares me off, but it would make me feel less uncomfortable.
>> A scheme in which multiple licenses are used for various portions of
>> CLFSWM seems like a viable option for me too.  Anyone using the full
>> CLFSWM system will then be forced to use the most oppressing license
>> (GPLv3 or later), for various smaller portions the compatible MIT
>> license could be used.  By all means, I do suggest we drop the "or any
>> future version" of the license we have now.  If you want to allow
>> swift upgrades, then the only sensible thing to do is to give all
>> rights to the code to Philippe Brochard and let him take the
>> responsibility of upgrading the license when necessary.
>>
>>
>>
>> It would be absolutely awesome if I could hear each contributor's
>> preference and the reason for his preference!  I'm eagerly waiting to
>> hear from all of you.
>>
>>
>> Best regards,
>>
>> Aad Versteden
>>
>>
>>
>> [1] http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-is-under-GPL
>> [2] Practically speaking, GPLv2 is only compatible with 2-clause BSD,
>> which is the same as MIT, or other (L)GPLv2 code.  AFAIK GPLv2 and
>> GPLv3 are incompatible.  Kindergarten psychology tells me pictures
>> work better: http://www.gnu.org/licenses/quick-guide-gplv3-compatibility.png
>> Expat is the name the FSF uses for what everyone else calls the MIT
>> license.
>>
>> _______________________________________________
>> clfswm-devel mailing list
>> clfswm-devel at common-lisp.net
>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/clfswm-devel
>
> _______________________________________________
> clfswm-devel mailing list
> clfswm-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/clfswm-devel

[3] http://en.wikipedia.org/wiki/Proprietary_software