This semester I finally sat down and untangled the confusing world of software licenses, starting from a basic question: what can you actually protect when you write code? One of the first things I learned is that you cannot copyright a mere idea for a program; copyright law only protects the concrete expression, like source code saved to disk. As soon as that code is written and fixed in a tangible form, copyright protection arises automatically, without any registration step. So when I turn an idea into a working program, the software itself is copyrightable even if I never file paperwork or add a © symbol. What I do need to add is a license, which tells other people how they are allowed to use the code I already own by default.
Digging deeper, I learned that copyright is really a bundle of exclusive rights: to reproduce the work, make derivative versions, distribute copies, perform it, and display it. For software, that translates into controlling who can copy the code, modify it, run it, and share it with others. That also answered a classic classroom scenario: if I find code on a website with no license file and no notice, the default is that it is still fully protected, and I am only safe to read it, not copy or reuse it. Lack of a visible license does not mean the author has given up any of these rights.
A license sits on top of copyright and simply grants some of those rights to others under certain conditions, without the author giving up ownership. That means I can publish my code under one license today and later relicense new versions under a different one, while earlier releases remain usable under the terms they were originally offered with. In class we compared permissive licenses like MIT and Apache 2.0, which allow broad reuse, modification, and even relicensing, with copyleft licenses like GPLv3 that require derivative works to stay under the same license when distributed. Sites like tldrlegal and choosealicense break this down into the “can,” “cannot,” and “must” for each license—commercial use, distribution, attribution requirements, patent grants, and so on—which made those abstract rules feel much more concrete.
Open-source does not magically remove copyright; instead, it is the license that decides whether someone can sell copies, build closed-source products on top, or must keep their changes open. For educational use on class projects, the MIT License is simple, permissive, and friendly to both open-source and commercial use. For the documentation, Creative Commons Zero (CC0) is best as it waives copyright interests and dedicates the text to the worldwide public domain so anyone can reuse it without worrying about conditions. In the end, I learned that picking a license is not just a legal afterthought, it is how developers communicate the rules of the road for their work.
Resources:
choosealicense – This site explains common open-source licenses like MIT, GPLv3, and Apache 2.0 in a beginner-friendly way and clarifies the difference between permissive and copyleft licenses, which ties directly into my class discussion.
https://www.tldrlegal.com – TLDRLegal summarizes licenses into “can,” “cannot,” and “must,” which is the same framework we used in our class activities. It is a great example to share with beginners who want the legal terms translated into more approachable language