Billy, here is the problem. If you are planning to distribute files on a network, this presumes that you are sending them to another computer. If you give a person the file to put on their computer somewhere, by implication the person will have not less than MODIFY permissions (if not FULL CONTROL). At that level, you cannot protect the files from having someone get into them. At most, you could password protect the files so as to encrypt them. However, unless you have taken suitable stops to block visibility of your DB's internal structure, they could just export everything to another blank DB and have tons of fun.
Search this forum for the topics of "Securing a database" and then see about implementing the protections described in those topics. In particular, if you see posts by isladogs, he has researched this topic heavily and has posted on it many times.
Now, the philosophy behind these suggestions: If someone wants to get into an Access database, they can. Notice I didn't qualify that? They can get in if they really want to. But you use the same theory for this as you do for hacker protection. A determined hacker can get it - but if you make it hard enough, they will look elsewhere for their fun. I.e., the trick is to make it not worth the extra effort.
Re-reading the second post, I realize there is a different interpretation. I have answered one of the possible interpretations. I'll address the other one.
If you worry about folks getting to your "original" files, don't distribute them. Set aside a public location on the net as the "repository" for the public copies of the files. Never put the private copies (master design copies) in harm's way. This is good for another reason. You should ALWAYS keep separate, private copies of any project in a private area, a totally different folder.
On the server we used for my biggest project, I had five folders: PROD, TEST, DEV, STAGING, and HISTORY. Users had access to PROD but only three people had access to the other folders. I would develop in DEV, test in TEST, and promote the new release through STAGING to the PROD folder. I would copy the old PROD copy of the DB to HISTORY before promoting the new copy from TEST. There would never be multiple copies or unsecured copies of the DB in PROD.
One thing I did at the last minute for each "promotion" was to never fully secure the DB until promotion time. When the tests were complete and the DB did what it needed to do, I copied that version to staging and finished the process of securing it. (Which included the stuff discussed in the FIRST part of this post.) Once I had the hardened version of the DB in staging, I did the archiving to the HISTORY folder and the promotion to the PROD folder, after which I cleaned up everything.