New license request: DRL-1.1

[kelnage]

Introduction

The Detection Rule License was updated to version 1.1 in May 2021, with the inclusion of a attribution requirement when a rule has been modified (see the commit https://github.com/SigmaHQ/sigma/commit/528be5977cb686e9444b19db126449d7bb4dd12f).

Beyond this, there have been minimal change between now and when the DRL was first approved as an SPDX license (#1075).

License Name

Detection Rule License 1.1

Suggested short identifier

DRL-1.1

URL to license text

https://github.com/SigmaHQ/Detection-Rule-License/blob/main/LICENSE.Detection.Rules.md

OSI Status

Not Submitted

License author or steward

Author: Florian Roth (@Neo23x0); Steward: Nicholas Moore (nicholas.moore@grafana.com)

URL to project(s) that use license

• https://github.com/SigmaHQ/Sigma
• https://developer.socprime.com/home/content-partner-license-agreement/; per this text:

  The Partner Content is sublicensable to Users under the terms of the Detection Rule License (may be updated from time to time), which can be found by following this link: https://github.com/SigmaHQ/sigma/blob/master/LICENSE.Detection.Rules.md, (hereinafter the “DLR license”). By uploading Partner Content, you agree that the Partner Content will be available to SOC Prime and its Users under the DLR license.

[swinslow]

As mentioned in the issue thread, this is identical to DRL-1.0 except for adding the following after clause 3:

If you use the Rules (including in modified form) on data, messages based on matches with the Rules must retain the following if it is supplied within the Rules:

1. identification of the authors(s) ("author" field) of the Rule and any others designated to receive attribution, in any reasonable manner requested by the Rule author (including by pseudonym if designated).

My question here is, what are "messages based on matches with the Rules"? I'm definitely not familiar enough with the underlying project to know what this is referring to.

If it's referring to something external to the "Rules" themselves, I'm a little hesitant to give an automatic thumbs-up here. It would possibly seem to take this outside the normal attribution requirement (i.e., keeping attribution notices in the software and associated documentation itself), and require outputs of the software to also carry notices, in more of a "badgeware" manner (see one discussion of badgeware here).

I'm not saying I'm necessarily opposed, but I'd like to understand more about what this is intended to pick up that extends beyond the existing attribution requirements in DRL-1.0, before saying that this is a simple permissive / attribution-style license for purposes of the License Inclusion Principles.

[richardfontana]

My quick impression is that DRL-1.1 would move DRL from being FOSS or more or less FOSS to something non-FOSS, FWIW (may be relevant to considering the License Inclusion Principles).

[Pizza-Ria]

Not Inclined (agree with above @swinslow and @richardfontana): "If you use the Rules (including in modified form) on data, messages based on matches with the Rules must retain the following if it is supplied within the Rules: identification of the authors(s) ("author" field) of the Rule and any others designated to receive attribution, in any reasonable manner requested by the Rule author (including by pseudonym if designated)."

This sounds like it covers the output of the project which unless it actually embeds the code (or whatever) is part of the project, may not have any copyright connection to the original code. In fact, the Sigma project which uses this license seems to be just a way to format input into a standardized output.

[nasbench]

Hi everyone Nas here. I'm one of the current maintainers of the Sigma project. Just chiming in to clarify the added point in DRL 1.1

One thing that was required from the start when using SIGMA rules under DRL is to always keep identification of the authors(s) and a URI reference the source.

Basically this addition to the DRL ensures that the identification of the authors(s) portion is respected to the maximum extent during matches. These matches include for example when you use a detection rule and it finds something, usually an alert is triggered. This point make sure that the author field must be present during such matches.

This doesn't change anything with the DRL it just makes a certain edge case more clear and enforces it.

Let me know if you require any further info

Cheers.

[jlovejoy]

thanks for the explanation @nasbench

I'm inclined to include this license especially since we included the first version and this update seems to retain or expand the requirement for "acknowledgement"

@swinslow @richardfontana @Pizza-Ria - thoughts?

[richardfontana]

I don't think this license satisfies the inclusion principles because it seems substantially non-FOSS-like to me.

[Neo23x0]

Hi everyone,

I'd like to provide additional context to our ongoing discussion and highlight a few nuances that might not have been fully considered thus far. Detection rules, unlike traditional software, operate in a unique paradigm, warranting special considerations when discussing licensing and attribution.

Nature of Detection Rules vs. Software Traditional software outputs, like a graphical interface or a report, offer natural opportunities to embed or display licenses and acknowledgements. This ensures that users can easily trace back the origin or authorship of the software. Detection rules, however, don't exhibit such directness. Instead, they analyze datasets, like logs, files, or network traffic, and only produce or display matches based on these rules to the end-user. This inherent transformation process often strips away all associated metadata, including author information.

Translational Loss in Detection Rules When detection rules are applied, what the end user perceives is not a direct rendition of the original rule but a translated, processed output. This is akin to seeing the result of a calculation without ever knowing the formula. With standard software, even after compilations or transformations, there are clear avenues to embed license or attribution information, be it in the 'About' section, the software's footer, or its documentation. Detection rules lack such a conventional venue.

The Aim of DRL 1.1 The changes in DRL 1.1 aren't crafted to enforce a splashy display of the author's credentials, akin to what is often seen in badgeware licenses. Instead, the intent is to address the unique attribution challenges posed by the nature of detection rules. By ensuring that matches arising from a specific rule carry the original author's attribution, the license endeavors to give due credit to the intellectual work, especially when that rule aids in crucial detections.

Acknowledging Intellectual Contribution The intellectual contribution behind crafting an effective detection rule can be substantial. The rule, once applied, can reveal significant insights, anomalies, or threats, providing tangible value to users. Given the nature of detection rules, where the rule's structure and metadata can be obscured during application, it's crucial, and only fair, to ensure that creators receive recognition for their work.

In essence, while DRL 1.1 seeks to ensure attribution, it does so to address the specific challenges tied to the nature of detection rules. It isn't a blanket bid to plaster authorship details everywhere, but a measured approach to ensure credit is given where it's due in an ecosystem where traditional attribution methods fall short.

I hope this clarification aids in understanding the license's specific purpose and its unique use case.

Florian

[richardfontana]

Thanks for the explanation @Neo23x0 but I continue to be -1 on adding this to the SPDX License List because I think it does not satisfy the license inclusion principles.

[jlovejoy]

discussed on 9/28 call, going through https://github.com/spdx/license-list-XML/blob/main/DOCS/license-inclusion-principles.md 👍

1) does not comply with OSD 2) is structured to be used by others, but very specific use case 3) does not seem to have substantial use, only used by Sigma (as far as we can tell), but does have 6700 stars and many forks on Github, so could be deemed substantial use in this way 4) is intended for free distribution of content, restrictions are limited 5) yes and text is stable and versioned

decided ok to add (note that reviewing this against current inclusion guidelines caused us to think we might want to revisit them. we have added some clarifications elsewhere and probably need to be consolidate and expanded upon now that we have some mileage with this iteration of the inclusion guidelines - will note in new issue for future discussion)

[jlovejoy]

@kelnage - now that this has been accepted, can you make the PR for this? Note - to be included for 3.22, that would have to happen in the next day (otherwise, it will get in for the next release officially)

see https://github.com/spdx/license-list-XML/blob/main/DOCS/request-new-license.md#accepted-license-process

[jlovejoy]

moving to 3.23 as there is no PR for this yet and 3.22 is about to go out

[nasbench]

I opened PR #2207 with the updated DRL-1.1 content.

[xsuchy]

The PR has been merged. This can be closed.