Subject: Re: Apple violating git LGPL?

From: Jeff King <[email-masked]>
Date: Wed, 6 Aug 2014 16:51:45 -0400

On Wed, Aug 06, 2014 at 12:53:56PM -0700, Bruce Ferrell wrote:

> On 08/06/2014 11:43 AM, Jeff King wrote:
> 
> snippage here 8< >8
> >As it happens, though, they _do_ modify the git that they distribute. I
> >know at least that they bake-in the osxkeychain helper config in away that
> >the user cannot turn off. There may be more changes, but I haven't done a
> >full diff. And they do provide the source:
> >https://www.opensource.apple.com/source/Git/

> Is that a plugin?  if not what about proprietary plugins? How are they
> affected by the license is this case?

I don't know exactly what you mean by "plugin" here.

osxkeychain is a separate program found in git's contrib directory.  You
point git at it by setting your credential.helper config to
"osxkeychain". However, in the Apple version, they have hardcoded that
config into the git binary, and you can't turn it off (you can add
additional helpers, but you can't undo the keychain helper). So I don't
think there is any licensing question about what they have done[1].

I do not know offhand of any proprietary credential helpers.  They do
interact with git over a pipe, and their primary function is to feed
data to git. My understanding is that there are some people who believe
that makes them derivative works of git (i.e., that talking RPC over a
pipe to avoid linking does not get around the GPL), but there are others
who would consider them separate programs.

-Peff

[1] Whether what they have done is smart is another matter. I looked at
    the diff Apple's Git-48 and v1.8.5.2 (on which it seems to be
    based).  There aren't a huge number of changes, but some of them
    baffle me. Why bake-in credential.helper when you can set it in
    /etc/gitconfig? Why default core.trustctime to false when you can
    set it via /etc/gitconfig?  Etc. I wish they would work with the
    configurability tools that we already provide, and if those are not
    sufficient, work with us to make git more configurable. But AFAIK
    whoever is responsible for those changes has never participated on
    the mailing list.