Wiele zasobów powstaje w wyniku tłumaczenia, kompilowania, kopiowania lub innego przetwarzania plików tworzonych i edytowanych przez użytkownika. Zasoby pochodne nie stanowią oryginalnych danych i mogą zostać utworzone ponownie z ich plików źródłowych. Pliki pochodne często są wykluczane z pewnych rodzajów procesów.
Na przykład zasoby pochodne zazwyczaj nie są przechowywane w repozytorium zespołu, ponieważ je zaśmiecają, są regularnie zmieniane i mogą zostać utworzone ponownie z ich plików źródłowych. Z praktycznego punktu widzenia nie jest dobrze, gdy dostawcy zespołowi muszą zastanawiać się, które zasoby są zasobami pochodnymi. Interfejs API zasobu udostępnia modułom dodatkowym powszechny mechanizm do oznaczania tworzonych zasobów jako pochodnych.
Do oznaczania zasobu jako pochodnego innych zasobów moduły dodatkowe mogą używać metody IResource.setDerived(boolean). Nowo tworzone zasoby nie są domyślnie oznaczane jako pochodne, więc ta metoda musi zostać użyta w celu jawnego oznaczania zasobów jako pochodnych. Powszechną praktyką jest oznaczanie podfolderu projektu jako pochodnego, gdy folder wyjściowy (na przykład folder "bin" w projektach Java) jest tworzony przez moduł dodatkowy.
Inne moduły dodatkowe, zazwyczaj dostawcy zespołowi, mogą używać metody IResource.isDerived do określania, czy konkretny zasób powinien być zarządzany przez repozytorium. Próby oznaczenia projektów lub katalogu głównego obszaru roboczego jako pochodnych zostaną zignorowane.
Uwaga: Pojęcie zasobów pochodnych jest udostępniane innym modułom dodatkowym (niezespołowym) do oznaczania zasobów, które nie powinny być zarządzane przez repozytorium. Specjalne pliki tworzone przez implementacje zespołowe do zarządzania ich danymi nie powinny być oznaczane jako zasoby pochodne. Więcej informacji na temat technik oznaczania zasobów implementacji zespołowych jako ukrytych zawiera sekcja Prywatne zasoby zespołowe.