> Like....what licencing issues? After the game is "dead" and the parent company doesn't want to support it anymore, we could easily release the source code or even just the executables for the servers.
I can't speak to the parent's stance, but more generally this would be referring to IP licensing and patent encumbrance. I've worked on a number of large systems where non-trivial parts of the codebase were licensed from external parties with distribution restrictions in place. Even the executable versions would be problematic as the contracts go to great lengths to lock it down to strictly company XYZ may modify and use the IP, but nothing else regardless of the form or means of distribution.
Releasing said systems as-is would require either relicensing to allow distribution (very costly and potentially impossible if the vendor declines), or replacing that functionality with a cleanroom implementation. Which is both costly, time consuming and difficult. You may also run into further issues there if the contract forbids cloning functionality, or even worse: if there is patent encumbrance you have to go back to the relicensing option.
No problem at all. Just release your own source code. Leave out the licensed stuff. That's how id did it. If you have non-ridiculous development practices, knowing what's your IP and what is not is a basic requirement anyway.
The modder base will reimplement the licensed stuff, if needed.
What if your licensed component is non-trivial, e.g. provides critical features so that omission renders the service entirely non-functional? These laws would need to cater for that scenario, as skimming over that detail and allowing stripped releases would either mean:
1) companies get to release broken, incomplete source under the banner of commercial licensing restrictions.
2) truly upstanding companies (/s) will use this as a loophole to block the majority of their source as commercially licensed by stuffing it all under related companies and licensing it back to themselves. e.g. Company A selling game licenses majority of source (say, the entire server platform) from Company B -> Company B can't be compelled to release their engine because they aren't selling the game.
#1 would be an annoyance through to major challenge depending on the scale, #2 seems a more likely outcome for the major players as they can afford to play that sort of game and get away with it.
To be clear, I think this law should be implemented. However it would be pointless to pretend that licensing constraints won't add significant complexity, and many inventive pathways to highly evasive yet technically compliant outcomes.
I think most people are looking at existing games made under different constraints and concluding that it can't be done. But If the law passed, to me it's quite clear that it's just something that would have to be considered during development - like, we already have to get a sign-off from legal on using any open source libraries, and they usually say if it's fine for something that ships vs something that doesn't. If we knew beforehand that server binaries will eventually ship then that changes the answer from legal, and we either don't use it or try to licence it for that usecase.
Yes, this would force the nature of licensing to change. It does not apply retroactively, so the legal processes would naturally need to shift. Such licenses were used in the past, so there is no reason they cannot be considered again.
Unfortunately that's non-DAC copper cabling life it seems. They build them to work at the rated speed at the maximum rated distance (on the transceiver, not the spec) and none of them appear to link train to reduce the power output over shorter runs.
If you use a DAC they usually run cool, and optical is even cooler.
Could do with a difficulty setting that includes when you inherit someone else's log pile, someone who really enjoyed making every cut on a new and more inventive angle than the last.
Normally a wedge is used to split the wood, but it also doubles as a wedge to be wedged underneath just so you can get the log to stand up.
Also, Y sections (ycombinator mode?). 40 hits later and you might have a nice pile of woodchips, very rarely will it actually split in any clean way.
Vastly different target market and/or features there. Mercedes are chasing maximum power density, minimum weight for high performance deployments, with seemingly little concern for cost or supply chain.
Renault is going after the consumer market with these motors, where minimising cost and maximising availability is more important than pushing past 95% efficiency or cramming a 700kW power output in a motor that is small and light enough to fit inside of a wheel hub.
Looking at just the `grit` executable, 58 of the top 200 largest file->resulting code sources are from clap-rs' derive functionality i.e. it's the command-line parsing. The #1 largest is, surprisingly, merge_trees[1] which comes in at 183kiB final binary size. There isn't so much code in that file that it seems reasonable, so it's potentially one of the derives in use (Debug being a common culprit for bloat) that's blowing it out. After those outliers it starts to level out quickly.
Splitting it by crate: `grit` is 13.6MiB, `grit_lib` is 4.8MiB and then it's `std`, `rustls` and `regex_automata` that are the next largest. So as pure library you could hopefully shave off quite a bit of that 25MiB.
Nice, I haven't dug into this yet. If we can get this usable, it would be pretty cool to have a small lib or a series of much smaller, directed libs that can be used by simpler interfaces and you can just compose the parts you need.
The problem in isolation isn't new as such, but I think there's a combination of new factors to differentiate it:
1) the speed at which AI-generated codebases grow is far in excess of what human developers can achieve. What took years to accumulate in the past can be produced in a few days/weeks.
2) past large codebases that end up in a similar state would often see a mixture of developer talent. So while you might have a few developers who produce dross, there will also be a few who can pull it back together. You start to see threads of sanity appear, and from that the potential to refactor further, rather than the uniform spaghetti monster that's near unassailable from every direction that we're now getting from the pure-AI projects.
3) external perception differs. AI has been pitched, sadly by sales, influencers and shills rather than experts in the field, to business leaders as the solution to all development problems. When you present this issue to stakeholders you're then immediately put on the defensive, e.g. it's initially viewed as negativity for the sake of negativity. With past technical debt discussions, outside of a few key parties (too often the person responsible for overseeing said debt developing), I've found that it's relatively straight forward to explain technical debt, the need to refactor and maintain systems as a going concern. For the technically disinclined it's easy to draw parallels with building maintenance: you don't expect to build an office and then never spend another cent, it takes continued investment and maintenance to keep it safe, clean, functional and compliant. The difficulty again with the AI projects here I think comes back to the accelerated timeline, as you're inevitably going to be saying months after it's created that it probably needs to be burnt to the ground in lieu of the far greater task of refactoring it. As opposed to a legacy project that has been going for years or decades, where it's a far more palatable concept to take drastic action.
The AI pundits often seem to apply the logic that code output is directly proportional to revenue and/or profit, and as such it follows that an AI usage increase leads to more code which leads to more revenue.
I don't believe this aligns with the reality of any major company, unless your business is in the literal sense "selling code" your revenue and profit is tangential to the quantity of code you produce. Google is a good example of this: most of their revenue and profit comes from their ad network, which is disconnected from their development productivity and instead heavily reliant on network effects and time in market. If I was a new competitor with infinite AI funds to throw at whatever problem I choose, I can't simply capture their market by developing an exact copy of Google's ad platform. In the same way, Google can't substantially grow their ad network by coding "more" or "better", they still need more customers and consumers to interact with their network to see any increase in revenue.
So it doesn't directly follow that a productivity increase will inherently follow an AI usage increase.
Agreed. I think it’s more likely to expect that most of it is pure waste.
My impression is that most software development work is not profitable. Either the project is abandoned, or it fails, or it gets shipped but doesn’t generate positive ROI. But, like how venture capital works, the minority of projects that are successful make enough money to cover the rest.
Some portion of this is because demand for software projects in general is less than perfectly elastic. So more software does not automatically mean more software sales.
It also seems plausible that, in general, companies tend to fund the projects that are most likely to be profitable. They aren’t perfect at it, but I doubt they’re just rolling dice.
Which would imply that the new work companies can take on thanks to developer productivity gains will tend to be ones that are less likely to generate positive ROI.
meaning AI may only produce a net increase in waste, which only serves to erode profits.
Add to that that it’s been years now and we still don’t have an example of someone army-of-oneing a killer app or anything like that. It’s beginning to feel like another iteration of the amazing blockchain revolution that was always & forever just around the corner.
The unlocked economic activity won’t come from a Google competitor writing code faster. A lot of it will come from “boring” businesses who could benefit from custom software but haven’t had the means to create it themselves. In some cases they may not even know their problem can be solved by software, but some AI they are using for repetitive tasks will notice and offer to build an app for them.
Sadly that only works when all parties agree on the "clearly" part. They will lose, but only if you can endure years of squabbling in court and have unlimited funds for your legal team to prove that the aforementioned clearly really is clear. More likely they'll bleed you dry and force a settlement with an NDA bolt on.
For a company like MS, pissing a few million down the drain on making life hell for litigants turns into a sound investment: no one looks at it and thinks "I want what they're having". This is where you would ideally have a government-backed consumer rights agency step in and take up the battle.
That's an oversimplification. Asset vs liability isn't a binary state but a superposition. An asset can carry liabilities.
Your asset might generate $10k a month in revenue, but at the same time may have a high chance of needing a $100k investment in upgrades and repairs to remain productive.
It's about denial of labour leading to denial of broader competition, rather than a true intent to build a competing product.
If you were actually to follow through with building the product you would need a lot more than just engineers to roll out a successful product, effectively an entire company is needed, which would spread the company focus out and the lead to investor questions about your focus and commitment. Then if it's an unproven idea there's significant risk in going to market etc etc.
Cheaper to just lock up the talent and burn the wages. Bit of a ding to your books, big ding to your competitor's capability.
In saying that, it's a terrible practice. Massive waste of time, opportunity, talent and money.
I can't speak to the parent's stance, but more generally this would be referring to IP licensing and patent encumbrance. I've worked on a number of large systems where non-trivial parts of the codebase were licensed from external parties with distribution restrictions in place. Even the executable versions would be problematic as the contracts go to great lengths to lock it down to strictly company XYZ may modify and use the IP, but nothing else regardless of the form or means of distribution.
Releasing said systems as-is would require either relicensing to allow distribution (very costly and potentially impossible if the vendor declines), or replacing that functionality with a cleanroom implementation. Which is both costly, time consuming and difficult. You may also run into further issues there if the contract forbids cloning functionality, or even worse: if there is patent encumbrance you have to go back to the relicensing option.
reply