Create a list of common conditions.

[aiuto]

It should be small and unambiguous in favor of comprehensive.

• notice
• requires_relinkability
• unencumbered

Maybe more.

[aiuto]

From #21: @aiuto: Questions for review.

• Should we have by_exception_only?
• I don't particularly like restricted_if_statically_linked. I would prefer to say requires_relinkable_library, or something else that states the condition you must fulfill, rather than the prohibition you are likely to have.

@danielmachlab: I think we should include it because, although by_exception_only may be needed more rarely, it is a generic license that would be useful to many open source projects or organizations that decide to depend on these license_kind declarations (even though private organizations will probably define their own). Additionally, it seems that there are cases where it is useful to combine restricted and by_exception_only: https://opensource.google/docs/thirdparty/licenses/#combinations-of-restricted-and-byexceptiononly-code

w.r.t.: restricted_if_statically_linked You make a good point here about the value of stating the condition that must be fulfilled instead of the prohibition you are likely to have. The answer in my mind could really go either way or even to a third alternative. It seems that restricted_if_statically_linked implies restricted_unless_dynamically_linked, where restricted_unless_dynamically_linked states the condition that must be fulfilled.

Probably a good idea to get a third opinion on this question if possible. @aiuto: Yes. I could start a thread with our compliance team. You could do the same at your company.

Another way to phase the condition might be `requires_dynamic_link_for_distribution'. That gets rid of the word "restricted", which is a very loose one. Restricted to what? From using it in your company? From use in the EU? From export?

That said, "distribution" is still a little too loose for comfort. Does it mean distribution to anyone else but the person who compiles it? Does it mean people outside your company? Does it mean paid customers? Does it mean someone can access it over the internet, even it if is wholly running on your own server. I think it is important to steer clear of things that could be confused with the AGPL taint.

But this brings us back to maybe the very ambiguous "restricted" is more useful in practice. We use restricted to mean that you can not ship without getting approval from your compliance team. Each org can set their own policy on various restricted_* conditions. So some can be auto-allowed.

Perhaps the right thing to do is not add this in this PR. Only do the none, notice, unencumbered, which have clear meanings. Then we can have a long and leisurely discussion of the more difficult cases. Any conditions we add we have to live with forever, so I don't mind taking as much time as needed to create each.