While I agree the license is badly written, I think you can construct an argument that the common workflows do not violate the license: - 4.b says, "You must c

While I agree the license is badly written, I think you can construct an argument that the common workflows do not violate the license: - 4.b says, "You must cause any modified files to carry prominent notices stating that You changed the files." When you modify the file using Git (etc.), the file is stored in the Git database in such a way that it can only be accessed indirectly, by going through an object (a commit) whose entire purpose is to be a record and notice of your modification. That seems pretty prominent. - 4.c obligates a redistributor like GitHub (etc.) to "retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work." But the prominent notice was never in the Source form of the Work, it was in the Git metadata. Consider the analogy to the patch-based workflow: if you email a patch to a mailing list, you satisfy 4.b because the email itself serves as a prominent notice, but 4.c would not obligate the maintainer receiving the email to add the information in the email (such as the From: header) to the Source form. They could just apply the patch as given. This is a somewhat strained reading, to be fair, and it'd be nice to standardize a fewer-clause version of the Apache license à la the fewer-clause versions of the BSDs. It seems to me that the Apache license minus 4.b, 4.c, and 4.d would clearly be a FOSS license by any standard that accepts the existing Apache license.