A licence-class rule must block copyleft in a shipped binary yet allow it internally - how does the rule tell the two apart?
answer
- one rule, two populations
- applicability comes from outside the inventory
- the catalog entry says whether it ships
- class from the declared field, never re-derived
basics
~20 sThe rule reads two inputs: licence class per component from the build's inventory, and the service's distribution context from its catalog entry. Applicability comes from the catalog, so one component passes internally and fails in a shipped binary.
solid answer
~50 sTwo inputs, two jobs. The component inventory produced by the build supplies a **declared licence** per component, which the rule maps to a small class vocabulary - permissive, weak copyleft, strong copyleft, unknown. The service's catalog entry supplies the **distribution context**: does this artifact ship to customers or run only on our own infrastructure. The rule is then one sentence: for a subject whose catalog entry says it is distributed, no component may carry a class outside the allowed set. The same dependency in an internal service is untouched. The discipline that matters is not re-deriving the licence at gate time - the gate is not a licence detector, and its own opinion will disagree with the inventory and with whatever legal already reviewed. Read the declared field, map it to a class, and decide unknown explicitly rather than letting it fall through as permissive.
go deeper
Know that the same component can be acceptable in one service and unacceptable in another, and that the difference comes from what the organisation does with the artifact, not from the component itself.
Be able to name both inputs and where each lives - class from the build's component inventory, applicability from the service's catalog entry - and explain why the gate reads a declared field instead of working the licence out itself.
Show judgment about the rule's edges: what you do with a component that maps to no class, how you keep the distribution flag honest, and how you keep the rule deterministic across pipelines that run different tooling.
Own who sets the allowed classes. Engineering encodes a legal position; it does not invent one. Be ready to say how that list is reviewed, who signs it, and what happens when the business wants an exception to it.
## The rule needs two facts, from two different places Almost every interesting policy about licences fails on the same point: the licence alone does not decide anything. Obligations attach to what you **do** with the software, and the most consequential distinction for most organisations is whether the artifact is distributed to third parties or merely operated internally. So the rule needs: 1. **What licence class each component carries** - from the component inventory the build produces. 2. **Whether this subject is distributed** - from the service's own catalog entry. Neither input can supply the other. An inventory describes an artifact's contents; it has no idea who receives the artifact. A catalog entry describes a service; it has no idea what is inside the build. ## Classes, not licence identifiers Write the allowed set as a small vocabulary of **classes** rather than a list of licence identifiers: | class | rough meaning for a gate | | --- | --- | | permissive | attribution-style obligations, generally allowed everywhere | | weak copyleft | obligations attach to the covered files, often allowed with conditions | | strong copyleft | obligations that legal may treat as unacceptable for a distributed binary | | unknown / none declared | not a class - a decision the rule must make explicitly | Two reasons. First, an identifier list churns constantly, because a new dependency arrives under a licence that is equivalent to one already on the list but spelled differently, and the gate then blocks a change for a reason nobody can defend. Second, and more important, a class list is a vocabulary that a legal or compliance owner can actually read, review and own. Nobody in legal wants to approve four hundred identifier strings; they will happily approve four classes and let engineering maintain the identifier-to-class mapping underneath. ## Never re-derive the licence inside the gate The strongest instinct to resist is having the gate inspect package contents and decide the licence for itself. Three things go wrong: - It produces a **second opinion**. When the gate and the inventory disagree, the outcome depends on which one a given pipeline consulted, and the policy is no longer deterministic. - It makes the gate the licence authority, which it is not qualified to be. Whoever produces the inventory owns that field, and how they populate it - and what its edge values mean - is their problem to define and improve. - It is slow and it drifts, because detection heuristics change between tool versions while the rule's text stays the same. The rule's job is to read a field and apply a policy to it. If the field is wrong, that is an inventory quality defect and it gets routed to the inventory's owner, not patched around inside the policy. ## Handling a component with no usable class A component whose declared licence maps to no class is not automatically fine and not automatically fatal. Decide it, write the decision down, and make the message say what the engineer must do: get the field populated upstream, or record an explicit determination. The failure to avoid is silent - a rule whose condition simply does not match an unclassified component lets it through while looking green, and the organisation believes it has a licence gate that in fact only covers components that were easy to classify. ## Where the distribution flag comes from It is a field in the same catalog entry as the ownership metadata, which is why that entry is worth requiring in the first place. It needs the same treatment: a closed set of values, changes visible in code review, and ideally reconciliation against the pipeline that actually publishes artifacts to customers. A self-declared flag that nobody ever reconciles is an opt-out button with a polite name - a team under deadline flips it, and the rule stops applying without anyone deciding that it should. ## What good sounds like in an interview "One rule, two inputs. Class comes from the inventory's declared field and I never re-derive it. Applicability comes from the service's own declaration of whether it distributes, and that declaration is constrained and reconciled. Unknown class is an explicit branch, not a gap." That answer shows you understand that a licence gate is a policy about **context**, not a scanner.
- Why map licences to classes instead of listing allowed licence identifiers?An identifier list churns every time a dependency arrives under a new but equivalent licence, and it forces engineers to make legal calls one string at a time. A four-or-five item class vocabulary is small enough for a legal owner to review and own, with the identifier-to-class mapping maintained once underneath it.
- What if the inventory's declared licence disagrees with the licence text in the package?That is an inventory quality defect, and the gate must not arbitrate it - a rule that forms its own opinion becomes non-deterministic across pipelines. Route it to whoever produces the inventory. Meanwhile the rule should still have an explicit branch for a component whose class it cannot determine, rather than passing it silently.
- Where does the distribution flag come from, and can a team simply flip it?It is a field in the service's catalog entry, so constrain it like any other: closed value set, changes visible in review, and reconciliation against the pipeline that actually publishes to customers. An unreconciled self-declared flag is an opt-out from the rule that nobody explicitly granted.
saying these in an interview costs you the question
- Re-derives licences by inspecting packages at gate time
- Applies one allowed-licence list to every service
- Lets an unclassified component pass silently
- Treats a declared licence field as legal clearance