Contributing

Logline is an independent, SPL-compatible log platform. It is not affiliated with, endorsed by or sponsored by Splunk. The rules below keep it independent. They apply to code, comments, tests and test data, docs, commit messages, issues and pull requests.

The engineering conventions (Go version, tests, golden files, commit style) are in TODO.md, "Working on it". DESIGN.md section 5.5 explains why these rules exist, and section 13 lists the questions still open for counsel. These rules are project policy, not legal advice.

Rules for SPL compatibility work#

1. Don't use Splunk software or accounts for this project. Don't install, run or inspect Splunk Enterprise, Splunk Free, a developer or trial license, Splunk Cloud, a forwarder, or an app or add-on (the CIM add-on included) to build, test, troubleshoot or check anything here. Don't use a Splunk account, your employer's included, to see how a query behaves for this project. Splunk's General Terms (section 1.2) prohibit using its offerings to develop, test, troubleshoot, support or market competing software, or testing them for competitive purposes. Knowing SPL from your day job is fine; running something on a Splunk instance to settle a question here is not.

2. Expected results come from public documentation and reasoning. Read Splunk's public documentation, reason out what the query must return over the fixture data, and review the corpus expected.json from a real ClickHouse run against that. If the documentation leaves a behavior open, write down your reading: in the code comment, and under "Uncertain semantics" in the pull request, with a link to the page you read. Once a difference from Splunk is known, add it to docs/COMPATIBILITY.md as a known deviation.

3. Don't copy Splunk documentation text into code, comments, docs, test data, commit messages, issues or pull requests. Write it in your own words and link the page instead. The names that compatibility depends on are fine: commands, options, functions, fields and time modifiers. Descriptions, option tables, examples and sample data are not; write your own.

4. No Splunk marks or logos in names, the UI, domains or branding. This covers product, binary, package, repository, organization and domain names, sourcetype and index prefixes, and anything in the UI. Don't use Splunk logos or a look-alike of them, anything confusingly similar to a Splunk mark, or anything that suggests endorsement. Descriptive references are fine, in plain text, where a reader needs them: "SPL-compatible", "accepts the Splunk HEC protocol", "as in Splunk" in a behavior note, "not affiliated with Splunk".

5. Don't decompile or reverse-engineer Splunk software. No decompiling, disassembling or reading Splunk binaries, no capturing traffic from a Splunk instance, and no reading or vendoring the configuration or other files shipped in Splunk products, apps or add-ons.

6. Leave existing Splunk-named identifiers alone, and don't add new ones. Some identifiers are functional and kept for compatibility: the HEC paths under /services/collector, the Authorization: Splunk header, Vector's splunk_hec source type, the splunk_* HEC metadata keys, and the planned splunk_server alias. Don't rename them, and ask in an issue before adding another. They are on the list for counsel in DESIGN.md section 13.

Pull requests#

• Work on a branch and open a pull request; the owner reviews every one (see TODO.md, "Repository rules").
• If the change implements or alters SPL behavior, the description links the documentation pages you worked from and lists any uncertain semantics.
• Opening a pull request confirms that the work in it follows these rules.
• Contributions are licensed under the project's license, Apache-2.0 (LICENSE).