Neo23x0
commented
3 years ago I've just discovered this old discussions entry. It's problematic that I get between 20 to 40 notifications from Github each day. I must have missed this more important one back than in May. We've clarified the last point in DRL version 1.1, but the "patent granting" issue and the "derivative works" are still open.
I think that we'll close these holes in version 1.2 some day. Until then, I think I could create a shitstorm that is unpleasant enough in case someone uses the work of the community in some shady or unethical way.
JasonKeirstead
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...