Blog

I was halfway through a group project slide deck when it hit me: if this turned into a real startup, who would actually own it? Me, my team, or the university quietly sitting in the background like a silent shareholder?

Here is the short answer: who owns your university project depends on a mix of factors: who created what, whether you used “significant” university resources, whether you are an employee or just a student, what you signed (course policies, lab agreements, competition rules), and your university’s IP policy. In many cases, students own their projects. In some cases, the university or a company sponsor owns some or all of it. The only way to avoid trouble is to read the policy, map your project to it, and clean up ownership before the project becomes a startup.

What “intellectual property” actually means in student projects

I used to think IP was just patents that big pharma companies fight about. Then I sat in a tech transfer info session and realized my class projects were quietly ticking all the same legal boxes.

At campus level, your project can involve several types of IP at once:

• Copyright: protects original “works of authorship” like code, designs, reports, pitch decks, UI layouts, written content, and graphics. For student founders, this is often the first and biggest piece.
• Patents: cover new technical inventions (hardware, algorithms with a practical effect, lab methods, chemical formulas, etc.). This is where universities get very interested.
• Trademarks: protect names, logos, and slogans that identify your product or team. That “cool” project name? It might actually be trademark material.
• Trade secrets: confidential know-how, formulas, code, datasets, or processes that give an advantage because others do not have them.

Your project is not “just a course assignment” once it starts to look like a real product or method that could be commercialized or licensed.

So the real question is not “who owns my project” in a vague sense. The real questions are:

• Who owns the copyright in our code, UI, slides, and documentation?
• Who owns any patentable idea in our project?
• Who controls the project name and logo if we turn this into a startup?
• Who can legally share or reuse the data, models, or methods we created?

Your university has likely written down answers to most of this in an IP policy. The tricky part is translating that policy into the messy reality of project groups, shared Google Drives, and late-night lab sessions.

The 5 main forces that decide who owns your project

During one entrepreneurship seminar, I realized that IP ownership on campus is basically a five-way tug-of-war. Not dramatic, just systematic.

1. Your status: student, employee, or both

This is the first filter lawyers look at, and students often ignore it.

If you are a regular undergrad or coursework masters student, you usually start from a stronger position: default ownership is with you.

The moment you are paid as an RA, TA, or staff, things change. Many universities treat inventions and sometimes even code you create under your employment agreement as belonging to the university.

If you are on a payroll, your contract and HR status matter just as much as your student status.

So ask yourself, honestly:

• Am I paid by the university for work related to this project?
• Did I sign any employment or fellowship contract with IP clauses?

If the answer is yes, you cannot treat the project like a purely student-owned side project.

2. Use of “significant” university resources

Most student policies rely on a magic word: “significant”. It often appears as “significant use of university resources”.

Normal use usually does not trigger IP claims:

• Using campus Wi-Fi
• Working in public computer labs during normal hours
• Attending regular classes, standard lab sessions, or using the library

“Significant” use often includes:

• Access to specialized laboratories or equipment (3D printers, advanced microscopes, fabrication labs, wind tunnels, etc.)
• Use of university-owned proprietary software licenses that are not general campus licenses
• Substantial staff support from technicians, lab managers, or research engineers
• Use of confidential datasets or resources obtained via university agreements

The more your project depends on special university infrastructure that you could not access outside campus, the stronger the argument that the university wants a stake in the IP.

This does not mean the university will automatically own everything. Some policies say:

• The university owns patents, but students own copyrights in code and reports.
• The university gets a non-exclusive license to use your work for teaching or research, even if you own it.
• Revenue from patents is shared among inventors and the university under a set formula.

The key is to map your project usage:

• Did we only use laptops and public areas?
• Did we use special labs or machines that require permission or training?
• Did staff invest serious time outside teaching duties to help us build or test something?

Write this down. It is much easier to negotiate or clarify ownership when you have a factual record instead of a vague memory of “we were in the lab a lot”.

3. Course rules and project-specific agreements

This is the sneaky one. Many courses, hackathons, and accelerators have their own IP clauses that sit on top of the general university policy.

Common patterns:

• Standard design or software courses: often say “students own their work, but the university may reuse it for teaching and promotion”.
• Capstone / senior design projects: if there is an external sponsor (company, government, or NGO), there is frequently a separate agreement where the sponsor gets some or all IP.
• Incubators and entrepreneurship programs: may ask for a non-exclusive license to talk about your startup or use your logo, but not own it.
• Competitions and hackathons: some claim rights over submissions; others are very founder-friendly.

