How to tell your OSS is ridiculously popular: people aren't 100% sure they didn't embed it, and tack on the software equivalent of "packaged in a facility where peanuts were also present" to the license list.
This watch contains software, so statistically probably contains at least traces of curl.
@bagder Yup, I see the Garmin Fenix 5 (2017), Forerunner 245 (2019) and Venu Sq (2021). The one in the photo is a Venu 3s (2023) and features exactly the same wording.
Not too surprising, the base firmware doesn't seem to change hugely (mostly new display tech and upgraded sensor hardware), and most of the user visible stuff runs in a custom VM. If I had to guess, I would say maybe libcurl is used for the sync-over-wifi feature for bulk downloads like maps and firmware updates.
@danderson Interestingly, they did it with a misidentification of the curl license for another one.
It isn't MIT/X11 but ISC with "and/or" changed into "and", and the no-advertising clause of the X11 license appended.
Boring joke deflator: afaict it's just Garmin's standard wording so that they can splat in all licenses to everything involved in any of their products, rather than have to generate license compliance text specific to individual firmware builds. But also, lol
@evana Knowing nothing about how garmin build firmware, my suspicion is it's something like: this is a list of all OSS present in their Yocto source tree, or similar. Rather than track what OSS makes it into which firmware builds for which SKUs, they just make a list of all OSS that gets too close to their build system, and put that one list in all products. But I dunno 🤷
@evana What makes you think because they "made the thing" they know what's inside? At many vendors, what they call the "development team" is mostly clicking things together from some "modular system". They have no clue what gets dragged in or, when you tell them, how to get rid of some unwanted dependency ("but we don't use that!"). Telling them "use exclude:group in your build.gradle" overtaxes them (yepp, a real case I had) 🤷♂️ @danderson
I think it's unfortunate that our tools don't automatically record what they put inside. I'm hopeful that the addition of SBOM requirements for federal contracting will help drive improvements in the tooling so that we can get the contents of our software automatically.
Right now, I'm hearing that we know everything that goes into the factory, so we assume that all of that goes into the Twinkies that come out. Including the bolts...
@evana Oopsie… No offense meant! Wasn't aware you were involved. Still, my "rant" holds its truth unfortunately in far too many places. But I should add that with the current tools it's not always easy to be aware what went it or what dragged in other things (well, one can check the dependency tree in most cases, but does not always remember too). One reason more than one FOSS dev expressed their thanks to the additional checks at the #IzzyOnDroid repo, for example…
@IzzyOnDroid no problem! The post went a little further than I expected, and I wanted to follow up with how I thought we could genuinely make software better.
@evana That's a driving force for me as well. If I might exaggerate a bit, I guess you'll have a hard time looking at just 10 Github repos without finding some issue, issue comment, PR or review by me 🙈 Especially if it's the repo of some Android app.
And it's usually a clear win-win. Not being an Android dev, I've learned a lot about that during the discussions – while my reports usually uncovered something the devs were not aware of. Respect from both sides, precious outcome for all :awesome:
Add comment