The UNICEF Innovation Fund invests exclusively in Open Source technology – with today’s rapidly evolving innovation landscape, Open Source software, hardware, data, and content not only create value and generate revenue, but also ensure greater collaboration and impact. This reflection is a look back at Open Source activity and participation stemming from the UNICEF Ventures Team from June 2020 to date (July 2021).

By the end of this article, you will have a better understanding of the evolving and forward-thinking approach to Open Source taken by the UNICEF Office of Innovation.

This article looks at a few aspects of Open Source engagement at the Innovation Fund:

1. Support models
   1. Legal & policy
   2. Building and leveraging from the community
2. Case study: Cloudline and upstream engagement

New to Open Source at UNICEF? 🔗

If you are hearing about the UNICEF Open Source Mentorship programme for the first time, check out this introduction post to get important context behind why UNICEF invests in Open Source mentorship and support for Innovation Fund portfolio teams:

https://jwfblog.wpenginepowered.com/2021/07/unicef-open-source-mentorship/

Innovation Fund support models 🔗

Start-ups receive both funding and customized mentorship during their 12-month investment period with the UNICEF Innovation Fund. Since the Innovation Fund launched in 2016, the Innovation Fund team noted the impact of hands-on guidance to help start-ups understand how to work open and lead open. Start-ups receiving Open Source support were better equipped to develop sustainable business models that made Open Source intellectual property work with them instead of against them.

By the end of the 12-month investment cycle, graduating companies achieve the following milestones in place with their projects:

• Solid understanding of Open Source licenses and different business models depending on a permissive or copyleft strategy.
• Laying foundations for growing or participating in friendly, inclusive communities.
• Documentation site to showcase their Open Source work, and how to get involved.
• Continuous Integration pipeline to test new changes in the code-base before they are added, and avoid common human errors.

Across these milestones, three themes of support have emerged as as most essential in the past year: legal & policy, building and leveraging from the community, and building in the open.

Legal & policy 🔗

The UNICEF Innovation Fund is unique in Venture Capital on its open-first investment strategy. Start-ups receiving UNICEF funding are obligated to either create their own Open Source works or contribute to existing Open Source works. This leads start-up teams to ask more questions: how does this work in a legal sense? How do you establish a sustainable business model with Open Source dependencies and the different types of license models that exist (e.g. permissive and copyleft)? These are the questions that start-ups receive tailored guidance on from the Open Source Mentorship programme.

How did the Open Source Mentorship programme support both start-ups and UNICEF Country Offices receiving funding from the UNICEF Innovation Fund? The programme improved business and legal resources and referrals for managing Open Source intellectual property. This was primarily done by creating a self-serve knowledgebase of legal, governance, and tech policy: the UNICEF Open Source Inventory. The Inventory was created in close consultation with start-ups receiving UNICEF funding, leading industry experts in areas such as Open Hardware and open design, and other existing Open Source communities of practice.

Building and leveraging from the community 🔗

Over the past year, we also saw more upstream collaboration. UNICEF Innovation Fund start-ups collaborated on existing projects like the PX4 Drone auto-pilot software instead of reinventing the wheel themselves. This enabled the work done with UNICEF funding to go further and impact the wider ecosystem, instead of an individual project with highly-specific use cases.

Furthermore, as the Innovation Fund portfolio continues to grow, new inductees in the Open Source Mentorship programme are able to build on top of work done by previous portfolio companies. This accelerates the rate of development for the new inductees and gives them a model of success to look towards during their engagement with UNICEF.

For example, two companies from the 2019 Drones cohort created documentation websites that were used as models for the 2020 Generation Unlimited cohort. qAIRa from Perú and Rentadrone from Chile created documentation websites using the popular toolchain Docusaurus, created by Facebook’s Open Source Program Office. The work of qAIRa and Rentadrone was leveraged as models by VRapeutic and I-STEM in the 2020 Generation Unlimited cohort. Using graduated companies as models accelerated both technical and content development for the new teams when they had relatable models to use in building their own Open Source documentation websites.

Innovation Fund case study: Cloudline and upstream engagement 🔗

Cloudline Africa (South Africa) operates small-scale autonomous airships that have longer endurance and range than current commercial drones; their solution will help deliver medical supplies to hard-to-reach communities and reduce operational costs in the last-mile.

Four highlights from Cloudline’s period with the Innovation Fund are below:

• The team launched the airship with a payload capacity of 10 kgs with a 50 km range.  
• Full endurance capability (40km/h) along with automated waypoint flying. 
• Contributed flight control software to the PX4 upstream community by introducing a new mode of aircraft to the community in the form of airships.  
• Cloudline received the Fast Company South Africa Most Innovative Company Award 

“Our greatest triumph of the year was the flight of our pre-production airship. Capable of a 10kg useful payload and a 50km range, this aircraft is ideally suited to medical logistics and other high-value scheduled deliveries.” — Spencer Horne, Co-Founder

Going upstream 🔗

Contributions made to another popular upstream community was another major highlight of the Open Source Mentorship programme. Furthermore, the contributions were not casual “drive-through” contributions; they were consistent and focused broadly around the ecosystem instead of a single repository of source code.

During the mentorship programme, Cloudline added 61 commits across four repositories. The summary of their contributions were adding a new vehicle type to the PX4 auto-pilot software: airships. The team first opened a discussion on the PX4 community forum. After getting feedback from a developer, they proceeded to add the Cloudline airship into the upstream software. This was followed by documentation additions with controller diagrams and simulation instructions. Through their contributions, a wider network of developers can simulate and interact with airships similar to the one created by Cloudline.

But the contributions did not stop at code. Cloudline developer Anton Erasmus delivered a deep dive presentation at the PX4 2020 virtual contributor summit. He explained to other developers about how to leverage the multicopter control system, as used in the Cloudline airships and other popular drone devices. This outreach step is important in growing awareness in the existing community for new introductions to the common software, and how both Cloudline and the PX4 community could help each other in achieving their similar yet different goals.

What is next for the Innovation Fund? 🔗

What does the next year ahead look like for UNICEF’s Open Source Mentorship programme? Stay tuned for the final post in this series, which will explore on-going work to standardize the mentorship curriculum, detail how Innovation Fund companies are being coached in becoming Digital Public Goods, and the research and development for an Open Source Program Office at the UNICEF Office of Innovation in 2022.

Special thanks for content and data collected in this post: Sanna Bedi, Zenani Orengo

However, this question only led to more questions. Much of the existing Open Source discourse on sustainability centers on defining, tracking, and understanding “dependencies.” Yet when we say dependencies, people typically mean source code, software packages, and license compatibility. So, how do we describe the value proposition of people and the impact of cross-pollinated communities?

So, what if Open Source dependencies weren’t just software? Furthermore, what if Open Source dependencies could mean people… or simply, human beings? In this blog post, we’ll walk through this thought experiment.

Open Source dependencies are people. 🔗

My purpose is to augment the idea of “dependencies” from exclusively source code to be more inclusive of its authors as well. We typically center software in our Open Source conversations, so I want to deliberately center people. There are many ways to cover this, but I will offer three ways we could think of Open Source dependencies as more than source code:

1. Community inheritance
2. Legacies
3. Love

Dependencies: Community inheritance 🔗

New, smaller projects sometimes form up underneath or within an existing larger project. Sometimes a new project is created to support the existing project. Sometimes it is a passion project led by a few that aligns with the motivations and values of a wider community. But these new projects begin with an added advantage of inheriting the collaborative ecosystem surrounding the existing project, instead of being tasked to create this from scratch themselves.

Why measure this? 🔗

Ask anyone responsible for building an Open Source community from scratch. The approach at this stage is experimental:

• Will using this feature encourage new contributors to participate?
• Does someone in a related field discover our project on a casual whim looking at GitHub?
• How do we make our project more accessible for contributors we do not yet have?

Many times, it is about forming a hypothesis and then testing it.

However…

If you exist within the dynamic of an existing community, you benefit from resources, people, and infrastructure that would be unavailable if you started independently. Finding communities with compatible values and motives exposes you to a wider network, and thus more visibility in a world where there is already too much information. Working within an existing community can cut light-years off of time-to-market or improving product sustainability and community resiliency (in the context of other variables).

Example of community inheritance 🔗

The Fedora Project produces Fedora Linux. Fedora Linux is a Free and Open Source operating system derived from the open source Linux kernel. The Fedora Project also creates other software in order to facilitate the production, creation, and updates of Fedora Linux. Examples of this are asynchronous meeting minute note managers, community calendars, gamified badges, software package distribution tools, and more.

While none of these smaller software projects are the ultimate purpose and goal of the Fedora Project, they are supplementary to the overall goal of producing Fedora Linux. The sustainability of these smaller parts ensure a healthier ecosystem around the larger project.

Another way to see this is as a planet with several orbiting moons, where the planet is an existing project and each moon represents another smaller project orbiting around the existing one. Each moon is different, yet each is still connected to the gravitational force and motions of the planet.

Dependencies: Legacies 🔗

Open Source projects are more than source code. Human beings are social creatures, and Open Source is a social activity. An individual or groups of individuals may influence the hearts and minds of others in the movement. To win hearts and minds is to merge the intentions of the individual with the intentions of the wider community. The power to change minds is the power to move mountains.

Why measure this? 🔗

Open Source is a social activity. It has both a written and oral story-telling tradition. There is a rich history from the movement that first took root in the 1980s. We use stories to expand our imagination, or to see a perspective in a way we might not have before. So, it is important to note the value these historical stories play in shaping our movement and creating leaders.

Legacies of kindness and love result in thriving communities where contributors look out for each other. People are not motivated by the will to survive; they are motivated by the will to thrive with a community. Legacies of discrimination and hate result in divided, splintered communities who are focused on counting their differences instead of seeing how alike we are.

Example of legacies 🔗

