GitBOM | Hacker News Reader

GitBOM

gitbom.dev

25 pointspabs325 comments

This is a potentially interesting project, but as a word of advice: Git's trademark[1] explicitly prohibits uses of "Git" that imply closer provenance and/or association with the Git project than actually exists. The name "GitBOM" made me think that this was an affiliated project at first, which it doesn't appear to be.

[1]: https://git-scm.com/about/trademark

How does this guideline apply to, say, Github or Gitlab?

Edit: Someone in a different comment said those cases are grandfathered because they named themselves before Git was trademarked

Their use of those names predates the policy (and the git trademark), projects like that got exceptions.

I wish this applied to (or would get enforced against) Gitcoin, which doesn't actually have anything--afaik--to do with git (it is just attempting to fund open source development in general, and seems to have just glommed onto "git" as "I guess this has something to do with open source").

So GitHub.com is blessed, but no newcomers can use it?

Cool...so exclusive. /s

I mean at least GitHub and gitlab actually have something to do with git.

But if I make an even better gitlabhub app at metagit.com, I'll be in violation.

Unless you ask the SFC for permission to use their trademark. They're pretty reasonable people.

Alternatively, you could name your project $FOO and host your Git service on `git.$FOO.tld`.

I thought you couldn't register trademarks that were already in use?

I've recently heard about GitOps - https://www.weave.works/technologies/gitops/ but also https://about.gitlab.com/topics/gitops/

I'm not the grand adjudicator of what is or isn't a violation of this policy, but GitOps (from a quick glance) is described as an "operational framework" and not a specific project.

Aside from the git trademark issue, which is easily resolvable, this project is interesting from a professional point of view because the concepts of SBOMs and the requirement to deliver them as part of NIST standards is becoming more important.

It's likely that these standards will start to "trickle down" from US Federal Government to other levels of US government and across general contract negotiations for software deliveries.

Has anyone started delivering SBOMs as part of their delivery? We've had to deliver reproducible build infrastructure and source as part of contractual escrow conditions, but there's a big difference between "reproducible" and actually byte-for-byte equality to a released SBOM.

Personally I'd just use Debian as my SBOM if one was required. For anything open source, just make new packages and upload them to Debian. It has probably many of the things needed (including in-progress deterministic reproducible builds), apart from building proprietary software, but you can create Debian packages internally and use your own build servers and apt repository.

https://www.reproducible-builds.org/ https://tests.reproducible-builds.org/debian/reproducible.ht...

Any other distro can be treated similarly really.

That's fine if you're running on a Linux platform, but if you're running on AWS/GCP/Azure with lambdas/workers/serverless, you need to have the SBOM for your own software.

Not everything is going to be accepted as part of Debian as a distribution.

If you are using a proprietary cloud platform there can be no real SBOM, because you're relying on software you can't even get a hash of. The SBOM for the part of the software that you do control when running on such platformas has to be something that the proprietary platform supports, which obviously will have zero overlap with Debian packaging, so in that situation you just need to look at what the platform supports.

For situations where one is using Debian but also software not in Debian, you can create an internal apt repository and make internal .deb packages to put in the internal apt repository.

The name "GitBOM" and use of the logo breaks pretty much all of the Git trademark rules: https://git-scm.com/about/trademark

If you take a look at the site's footer, they're stating the original logo copyright.

Not sure about the "Git" trademark part...

> GitBOM is NOT (contrary to the name’s appearance): - Git

but fully capitalizing on git branding (in a way that violates the git trademark rules) to try look "official", even including using the logo. Icky.

I’m confused about the “BOM” part as well. It’s clearly not a byte order mark, and explicitly states that it’s not a bill of materials.

Like GnuPlot, which is not GNU

But it appears that gnuplot was never trying to be confused with GNU. I don't even know how well-known GNU would have been at the time the gnuplot was named.

This project on the other hand straight up rips off the Git logo. It makes this project look official. If I wasn't paying attention I could easily have been fooled.

I somewhat disagree with the comments saying that GitBom goes against their trademark (it doesn't sound like an affiliated project to git, just that it uses Git. Similar to GitHub). BUT the logo is a complete rip off.

FWIW the only reason GitHub (and a few other things) are allowed to use that kind of name is because they used the name before "git" was trademarked and the policy established.

this looks cool but apparently the entire project seems to just boot up a few days ago

Well, that's a good thing if they are open to creating a community, which is what they're looking for on first inspection.

The idea of using a directed acyclic graph, along with content addressable artifacts (or representation of external artifacts) could potentially work well alongside spdx and other standards for identifying packages and dependencies at a higher level of abstraction.

Delivering a git repo as your SBOM has distinct advantages in terms of tooling and reproducability, and general "gitops"/git flow processes accomodate multiple releases and signed tags to provide roots of trust for SBOMs.

Reply on news.ycombinator.com