Repository navigation
Third-party image assets (Icons8 icon, vendor logos) not covered by LICENSE #8800
Description
What happened?
The source release ships about 230 image assets under frontend/src/assets/. Some of them are clearly third-party, but LICENSE covers only the 3 SVGRepo SVGs. Seen while verifying 1.2.1-incubating-RC1. The same assets were in 1.2.0-incubating.
1. Icons8 icon with no attribution
frontend/src/assets/operator_images/icons8-chat_bubble.png is the workflow comment icon, referenced in frontend/src/app/workspace/service/joint-ui/joint-ui.service.ts:1025. It was added in #1417. The filename shows it comes from Icons8. Icons8's free licence requires attribution (a link to icons8.com), and without a paid licence it is not clearly compatible with redistribution under Apache-2.0. LICENSE and NOTICE don't mention it.
2. Third-party logos used as operator icons
These are the official logos of other organisations. They are copyrighted artwork as well as trademarks, and nothing records where the files came from or under what terms:
| File | Logo |
|---|---|
operator_images/TwitterSearch.png, TwitterFullArchiveSearch.png, TwitterFeed.png, TwitterConverter.png |
Twitter bird |
operator_images/RedditSearch.png |
Reddit "Snoo" |
operator_images/PostgreSQLSource.png |
PostgreSQL "Slonik" elephant with wordmark |
operator_images/HuggingFace*.png |
Hugging Face logo |
Each of these needs one of the following:
- the source and licence recorded in
LICENSE, if the image is under a compatible licence; - confirmation that the brand's usage terms allow redistribution in an Apache-2.0 release;
- or replacement with a generic or project-made icon.
3. Everything else has no recorded provenance
The other ~200 PNGs in operator_images/, the tutorial GIFs/JPEG (frontend/src/assets/Tutor_*), card_background.jpg, and so on may well be project-made. Some look like they came from icon sets (for example SklearnRandomForest.png is a generic "shuffle" glyph). None of them record where they came from.
Minor: operator_images/MysqlSink.png is actually a JPEG (CREATOR: gd-jpeg) despite the .png extension. That suggests it was downloaded from somewhere.
Expected:
- every bundled third-party image is listed in
LICENSEwith its source and licence (as the SVGRepo icons already are), with the licence text underlicenses/; - images whose licence isn't compatible are replaced;
- images the project made itself are confirmed as such.
How to reproduce?
B=https://dist.apache.org/repos/dist/dev/incubator/texera/1.2.1-incubating-RC1
curl -sO $B/apache-texera-1.2.1-incubating-src.tar.gz
tar xzf apache-texera-1.2.1-incubating-src.tar.gz
cd apache-texera-1.2.1-incubating-src
ls frontend/src/assets/operator_images/ | grep -iE 'icons8|twitter|reddit|postgres|huggingface'
grep -niE 'icons8|twitter|reddit|postgres|hugging' LICENSE # no matches
file frontend/src/assets/operator_images/MysqlSink.pngVersion/Branch
1.2.1-incubating-RC1 (also present in 1.2.0-incubating)
Activity
github-actions commentedon Oct 1, 2026
👋 Thanks for opening this issue, @pjfanning!
It looks like the issue description doesn't quite follow our template yet:
Filling out the template helps reviewers understand and triage your contribution faster. Please edit the description to complete it. This message will disappear automatically once the template is followed.
You can find the template prompts by editing the description, or see CONTRIBUTING.md for the full contribution flow.
fix(frontend): replace the Icons8 comment icon with an original drawi…
Yicong-Huang commentedon Oct 7, 2026
Thanks @pjfanning for pointing this out. I think we indeed missed to attribute for those icons.
For icon8 images, let's just list them and point to icon8 website.
For third party ones like twitter, hugging face, Postgres, we can research each of their license to see if they are compatible, and if not, let's replace them with Text or AI-made icons.
For other images generated by us, including screenshots for tutorials, let's revisit them and make sure there is no copy right problem.
parshimers commentedon Oct 7, 2026
The problem with the icon8 images is that it is not a free license. Pointing to the website isn't enough. It is free as in beer, not as in speech: https://intercom.help/icons8-7fb7577e8170/en/articles/5534926-universal-multimedia-license-agreement-for-icons8 .
In general anything which isn't in Category A and perhaps B from https://www.apache.org/legal/resolved.html is going to be a hard no.
pjfanning commentedon Oct 7, 2026
#8804 appears to remove the icons8 image. Keeping the icons8 image is complicated and requires attribution - and probably getting legal advice on the license. It is much more complicated to try to work out the licensing implications and get multiple reviews than just dumping the image.
It isn't hard to create new images.
mengw15 commentedon Oct 8, 2026
Yes, #8804 fixed one image, and notably the only one whose filename still said where it came from. The harder part is the remaining ~200 under frontend/src/assets/: filename grep only catches the honest ones, so we don't actually know how many are third-party (PJ already flagged two suspects). How do we want to tackle the audit?
parshimers commentedon Oct 8, 2026
The method that I would use is: try to use git blame to find out what commit added them. If we can ask the author of the commit that added them where they got the icons, that's an easy way. If we can't or they don't remember, I would try using reverse image search to try and figure out if they were produced or copied. If they were copied then we need to know where they were copied from.
mengw15 commentedon Oct 8, 2026
Thanks @parshimers, that's a helpful way to approach it. Auditing ~200 images could be a sizable effort though — does this need to block the upcoming 1.3.0 and 1.2.1 releases, or can the audit proceed in parallel?
parshimers commentedon Oct 8, 2026
If there is reasonable doubt about the licensing of those resources, then yes, I wouldn't release until that doubt was removed. I think we're blocked on resolving #8807 anyway.
mengw15 commentedon Oct 8, 2026
On the audit: agreed.
On #8807 though: my understanding is the reproducibility precondition applies to automated signing only. Since the GPG secrets were removed, both upcoming RCs will be signed manually by the release managers on their own hardware, so I don't think the releases are blocked on resolving #8807 itself. Am I missing something?
parshimers commentedon Oct 8, 2026
This is kind of a diversion from this topic, so we should probably take it to the main discussion, but I will diverge here:
Yes, I think the missing piece is the docker images. The helm charts refer to these and aren't really useful without them. They are part of the release, effectively.
The relevant quote from the release signing document:
https://www.apache.org/legal/release-policy.html#owned-controlled-hardware is also worth a read.
The point is that you need to be able to verify (in the cryptographic sense) what you are releasing is actually a product of the source, and doesn't contain anything else. You can't be sure about that with something that was built on hardware you don't fully control. The only caveat to this, is if you can build a bit-for-bit identical version of that something locally from the same source.
mengw15 commentedon Oct 10, 2026
@parshimers I ran the first step of your method, a blame inventory over the 231 images under frontend/src/assets/: they trace to 68 different authors spanning 2017–2026, and more than half of them added just one or two images (one-time contributors, many no longer around). and realistically nobody will remember where a specific icon came from, and we'd rather not block the releases on tracking people down.
So I'd propose going straight to the reverse-image-search pass, and replace anything doubtful with maybe AI-generated icons (would AI-generated icons be acceptable?). Does that work?
xuang7 commentedon Oct 11, 2026
I agree with @mengw15 that tracking down the original contributors may not be practical, especially since many of these operator images were added years ago and the contributors may no longer be active. I'm also concerned that reverse image search could be quite time-consuming for over 200 images, and even if we don't find a match, it wouldn't necessarily confirm their provenance. Would it be more practical to replace the existing operator images with icons from an Apache-compatible icon library, or create new icons ourselves, either manually or with AI assistance?
As a next step, we could prioritize replacing the remaining third-party branded icons (Twitter, Reddit, PostgreSQL, Hugging Face, Java, NLTK, and MysqlSink.png) with generic icons or text labels.
pjfanning commentedon Oct 11, 2026
There is also other media like sample-video.mp4, sample-audio.wav and sample-image.png.
Replacing this stuff with user generated files or files with proven provenance seems to be the best path.
All media like this should be immediately documented so that we don't end up with another issue in the future.
pjfanning commentedon Oct 11, 2026
It may be feasible to release with a DISCLAIMER-WIP file that lists this as a known issue but that doesn't allow you to release with files that are Category X License. So there is a Catch 22. The DISCLAIMER-WIP approach may save you some work in the short term but it doesn't really mean that you can skip working out the license situation with these media files.
mengw15 commentedon Oct 13, 2026
Thanks Xuan and PJ for the suggestions.
For the branded icons, would replacing them with simple text-based icons be an acceptable solution?
For the remaining ~200 images, I suggest we start documenting their provenance and replacing those with unknown sources using self-made or Apache-compatible icons. Does this approach sound reasonable?
We should also replace the sample images, audio, and video with files we generate ourselves, and document their provenance as well.
If there are no objections, I think we should start creating issues to track these tasks and move forward with the replacements.
parshimers commentedon Oct 14, 2026
I agree with that plan. If the provenance is unclear, and there is an icon that is similar enough with a clearly free (and permissive/compatible) license, then we should just use that.
If it looks like it might take a long time (weeks) to do this, then we can do the DISCLAIMER-WIP route to unblock the release, but as PJ said, it can't be left like that.
mengw15 commentedon Oct 14, 2026
Thanks all. I've split the work into sub-issues:
#8982 and #8983 block the next RCs. If #8984 looks like it will take weeks, we can take the
DISCLAIMER-WIProute for it, as discussed.fix(frontend): replace the Spider-Man sample image with an original d…
fix(frontend): replace vendor logos in operator icons with typographi…