Back to the topics list

Security and software licensing can present constraints and restrictions in computational design and development.

Security and Software Licensing Constraints in Programming 💻

Introduction: Code Is Powerful, But Not Free to Use Any Way You Want

Have you ever seen a cool feature in an app and thought, “I could just copy that into my project”? Or wanted to grab a code snippet from an online repository and drop it straight into your game? In the real world, programmers cannot do “anything they want” with code. They must follow security rules that protect users, and they must obey software licenses that protect creators’ rights. These rules shape what software can do, how it is built, and even whether it can be shared at all. 🔒

This lesson explores how security requirements and software licensing create constraints and restrictions in computational design and development. Understanding these limits is just as important as knowing how to write a loop or a function, especially if you ever want to release your code to the public, work for a company, or contribute to open-source projects.

Security in Computational Design and Development

When we talk about security in computer programming, we are talking about how well a system protects information and services from being stolen, changed, or broken by attackers or accidents.

Security is often described using three main goals, sometimes called the “CIA triad” (not the intelligence agency!):

• Confidentiality: Only authorized people can read the data.
• Integrity: Data and code cannot be changed in unauthorized ways.
• Availability: Systems and data are accessible when needed, not crashed or blocked.

Programmers face many security threats, such as:

• Malware (viruses, worms, ransomware) that infect systems.
• Data breaches that leak passwords, credit cards, or personal info.
• Injection attacks like SQL injection, where attackers trick the program into running malicious commands.
• Unauthorized access, such as logging in as someone else without permission.

Because of these threats, security becomes a major design requirement. That means certain designs or features are not acceptable, even if they seem easier or faster to code, because they are too risky. Security requirements limit how you store data, which libraries you use, how users interact with the system, and how information flows through your code.

How Security Requirements Shape Program Design

Security is not something you “add at the end.” It affects the structure of your program from the beginning. The way data travels from user to server, is checked, processed, and stored, must follow secure patterns, as shown in [Figure 1]. This changes what your code looks like and what is allowed.

Here are key ways security requirements impose constraints on computational design and development.

1. Authentication and Authorization

Authentication is verifying who a user is (for example, logging in with a username and password, or using multifactor authentication). Authorization is checking what that user is allowed to do (for example, can they edit someone else’s profile?).

Security requirements might force you to:

• Add a login system instead of letting users act anonymously.
• Store password hashes instead of plain passwords, so that even if the database is stolen, the attacker does not see passwords directly.
• Separate roles (admin, teacher, student, guest) with different permissions, which can complicate the code.

These constraints mean you cannot just write a quick “everyone can do everything” design, even if that would be simpler.

2. Input Validation and Sanitization

Any time a program accepts input (text boxes, file uploads, API requests), security requires that you validate and sanitize that input. You must check that it is the right type, length, and format, and remove or block dangerous content.

This leads to constraints such as:

• More code to check every field.
• Rejecting certain characters (for example, angle brackets) to prevent HTML or script injection.
• Limiting file types and sizes.

For example, if you are designing a comment system, you might want to let users post any text. Security forces you to restrict scripts or certain HTML tags to stop cross-site scripting attacks.

3. Encryption and Secure Storage

Encryption scrambles data so that only people with the correct key can read it. Security requirements may require you to use encryption for:

• Network traffic (for example, HTTPS instead of HTTP).
• Sensitive data stored in databases, such as personal information.

This introduces constraints such as:

• Having to choose and correctly configure encryption libraries.
• Managing keys safely (not hardcoding them in your source code).
• Increased CPU usage and slightly slower performance.

Sometimes a design that is fast but unencrypted must be replaced with a slower but secure design.

4. Logging, Monitoring, and Auditing

Secure systems usually keep logs of important events: logins, password changes, failed access attempts, and admin actions. This allows developers and security teams to detect attacks and investigate incidents.

This creates design requirements like:

• Storing logs in a safe place (not easily wiped by attackers).
• Ensuring that logs do not contain private data like full passwords.
• Designing the system to handle large volumes of log data without failing.

5. Trade-Offs: Security vs. Convenience and Performance 🙂

Security is full of trade-offs. Stronger security can mean:

• More steps for users (for example, two-factor authentication).
• More code to maintain (validation, encryption, access control).
• More computing resources, which can slow down the system.

Programmers must design systems that are secure enough for their purpose, without being unusable. These trade-offs are a big part of why security is a constraint on design, not just an optional extra.

Introduction to Software Licensing

Security is not the only limit on how we build software. There is also the law. When someone writes code, that code is usually protected by copyright. This means the author owns it by default, and others cannot legally use, copy, or modify it without permission.

