plz 4
Google v. Oracle
A nice thing about computer programs is that they are composable. You can write a program that does one specific task and then you can use that first program to perform the task as part of many other programs. For example, let’s say that you like to make video games. You might write a program that renders pixels on the screen based on some formatted input. Every time a new input is provided, the program replaces whatever was on the screen with the new input. Perhaps you apply some optimizations to make this program really fast so that your games can have a high frame rate.
Now that you have a performant program for rendering things on the screen you can use it every time you make a game! When a game needs to update the screen it can simply pass a new input to the rendering program. You can reuse the rendering program in every game you make and if you ever update the rendering program (to fix a bug or make it faster) you will be able to easily apply the update to all your games since they all contain the same program. You could also put the code for your program on the internet for other people to use in their games (this is called open-source software).
The games don’t need to understand what processes or optimizations go into quickly updating each pixel, they just need a way to reliably change what’s on the screen. All the rendering details are neatly encapsulated in the program and as long as the games can reliably trigger the rendering program they don’t care what’s happening under the hood.
That ‘trigger’ — the way one program causes another to execute — is called an Application Programming Interface or API. An API is a definition of the various ways that a program can be triggered. In the case of your rendering program, it might be a function like paintScreen. The function has an input (the pixels that need to be painted on the screen) so the full definition might be something like paintScreen(int[][] pixels). Every game that uses your rendering program will have code that calls the function when it needs to change what is on the screen. This API is very simple (only one function) but a more complex program might have tens or hundreds of functions in its API. The important thing to remember is that the API is not the contents of the functions, it is only the interface between the programs. The promise is, “you don’t need to know or care how the pixels end up on the screen, just call this function and it will happen.”
Let’s say you open-source your rendering program so that other people can use it. The program is really good and lots of people download your code to use it in their games. However, the march of progress is relentless and with time your rendering program begins to show its age. Your program is not optimized for the newest hardware and you have stopped making updates for it, having abandoned the software industry to pursue your love of carpentry. An up and coming game developer decides to write a new rendering program from scratch. They don’t use any of your code but instead apply the most modern algorithmic optimizations to build a blazing-fast program.
Everyone is excited to replace your old, slow rendering program with this new one. Remember paintScreen? This new program has a printScreen function in its API too! The contents of the function (and, indeed, the whole rendering program) is completely different but each game doesn’t need to know or care about that. Each game author can drop the new program into their project and delete your code and the games don’t know the difference! The authors get to enjoy the performance improvements of the new program without having to rewrite their games’ code, because a consistent API allows the games to work with either renderer.
Imagine that you never discovered carpentry but instead made a business out of your game software. You can imagine all sorts of useful programs besides rendering: customizing control configurations, managing save data, playing in-game sounds, etc. You write programs to handle all these challenges and instead of open-sourcing your code you license it to game studios. Your programs are good and these are hard problems to solve so the game studios are happy to pay. Your company grows into a massive corporation and you become fabulously rich.
However, the march of progress is relentless and with time a smaller, more agile company decides that your programs are overpriced and that they can write their own, better versions. They start with a rendering program and soon have a working beta version. Since everyone in the industry (including them) is using your rendering program right now, they write their program to mimic your API. It has a function with the exact same name and input: printScreen(int[][] pixels). They haven’t used any of your code but they did copy the structure of your API to take advantage of the interoperability that we’ve discussed.
Is this theft? The Supreme Court says no:
In a win for innovation, the U.S. Supreme Court has held that Google’s use of certain Java Application Programming Interfaces (APIs) is a lawful fair use. In doing so, the Court reversed the previous rulings by the Federal Circuit and recognized that copyright only promotes innovation and creativity when it provides breathing room for those who are building on what has come before.
This decision gives more legal certainty to software developers’ common practice of using, re-using, and re-implementing software interfaces written by others, a custom that underlies most of the internet and personal computing technologies we use every day.
To briefly summarize over ten years of litigation: Oracle claims a copyright on the Java APIs—essentially names and formats for calling computer functions—and claims that Google infringed that copyright by using (reimplementing) certain Java APIs in the Android OS. When it created Android, Google wrote its own set of basic functions similar to Java (its own implementing code). But in order to allow developers to write their own programs for Android, Google used certain specifications of the Java APIs (sometimes called the “declaring code”).
That article from the EFF has a good overview of the history of the case and the role of Java APIs and their role in the Android operating system. The case was long (a decade!) and complicated, with multiple overturns-on-appeal and a mix of copyright, patent, and fair-use issues in play. The result is notable for what it avoided: if APIs were deemed copyrightable a wave of rent-seeking behavior would have been unleashed and a key pillar of software interoperability would have been damaged. Imagine if the innovative newcomers in our rendering program examples had been met with (valid) lawsuits.
Paul Graham v. Wealth Tax
Is it bad for a society when some people have way, way more money than everyone else? Some people think so, and one of the ways they have proposed to address this issue is a wealth tax. Though proposals come in many forms, the basic idea is usually to levy a tax on assets (as distinct from income) above a certain threshold. For example, a 1% tax on assets above $50 million would mean that someone with $60 million in assets would be assessed $100k (1% of $10 million) in a given year, regardless of what they were doing with their money. Anyone with less than $50 million in assets wouldn’t pay any additional tax.
Despite the rhetoric from some corners, most popular wealth tax proposals don’t function as a mechanism to ‘eliminate all billionaires’ or any such thing. Instead, a wealth tax is theorized (in the U.S., some countries already have wealth taxes) as a more aggressive form of progressive taxation, something advocates view as desirable in the face of rising inequality.
There are unlimited ways to set this up and also unlimited things to do with the tax windfall. You could increase spending on social services, reduce taxes on the middle class, build some cool fighter jets, it’s open season. Supporters of a wealth tax (in the U.S.) typically point to the country’s relatively low maximum marginal income tax rate, tax avoidance among very rich people, and rising wealth inequality as reasons to favor more progressive taxation. Common arguments against a wealth tax are that it would incentivize both tax evasion and capital flight. Detractors argue that the second and third-order effects of a tax would harm the poor and middle class, ultimately outweighing the benefits of wealth redistribution.
What does Paul Graham think about this? Paul is a programmer and writer, notable for founding Y Combinator and publishing essays on the internet. In keeping with the goals of Y Combinator he is a staunch advocate for startups and policies that bolster the startup ecosystem. It was from this perspective in August of last year that he wrote “Modeling a Wealth Tax”, describing the effects of various wealth taxes on a successful startup founder over 60 years:
Suppose your stock is initially worth $2 million, and the company’s trajectory is as follows: the value of your stock grows 3x for 2 years, then 2x for 2 years, then 50% for 2 years, after which you just get a typical public company growth rate, which we’ll call 8%. Suppose the wealth tax threshold is $50 million. How much stock does the government take now?
wealth tax government takes 0.1%
5%
0.5%
23%
1.0%
41%
2.0%
65%
3.0%
79%
4.0%
88%
5.0%
93%
It may at first seem surprising that such apparently small tax rates produce such dramatic effects. A 2% wealth tax with a $50 million threshold takes about two thirds of a successful founder’s stock.
Wow, that sounds scary! Paul says that even at a 1% tax on assets above $50 million the government will (given 60 years) take 41% of a hypothetical founder’s stock. How much money is that? With the growth Paul outlines the founder’s stock is worth $72 million in year four when the tax first kicks in. The stock grows at 50% for two years and then 8% for the remaining 54 years so without a tax the founder would net $10.3 billion. With the wealth tax the government takes 41% of that leaving the founder with a little over $6 billion.
That is… still a lot of money? I don’t know, we’re talking about sums that are really beyond our capacity for imagination. I think the implied point of Paul’s piece is mostly what I outlined earlier: that a wealth tax like this would disincentivize people from starting companies (creating value) and thereby be a net negative for the people it is designed to help.
I suppose it could be true. It does seem a little disingenuous, though, to concoct a hypothetical scenario as an example of the negative incentive (government takes 41% of your money! scary!) and not mention that you walk away with billions of dollars. I don’t think that’s an uncharitable reading of the essay, especially given that Paul’s net worth is likely somewhere in the nine-figure range. There’s a clear conflict of interest.
Macroeconomics and tax policy are very complicated topics to begin with and the politicization of this issue makes any attempt at an unbiased analysis of wealth tax effects challenging. Even so, it’s disappointing to see Paul employ his usual pro-startup viewpoint as a smokescreen for his personal incentives.
Bookmarks
Making $100k selling premium editor themes. “Young female Japanese biker is really 50-year-old man with luscious hair using FaceApp”. Please don’t sabotage the Linux kernel.