Seth Vidal wrote the Yellowdog Update Manager (Y.U.M.), and he contributed to Fedora. Matthew Williams helped others learn about Linux and Open Source, and he contributed to Fedora. Thomas Gilliaird helped me with using Fedora Linux in IRC as a teenager, and he contributed to Fedora. The ways we help other humans while on our own journey is how we create a legacy with wider wings. The impact of a few kind people is enough to inspire more to follow.

To ignore the impact of legacies in social activities surrounding Open Source is to deny the impact of charismatic leaders who lead in styles of either unity or division.

Dependencies: Love 🔗

Power at its best is love implementing the demands of justice. Justice at its best is love correcting everything that stands against love.

Dr. Martin Luther King, Jr.

The act of existence can be political. We cannot escape the sociopolitical environment of our world, no matter how much we wish to push it aside. If we choose to ignore it, there are others who choose to manipulate common ignorance, to the exploit of their own unbounded wealth. We must embrace and acknowledge the political atmosphere permeates our world; it does not disappear and hide away when it makes us uncomfortable.

Why measure this? 🔗

Open Source does not get a “get out of jail free” card.

Open Source is political. Its roots in the Free Software movement were firmly rooted in politics, even if they were narrowly confined to a few key issues. The real question is, how do we wield our own political agency and expediency? We should act from our hearts and move to inspired action to correct everything that stands against love.

Example of love 🔗

This blog post. These words are a radical act of love. Acknowledging it and choosing to embrace it is the first step in using our Open Source power responsibly.

Featured image arranged by Justin Wheeler. Original photograph by Ian Schneider on Unsplash.

2020 saw the launch of a formalized Open Source Mentorship programme for the UNICEF Innovation Fund, built up on two years of work from RIT LibreCorps expertise and consulting.

The Open Source Mentorship programme includes five modules about Open Source intellectual property and communities delivered across twelve months. UNICEF grantees are matched with an experienced Open Source Mentor to guide them through the modules. The mentorship takes an interactive, guided approach to understanding the unique context that each team and product exist within. The assigned Open Source Mentor provides specialized advice and training:

• Tailored feedback based on business models
• Existing local user communities
• Best practices for collaborating together with others on similar challenges.

The geographic diversity in the UNICEF Open Source Mentorship programme is unusual for technology incubators or accelerator programs. All funded projects come from UNICEF programme countries. The UNICEF Innovation Fund provides equity-free funding for Open Source solutions from local innovators and entrepreneurs solving local problems. To date, the Innovation Fund has invested in teams from over 57 countries. Argentina, India, Iran, Kenya, Mexico, Nepal, and Rwanda represent the most recent incoming cohort in July 2021.

But why does this kind of work matter to UNICEF or the United Nations?

UN Roadmap for Digital Cooperation 🔗

In June 2020, the United Nations Secretary-General released the UN Roadmap for Digital Cooperation, a call for action and a vision with several key considerations:

• An Inclusive Digital Economy and Society
• Human and Institutional Capacity
• Human Rights and Human Agency
• Trust, Security and Stability
• Global Digital Cooperation

The report explores the impact technology has in each key area:

“Digital technology does not exist in a vacuum – it has enormous potential for positive change, but can also reinforce and magnify existing fault lines and worsen economic and other inequalities. In 2019, close to 87 per cent of individuals in developed countries used the Internet, compared with only 19 per cent in the least developed countries.”

UN Roadmap for Digital Cooperation, June 2020

Open Source Mentorship enables digital cooperation. 🔗

Therefore, the conception and development of Open Source Mentorship is inspired by the Roadmap, in four key aspects:

1. Digital Public Goods: To encourage knowledge transfer and collaboration on practical, everyday advice on building technology projects in line with the Digital Public Good Standard.
2. Digital Capacity-Building: Empowering others with the skills and information they need to be bringers of Open Source change and innovation in a disruptive and competitive Venture Capital ecosystem.
3. Digital Trust and Security: Providing a holistic view of Open Source intellectual property that is influenced by, but not bound by, quarterly earnings reports and share prices. Understanding the commitments of Open Source licenses and technology, and how trust is earned and lost in Open Source products and communities.
4. Global Digital Cooperation: Designing and structuring communities to be healthy and collaborative in nature, united in resolving common challenges and problems.

No culture can live if it attempts to be exclusive.

Mahatma Gandhi

I believe in the value of upholding the Open Source Definition as a mature and dependable legal framework while recognizing the OSI needs to work better with works that are not Open Source. My ambition as a candidate is to support existing work to enable a more responsive, more agile Open Source Initiative.

Twitter: @jwf_foss

Why should you vote for me? 🔗

I bring a public sector perspective to a conversation where it seems missing, despite the dependent relationship of the public sector to Free and Open Source works. In my work, I provide Open Source mentorship and coaching to humanitarian-driven start-ups hailing from 57 countries. I am an excellent communicator, I understand a subset of challenges faced by Open Source communities, and I have a collaborative nature.

I am also a millennial. The GPL was first drafted before I was born. My lived experience with Free Software and Open Source gives me a vantage point not well-represented in Open Source legal and policy work. My personal experience with Free and Open Source software is impacted by years of untangling my own digital life from technology decisions made for me, not by me. With that in mind, I realize not everyone can afford to be a Free Software purist, but we can still uphold the values of Open Source even if we do not use it exclusively.

Who am I? 🔗

I work as an Open Source Technical Advisor at UNICEF in the Office of Innovation. I manage and support an Open Source Mentorship programme for start-up investments and teams building Open Source products and communities from more than 57 countries. I also provide Open Source support to other UNICEF colleagues and recently coordinated UNICEF Innovation’s participation in the [on-going, at publication time] Outreachy round.

Outside of work, I have contributed to the Fedora Project for almost six years. I am soon ending a year-long term as the Diversity & Inclusion Advisor to the Fedora Council. I am a founding member of the Fedora Community Operations and Diversity & Inclusion teams. 

What are my qualifications? 🔗

I first contributed to Open Source as a teenager. I was a community moderator and staff member of the open source SpigotMC project. There, I handled user reports for a community forum with over 400,000 registered members. This is one of the most unique communities I have worked in, as the Spigot Community is a population of hundreds of thousands with an age demographic concentrated between ages 13-25.

Additionally, I am on the advisory board of Open @ RIT, the Open Source Programs Office for the Rochester Institute of Technology in Rochester, New York. This enables me to work more closely with academia, which has a growing interest in the growing ecosystem of academic Open Source Program Offices.

Finally, I regularly work with teams building Open Source solutions in support of children and UNICEF’s core work. I have lived experience of coaching teams on Open Source best practices across six continents. I have seen where Open Source worked well and where it didn’t. I bring this background and perspective into the work I would do as a member and representative elected by the Open Source Initiative constituency.

In summary, my lived experiences in Open Source, my connection to academic Open Source, and the humanitarian focus of my work make me a uniquely-qualified candidate for the OSI Board.

Interview responses 🔗

Luis Villa published four interview questions for OSI Board candidates on Opensource.com. I originally tweeted my response, but I copied it here for wider visibility too.

Q1: What should OSI do… 🔗

“…about the tens of millions of people who regularly collaborate to build software online (often calling that activity, colloquially, open source) but have literally no idea what OSI is or what it does?”

I am excited at the opportunity to contribute here. The UNICEF Office of Innovation (and my own Open Source Mentorship programme) rely on the Open Source Definition to guide our international Open Source work, even if we are still learning how to do it best. But without the OSD as a guiding light, our work is much harder. My team is well-positioned to be an advocate and voice of support for the Open Source Definition in policy environments where Open Source is not. This relates to on-going Giga connectivity work to connect schools worldwide to the Internet for equitable education opportunities for children.

So to directly answer the question, we have a conversation. Avoid anger when others choose software that is not Open Source. Avoid exasperated frustration when people pick licenses that are not Open Source. But the first step is always to teach & educate on the stories, values and history of the Free/Open Source community.

Q2: If an Ethical Software Initiative sprung up tomorrow, what should OSI’s relationship to it be? 🔗

The good folks behind the Ethical Source movement have done so. The OSI needs to be open to collaborate and engage with other orgs who steward legal works that do not adhere to the OSD.

I want to invite the Ethical Source folks into the conversation. How can we better partner together? If elected, I would commit myself to organizing a public town hall or community discussion with the Ethical Source folks. Coraline Ada Ehmke, Tobie Langel, and many other folks are doing great work in this space. So, let’s collaborate and work together.

Q3: When a license decision involves a topic… 🔗

“…on which the Open Source Definition is vague or otherwise unhelpful, what should the board do?”

The OSI needs to improve at saying what it is not. We are more clear on what the OSD is than we were even last year. As a candidate, I don’t have crazy ideas for the Definition. But there are things that are not Open Source. The world is changing.

We need to adapt. We must be nimble in changing with the world, or the values and motives of the original Free/Open Source movement are at risk of volatility. As a candidate, if presented with an unclear situation, I would take one of two options:

1. If the proposed work stands against a principle of the OSD, it should not be approved as such, or the OSD becomes meaningless; OR
2. Take an interpretive, “living document” view of the OSD for new copyleft innovations where the OSD is not clear or ambiguous.

For context, I am a copyleft believer. Promoting and advocating for the stability and integrity of Open Source licenses is a fundamental part of my interest as a candidate for the Board.

Q4: What role should the new staff play in license evaluation (or the OSD more generally)? 🔗

I don’t have an answer to this one. Foundations are mostly new to me. I would defer to expertise and listen to what others with more years have to say. I want to better understand the capacity and ambition of the OSI to take on new work with a steady staff.

I am a collaborator by nature and a team player. So, I want to enable the work for the OSI to be more agile and responsive in what I see as core, critical work.

That’s it. If you have specific questions, you are welcome to get in touch with me on Twitter or add a comment below.

I don’t say that casually either. I have involuntarily found Open Source as my calling. Or my people. I contribute to Open Source because I love to collaborate and work together with other people. This challenges me. It humbles me in a way that I know I can always learn something new from someone else. For this, Open Source and Free Software have enriched my life. They have also given me, again involuntarily, an odd but productive way of coping with my own mental health issues, anxiety, and depression.

