git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Bruce Ferrell <bferrell@baywinds.org>
Cc: Robert P Fischer <rpf2116@columbia.edu>, git@vger.kernel.org
Subject: Re: Apple violating git LGPL?
Date: Wed, 6 Aug 2014 16:51:45 -0400	[thread overview]
Message-ID: <20140806205145.GB22592@peff.net> (raw)
In-Reply-To: <53E287D4.1050106@baywinds.org>

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.

  reply	other threads:[~2014-08-06 20:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-06 18:10 Apple violating git LGPL? Robert P Fischer
2014-08-06 18:36 ` Charles Bailey
2014-08-06 18:43 ` Jeff King
2014-08-06 19:53   ` Bruce Ferrell
2014-08-06 20:51     ` Jeff King [this message]
2014-08-06 20:23   ` Tony
2014-08-06 20:41     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140806205145.GB22592@peff.net \
    --to=peff@peff.net \
    --cc=bferrell@baywinds.org \
    --cc=git@vger.kernel.org \
    --cc=rpf2116@columbia.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).