Cdtjkyj

The basic difference is that /usr/local is for software not managed by the system packager, but still following the standard unix deployment rules.

That's why you have /usr/local/bin, /usr/local/sbin /usr/local/include etc...

/opt on the other hand is for software that doesn't follow this and is deployed in a monolithic fashion. This usually includes commercial and/or cross-platform software that is packaged in the "Windows" style.

They are very similar indeed, and the use of one or the other is more a matter of opinion.
Linux journal had this point/counterpoint discussion about this exact topic here.

For me, personally, it's what Bill said in @philfr's link:

On a development system, or a sandbox, having an /opt directory where you can just toss things and see if they work makes a whole lot of sense. I know I'm not going to go through the effort of packaging things myself to try them out. If the app doesn't work out, you can simply rm the /opt/mytestapp directory and that application is history. Packaging may make sense when you're running a large deployment (there are times when I do package apps), but lots of times, it's nice to toss stuff in /opt.

Unfortunately, most make install scripts pushes files into /usr/local instead of just making a symlink there :-/

First, I don't think there is a strict answer; different
adminstrators will have different opinions, according to their
background. Historically, /usr/local came first; it was the
convention in Berkley, IIRC. At one point during the
development of System V, if I'm not mistaken (this is all a long
time ago, and I didn't take notes), there was a decision or
a desire to be able to mount /usr read-only, which meant you
couldn't add new software to it; that may have been why /opt
was invented. As it happens, there was just so much existing
software that did write to /usr that that idea never really
got off the ground.

My personal preference is /opt, with a separate subdirectory
for each product; this makes removing a product a simple case of
rm -fr. But if all of your software is installed via a good
package manager, it doesn't matter, and if the software you
install doesn't strictly obey these conventions, and writes
configurations and such somewhere under /usr, it doesn't
matter either, although for the opposite reasons.

I have a slightly different take on this issue.

While everything in jlliagre's answer is correct, the practical application for me, when deploying software in a cluster, comes down to default environment variables and default reuse of libs.

Simply put - /usr/local and all its child dirs are in the appropriate env vars such as PATH and MANPATH, and /usr/local/lib{,64} are in ldconfig's (/etc/ld.so.conf.d/).

/opt/ OTOH is not — which is both advantageous when requiring multiple versions or conflicting packages to co-exist in the system, but requires some sort of environment management (e.g., environment-modules or software collections), and disadvantageous in that it would potentially "waste" storage space by duplicating shared libraries, as each installation in /opt can be completely self contained.

For the shared nature of /usr/local to work, it is assumed that e.g. binaries are installed directly to /usr/local/bin (and man pages to appropriate /usr/local/share/man/...) rather than /usr/local/app/{bin,share/man,...} etc.

/opt is intended for LANANA whilst /usr/local is not. LANANA is an authority that assigns names to packages in order to prevent conflicts between them across different plataforms and systems. I think that's the only difference concretely speaking.

In conclusion, you should place your self-made software into /usr/local, because /opt is intended for add-on's to install via the distro's package manager.

http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html