1. Each Team defines and uses its own.
2. Each Team uses its own but must make it clear to all other Teams.
3. All Teams must use the same definition.
4. It depends.

As far as I remember, I've had this one... wrong. I can't really check as I don't have the results anymore.
Wrong because I haven't mastered multiple Scrum teams yet? As a first intuition I think I answered 2, and I think it was to let self-organization play as much as possible.
Unless I am making the same mistake, the right (and obvious) answer is 3. Obvious because the results of multiple teams will be hard to integrate into the same Product if different definitions of 'Done' were used. It seems that this would be a legitimate boundary to self-organizing.

I answered 2, too. Lack of experience with multiple scrum teams. My experience with multiple teams on large projects is that there is a defined interface between the various parts. Either it's defined by a standard or agreed between teams. So in each iteration done means that parts of the interface work. If a component relies on hardware that is not present then there has to be a way to simulate the action of the hardware, or the interface just responds in an agreed way.

I don't see how the definition of done could apply across a whole lot of teams; some connecting to hardware, others more self contained. The definition would have to be overly complex to cope with the different types of software.

I think the answer should be (4), why...
(1) is not right because it fails to indicate that they have communicated this, agreed it, or any other part of the project understands it.
(2) is not right because although it is communicated it still isn't agreed, just because I tell you that black is white does not imply it really is.
(3) can't be true, the teams may be working in totally different disciplines, a particular example I had was with 3 teams working on a project, one designing and making silicon, one designing boards and the last doing software, I defy anyone to make a sensible common definition of done over those 3. Certainly demonstrating for real on real devices means that the silicon can't be developed step wise (several million to run a mask), the boards therefore can't be done stepwise either (this is hard however you try and rig it, but there are possibilities), this leaves only the software that can be done stepwise, but that can only 'finish' a sprint after the silicon and boards are finished, which then prevents any feedback from software to silicon or boards, not ideal and certainly not a good example of colaborative working.

It depends is the only other answer, and I like this, there are a number of ways of dealing with multiple teams, and how is going to depend on what the teams are all doing, what they deliver to each other, and I daresay a number of other factors I haven't listed.

Dave

The "most" correct answer is 3), but there are problems. It shouldn't be the "same" definition, but it is reasonable to be a common "minimal" definition. Each Team should be free to do more than the minimum, and have the whole organization "inspect and adapt" on the definition as it goes along.

I answered 2 mainly because I have been on small projects with just 2 teams.
Indeed I am always responsible for the splitting. I usually start to isolate technical developers in a "core" team. They are the one who read msdn, install beta vpc and dig with reflector each API. They are not interested in the line of business they are just fond of technologies and I charge them to keep clear the technical debt and their slogan is: the truth is in the code.
The others gather into functional team. They just want to do their job with little adversity [nothing more]. The technical team is responsible for simplifying the functional work by producing tools and solutions which will improve their comfort [Quality, Productivity] in order they will keep focused on business value creation, the slogan of the second team is: code is dirty.
Until now I never tried to make both population understand each other, I just take care that functional workers understand and use the features made to simplify their daily work. Next time I will try to ensure both team share the same done definition but I feel perplexed.

If a developer think you are an alien then you can be sure he belongs to functional team.

There should be a common minimum denominator to the definition. So 3 is the closest, but not the perfect answer

My experience with large systems and projects meshes with Dan's and is a combination of 2 and 3 and 4. On the one hand, there needs to be a common meaning with basic simple rules/criteria that apply to all the teams (even for the fully integrated result across all teams), but each team may also define its own context-specific meaning that abides by "the open-closed principle" w.r.t. to the basic common meaning.

I also find that when there are multiple levels of scale involved (e.g., team-level versus system-level, HW-layer vs SW layer, etc.) that there may even need to be a common-meaning across all levels of scale, as well as a more developed/refined meaning too each level of scale that is common across all other "definitions" & teams within that same scale, but may be more concrete than the the definition at the level above it.

This is ESPECIALLY true when it is deemed necessary to have multiple levels of "customer" (e.g., with a system that comprises multiple "products" to deliver a "complete solution", there might be a system-level, HW or Platform level, software or Product-level).