4 ms·

FWIW, going with Apache 2.0 is/was a mistake. There is a clause in the license which implies that almost everybody who uses GitHub/GitLab/etc. to work on an Ap

FWIW, going with Apache 2.0 is/was a mistake. There is a clause in the license which implies that almost everybody who uses GitHub/GitLab/etc. to work on an Apache 2.0 project in the common workflows is in breech of the license. Specifically, the license says that every file with modifications has to include a corresponding notice that the file was changed. Nobody does this in practice. Unfortunately the license is simply badly written. Licenses like the GPL don't have this problem because they only require that a modified version of the software is clearly marked as such without stating how that marking should be done. So the metadata contained in the Git history should be enough to satisfy those superior licenses.

vadfa 5y ago
>Specifically, the license says that every file with modifications has to include a corresponding notice that the file was changed. Nobody does this in practice. Can't you achieve this easily with a git hook or something like that?
- bmn__ 5y ago
  It can be achieved easily by manually editing the file. This is not the problem. People are in violation of the licence not because it's bothersome to produce the notice, but because they are unaware of the clause.
est31 5y ago
Yeah it's horrible how Apache 2.0 has become an industry standard with this clause in place. I think this industry standard status was the main reason why LLVM has chosen it.
- minitoar 5y ago
  If the corporate lawyers all agree it’s a standard and they don’t care about that clause then going with the license that the lawyers are all comfortable with seems like absolutely the right choice.
  - xbar 5y ago
    Very likely. But someday, some lawyer may litigate. Woe betide us all.
geofft 5y ago
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.

vadfa 5y ago

>Specifically, the license says that every file with modifications has to include a corresponding notice that the file was changed. Nobody does this in practice. Can't you achieve this easily with a git hook or something like that?

bmn__ 5y ago
It can be achieved easily by manually editing the file. This is not the problem. People are in violation of the licence not because it's bothersome to produce the notice, but because they are unaware of the clause.

est31 5y ago

Yeah it's horrible how Apache 2.0 has become an industry standard with this clause in place. I think this industry standard status was the main reason why LLVM has chosen it.

minitoar 5y ago
If the corporate lawyers all agree it’s a standard and they don’t care about that clause then going with the license that the lawyers are all comfortable with seems like absolutely the right choice.
- xbar 5y ago
  Very likely. But someday, some lawyer may litigate. Woe betide us all.

geofft 5y ago

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.