That's not a hack, if you operate the entity from Germany, it must be registered in Germany. It's often touted as a tax loophole, but it's not. Tax authorities do not care about you unless you actually make money, then they will come after you.
Would the liability shield not generally apply to a foreign entity registered in Germany? Sure there may be special rules for non-compliance with specific tax obligations, but I'm talking about for general liability for other purposes, like a contract signed by the entity where no personal guarantee was given, or a harm caused by the corporation where the owner was not personally involved or negligent in causing the harm.
It must be seated where the business happens for compliance with tax laws. But you may have a French S.a.r.l. in Germany and thus fall under their company law (with impact on publication responsibilities, company governance etc.)
While for some cases there is room for abuse (like Amazon Kindle eBooks are sold to Germany by a company situated in Luxembourg, while only selling via amazon.de to audience with German residency) However my employer is a Dutch B.V. with headquarters in Germany, thus they avoid having to form a board with works council representatives as a German GmbH (or AG) of comparable size would require.
Specifically, it must be seated where the principal management of the business occurs.
So if the executives and board meetings and books and records are strategically located in one country and most of the business operations are in a second, it's valid and probably even required for the business to have its tax residence in the first country rather than the second.
It may very well have a permanent establishment and therefore some tax obligations in the second country, but that's different from the second country being the primary tax residence.
> However my employer is a Dutch B.V. with headquarters in Germany, thus they avoid having to form a board with works council representatives as a German GmbH (or AG) of comparable size would require.
Damn, that's a pretty sleazy business practice. How do you feel about it? That would be a nice loophole to close.
It's not that easy if you want European integration and support the idea of "freedom of settlement" also for companies, which to me makes sense and it is known that some countries try to pull companies to register in their legislation with sometimes improper means. I would prefer to focus on Irish taxation, which extracts value produced elsewhere to Irish benefit.
Workers rights are being unified, but that's a long complex process, as work cultures vary a lot and most companies fear German-style code termination, while it's an uphill battle to weaken it in Germany, thus it remains in national law's responsibility.
And to be clear:
a) works council exists with all normal rights, only they don't have board seats, which can be quite powerful, especially in public companies where one might form alliances with independent share holders. In the case here it's a 100% subsidiary of an American corporation, so they get their will one way or the other, board members may only delay
b) I am somewhat priviligedge as I am no simply replicable conveyor belt worker, but somewhat specialized engineer
c) I'm currently on garden leave period after 18 years in the company (incl acquisitions) due to a reduction, where works council produced a quite nice exit for me, so the only time I needed it, it worked well. But then I am somewhat privileged over others, making it hard to generalize.
>c) I'm currently on garden leave period after 18 years in the company (incl acquisitions) due to a reduction, where works council produced a quite nice exit for me
Isn't this type of generosity the exact reason why German companies are making restructuring and moving jobs abroad where they don't have workers councils and such generous exit packages?
Like I'm sure it worked well for you now, but I'm wondering how sustainable this is for German companies going forward, in a more competitive business-cutthroat globalized world, that has less and less barriers for capital and trade.
It is complicated and has multiple dimensions. For example it also leads to workers not switching Job away from an employer as quickly.
It's also interesting how it plays together with social benefits: As it is hard to fire people, hire&fire isn't an approach, thus companies keep workers longer during a downturn, thus when they let go there is more budget for social security.
Also the effects of having works council representatives on the board might lead to decisions not tied to the quarterly results, but long-term stability.
This all of course makes it harder to do experiments, build up a business unit to see if an idea might work ...
As a worker it is quite good and the model worked quite well for large parts of the 20th century. With global competition (for many jobs exact location doesn't matter) it could be a factor which plays a role in being late with digital stuff.
Unfortunately your comment still doesn't address my concerns on how this model is supposed to be sustainable to work in the future given the new economic realities of Germany's faltering industry, and especially the existing intra-EU disparity between german labor and eastern European labor, let alone international labor.
You're reiterating the pros of why it's been good SO FAR, but you don't drive on the road by looking in the rearview mirror, if you get what I mean.
My take is that the german government will have to do another "agenda 2010" row of cuts to union and labor rights, if it wishes to keep jobs in the country and remain a competitive export economy, hell, even Switzerland has significantly less labor rights than Germany. Not saying that's a good thing, but it seems like that's one of the necessary evils if you want to have a growing economy, and not turn into Italy or France.
It's not that it must be registered (incorporated) in Germany. It's that for tax purposes if the company is run from Germany it will be considered "permanently established" and treated as resident there. Permanent establishment laws are often quite surprising to people doing business across different territories.
You don't need business plans and all that stuff. The problem in Germany for instance is that a GmbH needs 25k of capital + expensive notarization. These are the only two things that need improvement.
You can start an Unternehmergesellschaft (UG) within days with a template. However tax filing burdens will costs you around 2000€ baseline a year without having a single Euro of revenue let alone profit.
Came here to say the same. Founding a company in Germany is way to complicated and expensive... same for dismantling a company. I don't understand why you need a notary for everything.
Clear right? Because of notaries? They are powerful as everything official goes through them. They also do nothing usually; their underpaid underling presses a few buttons, enters a few names (often wrong the first time), prints and so on and then notary reads and signs. Money made. Luckily this has been changing a lot that some notaries smelled a rat coming and started to go for mass market, heavily undercutting all others for standard contracts; in some cities I have seen these type of places eating all the other ones. They are fast and cheap until you need custom stuff.
I don't disagree with that call out. However, we've been through these discussions many times over the years. The solid queue of yesteryear was delayed_job which was originally created by Shopify's CEO.
Shopify however grew (as many others) and we saw a host of blog posts and talks about moving away from DB queues to Redis, RabbitMQ, Kafka etc. We saw posts about moving from Resque to SideKiq etc. All this to day storing a task queue in the db has always been the naive approach. Engineers absolutely shouldn't be shocked that approach isn't viable at higher workloads.
It's not like I'll get a choice between the task database going down and not going down. If my task database goes down, I'm either losing jobs or duplicating jobs, and I have to pick which one I want. Whether the downtime is at the same time as the production database or not is irrelevant.
In fact, I'd rather it did happen at the same time as production, so I don't have to reconcile a bunch of data on top of the tasks.
But even for the logical databases, if I want to revert to an earlier state of the database, why wouldn't I want the tasks as well? If I have a bunch of update tasks in flight at that point, wouldn't I want them to actually run? They are a part of the overall state of the system.
I use the same motion to iterate on linter config and hooks (both claude code hooks and git hooks). So guardrails are actually enforced and iterated upon and do not clutter the context.
It's good idea. I didn't think of it because this project came about a "let's try to write a remote MCP server now that the standard has stabilized."
But there are some issues:
1. Cheaper + Deterministic: It is much more costly, both in terms of tokens and context window. (Generating the code takes many more tokens than making a tool call.) And there can be variability in the query, like issues with timezones.
2. Portability: It is not portable, not all LLM or LM environments have access to a code interpreter. This is a much lower resource requirement.
3. Extensibility: This approach is extensible, and it allows us to expand the toolkit with additional cognitive scaffolds that help contextualize how we experience time for the model. (This is a fancy way of saying: The code only gives the timestamp, but building an MCP allows us to contextualize this information — "this is time I'm sleeping, this is the time I'm eating or commuting, etc.")
4. Security: Ops teams are happier approving a read-only REST call than arbitrary code running.
One last thing I will say: The MCP server specification is unclear how much the initial "instructions", the README.md of the server for the model, is discovered. In the "passage-of-time" MCP server, the instructions provide the model with information on each available tool as well as the requirement to poll the time at each message.
In practice, this hasn't really worked. I've had to add a custom instruction to "call current_datetime" at each message to get Claude to do it consistently over time.
Still, it is meaningful that I ask the model to make a single quick query rather than generate code.
Because LLMs are notoriously unreliable especially over long context. Telling it something like "check the time before every turn" is going to fail after enough interactions. MCP call is more reliable for programmatic and specific queries, like retrieving the time.
> But if it's so obvious, why aren't other developers rolling out their own PKMS? Perhaps I'm the first to discover this or perhaps developers aren't writing about their custom PKMS. My guess is that commercial note-taking apps have larger, more vocal communities that drown out the murmurings of other DIY solutions.
It's a good idea to just not do stupid shit that would make it very painful to actually get compliant. Get vendors who have certs, keep infra minimal (which means not infra team). The more you do in house the more painful compliance will be. Buy, and buy from certified providers, simple. Manage identity centrally, keep all your secrets in a secret manager, use git and do code reviews. You're right all things you should be doing anyway.
Manage identity centrally is probably referring to using an identity management system like Okta, Microsoft Identity, or hosting your own IdP and using strong hardware 2FA. You don't want people creating their own accounts manually for everything or shared accounts that everyone knows the password for (or is on a shared spreadsheet that the entire company has access to).
At this point most startups would just use Google; since they're almost certainly using Google as their email provider, and "company email" is a de facto root-of-trust even if you don't intend it to be, there isn't really a whole lot of thought that needs to go into it. It helps that they have the best 2FA stack of any mainstream cloud service.
reply