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 cannot be shown in public. This page answers both. It is policy, so it is written once here and the rest of the handbook links to it.

Who Owns the Work

Students hold the intellectual property 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 cannot unmake.

The Flags a Proposal Carries

A project proposal declares whether the project requires an intellectual property agreement, a non-disclosure agreement, or both. Either flag is fine and neither disqualifies a project. What matters is that it is declared before students bid rather than negotiated afterwards.

Instructors cannot sign an IP agreement or an NDA. The agreement is between the project partner and the students, and the teaching staff is not a party to it. If your organization’s legal team expects a university signature, raise it before you submit, because it takes longer to resolve than you expect.

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 is 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 how the teaching staff reads your work, which is the next section.

Teams Under an NDA

The default in this course is that the teaching staff has read access to your repository. Under an NDA, that access may not be possible, and the course accommodates it: the team is assessed through live walkthroughs and sanitized evidence instead. We might also rely on the project partner judgement even more. The assignments overview has the mechanics, and the points are identical either way.

Three things follow from being under an NDA, and all three are cheaper to settle in fall week 1 than in spring:

• Repository access. Find out in your first partner meeting whether staff read access is allowed. If it is not, tell your Teaching Assistant (TA) in week 1 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 still happens. Every student defends their own contributions. An NDA changes the venue and the evidence, not the requirement.

Where an assignment works differently for an NDA team, that assignment’s page says so locally. There is no separate track to learn.