Open Source Software and Licensing

When students actively engage with open-source concepts through debates, case studies, and real-world examples, they move beyond memorisation to grapple with ethical and practical dilemmas. Hands-on activities make licensing principles tangible, helping students see how these rules shape software ecosystems around them.

• Class 11
• Computer Science
• 4 activities
• 30 min–50 min

Learning Objectives

1. Compare the core principles of open-source software with those of proprietary software, identifying key differences in access and distribution.
2. Explain the benefits, such as collaborative development and cost-effectiveness, and challenges, like potential security risks and support variability, of open-source software.
3. Evaluate the impact of open-source licenses, like GPL and MIT, on software innovation, accessibility, and community contribution.
4. Analyze real-world case studies of successful open-source projects and their societal implications.

World Café

⏱ 45 min·Small Groups

Debate Format: Open Source vs Proprietary

Divide class into two teams to argue for open source or proprietary software using prepared points on innovation, cost, and security. Each team presents for 5 minutes, followed by rebuttals and a class vote. Conclude with a summary of key differences.

Prepare & details

Compare the principles of open-source software with proprietary software.

Facilitation Tip: During the debate, assign roles explicitly to ensure every student participates, including roles that argue for hidden costs of open source and proprietary software's limitations in customisation.

Setup: Classroom desks arranged into clusters of 6-8 students each, with large chart paper sheets taped to each cluster surface for group documentation. Blackboard sections can substitute for chart paper in resource-constrained settings. Sufficient aisle space for student rotation, or chart paper rotation where physical movement is not possible.

Materials: Chart paper or A3 sheets (one per cluster), Markers in two or three colours, Printed question cards for each table, Timer visible to all students, Exit slip sheets for individual harvest responses

• Understand
• Apply
• Analyze
• Social Awareness
• Relationship Skills

World Café

⏱ 30 min·Pairs

Licence Matching: Case Study Analysis

Provide excerpts from GPL, MIT, and Apache licences alongside software scenarios. In pairs, students match licences to scenarios and justify choices. Discuss as a class which licence best fits Indian software firms.

Prepare & details

Explain the benefits and challenges associated with open-source development.

Facilitation Tip: For the licence matching activity, provide students with actual licence texts first, then let them analyse real-world projects like Firefox or LibreOffice to see licences in action.

Setup: Classroom desks arranged into clusters of 6-8 students each, with large chart paper sheets taped to each cluster surface for group documentation. Blackboard sections can substitute for chart paper in resource-constrained settings. Sufficient aisle space for student rotation, or chart paper rotation where physical movement is not possible.

Materials: Chart paper or A3 sheets (one per cluster), Markers in two or three colours, Printed question cards for each table, Timer visible to all students, Exit slip sheets for individual harvest responses

• Understand
• Apply
• Analyze
• Social Awareness
• Relationship Skills

World Café

⏱ 50 min·Small Groups

Project Hunt: Real-World OSS Examples

Students research and present one open source project like Ubuntu or Mozilla Firefox, noting its licence, contributors, and impact. Groups compile findings into a shared class poster. Include challenges faced by developers.

Prepare & details

Evaluate the role of open-source software in fostering innovation and collaboration.

Facilitation Tip: In the role play, give students licence summaries upfront so they focus on negotiation strategies rather than licence details during the simulation.

Setup: Classroom desks arranged into clusters of 6-8 students each, with large chart paper sheets taped to each cluster surface for group documentation. Blackboard sections can substitute for chart paper in resource-constrained settings. Sufficient aisle space for student rotation, or chart paper rotation where physical movement is not possible.

Materials: Chart paper or A3 sheets (one per cluster), Markers in two or three colours, Printed question cards for each table, Timer visible to all students, Exit slip sheets for individual harvest responses

• Understand
• Apply
• Analyze
• Social Awareness
• Relationship Skills

Role Play

⏱ 35 min·Small Groups

Role Play: Contributor Negotiation

Assign roles as developer, user, and licensor in a scenario where code is shared. Groups negotiate terms under different licences, then perform skits. Debrief on collaboration benefits.

