The first dependency is a "dependency", but in the same way that an RFC you have to read with your eyes is a dependency. Except in this case, the dependency is

The first dependency is a "dependency", but in the same way that an RFC you have to read with your eyes is a dependency. Except in this case, the dependency is a definition, in formal language (extended-backus-naur form, a.k.a. "e-bnf"), of the SQL language, as defined in ISO/IEC 9075:2016[0] (the 2016 version of the SQL language specification). They then use this language definition as the input to a program which generates parsers (called a parser-generator[1]), so that they can quickly get to where they have a library which they can use to parse/validate/inspect the SQL being given to them. Copying the BFN "from an external source" is a smart move, since it means they don't have to do lots of busy work slowly reading and transcribing the specification; someone's already done that step, so why would anyone expect the author to waste time? Using a parser generator is also a smart move since they exist already and are used all over the place (nobody hand-writes parsers for large languages; that's just a needless source of tedium and bugs). The code that's spit out of the parser generator is novel; that's newly created code which isn't taken from someone else's Github/other repo. Ultimately, I don't see how any of what the author's done constitutes "[relying] on a dependency" given that they're not using anyone elses Zig source code in their compiled binary, they're writing lots of code for themselves to use, just very quickly, and with powerful tools. [0] - https://en.wikipedia.org/wiki/SQL:2016 https://en.wikipedia.org/wiki/SQL:2016 [1] - https://en.wikipedia.org/wiki/Compiler-compiler https://en.wikipedia.org/wiki/Compiler-compiler