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.

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.

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.