[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please, no GitHub

From: Gregory Casamento
Subject: Re: Please, no GitHub
Date: Sun, 13 Dec 2015 01:26:50 -0500

A slight correction, before certain pedants swing in to "correct" me.
 GNUstep uses LGPL2.1+ for the libraries and GPLv3+ for the

On Sun, Dec 13, 2015 at 12:09 AM, Gregory Casamento
<address@hidden> wrote:
> 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 <address@hidden> wrote:
>>> On Dec 13, 2015, at 10:57, Gregory Casamento <address@hidden> wrote:
>>> Maxthon,
>>> On Sat, Dec 12, 2015 at 4:32 AM, Maxthon Chan <address@hidden> 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/

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]