So how do I make sense of the emotions and feelings I have now? How do I untangle this complicated web of events and reactions by other people? To ignore it doesn’t seem possible. If I remove emotion, I am left with a purely rational motive to involve myself in this contemporary issue. My work, profession, and career goals are directly affected by however this discussion goes. There is no way out for me. It’s my job, so I have to care. But if you add emotions back in, to stand still and remain idle is heartbreaking. To do nothing is to commit to defeat. Resignation. The darkness.

Yet what is there to do? The only thing Stallman ever directly gave to me in life was an email explaining elegantly how there was nothing he could do for the Minecraft GPL community fiasco. At a time when I was so personally lost as I saw a community I love tear itself apart, he stood by idly as the so-called steward of these licenses that I was just too naïve to believe in. That experience to me now is amplified in the light of the much more egregious things he is accused of.

So, the Free Software Foundation welcomes Richard Matthew Stallman back to its board. Wonderful. Congratulations Mr. Stallman. I am going to pause for a moment of sadness and hurt as I contemplate the impact of this moment on our fragile movement, which has much bigger enemies today than it has in its 40 year legacy. But then…

I will move on. Because we have to. The only way is forward.

I joined the UNICEF Innovation team in June 2020, although this is not the first time I have worked with UNICEF Innovation. I have had some opportunity to write about Open Source, but my personal blog has been quiet! So, this felt like the right opportunity to talk about what I am up to these days.

The Open Source Archetypes report (below) provides nine archetypes common among Open Source projects and communities. These archetypes provide a common language and perspective to think about how to capture the most value of Open Source in various contexts.

Open Source Archetypes (May 2018)Download

This article covers the following topics:

1. How Open Source Archetypes align with my experience
2. How I use Open Source Archetypes at UNICEF
3. Unanswered questions

How Open Source Archetypes align with my experience 🔗

The Open Source Archetypes report is useful to me because it aligns with my own experiences and encounters with common Free and Open Source Software projects. An advantage of taking my alma mater’s Free and Open Source Software and Free Culture Minor is experiencing what real Open Source projects are like long before I entered the industry. The projects and organizations I contributed to and interacted with all ran their projects in one of the nine models identified in the report.

The Open Source Archetypes report speaks to my personal experience either using or contributing to projects like Fedora, Kubernetes, SpigotMC, MusicBrainz, and various independent projects. The value of Open Source for any project is in meeting the goals of the intended audience. By itself, “Open Source” is a broad term, even if it does have a legal definition. My experiences taught me the importance of how different Open Source projects meet the needs of different audiences, or even different combinations and balances of audiences. The Open Source Archetypes report creates language for something I previously only understood through direct experience.

When I first read the report earlier in 2020, I knew it was relevant to my work. But how could I begin to integrate it into the Open Source Mentorship programme I manage for the UNICEF Innovation Fund?

How I use Open Source Archetypes at UNICEF 🔗

The UNICEF Innovation Fund provides early stage funding and support to frontier technology solutions that benefit children and the world. Most teams in the Innovation Fund are from countries where UNICEF has an ongoing country programme.

A requirement for solutions we fund is that they must be Open Source. I have seen many different types of projects and business models since I started working as a part-time consultant for UNICEF in 2018. As exciting as this is, it was challenging to understand the best way of supporting each team and their Open Source projects. Each team and project had differences unrelated to their source code, but closely tied to their business models and impact they wanted to have through their work.

So, the Open Source Archetypes report have me language. It gave me examples and explanations of how Open Source can work to teams who had little to no prior experience of Working Open. I take the unique context and details I understand about each team I work with, and contextualize what they are doing compared to the different models in the report.

The feedback I received so far on the report with the 15+ teams I currently work with is mostly positive. Some teams exclaimed this report was what they wish could have read months before because it resolved many of their doubts. Others were more overwhelmed, and needed extra time to read and review.

For my role as a mentor, the Open Source Archetypes report gives me cues for how to best support and direct each team I work with. The task of building an Open Source community or participating in an existing one is not a small task. Whether it is documentation, project management, quality assurance and testing, or community engagement, I have yet to see any small team accomplish all of these things at once. So, identifying which archetype a team best identifies with gives me a cue to guide the teams on their path forward. It gives me context for how to make Open Source something that works for them instead of against them.

Unanswered questions 🔗

I have great appreciation and gratitude for the folks at Mozilla and Open Tech Strategies who compiled this report. But it was written over two years ago, and like all things in life, things can change. So, while I look comfortably from the position of hindsight, there are some critiques and missing components to the Open Source Archetypes reports.

My unanswered questions are below.

Does the Linux kernel (and subsequently, Linux distributions) represent another unwritten archetype? 🔗

The report explicitly avoided using the Linux kernel as the basis for any archetype:

In some ways the Linux kernel project could be considered “Wide Open”. However, both technically and culturally, Linux kernel development is sui generis and we have deliberately avoided using it as the basis for any archetype.

Open Source Archetypes, Page 17

Contextualizing a project like Linux is hard. There is a lot of history to a project that first launched over email in 1991. There are many “yes, but"s about decisions made 10 or even 25 years ago that would not replay the same way in 2020.

Yet this is important work. Linux represents not just the kernel, but also large, decentralized sub-units of other systems that integrate the kernel in order to make it useful (e.g. Ubuntu, Fedora, Debian, Arch Linux, you name it). These sub-communities include large entities and corporations, spanning multiple countries and organizations of various sizes.

The Linux kernel communities are worthy of a deeper look, possibly in order to define a new archetype.

How can Open Source Archetypes better fit the social/humanitarian sector? 🔗

The archetypes shared in the report largely focus on business sustainability. In other words, the report is biased towards Mozilla’s interest in funding the research in order to better understand how to support a commercially-successful Open Source project. To me, there seems like a gap in models that often work for Open Source projects perhaps like U-Report and Ushahidi.

This is an area of interest to me, and likely others in the UN and NGO space. The report could do more to address these kinds of projects.

How would you teach Open Source? 🔗

To conclude, the Open Source Archetypes report is an invaluable tool that provides me language and context for teaching others about Free and Open Source Software.

How would you teach Open Source? What models, research, or tools would you use to inform an Open Source mentorship or education programme? Share your thoughts below in the comments!

The Cryptographic Autonomy License is one of newest Open Source licenses on the block. The Open Source Initiative approved it in February 2020. This license also made ripples when it came through. But the question I had, and could not find a clear answer to, was why is it so interesting?

This blog post is my attempt to do a casual coffee-table review of the license. If you agree or disagree, I encourage you to leave a comment and share your opinion and why!

This short article covers three sections:

1. CAL-1.0 provisions: What basic Free Software assumptions are present in the license, much like other copyleft licenses.
2. What’s fresh!!: What is the hype? Ready for the key information? It is covered here.
3. Personal takeaways: My personal thoughts on this license and where it might be applicable.

CAL-1.0 provisions 🔗

I learned there are basic assumptions and expectations that are true for all Open Source licenses, per the Open Source Definition. Copyleft licenses also have different degrees of rigidity depending on context and use. So, what basic ingredients of a Free Software license are present in the Cryptographic Autonomy License?

Note: The number in parentheses before each line is the corresponding section number in the license text.

Basic legal provisions 🔗

• (6.0) Disclaimer of warranty, limit on liability: If someone uses the software and it causes unexpected disastrous side effects, the Licensor cannot be held responsible.
• (2.0) Receiving a license: Anyone can receive a CAL-1.0 license. To receive it, you just have to agree to its rules.
• (7.4) Attorney fees: If a case involving noncompliance with the CAL-1.0 is brought to court, loser pays legal fees for prosecution and defense.
• (7.3) No sub-licensing: You cannot add another license “on top” of the CAL-1.0.
• (3.0) Patent clause: Got patents? This license is equipped to interface with external patent licenses.

Permissive provisions 🔗

• (4.1) Access: Source code must be made available over a network with this license.
• (4.3) Attribution: Cite your sources. Retain all licensing, authorship, and/or attribution notices.

Copyleft provisions 🔗

• (4.1) Modified Work: Changes to the original Work make it a Modified Work. Same license rules apply to a Modified Work.
• (5.2) Reinstatement: A la GPLv3, for non-compliant derivative works, there is a 60 day grace period to come into compliance before your license is terminated.
• (4.5) Combined Work Exception: Software in the Larger Work as well as the Larger Work as a whole may be licensed under the terms of your choice.
• Network use: A la AGPL, it also includes a trigger for network use.

What’s fresh!! 🔗

The fresh take on this license from other licenses is all in 4.2. Maintain User Autonomy:

In addition to providing each Recipient the opportunity to have Access to the Source Code, You cannot use the permissions given under this License to interfere with a Recipient’s ability to fully use an independent copy of the Work generated from the Source Code You provide with the Recipient’s own User Data.

Section 4.2 Maintain User Autonomy: intro text

My non-lawyer take on this is that user data plays a much more prominent role in the terms of this license than other copyleft licenses. Just like the AGPL was a response to the changing world of network services and cloud computing, the CAL-1.0 is a response to the changing world of machine learning and data science.

The CAL-1.0 seems to define “user autonomy” in the context of actually using the software, versus something more holistic like Digital Autonomy. In other words, if you are running CAL-1.0 software, you cannot interfere with requests for personal user data from your users.

This might not sound so radical, but it really is. It is a radical way to assert users’ ownership of their data. If you are the end user of a distributed or cloud-based app licensed under CAL-1.0, you are enabled (to some degree) to request copies of personal user data without interference or obfuscation.

CAL-1.0 and Hatbrim Technologies 🔗

To better explain this, consider this made-up example.