If you clicked “I agree” on a course or contest portal without reading the terms, you might have already assigned some IP rights.

So for each project, check:

• The course outline or syllabus (scan for “intellectual property”, “ownership”, “sponsor”).
• Any documents you signed with external partners.
• Rules of competitions where you submitted your project.

If there is a company sponsor, they often want:

• Exclusive rights to use or commercialize the project results in their field.
• The right to file patents based on your work.
• Confidentiality about certain findings.

You do not have to accept every term blindly. At minimum, ask:

• Can we keep the right to reuse the general concept for our own startup?
• Can we keep ownership of code we already wrote before the sponsored project?
• Can we publish a sanitized version for our portfolios?

Sometimes course coordinators can negotiate small adjustments if they know students are serious about building a startup out of the work.

4. Collaborators: group members, supervisors, and lab staff

This is where friendships meet law. IP law does not care who did the most procrastination. It cares who contributed to what.

For copyright (code, reports, designs), group projects usually create “joint authorship”. That means:

• Everyone who made a creative contribution is a joint owner.
• Each joint owner often has the right to use the work, but may need others’ consent for licensing or certain uses, depending on jurisdiction.
• You cannot just kick a teammate’s contribution out of a startup story because they dropped the course.

For patents, the bar is higher:

• An “inventor” is someone who helped conceive an inventive idea, not just someone who tested or built hardware.
• Supervisors and postdocs might be co-inventors if they contributed key ideas or solutions.
• Lab technicians rarely count as inventors if they only followed instructions, but specific contributions might change that.

Co-founders and co-inventors are not always the same people. One is legal; one is business. You need to untangle them early.

Things to map as a team:

• Who actually came up with the main concept or algorithm?
• Who wrote which core modules or components?
• Did any supervisor suggest the key method that made it work?

A simple practical step during the project:

• Keep a shared document that logs contributions: features, experiments, design decisions, and who proposed them.
• When the project ends, convert that into:
  • A list of authors for publications.
  • A list of inventors for any patent discussions.
  • A list of code owners if some of you want to create a startup or open-source it.

5. The university IP policy and tech transfer office

Every campus seems to hide a PDF somewhere that quietly decides half of this conversation. It usually covers:

• Who owns what by default (students vs employees).
• When the university claims patent rights.
• How revenue is shared if something is licensed or spun out.
• What role the tech transfer or commercialization office plays.

Typical patterns:

If your project has real commercial potential, you cannot skip a conversation with the tech transfer office, even if law technically favors you.

Why talk to them early?

• They can check if your project is already covered by a grant or sponsor agreement.
• They can help with patent filing timelines relative to conferences and demo days.
• They know standard deals for student spin-outs on your campus.

You are not required to accept every suggestion. But ignoring them and then asking for help after you sign something with a VC or corporate partner is a fast way to create conflicts.

Common university scenarios and who usually owns what

During a startup club workshop, we went through a series of “what if” cases. Seeing the patterns made decisions feel less mysterious.

Scenario 1: Pure coursework project, no special resources

Facts:

• Group project in a standard CS / design / business course.
• Code written on personal laptops, using public tools (GitHub, Figma, etc.).
• No company sponsor, no special lab access, no custom datasets.

Typical outcome:

• Copyright: shared among group members who contributed.
• Patents: if there is a patentable concept, it likely belongs to students as joint inventors.
• University: may have a non-exclusive license to use the project for teaching or promotion.

Practical tip:

• Agree within the team who can later turn this into a startup and whether non-founder teammates get equity or credits.

Scenario 2: Sponsored capstone with a company partner

Facts:

• Final year design project sponsored by “BigCo”.
• You signed a sponsor NDA or project agreement.
• You had access to company data or APIs that are not public.

Typical outcome:

• The sponsor may own patents and exclusive rights to the specific solution you built for their problem domain.
• You may still own your general skills, approaches, and reusable code libraries.
• Your ability to start a similar startup might be limited by confidentiality and non-compete clauses.

Questions to ask the coordinator:

• Can we build a separate version of this idea without using the sponsor’s data or secrets?
• Does the sponsor claim rights only in their field, or in all applications of the idea?
• Can we publish a sanitized case study or portfolio piece?

Scenario 3: Research project in a professor’s lab

Facts:

