A software license defines what you may and may not do with software, hardware, or a service. For a technology team, licensing is both a purchasing decision and an ongoing compliance responsibility: paying for access does not, by itself, establish that a particular use is permitted. Keep the terms accessible, and seek legal advice before agreeing to language you do not fully understand. section 10.5 section 10.0
For purchased software, assess the license alongside setup costs, annual or usage fees, support, and the time needed to configure the product. Then check actual use against the terms. A private or student license may not permit commercial work; changes in virtualization, processor capacity, or cloud deployment may also affect what a vendor requires. Recheck the fine print when the environment changes rather than assuming yesterday’s entitlement still applies. section 8.2.1 section 10.3
Open-source code needs the same attention. Access to source code does not grant ownership or unrestricted permission to reuse it. Copyleft licenses such as the GPL can require software using the licensed code, including modifications, to be released under the GPL. Permissive licenses such as BSD, MIT, and Apache allow proprietary commercial use, though some require a public notice. Details concerning copyright, patents, and derivative works can matter when making significant changes; do not treat every license within a broad category as interchangeable. section 8.7.1
A small dependency with a lasting obligation
A developer imports an npm module or copies a block from an open-source library. Record its source and licensing terms when it enters the project, even if it seems minor. Copying a permitted code block should be registered like incorporating the whole library. That record can later support an audit, a renewal or upgrade decision, or due diligence on whether the company owns and may use its code. section 11.2.12 section 8.7.4
Make license control a routine rather than an audit-day scramble:
- Maintain a shared register of purchased and open-source software. For purchases, capture acquisition date, renewal date and cost, contacts, internal usage, and license keys or codes; for dependencies, capture source and terms. section 10.3 section 11.2.12
- Update the record with each purchase, renewal, or new dependency, and review purchased licenses at least every six months. A shared spreadsheet may be enough before dedicated software is worthwhile. section 10.3 section 11.2.12
- Ask whether every third-party license and restriction is known, whether current use fits its terms, and whether open-source obligations are being honored. Bring uncertain legal interpretations to counsel. section 10.6 section 14.5.1 section 10.0