I am a product manager at Hatbrim Technologies. Hatbrim develops an integrated calendar application, Holocal, to store events, meetings, and reminders. Holocal is an integrated application that includes a front-end component, back-end component, and a machine learning algorithm. The algorithm offers tailored suggestions to reduce my meeting load based on my common meeting patterns with other events or activities I have planned.

Oraculous, a competing company to Hatbrim Technologies, creates a fork of Holocal called OraCal. It is almost functionally identical to Holocal except it also adds an integration to other services from Oraculous. However, OraCal also modifies the calendar optimization algorithm. It adds a periodic random event suggestion based on events and activities in your calendar.

Meanwhile at Hatbrim… 🔗

Since I am a product manager at Hatbrim, I turn to my trusty team of developers and ask them to explore the OraCal fork of Holocal. I am curious to know how their calendar optimization method works, since Oraculous must also release OraCal under the Cryptographic Autonomy License (CAL-1.0). My team of developers review the OraCal code, try making changes to Holocal, but we are unable to replicate this feature of OraCal in our environment.

Eventually, one developer runs OraCal internally, but optimized for our data. Still no luck to reproduce the nifty calendar event suggestion feature! Fortunately, the CAL-1.0 offers a protection here. So, the developer sends an email to Oraculous to request her personal user data from OraCal provided to her. Because the CAL-1.0 has provisions to prevent foul play or modifying the data, the developer receives a copy of her data and realizes another Oraculous tool was scrubbing and appending data for calendar predictions before it returned to OraCal.

In this hypothetical scenario, our developer is ultimately able to understand how the Modified Work is changed and how Oraculous adapted the original Work. Under another copyleft license like any GPL variant or the Mozilla Public License, a licensee has no obligation to share any user data with an end user. For any reason. Unless they happen to be nice or because another legal authority or body holds them accountable to share user data.

CAL-1.0 personal takeaways 🔗

Did I mention I am not a lawyer and this does not constitute legal or financial advice? In case I did not, I am not a lawyer and this does not constitute legal or financial advice.

This advice and interpretation of the license is raw and unfiltered. But you only read something for the first time but once. So, with all other contemporary issues in the Free Software world going on, I thought it would be a fun exercise to draft this blog post as I read through the Cryptographic Autonomy License for the first time.

Ultimately, my takeaways after reading and reflecting on the license a few times is this:

1. Lack of transparency in motivation: Holo, the company behind the license, emphasizes all the good qualities of this license while sneakily dodging the fact that it is a mildly anti-competitive license for their business case.
2. Precedent-setting: This is the first approved Open Source license that explicitly does anything significant about data. It will be interesting to see if this inspires other licenses that make definitions on data.
3. Potentially powerful if picked up: If used more widely or in more popular projects, it has potential to disrupt the status quo of how Open Source thinks about user data and the autonomy of the end user.
4. No defining moment: To my knowledge, CAL-1.0 lacks a significant defining moment since its approval. It is unclear what real-world noncompliance litigation looks like. It lacks the battle-testing of other copyleft licenses.

I imagine I am not the only one who feels mutually excited and hesitant about the Cryptographic Autonomy License. I am not sure if it makes sense to apply to any of my work or to recommend as a default license to others yet. And licensing is only but one of many pathways in the Free Software legal and policy world. But nonetheless, it is an interesting Free Software development that is still maturing since February 2020.

Photo by Markus Spiske on Unsplash. Modified by Justin Wheeler.

Why does this matter? 🔗

This exploration and thought experiment is important to understand when revisiting social movements in technology in the current day. In the FOSDEM 2020 talk Mike and I gave, we presented three possible digital “freedoms” for artificial intelligence. The rights-based approach we presented at FOSDEM 2020 was inspired by the origin of the Free Software movement.

But to understand how we got to today with thousands of contributors to the Linux project, billions of dollars in open source company buyouts, and the words “open source” used on mainstream cable news channels, we have to start from the beginning, in 1983.

27 Sept. 1983: GNU Project announced 🔗

On 27 September 1983, the GNU Project was announced by Richard Stallman. The GNU Project was a collection of Free Software tools for building a free operating system. But it was also more than that. The GNU Project came with a vision to give computer users freedom and control of their use of computers. To do this, the GNU Project advocated for four fundamental freedoms:

• Run software in any way desired
• Copy and distribute the software
• Study it (i.e. reading the source code)
• Modify it and make changes

Today, we call these the Four Freedoms.

So, the GNU Project was founded with these fundamental freedoms as the motivation for why they did what they did. It was more than shipping code for code’s sake, but to lead by example in how software could be developed without sacrificing the rights of users.

4 Oct. 1985: Free Software Foundation founded 🔗

Next, skip ahead to 4 October 1985. Two years after the launch of GNU, the Free Software Foundation (F.S.F.) is founded to support and sustain GNU and the Free Software movement. The values of the GNU Project were important and valuable, but it wasn’t enough to leave them out in the world on their own.

At first, the F.S.F. focused on employing software developers to work on Free Software and the GNU Project. Later, the F.S.F. transitioned to legal and structural issues to support the Free Software community.

So, it is one thing to have your values and ethics out there, but they need to be protected and respected by the rest of the world too. The F.S.F. represented the sustainability of protecting these rights and beliefs, originally put forth by GNU.

While the F.S.F. does help sustain those rights, how does a nonprofit foundation actually enforce these rights in practice?

25 Feb. 1989: GNU General Public License created 🔗

Finally, we skip ahead four more years to 25 February 1989: the first version of the GNU Public License (G.P.L.) is created. This is the license that gave “copyleft” a name. It was written and released for the GNU Project, but the license itself was stewarded by the F.S.F.

The G.P.L. put power in the hands of individual people and activists to shape how others used their software. Thus, copyleft is put into a practical legal policy. In a sense, the G.P.L. allowed software developers to place the Four Freedoms at the core of their code.

Although enforcement of copyleft licenses has a blemished history, it was still the “teeth” in translating these values and values to the rest of the world. It took inspiration from how copyright was not something often considered when distributing software until the early 1980s.

And thus, copyleft becomes a radical invention in software with the proliferation of the G.P.L., especially in its adoption in prominent projects like the Linux kernel.

Is the past relevant to social movements today? 🔗

So this was a lot of history. Is the past relevant to where we are today? First, consider how the early Free Software movement responded to these emerging societal issues in the 1980s.

Free Software was a response to the changing ecosystem of software distribution. Software became more valued because of a standardization on hardware that didn’t exist previously. There were simply fewer architectures to compile for!

Suddenly, the value of software increased. It became a commodity.

Before this commodification of software, the Four Freedoms were, in a sense, the default way of distributing and sharing software. After commodification, this was no longer true. The Four Freedoms were rooted in a belief that there are essential rights that belong to all users of computers and computer systems. Stallman observed this change directly at the MIT Media Lab in the 1970s and early 1980s. This motivated him and many others to stand up for Software Freedom by asserting these freedoms.

To respond to commodification of software, Free Software took a freedom-based approach to established their values, as the Four Freedoms. So, looking back 40 years ago, is it possible to extend and make the past relevant again in today’s changing world?

Before we can answer that, we have to first ask. How has the world changed?

Your future is the new commodity. 🔗

The history of Free Software overlaps with what is happening now.

Today the world is about predictions: predictions about human futures. This is accomplished by the combination of software and data. Human futures are a simple formula: Data + Software. Or, artificial intelligence and machine learning.

But how are human futures becoming a commodity? In the 1980s, software became the thing we “sold”. It had inherent value. Today, the ability to predict what you are doing to do next is valuable. This makes both your and my future the new commodity. Where will we go next? What will we buy next? Who have we contacted recently?

But data is only one piece of this big puzzle. It is the enabling force for determining our futures. Third-party organizations collect the world’s data on a massive, centralized scale. Your data is what allows companies to sell your future.

To add a metaphor, data is like oil, not gold. You consume the input (data) to sell the output (human futures).

Where are we today? 🔗

So, how have we responded to our changing world?

There have been some successful resistance to the new value of user data and human futures. The privacy movement and legislation like G.D.P.R. are representative of this.

However, data privacy is only one part of the big picture. Focusing on individual empowerment does not protect us from societal effects. Consider predictive policing and court rulings as two examples.

Ultimately, the data privacy movement has been a key factor in combating the effects of surveillance capitalism, but there are still gaps. Mike and I noticed we need to approach topics like artificial intelligence not in pieces, but as a whole.

And some organizations have recognized this challenge and are working to address it. “Working groups” and reports with non-mandatory recommendations are on the rise. However, these groups are not effective on moving forward ways of ensuring people are effectively protected from the unforeseen harms of AI systems. “Light self-regulation” works on an opt-in model, and it is against the interest of some actors to opt in.

So, if we are in the middle of this societal shift from software as a commodity to human futures as a commodity, where do we go from here? Do we choose chaos or community?

At time of publication, I am still wrestling with these questions. As are a lot of people! To get a wider picture of what is on my mind in 2020, read my event reports from my pre-coronavirus 2020 travels.

Photo by Shane Rounce on Unsplash.

This will be the second annual International Copyleft Conference. Participants from throughout the copyleft world — developers, strategists, enforcement organizations, scholars and critics — will be welcomed for an in-depth, high bandwidth, and expert-level discussion about the day-to-day details of using copyleft licensing, obstacles facing copyleft and the future of copyleft as a strategy to advance and defend software freedom for users and developers around the world.

This event will provide a friendly and safe place for discussion of all aspects of copyleft, including as a key strategy for defending software freedom!

Official conference website

This was my first time attending CopyleftConf. I attended on behalf of RIT LibreCorps to represent the sustainability efforts at the RIT FOSS@MAGIC initiative. However, I also represented myself as an individual in the Free Software movement. For CopyleftConf 2020, I arrived hoping to learn more about where we, as the Free Software community, are going. I also hoped to gain a deeper ethical perspective about our digital society.

Event reports take many forms. Since CopyleftConf 2020 is structured in a unique format, my event report is structured as follows:

