Re: Please, no GitHub

[Gregory Casamento]

Maxthon,

Please see my answers below.   It should be noted that I don't
necessarily agree with all of the FSF's policies, but I am simply
trying to get you to understand the argument from the a Free Software
perspective.

On Sat, Dec 12, 2015 at 11:19 PM, Maxthon Chan <xcvista@me.com> wrote:
>
>> On Dec 13, 2015, at 10:57, Gregory Casamento <greg.casamento@gmail.com> 
>> wrote:
>>
>> Maxthon,
>>
>> On Sat, Dec 12, 2015 at 4:32 AM, Maxthon Chan <xcvista@me.com> wrote:
>> < snipped for brevity... >
>>>
>>> They exposed **every single** site functionality through the API (in fact,
>>> the Web interface itself uses the API to do its business, so it is safe to
>>> say that https://github.com/ is no more than one of the several available
>>> front-ends for https://api.github.com/) so https://api.github.com/ is
>>> satisfying this criteria.
>>>
>>
>> I believe you are egregiously and entirely missing the point regarding
>> what Richard is saying.  Whether or not GitHub exposes the
>> functionality of the site via the API is COPLETELY immaterial to the
>> argument regarding whether or not it should be used according to the
>> FSF's rules.
>>
>> GitHub as a whole does not satisfy their criteria and that is what the
>> argument is about.
>>
>> The unfortunate part of this is that GitHub has been successful at
>> achieving a great deal of notoriety and going anywhere else would be
>> considered "obscure.”
>
> My point is that the website you see at https://github.com URL is not the 
> actual component of Github that handles the business. It is 
> https://api.github.com/ that does all the heavylifting.

Most people use the API through the web interface which is Non-free.
That's the point here.   To do so they will need to run obfuscated JS
in their browser.  This causes GitHub to fail even the C0 rating of
the repo criteria.   Which is terribly unfortunate.  I suspect that
changing it so that it would at least come in at C0 would be
relatively easy, but then again... I'm not working for GitHub, so I
have no clue.

You could actually argue that we don't have to use github at all and
could simply use git from the command line.   The worry here is that
putting GNUstep on GitHub will encourage the use of the offending
front end by people who do not know how to use the API and thus it
could be seen by the public at large as an endorsement by the FSF of
GitHub's practices.

I hope this makes it clear, because I am finding it difficult to be
more explicit than this in my explanation.

>>> Their website and API are license-blind. Github have a “choose a
>>> license” website that put GPL at the same level of recommendation as
>>> Apache 2.0 and MIT/X11 license. Due to **practical reasons** people
>>> are **avoiding** GPLv3 (you may need to check the reason why folks
>>> are doing this, or GPLv3 will soon become the license of past,) so their
>>> recommendation is GPLv2+ for GPL.
>>
>> I'm wondering where you get this impression.  GPLv3 is not being
>> avoided by any means:
>>
>> http://techrights.org/2007/10/27/gplv3-growth-palamida/
>> http://www.cnet.com/news/gplv3-hits-50-percent-adoption/
>
> You may want to check more recent data. World economy, and hence people’s pay 
> checks and donations, changed a lot from pre-crisis 2007 to in-crisis 2015.

Ahem.... you were, uh... saying?

https://www.blackducksoftware.com/news/releases/2009-06-30
https://en.wikipedia.org/wiki/GPLv3#Version_3

GPLv2.x has a larger degree of adoption than v3, mainly because it has
been around longer.  Additionally much software  is licensed as
GPLv2.1+ (or later).   So, I'm not entirely sure where you're coming
from.

I find the whole debate about licenses to be unnecessary in this
context in the first place.  It seems an argumentative tactic to
distract from the actual issue.

>> A person is entitled to their own opinion, but not to their own facts.
>> The fact of the matter is, GPLv3 is extremely relevant when it comes
>> to fighting patents as well as many other things.   While I,
>> personally, am no fan of it's incompatibility with GPLv2 (as it
>> adversely impacts some GNUstep apps due to those authors being
>> unwilling to re-license or even add a "or later") I do understand what
>> it's purpose is and why it's important.   So, please, don't lie to
>> yourself or spread misinformation about it being a "thing of the past"
>> as it certainly isn’t.
>
> The Linux kernel, probably the single biggest GPL-licensed codebase, is 
> GPLv2-only. GnuTLS, being another GNU package, relicensed itself, from 
> LGPLv3+ to LGPLv2.1. And as of now the most popular free license is MIT/X11 
> and then followed by GPLv2, and then the list goes: Apache 2.0, 3-clause BSD 
> then finally GPLv3. Please explain why the bulk of GPLv2-licensed projects 
> are not moving to GPLv3.
>

Many of them are.  Many are not.  It is currently more advantageous to
stay GPLv2.1+ or LGPLv2.1+ (the + denoting "or later") as this allows
the user more freedom and, additionally, allows the software to be
compatible, license wise, with a larger set of projects which are
GPLv2.1 only/LGPLv2.1 only.   This is precisely why GNUstep stayed at
LGPL2.1+.  We found that moving to LGPLv3 would damage our ability to
use many of the libraries we depended upon since they were
LGPL2.1-only.

Your argument of popularity is a non-sequitur.  It doesn't matter one
bit how popular a license is, that doesn't make it the best one to
use.   The debate here is about Free Software.  MIT, while a "Free
Software" license is too permissive as it will allow someone to take a
MIT licensed codebase and close it.  This is not in line with second
of the four freedoms (see here:
http://www.gnu.org/philosophy/free-sw.en.html) as it could allow
someone to create a version of the program which does not allow the
user to inspect how it works by looking at the code.

> Also why more and more people are moving away from GPL-licensed GCC compiler 
> in favour of a permissive-licensed LLVM/clang compiler? Apple stopped 
> contributing their change back since GCC relicensed to GPLv3+.

You're drawing a false parallel here.  One of the attractive features
of LLVM/clang is it's support of allowing the parser to be used
separate from the compiler.  LLVM has separated out many of its
components to be useful elsewhere.     GCC, honestly, lacks this
capability and does so on purpose.

There have been discussions about doing this in GCC to provide similar
functionality, but I'm not sure if those discussions ever led
anywhere.

Additionally Apple did this, not because of the license, but because
they were already developing LLVM/Clang.  The clang parser libraries
are at the heart of Xcode's ability to colorize syntax, find errors
while typing and make suggestions for corrections while the user is
working rather than at runtime.  This is a powerful feature which GCC
is not currently capable of due to it's architecture as described
above.   The issue of Apple and other companies switching from using
GCC to LLVM/clang is much more complex than JUST GPLv3.

Anyway, as I said, it is not really useful to start a flamewar about
licenses here.

GC
-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/