A software license is a legal agreement that tells you what you are allowed to do with code:

• Can you copy it?
• Can you change it?
• Can you use it in commercial projects?
• Do you have to share your own code if you use it?

When you download a game, use an app, or install a library in your project, you almost always agree to a license, even if you just clicked “I Agree” without reading it. For developers, especially, licenses are very important. Using a library incorrectly can mean you are breaking the law, even if your code “works.”

Owning vs. Licensing Software

You rarely “own” software the way you own a bike. You usually get a license to use it under specific conditions. For example:

• A desktop operating system license might say you can install it on only one computer.
• A photo editing app license might say you cannot reverse engineer the app or share copies.
• A game engine library might let you use it for free in non-commercial projects but require payment for commercial use.

Developers must read and respect these terms. Just like security rules, license terms constrain what you can do in your computational projects.

Major Types of Software Licenses

There are many software licenses, but most fall into a few broad categories. It helps to know the main ideas so you can predict what constraints they might place on your project. The main categories listed here are compared visually in [Figure 2].

1. Proprietary (Closed-Source) Licenses

Proprietary software is usually closed-source. You get to use the program, but you do not get the source code, and you cannot freely modify or redistribute it.

Characteristics:

• You cannot see or change the source code.
• You cannot legally copy or distribute it except as allowed (for example, backups).
• You usually cannot use parts of it inside your own code.

Examples include many commercial apps, big desktop operating systems, and professional-grade creative tools.

2. Free and Open-Source Software (FOSS)

Free and open-source software lets you view, modify, and share the source code under certain conditions. “Free” here means “freedom,” not necessarily price.

Within FOSS, there are two major groups:

a. Permissive Licenses (for example, MIT, Apache 2.0)

Permissive licenses are relatively relaxed. They usually allow you to:

• Use the code in open or closed-source projects.
• Modify the code and keep your changes private.
• Redistribute the code, often with attribution.

The main requirement is often that you keep the original copyright notice and license text. For example, if you use an MIT-licensed library in your app, you typically just need to credit the authors and include the license.

b. Copyleft Licenses (for example, GPL)

Copyleft licenses like GPL are stricter. They allow you to view, modify, and distribute the code, but with an important condition:

• If you distribute a program that is based on GPL-licensed code, you usually must release your program’s source code under the same license.

This is sometimes called a “viral” effect, because it spreads the GPL requirements to the larger project. It creates a strong constraint on how GPL code can be used, especially in commercial or closed-source software.

3. Public Domain and CC0

Some authors release their code into the public domain or under a license like CC0 (Creative Commons Zero). This means they give up almost all rights and allow anyone to use, modify, and redistribute the code with basically no restrictions.

Public domain code is the least restrictive in terms of licensing constraints. However, it is less common for large, complex projects.

Licensing Constraints on Programming Projects

Licenses directly affect what you can combine in a project. You cannot just mix any two code libraries and release the result however you want. You must check whether their licenses are compatible, as the flow in [Figure 3] makes clear.

1. License Compatibility

Suppose you are building a mobile app. You want to use:

• A UI library under the MIT license.
• A database library under the GPL license.

If you link the GPL library into your app and distribute the app, GPL may require that your entire app be released under GPL and that you share your source code. If you or your organization want to keep the app closed-source, this is a serious problem.

In contrast, if both libraries are MIT-licensed (or other permissive licenses), you usually have far more freedom: you can keep your code closed-source or open-source it as you choose, as long as you respect attribution rules.

2. Using Libraries vs. Using APIs

There is a difference between:

• Linking to a library (actually including other people’s code in your project).
• Calling an external API over the network (sending requests to another service that runs its own code).

Licenses often mostly control the code itself. Calling an API is more about terms of service than software licenses. For example, a social media platform’s API might let you read public posts, but forbid you from storing or reselling that data. That is still a constraint on your design: you might not be allowed to build a “download everything and save forever” feature.

3. School and Company Policies

Beyond the actual license text, schools and companies often have additional rules:

• Your school might say: only use libraries approved by the teacher.
• A company might forbid using GPL libraries in commercial products because of the copyleft effect.
• Some organizations require that you document every external component, its license, and where it came from.

These policies limit your choices when designing software, even if the code itself is technically free to use under its license.

Interactions Between Security and Licensing

Security and licensing sometimes push in different directions, and sometimes they support each other.

1. Open Source: Transparency vs. Exposure

With open-source licenses, anyone can see the code. This can:

