Even regular employment is OK. Tested that myself. It actually is better from taxation view for the employee compared to working for EU native companies - might not apply to all EU states though - but it does in my country of residence, thanks to the bilateral double taxation avoidance deal.
how does that work? does your remote employer pay their part of the taxes for you as employee? do they honor your local employment laws with regards to holidays, and what not? can you sue them if they violate your countries labor laws?
what is the company reporting about you in their country?
i'd really be curious to learn more details about the arrangement. my guess is that it looked like employment but legally it was contracting.
No, your guess is wrong as I had no business license at the time and the local tax/insurance agency would come after me immediately (because nobody would've been paying my mandatory insurance).
I had 25 days of vacation (standard here, 5 days over minimum). The US company had to register with the local tax agency - there is a standard procedure for this situation. Applicable labor law is based on physical location specified in contract so my local law had to be followed.
You don't usually sue companies for violation of labor laws here - you go to the labor agency and complain, then they sort it out. I didn't have any problems though, so I don't know much about this.
in germany/austria i don't need a business license to be a sole proprietor. i just need to report my income and pay the relevant income taxes.
suing was meant to be a stand in for any way to sort out complaints. how does your labor agency force a remote company to comply with your laws? in particular how would they deal with wrongful termination?
maybe we are talking about the same thing, and there is just a difference of what you or me consider a contract vs employment.
may i ask what is your country? the US company registering with your tax agency is interesting. that may make all the difference. i'd like to know more about that.
I really don't know more about resolving complaints as I haven't had any problems. I guess at some point things would go to courts.
Employment is the thing that's defined as employment by the labor law, where the employer signs an employment contract with you and then pays you salary and sorts out your taxes/insurance... Contracting is having a business licence and sending invoices to a customer - with zero relation to labor law. In particular, no concept of vacation, and you pay your own taxes and insurance.
employment for me is what gives me the right to holidays, employer contributions to insurance, overtime pay and protection against unlawful termination.
this is why i consider any remote employment a contract:
you have to pay all taxes yourself, there are no employer contributions (you just have to negotiate a higher salary).
you have no legal means to force the remote company to follow local employment laws, other than an international contract dispute.
it is possible that some countries make it easier to treat a remote job as employment by simplifying taxes or easier access to unemployment benefits, compared to a truly self-employed person.
it may be that czechia offers that. given that it is part of the EU it would actually be interesting to know if other countries offer that as well, or if it is even based on some EU wide regulation.
there may also be specific treaties between countries that support this.
It's not like the life extensions pills would make you impenetrable to bullets. Or just stop taking them if you stop liking it. Anyways, if the most important thing to you is visiting a new restaurant every day, perhaps immortality really isn't for you - doesn't mean there aren't people who would make much more of the gift, e.g. see another star (or a dozen) or something, hmm, more imaginative.
The payment processors will shut you down even for your first payment if it's for porn. More likely - you'll never get to a first payment anyways, they won't sign the contract.
> The payment processors will shut you down even for your first payment if it's for porn. More likely - you'll never get to a first payment anyways, they won't sign the contract.
If that was even occasionally true, the tons of paid porn sites wouldn't exist. The fact that they both exist and take popular cards tells me that that cannot possibly be true.
There are special payment processors catering to porn/etc, but the problem is that they require extremely large collateral and have other unusual requirements that are untenable to new businesses. Most probably they won't even talk to a startup (I tried, didn't get a reply). There's a reason why startups like OnlyFans used normal payment processors and tried to convince them they're not porn instead of beginning with these specialized ones.
Edit: BTW, a large portion of seemingly independent porn sites are actually run by only few companies. Especially the Xvideos corporation.
A payment processor is an entity that handles bureaucracy. It's not a piece of software you can run and forget about. It is many people working around the clock taking phone calls.
I should have been clearer and said "software to aid in running a payment processor" but I used "payment processor" as a shorthand. Just as "open-source Amazon" is shorthand for "software to aid in running an entity like Amazon."
You somehow forgot to mention that most (probably all) EU countries have laws that require you to know the birthdays of your customers - that of course overrides GDPR, or more precisely, the law is the reason to store the information so there's no need to find other reasons.
Also, don't forget that these laws also have requirements on you keeping logs, most of the time 3, 5 or more years. So yeah you have to obey a deletion request when that time is up, not "on request" - that would be illegal in most cases.
In many EU countries birthdate (and more) is public information, btw - my own birthdate is made public by the state itself (on the business registry website), together with my name and residence address. Same for any owner of real estate - be it land, house or unit - names, residence addresses and birthdates are publicly available in the online cadastre.
Any online service thanks to DSA, for example: Anything that children might use (yes, so everything - intent doesn't count). Anything where users can upload content (writing comments is enough according to our lawyer).
You picked about the only remaining thing where it's not always a requirement. It's a requirement even there if the transaction is over certain threshold (varies by local law, usually around 10k EUR) or certain categories of items (drugs, alcohol, tobacco-related, sextoys, weapons etc).
We're talking about programming apps such as Google docs. It is a hard requirement. Your reply is completely useless from technical perspective. Sorry-not-sorry to be so blunt but I have no sympathy for "yeah you can do it without any JS if you remove all features". Let's just go a little further and throw away our computers - we can send carrier pigeons to each other, right? And what's this paper stuff? Useless! Stone tablets 4ever!
And as a user, it is a hard requirement for me too. I never want to go back to locking and versions, that's absolutely terrible and completely kills the workflow I have with my colleagues. Collaborative docs editing is single most awesome development of the modern web and users are choosing the otherwise not-so-good Google Docs solely based on this feature. Perhaps not every user needs it - but there are countless users that do. If I wanted to edit without collaboration I'd use Word - much better UX and document editing capabilities... Sadly no truly working collaboration - it's too much like locking/versions, so it's not an option. I'd rather use collaborative raw text editor than the best of the best locking/versioned WYSIWYGs.
Tell that to the solar flare that randomly burns everything on it... Or the asteroid that crashes into it... Or the black hole that eats it... Or the aliens that invade it... Or the plague that kills everyone on it... Or the supervolcano that causes "nuclear" winter...
We could be doing our absolute best and still be surprised pikachus anyways. And there's no scifi remedy that will help us resolve these problems, we're not even K1, much less K2 - who's on Earth when it comes dies.
As the only known example of intelligent life in the observable universe, we should be doing everything we can to preserve ourselves. Having everyone on one planet is not a good idea if you're looking for survival on geological timescales (and/or have bad luck).
Hmm, why don't you specify your development-time dependencies as devDependencies in your package.json? Then you can simply install only the production ones in your final step Docker image - and only use the devDependencies in your build step. I'm doing it, works like a charm. It'd be really weird and wasteful to ship my TypeScript and Eslint and whatever to cloud/Lambda/...
> Hmm, why don't you specify your development-time dependencies as devDependencies in your package.json? Then you can simply install only the production ones in your final step Docker image - and only use the devDependencies in your build step.
This is pretty close to the solution and would work if I ran just Node.js server side. Then I could easily have separate sets of dependencies for development and deployment/running, which is what most folks should do. Yet in certain tech stacks, things aren't as easy and there is reliance on system folders instead of local ones.
For example, my application that's running on the server should have absolutely nothing to do with Node, since it should run Ruby alone and use the bundled files, however it should have all of the Ruby Gems (basically packages) available. Of course, I also need Node and possibly something else during build time, for generating my assets.
For example, my intermediate container images might look like:
FROM ruby_with_node_and_python AS builder
# Copy only what's needed for installing dependencies and other garbage (e.g. changed code files won't invalidate Docker cache)
COPY ./src/.browserslistrc ./src/.ruby-version ./src/babel.config.js ./src/config.ru ./src/Gemfile ./src/Gemfile.lock ./src/yarn.lock ./src/package.json ./src/postcss.config.js ./src/Rakefile /app
# install front end dependencies
RUN yarn install
# add code and run asset creation
COPY ./src /app
RUN bundle exec rake assets:clobber RAILS_ENV=production
RUN bundle exec rake assets:precompile RAILS_ENV=production
# install back end dependencies
RUN bundle install
# run tests (local SQLite, for example)
RUN rails db:migrate RAILS_ENV=test
RUN rails test RAILS_ENV=test
# clean up files after build (so copying in later images doesn't drag garbage along; this could be a separate intermediate image too)
RUN rm -rf src/node_modules
# clean up files after test (so copying in later images doesn't drag garbage along; this could be a separate intermediate image too)
RUN rm -rf src/log/*.log src/tmp/*
And then my container images for deployment would look like this:
FROM ruby_with_nothing_else AS runner
# copy over application files
COPY --from=builder /app /app
Except that this doesn't work! Why? Because Ruby Gems aren't installed in the application directory, but instead sit in a variety of directories on the actual file system. So instead I'd need something like:
FROM ruby_with_package_manager AS runner
# we actually could not carry over the precompiled gems etc. because I'm stupid, so instead we now run the install again :(
# well it's not like you need front end files here, but this doesn't really mean much
COPY ./src/.browserslistrc ./src/.ruby-version ./src/babel.config.js ./src/config.ru ./src/Gemfile ./src/Gemfile.lock ./src/yarn.lock ./src/package.json ./src/postcss.config.js ./src/Rakefile /app
# install back end dependencies
RUN bundle install
# copy over application files
COPY --from=builder /app /app
So while npm/yarn allows you to avoid some of the issues with `npm install --production` to exclude the devDependencies, other tech stacks aren't quite there yet. In addition, it feels kind of crazy to ship package managers like npm/yarn/pip/composer/bundle/maven or anything else in containers that should be immutable, so in practice you'd end up with more stages, even if you knew how to carry over the packages from one image to another in the technology stacks where it's not entirely clear how to do that.
I actually tried something similar to this, but it simply didn't work, especially when native extensions were needed for some of the Gems: https://stackoverflow.com/a/33778136
Nah, that's positive.