Data Protection, IPR and Open Source Explained: Two Worked Cases and Exam Traps
Separate privacy from security, match IP rights to software assets, and solve two numerical cases on data minimisation and mixed-licence releases.
KnowledgeGate Team
Exam prep & CS education

Privacy, security and data protection answer different questions. Copyright, patents, trademarks and open-source licences govern different parts of software. A 1,000-learner data audit tests minimisation, while a 1,700-line release tests asset ownership and licence duties. Legal outcomes depend on the applicable law, licence text and specific facts.
Data protection and IPR: build the concept map first
Privacy asks what personal information should be collected or used, why, and with what choice. Security asks how information is protected against unauthorised access, alteration, loss and disruption. Data protection covers the wider lifecycle of controls for collecting, using, sharing, retaining and deleting personal data. Encryption can strengthen security without making excessive collection privacy-friendly.
IPR is an umbrella for rights over creations and identifiers:
Right | What it concerns | Software example | Common trap |
|---|---|---|---|
Copyright | Original expression | Source code or documentation | It does not automatically protect every underlying idea |
Patent | An eligible invention after the required legal process | A qualifying technical invention | Creating code does not automatically grant a patent |
Trademark | A source-identifying name or logo | Product name | Company registration does not settle every trademark issue |
Trade secret | Valuable confidential know-how kept secret | Deployment method | Public disclosure defeats the secrecy premise |
Ownership, eligibility and employee-created work depend on jurisdiction and facts. A licence permits use under stated terms, not proof that material has no owner. Open source is code offered under a licence granting specified freedoms, not automatically freeware, public domain or unrestricted use.
Personal data: follow the complete lifecycle
A learner portal can use seven actions:
Define the enrolment purpose.
Collect only fields needed for that purpose.
Show a clear notice and record any required choice.
Give each staff role only the access it needs.
Protect storage and transfer with suitable controls.
Respond to requests and incidents through a defined process.
Delete or anonymise data when the documented purpose ends.
Research Ethics, Writing and Publication for Teaching Exams owns participant consent, confidential research records and publication misconduct. The data lifecycle below applies more broadly to collection, access, retention and deletion, while the later software case separates ownership from licence permission.
State | Example | What it means |
|---|---|---|
Directly identifiable | A named account | The person is directly identified |
Pseudonymised | Replace | Re-identification remains possible, so the data can remain personal |
Aggregated | Scores 78, 64, 91, 73 become (78 + 64 + 91 + 73) / 4 = 306 / 4 = 76.5 | The result describes the group |
Name removed | Delete the name but retain uniquely identifying fields | Removing one field does not guarantee anonymity |
Data minimisation worked case: audit 1,000 registrations
Suppose a portal registers 1,000 learners. Enrolment needs name, email, mobile number and course choice for everyone:
1,000 × 4 = 4,000 core field-values.
Only 80 scholarship applicants need date of birth and government-ID number:
80 × 2 = 160 conditional field-values.
The minimum is 4,000 + 160 = 4,160. The old six-field form collects 1,000 × 6 = 6,000 field-values. It therefore collects 6,000 - 4,160 = 1,840 avoidable values. A second route confirms this: (1,000 - 80) × 2 = 920 × 2 = 1,840.
The collection-volume reduction is:
1,840 / 6,000 × 100 = 30.666...% = 30.67%.
This is not a calculated reduction in legal liability or breach risk. Separately, 250 learners opt in to course news, so 250 / 1,000 × 100 = 25%; the other 750 make up 75%. All 1,000 retain course access. Marketing choice is separate, the scholarship role alone receives the 80 verification records, and those fields get a documented retention point. A checkbox does not cure unnecessary collection.

