current license creates uncertainty

[stevegt]

Licenses are code; tricky to the point of being analogous to cryptographic algorithms. Writing a custom one often creates unintended consequences. For instance, as currently worded, even with the best of intentions, a web developer might deploy the package believing themselves to be in full compliance with the license, then later learn that a site user is non-compliant; this new knowledge causes the developer to become immediately non-compliant.

Other than a return to a standard MIT license or one of the others listed at https://pkg.go.dev/license-policy, I don't have any good suggestions for what to do about this; I don't know of any standard open-source licenses that satisfy the full intent of the current license. That doesn't mean there aren't any -- the JSON license, for instance, is on the pkg.go.dev list, and is an MIT derivative that tries to do the right thing. Here's a related conversation on a stack exchange site that covers some of the issues in more detail: https://softwareengineering.stackexchange.com/questions/199055/open-source-licenses-that-explicitly-prohibit-military-applications

[pjebs]

Thank you for pointing out the json license.
I don't have the time to think about it yet I'll have another reconsider in the medium-term future.