Import old blog post

3 files changed, 273 insertions, 0 deletions

diff --git a/content/blog/_index.md b/content/blog/_index.md
new file mode 100644
index 0000000..34651ab
--- /dev/null
+++ b/content/blog/_index.md
@@ -0,0 +1,3 @@
++++
+title = "Blog"
++++
diff --git a/content/blog/free-software-games.md b/content/blog/free-software-games.md
new file mode 100644
index 0000000..2599930
--- /dev/null
+++ b/content/blog/free-software-games.md
@@ -0,0 +1,260 @@
++++
+author = "Drew DeVault"
+title = "The complete guide to publishing free software video games"
+date = "2021-03-23"
+description = "A comprehensive guide to publishing your video game as free software"
+tags = ["games", "publishers"]
+image = "supertuxkart.jpg"
++++
+
+*This article was adapted and republished from [Drew DeVault's blog](https://drewdevault.com/2021/03/23/Open-sourcing-video-games.html).*
+
+Video games are an interesting class of software. Unlike most software, they are
+a creative endeavour, rather than a practical utility. Where most software
+calls for new features to address practical needs of their users, video games
+call for new features to serve the creative vision of their makers. Similarly,
+matters like refactoring and paying down tech debt are often heavily
+de-prioritized in favor of shipping something ASAP. Many of the collaborative
+benefits of free software are less applicable to video games. It is perhaps for
+these reasons that there are very few commercial free software games.
+
+However, there are some examples of such games, and they have had a great deal
+of influence on gaming.  Id is famous for this, having released the source code
+for several versions of DOOM. The Quake engine was also released under the GPL,
+and went on to be highly influential, serving as the basis for dozens of games,
+including time-honored favorites such as the Half Life series. Large swaths of
+the gaming canon were made possible thanks to the generous contributions of free
+software game publishers.
+
+Publishing free software games is also a matter of historical preservation.
+Proprietary games tend to atrophy. Long after their heyday, with suitable
+platforms scarce and physical copies difficult to obtain, many games die a slow
+and quiet death, forgotten to the annals of time. Some games have overcome this
+by releasing their source code, making it easier for fans to port the game to
+new platforms and keep it alive.
+
+What will your game's legacy be? Will it be forgotten entirely, unable to run on
+contemporary platforms? Will it be source-available, occasionally useful to the
+devoted player, but with little reach beyond? Perhaps it goes the way of DOOM,
+living forever in ports to hundreds of devices and operating systems. Maybe it
+goes the way of Quake, its soul forever a part of the beloved classics of the
+future. If you keep the source code closed, the only conclusion is the first:
+enjoyed once, now forgotten.
+
+With this in mind, how do you go about securing your game's legacy?
+
+## Source available: the bare minimum
+
+The bare minimum is to make your game "source available". Be aware that this is
+not the same thing as making it free or open source software! Some of your
+famous peers in this category include Alien 3, Civilization IV and V, Crysis,
+Deus Ex, Prince of Persia, Unreal Tournament, and VVVVVV.
+
+This approach makes your source code available to view and perhaps to compile
+and run, but prohibits derivative works. This is definitely better than leaving
+it closed source: it provides helpful resources for modders, speedrunners, and
+other fans; and devoted players may be able to use it as the basis for getting
+the game running on future platforms, albeit alone and unable to share their
+work.
+
+If you choose a minimal enforcement approach, then some players might ultimately
+share their work, but you're leaving them on tenuous legal grounds. I would
+recommend this if you're very protective of your IP, but know that you're
+limiting the potential second life of your game if you take this approach.
+
+## Copyleft with proprietary assets
+
+The next step up is to make your game free software using a *copyleft* license,
+but refraining from extending the license to the assets — anyone who wants
+to get the source code working would either need to buy the game from you and
+extract the assets, or supply their own community-made assets. This is a popular
+approach among free software games, and gives you most of the benefits and few
+of the drawbacks. You'll join the ranks of our DOOM and Quake examples, as well
+as Amnesia: the Dark Descent, System Shock, Duke Nukem 3D, and Wolfenstein 3D.
+
+Games like this enjoy a long life as their software is more easily ported to new
+platforms and shared with other users. DOOM runs on phones, digital cameras,
+ATMs, even toasters! Its legacy is secure without any ongoing commitment from
+the original developers. This also allows derivatives works — new games
+based on your code — though it may turn some developers away. Using a
+copyleft license like the [GPL](https://www.gnu.org/licenses/gpl-3.0.en.html)
+requires derivative works to *also* be made free software. The community generally
+has no problem with this, but it may affect the willingness of future developers
+to incorporate your work into their own commercial games. I personally think
+that the proliferation of free software that's implied in the use of a
+copyleft license is a positive thing — but you may want to use another
+approach.
+
+## Permissive license, proprietary assets
+
+If you want to allow your source code to find its way into as many future games
+as possible, a permissive free software license like [MIT][0] is the way to go.
+[Flotilla](https://github.com/blendogames/flotilla) is an example of a game
+which went with this approach. It allows developers to incorporate your source
+code into their own games with little restriction, either by creating a direct
+derivative, or by taking little samples of your code and incorporating it into
+their own project. This comes with no obligation to release their own changes or
+works in a similar fashion: they can just take it, with very few strings
+attached. Such an approach makes it very easy to incorporate into new commercial
+games.
+
+[0]: https://opensource.org/licenses/MIT
+
+This is the most selfless way to release your code. I would recommend this if
+you don't care about what happens to your code later, and you just want to make
+it free software and move on. Though this will definitely enable the largest
+number of future projects to make use of your work, the copyleft approach is
+better for ensuring that the largest possible number of future games are *also*
+free software.
+
+## Open assets
+
+If you're feeling especially generous, you could release the assets, too. Good
+licenses for this includes the [Creative Commons](https://creativecommons.org/)
+licenses. All of them permit free redistribution of your assets, so future
+players won't have to buy your game to get them. This could be important if the
+distribution platform you used is defunct, or if you're not around to buy it
+from — consider this well before deciding that you'd rather keep your
+share of the dwindling asset sales as your game ages.
+
+Using Creative Commons also allows you to tune the degree to which your assets
+may be re-used. You can choose different CC licenses to control the
+commercialization of your assets and use in derivative works. To allow free
+redistribution and nothing else, the CC-NC-ND license (noncommercial, no
+derivatives) will do the trick. The CC-BY-SA license is the copyleft of creative
+commons: it will allow free redistribution, commercialization, and derivative
+works, *if* the derivatives are also shared with the same rights. The permissive
+approach is CC-0, which is equivalent to releasing your assets into the public
+domain.
+
+Permitting derivatives and re-commercialization of your assets can save a lot of
+time for new game developers, especially indie devs with a small budget. It's
+also cool for making derivative *games*, similar to modding, where creative
+players can remix your assets to make a new game or expansion pack.
+
+## What if I don't completely own my game?
+
+You can't give away the rights to anything you don't own. If you rely on
+proprietary libraries, or a third-party level editor, or you don't own the
+rights to the music or sprites, you cannot make them free or open source.
+
+In this situation, I recommend publishing everything that you're able to as
+free software. This might mean that you publish an ultimately broken game
+— it simply might not work, or not even compile, without these resources.
+This is unfortunate, but by releasing everything you can, you leave your
+community in a good position to fill in the gaps themselves, perhaps by
+refactoring your code to work around them, or by replacing the proprietary bits
+with free alternatives. This also allows the parts of your game which are open
+to be reused in future games.
+
+## But cheaters could use it!
+
+This is true. And it's worth noting that if your game has a mandatory online
+component based on your own servers, then making it free software doesn't make
+nearly as much sense, especially if you ultimately decide to shut those servers
+off.
+
+There is a trade-off to be made here. In truth, it's very difficult to prevent
+cheating in your game. If you've made a popular competitive multiplayer game,
+you and I both know that there are still cheaters using it despite your best
+efforts. Keeping it proprietary is not going to stave off cheaters. Social
+solutions are better — like a system to report cheaters, or to let friends
+play on private servers.
+
+Making your game free software might help less skilled script kiddie figure out
+how to cheat more easily in your game. I can't decide for you if the trade-off
+is worth it for your game, but I can tell you that the benefits of making it
+open are vast, and the efficacy of keeping it closed to prevent cheating is
+questionable.
+
+## But my code is embarrassing!
+
+So is everyone else's. 🙂 We all know that games are running up against tight
+deadlines and clean code is not going to be the #1 priority. I assure you that
+your community will be too busy having fun to judge you for the quality of your
+code. The idea that it just needs to be "cleaned up" first is the death of many
+projects which would otherwise have been made free software. If you feel this
+way, you will probably never be satisfied, and thus you'll never open it. I
+assure you: your game is ready to make free software, no matter what state it's
+in!
+
+Bonus: Ethan Lee tipped me off to some truly awful code which was left in
+VVVVVV, which you can freely browse on the [2.2 tag][vvvvvv 2.2]. It's not
+great, but you probably didn't know that — you only remember VVVVVV as a
+critically acclaimed game. Game developers are working under tight constraints
+and no one is judging them for that — we just want to have fun!
+
+[vvvvvv 2.2]: https://github.com/TerryCavanagh/vvvvvv/tree/2.2
+
+## So what do I need to do?
+
+Let's lay out the specific steps. You need to answer the following questions
+first:
+
+- Do I actually own the entire game? What parts am I allowed to publish as free
+  software?
+- Will I make the code source-available, copyleft, or permissively licensed?
+- And the assets? Proprietary? Creative Commons? If the latter, which version?
+
+If you're not sure what's best, I would recommend using the GPL for your code,
+and CC-BY-SA for the assets. This allows for derivative works, so long as
+they're also made open with a similar license. This enables the community to
+build on your work, porting it to new platforms, building a thriving modding
+community, and freely sharing your assets, ensuring an enduring legacy for your
+game. If you'd like to decide the details for yourself, review the comments
+above once again and pick out the licenses you'd like to use for each before
+moving on.
+
+If you need help with any of these steps, or have any questions, please [send me
+an email](mailto:sir@cmpwn.com), and I will help you to the best of my ability.
+
+**Publishing the source code**
+
+Prepare an archive of your source code, and add the license file. If you went
+with the source-available approach, simply write "Copyright ©
+<*you*> <*current year*>. All rights reserved." into a text file
+named LICENSE. If you chose something else, copy the license text into a
+LICENSE file.
+
+If you want this over with quickly, just stick the code and license into a zip
+file or a tarball and drop it on your website. A better approach, if you have
+the patience, would be to publish it as a git repository. If you already use
+version control, you may want to consider carefully if you want to publish your
+full version control history — the answer might be "yes", but if you're
+unsure, the answer is probably "no". Just make a copy of the code, delete the
+.git directory, and import it into a new repository if you need to.
+
+Double check that you aren't checking in any artifacts — assets,
+executables, libraries, etc — and then push it to the hosting service of
+your choice. GitHub is a popular choice, but I would selfishly recommend
+[sourcehut](https://sourcehut.org) as well. If you have time, write a little
+README file which gives an introduction to the project as well.
+
+**Publishing the assets**
+
+If you choose to leave the assets proprietary, then there are no further steps.
+Players can figure out how to extract the assets from their purchased game.
+
+If you choose to make them open, prepare an archive of your assets. Include a
+copy of the license you choose — e.g. which Creative Commons license you
+used — and drop it into a zip file or a tarball or something similar.
+Stick this on your website, and if you're feeling generous, prepare some
+instructions for how to incorporate the asset bundle into the game once a player
+compiles your code.
+
+**Tell the world!**
+
+Let everyone know that you've made your game free software! Write a little blog
+post, link to the source and assets, and enjoy a little bit more of the
+limelight while the press and the community thanks you for your contribution.
+
+One final request on this note: if you choose the source-available approach,
+please refer to it as such in your public statements. Source available is *not*
+the same thing as "free software" or "open source", and the distinction is
+important.
+
+And now it's my turn to thank you: I'm so happy that you've released your game
+as free software! The community is much richer for your contribution to it, and
+I hope that your game will live on for many years to come, both in self through
+ports and mods, and in spirit through its contributions to future games. You've
+done a wonderful thing. Thank you!
diff --git a/content/blog/introducing-writefreesoftware.org.md b/content/blog/introducing-writefreesoftware.org.md
new file mode 100644
index 0000000..38de990
--- /dev/null
+++ b/content/blog/introducing-writefreesoftware.org.md
@@ -0,0 +1,10 @@
++++
+author = "Drew DeVault"
+title = "Introducing WriteFreeSoftware.org"
+date = "2023-05-17"
+description = "A new website for disseminating free software philosophy and practice"
+tags = ["meta"]
+image = "banner.jpg"
++++
+
+TODO: write me