A benefit of free, open source software, or FOSS, over proprietary ones is that the former tends to profit significantly more from user feedback and involvement.
However, I believe that because of this precise aspect of FOSS, once a FOSS has been contributed to by a large enough number of people, philosophically speaking, its ownership will be “revoked” from whoever was its originator and handed to its entire user base. In other words, FOSS, in essence, is an expression of the community using it, not of any single individual. I also think everyone registers this fact in their minds when thinking about FOSS, at least on a subconscious level.
You might say that this is a non-issue for practically every FOSS you can think of right now, and you’d be correct. However, story-driven games are, well, based on a story, fiction or not, and stories, aside from folklore, are dominantly conceived of and written down by a single author. The author exercises sole authority over their work, which is a part of their identity, not anyone else’s. The majority of people can also subconsciously comprehend this fact.
Story-driven games lie at the intersection of the two senses of ownership outlined above. Someone hostilely taking over a FOSS project is set to be met with ferocious backlash, and you certainly don’t see any writers publishing their unfinished manuscripts for the entire world to read, even if they need feedback.
The question is: Should a story-based game be open-source at the potential expense of the loss of the unique manifestation of the story author’s sense of identity in their work, thereby reducing the story of its meaning?
As someone who thinks all software should ideally be FOSS I have to say yes.
I’m working on an adventure game that I plan to release under GPLv3. That doesn’t mean I will let other people contribute directly but I will of course accept feedback. I’m just going to put the source code up there with every release so that people can compile it, modify it, fork it, etc.
Someone hostilely taking over a FOSS project is set to be met with ferocious backlash
If you are creating this project and you are clear from the start that you are deciding the course of this project (or at least the story part) then I don’t think it’s a problem. If someone doesn’t like it they can just fork it. That’s the beauty of FOSS.
Another idea is to try and separate the story part from the rest. You could have an “engine” project that is meant to work with different stories where you let people contribute, and then you could have your own “story” project that uses that engine.
FOSS does not necessarily ensure that the community using it can contribute to it. In fact, usually most of the community using it doesn’t know how to modify it, and even if a user knows how to modify it, they could make fork of it but that doesn’t mean it will go to the original project. Some software such as GNU software judge contributions for ideological reasons, making GNU software representative of their anti-competitive ideology. Other software might judge contributions for their quality and usability, making them representative of what the owner considers usable. It really depends on how the software development is managed by the owner and not just by the license.
In my opinion, foss is just means of free beer. In the sites that I’m saw, the common Linux’s User never will pay anything for any software, main in Brazil and other third world’s country. here in Brazil, if you put some price over your software, the users speak things like: “He want to help people with autism but your software coast 1 dollar” (speaking about a app for kids).
For me, I just abandoned the making of FOSS, or else I must make the photosynthesis and living of absorbing pranna of the Universe.
If you don’t want it to be, then the answer is “No”.
Unless that author wants to make their story open, it does not need to be a part of the FOSS environment.
If you want to create a FOSS project and want the game/story it is built for to remain your own then release the engine as a separate entity. At that point you maintain a FOSS project, and your game is a client of that project.
You are the author. Just give clear lines of division as to what is FOSS, and what is Copyrighted.
If you wrote a book for instance: Just because you used Libre-0ffice to write your novel and compile it to PDF, it doesn’t mean that someone else now owns your book.
Even when you release a story to FOSS, most FOSS communities understand and respect that a story is the end of the ecosystem; Big Buck Bunny is everywhere, but not many people have tried to claim ownership over it.
(It would be an entirely different situation if a writer is hired by a studio to create that content for said studio. Please check with an actual lawyer if that kind of scenario is occurring.)
Edit: (I just noticed Peter87 made the same recommendation in their post)
Yes… kind of. Copyright vs Copyleft? It depends on the license you choose.
I tend to avoid GNU-GPL type licensing because I don’t like to force contributors into a strong Copyleft system. → Though now that I think of it, it is the answer for SWSHWD (original poster), It means that any contribution made by external parties becomes a part of the nebulous original game, nobody can legally claim ownership of the whole simply by being a contributor.
I love the MIT License and usually default to that just because it is so un-restrictive. (It’s basically a “Don’t sue me if it doesn’t work” clause). The only Copyleft is that the license must be included in future modifications, but it’s up to me to enforce that if I cared enough to.
ZLib License: The ZLib license is what SDL2 and 3 are released under. It’s very similar to the MIT License, I consider them interchangeable. It is broken down into key points to read a bit more clearly, and includes a clause about misrepresentation of source/origin. The use of ZLib over GNU-GPL is the determining factor that won me over as a user when I was comparing similar cross-platform gui libraries.
Public Domain AKA the “No Copyright”: There is a story of a photographer putting her picture into the public domain; a company took her photo, slapped their water-mark on it, then threatened to sue the original photographer for using “their” image. She sued them back [ Column: Photographer sues Getty Images for $1 billion after she's billed for her own photo ] → she actually did not win the case in District court, though there were settlements made later. I think it could go worse for a small studio or indie developer that can’t afford lawyer fees. As a user or as a developer; please do not use Public Domain licensing, both user and developer are opening themselves up for frivolous lawsuits.
I see above you prefer GNU-GPLv3:
Are there other licenses you or anyone else recommend?
Are there more conventional Copyright licenses out there that are still FOSS compatible?
Are there licenses you avoid?
I’m not in the mood for discussing various licenses here. My point is just that all the FOSS licenses (copyleft or not) build on the copyright laws. The author still holds the copyright even after releasing the work under a FOSS license. As far as I understand, it’s only the copyright holder that will be able to take legal actions if someone violates the license.
I’m sorry, I know you say you don’t want to discus this…but… it’s so extremely important to understand what it means to publish under GPL or just about any FOSS license.
GNU-GPL is a complete relinquishment of your Copyrights, and nearly all rights of ownership in general.
A Copyright by definition is your right as owner and creator of a work to be the sole and only person allowed to copy, modify and distribute/sell that work or grant permission to do so for your entire life. It then (in the USA) transfers to your heirs until 70 years after the creator’s death.
In the USA you have the right to sell, transfer, or relinquish your copyrights (your right to make copies).
GNU-GPL says that you, the owner, give anyone obtaining a copy of your work permission to copy, modify and distribute/sell those copies however they see fit. It forcibly tears Copyrighted-ness away from the work. You relinquish your copyrights to everyone.
Under GPL you can still sell the program at whatever price you want, but you must provide the entire source code (true copyleft) and a full copy of the GPL License upon doing so (Minus the license preamble, that’s owned by the GPL creators and [funny enough] remains copyrighted).
All you can enforce from there on is that any code that modifies or copies the work must do so under the same rules laid out by the GPL. If someone uses your code in a malicious fashion, you do not have a say in it. If they take your project and slap their name on it and sell it as a competing project, as long as they follow the legal letter of the GPL, you get no say in it. They do not get to erase you from the record/license, but they don’t need your permission any more for just about anything else.
That is the price of FOSS.
That is why it is so important that it be made clear what is distributed under FOSS and what remains Copyrighted. They should in fact be separate entities entirely if possible.
Please double-check everything I have said, I am not a lawyer nor a professional counselor in the field.
Even you choose GPL, you still have the copyright to your code, which also allows you to relicense it (as long as you’re the sole author of the code, or everyone else who has contributed to it agrees with relicensing it).
Note that the “GPL header” in code also includes one or multiple lines like Copyright (C) <year> <name of author>
that would be pointless if you didn’t have any copyright to the code anyway.
Please double-check everything I have said, I am not a lawyer nor a professional counselor in the field.
Indeed - the other things you wrote about licenses above are also wrong or incomplete at least :-p
(a major requirement of the MIT license is that binary distributions must mention the authors copyright, in their documentation or similar; the zlib license only requires the copyright notice and license text to remain in the source code, but has no requirements of attribution in binaries)
And, especially in games, the license of the source code can be different from the license of the assets/game data (levels, textures, models, even shaders and scripts, …).
See for example the old id games, like Quake: The source code is released under GPL, but the game data is still commercial, so to play Quake with a source port like Quakespasm, you still need to buy the game to get the game data.
Ouch. I’ll try to answer to this, but mostly I’m going to attribute it to you and I having different sources. Please help me if that is the case.
The version I was reading has no mention of binaries, documentation, or of attribution. There are variations of the MIT license and I’m only reading from the terms. What version/source are you quoting from?
Again, I didn’t mention the binaries, and again the terms I have access to do not mention binaries at all. I really don’t have the same source as you, please link.
I agree that you can re-license the next version of your code. But If someone owns a copy of your GPL licensed code, that’s that. It is a legally binding license. You cannot retroactively revoke that license from them.
It does seem that you can offer to “update” people into the new license in this instance (if you’ve been watching the Unity Engine situation that’s what their legal team is trying to do, I could not find my source on this, I think it was a youtube video).
You can produce code under multiple licenses, ideally the user then gets to choose based on their preference and the version they download is generally identified as being under one or the other.
And, yes, different source files can be marked by different licenses, which I feel it is rather indecent and rude to mix and match in a single project, but it is an option.
I really am pro-FOSS, I think it’s amazing what the community has achieved. I use it every day and always wish I had more skills so I could contribute in some speakable way.
The main problem I seem to run into is that once you’ve relinquished your copyrights, you can’t forcibly take them back. That’s something you should know before you start your own FOSS project.
You can change the license in your project if nobody has downloaded it yet, and hope nobody notices. That’s kind of legal by default, no harm no foul.
You can create a transformative work to regain copyright of the project. (I believe that’s why you can change the license between versions)
The thing is: you might have already given away a large amount of work, often the foundation of your project could be out there before you decide it’s time to rethink your licensing. If you decide to write FOSS, then it’s best to be ready to embrace it all the way.
I got yah, it’s basically limiting itself by being so specific… whereas had they used the words “the Software” instead of “source distribution” it would have covered more just by being more general.
Subtle but meaningful.
P.S. → those were the exact links I was reading, so it was my fault. Dang. I was hoping maybe there was some “more complete” description of the license out there that I hadn’t found yet.
Using a single license for the whole project is of course ideal. It reduces the confusion. But sometimes you might want to use code from other projects. This is fine as long as the licenses are compatible.
This means that a GPL-licensed project can use code licensed under the MIT and zlib licenses but the opposite is not possible unless they want the terms of the GPL to apply to the project as a whole.
I don’t know much about this, but my guess is that any game that has a story, whether the code of the game is open source or not, is available to anyone who has access to play the game. Therefore, I think the larger issue is how does the author of the story make sure that their work is seen as owned by them and keep others from making unauthorized changes. And even if the game is open source, the author has the original code and can still find a way to copyright the assets such as graphics, music, storyline, etc. separate from anything to do with the code.