Guide to Open-Source values and the two most-seen licenses you’ll meet early on: MIT (permissive) and GPL (copyleft).

1) What “open source” means (the values)

Open source isn’t just “free downloads.” It’s software you can:

1.   Use for any purpose

2.   Study the source code

3.   Modify it

4.   Share it (original or modified)

Why it matters (student edition):

·         Transparency & learning: you can read real code, not just slides.

·         Collaboration: issues, pull requests, code reviews—industry habits.

·         Reproducible science/engineering: others can verify/extend your work.

·         Security & quality: more eyes → bugs found/fixed faster.

·         Career: your GitHub history is a living portfolio.

2) Two big license families

·         Permissive (easier reuse): MIT, BSD, Apache-2.0

o    You can even use in closed-source apps, as long as you keep notices.

·         Copyleft (share-alike): GPL, LGPL, AGPL

o    If you distribute a derivative work, you must keep it open under the same license.

Think of it like photo licenses: permissive ≈ “use with credit”, copyleft ≈ “use with credit and share edits under same rules.”

3) MIT License (permissive)

What it allows: reuse, modification, private or commercial use, sublicensing.
Your obligations when distributing:

·         Keep the copyright notice and license text in the source (and in binary distributions, ship them in docs/about).

·         Accept the “no warranty” disclaimer.

What it doesn’t force:

·         You don’t have to open your modified source if you distribute binaries.

·         No explicit patent grant (often fine for student work; companies sometimes prefer Apache-2.0 for explicit patents).

Good for: libraries, teaching projects, starter templates, anything you want maximum adoption for.

4) GPL (GNU General Public License) (strong copyleft)

Core rule: if you distribute a derivative work of GPL code (e.g., your program links to it), you must:

·         License the whole derivative under the GPL, and

·         Provide the complete corresponding source (including your changes and build scripts),

·         Include the GPL text and notices.

What it doesn’t require:

·         If you only run the program privately (no distribution), you don’t have to publish changes (AGPL is different; see note).

Versions (quick view):

·         GPLv2: classic.

·         GPLv3: adds protections (anti-“tivoization” → users must be able to install modified firmware on “user products”), clearer patent terms, better license compatibility rules.

Good for: ensuring improvements stay open, community infrastructure, research tools meant to remain public.

AGPL note (just awareness): AGPL is like GPL plus “network copyleft”: if users interact with your modified program over a network, you must offer source even if you don’t ship binaries.

5) MIT vs GPL — quick comparison

6) Typical BTech scenarios

A) Class library/template you want juniors to reuse
→ MIT. Add a LICENSE file and a short header in key files. Done.

B) You fork a GPL tool, add features, and post binaries
→ You must publish your source and keep it GPL; ship the GPL text & notices.

C) You mix MIT library into a GPL project
→ Entire result is GPL when distributed. This is allowed (MIT is compatible), but the combined distribution inherits GPL terms.

D) You only run a modified GPL program on your own server
→ GPL doesn’t force publishing (no distribution). AGPL would.

7) How to choose (student decision mini-tree)

·         Want max adoption (including companies)? → MIT (or Apache-2.0 if patents worry you).

·         Want guarantee that improvements remain open? → GPLv3.

·         Building a library meant for diverse ecosystems? → MIT/Apache-2.0.

·         A server app where you want network users to get source? → consider AGPLv3 (advanced).

8) Compliance checklists

When you use MIT code in your project:

·         Keep the LICENSE and copyright notice.

·         Mention the dependency and license in your README/about.

·         No need to publish your source (unless other licenses require it).

When you use GPL code and you distribute your program:

·         Make your combined work GPL.

·         Provide complete source and build instructions.

·         Include the GPL license text and notices.

·         If it’s a “user product,” provide install information (v3 anti-tivoization).

·         Don’t add extra restrictions beyond GPL.

9) Practical files to add to your repo

LICENSE (MIT example)

MIT License

Copyright (c) 2025 <Your Name>

Permission is hereby granted, free of charge, to any person obtaining a copy

...

GPL projects usually include:

·         COPYING (the GPL text),

·         LICENSE (sometimes same as COPYING),

·         Headers in source files pointing to the license,

·         Instructions on getting the full corresponding source.

Source header (MIT example)

/* Copyright (c) 2025 Your Name

 * Licensed under the MIT License. See LICENSE file in the project root.

 */

10) Gotchas & tips

·         Linking & derivatives: GPL treats most linking (static/dynamic) as creating a derivative work when distributed. That triggers copyleft. (Edge cases exist—keep it simple for class work.)

·         Mixing licenses: MIT → GPL is fine; GPL → MIT is not.

·         Patents: For student work, MIT is usually fine; for company-friendly permissive with explicit patent grant, consider Apache-2.0.

·         No “license by README only”: Always add a LICENSE file at repo root.

·         “Or later” clause: “GPL-3.0-or-later” lets users adopt newer GPL versions automatically; “only” locks to that version.

Exam-ready bullets

·         Open source = use, study, modify, share.

·         MIT = permissive: keep notices; can be used in closed source; no source-sharing obligation.

·         GPL = copyleft: if you distribute derivatives, you must GPL the whole work and provide source.

·         MIT code can be included in a GPL project; not the other way around.

·         GPLv3 adds stronger user freedoms (anti-tivoization) and clearer patent terms.

·         For explicit patent grant in permissive licenses, look at Apache-2.0 (FYI).

If you want, I can:

·         add a ready-to-use LICENSE file to your repo (MIT or GPL),

·         draft a short “Licensing” section for your README, or

·         build a one-page slide comparing MIT vs GPL for your class.