This is not a problem unless your DB is not set to auto grow. So your DB exists on the file system in two files (a .MDF file that contains the data and a .LDF file that is used for logging/recovery). The space available is merely telling you how much empty space is in the file. If auto grow is set (by default it is) to say 10% then when the remaining space in the file is used if the file was say 100 MB in size it would automatically grow the file to 110 MB (pre-allocating blank space for the file in the file system). The 4 GB limitation you mentioned is on how large the file will grow so if you are using the free version of SQL it will not allow the .MDF or the .LDF to autogrow past 4 GB in size.
When you "shrink" a database it simply de-allocates white space in the file. So if you had a 1 GB .MDF file but only 100 MB of space was actually being used you could shrink the database and recover much of that space; however, if you shrink to often or to much this can lead to performance issues because if that space is needed and autogrow is enabled the file will simply re-grow again. For this reason you should only shrink the DB if for some reason the size got out of hand for example because you never purge old data from the DB. Essentially if you have proper maintenance setup on the DB that purges old data out you should never have to shrink the DB.
Thanks a lot, jistanley. You are right! I got the same answer from Google.