There's another piece to the definition. The traditional RDBMS (Oracle, DB2, SQL Server, MySQL, PostgreSQL) is designed to give 100% consistent results. All other design goals are sacrificed so that two people asking the DB the same question at the same time will get the same answer, and no one can make a modification and someone else gets an answer that is not 100% up to date. NoSQL trades consistency for flexibility/simpler scalability.
If you post something on a social network at 1:00 and your friend in a different timezone looks at 1:00:10 and doesn't see the update, no big deal. If one person authorizes $500 on your credit card at 1:00 and consumes your limit and someone else tries to authorize $300 at 1:00:10 and it goes through because the DBMS isn't giving consistent answers, that's a problem.
They're just systems with two different design goals. Some DBs will let you restrict this - SQL Server 2008R2 has a "replicate to nodes" setup that tries to stay 100% in sync but doesn't guarantee it. OTOH, something like Oracle RAC is always 100% in sync because there's only one set of datafiles shared by everyone.
I said "simpler scalability" because the idea that SQL-based RDBMS systems can't scale to any length is ridiculous - all credit card processing, bank transactions, airline reservations, Amazon orders, etc. all flow through very traditional RDBMS of one of the flavors I mentioned. However, it's a lot more complicated than scaling NoSQL. Getting that guarantee of consistency is not easy once you outgrow a single server, need 100% (not 99.999%) uptime, etc..
NoSQL is also better for large document storage. Traditional RDBMS has LOBs but they're a later add-on and it somewhat shows. Want to store a few gigabytes of LOBs in your DB? Sure. Want to store terabytes of big LOBs and use your DB as a transactional filesystem? It can be done, but it won't be pretty.
All in all, it depends on what you're trying to do.