Internal quality is about the design of the software. This is purely the interest of development.
If Internal quality starts falling the system will be less amenable to change in the future. Hence the
need for refactoring, clear coding, relentless testing, and the like. You need to be very careful
about letting internal quality slip. Ward has a wonderful DebtAnalogy? that discusses it.

External Quality is the fitness for purpose of the software. It's most obvious measure is the
Functional Tests, and some measure of the bugs that are still loose when the product is released.
There is more to it than that, however.

--MartinFowlerInternalQuality is everything the software does not do. It's the implementation, which the customer never directly sees, and often does not want to spend time or money on. Ironically enough, it's often what determines whether projects succeed or not. Take the Web for example - see ImplementationDoesTooMatter.

From here, I can't find any other property that a GoodCode should hold. Surely there are some.
The wiki pages on quality all focus from a developer's perspective on a single project. They need to also focus on architecture quality issues, which affect operations, deployment, adoption, interoperability, etc. Quality of code, Quality of architecture... See RoyFielding's superb dissertation for a discussion of architectural quality, omitting code quality entirely.
CruftMultiplies and TechnicalDebt deal with internal quality slip. Don't know whether the latter is the DebtAnalogy?. -- MichaelFeathers