Can I use SQLite to share data among different applications?
Yes.

From the FAQ:


  Can multiple applications or multiple instances of the same application access a single database file at the same time?
  
  Multiple processes can have the same database open at the same time.
  Multiple processes can be doing a SELECT at the same time. But only
  one process can be making changes to the database at any moment in
  time, however.
  
  SQLite uses reader/writer locks to control access to the database.
  (Under Win95/98/ME which lacks support for reader/writer locks, a
  probabilistic simulation is used instead.) But use caution: this
  locking mechanism might not work correctly if the database file is
  kept on an NFS filesystem. This is because fcntl() file locking is
  broken on many NFS implementations. You should avoid putting SQLite
  database files on NFS if multiple processes might try to access the
  file at the same time. On Windows, Microsoft's documentation says that
  locking may not work under FAT filesystems if you are not running the
  Share.exe daemon. People who have a lot of experience with Windows
  tell me that file locking of network files is very buggy and is not
  dependable. If what they say is true, sharing an SQLite database
  between two or more Windows machines might cause unexpected problems.
  
  We are aware of no other embedded SQL database engine that supports as
  much concurrency as SQLite. SQLite allows multiple processes to have
  the database file open at once, and for multiple processes to read the
  database at once. When any process wants to write, it must lock the
  entire database file for the duration of its update. But that normally
  only takes a few milliseconds. Other processes just wait on the writer
  to finish then continue about their business. Other embedded SQL
  database engines typically only allow a single process to connect to
  the database at once.
  
  However, client/server database engines (such as PostgreSQL, MySQL, or
  Oracle) usually support a higher level of concurrency and allow
  multiple processes to be writing to the same database at the same
  time. This is possible in a client/server database because there is
  always a single well-controlled server process available to coordinate
  access. If your application has a need for a lot of concurrency, then
  you should consider using a client/server database. But experience
  suggests that most applications need much less concurrency than their
  designers imagine.
  
  When SQLite tries to access a file that is locked by another process,
  the default behavior is to return SQLITE_BUSY. You can adjust this
  behavior from C code using the sqlite3_busy_handler() or
  sqlite3_busy_timeout() API functions.