Nothing written here is a legal advice.
Open approach is extremely dangerous because it bypasses spent controls, or any controls in generals. Some people claim that Linux won the server market long time ago not because it was superior to Windows, but because you had to wait 4-6 weeks to get an approval for buying Windows, and, at the same time, you could get Linux almost instantly.
Similarly, one company offers a HR suite (vacation planning software + a few other features) for the first year for FREE, and a lot of startups and small companies is falling for it, only to discover later that the cost of migration to a new solution is just slightly smaller than a licence for the next year.
Embrace & Extend is one way of dealing with such movements, but it is not the only one. There are far more evil 
approaches created in order to subtly damage the open component in a seemingly innocent way.
Licensing Play
Can be useful when dealing with hostile forks or when doing a hostile fork. The main goal is to use a licence that cannot be accepted by your competition because it will harm its business. A good case is Oracle developing Oracle Open Office suite on the top of the Open Office code acquired from Sun (under Apache Software Licence). A community fork used Open Office but changed the licence to LGPL (and the name to LibreOffice). Now LGPL software can take and use ASL licensed code, but not in the other way round unless the entire software pack is licensed under LGPL. In simpler words, LibreOffice can copy any feature of Open Office, but Oracle Open Office couldn’t copy code from LibreOffice (unless Oracle was willing to share every code modification).
It did not work well for Oracle, and the Oracle Open Office was cancelled, and regular Open Office died at the Apache Foundation (sort of, because developers moved to the LibreOffice).
Similar gameplays are possible when using dual licensing - pretending that a software is an open source while the licence practically limits the usage of the software through difficult to meet requirements (f.e. AGPL).
It is also possible to use an open licence that does not cover everything. As an example, Red Hat ships a Red Hat Enterprise Linux (portions are under the GPL licence). But if you wanted to use the source of RHEL to build and ship it, Red Hat would become very upset about the ‘Red Hat’ trademark. GPL does not cover trademarks, so Red Hat has a right to demand you to stop distributing ‘Red Hat’ logo. Some companies go for logo replacements process to comply with legal requirements, yet, it is tough.
Similarly, some licences do not cover patents. Incorporating some code with such a licence can bring a few surprises 
.
Insertion/Poison
This is one of the plays that is almost impossible to proof. You can, f.e. contribute a legal team to the Open Source community and ensure that the team is working very diligently, and carefully analysing all the risks and threats. By playing the role of a good uncle, you are slowing the development down. It does not have to be a legal team - contribute whatever you can - sloppy developers, inadequate hardware, processes that waste time, useless features that do nothing important but require extensive reviews.
CIA is pretty good at it. See chapter 11 on page 28 of this manual.
Design to fail
Start your own open source project before one is started by any of your competitors. Assume it grows well initially, and then poison it slowly. Your competitors will face a tough challenge - they will be convinced that such an initiative cannot really work, and it will take a really long time (or unexpected courage) before they decide to use open.
In the meantime, you can continue with whatever you are doing.
Note: I do not think anyone is able to prove that such a gameplay has really happened. Genius is not that different from total madness here.
