Three things I worked out before open-sourcing my game

Previous postcovered how Knight's Waltz got built in two days. The day after launch, I put the entire source code on GitHub:github.com/saomin0317/knight-duel。

I assumed "should I open-source this?" was a five-minute decision. It turned out to have three layers. This post is that thought process on file — useful, maybe, if you've also got a finished side project sitting on a hard drive waiting for a verdict.

As usual, a note on method: this is still an AI collaboration experiment. Claude handled the asset license audit, the GitHub setup, and the legal clause comparison; whether to go public and which license to attach were my calls.

Thing one: what does going public actually buy you?

The honest answer first:Less than you'd think.

GitHub has no "now available" notification. The second a repo flips from private to public, nobody on Earth finds out. No push alerts, no algorithm, no new-releases chart. Public means "can be seen," not "is seen."

So what do you get? For a one-person company, one thing:Proof of capability。

"I can build 3D games for the web" is a sentence. "Here's a playable game, here's all the source, see for yourself" is something else. On a sales call, the second one needs no explanation. A playable build plus visible source is the lowest-effort résumé there is.

The flip side: if your project has no reason to be seen — an internal tool, a product still racing for first-mover advantage — going public is all risk and no return. Don't force it.

Thing two: can you actually guard against what worries you?

One thing drove my hesitation:reskins. The game is complete and playable; publishing the source means anyone can swap the name and the art and sell it.

Working through it, there are three lines of defense — and none of them rely on suing anybody.

Line one: audit your asset licenses first. This one isn't about stopping other people, it's about stopping yourself. If the 3D models and sound effects in your game were purchased or licensed, putting them in a public repo counts as redistribution, which most asset terms explicitly prohibit — the first infringement would be yours. We went through everything: all models are KayKit CC0 (free for commercial use, no attribution required), sound effects are Kenney CC0, and the soundtrack, The Blue Danube, is public domain from 1867, with a recording by the United States Marine Band — works of the US federal government carry no copyright by law. All clear. This project deliberately used only CC0 and public-domain assets from day one, and that's paying off now.

Line two: the license. More on that below.

Line three: the name and the servers don't travel with the source. This is the lock I find most practical. The license notice states plainly that the name "Knight's Waltz" and the online services (accounts, cloud saves, leaderboards) arenot covered by the license. Meaning: even if someone legally forks the code, they can't use the name and they can't reach my servers. What they get is a shell with no name, no saves, no leaderboard, and they have to grow all of it themselves. What a copycat wants most is the finished whole — this lock takes the whole apart.

Thing three: four licenses, in plain language

One property of licensing you need to understand up front:you can't unring the bell. Once a repo is public, any copy someone forks is permanently governed by the terms in force at that moment. Changing your mind later doesn't reel it back. So the first license you attach is worth thinking through.

Four options, tightest to loosest:

No license at all. The legal default is "all rights reserved" — visible, but copying and modifying are both illegal. It sounds like the safest option, but the deterrent is limited in practice (people who'd copy it don't care, and you're not going to litigate across an ocean), and it dulls the showcase value: source code you can't legally even run reads to the community as "look, don't touch."

A non-commercial license (e.g. PolyForm NC). "Read it, learn from it, don't make money off it." The intent is stated as clearly as it gets, but it isn't formally open source, and parts of the developer community won't accept it.

GPL-3.0。 "Use it, sell it even — but your derivative worksmust be published under the same terms, source included." Its anti-reskin power comes from a psychological mechanism: what a copycat fears most is being forced to open up their own work — either they open-source their derivative by the rules, or they infringe, and most simply walk away. Meanwhile you keep your standing as a genuine open-source project.

MIT。 "Do whatever you want, just keep the copyright notice." Reskinning is entirely legal. Good for a utility library chasing adoption; wrong for a complete game you'd mind seeing copied.

I went with GPL-3.0. The reason: it delivers two things at once — the showcase value of real open source, and the structural deterrent of "copy it and you have to open up too." Combined with the third lock (name and servers withheld), the cost of a reskin gets pushed past the cost of just building your own.

One easy-to-miss piece of housekeeping:update your terms of service to match. The site originally said the code "may not be reproduced without written consent," which flatly contradicts GPL — so alongside going public, that became "code released under GPL-3.0 is exempt; rights to the name and services are reserved." Licensing isn't done when you drop in a LICENSE file; every public-facing document has to say the same thing.

So — should you open-source your side project?

My decision process boils down to three questions:

1. Does it need to be seen? If not, keep it. Going public pays nothing.
2. Are the assets clean? If even one license is unclear, hold off — this is the one step where you're the one who ends up infringing.
3. What are you afraid of? Afraid of copycats → GPL plus withheld name and servers. Not afraid → MIT. Just want a showcase → a non-commercial license works fine.

Knight's Waltz lives here:game、source. Have a look, have a game, and if you build on it, open it up.

FAQ: publishing source code and licensing

What kinds of open-source licenses are there, and how do you choose?

Public licenses fall into four broad groups: no license (all rights reserved — others can look but not use), non-commercial licenses like PolyForm NC (look and learn, no commercial use), copyleft licenses like GPL-3.0 (commercial use allowed, but derivatives must be open-sourced under the same terms), and permissive licenses like MIT / Apache-2.0 (use it however, just keep the copyright notice). Choose by purpose: GPL if you're worried about being copied, MIT if you want adoption, non-commercial if you only want to showcase capability, and nothing at all if it's purely a backup.

What's the difference between GPL and MIT?

In one line: MIT gives with no strings attached, GPL gives on the condition that derivatives are also open-sourced. Building a closed-source commercial product on MIT code is entirely legal; build a product on GPL code and that product's source must be released under GPL. That's what gives GPL its structural deterrent against reskin-style copying — the copycat either publishes their derivative or infringes.

Without a LICENSE file, can others use publicly posted code?

No. Copyright law defaults to "all rights reserved," so public code with no license terms may only be read — copying, modifying, and redistributing all constitute infringement. In practice, though, the deterrent is limited, and the community generally won't use or contribute to an unlicensed project.

Can CC0 assets be used commercially? Is attribution required?

Yes to commercial use, no attribution required. CC0 is equivalent to waiving copyright into the public domain — free commercial use, modification, and redistribution are all legal. KayKit (3D models) and Kenney (sound effects) are CC0 sources widely used in game development. Note that some creators attach a "please don't resell as-is" gentleman's agreement — not legally binding, but worth respecting.

Can you change your mind and switch licenses after open-sourcing?

You can change it, but you can't take it back. New versions can carry new terms, but any copy obtained while the old license was in force is permanently governed by those terms — code that's already been forked is beyond your reach. Which is why the first license choice deserves real thought.

Do the game's name and trademark get open-sourced along with the source?

No — provided you spell it out. A code license (GPL, MIT, and so on) covers only the code itself; the name, trademarks, and online services (account systems, servers, leaderboards) can be explicitly reserved in the license notice. This is the practical way open-source games guard against reskins: forkers can take the code, but not the name or the servers.

Further reading: - 3D isn't as hard as it looks: two days to put a 40-year-old game memory online - The real distance of automated lead-hunting: four days, 638 posts, one reply seen by three people