• You are working with a professor on a research project, maybe for thesis or as an RA.
• You use grant-funded equipment, lab space, and internal datasets.
• There may be external funders (government, industry, foundations).

Typical outcome:

• Patents: usually claimed by the university, with inventors (student, supervisor, others) sharing any revenue under policy.
• Copyright in your thesis text: usually yours, but the university has rights to archive and publish.
• Research data and lab notebooks: often owned or controlled by the university or lab.

If your “side project” runs on your supervisor’s grant, there is a strong chance it is legally not just your side project.

Practical moves:

• Clarify with your supervisor which parts of the work count as independent student IP, if any.
• Before you present at conferences, check with the tech transfer office about patent timing.
• If you want to spin out a company, ask about standard founder equity ranges for student spin-outs in your department.

Scenario 4: Hackathon or startup competition project

Facts:

• Weekend hackathon, often with sponsors and prize money.
• Submission through an online portal with terms and conditions.
• You probably clicked “I agree” at 1:48 a.m. while debugging.

Typical outcome:

• Some hackathons let teams own all IP, with sponsors getting a license to use submissions internally.
• Others are more aggressive and claim rights to any solutions built with their APIs or datasets.

Checklist:

• Read the IP clause before applying next time.
• Check whether the hackathon terms conflict with university policies if you used campus labs or were there as part of a course.
• If you want to build a startup afterward, confirm that no sponsor already has broad usage rights that kill your business model.

Scenario 5: Open-source project started for a class

Facts:

• You started a GitHub project for a course assignment.
• You later want to turn it into an open-source library or tool.

Questions:

• Can you choose the license (MIT, GPL, Apache, etc.) freely?
• Does the university or a sponsor need to agree?

Typically, if students own copyright and no sponsor is involved, you can choose the license. But:

• Co-authors must agree to the license choice.
• If there is university or sponsor code mixed in, that might limit your options.

Pushing code to GitHub does not erase existing IP rights. It just adds licensing rules on top.

Before you open-source a class project:

• Check the course policy and any sponsor agreements.
• Ask group members to confirm that they agree to the license in writing (even a group message is better than nothing).
• Make sure you are not publishing confidential data or proprietary assets.

Patents vs projects: the dangerous timing issue

One of the strangest parts of mixing research with entrepreneurship is that what your professor wants (publish fast) can conflict with what a patent attorney wants (keep it secret until filed).

Basic patent reality:

• A patent requires novelty. Public disclosure of the invention before filing can ruin that.
• Public disclosure can be:
  • A conference talk or poster
  • A published paper
  • A video demo on YouTube
  • Public GitHub code that reveals the inventive concept
  • Slides uploaded to a public site without access control

Many university policies say:

• If your work might be patentable and uses university resources, you must disclose it to the tech transfer office before public release.
• The university then decides whether to file a patent, sometimes with your input.

This creates a simple but high-stakes sequence:

1. You create something potentially patentable in a project.
2. You want to submit it to a competition, conference, or demo day.
3. Public demo might kill patent rights if filing is not done in time.

Practical approach:

• Set a mental trigger: if your project solves a technical problem in a novel, non-obvious way and you could imagine a company forming around it, talk to someone before you post it everywhere.
• Bring a short description to your supervisor or tech transfer office and ask: “Is this something we should consider for a patent?”
• If they say “maybe”, ask about timing relative to your thesis submission or conference deadlines.

Speed is great in startup culture, but IP law cares more about sequence than vibe. Public first, patent later can be a one-way door.

What about trademarks and project names?

People rarely think about trademarks during a semester, but the moment your project name sticks, it becomes relevant.

Trademarks cover:

• The name of your app, hardware, or service.
• Your logo or visual identity.
• Recognition that customers attach to your brand.

For student projects:

• Usually, the group owns the branding elements they created, unless a sponsor or course explicitly claims rights.
• Universities may want permission to mention and show your logo on their websites, but that is more about marketing than legal control.

Practical points:

• Before turning a project name into a startup brand, search existing trademarks in your country and do basic web/app store searches.
• Check if the university has any claim to the project name (rare, but check competition rules and course policies).
• If you want to be careful, file a basic trademark application when you are serious about launching, so future teams cannot claim the same name in your field.

Data, models, and AI projects on campus

During an AI course, you might casually train a model on data you got from a professor or an external partner. IP around that is its own puzzle.

Things to separate:

