License

[RichyHBM]

Hello, I wanted to open a discussion on the licensing of this project. The readme contains a lot of mention of Borgo, so I imagine you are aware of some of the issues that project had, mainly its lacking of a license meant that forking wasn't possible and as such the project died once the main contributor stopped working on it.

I'm not proposing any particular license or another as that is probably a choice for the core developers, but even starting off as public domain and then changing it in a few months once a specific license is selected would be better than nothing

[erudenko]

Yep. You nailed it.

I literally wrote a whole manifesto about "freedom" and "community-driven development" and then forgot to add... the thing that legally enables freedom and community-driven development.

The irony is not lost on me.

The Borgo Lesson

You're right that I'm aware of what happened there. Great project. Talented developer. Community wanted to help. Couldn't fork it. Project stalled. Everyone lost.

That's exactly the future I want to avoid. The whole point of Dingo is that it belongs to the community, not to me. If I get hit by a bus (or more likely, fall off my boat), this thing should keep going.

A repo without a license is just a public diary. That's not what we're building here.

What's Happening

Adding a proper license this week. Probably MIT or Apache 2.0 — both are standard for this kind of project and play nice with Go's ecosystem.

Quick gut check though: Anyone have strong feelings? MIT vs Apache 2.0 vs something else?

Leaning MIT for simplicity, but open to hearing arguments.

Thanks for the nudge. Sometimes you're so deep in writing transpilers and manifestos that you forget the basics. This is why we have community.

[erudenko]

There are really only 3-4 options worth considering for Dingo.

The Real Contenders

MIT License

The "do whatever you want" license.

You can: Use it, modify it, sell it, sublicense it
You must: Include the license text
That's it. Two sentences.

Pros:

• Dead simple — fits in a tweet
• Everyone understands it
• Zero friction for contributors
• Maximum adoption potential

Cons:

• No patent protection whatsoever
• If a contributor later claims their code infringes their patent, you're exposed

Used by: React, Vue, Rails, Babel, jQuery

---

Apache 2.0

MIT's lawyer friend.

You can: Same as MIT — use, modify, sell, sublicense
You must: Include license, state changes, include NOTICE file
Bonus: Explicit patent grant from all contributors

Pros:

• Patent protection baked in — if someone contributes code then sues users for patent infringement, they automatically lose their license
• More legally robust for larger projects
• What a huge chunk of the Go ecosystem uses

Cons:

• Slightly more complex
• Requires a NOTICE file (minor hassle)
• Some devs find it "corporate-y"

Used by: Kubernetes, Go itself (BSD-style but similar), Docker, TensorFlow, Android

---

GPL v3

The "freedom is mandatory" license.

You can: Use, modify, distribute
You must: Release all derivative works under GPL too

Pros:

• Guarantees the project stays open forever
• No one can make a proprietary fork

Cons:

• "Viral" nature scares off corporate users
• Companies often have blanket "no GPL" policies
• Could get weird with transpiled output — is the generated Go code a "derivative work"? Lawyers would argue

Used by: Linux kernel, GCC, WordPress

---

MPL 2.0 (Mozilla Public License)

The middle ground.

Copyleft at file level, not project level

Pros:

• Changes to Dingo files must stay open
• But people can combine with proprietary code
• Rust uses this

Cons:

• More complex than MIT/Apache
• Less well understood
• Weird edge cases

---

My Own Opinion: Apache 2.0

Here's my thinking:

1. Patent protection matters as the project grows

Right now it's just me. But if Dingo takes off and I get contributors from companies, the patent grant protects everyone. Some random contributor can't later claim "actually that pattern matching implementation infringes my patent, pay up."

MIT has zero protection here.

2. Go ecosystem alignment

Kubernetes, Docker, most CNCF projects — they're Apache 2.0. Companies that already use Go tooling won't have their legal teams flagging Dingo.

3. Still maximally permissive

Anyone can still do basically anything. Build proprietary tools on top? Fine. Fork it and sell it? Fine. The only real requirement is attribution and preserving the license.

4. The manifesto talks about freedom AND community

Apache 2.0 protects the community from bad actors while still enabling freedom. MIT is freedom without protection. GPL is protection without flexibility.

---

The Counter-Argument for MIT

If we want absolute simplicity and maximum "just use it" energy, MIT wins. Babel uses MIT. TypeScript uses Apache 2.0.

The patent thing is mostly theoretical until we are big enough for someone to sue. And if we are that big, we have already won.

[RichyHBM]

My approach is generally for building blocks (language/framework) you want quite a permissive license where as for software you can be more restrictive with the likes of GPL

I feel like Apache is well known enough to be a standard and its slight complexity over mit shouldn't really matter.

I might be getting my licenses confused but I thought Apache also has a requirement to submit changes to an existing file, or at least to keep them open? But maybe I had confused it with MPL?

[erudenko]

Yep, Apache is generally used to protect you and me from large corporations.

Everything else is super permissive, allowing Dingo to be easily adopted by individuals and companies with no additional friction.