Record the provenance of the remaining bundled images #8984

Activity

1. mengw15

   added the

   Task

   issue type on Oct 14, 2026
2. mengw15

   added a parent issue on Oct 14, 2026

   • Third-party image assets (Icons8 icon, vendor logos) not covered by LICENSE #8800
3. CaroFernando commented on Oct 18, 2026

   

   CaroFernando

   on Oct 18, 2026

   Contributor

   More actions

   /take
4. github-actions

   assigned

   CaroFernando

   on Oct 18, 2026
5. CaroFernando commented on Oct 18, 2026

   

   CaroFernando

   on Oct 18, 2026

   Contributor

   More actions

   Status update on the audit.

   I went through all 236 image and media files tracked in the repository, using the commit that wrote each file's current content, embedded metadata, the description and comments of the PR that added it, and a visual check. Results are recorded in a PROVENANCE.yaml manifest at the repository root, one entry per file with its origin (project-made / third-party / unknown), source, licence and the evidence. I kept the format close to what #8985 proposes so its check can consume it. Manifest: https://github.com/CaroFernando/texera/blob/feat/image-provenance/PROVENANCE.yaml (PR to follow)

   Summary

   Origin	Files	Notes
   project-made	31	Texera logos, UI screenshots and tutorial GIFs, the UDF icons redrawn in #5686, and the sample media / comment icon described as original in #5568, #8804, #8987
   third-party	15	8 already in LICENSE (SVGRepo, Apple, ORCID, Material Symbols / Jupyter diagrams); 7 need action, below
   unknown	190	13 of these are the vendor logos handled by #8999, leaving 177

   Third-party files that need action

   • SankeyDiagram.png: Adobe Stock asset 873461140, per its embedded metadata. Must be replaced.
   • DumbbellPlot.png: Freepik icon, named as the source in Add DumbbellPlot Viz Operator #2149. Must be replaced.
   • TypeCasting.png: Noun Project icon 2103686, named in Typecasting Operator #929. Noun Project icons are usually CC BY 3.0 (Category A with attribution), but the author and licence still need confirming; replacing it may be simpler.
   • ArrowSource.png, AsterixDBSource.png, HdfsFileScan.png: Apache Arrow / AsterixDB / Hadoop logos. Need LICENSE and frontend/LICENSE-binary entries.
   • frontend/src/favicon.ico: the Angular CLI default favicon from 2018. It is not shipped (angular.json only copies src/assets), so I propose deleting it.

   The 177 unknowns

   They trace back to 77 commits, and two of them account for almost half:

   • 51 icons from Introduce Sklearn ML models #2641 (sklearn operators). @aglinxinyuan, do you remember where these came from? One answer would settle a large part of the list.
   • 34 icons first added in 2017 to textdb-angular-gui/thirdparty/images/. The folder name says they are external, so I plan to replace them rather than search.
   • The remaining ~92 come from ~75 operator PRs, 1–2 icons each.

   Plan

   Following what was agreed in #8800:

   1. Before the RCs: replace SankeyDiagram.png and DumbbellPlot.png, add the missing LICENSE entries, remove the unused favicon, and merge the manifest.
   2. Because the remaining audit will take more than a few days, use the DISCLAIMER-WIP route agreed in Third-party image assets (Icons8 icon, vendor logos) not covered by LICENSE #8800, pointing at the unknown entries of the manifest as the known issue. As @pjfanning noted, this does not cover anything known to be non-Category-A, which is why step 1 comes first.
   3. Continue the audit after the RCs: reverse image search for the scattered icons, and replace anything that can't be proven, following the typographic style from fix(frontend): replace vendor logos in operator icons with typographic icons #8999 or with Ant Design icons (already a dependency).

   Open question

   @mengw15's question in #8800 about whether AI-generated icons are acceptable replacements is still unanswered. It matters for step 3. Until there is an answer, I'll stick to typographic icons rendered with a CC0 font, as #8999 does, and icons from Category A libraries.
6. parshimers commented on Oct 21, 2026

   

   parshimers

   on Oct 21, 2026

   Member

   More actions

   Very nice investigation, Luis. The fact that 85 of the icons can be traced to a shared provenance is a great find. That's like half of the task right there. The other 92 is still a lot, but half of a lot is better than a whole lot :)
7. CaroFernando

   added a commit that references this issue on Oct 23, 2026

   docs(licensing): record the provenance of every bundled image in PROV…

   ...

   0b5c61a
8. parshimers commented on Oct 23, 2026

   

   parshimers

   on Oct 23, 2026

   Member

   More actions

   Luis, Meng and I caught each other in the hall, so we ended up having a little chat about this.
   We talked a bit about the history of each operator's icons. Meng mentioned the main way these icons came in was very distributed. A typical immigration project for many new contributors was to create an operator, and as part of that they had to add an icon for it. At that time the licensing was not being closely scrutinized. So, for these icons, they are certainly suspect- people would likely just look on Google Images or something.

   Then we discussed a bit about what to do about it. We discussed the complications of using a model to create the icons. I mentioned that it isn't out of the question, but it is kind of a grey area. I pointed out that the very same thing can happen with LLMs when coding (e.g. it could produce more or less verbatim some well known implementation of an algorithm). This was for the purpose of highlighting that it could be acceptable just as it is for code, but you always must scrutinize the output of any generated asset and clearly mark that it is one (and hopefully information about how it was generated)

   Based on all of this, I mentioned that my general preference for addressing the remaining icons that we don't know the copyright status of is something like this (from most preferred to least):

   1. If we can find icons used in other Apache projects that represent similar things (e.g. database operations) we can use them. This might not be a ton of work, because a lot of them are in the same category, so some other project may have either made the icons themselves or clearly stated the license of it. The same thing applies if we can find some icon set with a compatible license.
   2. If we cannot find anything, it may be permissible to generate some of the icons. It needs to be closely scrutinized and marked as such though.
   3. We can DISCLAIMER-WIP, but I stated that this is "kicking the can"; it's only really something that can unblock the release but it doesn't get us any closer to actually solving the problem.

   If anyone has other thoughts about it please chime in.
9. Yicong-Huang commented on Oct 29, 2026

   

   Yicong-Huang

   on Oct 29, 2026

   Contributor

   More actions

   Shall we just go with the easier and fastest way: just generate some icons? We can have the copyright of them, and that will be the clean.
10. chenlica commented on Oct 29, 2026

    

    chenlica

    on Oct 29, 2026

    Contributor

    More actions

    @CaroFernando As you are working on this task, can you chime in?
11. parshimers commented on Oct 29, 2026

    

    parshimers

    on Oct 29, 2026

    Member

    More actions

    I'm not opposed to the generation for things that seem fiddly; we still have to look at each icon and the prompt though to make sure it's not regurgitating something that is copyrighted.