Comment by bunnie

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.

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.

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.

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.

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.

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.

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.

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.