• At a glance: structure and key takeaways: High-level overview of what CopyleftConf 2020 was like. What the biggest ideas on my mind were at the end of the day.
• Copyleft adopt curves: what drove copyright adoption then (or now?): Musings on the history of copyleft and movement building.
• Free Software, but for kids: Children and teenagers are already building open source communities. How do we include the next generation?
• Where are we going?: Software ethics and copyleft licensing.

At a glance: structure and key takeaways 🔗

If you’re here for the quick overview, this is it.

CopyleftConf 2020 is one of the best conferences I have attended. I bought my ticket the morning of the conference. Karen Sandler and Bradley Kuhn fired me up the day before in their FOSDEM 2020 talk. My initial reluctance to go was because I assumed it was a conference for FOSS lawyers. While it definitely includes that group, it isn’t exclusive to that group. CopyleftConf 2020 collected people from a diverse range of experiences and backgrounds in the open source world.

However, I also realized the “movers and shakers” in the Free Software world have been around a while. Many people there are embedded in this ecosystem for the last 10, 20, or even 30 years. I think I was the youngest person there. I realized Free Software has not done an excellent job of including my generation. This left me with interesting reflections on the future of copyleft and its ability to transfer lessons and values on to the next generation.

Structure: Dialogue and discussion 🔗

The best way to describe the format of CopyleftConf 2020 is “dialogue and discussion”. The first half of the conference started with traditional sessions, with speakers and slide decks. The end of the conference moved towards open panels with stronger audience participation. Most panels centered around topics or ideas addressed in the morning sessions.

I attended these sessions:

• Keynote (Tony Sebro)
• Copyleft adoption curves: what drove adoption then (or now?) (Luis Villa)
• Copyleft Expansion: What should – and shouldn’t – be on the table? (Deb Nicholson, Bradley M. Kuhn, Allison Randal, Heather J. Meeker, John Sullivan)
• The Rising Ethical Storm in Open Source (Coraline Ada Ehmke)
• Software Ethics and Copyleft Licensing (Karen Sandler)

I came up with three key takeaways from CopyleftConf 2020 as a whole (not including the detailed sections further below):

1. Open source is in an identity crisis. 🔗

Many people are confused. The confusion is simultaneously indecisive and divisive. I believe the identity crisis stems from that early decision in 1997 about what we call this particularly different way of developing and collaborating on software and technology. Free Software or open source? One is politically charged and historically exclusive, while the other is more neutral and business-friendly, and more inclusive to people who believe in compromise. Today, we are seeing a similar divide emerge between Free/Open Source and Ethical Source.

There are several emotions. It is deeply personal. For some, the promises of free/open source failed our collective humanity. For others, open source is a vastly successful turn of events to make the closed world more open. Yet for others still, it is both. CopyleftConf 2020 took a highlighter to this tension between what we consider right and wrong. It also questioned what the role of Free Software is in all of this.

I don’t think anyone has the answer yet. Surely some people left CopyleftConf 2020 with a more clear view if they think licensing is a viable approach or not. But CopyleftConf 2020 did not have this answer. It just made it clear that most of us are still wrestling with this.

2. Millennials are underrepresented. 🔗

Most of the time I was at CopyleftConf 2020, I had massive imposter syndrome. This is no fault of the conference or the great steps the organizers took to make it inclusive, but wow. There were so many people there who I have seen all across Twitter. People who are moving and shaking in different realms of the open source world.

Yet as I looked around the room, I started to wonder what the average age demographic of the room was. Being in my early 20s, I felt like I was in a room of Free Software giants. Many people there have been pushing the conversation forward and definitively fighting for Software Freedom for a decade or more.

And then there was me. I don’t know what my role or higher calling is yet in this great big movement we call Free Software. While I was glad to be in the room, I felt sorely underrepresented in age.

Born digital 🔗

I couldn’t help but find it unusual though. My generation and those after me are the first generations who were born into the digital society, built by those who came before us. When I was four years old, I was privileged to have my own computer. By six, I was connected to the Internet (even if it was dial-up). By fourteen, I was in a Linux command line running my own Minecraft server with thousands of players.

While my perspective is rooted in some privilege, there is something interesting in my experience. I was born into a world where I didn’t make the choices of what hardware or software I used. In the beginning, everything was handed to me or provided for me.

For kids and teenagers today, this couldn’t be more of a reality. Before COVID-19, when you went out to a restaurant or public place, how often would you see a small kid clutching a tablet, provided by an exhausted parent? Adolescents today grew up in the always-online worlds of Google and Snapchat.

Today’s teenagers and young adults I know are often keenly aware that they are the prey in a complex digital world they are already so deeply embedded in. So, why resist at all? To them, there is little point in resisting because all the technology decisions made for them early in life locked them deeper into this “predator-prey” ecosystem.

Is Free Software ready for the millennials? 🔗

So, I felt like an imposter at this conference of people who are wise to the role of Software Freedom in our new digital society, but never grew up in the kind of world I did. A lot of the people in the room at CopyleftConf 2020 developed their worldview, ethical perspectives, and software preferences as the world changed around them. Me and other people of my generation were born into this world.

It makes the conversation around Software Freedom very different, and also challenging, because the next ten and twenty years of Software Freedom will have to include today’s youth to be truly sustainable.

3. The world is changing. Will Free Software? 🔗

Related to the identity crisis and under-representation of youth, the theme of change begins to emerge. Stallman and other Free Software leaders in the 1980s and 1990s were ahead of their time to realize the importance of Software Freedom in respecting and protecting user freedom. Some of those same people were also in the room at CopyleftConf 2020.

But today’s world is changing. Software became the commodity in the 1970s and 1980s. Free Software was the resistance. Today, data is the new digital commodity. Software is just one piece of a bigger puzzle. Software Freedom may protect one aspect of our digital lives, but it would be nonsensical to assume the digital world would stay the same. Why should Free Software?

The 2020s will be definitive 🔗

So, CopyleftConf 2020 made me realize that the next ten years will be definitive. The 2020s will determine whether open source becomes yet another cog in strengthening our capitalist society and enthroning corporations as a great benefactor to technology, or if Software Freedom undergoes some sort of transformation to meet the new demands of freedom in our digital world.

No matter your political leanings, read any news site that isn’t a tech journal and tell me honestly that there are not some scary trends in our technology world. COVID-19 is just the latest example, with our data privacy and digital rights being on the sacrificial alter for our “safety” and “protection”. This line is all too common. I have heard it as a justification of many things across my life since September 2001.

So, what will Free Software do?

Copyleft adoption curves: what drove copyright adoption then (or now?) 🔗

Copyleft adoption has changed significantly over time, for better and for worse. This talk will survey the many factors that drive adoption, with particular focus on GPL v2 and Affero GPL v3. While some factors are obvious and reasonably well-understood (particularly the shift towards SaaS economics) many other nuanced factors play in as well.

Luis Villa

What I highlighted in my notes from Luis’s talk was his history lesson on adoption. While the history of Free Software wasn’t new to me, nor most people in the room, Luis took it in a different way. His history lesson was a reflection on “why?” and not just “what?”

Whether you think Free Software “won” or not, open source is here to stay. So, how did we get to where we are today? How did a famous software company go from calling open source an “intellectual property cancer” in 2001 to investing billions of dollars into open source and open source companies by 2020?

Add more chairs to the table 🔗

I loved this quote that Luis dropped: “Movement building is the only way to influence political change.” Luis gave examples from the 1990s of how evangelism and education were part of the building blocks of open source. There were “leading apps” that brought new people to the Free Software (or open source) table. Mozilla was the first browser that brought common lawyers in. A focus on education for lawyers, such as the F.S.F.’s 22,000 word F.A.Q., converted a motivation to learn into practical knowledge used for compliance work.

However, I think Luis’s goal was to define, not to prescribe. He implied that building a movement doesn’t start with writing a license, based on his personal experiences (he did lead drafting of the Mozilla Public License). My takeaway from Luis is that we need to think about how we build a movement that includes people who aren’t at the table today to build a strong foundation for what comes next.

Free Software, but for kids 🔗

There was a panel on copyleft expansion and what should and shouldn’t be at the table. At some point, the role of “the next generation” came up in heralding the values of copyleft licensing forward in light of the popularity of permissive licenses.

This was personal. My first experience in the open source world was as a community member and later a volunteer staff member of the largest open source Minecraft server software project. In my time in that community, I learned a lot. I saw a major breakdown of the GPL for a community of hundreds of thousands of young adults, teenagers, and children. So, indeed, how is “the next generation” going to herald these values of copyleft licensing?

Talk with us, not at us 🔗

It is interesting to be present in these conversations about “the next generation” because it usually feels like people are talking at me instead of with me. It took some reflection time to realize this after CopyleftConf 2020, but I feel like some older folks like to imagine that younger folks will come on board and just start steering the ship in the same course it has always traveled. Some younger folks may be fine with that.

But I also think a lot of younger people will ask more of Free Software because of our collective experiences with Free Software licenses. From my hey-days in the Minecraft community, there is bad blood towards the GPL and copyleft licensing because of the scars it left on the community, even if it was really because the GPL should never have been used in that context.

But the demands for more also stem from the collective treatment by those senior to us in traditional “FOSS circles.” Even at my university, I also see how students become bitter and frustrated in instances where senior faculty and older community members insist on a Free Software-first, no-compromises approach. As if it were so simple for my generation.

I already explained the perspective of younger folks earlier in this blog post. But the way some senior folks treat us in the proper Free Software world is sometimes exclusionary and off-putting, even if that isn’t the intention. It discards great opportunity for guidance and mentorship. There is an innumerable amount of times an older person completely dismissed my decision to use a proprietary or mixed-source platform for a community, yet they lament about not having the patience to troubleshoot the Free Software tools they rely on when they fail (mailing lists and email spam filters, I’m looking at you).

Teach early and teach often 🔗

