Frequently Asked Questions
First, we will present the process in brief, as it is very easy and straightforward. After that, we will go into a little bit of detail about why it works the way it does.
That's it. The whole process usually takes about five minutes of your time to arrange.
It's very common for expert web developers and designers to use our service to set up and manage accounts, domains, and sites for third parties. The third party might be an individual (like clients, friends or relatives) or a group, club, or company that the person is involved with. (For the sake of simplicity we'll call people who do this "webmasters" and we'll call the third party the "client" for the rest of this FAQ entry.)
That's a good match for the way our service is set up, and it's fine to do as long as everyone involved understands that, as far as we're concerned, the member managing the account is calling the shots.
From time to time, for various reasons, it becomes necessary to change the responsible party. Maybe a client/designer relationship is ending, or maybe someone is leaving the company or graduating out of a school club. This situation, which is often already delicate enough, does need to be handled with special care.
The very first thing is to be very sure you understand the difference between an account and a membership. It helps this type of transfer a lot if all the relevant assets are bundled up in one account on the current webmaster's membership. Then, it can then be transferred as a single easy piece to the client's membership. (Most people handling hosting for others already manage assets this way anyway for accounting purposes.)
Transferring assets from the developer's membership to the client's membership (whether neatly bundled in one account or not) must be done while following certain very strict rules about NearlyFreeSpeech.NET memberships:
This means that if you are acting as a webmaster for a client, you cannot, for any reason, create or access a membership belonging to them. This specifically includes setting up a new membership on behalf of a client. And they cannot access your membership either. So giving them your login and password information and sailing off into the sunset is right out.
The common question at this point is how a non-technical client is supposed to set up and manage a membership and hosting for themselves. The answer is that they are not. Our service is designed to be used by skilled webmasters, and it's often the case that removing the technical expertise of a professional developer without replacing it with an equivalent is simply not viable. If you find yourself in a situation that would wind up with a NearlyFreeSpeech.NET membership in the hands of someone who won't know what to do with it, stop. That probably means the transfer you need to arrange is to a hosting company that offers a lot of tech support (e.g. telephone tech support) and caters specifically to nonspecialists. That's absolutely fine; there are a large number of such companies. We would much rather that happen, than for someone to end up with a NearlyFreeSpeech.NET member left in the lurch with no idea of what our rules and policies are, or how to use our service.
For this reason, if we detect a transfer request between two memberships that appear to have been accessed by the same person, we will stop the transfer. Depending on the circumstances, we may refuse to process it entirely. But at a minimum, we will contact both parties and ask them to verify their identity and that they submitted their request themselves. We will further ask the recipient to confirm that they personally went through the signup process, that they have read and understood (and agreed to) our Terms and Conditions of Service, that they understand the nature of our service, and that they are comfortable managing their membership and account moving forward without any external assistance (including ours). Only if we're satisfied will we allow the transfer to proceed.
That's a lot of extra hassle. However, it's very simple to completely avoid it: just make sure that the transfer recipient sets up their own membership and that neither the sender nor the recipient ever accesses the other's membership.