Thanks to @Neo23x0 on Twitter I became aware of the DRL - I am now somewhat embarrassed discovering it is over a year old and I am only now discovering it. Now that I read it I have some thoughts / suggestions... I am not sure if these should be tracked as separate issues or not, I will gladly break this apart if you want.

First comment - I agree / endorse the issue SigmaHQ/sigma#1417 strongly (wording may need to be adjusted) as currently the licensing situation of the repository is ambiguous.

Second comment - I would suggest considering adding an explicit patent grant to the DRL. Currently, as it is MIT based and not Apache based, there is no explicit patent grant. The problem with this is while we may wish they were not, the detections expressed in rules are patentable. A patent grant helps in two ways. First, by adding a patent grant it protects the repo and it's consumers from submarine patents / patent trolls. ( Yes the MIT license has an implicit grant, but explicit is much safer - ref: https://opensource.stackexchange.com/questions/7964/why-is-the-apache-license-2-0-patent-license-clause-useful-important). The second, is that as detections that are shared get more and more complex (think: Jupyter notebooks being shared among tools), patents and the IP law around them will get more important. Having the DRL be robust to many types of detections will lead to it being used outside Sigma and increased awareness, which is a good thing for it's long term health.

Final comment - I believe the DRL as it is written has some large loopholes. The first thing I notice is it does not cover derivative works, which would include the output of sigma's own toolchain. All one has to do to get around the DRL, is to ship the converted form of the rule to any other format, instead of the rule itself, and it no longer applies. Another problem/loophole I notice is the DRL does not specify where or how this credit must be given. You could comply with this license by having the credit be given in an obscure HTML file that ships with the product, and never show it anywhere in the GUI at all. There was an infographic shared on Twitter that said "matches have to include the author of the rule" - that is not actually required to comply with the license as written. There is probably language change needed to something sort of like this:

If you share the Rules (including in modified form), you must retain the following if it is supplied within the Rules:

to

If you use the Rules (including in modified form), you must retain the following information if it is supplied within the Rules, as well as make such information clearly noted alongside any machine-generated output that results from said usage of the Rules:

I will close this with "I am not a lawyer" - however if you would like I could get some IP attorneys to help with this.... I am not sure if any were involved in the original creation... we have some solid ones :) LMK...

Previously, the DRL-1.0 was submitted to and accepted by the SPDX as a license (see the submission and the current license page). Given the DRL has been updated to 1.1, I'd like to submit the new version of it to the SPDX; this would make it easier to associate it clearly with GitHub repositories (such as SigmaHQ/sigma) and may encourage wider uptake of it.

I'd be happy to act as the Steward for the submission, but I wanted to check that there were no issues with me doing so before I went ahead (particularly @Neo23x0, as the license author), and that weren't any forthcoming planned updates that might make this redundant?