15

After launching an upgrade of XCode on a MacOS Sierra, calling git in a terminal suprisingly results in:

$ git


Agreeing to the Xcode/iOS license requires admin privileges,
please re-run as root via sudo.

and the command quits. This happens no matter what option git is given, including none or --version. The command used to work normally before this upgrade.

I don't see how it's legit to do that. According to git README:

Git is an Open Source project covered by the GNU General Public License version 2 (some parts of it are under different licenses, compatible with the GPLv2)

This git binary is located in MacOS /usr/bin, so it's from Apple as far as I can tell.

EDIT: once the license is agreed upon, git --version confirms it:

git version 2.10.1 (Apple Git-78)

It seems to me that forcing users to accept an incompatible license to be able to use a GPL software contradicts the GPL, for instance section 2b or section 6:

  1. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
  1. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

I assume that Apple has technically tied git (and I believe other free-licensed command line tools) to its Xcode closed-source product (which I don't really know or use directly, I develop with Qt which depends on it), in a way that you can't use them until you accept the license of what they see as the "main product", the container.

Does that practice effectively violate the GPLv2?

Related questions on https://apple.stackexchange.com/

About strings applied to the binary: strings /usr/bin/git on MacOS curiously doesn't produce anything, but the strings commands from linux binutils extracts 94 lines from it, which are mostly related to Apple and licensing.

Those that consist of readable text are essentially:

com.apple.git
com.apple.git
Apple Inc.1&0$
Apple Certification Authority1
Apple Root CA0
Apple Certification Authority1301
*Apple Code Signing Certification Authority0
https://www.apple.com/appleca/0
Reliance on this certificate by any party assumes acceptance of the then applicable standard terms and conditions of use, certificate policy and certification practice statements.0
*Apple Code Signing Certification Authority0
Apple Inc.1
Apple Software1
Software Signing0
)http://www.apple.com/certificateauthority0

It seems that this binary (which is very small: 18KB) is only about checking the license stuff, and then it launches another binary which would be the real git. I could not dtruss /usr/bin/git (permission problems), but there's a 1.8MB /Library/Developer/CommandLineTools/usr/bin/git that seems to be the real thing.

Improve this question
4
  • Could you tell what is the output of running which git and what is the type of the /usr/bin/git by running file /usr/bin/git and eventually if this is some text file tell us roughly what this file looks like (e.g which scripting language, etc)?
    – Philippe Ombredanne
    Commented Jan 17, 2017 at 8:25
  • See also stackoverflow.com/questions/26197347/…
    – Philippe Ombredanne
    Commented Jan 17, 2017 at 11:43
  • @PhilippeOmbredanne: which git gives /usr/bin/git and file tells it's a binary: /usr/bin/git: Mach-O 64-bit executable x86_64
    – Daniel Vérité
    Commented Jan 17, 2017 at 12:07
  • 3
    Could you check with strings /usr/bin/git | less if this contains some typical strings for the git exe such as git [--version] [--help] or similar?
    – Philippe Ombredanne
    Commented Jan 17, 2017 at 14:59

4 Answers 4

Reset to default
10

Apple is generally very good at being on the verge of legality regarding open source / free software. And they have enough lawyers so that I would be really surprised if one found a clear violation.

You might be aware that section 2b that you cite talks about derivative works but does not prevent "mere aggregation" in a collection of software. It could very well be that when you are calling the command git, you think that you are calling the program that you are used to but in fact are calling some command developed by Apple which asks you to agree with the license of the Xcode/iOS collection before effectively calling the real software. This would not be a modification of git and therefore would not be a violation.

EDIT: this seems to be confirmed by the information you added to your question:

It seems that this binary (which is very small: 18KB) is only about checking the license stuff, and then it launches another binary which would be the real git. I could not dtruss /usr/bin/git (permission problems), but there's a 1.8MB /Library/Developer/CommandLineTools/usr/bin/git that seems to be the real thing.

You could try to add /Library/Developer/CommandLineTools/usr/bin/ in the front of your $PATH to confirm that you can use the real command without agreeing to any license.

END OF EDIT

As for section 6, I am sure that Apple complies with this by providing all the required information somewhere (on your machine). It does not effectively imposes further restriction on the use of the software because they very likely provide the source somewhere and you can compile this source yourself and use it without agreeing to any license.

Finally, this is not really related to this question but I think you can also install git in various other ways on a Mac. For instance via homebrew I suppose (but I'm not a Mac person).

Improve this answer
3
  • 5
    Just confirming that you can install git via homebrew, and it's the generally-recommended way of staying up to date with it.
    – Xiong Chiamiov
    Commented Jan 17, 2017 at 16:45
  • 1
    In the end I think it's a judgment call wether Apple's /usr/bin/git imposes further restriction on the use of the software and thus complies with section 6, and if I was the judge I'd say they ought to remove it completely to clear the path to the real git.
    – Daniel Vérité
    Commented Jan 26, 2017 at 10:16
  • any guesses on WHY apple wants to do that? do you see any connection to zsh?
    – mireille raad
    Commented Mar 10, 2020 at 2:18
4

Based on the latest update to your question and the research you made, it seems that /usr/bin/git is NOT an executable from git proper but a wrapper created by Apple that would then likely call and spawn the real git at /Library/Developer/CommandLineTools/usr/bin/git.

This git wrapper seems to be a signed executable and it asks for some Xcode license acceptance. This is perfectly OK to do this and this should not preclude you to execute the real git at /Library/Developer/CommandLineTools/usr/bin/git.

I reckon this is weird, impractical and byzantine, but from the face of your facts gathering this does not seem to contradict any of the GPL terms for git.

Improve this answer
1

It's possible that they consider their terminal to be part of xcode, and that they want you to agree to their license before you use their terminal in certain ways. They cannot condition your use of Git on agreement to any other kind of license, but they don't need to provide you the terminal that git runs on, or the operating system beneath that.

Improve this answer
-2

First, Git is not being packaged or redistributed here for the terms of GPL conditions to get it enacted.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.