Last Updated: November 20, 2025
Introduction
Every time you write code, create a database schema, or develop a software application, you’re creating intellectual property that’s automatically protected by copyright. But copyright alone doesn’t tell others how they can use your work—that’s where software licenses come in.
Software licensing is one of the most important yet often misunderstood aspects of computer engineering practice. Whether you’re developing proprietary applications for a company, contributing to open source projects, or building your own software products, understanding software licenses is essential for both protecting your work and respecting others’ rights.
As computer engineers in the Philippines, we work in an increasingly interconnected global software ecosystem. The code we write often incorporates libraries, frameworks, and tools created by others, each with its own license. Making the wrong choice about licensing—or worse, ignoring licenses altogether—can lead to legal problems, limit your ability to commercialize your work, or inadvertently give away rights you intended to keep.
This comprehensive guide will help you understand the landscape of software licensing, from permissive open source licenses to restrictive commercial agreements. You’ll learn how to choose the right license for your projects, ensure compliance when using third-party code, and navigate the legal requirements specific to the Philippines.
What is a Software License?
A software license is a legal instrument that governs the use, modification, and distribution of software. It’s essentially a contract between the copyright holder (the person or entity who created or owns the software) and users, specifying what they can and cannot do with the software.
Without a license, copyright law provides strong default protections: nobody can legally copy, modify, or distribute your software without your permission. A license explicitly grants specific permissions while potentially imposing conditions or restrictions.
Why Licenses Matter
Software licenses serve several critical functions:
- Define Permissions: They specify what users can do with the software—use it, modify it, redistribute it, or use it commercially
- Set Conditions: They may impose requirements, such as attribution, sharing modifications, or maintaining the same license
- Limit Liability: They typically include disclaimers that limit the developer’s legal liability
- Protect Rights: They help copyright holders retain control over their work
- Enable Collaboration: They create legal frameworks for collaborative development
- Support Business Models: They enable various commercialization strategies
The Foundation: Copyright Protection
Before diving into specific licenses, it’s important to understand that software licensing is built on copyright law. In the Philippines, under the Intellectual Property Code (RA 8293), computer programs are protected as literary works under copyright law.
Key copyright principles for software:
- Automatic protection: Copyright protection exists the moment you create original code—no registration required
- Exclusive rights: Copyright holders have exclusive rights to reproduce, modify, and distribute their work
- Default restriction: Without a license, others cannot legally copy, modify, or distribute your code
- Expression, not ideas: Copyright protects the code itself, not the underlying ideas or algorithms
This is why even code without an explicit license is protected—the copyright holder simply hasn’t granted permission for others to use it. If you find code online without a license, you cannot legally use it without obtaining permission from the copyright holder.
Types of Software Licenses
Software licenses fall into several broad categories, each with different philosophies and practical implications.
1. Proprietary (Closed Source) Licenses
Proprietary licenses grant users limited rights to use software while maintaining tight control over the source code and how the software can be used, modified, and distributed.
Characteristics:
- Source code is typically not available
- Users cannot modify the software
- Redistribution is usually prohibited
- Often requires payment or subscription
- May have usage restrictions (number of installations, geographic limits, etc.)
Common models:
- Perpetual licenses: One-time purchase for indefinite use
- Subscription licenses: Recurring payment for continued access (SaaS)
- Per-seat licenses: License fee based on number of users
- Enterprise licenses: Organization-wide usage rights
2. Open Source Licenses
Open source licenses grant users freedom to use, study, modify, and distribute software. They make source code publicly available and encourage collaborative development. However, they vary significantly in the conditions they impose.
Open source licenses are generally divided into two main philosophies:
A. Permissive Licenses
Permissive licenses place minimal restrictions on how software can be used and redistributed. You can modify the code, incorporate it into proprietary products, and distribute it under different terms.
B. Copyleft (Restrictive) Licenses
Copyleft licenses require that derivative works maintain the same open license. They ensure that software remains free and open, preventing proprietary appropriation.
3. Public Domain / No License
Some software is placed in the public domain or released with dedications that waive all rights. This grants maximum freedom but provides no legal protections for the original author.
Popular Open Source Licenses: A Detailed Comparison
Let’s examine the most commonly used open source licenses that computer engineers encounter.
MIT License
Type: Permissive
Philosophy: The MIT License is one of the most permissive and simplest open source licenses. It essentially says: “Do whatever you want with this code, just keep the copyright notice and don’t blame me if something goes wrong.”
Key Features:
- Very short and easy to understand
- Allows commercial use
- Allows modification and distribution
- Can be incorporated into proprietary software
- Only requirement: include the original license and copyright notice
- No requirement to share modifications
- Includes liability disclaimer
Best for: Projects where you want maximum adoption and don’t care if others create proprietary derivatives.
Used by: jQuery, Rails, Node.js, React, Angular
Apache License 2.0
Type: Permissive
Philosophy: Similar to MIT but with explicit patent grants and more detailed legal language. It addresses concerns about patent litigation and provides better legal clarity.
Key Features:
- Allows commercial use and modification
- Explicit patent license grant (contributors grant patent rights)
- Patent retaliation clause (if you sue for patent infringement, you lose license rights)
- Requires preserving copyright notices
- Requires stating significant changes
- Can be incorporated into proprietary software
- More detailed and legally explicit than MIT
Best for: Projects where patent protection is important, or projects that want permissive licensing with better legal clarity.
Used by: Android, Apache web server, TensorFlow, Kubernetes
BSD Licenses (2-Clause and 3-Clause)
Type: Permissive
Philosophy: Very similar to MIT, originating from Berkeley Software Distribution. The 2-clause BSD is nearly identical to MIT, while the 3-clause version adds a prohibition on using the project’s name for endorsement.
Key Features (3-Clause BSD):
- Allows commercial use and modification
- Requires copyright notice in redistributions
- Prohibits using names of contributors for endorsement without permission
- No requirement to share source code of modifications
- Can be incorporated into proprietary software
Best for: Projects wanting permissive licensing with explicit prohibition on name misuse.
Used by: FreeBSD, NetBSD, many academic projects
GNU General Public License (GPL) v3
Type: Strong Copyleft
Philosophy: Software freedom must be preserved. If you use GPL code, your entire project must be open source under GPL. This ensures that software remains free and prevents proprietary appropriation.
Key Features:
- Allows use, modification, and distribution
- Requires sharing source code of distributed modifications
- Requires same license for derivative works (viral/copyleft)
- Cannot be incorporated into proprietary software
- Includes patent license grant
- Prohibits “tivoization” (v3)
- Compatible with other GPL-licensed code
Best for: Projects where you want to ensure all improvements remain open source and prevent proprietary forks.
Used by: Linux kernel (v2), Git, GIMP, WordPress (v2)
Important Warning for Computer Engineers: Using GPL-licensed libraries in your project typically means your entire project must be GPL-licensed. This is the most significant consideration when choosing whether to use GPL code.
GNU Lesser General Public License (LGPL)
Type: Weak Copyleft
Philosophy: A compromise between GPL and permissive licenses. The library itself must remain open, but applications that use it can be proprietary.
Key Features:
- Allows linking to proprietary code
- Modifications to the library itself must be LGPL
- Applications using the library can be proprietary
- Users must be able to replace the LGPL library
Best for: Libraries you want to be widely adopted, including in proprietary software, while keeping the library itself open.
Used by: Qt (dual-licensed), GNU C Library
Mozilla Public License 2.0 (MPL)
Type: Weak Copyleft (File-level)
Philosophy: A middle ground that operates at the file level. Modified MPL files must remain MPL, but you can combine them with proprietary files.
Key Features:
- File-level copyleft (not project-level like GPL)
- Can combine MPL files with proprietary files
- Modifications to MPL files must be shared
- Includes patent grant
- Compatible with GPL and LGPL
Best for: Projects wanting some copyleft protection while allowing proprietary integration.
Used by: Firefox, Thunderbird, LibreOffice
Quick Comparison Table
| License | Type | Commercial Use | Modify | Distribute | Private Use | Must Share Changes | Can Make Proprietary |
|---|---|---|---|---|---|---|---|
| MIT | Permissive | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ |
| Apache 2.0 | Permissive | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ |
| BSD 3-Clause | Permissive | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ |
| GPL v3 | Strong Copyleft | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ |
| LGPL | Weak Copyleft | ✓ | ✓ | ✓ | ✓ | ✓ (library only) | ✓ (app, not library) |
| MPL 2.0 | Weak Copyleft | ✓ | ✓ | ✓ | ✓ | ✓ (modified files) | ✓ (new files) |
How to Choose the Right License for Your Project
Choosing a license is a strategic decision that depends on your goals, audience, and business model. Here’s a practical framework for making this decision:
Decision Tree
1. Is this a commercial/proprietary project?
- Yes: Use a proprietary license
- No: Continue to question 2
2. Do you want to share your code openly?
- No: Use a proprietary license or no license
- Yes: Continue to question 3
3. Do you want to prevent others from making proprietary versions?
- Yes: Use GPL (strong copyleft)
- No, but I want modifications to remain open: Use LGPL or MPL (weak copyleft)
- No, I don’t care: Continue to question 4
4. Do you need explicit patent protection?
- Yes: Use Apache 2.0
- No: Use MIT or BSD
Considerations by Project Type
For Libraries and Frameworks:
- Want maximum adoption? → MIT or Apache 2.0
- Want library improvements to remain open? → LGPL or MPL
- Want to prevent proprietary forks? → GPL
For Applications:
- Want community contributions while preventing proprietary competition? → GPL
- Want flexibility for future commercialization? → MIT or Apache 2.0
- Want to build a business around it? → Consider dual licensing
For Academic/Research Projects:
- Want maximum citations and adoption? → MIT or BSD
- Want to ensure improvements are shared? → GPL
License Compatibility
One of the most complex aspects of software licensing is ensuring compatibility when combining code from multiple sources. Not all licenses can be combined legally.
Key Compatibility Rules
- Permissive licenses are generally compatible with everything: MIT, BSD, and Apache code can typically be incorporated into GPL, proprietary, or other projects
- GPL is one-way compatible: You can use permissive-licensed code in GPL projects, but you cannot use GPL code in permissive or proprietary projects
- Different versions of GPL may not be compatible: GPLv2 and GPLv3 are not always compatible unless the license says “or later”
- Some licenses are incompatible with GPL: Apache 1.x and some other licenses cannot be combined with GPL
Practical Compliance Tips
- Track dependencies: Maintain a list of all third-party code and their licenses
- Check before adding: Verify license compatibility before incorporating third-party code
- Use tools: Employ automated tools to scan for license compliance
- Preserve notices: Always include required copyright and license notices
- Document everything: Keep records of what licenses apply to what code
Software Licensing in the Philippine Context
While international open source licenses are generally valid in the Philippines, there are specific Philippine legal requirements that computer engineers should be aware of.
Relevant Philippine Laws
- Intellectual Property Code (RA 8293): Provides copyright protection for software and establishes the legal framework for licensing
- E-Commerce Act (RA 8792): Provides legal framework for electronic contracts, including software license agreements
- Data Privacy Act (RA 10173): Affects software that processes personal data, regardless of license type
Technology Transfer Arrangements
For commercial software licensing in the Philippines, technology transfer arrangements must comply with the Intellectual Property Code. This includes:
- Licensing of computer software (except mass-market software)
- Transfer of systematic knowledge for product manufacture or service delivery
- Management contracts involving technology
These arrangements must avoid prohibited clauses such as restrictions on research, unreasonable pricing, or mandatory purchase clauses that the IP Code deems unenforceable.
Best Practices for Computer Engineers
When Creating Software
- Always include a LICENSE file: Make your licensing explicit—don’t leave it ambiguous
- Include copyright notices: Add copyright notices to your source files
- Choose early: Decide on a license before releasing code publicly
- Be consistent: Use the same license throughout your project unless you have good reason not to
- Consider your dependencies: Ensure your chosen license is compatible with all dependencies
When Using Third-Party Code
- Read the license: Always check what license applies before using code
- Understand obligations: Know what the license requires you to do
- Comply fully: Follow all license requirements (attribution, sharing changes, etc.)
- Track dependencies: Maintain a list of all third-party components and their licenses
- When in doubt, ask: Contact the copyright holder if licensing is unclear
In Employment
- Review your contract: Understand what your employer claims ownership of
- Clarify personal projects: Get written agreement about ownership of side projects
- Respect company IP: Don’t reuse company code in personal projects without permission
- Document contributions: Keep records of what you create and when
Frequently Asked Questions
1. Can I change my project’s license later?
Yes, but it’s complicated. If you own all the copyright (no contributors or you have agreements from all contributors), you can change the license. However, code already released under the old license remains under that license. For projects with many contributors, relicensing requires obtaining permission from all copyright holders.
2. What if I find code on GitHub without a license?
Code without an explicit license is protected by copyright with all rights reserved. You cannot legally use it without obtaining permission from the copyright holder. Contact the author to request they add a license or grant you permission.
3. Can I use GPL code in my proprietary product?
Generally, no. GPL requires that derivative works also be GPL-licensed and open source. If you incorporate GPL code into your product, your entire product typically must be GPL. Consider using LGPL libraries or seeking dual licensing.
4. Do I need to register my software license in the Philippines?
No, copyright (and thus licensing rights) is automatic. However, registration with the National Library provides additional legal benefits, including presumption of ownership.
5. What’s dual licensing?
Dual licensing offers software under two licenses simultaneously—typically GPL for open source use and a commercial license for proprietary use. This business model allows companies to monetize open source software while keeping it free for the community.
Conclusion
Software licensing is a critical aspect of computer engineering practice that affects how you create, share, and commercialize software. Understanding the landscape of licenses—from permissive MIT and Apache to copyleft GPL—empowers you to make informed decisions that align with your goals.
Remember these key principles:
- Always use an explicit license for your code
- Always check licenses before using third-party code
- Understand the implications of different licenses for your business model
- Ensure license compatibility when combining code
- Comply fully with all license requirements
- When in doubt, consult with a legal professional
As computer engineers in the Philippines, we participate in a global software ecosystem governed by both international licensing norms and local legal requirements. By understanding and properly applying software licenses, we protect our work, respect others’ rights, build sustainable businesses, and contribute responsibly to the technological commons.
The choice of license is not just a legal formality—it’s a strategic decision that reflects your values, defines your relationship with users and contributors, and shapes the future of your project. Choose wisely, comply diligently, and help build a thriving software ecosystem in the Philippines and beyond.
References
- Endor Labs. (n.d.). Open Source Licensing Simplified: A Comparative Overview of Popular Licenses. Retrieved from https://www.endorlabs.com/learn/open-source-licensing-simplified-a-comparative-overview-of-popular-licenses
- Wikipedia. (2024). Comparison of free and open-source software licenses. Retrieved from https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses
- Exygy. (n.d.). Which License Should I Use? MIT vs. Apache vs. GPL. Retrieved from https://www.exygy.com/blog/which-license-should-i-use-mit-vs-apache-vs-gpl
- Morin, A., Urban, J., & Sliz, P. (2012). A Quick Guide to Software Licensing for the Scientist-Programmer. PLOS Computational Biology. Retrieved from https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1002598
- OSS Software. (n.d.). Open Source Licenses Explained: A Comparison. Retrieved from https://osssoftware.org/blog/open-source-licenses-explained-a-comparison/
- BCCS Law. (n.d.). Technology Transfer, Licensing and Franchising. Retrieved from https://bccslaw.com/technology-transfer-and-licensing/
- NDV Law. (n.d.). Licensing Agreements in the Philippines. Retrieved from https://ndvlaw.com/licensing-agreements-in-the-philippines/
- Teldat. (n.d.). Open source software licences differences. GPL, BSD, MIT. Retrieved from https://www.teldat.com/blog/open-source-software-licenses-coyleft-gpl-bsd/
- LicenseSpring. (n.d.). How to License Your Software [GUIDE]. Retrieved from https://licensespring.com/blog/guide/how-to-license-your-software
Disclaimer: This article is for educational purposes only and does not constitute legal advice. Software licensing is a complex legal area. For specific licensing questions or concerns, consult with a qualified intellectual property attorney. Laws and license interpretations may evolve; always verify current requirements.
Article Length: Approximately 4,100 words
Target Audience: Computer Engineering students and professionals in the Philippines
Category: CpE Laws and Professional Practice
Tags: Software Licensing, Open Source, GPL, MIT License, Apache License, BSD License, Copyright, Licensing Guide, Computer Engineering Law, Philippines