• Raw data: who owns or controls the dataset? It could be the university, an external partner, or a public source.
• Processed data or annotations: you might create labels or transform data in ways that carry copyright.
• The trained model weights: these might be protected as a derivative of both your code and the underlying data.
• Training code and pipeline: typically copyright held by the authors.

If the dataset:

• Is confidential or proprietary, you might not have the right to reuse it for a startup.
• Is public, then your main IP lies in your specific model architecture, training tricks, and implementation.

A model trained on restricted data can be like a passport with the wrong visa: technically impressive, practically unusable for your startup.

What to do:

• Ask who owns the data and under what license you are allowed to use it.
• If you plan a startup, try to train on data you can legally access outside the university too.
• Document how to recreate the results with alternative open datasets if needed.

How to keep your future startup alive while still in class

At some point, the project stops feeling like homework and starts feeling like a minimum viable product. That is when ownership questions stop being theoretical.

Here is a practical path that has worked for many student teams I have watched:

Step 1: Map your project’s IP reality

Create a one-page summary for your team that answers:

• Who is on the team, and what is each person’s status (student, RA, TA, etc.)?
• Which university resources did you use, beyond “normal” ones?
• Was the project sponsored by any company or external funder?
• Which course or program is this tied to, and what does that syllabus say about IP?
• Did you agree to any hackathon or competition terms?

This is not busywork. It is your foundation for any future discussion with staff, lawyers, or investors.

Step 2: Rank the pieces of IP that matter

Not all parts of your project are equally important for a future startup. Create a simple list:

• Core code or algorithm
• Hardware design or mechanical layout
• Dataset and annotation scheme
• Brand name and logo
• Any new method or process that might be patentable

Then, for each item, ask:

• Who contributed to this?
• Did we use special university resources or data to build it?
• Is this essential to our potential startup, or just course scaffolding?

Step 3: Talk to your supervisor like a future founder, not just a student

Many conflicts start because students keep everything informal until very late. A better pattern:

• Schedule a specific meeting with a clear agenda: “We think this project might have commercial potential. We want to clarify ownership and next steps.”
• Bring your one-page summary and your ranked IP list.
• Ask precise questions:
  • “Under the university policy, who would own a patent on this method?”
  • “Are there any grants or sponsors that might claim rights?”
  • “Has the tech transfer office expressed interest in similar work before?”

Your goal is not to win an argument, but to make sure there are no unpleasant surprises when money or press show up.

If your supervisor does not know the exact policy, that is not a red flag. It is normal. The goal is to get introduced to the person who does know.

Step 4: Meet the tech transfer or commercialization office early

Walk in with:

• A short description of the project and what is technically new.
• Your map of team members, resources used, and any external sponsors.
• A rough idea of your future plans (startup, license to a company, open-source, etc.).

Ask clear questions:

• “Under the policy, does the university claim ownership of any part of this?”
• “If there is a patent, how would revenue and control be shared?”
• “What typical deals have student spin-outs done in the past two years?”

You do not have to accept an arrangement that feels unfair, but going in informed is always better than avoiding the conversation.

Step 5: Agree on internal team rules

Within your student team, have the mildly awkward conversation now rather than the very awkward one later. Topics:

• Who actually wants to pursue this as a startup after the course?
• What happens if someone leaves or loses interest?
• How will you handle:
  • Equity or recognition for non-founding contributors
  • Open-sourcing parts of the project vs keeping them proprietary
  • Future contributions and decision rights

You do not need a perfect shareholder agreement on week 10 of the semester. But a simple written understanding such as:

• “If A and B form a company, C and D will receive X percent each in recognition of their contributions, subject to later formal documents.”

can prevent messy disputes when things start to look serious.

Red flags that your approach might be risky

From watching teams around campus, certain patterns usually end badly for founders:

• You are relying completely on a university-owned dataset or lab that you cannot access once you graduate.
• You strengthened your “secret sauce” during a sponsored project but never checked the sponsor’s IP rights.
• Your project requires patented technology owned by the university, and you have not discussed licensing terms.
• Your group never discussed who wrote what, and now only two of you are starting a company while others feel excluded.
• You posted the whole method and code publicly, and only months later realized it might have been patentable.

If your startup’s core asset belongs to someone else, no amount of hustle will fix that later. It is a structural problem, not a marketing one.

The fix is not paranoia. It is early, boring clarity. Read the policies, ask the blunt questions, and write down the answers. That habit is one of the most underrated skills you can gain from a “simple” university project.