Prepare & details

Compare the principles of open-source software with proprietary software.

Setup: Adaptable to standard classroom seating with fixed benches; fishbowl arrangements work well for Classes of 35 or more; open floor space is useful but not required

Materials: Printed character cards with role background, objectives, and knowledge constraints, Scenario brief sheet (one per student or one per group), Structured observation sheet for students watching a fishbowl format, Debrief discussion prompt cards, Assessment rubric aligned to NEP 2020 competency domains

• Apply
• Analyze
• Evaluate
• Social Awareness
• Self-Awareness

Teaching This Topic

Teachers find success when they start with students' existing assumptions and use the activities as evidence-checking exercises. Avoid lecturing on licence terms; instead, let students discover constraints and freedoms through structured analysis. Research shows that peer discussions about real projects like Linux or Blender help students grasp the balance between freedom and responsibility in open source.

What to Expect

By the end of these activities, students will articulate clear differences between licences, justify choices using evidence, and demonstrate how community collaboration impacts software quality. They will also recognise both the strengths and limitations of open-source models in real-world contexts.

Watch Out for These Misconceptions

Common Misconception

During the debate on open source vs proprietary, listen for statements claiming open-source software is always free. Use the Licence Matching activity materials to redirect by asking students to examine project donation pages or service offerings.

What to Teach Instead

During the debate, pause discussions when this claim arises and refer students to the Licence Matching activity materials, where they can see that projects like GIMP rely on paid services or donations, making the 'free' claim inaccurate.

Common Misconception

During the Licence Matching activity, expect some students to assume all open-source licences permit unrestricted commercial use. Use the Debate Format activity to redirect by asking students to compare GPL's 'copyleft' clause with MIT's permissiveness.

What to Teach Instead

During the Licence Matching activity, guide students back to the Debate Format activity by asking them to revisit licence clauses they discussed, such as GPL's requirement to share derivative works, to correct the assumption of unrestricted use.

Common Misconception

During the Project Hunt activity, some students may claim open-source software lacks quality because it is 'amateur'. Use the Role Play activity to redirect by asking them to analyse bug trackers or contribution guidelines from projects they researched.

What to Teach Instead

During the Project Hunt activity, if this claim arises, steer students toward the Role Play activity by referencing how projects like the Linux kernel or Blender use structured contribution processes and peer reviews to maintain high standards.

Assessment Ideas

Discussion Prompt

After the Debate Format activity, pose this question: 'Imagine you are starting a new software company. Would you choose an open-source or proprietary model? Justify your decision by citing at least two benefits and two challenges of your chosen model, referencing specific licences where applicable, and use arguments from your debate to support your stance.'

Quick Check

After the Licence Matching activity, provide students with short descriptions of two software scenarios: one requiring extensive customisation and another needing a stable, widely supported platform. Ask them to identify which scenario might benefit more from open-source software and explain why, referencing licence types they matched during the activity.

Exit Ticket

During the Role Play activity, on a slip of paper, ask students to write down one key difference between the GPL and MIT licences and one example of a well-known open-source project they learned about during the Project Hunt activity.

Extensions & Scaffolding

• Challenge advanced students to draft a new licence that balances MIT's flexibility with GPL's protection, citing two real-world scenarios where it would be ideal.
• For students struggling with licence comparisons, provide a simplified chart with three columns: GPL, MIT, Apache, and ask them to fill in one row per licence based on a guided reading.
• Deeper exploration: Ask students to research how a specific open-source project like GIMP or VLC funds its development, presenting findings to the class.

Key Vocabulary

Open Source Software	Software with source code that anyone can inspect, modify, and enhance. It promotes collaboration and free distribution.
Proprietary Software	Software that is owned by an individual or company, with its source code kept secret and usage restricted by licenses.
GNU General Public License (GPL)	A widely used open-source license that ensures software remains free and open, requiring derivative works to also be open source.
MIT License	A permissive open-source license that allows users to do anything with the software, provided they include the original copyright and license notice.
Source Code	The human-readable instructions written by programmers that define how a software program works. It must be compiled or interpreted to run.