But that point aside, let’s bring it back to the panel. I think it was Allison Randall and John Sullivan who emphasized the importance of early education around the concepts of Software Freedom. The average middle school student interested in STEM will not comprehend the GPL. However, the Four Freedoms (by design) are easy to comprehend. The freedoms to Read, Run, Remix, and Redistribute are not that difficult to understand. Perhaps part of the answer lies in how we think about messaging to younger folks and keeping foundational concepts like the Four Freedoms at the forefront.

I still lament over the way that Free Software built itself in a technology-centered way instead of a people-centered way, but I digress.

Where are we going? 🔗

The hottest discussions I participated in were from The Rising Ethical Storm in Open Source (Coraline Ada Ehmke) and Software Ethics and Copyleft Licensing, emceed by Karen Sandler. Coraline dropped absolute fire in her talk, even knowing that the essence of her talk would alienate some people. But it was a call-out to us folks in tech who consciously or unconsciously live these values that our Free Software movement is built upon: the freedoms of personal liberty, as it lends itself both for justice and harm.

I won’t spend a lot of time summarizing these talks and sessions, but one interesting thing to look up that Coraline mentioned was the Parable of the Locksmith.

During Karen’s session, I penned what ended up being a short speech in my notebook. When I was eventually passed the mic, I tried to fit too much into too little time, and I was not fully respectful of other folks who also had something to contribute to the discussion. So, instead, I will recap the full essence of what I wanted to say in my blog post.

Our software freedoms are not enough 🔗

The Four Freedoms, the foundation of all copyleft licenses, is not enough.

On the Saturday before CopyleftConf 2020, I presented at FOSDEM 2020 with my colleague and dear friend Mike Nolan on three new freedoms for AI that go beyond software. In our talk, we analyzed the history of how Free Software began as a social movement. It roughly flowed as follows:

1. GNU Project, 1983: Establishment of values
2. Free Software Foundation, 1985: Establishment of organization to champion the values
3. GNU Public License, 1989: Establishment of license to enforce and protect the values

In today’s complex and changing world, we need more than Free Software’s Four Freedoms. This libertarian base was susceptible to the co-opting of its values as “open source.” It was always inevitable, because Free Software was built from the strengths and biases of those who founded the movement (i.e. Richard Stallman).

Free Software was designed with technology at its center, not people. This is to say, it was poorly designed.

Now, we have an ethical dilemma that was always possible because Freedom means freedom to do as you wish, not the freedom of all people.

Some context for discussing legal issues is key, but we need to push the conversation forward beyond semantics. We need to identify whether unethical uses of our software is something we will tolerate. We can’t continue to ignore or delegate social responsibilities for what we do.

So, now what? 🔗

On one hand, we need to be ready to have these conversations about real effects and the impact of what we do on people. Look at the Facebook news feed and the Myanmar genocide. Legal semantics is where we are stuck since we defined the Four Freedoms. But these freedoms are no longer enough.

There is not one answer of where we are going. There are only multilateral answers. We have to be intersectional and inclusive for where we go from here. Free Software needs to turn to its allies not only in law and licenses, but also in labor organizing and regulation authorities.

One direction on my mind is continuing to support D&I initiatives like Outreachy. Outreachy interns do awesome things during their internships, and many continue to do awesome things even when their internships end. Bringing more diverse perspectives to the table, especially from underprivileged groups, is key to giving those perspectives equitable power and influence.

We do have the power. 🔗

But everyone in that room at CopyleftConf 2020, and you, the reader, have some power. We all have some room to influence change for good. But we cannot avoid the discomfort. We can not keep turning away our eyes.

So, what will you do?

For me, I am wrestling with that question actively as I continue to make my way out into the world.

Thanks folx! 🔗

To wrap up this CopyleftConf 2020 report, a few thank-yous are in order:

• Stephen Jacobs: For always being supportive for yet another trip abroad and helping me push my career forward in a number of ways (and footing the bill!)
• Mike Nolan: My co-conspirator, partner in FOSS, and comrade in arms
• Software Freedom Conservancy: For creating and holding this important space.

CopyleftConf 2020 continues to give me a lot to think about and consider. I’m fortunate to have attended. I hope this event report gives additional visibility to some of the conversations held in Brussels this year.

This blog post is a story roughly covering 2010 to 2014 on the meaning, values, and promise of open source. This story impacted a community of hundreds of thousands of people, mostly adolescent children, teenagers, and young adults. It is a tale about the simultaneous success and failure of the GNU Public License (GPL).

From the beginning: Bukkit, Minecraft, and the GPL 🔗

In the beginning, in December 2010, there was Bukkit.

Bukkit is an up-and-coming Minecraft Server mod that will completely change how running and modifying a Minecraft server is done - making managing and creating servers easier and providing more flexibility. Learning from the mistakes made by other mods, Bukkit aims to be different and fill the void left by them: built from the ground up we’ve focused on performance, ease-of-use, extreme customisability and better communication between the Team and, you, our users. The overall design of Bukkit has been inspired by other mods and our experience as Minecraft players just like yourselves, giving us a unique perspective and advantage going into the creation of the Bukkit Project.

About Us, Bukkit.org

Bukkit was an open source server for Minecraft. It provided an API for developers to create plugins that extended Minecraft in unique and fun ways. While Bukkit was not the first open source Minecraft server, it was the first organized project. Bukkit launched with the GNU Public License (GPL) v3 license.

From 2011 to 2014, Bukkit was the de-facto standard for running a Minecraft multiplayer game server. Over time, more Bukkit servers (and derivatives) were used than the official server software distributed by Mojang. Mojang is the company responsible for Minecraft development.

Hard work on Bukkit recognized 🔗

The project’s success was also recognized by Mojang too. At the first-ever Minecraft convention in 2011, MINECON, four Bukkit lead developers were hired by Mojang to work on Minecraft. All but one of the hired employees then departed from Bukkit. That one developer who remained active in Bukkit would depart from Mojang mysteriously in 2013.

Had a great time working for Mojang but it's time for me to pursue other interests. As of yesterday, I am no longer working for Mojang.

— EvilSeph (@EvilSeph) October 2, 2013

However, there was always one caveat. Bukkit was an open source project licensed under the GPLv3. However, it also reverse-engineered some parts of the Minecraft game code to build its server code and API. This was never a problem for Bukkit or Mojang:

“When we started up Bukkit in December of 2010, we decided we wanted to do things right. Right from the beginning we wanted to be sure we were bringing about a positive change to Minecraft, one that Mojang themselves would approve of. To that end, we set up a meeting with Mojang to get a feel for their opinions on our project and make sure we weren’t doing anything they didn’t like. The gist of the meeting was that Mojang “liked what we were doing” but not how we had to go about doing things. Unfortunately, we both knew that we had no alternatives, so we continued along - albeit now with the reassurance that our project would most likely not be shut down any time in the future.”

EvilSeph (Warren Loo), “Bukkit: The Next Chapter”

Nobody ever raised a copyright issue over the reverse-engineered code from Minecraft in Bukkit. Yet, for years, the GPL code released by Bukkit included bits from official Minecraft code.

Act 1: The Minecraft EULA 🔗

An alternative perspective on the Minecraft EULA is in this Guardian article. “Minecraft: how a change to the rules is tearing the community apart.”

All was fine for a number of years. Bukkit was a volunteer-led project even after some of its core developers were hired to work at Mojang. However, in 2014, unrelated tension started to grow in the Minecraft community.

The tension was about the language used in Minecraft’s End User License Agreement (EULA). The EULA used ambiguous language over the monetization of Minecraft multiplayer servers:

“The one major rule is that you must not distribute anything we‘ve made. By “distribute anything we‘ve made” what we mean is “give copies of the game away, make commercial use of, try to make money from, or let other people get access to our game and its parts in a way that is unfair or unreasonable”."

2014: account.mojang.com/documents/minecraft_eula

While many open source projects flourished around Minecraft, a huge game server industry also co-existed in this ecosystem. Multiplayer server owners running Bukkit (or derivative projects, like Spigot) created web stores for their servers. Players paid real money to buy in-game perks for a specific multiplayer server. Using open source plugins, players paid for things like item packages with diamond swords or virtual currency to spend in-game.

This behavior was allowed to flourish for years. However, the EULA was discreetly edited in December 2013. In mid-2014, someone in the community noticed the changed language. They tweeted and tagged a Mojang employee asking if this meant multiplayer servers had to stop selling in-game items for real money. In as much detail that a 2014 tweet with a 140-character limit allowed, the Mojang employee confirmed the EULA language did technically forbid that.

Panic! In The Bukkit Server 🔗

“Then, everything changed when the Fire Nation attacked.”

The community erupted into chaos. Suddenly, a community that had mostly co-existed peacefully was at a virtual war with each other. The situation was understandable from both ends, if for different reasons.

Anyone could start their own multiplayer server. So it was possible for malicious servers to scam players (usually young children) of money. Usually this happened by failing to deliver on the purchases or closing down after a period. Frequently, Mojang was contacted for help (usually by angry parents) about game servers Mojang did not control.

At the same time, many good people built (probably unwise) business models around the permissive nature of Minecraft intellectual property. The open source software made it easy to extend Minecraft in ways Mojang did not intend.

Act 2: The Bukkit cards are revealed 🔗

Tension was already high between the the trinity of business owners, open source developers, and Mojang. By 2014, Mojang was a multi-million dollar company (even before their multi-billion Microsoft buyout). The EULA tension placed a heavy burden on the open source developers, who received pressure from both ends.

Then, the unexpected happened on August 21st, 2014. The Bukkit project lead, Warren Loo (EvilSeph), announced the end of development on the Bukkit project:

.@CraftBukkit: It's time to say goodbye - http://t.co/LRG2uiMbDe

— EvilSeph (@EvilSeph) August 21, 2014

Read the full announcement from Bukkit team

Bukkit gets “owned” 🔗

This was sad news. But the real shock came an hour later when the lead developer of Minecraft at Mojang shot back on Twitter:

