Dependencies, licences and the supply chain
A program may rely on directly chosen packages and packages reached through them. Teams track those relationships, check exact licence terms against their intended use and release, and assess maintenance and security risks. Pinning selects a version but does not remove vulnerabilities or replace a maintenance plan.
What a learner can do afterwards
- Read dependency paths, distinguish direct and transitive packages, and count shared packages once
- Identify how exact licence terms and intended use determine source-sharing duties
- Assess a dependency's support and risk, then plan tested replacement or maintenance work
1 · Read
A direct dependency is declared by the app. A transitive dependency is reached through another package. One package can be reached both ways. Some packages add no dependencies. Shared packages can appear on several paths. A graph shows these links; tools often display them as a tree. Count a shared package once when counting distinct packages. You can plan dependency work as scoped issues, using the estimates and review checks you have studied.
The app chooses chart-kit. That package needs date-helper and color-helper, and date-helper needs locale-data. The app declares none of those helpers directly. Chart-kit is direct; the other three packages are transitive. To identify a direct dependency, check the app's own declarations. To find transitive dependencies, follow paths through other packages.
Check the exact licence and version against intended copying, changes, linking and release. Record applicable duties and how they will be met. A licence label alone is insufficient. Permissive licences can require copyright notices, licence text or other conditions; credit alone is not a universal rule. Missing licence terms are not permission to assume unrestricted use.
Copyleft can require covered code to stay under specified terms and its source to be provided when the licence's conditions apply. Which code is covered depends on the exact licence and use. Distribution often matters; some licences also address network use. Linking does not have one rule for all copyleft licences. Read the scope and triggers before concluding that a whole app must be shared.
To check a release, list what is copied or linked, what is modified and what recipients receive. Compare each triggered duty with the release plan. Under a made-up rule requiring a notice with every distributed copy, keeping that notice only in an internal folder would not meet the rule. The fictional clauses in these practice questions are teaching conditions, not permission grants for real software.
A quiet repository alone does not prove abandonment. Check maintainer notices, unresolved reports, known vulnerabilities and use in your app. Pinning selects a version; it does not remove bugs or stop attacks. Repeatable builds also depend on transitive versions and other build inputs. If support ends, assess risk and plan replacement or maintenance. Estimate and test the work, and prepare rollback. Urgent security action may be needed sooner.
Trace direct and transitive packages. Check exact terms against planned use. Assess support and security risks, then test replacement or maintenance work; a version pin is not a security fix.
Lesson, questions, worked solutions and flashcards about dependencies, licence checks and maintenance planning were written for this learning dataset. Fictional licence clauses are labelled teaching examples.
2 · Watch
Take it off screen
Where it sits
Optional connections
This opens up
Nothing builds on it yet.
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.