• Help security, because more people can review the code, find bugs, and submit fixes.
• Risk exposure, because attackers can study the code to find vulnerabilities.

In practice, open-source security often works well because active communities fix issues quickly. However, if a project is abandoned, its open code can become a roadmap for attackers. Programmers must design with the assumption that attackers can see the code, whether it is open-source or not.

2. Security Updates and Patching

Licensing affects how security updates happen:

• In proprietary software, only the vendor can fix vulnerabilities in the source code. Users must wait for official patches.
• In open-source projects, anyone can propose patches, and forks can appear if the original maintainers do not respond.

This changes how you design maintenance and update strategies. For example, if you depend on an open-source library that is no longer maintained, you might legally fork it and maintain your own secure version, depending on the license.

3. Illegal Copies and Security Risks

Using unlicensed or “pirated” software is not just a legal issue; it is also a security risk. Cracked versions of expensive software often contain malware. For example:

• A pirated game engine might include hidden code that steals passwords.
• A cracked productivity app might install a keylogger on your computer.

This is why many schools and companies have strict rules about only using properly licensed software. They want to avoid both legal problems and security compromises.

Real-World Case Scenarios and Best Practices

To see how all of this affects computational design, consider some real-world-style situations you might encounter.

Scenario 1: A School Web App Project

You and your classmates are building a simple web app for a school club to track events and members. You plan to host it publicly so other students can use it.

Security constraints:

• You must implement authentication so only officers can edit events and member info.
• You must hash passwords before storing them; storing plain text passwords is not acceptable.
• You must validate all input to avoid someone injecting malicious code into event descriptions.

Licensing constraints:

• For a CSS framework, you choose one under a permissive license (for example, MIT), so you can publish your project on a code-hosting site without complex obligations.
• You avoid using a GPL-licensed backend library because your teacher wants the option to deploy the app on the school’s internal servers without releasing all source code.

These choices change which technologies you can select and how you implement them, even though your main goal is just “build a useful web app.”

Scenario 2: A Startup Mobile App

Imagine you are part of a small startup building a mobile app that collects health data to give users personalized recommendations.

Security constraints:

• You must use strong encryption for any health data in transit and at rest.
• You must design the database with strict access controls so that only specific services can read sensitive fields.
• You must log access to user data for auditing, but you cannot include actual sensitive values in logs.

Licensing constraints:

• You choose a database driver under the Apache 2.0 license, which is compatible with your plan to keep the main app closed-source.
• You decide not to use a GPL-licensed analytics library because your investors want to keep your recommendation algorithm secret.

Security and licensing together heavily influence your tech stack and architecture, not just what features you dream up.

Scenario 3: A Game Mod

You want to write a mod for a popular game that adds new levels and mechanics.

Security constraints:

• The game’s developer may require that mods run in a sandboxed environment so they cannot access players’ files or accounts outside the game.
• Your mod might be reviewed for malicious behavior before being listed on official mod stores.

Licensing constraints:

• The game’s End User License Agreement (EULA) might allow mods but forbid selling them without permission.
• The EULA might forbid decompiling or reverse engineering the game’s core executable.

So, even though you can code, you must play by both security and licensing rules set by the original game creator.

Best Practices for Students and New Developers 💡

• Think about security from the start. Ask: what data needs protection? Who should have access?
• Use well-known, maintained libraries for security-critical tasks like encryption and authentication, and keep them updated.
• Always check the license of libraries, frameworks, and code snippets before including them.
• Document every third-party component in your project, including name, version, source, and license.
• Follow your school’s or organization’s policies on acceptable software and licenses.

Summary of Key Points ⭐

Security and software licensing are two major forces that constrain and guide computational design and development.

• Security focuses on protecting confidentiality, integrity, and availability. It leads to design requirements like authentication, authorization, input validation, encryption, logging, and careful handling of sensitive data. These requirements limit “quick and easy” solutions and create trade-offs with usability and performance.
• Software licensing is about the legal rights to use, modify, and share code. Proprietary licenses are restrictive and usually keep code closed. Open-source licenses, including permissive (like MIT and Apache) and copyleft (like GPL), allow more freedom but impose different obligations, especially around whether you must share your own source code.
• Licensing creates constraints on which libraries and frameworks you can use together and how you can distribute your projects. License compatibility is critical when combining multiple components.
• Security and licensing interact: open-source code can be reviewed for security but also studied by attackers; legal use of software also reduces security risks from pirated, malware-infected copies.
• Real-world projects—from school apps to commercial products and game mods—must respect both sets of rules. Successful developers learn to design software that is secure, legally compliant, and still useful and user-friendly.