Intellectual property: match each right to the asset
One product can involve all four rights. Original code and documentation point to copyright, its name and logo to trademark, an eligible technical invention may raise a patent question, and a confidential deployment recipe may be a trade secret only while secrecy is maintained.
Publicly posting source code does not grant reuse permission. Repository access also proves neither ownership nor permission without a licence or other authorisation. Use this chain: creator or rights holder -> licence terms -> permitted actions -> conditions. A contributor can retain copyright while permitting copying, modification and redistribution.
Open-source licensing worked case: release StudyTimer
StudyTimer contains 1,200 lines of original team code, 300 unchanged lines from an MIT-licensed module, and a separate modified 200-line GPLv3 command-line utility. The distributed total is:
1,200 + 300 + 200 = 1,700 lines.
Asset | Share calculation | Share | Required decision |
|---|---|---|---|
Original team code | 1,200 / 1,700 × 100 | 70.59% | Confirm ownership and choose a licence |
MIT module | 300 / 1,700 × 100 | 17.65% | Retain its copyright and licence notice |
Separate modified GPLv3 utility | 200 / 1,700 × 100 | 11.76% | Follow source and notice obligations for redistribution |
All third-party code | 500 / 1,700 × 100 | 29.41% | Check each applicable licence |
The team can choose a licence only for the 1,200 lines it may license. The GPLv3 utility cannot be treated as proprietary merely because it is 11.76% of the total. Percentages aid inventory, but do not decide which licence condition applies.
A logo supplied only for website display and a sample dataset with no stated reuse terms are separate assets. Neither becomes open source by proximity. Redistributing the modified GPLv3 utility as a separate program triggers the duties that apply to that distribution. Whether real components form one combined work depends on architecture, licence text and applicable law.

Open source, permissive licences, copyleft and public domain
Label | Source available? | Modification and redistribution | Typical condition | Do not infer |
|---|---|---|---|---|
Open source | Yes | Allowed within its licence | Follow the stated terms | Ownerless or unrestricted |
Permissive licence | Yes | Generally broad reuse | Retain specified notices | No conditions at all |
Copyleft licence | Yes | Allowed with share-alike duties in defined situations | Provide required source, notices or same-licence terms | Every nearby asset is covered |
Public domain | May vary | Depends on the legally valid status | Confirm that status in the jurisdiction | A public repository is public domain |
“I downloaded it”, “the repository is public”, “it was free”, and “I credited the author” do not replace reading the licence. Ask: Who owns each asset? Which licence and version applies? Are you using, modifying, linking or redistributing it? Which notice, source or same-licence duties are triggered? Are non-code assets covered separately?
Data protection and IPR: how objective exams test the traps
A match-the-column item can map logo -> trademark, source-code expression -> copyright, confidential deployment recipe -> trade secret, and eligible granted invention -> patent. A scenario can test why retained re-identification keys indicate pseudonymisation, not guaranteed anonymisation. A numerical caselet can ask for 1,840 / 6,000 = 30.67%, while a licence item can test why a public repository without a licence does not automatically permit redistribution.
For an assertion-reason item, both statements are true: open-source software can remain protected by copyright, and the rights holder can grant conditional permissions through a copyright licence. The reason explains the assertion. Distractors swap privacy with security, confuse encryption with anonymisation, treat every invention as patented, equate open source with public domain, or let line count override licence terms. Common Software & Tools MCQs: 12 Solved ICT Questions Explained tests product identification, including an open-source data-analysis tool. StudyTimer instead requires an asset inventory and licence-by-licence redistribution check.
The short version and your next practice step
Privacy asks whether and why.
Security asks how information is protected.
Data protection governs the lifecycle.
IPR identifies the right.
A licence grants permission with conditions.
Open source is licensed, not ownerless.
Recalculate 4,160, 1,840, 30.67%, 70.59%, 17.65%, 11.76% and 29.41%. Then draw a two-column sheet labelled “data lifecycle” and “asset/licence inventory”, classify both cases, and explain why a percentage cannot determine a legal duty. Repeat the classification until each trap is obvious on sight.
For structured teaching, use the NTA UGC NET Paper 1 Course. The UGC NET Preparation Courses and Test Series page compares current learning and practice options.
Keep learning

Function Keys F1-F12 Explained: Uses, Worked Shortcut Map and Exam Traps
Learn what F1 through F12 do in named Windows and Microsoft application contexts, then solve a nine-command classification and avoid common modifier traps.

E-Waste Management Explained: Lifecycle, Worked Recovery Example and Exam Traps
Learn how e-waste moves from use to reuse, recycling and controlled residue. A hypothetical 600 kg batch shows how to close the mass balance and avoid denominator traps.

Common Software & Tools MCQs: 12 Solved ICT Questions Explained
Attempt 12 previous-year ICT MCQs before reading concise explanations that separate applications, hardware, web tools, abbreviations, malware and operating systems.

ICT in Education MCQs: 12 Solved Questions on Digital Learning Tools
Solve 12 ICT in Education MCQs, then use clear explanations and a five-layer model to separate files, tools, platforms and public initiatives.