Warren over at bukkit seems to have forgotten that the project was bought by Mojang over two years ago, and isn't his to discontinue.

— Jens Bergensten (@jeb_) August 21, 2014

Two other former Bukkit developers working at Mojang chimed in too:

We took ownership of the Bukkit github repos & project. We'll see what happens from here.

— Erik Broes (@_grum) August 21, 2014

To make this clear: Mojang owns Bukkit. I'm personally going to update Bukkit to 1.8 myself. Bukkit IS NOT and WILL NOT BE the official API.

— Nathan Adams (@Dinnerbone) August 21, 2014

It was now revealed that the Bukkit open source developers hired by Mojang in 2011 had given up their personal copyright and rights to their open source contributions as part of their employment contracts. The open source developer and business owner communities both learned this abruptly over a 140-character tweet.

The community was confused, upset, and angry.

“The decision to keep the acquisition of the Bukkit codebase a secret was made between Mojang and Curse, which only recently came to light. I was completely unaware that I had spent the last two years of my life as a Bukkit Administrator, and successor to the project lead, under the illusion that the project was independently ran. Had I known back then perhaps my choice would have been different, perhaps not. It’s easy to speculate on what might have been, but unless faced head on with the choice, the decision is not always clear.”

TnT, “So long, and thanks for all the fish”

What is known now was that for about three years, the volunteer-driven open source project was “owned” by company valued for millions of dollars that did little to support the open source project that helped build a community around the game. The only visible contribution made by Mojang to Bukkit was the explicit permission to continue their endeavor in the legal gray area.

Act 3: DMCA take-down of Bukkit 🔗

On September 5th, 2014, a lead developer not hired by Mojang, who had contributed over 15,000 lines of code to the project, invoked a Digital Millennium Copyright Act (DMCA) take-down on all of his personal contributions to the project (and all derivative projects). In a day, all the source code for a project used ~3x more than Mojang’s official server software disappeared from the Internet.

It is easy to understand why this lead developer did what he did. To find out the last few years of your life spent volunteering on a game project that was secretly owned by a multi-million dollar company is a shattering experience. It’s essentially free labor. But at the same time, this was a project used by hundreds of thousands of people around the world. It was more than a project; it was also a community.

One of the lead developers of Bukkit said this of the project in their resignation letter to the community:

“The Bukkit Project is so much more than CraftBukkit, getting updates out and providing API. It’s about giving the community a place where they feel welcomed and can program to their hearts’ content with the use of our product. The Bukkit API gave people the ability to change the behavior of Minecraft, but it would have meant nothing without the contributions from the plugin developers in the community.”

feildmaster

