A one hour open source class for new engineers should cover why the company has rules, the license tiers, how to add a dependency, how to handle vulnerabilities, how to contribute upstream, and who to ask. Keep it practical, use your own repositories as examples, and finish with a short quiz.
Why a short class works
The Linux Foundation guide describes one large company that requires all new engineers to take a one hour open source class where licensing and compliance are stressed as part of how the company does business. It also notes the company complies not only because licenses oblige it to, but because it values the community. A short, regular class is easier to keep running than a long course, and it builds the habit that policy alone cannot.
Outline with timings
| Minutes | Topic | What to show |
|---|---|---|
| 0 to 5 | Why this matters | One real example of a license or supply chain problem, kept factual |
| 5 to 15 | License tiers | Your allowed, review and not allowed lists, with two examples each |
| 15 to 30 | Adding a dependency | The intake steps, a walk through a real pull request, and the automated checks |
| 30 to 40 | Security | How advisories reach you, what to do when a dependency has one, how to report one upstream |
| 40 to 50 | Contributing | The tier rules, the checklist, what never goes in a public pull request |
| 50 to 60 | Questions and quiz | Where to ask, who owns policy, three scenario questions |
Content notes
License tiers. Avoid legal depth. Engineers need to know which families are allowed without asking and what triggers a review. Point to the written policy. See a three tier license policy.
Adding a dependency. Teach the questions to ask: is it maintained, who maintains it, what does it pull in, how is it licensed. See a checklist before adding a new open source dependency.
Security. Explain the difference between a vulnerable package, an abandoned one and a malicious one. See three kinds of open source risk.
Contributing. Teach the self-serve checklist: no proprietary code, no secrets, right license, private route for security issues. See how employee contributions should be approved.
Three scenario questions
- You find a small library that solves your problem, but its license field is blank. What do you do?
- A dependency has a new advisory on a Friday afternoon. Who do you tell and what do you check?
- You fixed a bug in a library you use. What must you check before opening a pull request?
Walk through answers in the room. Scenarios stick better than slides.
Make it durable
- Record a short video so late joiners can watch it.
- Update it twice a year with a real incident from your own repositories.
- Track completion, not scores.
- Repeat a five minute refresher for existing staff when the policy changes.
Measure whether it works
Look for fewer repeated questions to the program owner, fewer exceptions for avoidable reasons, and faster dependency reviews. The guide also notes the value of tracking program statistics. Pick two numbers and watch them.
Where Safeguard fits
Use your own repositories for the examples. Safeguard's dependency scanning, reachability analysis and pull request gates give you real screens to teach from. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. It shows the pull request moment you will teach in the dependency segment.
Quick check
Should the class be mandatory?
Making it part of onboarding is the simplest way to reach everyone, as the large company example in the guide does.
Who should teach it?
The program owner, ideally with a guest from legal or security for ten minutes.
Sources
Last reviewed: 19 October 2026.
