IP, NDA, and Licensing

Two questions come up every year, once from students and once from project partners: who owns what the team builds, and what happens when a project can’t be shown in public. This page answers both, and the rest of the handbook links here instead of restating the policy.

Who Owns the Work

Students hold the IP of the work they produce during capstone, unless the project was flagged as requiring an IP agreement when it was submitted. The idea belongs to whoever proposed the project; the code belongs to the people who wrote it.

A project partner who needs to own the output says so at submission, and the flag is visible to students before they bid, because it changes what they can put in a portfolio and whether they can keep working on the project after the course. A team that discovers the constraint in winter has already made decisions it can’t unmake.

The Flags a Proposal Carries

A project proposal declares whether the project requires an IP agreement, an NDA, or both. Either flag is fine and neither disqualifies a project. What matters is that it’s declared before students bid, rather than negotiated afterward.

The instructors can’t sign an IP agreement or an NDA. The agreement is between the project partner and the students, and the instruction team is not a party to it. If your organization’s legal team expects a university signature, raise it before you submit, and ask them how long resolving it takes.

Licensing

Discuss licensing with your project partner in the first sprint, even when everyone assumes the project will be open source. The choice is easier to make before there’s a codebase and a contributor history to relicense.

choosealicense.com is the reference: it walks the common choices (MIT, Apache 2.0, GPL) by what you want to allow. If your project starts in an existing open-source codebase, the upstream license usually decides this for you; check it before you assume.

Closed source is a valid choice, and the obvious one if you intend to commercialize the result. It does not change the grade. It does mean agreeing early on how the instruction team reads your work.

Teams Under an NDA

By default, the instruction team has read access to your repository. Under an NDA, that access may not be possible, and one rule covers what you submit: submit a sanitized version showing only what your partner agreed up front may appear, with partner-confidential specifics replaced by neutral placeholders (“the partner’s internal system”, “the dataset”). If that isn’t possible, contact the instruction team; in rare cases, your project partner grades that work directly. The criteria and points are identical either way.

Three things follow from being under an NDA, and all three are cheaper to settle in the first weeks of fall than in spring:

• Repository access: find out in your first partner meeting whether the instruction team may have read access to the repository. If not, tell your TA by Sunday of fall week 2 so your checkpoints are scheduled as walkthroughs from the start.
• What may be shown in public: your landing page, your release trailer, and your Expo poster are all public. Agree with your partner what may appear in them: usually the problem, the approach, and sanitized screenshots, without partner data or internal identifiers.
• Individual assessment: every student still defends their own contributions. Under an NDA, only the venue and the evidence you show change.

Where an assignment works differently for an NDA team, that assignment’s page says so in a short note; everything else on the page applies unchanged.