I don't know what Mr. Papp is complaining about; I was able to reproduce your problem without any more information.
On Linux, if the Qt process with an open QSerialPort instance terminates abnormally or the QSerialPort instance is otherwise not destroyed upon process exit, then the lock file hangs around and can cause a problem. A stale lock file shouldn't cause this problem; the lock file contains the crashed application's PID, and the new application instance should recognize that no process with that PID exists and delete the lock immediately before creating a new one. strace will show you the lock file in question repeatedly with increasing backoff time as the new process repeatedly checks to see if the stale lock file has been deleted or whatever. So, delete the file (for example, /var/lock/LCK..ttyS0); you will own the lock file if you ran the application that crashed.
A random side note: if you are using QSerialPort in Python through PyQt5 (which does work, by the way!), be sure you have explicitly deleted the QSerialPort instance before the Python interpreter exits. If you're manipulating the port in IPython, then do "%xdel portobject" before exiting.
It's a dumb workaround, but provided you are using some other mechanism to ensure that you don't have two instances of your program running and using the same port - or if you simply don't care - you could have a line of code delete that lock file before opening the port.
IMHO, Qt shouldn't be emulating completely worthless Windows style nanny state protections in the first place. I can sudo rm -rf / and it happens! I can even rm the serial port. Given such unfettered, primal, god like power, I should be able to open a serial port whenever and however I please...