[duskwuff]

> The server binaries will almost always include other proprietary information that the studio will not want to release.

Or even information that they are contractually forbidden from releasing. A typical scenario would be a game developed as a fork of a proprietary codebase which was licensed from another company. Forcing the licensee to release material would infringe on the rights of the licensor.

[stouset]

Setting aside for a moment whether or not this specific legislation is a good implementation of the idea, I cannot understand how people don’t comprehend that this only happens because there is currently no obligation to release their server binaries or code.

The second that becomes a legal requirement with associated penalties, developers will stop licensing technology under those kinds of terms.

[cityofdelusion]

Why would developers stop licensing? They will just tear the middleware out and release as-is, leaving the community to fill the API gaps.

[Manuel_D]

Right, they'll stop licensing proprietary sever code. But that in turn drives up the cost of game development since they'd have to either purchase redistributable licenses or develop their own networking software.

I suspect companies will just scale down the servers to 1 instance with bare minimum support. Technically the online service is still active, thereby eliminating the requirements to distribute source code, even if it can only handle a handful of active players and terrible latency.

[db48x]

Why do people keep bringing up source code? It’s just as much a canard as the stupid “nonredistributable middleware” argument.

The ideal way for a game company to keep their game alive after they have stopped supporting it is to build it with that in mind from the start. A lot of the server–side components, such as monitoring, authentication, database storage, moderation, anti–cheat, etc, etc can all be made optional. It’s a small upfront cost, but set up the build system so that you can build without all of those components, or with simpler versions of them. That includes anything you cannot legally redistribute. If your last game used a middleware component that was critical to the functionality of the game but that you cannot redistribute, then you do need to find a replacement for that specific middleware component for your future games.

Then, when the end of life date of your game approaches you simply build the server binaries one last time, this time turning off all of the optional components, and let your customers download it. You don’t have to give them the source code and you don’t have to violate any license agreements in the process. Your customers can arrange for any necessary hosting of the servers themselves, most likely by simply running the server process on their own computer.

And of course the option remains to simply write a single–player game that runs entirely on the customer’s computer, with no networked components at all. It’s a little bit old–school, but lots of game developers manage to make money that way.

[Manuel_D]

Middleware isn't just things like matchmaking. Crucial components like client-side prediction, state reconciliation, and other netcode is often part of it. Stripping out all the proprietary components would leave the game in a non-functional state. This isn't just source code, the developers often have to pay license for each server instance that uses the middleware.

> And of course the option remains to simply write a single–player game that runs entirely on the customer’s computer, with no networked components at all.

So the solution is to just stop developing multiplayer games? This is just a laughable response.

[db48x]

> Stripping out all the [critical] proprietary components would leave the game in a non-functional state.

Correct. This is why I said that there would be multiple responses depending on the type of component. Many proprietary components are not critical and could easily be stripped out without harming the End–of–life version of the game, like matchmaking. But obviously that still leaves the critical ones. For those the game developer would obviously have to avoid any license agreement that would be unduly burdensome once the game was in the EOL state. Either there are already components without these onerous license terms, the existing components will be relicensed, new ones will be written and made available under less onerous licensing terms, or developers will just write their own. The market will provide.

> So the solution is to just stop developing multiplayer games?

No, not to stop developing multiplayer games but to stop putting networked components into single–player games. Remember that this all started with The Crew, which was purely a single–player game that was killed precisely because it nevertheless wouldn’t run if no server was available. If you don’t choose to make that design decision in the first place then this law has no effect on you at all. Your game is automatically safe from being killed when you stop selling it. You won’t have to do anything extra at all for players to keep playing it as long as they want to.

[FeepingCreature]

I think if you have a market where you don't license distribution for your software mostly because "hey, you can sell that for more, maybe", then changing the market so that everybody has to buy distribution should actually force the middleware price down, if anything, because they're no longer able to segment their market on it.

[bob1029]

There's also scenarios like games that depended on GameSpy being forced out into the cold. Battle for Middle Earth 2 is a good example of this. The LOTR rights expiring isn't what got them. It was another provider going away in a puff of smoke and not enough player base to justify a complete rewrite of the backend.

https://www.ea.com/news/update-on-ea-titles-hosted-on-gamesp...

[circuit10]

It would at least be reasonable to expect this for future games, just treat the server binary the same way as the client in terms of what code you include (there way be some more involved if they have to migrate off a reusable codebase but I think it’s worth it)

[maccard]

There is lots of software not specific to games out there that comes with very murky licensing when it comes to redistribution. That’s fine because it’s predominantly used for backend, but now we’re talking about distributing binaries (or source code if you’re python). Here [0] is the license for a closed source python module - what do I do if I’m using this? SQL server is widely used and not redistributable, and has lots of proprietary features as a more common one

[0] https://github.com/Azure/MachineLearningNotebooks/blob/maste...

[duskwuff]

I don't think it's reasonable for a law to dictate how software must be developed. If a developer wants to create some software by taking some licensed code and modifying it, that's their prerogative - it seems rather overreaching for the law to mandate that any licensed code must be structured as a library. (And in practice it'd be rather limiting for that to be the case.)

[Maxatar]

Almost every law that exists about software exists to dictate what a consumer is or isn't allowed to do with software on their own computer using their own hardware.

For once, there is a law that actually dictates the responsibilities that a developer has to the customer, and all that responsibility states is that the developer can not revoke the use of software that a customer has already fully paid for under certain narrow circumstances; somehow this is what you find to be unreasonable?

[duskwuff]

I think you may have misunderstood the situation I'm outlining:

1. Developer A writes some software.

2. Developer B licenses that software from Developer A, under the terms that (for instance) it only be used internally by Developer B and not disclosed.

3. Developer B makes modifications to that software and uses it as part of the implementation of a video game server.

4. Developer B goes bankrupt.

Under this proposed law, Developer B would be obligated to release the modified software, breaching their agreement with Developer A and potentially causing them financial harm.

[circuit10]

For new games, they would know from the beginning that they’ll need to release the server software eventually, so they wouldn’t be able to agree with those terms

[db48x]

If the this law or something similar had been passed before step 2, then Developer B made a mistake.

If the law passed after the game was released, then it doesn’t apply.

[circuit10]

It is of course reasonable to restrict what you can do with a product you’re selling for money. There are plenty of laws and regulations that already do this. Without these kinds of laws intellectual property wouldn’t even exist - copyright was only created to benefit society by providing an incentive for people to create and invent things

It’s no different from mandating that the software can’t be malware that puts a ransom on your data, contain other people’s copyrighted content without permission, or just not work despite you claiming that it does when you sold it

And it’s not mandating that anything is structured in a particular way, just that the game works as the buyer would expect and how they achieve that is up to them

[mschuster91]

> Or even information that they are contractually forbidden from releasing.

Laws trump contracts.