[IANAL, the following is not legal advice]
On Fri, Mar 24, 2017 at 9:03 PM, Lukas Fleischer
Let us start with the ToS:
* Introduction saying that using the service means accepting the terms. * Liability clause, say that users are responsible for uploaded content. * Forbid to upload unlawful, harmful or copyrighted content. * Explicitly forbid illegal software copies and malware. * Licensing of things uploaded to the AUR. * Notes on what happens when the ToS are changed. * Notes on what happens when the AUR is shut down.
Things that should be covered in the Privacy Statement:
* What kind of personal information we collect and where it is stored. * How the information is used. * Notes on what happens when there are changes to the Privacy Statement.
A privacy policy and terms of service should definitely be separate. The privacy policy should be an informational document for users and visitors, which details just like you said what personal information is collected, what tracking information is collected, IP addresses, server logs, etc; how long that information is retained, whether it's shared with anyone (directly or indirectly as part of some third party web service usage...), and so on. The privacy policy is not a document users generally need to *agree to* as it's informational only, but it is safe to have a clause in the TOS requiring users to say they have read and understood the privacy policy. To add to the terms of service: 1. A DMCA policy. It's already policy afaik that copyrighted assets cannot be distributed on the AUR. I invite you to set up dmca@archlinux.org and enact a policy similar to this one: https://github.com/HearthSim/legal/blob/master/TERMS.md#9-digital-millennium... It doesn't *have* to be part of the terms of service (users don't need to agree to it), it can be a separate document, but it often is and I highly recommend taking care of that at the same time regardless while you're taking care of legal documents, as it's bound to come up at some point. 2. Ensure that any user input (including comments, package metadata etc) is covered under the TOS. TOS documents generally have very broad wording which cover essentially everything the user can put into a site, so that you don't have to change the terms every time a new feature is added to the AUR. 3. Ensure that there are usage limits for the API, crawling the site, etc. Clearly state that users can be banned if they are found to be acting maliciously or abusively. 4. Ensure volunteer staff, trusted users etc are not liable for the actions of users. The TOS should protect Arch Linux and all its volunteers and/or paid staff.
Am I missing anything? It would be awesome to have some volunteer writing a first draft of these two documents. Preferably somebody who is a native speaker and has *some* experience with this kind of legal stuff. If nobody else steps up, I will give it a try myself even though I have neither of these two requirements/skills. It might also be helpful to look for some (public domain) templates of sentences we might reuse.
I can't afford the time to write one, but I can volunteer some to review drafts. Starting from an existing document is a good idea - I highly recommend the Auttomatic Terms of Service: https://en.wordpress.com/tos/ They are CC-BY-SA, very reasonable and apply quite nicely to Arch. Strike the sections that don't apply, rewrite the ones that do. Additionally, I HIGHLY recommend this to be a general document that applies not just to the AUR but to the Arch Linux web properties. You can have users only agree to it when using the AUR if you wish, but it's very useful to have a single policy and not deal with a dozen different ones. I would recommend enacting them for the arch forums as well, FWIW.
As mentioned in the other thread, we should also agree on whether we want the final terms be checked by a lawyer.
YES. Get the document reviewed by a lawyer, 100%. This is a document that should/will legally protect Arch and the people involved in Arch. Make sure it's good.
Regards, Lukas
[1] https://lists.archlinux.org/pipermail/arch-dev-public/2017-March/028726.html
J. Leclanche