The time bomb in the tax code that's fueling mass tech layoffs
qz.com1575 points by booleanbetrayal 10 months ago
1575 points by booleanbetrayal 10 months ago
There are some misunderstandings in the comments that seem to stem from not having read the section, so I thought it was worth referencing the actual text [0]. It's quite short and easy to read.
The most important bits:
* Subsection (a) requires amortizing "Specified research or experimental expenditures" over 5 years (paragraph (2)) instead of deducting them (paragraph (1))
* Paragraph (c)(3) is a Special Rule that requires that all software development expenses be counted as a "research or experimental expenditure".
That's it. All software expenses must be treated as research and experimental expenses, and no research and experimental expense can be deducted instead of amortized. Ergo, all software expenses must be amortized over 5 years.
I strongly recommend reading the section before forming an opinion. It really is quite unambiguous and is unambiguously bad for anyone who builds software and especially for companies that aren't yet thoroughly established in their space (i.e. startups).
Also note that this makes Software a special case of R&D. It's the only form of R&D that Section 174 requires you to categorize as such and therefore amortize.
It's pretty bad.
It had a huge impact on my personally, I'm a small R&D shop and basically I have had to end all risky long-term research projects.
In addition to the research costs, I'd also have to pay taxes on the research costs mostly up-front. Significantly, if the project doesn't work out, I'm still out of pocket for the tax money. It's a penalty for taking a risk, and it kneecaps American innovators in a globally competitive technology race.
The rules are even worse than the article notes because it double-dings open source developers. See Section 6.4 of https://www.irs.gov/pub/irs-drop/n-23-63.pdf. The relevant bit is here:
> "However, even if the research provider does not bear financial risk under the terms of the contract with the research recipient, if the research provider has a right to use any resulting SRE product ... costs paid or incurred by the research provider that are incident to the SRE activities performed by the research provider under the contract are SRE expenditures of the research provider for which no deduction is allowed ..."
The rule as written means contractors who write Windows drivers could deduct their expenses (as they would have no residual rights to a closed-source work product), but contractors who write Linux drivers may not (as they would have some rights to open-source Linux drivers).
> In addition to the research costs, I'd also have to pay taxes on the research costs mostly up-front. Significantly, if the project doesn't work out, I'm still out of pocket for the tax money.
That’s how it works for every business! If Jim Bean builds a distillation facility it has to amortize the investment in that over time. If the distillation facility doesn’t pan out, then it doesn’t get a refund for the taxes paid.
In my (admittedly lay) understanding of the issue, it boils down to software maintenance being taxed as research and development.
In general, costs for running a business (buying inventory) are immediately deductible, while establishing new business (building factories) has to be amortized, since the factory can be used for several years.
In software, the line is a bit more blurry - coding creates new IP (research), but is also required to keep many software companies running (maintenance) by e.g. fixing bugs and updating infrastructure. Here, the IRS has decided that all software development counts as research.
This would kinda make sense if you could hire programmers for a single year to develop software, fire them and then sell the software for 5 years, but I think that's rarely the case.
The comparison with Jim Beam is misplaced. Both TSMC and Jim Beam already have to amortize their production equipment over several years. I'm not arguing that this should be changed. This is because the primary risk taken in a distillery build-out or a fab build-out is if there is market demand for a known product. It's primarily a business risk, not a research risk. Tax code is a reasonable tool to regulate business risk.
The people this tax code change hurts are those doing basic research. In the context of semiconductors, that would be a company like ASML (except they are Dutch, so they can happily continue their research practices) who took a decades-long bet to build their EUV steppers.
In the case of basic research, one could be spending millions of dollars on hardware prototypes when you know it can't produce any salable product. There's no upside profit to amortize expenses against: it's like building a distillery that you know can't produce a single drop of salable bourbon because you're working out a radical new distillation technique.
In summary: in basic hardware research, one could be spending millions of dollars to put a whole system together just so you can learn how it fails. It's a true "expense", with no path to amortization.
Now, in addition to making the right technical decisions, the tax law changes force the R&D teams to also consider how to amortize their experiments over many years. You now have have pressure from management to do things like stage prototypes and expenses in the right tax year so the company can continue to show a profit for the shareholders. You could argue that the lessons learned are perhaps IP that have "goodwill" value, but now you're opening a can of worms trying to price a fair market value on a negative result, and you're now having senior research staff spend more time arguing with accountants than directing research. You also have to get to that negative result within a tax year - which effectively penalizes any research project that takes more than 12 months to complete.
Same-year 100% deduction of R&D expenses is simple and it reflects the actual nature of basic research risk. Yes, it allows companies to convert short-term windfalls into long-term research gains by converting taxable profits into research projects, but I'd argue that's not actually a bad social policy.
I think US is probably unique among developed nations in having a tax code that punishes basic research; other countries at least allow it to be deducted. Some even allow super-deductions (e.g. you can deduct $2 for every $1 of R&D expense) or the research is explicitly subsidized through grants.
The argument for special treatment of research is that pioneers put their careers on the line to discover new things, so the rest of us can live in risk-free comfort; so, as a collective we give them some reward for taking that risk.
I suppose the counter-argument is that research incentives and subsidies are socialist "market manipulation" and violate the "free market" principle, and thus America is justified in sanctioning and trade warring with the rest of the world that is socializing basic research costs. That's an opinion one is entitled to hold, but we'll have to agree to disagree on that opinion.
> Both TSMC and Jim Beam already have to amortize their production equipment over several years. I'm not arguing that this should be changed. This is because the primary risk taken in a distillery build-out or a fab build-out is if there is market demand for a known product. It's primarily a *business* risk, not a *research* risk.
Norway did something similar with oil[1]. Companies could get most of their oil search expenses covered by the state, to encourage finding new oil fields.
But if a company starts extracting oil from a field they have to pay heavy taxes on that oil.
[1]: https://www.offshorenorge.no/om-oss/nyheter/2019/01/leterefu...
This is different because the value of the distillation facility is not defined as “the wages of the builders”.
It doesn’t matter. Jim Bean doesn’t compete with an R&D software company. The R&D software company does compete with other companies in different jurisdictions with better regulations.
Jim Bean competes with other beverage makers who also operate out of different jurisdictions that may have different regulations ... not sure your point is as much of a "gotcha" as you think it is.
TIL that Hacker News readers think the Jim Beam whiskey company is called Jim Bean.
> The rule as written means contractors who write Windows drivers could deduct their expenses (as they would have no residual rights to a closed-source work product), but contractors who write Linux drivers may not (as they would have some rights to open-source Linux drivers).
Is it just me or are you conflating two orthogonal things?
An open-source Windows driver would have the same issue, no? And a closed-source proprietary Linux driver privately written for some company wouldn't have this issue either, right?
I could see it being inferred that way but, the way I read it, they are not meant as unilateral facts. Rather, they serve as rhetorical examples of where you might find contractors doing similar work, but where the one more in service of "public good" is taxed higher because it's open source. Strictly speaking, Windows bits are not all closed source and there exist closed source Linux bits. But it's not a point that really matters in the context of the conversation.
I think it's fair to use Windows and Linux as stand-ins for closed vs open source because it's a very accessible example. And knowing the technicalities clearly doesn't undermine the argument.
> I think it's fair to use Windows and Linux as stand-ins for closed vs open source because it's a very accessible example
We're talking about businesses here that would struggle with these tax rules. Which I guess is, mainly, contractors or startups. How common is it for them to write open-source drivers vs. closed-source ones? I would've imagined the majority of drivers in such cases are closed-source, on every platform. But I would find it interesting to hear if things are somehow different on Linux.
Linux kernel drivers often end up being GPL'd, but out of tree. This is because Linux releases many very useful (and sometimes critical to the use-case!) functions behind a GPL-license API restriction. This is EXPORT_SYMBOL_GPL.
Are you sure this is exactly what it means? You're basically saying that if I start hacking on a driver that consumes such an API tonight, I must release it as GPL somewhere publicly the moment I start consuming the API? I can't even work on it for a bit privately?
I'm surprised if so, because usually these sorts of licenses only apply if you're redistributing the code, not if you're just using it privately.
You're right, the law text doesn't specifically call out the Windows operating system or the Linux operating system. The example you gave of Open Source Windows drivers is valid.
The Grandparent's point about that "it double-dings open source developers" is still correct and poignant even with this clarification.
> The Grandparent's point about that "it double-dings open source developers" is still correct and poignant even with this clarification.
I feel like I'm missing what subset of people this is, exactly. We're talking about businesses here that would struggle with these tax rules. Which I guess is, mainly, contractors or startups. How common is it for such businesses to release their software as open-source, vs. as closed-source? I would've (naively) expected most paid OSS developers to be funded by large organizations/businesses that have plenty of money to fund them, not small businesses/contractors that would be severely impacted by this law. Is this actually a large set of people?
There are lots of small OSS businesses that are contractors to the big companies you mention. My go-to example is Igalia, who work on web browser and other core OSS tech, but there lots of others, some mentioned on the FOSSjobs wiki.
https://www.igalia.com/ https://github.com/fossjobs/fossjobs/wiki/resources
You are correct. I picked this example under the general assumption that the Windows driver would be closed-source, but you are correct that it doesn't necessarily have to be closed source.
The problem goes with the license, not with the OS.
Just pledge copyright of contributions to eff or something.
Work-for-hire open source contributions often already bear a copyright holder of the entity paying for the work. The problem isn't who is the copyright holder.
The problem is that the license assigned says that anyone is free to use the code. Anyone is a set of people that includes the contributor, which then triggers the interpretation that the research is incrementally in the contributor's benefit and thus disqualified from preferential tax treatment.
You'd need a custom license where everyone in the world could use the results except for the contributor, and then like, a source control system that hides the source files from the contributor's view of the repository.
> Anyone is a set of people that includes the contributor
Should every other member of that set, i.e. everyone minus contributor, also amortize their software development expenses because they have a hypothetical, non-exercised right to use some (i.e. all) open-source "R&D" software... somewhere? Or should the tax liability be invoked starting on the date of first use of any open-source code?
If some code is upstreamed to Linux kernel or userspace, should this obligate every Linux distro consumer to amortize their Linux software development expenses?
There must be _some_ legal boundary for dispersal of the tax obligation with respect to open-source code, since it self-evidently cannot be intended to apply to the entire universe of businesses and union of all OSS development. If necessary, a court case can establish this distinction.
> a source control system that hides the source files from the contributor's view of the repository.
How would that work?
> You'd need a custom license where everyone in the world could use the results except for the contributor
That one is incompatible with copyright laws in many countries outside USA.
The point is that it's a ridiculous and impractical workaround that makes no sense
> That one is incompatible with copyright laws in many countries outside USA.
How so? You can't sign away your interest in a copywrighted work?
The USA hasn’t managed to completely impose their idea of intellectual property on everyone yet. Some countries you can’t sign away authorship even if you can commercial rights.
I am unsure if I fully understand your point, so let me ask a related question to see if I understand.
For many open source projects, there is a CLA (contributor license agreement) that must be signed before contributions can be accepted. The Free Software Foundation (which holds the copyright for most/all? GNU tools) is pretty in/famous for requiring it. Their reasoning: If there are copyright violations, they have the time and financial resources to pursue the violators.
Are you saying that these CLAs and their intended purpose are invalid in some jurisdictions? If yes, please share some examples. To be clear: I'm only interested in "normal/regular" jurisdictions that have at least accepted the Berne Convention.
Parent objected to:
> You'd need a custom license where everyone in the world could use the results except for the contributor
> That one is incompatible with copyright laws in many countries outside USA.
Does authorship confer usage rights?
In fact, many countries don't let you sign away your statutory rights in general.
Create a shell company with an X$ investment.
Have the shell company write code. (Or more risky pay your company to write code as a work for higher.)
Devolve the shell contributing its assets to OSS.
Take a X$ loss in that year.
Argue that it is perfectly legal to the IRS.
I wonder of you could also just pay bounties for specific features to be written for OSS.
Or have your shell company operating out of any other country.
You’re likely overreacting.
It makes software temporarily 16.7% more expensive in year one if you’re operating a profitable company, but you do eventually get to deduct that over time. Pay 8% on a 4 year loan and that drops to ~4%.
Eventually, as long as you survive that long.
As has been said repeatedly in this thread, this change is purely a boon for existing big tech companies that now have even less to worry about from startups. It takes a startup 5 years before they'll be playing on an even field with big tech.
> if you’re operating a profitable company
You keep saying this across this thread, and keep ignoring that Section 174 has now redefined "profitable" for tax purposes to include companies who:
* Are in year 1 with no history of expenses to draw on.
* Have spent <900% of their year 1 revenue on software development expenses.
i.e., a startup that earns $1mil and spent $8mil in software dev expenses is only able to deduct 10% * 8mil = $800k of expenses, which means that as far as the government is concerned they made a profit of $200k and owe taxes on that on top of their already-net-loss of $7mil.
You can keep ignoring this fact, but ignoring it doesn't help your case. If you want to argue that this is fine and dandy you need to explain why the above math doesn't prevent new companies from competing on fair terms with big tech.
> As has been said repeatedly in this thread, this change is purely a boon for existing big tech companies that now have even less to worry about from startups. It takes a startup 5 years before they'll be playing on an even field with big tech.
The article also blames it for 2022 mass layups at existing big tech companies with cash reserves.
That seems like a big stretch compared to the "oops we over-hired in 2021" theory, especially if it's net-advantageous for big tech vs up and comers.
> The article also blames it for 2022 mass layups at existing big tech companies with cash reserves.
It's possible for two things to be true at once. The new rules can be moderately bad for big companies and cause them to do layoffs and also cause them to be catastrophically bad for startups, giving incumbent big tech companies another relative advantage over them.
This is also ignoring the short-term vs. long-term effects. In the first year the incumbent companies are in the same boat as the new ones because they already deducted all their R&D expenses from the previous year when they were still allowed to, so they get a minimal deduction this year and have no advantage. But five years from now, they'll have five years worth of R&D they're still amortizing -- notably, this means the government is no longer getting more revenue from them in the current year than they would otherwise, since their average R&D expense and their average amortized deduction are now equal -- whereas the startup has no historical R&D to deduct and is put at a disadvantage.
Article theory is bullshit, but it can still be some factor for startups, as research costs for them are effectively higher they probably just hire less.
> You keep saying this across this thread, and keep ignoring that Section 174 has now redefined "profitable" for tax purposes to include companies who:
Because generating an asset IE software isn’t a pure loss that’s why you’re doing it in the first place. Companies with a cash flow problem are different than companies which an actual loss.
> i.e., a startup that earns $1mil and spent $8mil in software dev expenses is only able to deduct 10% * 8mil = $800k of expenses, which means that as far as the government is concerned they made a profit of $200k and owe taxes on that on top of their already-net-loss of $7mil.
That assumes 100% of expenses are software development related. But the numbers are imaginary so using your example taxes are 21% of 200k, so 7 million in losses = 7.042 million in losses. A 1/2 of 1% increase, the sky is fucking falling.
Further a competent account would likely want you to carry the majority of those expenses to the future. Given the option many companies voluntarily did so because it made financial sense. You can only carry 80% of losses forward a likely future issue, but these expenses don’t fall under that category.
> That assumes 100% of expenses are software development related. But the numbers are imaginary so using your example taxes are 21% of 200k, so 7 million in losses = 7.042 million in losses. A 1/2 of 1% increase, the sky is fucking falling.
The problem here is that the losses are often in time or future liabilities but the government expects to be paid in cash. Your developers were mostly working for stock options or some other deferred compensation, which may cost you tomorrow but tomorrow you'll have more revenue. Where are you getting the cash to pay the government right now?
> Because generating an asset IE software isn’t a pure loss that’s why you’re doing it in the first place.
Tell me you're not an experienced software engineer without telling me you're not an experienced software engineer.
Code is a liability, not an asset.
> Code is a liability, not an asset.
So you have no idea what that phrase means. If you don’t think code is an asset don’t write it.
O wait obviously that’s not what code is a liability means. Code is a liability in the same way roads or buildings are a liability, they incur an ongoing cost, but removing the US highway system would be just as idiotic as a startup deleting their source repository from a misunderstood idea.
More importantly valueless code stops being a liability because you can abandon it. Calling it a liability implies it has value.
> More importantly valueless code stops being a liability because you can abandon it. Calling it a liability implies it has value.
This is kind of missing the issue though.
Suppose you pay a million dollars this year to develop something that will also cost a million dollars a year to maintain, but is worth over a million dollars a year, so you do it anyway.
So this year you spend a million dollars, make $1.1M, have a profit of $100k. Next year you'll spend a million dollars, make $1.1M, have a profit of $100k. But if you don't do the maintenance, it ceases to comply with changing regulatory requirements and not only has to be shut down but causes you to incur criminal penalties, or develops public security vulnerabilities and then criminals break in and destroy your business and cause you to be sued into bankruptcy by your customers.
In other words, the code creates an obligation that offsets the value of the asset. These two things can easily cancel out so that the total value is ~0 -- or even negative in ways that don't allow you to walk away, e.g. because you entered into a contract to supply this thing for a defined price but underestimated the maintenance cost.
But now the government is telling you that you have something worth most of a million dollars even though it's not worth a dime without putting another million dollars into it -- and even then it still wouldn't be worth two million dollars.
The reason you continue to do it is that the continued development made you $100k this year, not because what you had left at the end of the year that would be worth something without further investment.
> O wait obviously that’s not what code is a liability means. Code is a liability in the same way roads or buildings are a liability, they incur an ongoing cost, but removing the US highway system would be just as idiotic as a startup deleting their source repository from a misunderstood idea.
I love this example! It perfectly illustrates a case where the government intentionally subsidizes a liability that no sane company would take on without government funding. Well said.
So we're agreed that the government should incentivize R&D with a favorable tax code that makes it not completely insane to take on the risk of doing something new.
> It perfectly illustrates a case where the government intentionally subsidizes a liability that no sane company would take on without government funding. Well said.
LOL, try again liabilities like buildings don’t need incentives. Software that is only barely worth maintaining isn’t worth subsidizing, highly valuable software needs no incentives.
If anything you’re making a solid argument government should discourage the creation of software so only the most valuable software is created and maintained. Except the optimum economic efficiency as so often happens occurs without government incentives.
Wow all this time I thought the key to a successful startup was to just be better and more disruptive than the competition but really I guess it all comes down to being more tax efficient.
We are small and so have been on a hiring freeze since 2022. I’d like to hire but the upfront cost is high.
For those around when this went into effect many business owners were surprised. Our accountants told us they seriously thought congress would fix this before it went into effect.
... they did that because that's exactly how Trump presented the change. The article points that out: this change was an attempt to lie to the congressional budget office, not intended to be an actual tax change.
And then it suddenly was an actual tax change.
Like so many Trump actions: "oops".
[flagged]
Often the way this works is that some time bomb is added to the tax code so that forecasts for future tax revenue will be higher (justifying more spending in the short term) and congress then needs to remember to remove the time bomb before it blows up. So it isn’t that uncommon for these things to be reverted.
Everyone knows it’s a time bomb but the only way we can get an omnibus funding bill through Congress is reconciliation. That’s how our government has been functioning since like 1980 and almost nothing has been “reverted” since then except for the time bombs required to get through the reconciliation process.
Or in this case, not justifying extra spending, but justifying extra tax cuts for incomes above a half million dollars per year, inheritances of more than 5 million dollars, corporate profits, private jet flights, and a variety of other special tax cuts, mostly aimed at wealthy GOP donors.
It's actually not uncommon for something stupid to make it to the official tax code and then get reverted. They knew the history.
Get a better government.
Get better citizens.
Get better education for kids that grow to become citizens
There's another word for "educating" people until they reach the decision you want them to.
Brainwashing.
You know it's completely possible that people have a different outlook or opinion or perspective on things and that is why they disagree with you, not necessarily a lack of education?
Some people think these are good ideas and they vote or welcome them. Some people think they are bad ideas and they vote or oppose them.
No, education is not brainwashing. These terms have different definitions. One is by definition good, one bad. Words matter, definitions of words matter.
I’d love an education system that only teaches scientific consensus, and leaves moral conclusions to parents and households. However I’m sure you’d appreciate that’s not what we have.