Why I Switched to EUPL for My Software Projects
A developer shares his journey through software licensing eras.
1The Early Days: LGPLv2
The author's first era used LGPLv2 for Midgard, a web framework, aligning with the simpler licensing landscape of the late 90s. This weak copyleft allowed flexibility while maintaining some open-source principles. The accompanying example website used the even more permissive X11 license, typical for that period's collaborative ethos.
2JavaScript Shift to MIT
By 2011, JavaScript work led to adopting the MIT license, favored by NPM's ecosystem. This ultra-permissive 'no strings attached' approach maximized interoperability but gave all rights to users. The choice reflected industry trends toward minimal restrictions during the package management boom.
3Post-Flowhub Hiatus
After closing Flowhub, software publishing paused for years due to work constraints and personal projects. This gap coincided with growing industry debates about open-source sustainability and corporate exploitation, setting the stage for a licensing philosophy change.
4EUPL-1.2 as New Standard
The 2023 shift to EUPL-1.2 marks a stark departure - this OSI-approved strong copyleft license closes SaaS loopholes by mandating reciprocity regardless of distribution method. Created by the EU, it legally binds derivative works to open terms, preventing proprietary commercialization.
5Open Source's Failed Promise
The author argues permissive licenses primarily benefited corporations, enabling cheaper R&D without reciprocation. While 'open source' won ideological debates, it failed to protect developer rights or user freedoms, instead accelerating wealth concentration in tech giants.
6Corporate Accountability
EUPL adoption represents a stance against uncompensated corporate use: companies must either comply with reciprocal terms or build alternatives. This counters decades of extractive relationships where firms profit from community work without contributing back.
7Multilingual Legal Advantage
EUPL's 23 official translations provide unique global enforceability beyond English-dominant licenses. This matters as most software development now occurs outside Silicon Valley, requiring frameworks that work across legal jurisdictions and languages.
8Practical Implementation
Current projects like the NoFlo Dev Environment rewrite use EUPL, while established tools like NoFlo remain MIT-licensed due to third-party contributions. This pragmatic approach balances principle with existing community commitments, demonstrating transitional strategies for license evolution.
Original article: Hacker News — Why I Switched to EUPL for My Software Projects