The DMCA take-down wasn’t just a take-down of the software; it also was a take-down of a community. The overnight disappearance of Bukkit left a huge power vacuum full of bitterness, personal harassment, and doxing. (Don’t forget this was also the era of #GamerGate.)

Who was this community? 🔗

The project I participated with, Spigot, was a fork of Bukkit created in 2012. Like Bukkit, Spigot was also hit by the DMCA take-down, although the Spigot team worked out a clever legal workaround to continue development.

A huge plugin community and third-party software around Bukkit’s API grew around both Bukkit and Spigot. The unusual thing was, with few exceptions, most of the leaders of these communities were young adults in their 20s, teenagers, or even 11 year old kids. Open source wasn’t a strongly understood concept in this community. It was just what everyone did. The messaging around licensing was not always great, but working in the open was the nature of how this gaming community operated.

The spirit of open source died 🔗

For this community, the promise and glory of open source died. For years, the Bukkit developer team shared their belief in open source with the community:

“Bukkit chose to go the open source route with our API for several reasons. Not only is open source awesome, but we knew that there were many talented individuals within the Minecraft community that could help us evolve, mature and grow our project much faster than we could have ever dreamed on our own.”

EvilSeph (Warren Loo), “Bukkit Project Changes and Improvements”

But with the complications of a project doomed to failure under the GPL that never should have been, combined with the hidden secret of ownership and DMCA take-down of open source code, the promise of open source both helped and failed this community.

Who was right? Who was wrong? 🔗

On one hand, the lead developer who issued the DMCA take-down was able to vent the frustration faced by those who discovered their secret “free labor” agreement with Mojang (at a great personal cost, as he was harassed, stalked, and received death threats). On the other hand, the collective community faced the end of an era brought about extraordinary circumstances that actually voided the GPL as a valid license:

“A license is a contract. There are many reasons why a contract would be void, and many conditions that make a contract invalid from the get-go. One such condition is being “tricked” into the agreement, which would include agreeing to work on a project under false pretenses. As stated above, an open source project being secretly purchased by a company, in hopes to have that company’s game be improved through it, is as close to a loophole for free labor as you will find. Free labor was outlawed in this country a while ago. We had a whole war about it.”

/u/VideoGameAttorney, “My Response to Vubui, Mojang, and the hundreds (yes, hundreds) of you who asked me to weigh in on this.”

The only conclusion I can muster on this saga is from that same Reddit thread: “But at the end of the day, don’t just believe one side is “good” and the other “bad” here. These things are rarely so simple.”

Why did I write this? 🔗

Because I keep coming back to this story, across my life. I was writing an event report about a copyleft licensing conference I went to in February 2020, when I recapped this same story to someone there in-person. It wasn’t the first time I told this story at a conference though. It’s such an interesting case study of copyleft licensing.

Because it is in the open source gaming world and the largest demographic of this particular gaming community is under 30 years old, many folks who have been “around the block” in open source are unaware of this story.

But as my first open source community and also something I invested nearly a whole decade of my life into (as have countless others), this experience shaped my outlook on open source and community in an unusual way. It’s an experience I can’t forget. Even if I only have an abrupt ending to this story, it’s a story that I think deserves to be told, in respect to those who invested far more time, energy, money, and tears in this than I ever have.

Where Byfield was accurate 🔗

While I don’t agree with all of Byfield’s sentiments, he identified some key challenges that still hold truth today: a predisposition to focus on differences and not similarities, an outreach approach centered on ethics and not software, and the importance of opportunities for intersectional interaction.

Predisposition towards difference 🔗

First, Byfield notes the differing age groups of the activist communities and the tendency for viewing others by their differences first, not their similarities. He seems to attribute the tendency to view others by differences first as a characteristic of older generations; however, this is not necessarily the full truth.

As a member of the young activist community, this explanation is too simplistic of the underlying cause. There is also a political motivation by established power to sow division among the population of a nation-state. It makes community organizing more difficult and presents diversity as an issue to “solve” instead of a source of greater unity and common strength.

This is exemplified by the social media algorithms of today that reward sensational content (judged on likes, views, clicks, or other user feedback) and share it widely across a huge platform. In 2006, it was difficult to imagine the relationship social media would have in the lives of an everyday person; today, a great deal of social power is granted to those who understand how to leverage social media, either for good (e.g. social activism) or harm (e.g. deceptively persuading large parts of a nation-state’s population leading up to a national election).

The politics of division are within the fabric of our political systems; this is a challenge for modern-day activism and community organizing to overcome. In identifying this as a challenge, Byfield is correct that a differences-first approach makes it harder to share and spread the importance of FOSS in other activism circles, especially as technology becomes an increasingly relevant way of how we experience our lives and how our systems of law and justice are enforced.

Outreach on ethics, not software 🔗

Second, Byfield suggests an ethics-based approach to outreach is more effective than a software-based approach. This is also correctly noted, even if perhaps overemphasized. The jargon and language of the technology world is not accessible to the large majority of the global population. While some degree of technology literacy might be expected in some populations, much of the existing FOSS community is deeply rooted in technology. Sometimes this limited perspective is counterproductive.

This revisits the rebranding of “Free Software” as “open source” in 1997. For many subsets of the wider open source community in 2019, the default approach to open source software is merely a secondary thought for how to collaboratively work on technology. This is part of the outcome of the Open Source Initiative’s gamble in 1997 by beginning to emphasize the business sensibility and practicality of open source, and de-emphasize the social roots of Free Software (or rather, try and position itself as some sort of translator between these two “worlds”, as if they cannot be spoken of together in the same room).

As such, those who work on open source software projects are not necessarily predisposed to assume the role of an activist. Truly if Free Software is to take root outside of technology, then those who see the ethical values of Free Software need to better organize and promote the values of FOSS externally. This will contribute to the diversity of Free Software activism by helping non-technology activists add FOSS as a tool to their existing work.

Intersectional movement building is the future 🔗

Thirdly and finally, and perhaps most importantly, Byfield suggests the importance of intersectional interactions between Free Software communities and other activist communities. This is a fundamental requirement for the growth of Free Software as a social movement. Those of us in Free Software see the world around us informed by a background informed by technology; this background is emphasized in a world that is generating new, advanced technology at an unprecedented rate. However, while software and technology are important parts of the world around us, they are not the world around us. They are one part of a greater picture of fighting for a common good and welfare for all people. There are others in similar niches who have a deep understanding of their problem space and how they want to approach a challenge.

“One group may be working against child poverty, another for recycling, but the people in these organizations can almost be transferred from one to the next.”

Peter T. Brown, Free Software Foundation Executive Director (2006)

Just like a healthy garden, cross-pollination of these niches is vital to help others understand how we can help each other in accomplishing our mutual goals (this also feeds into why the politics of division explained above is so pervasive and difficult). Bringing Free Software technologists to activist communities where there is not an overwhelming Free Software background (and vice versa) is vital to building an intersectional social movement that strengthens the social impact of Free Software, not just open source.

Where Byfield didn’t go far enough 🔗

Byfield made one assumption on how activists have “their own share of insularity” and that the presence of connections between two movements does not mean they could immediately connect their existing beliefs with new ones. Fioretti’s challenge was in others understanding why they should listen to him; there was a lack of foundational knowledge of open source and technology that is normally assumed of someone who works as a software engineer.

Indeed, attention is a currency in the world of an activist. It is not enough for a FOSS advocate to expect others to listen to you on an appeal of technology. Part of the work in sharing is understanding who you are sharing with; if FOSS wants to take deeper roots in the activist community, it needs to understand the backgrounds of activist communities and be creative in how to appeal the mission of FOSS to the mission of their work. Where you can build in-roads together with others through common initiatives is the beginning of grassroots community organizing. So, while Byfield is right that there is an almost competitive nature of ideas in activism, it is not enough to write insularity off as a fixed aspect of nature. To not acknowledge this is to deny the influence of capitalist power structures in the humanitarian sector as they pertain to sustainable funding.

What are today’s challenges? 🔗

Some of today’s challenges are about inclusion and power.

Inclusion builds power 🔗

Diversity and inclusion (D&I) are important but poorly understood; not only are D&I about including people of different identities in technology, but also people with backgrounds outside of technology. FOSS stands to benefit by including more people who do not necessarily have a strong technology or engineering background. The goal is to inspire different perspectives to contribute in meaningful ways to build sustainable technology.

Instead of seeing diversity and inclusion initiatives as problematic or unneeded, D&I groups in FOSS communities stand to be the most effective people at building community and influence.

Power and governance 🔗

In the activist / humanitarian / non-profit world, there is a power struggle for sustainability as it pertains to funding. Funding models in non-profit work (usually sustained by grants, sponsors, and donors) encourage solutions that get funded, not necessarily solve problems the most effective way. Many organizations struggle with how to achieve sustainable funding without being so dependent on the expiration date of a grant’s funding.

We need more representative governance models in open source communities that reflect the interests of the communities around them, not necessarily an individual, a company, or group of companies. Building governance models that empower people within a community to make decisions and reduce the corrosive influence of money from humanitarian work.

Where do we go from here? 🔗

This blog post is an active reflection of my own thoughts and perspectives of Free Software, activism, and humanitarian work. If you are interested in pushing this conversation further, find me in Brussels, Belgium for any of the following three conferences and let’s chat further:

• 30 January 2020: Sustain Summit
• 31 January 2020: CHAOSScon
• 1-2 February 2020: FOSDEM

If you want to discuss this further, you can also drop a line in our online discussion community, fossrit.community.

Photo by Walid Berrazeg on Unsplash

Today’s entry to the blog is sourced from a thread that I posted on the SpigotMC Forums. If you wish to join in the discussion about this, feel free to chime in on the thread or leave a comment on my blog. In this post, I covered licensing, licenses, and why your open-source software project should have a license. You can read my original post in this blog entry.

I’d like to share some personal and real-word advice to many of you contributing open-source resources to Spigot, but also to other open-source software projects you may work on even outside of just Minecraft or Spigot.

Licensing 🔗

What is licensing? Why does it matter? Why should you care? There are many reasons that licensing is an important part of a project you are working on. You are taking the time to write code and share it with the world in an open way, such as publishing it on GitHub, Bitbucket, or any number of other code-hosting services. Anyone might stumble across your code and find it useful.

Licensing is the way that you can control exactly how someone who finds your code can use it and in what ways.

Okay, why does it really matter? 🔗

Maybe you’ve been writing code for a really long time and you’ve never bothered with licenses and don’t feel the need to. I’d like to present two hypothetical situations that I see pop up all the time, one in Spigot and one in the greater open-source community.

Your Plugin 🔗

You have spent a lot of time writing an awesome resource and you pushed all of your code on GitHub! Woohoo, project complete! You package it up as a JAR and submit out to the open. Skip ahead a few months, and maybe you no longer have the time to contribute to your project. Or maybe someone has an awesome idea for a totally different plugin that uses similar functionality to what you have written.

A new person finds your code on GitHub and discovers that it has the perfect method or algorithm for his own project. Or maybe they want to continue your project with new, fresh energy! But you have no license for your code. By default, this means default copyright laws will apply to your code. This is an extremely limiting type of copyright enforcement and almost defeats the entire purpose of even open-sourcing your code. A law-abiding programmer might just give up on the project and look elsewhere, or maybe a not-so-law-abiding programmer will secretly copy and paste your code without attributing your work back to you. This helps neither you or the friendly programmer looking at continuing or forking your work.

In many cases, the SpigotMC Staff receive reports about people “copying” other peoples’ code. Having a licensed project makes reviewing these reports 10x easier. People without licenses or with ambiguous sources makes it extremely difficult to review and make decisions about whether projects are copies.

By licensing your code, you are protecting your own work and writing the rules to how people can use your code. If you are open-sourcing your code, usually the point is to have collaboration with others and give back to the community by allowing others to tinker, modify, or play with what you have created. Make it easier for others to contribute, help, or build new awesome things by choosing a license!

Your Project 🔗

For any open-source software project on the Internet, having a license is very, very important. For example, let’s say you write an important library or utility that can be used to make a developer’s life easier for making a user interface more friendly. Your program is well-designed and has usefulness outside of what even you intended to write it for.

Perhaps a large company stumbles across your code and also thinks it’s very useful for their own project. Maybe their project is proprietary or closed-source. Having a license in a situation like this suddenly becomes very important. Some licenses would permit this company to take the plugin or library, modify it to their own needs, and include it in their own product, while only leaving a small mention to you in the “Legal” section of their app. Maybe you’re okay with that! Maybe you’re not.

If you’re not, there are licenses that let you define how the code is used in a case like this. With some licenses, if the company decides to modify and use your code, they will have to open-source their changes that made as well. If they don’t modify anything, they just have to link back to your original source code. In some more extreme licenses, anything that touches your code also by extension has to be open source.

For a Minecraft example of this, let’s say you have a “Super Craft Bros.” plugin open-sourced on your GitHub. Hypixel stumbles across your code and decides they want to use it for their own servers. Let’s say your code is licensed under the Mozilla Public License 2.0. For this license, if they take your code and make no changes, they only have to give credit back to you. If they take your code and change it, they also have to open-source all of the changes they make to your code.

Now, the changes made by the bigger company can benefit many others instead of just the one company!

What licenses are there? 🔗

If you Google “open source licenses”, you may be overwhelmed. There are maybe close to the hundreds of different licenses for you to choose from. How can you pick one to settle on?! Fortunately, there are websites that do a great job of summarizing licenses to exactly what others can or cannot do with your code. A very popular site is tldrlegal.com, which provides bullet-point summaries of different licenses.

tldrlegal.com 🔗

Exploring that site is a great reference for picking a license. However, in this thread, I’m going to do a very quick summary of four of the most popular open-source licenses that exist. However, it is important to preface this with a statement: I am not a lawyer and this does not constitute legal advice. It is important for you to look more into a license that feels right for how you want to share your code and determine what others can do with it.

MIT License 🔗

The MIT License is almost universally regarded as one of the least strict licenses in open source. You can read more about it here.

You can:

• Use the work commercially (think of the big company example said earlier)
• Modify the original code
• Distribute the original code or distribute your modifications
• Sublicense the code (in other words, use it with code that has a different license)
• Use the code for private use

You cannot:

• Hold the original author liable for damages
  • So this can’t happen: “Oh noes! I accidentally exploded my entire server with your code! You must pay me monies to fix this nao!!!”

You must:

• Include a copyright notice in all copies or other uses of the work
• Include an original copy of the license with the original or modified code
  • You will always be credited for your work!

Apache License 2.0 🔗

The Apache License 2.0 is only slightly more restrictive than the MIT License, but it defines a few more rules than the MIT License. This can be useful if you want to make sure your work is given proper credit back to you and you care a little more about how it’s used. You can read more here.

You can and cannot do the same things mentioned above for the MIT License. So we will just highlight the changes!

You can:

• Same as MIT License
• Use patent claims (might be advanced for most of you, but can be useful for bigger projects)
• Place a warranty (lets you have a warranty on your code, if desired)

You cannot:

• Same as MIT License

You must:

• Same as MIT License
• Openly state changes you make from the original project
• Include the NOTICE (if the project has a NOTICE file, you have to keep it in copies / modified works)

Mozilla Public License 2.0 🔗

The next step up from the Apache License 2.0 is the Mozilla Public License 2.0. This license has the same basic rights as the Apache License 2.0, but it goes a little more in-depth about how the code can be re-used. This is my personal favorite license! You can read more here.

Most of the things for what you can and cannot do are the same as the Apache License (and thereby, the MIT License). So again, we’ll just highlight the changes.

You can:

• Same as Apache License 2.0

You cannot:

• Same as Apache License 2.0

You must:

• Same as Apache License 2.0
• Disclose the source (any changes made using MPL’d code must also be made open under the MPL!)
• Include the original (either the source code or instructions to get the original code must be provided)

GNU Public License v3 🔗

The GNU Public License v3, also known as the GPLv3, is one of the most well-known and strict licenses in open-source. It has very specific rules for how the code can be used and shared, and leaves a lot of control over to the author. In a sense, it’s “after” the MPL 2.0, but it also has some key differences. You can read more about it here.

Again, we will highlight the changes from the Mozilla Public License 2.0.

You can:

• Same as Mozilla Public License 2.0 (except sublicensing)

You cannot:

• Same as Mozilla Public License 2.0
• Sublicense the code (this is a big concept worth understanding if you use the GPLv3)

You must:

• Same as Mozilla Public License 2.0
• Include original copyright (must be retained in all copies or modified works)
• Include install instructions (you must document how to install the software)

Go forth and conquer! 🔗

Congratulations! You now know a little bit more about licensing, open-source licenses, and how to use them. Hopefully this will help emphasize why and how licenses are important in open-source software. In many ways, the license you choose to use can even be more important than any lines of code you write. That might sound absurd, but when it comes to deciding how your code can be reused, modified, or distributed, it’s something that can be vitally important to your project.

Those of you without a license, please consider choosing one, or talk to other teammates of your projects about what license you all want to use. If you code in the open, make sure you are protecting yourself and paying attention to how you want other people to use your code.