Skip to Main Content
Lightning Talk Beginner

Open Source Licensing for Developers: Avoiding Legal Landmines

Review Pending
Session Description
  • When Oracle acquired Sun Microsystems, Hudson's community voted 93% to fork and rebrand as Jenkins.

  • When AWS launched a managed Elasticsearch service without collaborating, Elastic changed their license — triggering a years-long feud that only resolved in 2024 with triple licensing.

  • Oracle still holds the "JavaScript" trademark, and Deno Land is fighting to cancel it.

These aren't hypotheticals — they're consequences of licensing decisions that every developer should understand but few do.

This lightning talk walks through the families of open-source licenses — permissive (MIT, Apache 2.0, BSD), copyleft (GPL v2/v3, AGPL), and the newer source-available models (SSPL, BUSL) — using real corporate battles as case studies. We'll cover why GPL v2's SaaS loophole led to AGPL, why MongoDB's SSPL was rejected by OSI, and what happens when one AGPL component can infect your entire stack.

Most developers write 4 lines of code but pull in 12 dependencies — each carrying its own license. One wrong dependency in a commercial product can mean forced open-sourcing of your codebase, legal notices, or worse. Licensing isn't a legal team problem anymore — it's a developer problem, and every npm install, pip install, or mvn dependency deserves a second look.

Key Takeaways
  • Understand the real differences between permissive (MIT, Apache 2.0), copyleft (GPL v2/v3, AGPL), and source-available (SSPL, BUSL) license families — and why each exists.

  • Learn from corporate case studies: how licensing decisions led to the Hudson→Jenkins fork, the AWS-Elasticsearch feud, and the JavaScript trademark battle.

  • Recognize the GPL SaaS loophole, AGPL's "infection" risk, and why companies like MongoDB and Redis moved away from OSI-approved licenses.

  • Know when adding a single dependency can force you to open-source your entire stack — and how to audit for it using tools like FOSSology.

  • Understand why licensing is a developer responsibility, not just a legal one — every dependency you add carries a license, and ignoring it doesn't make it go away.

  • Walk away with a decision framework and resources (choosealicense.com, CMU's license grid) to pick the right license for your next project.

References

Session Categories

Technology / FOSS licenses, policy

Speakers

Surendar Vinayagamoorthy Lead SDE | M2P Fintech

Polyglot programmer who talks to machines for a living and occasionally to humans about open-source software, developer tools, and the hidden complexities behind everyday code.

Surendar Vinayagamoorthy

Reviews

This is a useful topic but I feel like this would be better served by a blog post.

Reviewer #1 Not Sure

The proposal is short on details, but the topic is worth having at a developer-focused FOSS event. Additional information demonstrating the proposers' understanding of the FOSS licenses would have helped.

Reviewer #2 Approved