Software Licenses - Interview-Ready Notes
Why licenses matter
A software license defines what others can do with code: use it, copy it, modify it, distribute it, sell it, or combine it with proprietary software.
For senior/staff interviews, the important framing is:
- Licenses are a product, business, and risk decision, not just a legal checkbox.
- The main engineering concern is usually obligations when distributing software, especially if open-source code is linked, modified, or shipped to customers.
- Most companies track licenses through dependency scanning, SBOMs, legal review, and open-source policy.
Quick Mental Model
| Family | Meaning | Examples | Interview takeaway |
|---|---|---|---|
| Permissive | Use freely with minimal obligations | MIT, BSD, Apache 2.0 | Easy for commercial use |
| Copyleft | If you distribute derivatives, you must preserve open-source freedoms | GPL, AGPL, LGPL | Stronger obligations; review carefully |
| Proprietary | Owner controls usage, modification, redistribution | Commercial SaaS, internal code | Protects business IP |
| Public domain / near-public-domain | Author gives up most restrictions | Unlicense, CC0 | Maximum reuse, but weaker warranty/IP protections |
Short History
Early software
In the early computing era, software was often bundled with hardware or shared among researchers. As software became commercially valuable, companies began using proprietary licenses to control copying and redistribution.
Free software movement
In the 1980s, Richard Stallman and the GNU project pushed the idea that users should have freedom to run, study, modify, and share software. This led to the GPL, which uses copyright law to require downstream users to keep the same freedoms.
Open source movement
In the late 1990s, “open source” reframed the movement in more business-friendly terms: collaborative development, faster innovation, transparency, and lower cost. Permissive licenses like MIT, BSD, and Apache became popular because they fit commercial adoption well.
Modern era
Today, companies mix open source and proprietary software heavily. The focus is less ideological and more operational: dependency governance, supply-chain risk, security, cloud service usage, patents, and license compliance.
Major License Types
MIT License
Type: Permissive
Core idea: Do almost anything with the code as long as you keep the copyright and license notice.
Good for: Libraries, tools, broad adoption, startups, developer-friendly projects.
Interview line: “MIT is simple and commercially friendly. The main obligation is preserving the copyright/license notice.”
BSD Licenses
Type: Permissive
Core idea: Similar to MIT. Allows commercial use, modification, and redistribution.
Important nuance: BSD has variants. The old 4-clause BSD had an advertising clause; modern 2-clause and 3-clause BSD are simpler and widely used.
Interview line: “BSD is permissive like MIT, commonly used when maintainers want broad adoption with minimal downstream restrictions.”
Apache License 2.0
Type: Permissive
Core idea: Permissive like MIT/BSD, but more explicit about patents.
Why companies like it: It includes an express patent grant from contributors, which can reduce IP risk.
Interview line: “Apache 2.0 is business-friendly and stronger than MIT/BSD on patent clarity, which matters for larger companies.”
GPL
Type: Strong copyleft
Core idea: If you distribute a derivative work based on GPL code, the derivative generally must also be GPL and source must be provided.
Good for: Projects that want to guarantee software freedom downstream.
Risk area: Combining GPL code with proprietary code can create obligations that companies may not want.
Interview line: “GPL is not anti-commercial, but it is anti-closing-the-source for distributed derivative works.”
MIT vs GPL - Quick Reference
| Question | MIT | GPL |
|---|---|---|
| License family | Permissive | Strong copyleft |
| Commercial use | Usually easy | Allowed, but obligations matter |
| Can proprietary code use it? | Usually yes | Risky if combined into a distributed derivative work |
| Main obligation | Keep copyright and license notice | Preserve GPL terms and provide source for distributed derivatives |
| Business posture | Optimizes adoption | Optimizes downstream openness |
| Typical company reaction | Low-friction approval | Needs OSS/legal review |
How to explain the difference
MIT: “You can use, modify, redistribute, and sell the software, including inside proprietary products, as long as you keep the copyright and license notice.”
GPL: “You can use, modify, and sell the software, but if you distribute a derivative work, you generally need to distribute it under GPL and provide source code.”
Practical example
If a team uses an MIT-licensed utility library inside a commercial product, the usual requirement is attribution/notice preservation.
If a team embeds or modifies a GPL-licensed component inside a distributed proprietary product, the company may be required to release the combined derivative work under GPL. That is why GPL dependencies usually need review before adoption.
Interview-safe phrasing
“MIT is permissive and adoption-friendly. GPL is copyleft and freedom-preserving. The biggest practical difference is what happens when the software is distributed as part of another product.” “MIT is permissive: I can use it in proprietary or differently licensed software while preserving notices. GPL is copyleft: if I distribute a derivative work that incorporates GPL code, the combined work generally must also be GPL.”
LGPL
Type: Weak copyleft
Core idea: Designed mostly for libraries. Proprietary software can often link to LGPL libraries, but modifications to the LGPL library itself must remain open under LGPL.
Interview line: “LGPL is a compromise: it protects improvements to the library while allowing broader use from proprietary applications.”
AGPL
Type: Strong network copyleft
Core idea: Closes the “SaaS loophole.” If users interact with modified AGPL software over a network, source-code obligations can be triggered even without traditional distribution.
Why companies are careful: SaaS companies may avoid AGPL dependencies unless legal approves them.
Interview line: “AGPL matters because cloud delivery can trigger source-sharing obligations, not just shipping binaries.”
Proprietary Licenses
Type: Closed / controlled
Core idea: The owner grants limited rights, often restricting copying, modification, reverse engineering, or redistribution.
Good for: Commercial products, enterprise software, internal platforms, IP protection.
Interview line: “Proprietary licensing gives business control, but often reduces community contribution and transparency.”
Creative Commons
Type: Content licenses, not usually software licenses
Core idea: Used for text, images, videos, documentation, and educational content.
Important nuance: Avoid using most Creative Commons licenses for code. Use OSI-approved software licenses instead.
Interview line: “Creative Commons is generally for content, not source code, except CC0-like public-domain dedication cases.”
Copyleft vs Permissive
Permissive
- Encourages adoption by minimizing restrictions
- Easy to use in proprietary products
- Common for infrastructure libraries and developer tooling
- Examples: MIT, BSD, Apache 2.0
Copyleft
- Ensures derived distributed works remain open
- Protects community freedoms
- Requires more careful review in commercial products
- Examples: GPL, LGPL, AGPL
Simple comparison:
Permissive licenses optimize for adoption. Copyleft licenses optimize for preserving openness downstream.
Senior/Staff-Level Discussion Points
1. Distribution is the key trigger
Many obligations become important when software is distributed outside the company. Internal-only use is often lower risk, but not always, especially with AGPL or hosted services.
2. Linking and derivative work can be nuanced
Static linking, dynamic linking, plugins, IPC, and service boundaries can affect risk, but this is legal-context dependent. In interviews, do not overstate certainty.
Good phrasing:
“The engineering team should identify the dependency and usage pattern, then let legal or OSS review decide the exact obligation.”
3. Patents matter
Apache 2.0 is often preferred in enterprise contexts because it includes explicit patent language. MIT is simpler but less explicit.
4. SaaS changed the conversation
Traditional GPL obligations often focus on distribution. AGPL was created because cloud providers could modify server software and provide it as a service without distributing binaries.
5. Compliance is part of supply-chain management
Modern companies manage licenses using:
- Dependency manifests
- SBOMs
- License scanners
- Approved license lists
- Legal review for high-risk licenses
- Notice files and attribution generation
Common Interview Questions
Q1: Can we use MIT-licensed code in a proprietary product?
A: Usually yes. Keep the license and copyright notice.
Q2: Why are companies cautious about GPL?
A: If GPL code is incorporated into distributed proprietary software, it may require releasing the combined derivative work under GPL.
Q3: How is LGPL different from GPL?
A: LGPL is weaker copyleft, mainly for libraries. It often allows proprietary apps to link to the library, but modifications to the LGPL library itself must remain open.
Q4: Why is AGPL considered stricter for SaaS?
A: Because network use can trigger source-sharing obligations, even if the software is not shipped as a binary.
Q5: Why might a company prefer Apache 2.0 over MIT?
A: Apache 2.0 has explicit patent grants and more detailed contribution terms, which can be important for enterprise risk management.
Q6: Is open source the same as free software?
A: They overlap in licensing, but differ in philosophy. Free software emphasizes user freedoms; open source emphasizes development model, transparency, and practical collaboration.
60-Second Interview Script
“Software licenses define the rights and obligations around using, modifying, and distributing code.
The big split is permissive versus copyleft. Permissive licenses like MIT, BSD, and Apache 2.0 allow broad commercial use with minimal obligations, usually preserving notices. Apache 2.0 is especially common in enterprise contexts because it has explicit patent language.
Copyleft licenses like GPL require derivative distributed works to preserve the same open-source freedoms. LGPL is weaker copyleft, usually used for libraries, while AGPL is stricter for network services because SaaS usage can trigger source-sharing obligations.
Historically, licenses evolved from proprietary software control, to the free software movement and GPL, to the open-source movement with business-friendly permissive licenses. Today, senior engineers think about licenses as part of architecture, dependency governance, supply-chain risk, and product strategy. My practical approach would be to classify dependencies, understand how they are used or distributed, and route higher-risk licenses through legal or OSS review.”
Rapid Recall
- MIT: Simple, permissive, keep notice.
- BSD: MIT-like, permissive, several variants.
- Apache 2.0: Permissive plus patent grant.
- GPL: Strong copyleft on distributed derivatives.
- LGPL: Weaker copyleft for libraries.
- AGPL: GPL-like obligations can apply over network/SaaS use.
- Proprietary: Controlled by owner; limited rights granted.
- Creative Commons: Mostly for content, not code.
One-Line Senior Answer
“At staff level, I would treat licenses as part of technical risk management: understand the dependency, usage model, distribution path, patent implications, and company policy before bringing it into a product.”