UPI Study › Courses › Ethics in Technology › Free lessons › Lesson 11.7 Free with a free account
Open Source and Software Ownership
Ethics in Technology · Chapter 11: Secure Tunnels, Digital Rights, and Intellectual Property in a Connected WorldSection 11.7 · lesson 64 of 11614 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Ethics in Technology.
Lesson complete
Earn the 3 college credits for Ethics in Technology
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: The Laws That Protect Your Personal Data and Control How Organizations Use It →← Intellectual Property in a Digital WorldNext lesson: The Laws That Protect Your Personal Data and Control How Organizations Use It →
In this lesson
Broad permissions, reciprocal obligations, and sustainable development.
- Define open source and distinguish it from merely visible source code.
- Compare permissive, weak copyleft, strong copyleft, and network obligations.
- Apply license compliance to downloadable apps and server-only services.
- Explain ownership, forks, business models, and maintenance responsibility.
Free study notes
Get this lesson's notes by email
The key points and 4 practice questions with answers, in your inbox. One email, free.
One email. Unsubscribe in one click.
Transcript
Everything said in the video, section by section (1,679 words). Read along, or search it.
Chapter 11
Open Source and Software Ownership
Open source software challenges the idea that value depends on exclusive control over copying. Its authors can retain copyright while giving users broad permissions through a license. Those permissions include using, studying, modifying, and sharing code under specified conditions. Simply publishing source code does not prove that its license meets the open source definition. We will compare permissive, weak copyleft, strong copyleft, and network-related obligations. Different conditions apply to covered code, different program structures, and different delivery methods. A downloadable application differs from code operating only on a company’s server. Even a website can distribute client software, so the actual technical delivery matters. Compliance includes inventory, compatibility review, required notices, and appropriate source delivery. We will also examine forks, licensing changes, business models, and maintenance responsibility. The central lesson is broad permission with defined obligations, rather than the disappearance of ownership.
Definition and History
Open Source Requires Permissions, Rather Than Source Visibility Alone
Source code means the preferred human-readable form for modifying a program. The free software movement developed in the nineteen eighties, emphasizing users’ freedoms. The open source term was adopted in nineteen ninety-eight, with a business-oriented presentation. The Open Source Initiative maintains ten criteria for qualifying distribution terms. Copies may be given away or sold, and appropriate source must be available. Modifications and derived works must be allowed, with certain permitted author-integrity conditions. A license cannot discriminate against people, groups, or fields such as business and research. Relevant rights follow redistributed copies and cannot depend solely on one particular product bundle. The definition also protects independent bundled software and requires technology-neutral terms. A proprietary or restricted source-available license may fail those criteria despite visible code. Linux, Apache, Python, and many libraries are used throughout digital infrastructure and application development.
Ownership and Forks
Authors Can Retain Copyright While Granting Broad, Conditional Permissions
Open source authors generally use copyright to grant permissions, rather than necessarily surrendering ownership. A project’s rights may belong to contributors, employers, or assignees. Relicensing existing code requires the relevant authority, and contributor agreements can grant defined rights. A project cannot simply erase compliant users’ existing grants by changing a later release. However, violating conditions can affect license rights, so continuing compliance matters. A fork lets a community continue appropriately licensed code under an independent project identity. Terraform’s twenty twenty-three licensing change prompted the OpenTofu fork. Redis’s twenty twenty-four change prompted Valkey, based on Redis seven point two point four. Redis then added an open AGPL version-three option with Redis eight, in May twenty twenty-five. Licensing history must therefore be tied to particular versions, rather than treated as permanently static. Log four Shell, in twenty twenty-one, also highlighted dependence on shared code and the need for sustainable maintenance.
License Families
The Important Difference Is the Scope and Trigger of Obligations
Permissive licenses generally allow proprietary derivatives while their conditions are satisfied. Examples include MIT, BSD variants, and Apache version two. Weak copyleft limits reciprocal obligations to particular covered files or libraries. The Mozilla Public License and Lesser GPL illustrate different weak-copyleft scopes. Strong copyleft requires reciprocal terms and corresponding source for distributed covered derivative or combined programs. The GPL is the central example, but its exact version matters. The Affero GPL adds an obligation for modified covered versions supporting remote network interaction. A proprietary license can restrict copying or modification, even if source is visible. These categories describe obligations and triggers, rather than a numerical ranking of everyone’s freedom. Permissive integration choices and copyleft’s protection for downstream users serve different priorities. Neither approach automatically licenses every unrelated patent, trademark, or asset connected to a product.
MIT and Apache 2.0
Permissive Terms Still Carry Concrete Conditions
The MIT license permits broad use, modification, redistribution, sublicensing, and sale. It also requires copyright and permission notices in copies or substantial portions. It does not impose a general duty to publish modifications. Apache version two also permits proprietary derivatives, but gives more detailed redistribution conditions. Recipients need the license, applicable notices, relevant NOTICE attributions, and appropriate modified-file markings. Its express patent grant covers defined contributor-licensable claims connected to covered contributions. That grant does not promise a license to every patent the contributor owns. The defined patent-litigation clause can terminate the granted patent license for the work. It concerns specified infringement allegations, rather than every unrelated lawsuit involving a patent. MIT lacks that comparable express clause, which does not resolve every possible patent defense. Both licenses disclaim warranties, while paid support or separate service commitments can provide additional value.
GPL, LGPL, MPL, and AGPL
Covered Program Structure and Delivery Determine the Source Obligation
GPL distribution requires the prescribed terms and Corresponding Source for the covered program. A combined derivative can have broader obligations than the original library alone. Mere aggregation of separate independent programs does not automatically place unrelated code under the GPL. The structure, linking, version, exceptions, and actual delivery therefore require assessment. The LGPL can allow a separate proprietary application to use a covered library. Library source, notices, and applicable relinking or replacement conditions still matter. The Mozilla Public License uses file-level copyleft for covered files. New separate files can use other terms under its larger-work conditions. Ordinary GPL server operation does not trigger source distribution merely because users interact remotely. A modified network-interactive AGPL version must offer its covered Corresponding Source to relevant remote users. These rules concern the covered version, rather than every unrelated private company repository.
Three-License Comparison
Match the Exact License and Component Version
Now compare the MIT, Apache version-two, and GPL version-three licenses side by side. MIT and Apache are permissive, while GPL version three is strong copyleft. All carry notice obligations, but the details and source requirements differ. Apache and GPL version three contain express patent provisions with defined scope. MIT has no comparable express contributor patent-grant clause. For distributed covered GPL derivatives, corresponding source and reciprocal rights accompany the required compliance route. Representative examples include React and Node dot J S under MIT-associated licensing. Kubernetes and many Android components use Apache licensing, while Android contains other licenses too. Linux uses GPL version two, and WordPress uses version two or later. Those examples should not be mislabeled as GPL version-three-only projects. Apache code can enter a GPL version-three work, but ordinary GPL version-two-only combination is generally incompatible.
License Compliance
Inventory, Assess, Satisfy Conditions, and Review Actual Releases
License compliance means meeting the conditions that actually cover the software used and delivered. First, inventory components, versions, origins, and licenses, often through a software bill of materials. Second, scan dependencies and copied code, then investigate findings rather than trusting a tool blindly. Third, assess compatibility using exact versions and the way components combine. Fourth, supply required notices, license text, change statements, and appropriate corresponding source. Fifth, establish a policy defining approved uses and combinations requiring review. Sixth, review the actual release or acquisition, including inherited obligations. In Jacobsen versus Katzer, two thousand eight, relevant open-license conditions could support copyright enforcement. The case did not establish that every possible breach has an identical legal result. Consumer-device GPL enforcement illustrates why source delivery and notices must match the actual product. No purchase fee is necessary for a license condition to be legally meaningful.
Worked Photo-Editing App
Assume the GPL Engine Forms a Covered Combined Program in the Downloaded Product
Consider the startup’s downloadable photo-editing app, containing four differently licensed components. MIT image filters require preserved copyright and permission notices, while proprietary changes can remain closed. Apache storage code requires its license, relevant attributions, and modified-file markings. The LGPL decoder has covered-library source duties and applicable linking or replacement conditions. A compliant separate application can remain proprietary, but those duties cannot simply be ignored. For the GPL face-detection engine, assume integration forms a covered combined program. The distributed covered program then needs GPL rights and required Corresponding Source. A separate independent program would require a different scope assessment, rather than the same automatic answer. An AGPL alternative also adds its modified-network-version source-offer obligation. The startup can charge for open source copies; charging does not defeat the license. A suitable permissive replacement or properly authorized commercial license may support a closed combined product.
Server-Only Service Comparison
A Website Can Still Distribute Code, So Identify What Actually Reaches Users
Now assume those libraries operate entirely on the startup’s server. Remote interaction alone does not ordinarily trigger Apache, LGPL, or GPL redistribution duties. That is different from claiming every license obligation disappears. MIT still requires notices in copies or substantial portions, though not public source publication. Applicable conditions and the actual code’s license must remain satisfied. A modified network-interactive AGPL version must offer its covered source to relevant remote users. Two details matter when comparing a downloaded application with a server-only service. First, browser software such as JavaScript can be transferred to users, constituting distribution. Downloadable clients, supplied copies, or other delivery can also change the obligations. Second, server-only operation does not erase MIT’s notice condition or every other applicable term. Trace what users receive, and which program they interact with, before selecting a compliance strategy.
Business Models
Revenue Can Come From Service, Convenience, Features, and Rights
Open source businesses can earn money without exclusively controlling every copy. Support and services sell tested releases, updates, assistance, and training, as Red Hat illustrates. IBM’s twenty nineteen acquisition had roughly thirty-four billion dollars in equity value. That historical price is not simply support revenue or a current valuation. Open core, illustrated by GitLab, charges for additional features while preserving an open core. Its challenge is choosing paid boundaries without undermining community trust. Hosted services sell managed operation, with MongoDB Atlas illustrating convenience and delivery value. Other operators can compete, and associated product licenses must still be checked. Dual licensing offers authorized copyleft and proprietary choices, as MySQL and Qt illustrate. It requires sufficient rights, while foundations and sponsorship must direct funding toward sustainable maintenance. Shared development, recruitment, and standards can also motivate contributions beyond immediate sales revenue.
Review and Sustainable Responsibility
Ownership, Permission, Compliance, and Maintenance Are Separate Questions
Review begins with ownership: open source software can still have copyright holders. They grant permissions through a license, rather than necessarily donating their rights to the public domain. Permissive licenses allow closed derivatives under conditions; copyleft applies reciprocal duties at its covered triggers. Apache adds defined patent provisions, redistribution notices, and change-marking requirements beyond MIT’s short text. The AGPL addresses a server-only gap through its modified-network-version source-offer requirement. Open core and hosted services illustrate two viable business models with different challenges. Paid-feature boundaries can upset a community, while hosting faces competition from other operators. Licensing changes and forks show why particular versions and existing permissions matter. Compliance also requires tracking what code is combined and what software actually reaches customers. Security maintenance is a separate responsibility, even when the license disclaims warranties. Businesses should sustain critical dependencies instead of assuming unpaid volunteers can meet every operational expectation.
About Ethics in Technology at UPI Study
Ethics in Technology (Computer Science 195) is a self-paced online course of 116 video lessons in 15 chapters, from cybersecurity basics, privacy and surveillance to big data, hacking, malware, network defense, intellectual property, cybercrime, encryption, emerging technology and digital citizenship. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses
Compare: Cybersecurity vs Ethics in Technology · Which ethics course?
Why take it here
Why students take Ethics in Technology with UPI Study
Where the credit goes
Universities that work with NCCRS
Ethics in Technology carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Open Source and Software Ownership
What is the difference between permissive and copyleft open source licenses?
Does the GPL apply to software that only runs on a server?
What is the difference between the MIT and Apache 2.0 licenses?
How do open source companies make money?
About the Ethics in Technology course
How many college credits is Ethics in Technology?
How much does Ethics in Technology cost and what is included?
Which universities accept UPI Study credits?
How long does Ethics in Technology take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Ethics in Technology.
116 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →