├── 0000-template.md ├── 0005-private-communities.md ├── 0008-plugins.md ├── README.md ├── 0004-post-tags.md └── LICENSE /0000-template.md: -------------------------------------------------------------------------------- 1 | - Feature Name: (fill me in with a unique ident, `my_awesome_feature`) 2 | - Start Date: (fill me in with today's date, YYYY-MM-DD) 3 | - RFC PR: [LemmyNet/rfcs#0000](https://github.com/LemmyNet/rfcs/pull/0000) 4 | - Lemmy Issue: [LemmyNet/lemmy#0000](https://github.com/LemmyNet/lemmy/issues/0000) 5 | 6 | # Summary 7 | 8 | One paragraph explanation of the feature. 9 | 10 | # Motivation 11 | 12 | Why are we doing this? What use cases does it support? What is the expected outcome? 13 | 14 | # Guide-level explanation 15 | 16 | Explain the proposal as if it was already included in Lemmy and you were teaching it to another user. That generally means: 17 | 18 | - Explaining the feature largely in terms of examples. 19 | - Explaining how Lemmy users should *think* about the feature, and how it should impact the way they use Lemmy. It should explain the impact as concretely as possible. 20 | - For policy RFCs, this section should provide an example-driven introduction to the policy, and explain its impact in concrete terms. 21 | 22 | # Reference-level explanation 23 | 24 | This is the technical portion of the RFC. Explain the design in sufficient detail that: 25 | 26 | - Its interaction with other features is clear. 27 | - It is reasonably clear how the feature would be implemented. 28 | - Corner cases are dissected by example. 29 | 30 | The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. 31 | 32 | In particular explain the following, if applicable: 33 | 34 | - Which database changes are necessary? 35 | - How does the HTTP API change? 36 | - How does the new feature work over federation? Are there similar features in other Fediverse platforms which should be compatible? Also see the [federation docs](https://join-lemmy.org/docs/contributors/05-federation.html). 37 | 38 | # Drawbacks 39 | 40 | Why should we *not* do this? 41 | 42 | # Rationale and alternatives 43 | 44 | - Why is this design the best in the space of possible designs? 45 | - What other designs have been considered and what is the rationale for not choosing them? 46 | - What is the impact of not doing this? 47 | - Could this change be implemented in an external project instead? How much complexity does it add? 48 | 49 | # Prior art 50 | 51 | Discuss prior art, both the good and the bad, in relation to this proposal. 52 | A few examples of what this can include are: 53 | 54 | - Does this feature exist in other social media platforms and what experience have their community had? 55 | - Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background. 56 | 57 | This section is intended to encourage you as an author to think about the lessons from other social networks, provide readers of your RFC with a fuller picture. 58 | If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other languages. 59 | 60 | Note that while precedent set by other social networks is some motivation, it does not on its own motivate an RFC. 61 | 62 | # Unresolved questions 63 | 64 | - What parts of the design do you expect to resolve through the RFC process before this gets merged? 65 | - What parts of the design do you expect to resolve through the implementation of this feature before stabilization? 66 | - What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? 67 | 68 | # Future possibilities 69 | 70 | Think about what the natural extension and evolution of your proposal would 71 | be and how it would affect the language and project as a whole in a holistic 72 | way. Try to use this section as a tool to more fully consider all possible 73 | interactions with the project in your proposal. 74 | 75 | This is also a good place to "dump ideas", if they are out of scope for the 76 | RFC you are writing but otherwise related. 77 | 78 | If you have tried and cannot think of any future possibilities, 79 | you may simply state that you cannot think of anything. 80 | 81 | Note that having something written down in the future-possibilities section 82 | is not a reason to accept the current or a future RFC; such notes should be 83 | in the section on motivation or rationale in this or subsequent RFCs. 84 | The section merely provides additional information. 85 | -------------------------------------------------------------------------------- /0005-private-communities.md: -------------------------------------------------------------------------------- 1 | - Feature Name: Private Communities 2 | - Start Date: 2024-02-15 3 | - RFC PR: [LemmyNet/rfcs#0005](https://github.com/LemmyNet/rfcs/pull/5) 4 | - Lemmy Issue: [LemmyNet/lemmy#187](https://github.com/LemmyNet/lemmy/issues/187) 5 | 6 | ## Summary 7 | 8 | Lemmy is currently limited to public communities with public content. This RFC proposes a way to implement private, federated communities where only approved users can read and write. 9 | 10 | ## Motivation 11 | 12 | Private spaces are a fundamental aspect of human communication. They allow discussing sensitive topics without interruption from outsiders. Supporting private communities in Lemmy gives a major new use case for talking among friends or within organizations. This use case is currently not covered by major Fediverse projects. 13 | 14 | ## Detailed design 15 | 16 | The functionality requires only minor changes to the existing community implementation. The community profile with sidebar, icon etc remains public, so that anyone can follow the community. When a follow request is received, it needs to be manually approved by a moderator, using an interface similar to the existing registration applications. Posts and comments inside a private community are only visible to approved followers. 17 | 18 | This change is in some ways similar to [Local-only communities](https://github.com/LemmyNet/lemmy/pull/4350). That PR can be used as a reference for parts of code which need to be changed. 19 | 20 | ## Database 21 | 22 | The `CommunityVisibility` enum used in `community.visibility` gets a new variant `Private`. Queries in `post_view.rs` and `comment_view.rs` need to be adjusted so that content in communities set to private is only shown to followers. This also needs to be covered by unit tests. 23 | 24 | ## API 25 | 26 | When a new follow request for a local private community is made, it needs to set `pending = true`. Moderators can review and approve/reject pending follows with the following endpoints: 27 | - `GET /api/v3/community/pending_follows/count` 28 | - `GET /api/v3/community/pending_follows/list` 29 | - `POST /api/v3/community/pending_follows/approve` 30 | 31 | The follow_request list for each item should contain a boolean value `is_new_instance`. This value should be true if the community has no followers from the user's instance yet, and allows showing a warning when content will be federated to a new server. 32 | 33 | Once the approve endpoint is called, the follow request can be deleted. If the request was approved, write the follow relation to `community_follower`. If it was rejected, we could notify the user about this (optional). 34 | 35 | Users who don't follow the private community need to be prevented from posting or making other actions in it. This can be done by adding a check in [check_community_user_action()](https://github.com/LemmyNet/lemmy/blob/main/crates/api_common/src/utils.rs#L171). 36 | 37 | When [processing mentions](https://github.com/LemmyNet/lemmy/blob/main/crates/utils/src/utils/mention.rs#L24), the code needs to check if it is inside a private community, and in that case ignore mentions of users which don't follow it. 38 | 39 | The new endpoints should be covered by [Typescript API tests](https://github.com/LemmyNet/lemmy/tree/main/api_tests). 40 | 41 | ## Federation 42 | 43 | When a `Follow` activity is received, Lemmy currently automatically responds with an `Accept`. This needs to be changed so that private communities only store the pending follow in the database, without sending an `Accept`. Once a moderator approves the request, send an `Accept` to the user. Note that only moderators registered on the same instance as the community will see follow requests. 44 | 45 | The `Group` actor for private communities remains public and can be fetched without restrictions, so that remote users can fetch it and follow it. It needs a new attribute to indicate that the group is not public. We can use `manuallyApprovesFollowers: true` which is supported by many existing platforms including Mastodon. 46 | 47 | With Activitypub federation there are two ways instances can communicate with each other: Fetch data via HTTP GET, or POST an activity to the inbox. Activities are only sent to approved followers, so we don't need to worry about leaking any private data. However the fetching needs adjustments. For this we can use authorized fetch, which is already [implemented behind a setting](https://github.com/LemmyNet/lemmy/blob/main/src/lib.rs#L182). The simplest solution here is to remove the setting and sign all all outgoing requests, so we don't have to track which specific objects require auth or not. 48 | 49 | On the server side we need to verify the signature when an object gets fetched in a private community. The code for this is [here](https://github.com/LemmyNet/lemmy/blob/main/crates/apub/src/http/post.rs), [here](https://github.com/LemmyNet/lemmy/blob/main/crates/apub/src/http/comment.rs) and [here](https://github.com/LemmyNet/lemmy/blob/main/crates/apub/src/http/community.rs#L76). The logic for signature verification is [implemented in the activitypub-federation crate](https://github.com/LemmyNet/activitypub-federation-rust/blob/main/src/http_signatures.rs#L146), but not yet part of the public API. 50 | 51 | Like in the API code we need to ensure that only followers can perform actions in private communities. Here a check needs to be added to [verify_person_in_community()](https://github.com/LemmyNet/lemmy/blob/main/crates/apub/src/activities/mod.rs#L77). 52 | 53 | [Objects](https://github.com/LemmyNet/lemmy/blob/main/crates/apub/src/objects/post.rs#L127) and [activities](https://github.com/LemmyNet/lemmy/blob/main/crates/apub/src/activities/create_or_update/post.rs#L53) are currently marked as public, we need to get rid of this in private communities. Additionally, the method [verify_is_public()](https://github.com/LemmyNet/lemmy/blob/main/crates/apub/src/activities/mod.rs#L127) needs to take community visibility into account. If the community is public, reject any non-public content (just like now). if it is private, reject any public content. 54 | 55 | ## RSS 56 | 57 | The community RSS feed needs to be adjusted to avoid leaking private content. The easiest solution is to disable it for private communities, but it would also be possible to serve private community feeds with authentication, similar to the existing subscribed feed. 58 | 59 | Other feed types need to exclude any content from private communities. This should already be handled by changes to `post_view.rs` 60 | 61 | ## Frontends and Apps 62 | 63 | Community moderators need to get access to the new `community.visibility` setting in the sidebar. Community visibility should also be indicated to users. 64 | 65 | Frontends need to show an interface for moderators to approve new followers. This can likely reuse much of the code from registration applications, and use the endpoints described under "API". When `is_new_instance` is true on a given application, show a warning similar to the following before approving: 66 | 67 | > Warning: This is the first follower from example.com. After approval, the admin of example.com is technically able to access all past and future content in this community. It is also possible that the instance at example.com makes community posts publicly available. If the community has sensitive content, make sure to only approve followers from trusted instances. 68 | 69 | ## Alternatives 70 | 71 | The only alternative would be not to implement this feature in Lemmy, and rely on different platforms for private communities instead. Considering that Lemmy already has a large number of users and many important features, it is better to provide this feature directly. 72 | 73 | ## Unresolved questions 74 | 75 | Images in private communities are publicly available for anyone who knows the url. This is probably fine as image URLs are long and randomized, so they are impossible to guess. 76 | 77 | When setting an existing community to private, this setting will generally also federate to other instances. However it is possible that some instances don't refetch the community, and old content remains public. And of course old content can be stored in external archives. This problem could be avoided by preventing existing, public communities to be marked as private. 78 | 79 | In a public community, old content missing from your instance can be fetched by visiting the community on its home instance and copying the URL of individual posts and comments into your own instance's search field to fetch them. This is not easily possible with a private community, as it cannot be viewed publicly. However this is a general problem with Lemmy communities and can be handled separately. 80 | 81 | ## Further Work 82 | 83 | In addition to the described private communities, we can implement semi-private communities. These would require the same approval process for joining and posting, however all content in semi-private communities would be public. It would be useful to allow public conversations between trusted users. 84 | -------------------------------------------------------------------------------- /0008-plugins.md: -------------------------------------------------------------------------------- 1 | - Feature Name: plugins 2 | - Start Date: 2024-12-02 3 | - RFC PR: [LemmyNet/rfcs#0008](https://github.com/LemmyNet/rfcs/pull/0008) 4 | - Lemmy Issue: [LemmyNet/lemmy#3562](https://github.com/LemmyNet/lemmy/issues/3562) 5 | 6 | # Summary 7 | 8 | Implement a plugin system for Lemmy based on Webassembly. 9 | 10 | # Motivation 11 | 12 | Plugins will make Lemmy more flexible, and allow implementing features which are too niche for merging into Lemmy core. It will allow Lemmy to focus on core features, while allowing outside developers to contribute new features without using Rust. 13 | 14 | # Guide-level explanation 15 | 16 | ## Extism 17 | 18 | [Extism](https://extism.org/) is an open source framework to develop plugins for Rust projects. It supports numerous different languages by compiling them to webassembly which gets called from Rust. 19 | 20 | # Reference-level explanation 21 | 22 | ## File Structure 23 | 24 | Each plugin consists of two files, a [manifest](https://extism.org/docs/concepts/manifest) and the actual wasm binary. The manifest specifies how to load the binary, and provides various configuration options. Plugins are loaded at startup from `./plugins/` or `LEMMY_PLUGIN_PATH`. Each plugin must have a `metadata` hook returning data in the format below, which is listed in a new field `active_plugins` under `/api/v4/site`. 25 | 26 | ```json 27 | { 28 | "name": "My Plugin", 29 | "url": "http://example.com/plugin-info", 30 | "description": "Plugin which does the thing" 31 | } 32 | ``` 33 | 34 | ## Plugin Hooks 35 | 36 | Lemmy will have hooks for specific actions which can then be used by plugins. In general there are two types of hooks: before an action is written to the database, so it can be rejected or altered. And after it is written to the database, mainly for different types of notifications. 37 | 38 | Whenever a plugin hook is called, Lemmy blocks the API call until the plugin returns. This means that slow plugins can result in slow API actions for users, or delays for incoming federation. To avoid such problems, plugin developers should optimize their code to return as fast as possible, and perform expensive operations or network calls in a background thread. 39 | 40 | Data is passed to plugins using the existing structs linked below, serialized to JSON. Additionally plugins can retrieve [config values](https://github.com/extism/go-pdk?tab=readme-ov-file#configs) `lemmy_version` (e.g. `0.19.8`) and `lemmy_url` (e.g. `http://localhost:8536/`), in order to retrieve data or perform further actions via Lemmy API. 41 | 42 | For the initial implementation, the following hooks will be available: 43 | 44 | ### Before writing to Database 45 | 46 | These hooks can be used to reject or alter user actions based on different criteria. 47 | 48 | - Post 49 | - `before_create_local_post` (with [PostInsertForm](https://github.com/LemmyNet/lemmy/blob/main/crates/db_schema/src/source/post.rs#L101)) 50 | - `before_update_local_post` (with [PostUpdateForm](https://github.com/LemmyNet/lemmy/blob/main/crates/db_schema/src/source/post.rs#L150)) 51 | - `before_receive_federated_post` (with [PostInsertForm](https://github.com/LemmyNet/lemmy/blob/main/crates/db_schema/src/source/post.rs#L101)) 52 | - Comment 53 | - `before_create_local_comment` (with [CommentInsertForm](https://github.com/LemmyNet/lemmy/blob/main/crates/db_schema/src/source/comment.rs#L68)) 54 | - `before_update_local_comment` (with [CommentUpdateForm](https://github.com/LemmyNet/lemmy/blob/main/crates/db_schema/src/source/comment.rs#L93)) 55 | - `before_receive_federated_comment` (with [CommentInsertForm](https://github.com/LemmyNet/lemmy/blob/main/crates/db_schema/src/source/comment.rs#L68)) 56 | - Votes 57 | - `before_post_vote` (with [PostLikeForm](https://github.com/LemmyNet/lemmy/blob/main/crates/db_schema/src/source/post.rs#L215)) 58 | - `before_comment_vote` (with [CommentLikeForm](https://github.com/LemmyNet/lemmy/blob/main/crates/db_schema/src/source/comment.rs#L133)) 59 | - Private Message 60 | - `before_create_local_private_message` (with [PrivateMessageInsertForm](https://github.com/LemmyNet/lemmy/blob/main/crates/db_schema/src/source/comment.rs#L116)) 61 | - `before_update_local_private_message` (with [PrivateMessageUpdateForm](https://github.com/LemmyNet/lemmy/blob/main/crates/db_schema/src/source/private_message.rs#L63)) 62 | - `before_receive_federated_private_message` (with [PrivateMessageInsertForm](https://github.com/LemmyNet/lemmy/blob/main/crates/db_schema/src/source/comment.rs#L116)) 63 | 64 | ### After writing to Database 65 | 66 | These are mainly useful to generate notifications. 67 | 68 | - Post (all with [Post](https://github.com/LemmyNet/lemmy/blob/0.19.7/crates/db_schema/src/source/post.rs#L18)) 69 | - `after_create_local_post` 70 | - `after_update_local_post` 71 | - `after_receive_federated_comment` 72 | - Comment (all with [Comment](https://github.com/LemmyNet/lemmy/blob/0.19.7/crates/db_schema/src/source/comment.rs#L26)) 73 | - `after_create_local_comment` 74 | - `after_update_local_comment` 75 | - `after_receive_federated_post` 76 | - Votes 77 | - `after_post_vote` (with [PostActions](https://github.com/LemmyNet/lemmy/blob/main/crates/db_schema/src/source/post.rs#L185)) 78 | - `after_comment_vote` (with [CommentActions](https://github.com/LemmyNet/lemmy/blob/main/crates/db_schema/src/source/comment.rs#L116)) 79 | - Private Message (all with [PrivateMessage](https://github.com/LemmyNet/lemmy/blob/0.19.7/crates/db_schema/src/source/private_message.rs#L25)) 80 | - `after_create_local_private_message` 81 | - `after_update_local_private_message` 82 | - `after_receive_federated_private_message` 83 | 84 | ## Example 85 | 86 | Below is a simple Go plugin which uses the `before_create_local_post` hook to replace `Rust` in post body with `Go`, and reject posts which mention `Java`. 87 | 88 | Also checkout the documentation for Extism's [Go Plugin Development Kit](https://github.com/extism/go-pdk). 89 | 90 | ```golang 91 | package main 92 | 93 | import ( 94 | "github.com/extism/go-pdk" 95 | "errors" 96 | "strings" 97 | ) 98 | 99 | type Metadata struct { 100 | Name string `json:"name"` 101 | Url string `json:"url"` 102 | Description string `json:"description"` 103 | } 104 | 105 | // Returns info about the plugin which gets included in /api/v4/site 106 | //go:wasmexport metadata 107 | func metadata() int32 { 108 | metadata := Metadata { 109 | Name: "Test Plugin", 110 | Url: "https://example.com", 111 | Description: "Plugin to test Lemmy feature", 112 | } 113 | err := pdk.OutputJSON(metadata) 114 | if err != nil { 115 | pdk.SetError(err) 116 | return 1 117 | } 118 | return 0 119 | } 120 | 121 | // This hook gets called when a local user creates a new post 122 | //go:wasmexport before_create_local_post 123 | func create_local_post() int32 { 124 | // Load user parameters into a map, to make sure we return all the same fields later 125 | // and dont drop anything 126 | params := make(map[string]interface{}) 127 | err := pdk.InputJSON(¶ms) 128 | if err != nil { 129 | pdk.SetError(err) 130 | return 1 131 | } 132 | 133 | // Dont allow any posts mentioning Java in title 134 | // (these will throw an API error and not be written to the database) 135 | name := params["name"].(string) 136 | if strings.Contains(name, "Java") { 137 | // Throw error to reject post 138 | pdk.SetError(errors.New("We dont talk about Java")) 139 | return 1 140 | } 141 | 142 | // Replace all occurences of "Rust" in post title with "Go" 143 | params["name"] = strings.Replace(name, "Rust", "Go", -1); 144 | 145 | err = pdk.OutputJSON(params) 146 | if err != nil { 147 | pdk.SetError(err) 148 | return 1 149 | } 150 | return 0 151 | } 152 | ``` 153 | 154 | You can see more examples in different languages in the [lemmy-plugins](https://github.com/LemmyNet/lemmy-plugins) repo. 155 | 156 | ## Licensing 157 | 158 | Plugins can use any [OSI-approved open source licenses](https://opensource.org/licenses). Unlike Lemmy's AGPL license, most of them don't require sharing the source code with people who use it over a network, so the source code only needs to be made available to server admins. This also allows for for paid plugins. 159 | 160 | # Drawbacks 161 | 162 | Plugins may have a performance impact as described above. It is up to plugin developers and instance admins to ensure that plugins run adequately. In any case plugins are only called for POST actions but not for GET. This means slow plugins might result in longer waiting time to submit posts, but passive browsing will be unaffected. 163 | 164 | # Rationale and alternatives 165 | 166 | The alternative would be to implement all possible functionality directly in the Lemmy backend. This is not always desirable because features may only be desired by a small fraction of users. Additionally Lemmy code can only be written in Rust, while plugins can use many different languages. 167 | 168 | # Prior art 169 | 170 | Plugins for other Fediverse platforms: 171 | 172 | - https://docs.joinpeertube.org/contribute/plugins 173 | - https://github.com/friendica/friendica-addons 174 | - https://codeberg.org/hubzilla/hubzilla-addons 175 | - https://nextcloud.github.io/news/features/plugins/ 176 | - https://developer.wordpress.org/plugins/ 177 | 178 | # Unresolved questions 179 | 180 | # Future possibilities 181 | 182 | In the future we can add hooks for other user actions, such as voting or uploading images. We could also support implementing new post ranking algorithms in plugins. 183 | 184 | Additionally it should be possible for plugins to define new API routes for additional functionality. 185 | 186 | We may also consider to move some existing features into plugins. This applies to features which are mostly separate from core functionality, and which are only used by few instances. For example: 187 | 188 | - Slur filter 189 | - Custom emojis 190 | - Taglines 191 | 192 | In the opposite way, popular plugins may be shipped as part of Lemmy releases, or reimplemented as part of Lemmy core. 193 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Lemmy RFCs 2 | 3 | The "RFC" (request for comments) process is intended to provide a consistent 4 | and controlled path for changes to Lemmy (such as new features) so that all 5 | stakeholders can be confident about the direction of the project. 6 | 7 | Many changes, including bug fixes and documentation improvements can be 8 | implemented and reviewed via the normal GitHub pull request workflow. 9 | 10 | Some changes though are "substantial", and we ask that these be put through a 11 | bit of a design process and produce a consensus among the Lemmy community. 12 | 13 | ## Table of Contents 14 | 15 | - [When you need to follow this process] 16 | - [Before creating an RFC] 17 | - [What the process is] 18 | - [The RFC life-cycle] 19 | - [Reviewing RFCs] 20 | - [Implementing an RFC] 21 | - [RFC Postponement] 22 | - [Help this is all too informal!] 23 | - [License] 24 | 25 | 26 | ## When you need to follow this process 27 | [When you need to follow this process]: #when-you-need-to-follow-this-process 28 | 29 | You need to follow this process if you intend to make "substantial" changes to 30 | the Lemmy backend, or the RFC process itself. What constitutes a 31 | "substantial" change is evolving based on community norms and varies depending 32 | on what part of the ecosystem you are proposing to change, but may include the 33 | following. 34 | 35 | - Complex new features which cannot be specified adequately in an issue. 36 | 37 | Some changes do not require an RFC: 38 | 39 | - Rephrasing, reorganizing, refactoring, or otherwise "changing shape does 40 | not change meaning". 41 | - Additions that strictly improve objective, numerical quality criteria 42 | (warning removal, speedup, better platform coverage, more parallelism, trap 43 | more errors, etc.) 44 | 45 | If you submit a pull request to implement a major new feature without going through 46 | the RFC process, it may be closed with a polite request to submit an RFC first. 47 | 48 | ## Before creating an RFC 49 | [Before creating an RFC]: #before-creating-an-rfc 50 | 51 | A hastily-proposed RFC can hurt its chances of acceptance. Low quality 52 | proposals, proposals for previously-rejected features, or those that don't fit 53 | into the near-term roadmap, may be quickly rejected, which can be demotivating 54 | for the unprepared contributor. Laying some groundwork ahead of the RFC can 55 | make the process smoother. 56 | 57 | Although there is no single way to prepare for submitting an RFC, it is 58 | generally a good idea to pursue feedback from other project developers 59 | beforehand, to ascertain that the RFC may be desirable; having a consistent 60 | impact on the project requires concerted effort toward consensus-building. 61 | 62 | The most common preparations for writing and submitting an RFC include talking 63 | the idea over on our [official Zulip server], discussing the topic on our 64 | [developer discussion forum], and occasionally posting "pre-RFCs" on the 65 | developer forum. You may file issues on this repo for discussion, but these are 66 | not actively looked at by the teams. 67 | 68 | As a rule of thumb, receiving encouraging feedback from long-standing project 69 | developers is a good indication that the RFC is worth pursuing. 70 | 71 | 72 | ## What the process is 73 | [What the process is]: #what-the-process-is 74 | 75 | In short, to get a major feature added to Lemmy, one must first get the RFC 76 | merged into the RFC repository as a markdown file. At that point the RFC is 77 | "active" and may be implemented with the goal of eventual inclusion into Lemmy. 78 | 79 | - Fork the RFC repo [RFC repository] 80 | - Copy `0000-template.md` to `text/0000-my-feature.md` (where "my-feature" is 81 | descriptive). Don't assign an RFC number yet; This is going to be the PR 82 | number and we'll rename the file accordingly if the RFC is accepted. 83 | - Fill in the RFC. Put care into the details: RFCs that do not present 84 | convincing motivation, demonstrate lack of understanding of the design's 85 | impact, or are disingenuous about the drawbacks or alternatives tend to 86 | be poorly-received. 87 | - Submit a pull request. As a pull request the RFC will receive design 88 | feedback from the larger community, and the author should be prepared to 89 | revise it in response. 90 | - Now that your RFC has an open pull request, use the issue number of the PR 91 | to update your `0000-` prefix to that number. 92 | - Build consensus and integrate feedback. RFCs that have broad support are 93 | much more likely to make progress than those that don't receive any 94 | comments. Feel free to reach out to the RFC assignee in particular to get 95 | help identifying stakeholders and obstacles. 96 | - Maintainers will discuss the RFC pull request, as much as possible in the 97 | comment thread of the pull request itself. Offline discussion will be 98 | summarized on the pull request comment thread. 99 | - RFCs rarely go through this process unchanged, especially as alternatives 100 | and drawbacks are shown. You can make edits, big and small, to the RFC to 101 | clarify or change the design, but make changes as new commits to the pull 102 | request, and leave a comment on the pull request explaining your changes. 103 | Specifically, do not squash or rebase commits after they are visible on the 104 | pull request. 105 | - At some point, a maintainer will propose a "motion for final 106 | comment period" (FCP), along with a *disposition* for the RFC (merge, close, 107 | or postpone). 108 | - This step is taken when enough of the tradeoffs have been discussed that 109 | maintainers are in a position to make a decision. That does not require 110 | consensus amongst all participants in the RFC thread (which is usually 111 | impossible). However, the argument supporting the disposition on the RFC 112 | needs to have already been clearly articulated, and there should not be a 113 | strong consensus *against* that position. Maintainers use their best judgment 114 | in taking this step, and the FCP itself ensures there is ample time and 115 | notification for stakeholders to push back if it is made prematurely. 116 | - For RFCs with lengthy discussion, the motion to FCP is usually preceded by 117 | a *summary comment* trying to lay out the current state of the discussion 118 | and major tradeoffs/points of disagreement. 119 | - Before actually entering FCP, *all* maintainers must sign off; 120 | this is often the point at which many maintainers first review the 121 | RFC in full depth. 122 | - The FCP lasts ten calendar days, so that it is open for at least 5 business 123 | days. It is also advertised widely, 124 | e.g. in [/c/lemmy](https://lemmy.ml/c/lemmy). This way all 125 | stakeholders have a chance to lodge any final objections before a decision 126 | is reached. 127 | - In most cases, the FCP period is quiet, and the RFC is either merged or 128 | closed. However, sometimes substantial new arguments or ideas are raised, 129 | the FCP is canceled, and the RFC goes back into development mode. 130 | 131 | ## The RFC life-cycle 132 | [The RFC life-cycle]: #the-rfc-life-cycle 133 | 134 | Once an RFC becomes "active" then authors may implement it and submit the 135 | feature as a pull request to the Lemmy repo. Being "active" is not a rubber 136 | stamp, and in particular still does not mean the feature will ultimately be 137 | merged; it does mean that in principle all the major stakeholders have agreed 138 | to the feature and are amenable to merging it. 139 | 140 | Furthermore, the fact that a given RFC has been accepted and is "active" 141 | implies nothing about what priority is assigned to its implementation, nor does 142 | it imply anything about whether a Lemmy developer has been assigned the task of 143 | implementing the feature. While it is not *necessary* that the author of the 144 | RFC also write the implementation, it is by far the most effective way to see 145 | an RFC through to completion: authors should not expect that other project 146 | developers will take on responsibility for implementing their accepted feature. 147 | 148 | Modifications to "active" RFCs can be done in follow-up pull requests. We 149 | strive to write each RFC in a manner that it will reflect the final design of 150 | the feature; but the nature of the process means that we cannot expect every 151 | merged RFC to actually reflect what the end result will be at the time of the 152 | next major release. 153 | 154 | In general, once accepted, RFCs should not be substantially changed. Only very 155 | minor changes should be submitted as amendments. More substantial changes 156 | should be new RFCs, with a note added to the original RFC. Exactly what counts 157 | as a "very minor change" is up to the maintainers to decide. 158 | 159 | 160 | ## Reviewing RFCs 161 | [Reviewing RFCs]: #reviewing-rfcs 162 | 163 | While the RFC pull request is up, maintainers may schedule meetings with the 164 | author and/or relevant stakeholders to discuss the issues in greater detail, 165 | and in some cases the topic may be discussed in maintainer chat. In either 166 | case a summary from the meeting will be posted back to the RFC pull request. 167 | 168 | Maintainers make a final decisions about RFCs after the benefits and drawbacks 169 | are well understood. These decisions can be made at any time, but the maintainers 170 | will regularly issue decisions. When a decision is made, the RFC pull request 171 | will either be merged or closed. In either case, if the reasoning is not clear 172 | from the discussion in thread, the maintainers will add a comment describing the 173 | rationale for the decision. 174 | 175 | 176 | ## Implementing an RFC 177 | [Implementing an RFC]: #implementing-an-rfc 178 | 179 | Some accepted RFCs represent vital features that need to be implemented right 180 | away. Other accepted RFCs can represent features that can wait until some 181 | arbitrary developer feels like doing the work. Every accepted RFC has an 182 | associated issue tracking its implementation in the Lemmy repository; thus that 183 | associated issue can be assigned a priority via the triage process that the 184 | team uses for all issues in the Lemmy repository. 185 | 186 | The author of an RFC is not obligated to implement it. Of course, the RFC 187 | author (like any other developer) is welcome to post an implementation for 188 | review after the RFC has been accepted. 189 | 190 | If you are interested in working on the implementation for an "active" RFC, but 191 | cannot determine if someone else is already working on it, feel free to ask 192 | (e.g. by leaving a comment on the associated issue). 193 | 194 | 195 | ## RFC Postponement 196 | [RFC Postponement]: #rfc-postponement 197 | 198 | Some RFC pull requests are tagged with the "postponed" label when they are 199 | closed (as part of the rejection process). An RFC closed with "postponed" is 200 | marked as such because we want neither to think about evaluating the proposal 201 | nor about implementing the described feature until some time in the future, and 202 | we believe that we can afford to wait until then to do so. Historically, 203 | "postponed" was used to postpone features until after 1.0. Postponed pull 204 | requests may be re-opened when the time is right. We don't have any formal 205 | process for that, you should ask the maintainers. 206 | 207 | Usually an RFC pull request marked as "postponed" has already passed an 208 | informal first round of evaluation, namely the round of "do we think we would 209 | ever possibly consider making this change, as outlined in the RFC pull request, 210 | or some semi-obvious variation of it." (When the answer to the latter question 211 | is "no", then the appropriate response is to close the RFC, not postpone it.) 212 | 213 | 214 | ### Help this is all too informal! 215 | [Help this is all too informal!]: #help-this-is-all-too-informal 216 | 217 | The process is intended to be as lightweight as reasonable for the present 218 | circumstances. As usual, we are trying to let the process be driven by 219 | consensus and community norms, not impose more structure than necessary. 220 | 221 | 222 | ## License 223 | [License]: #license 224 | 225 | This repository is licensed under [AGPL](LICENSE). 226 | -------------------------------------------------------------------------------- /0004-post-tags.md: -------------------------------------------------------------------------------- 1 | - Feature Name: Post Tags 2 | - Start Date: 2023-11-04 3 | - RFC PR: [LemmyNet/rfcs#0004](https://github.com/LemmyNet/rfcs/pull/4) 4 | - Lemmy Issue: [LemmyNet/lemmy#317](https://github.com/LemmyNet/lemmy/issues/317) 5 | 6 | # Summary 7 | 8 | Ability to add descriptive tags to Posts similar to Reddit's Flair system primarily on a per-community basis. 9 | 10 | # Motivation 11 | 12 | Post Tags would allow for vastly improved content filtering (and to a lesser extent searching) both for Users and Admins/Moderators. 13 | 14 | # Guide-level explanation 15 | 16 | Tags grant you more fine grained control over the content you see on Lemmy. Certain users do not want to see certain content and tags allow you to do exactly that. 17 | 18 | For example a lot of communities offer mixed content such as Memes, News and Discussions. Some people would like to only see News or Discussions. In such a case they could blocklist (filter out) the "Meme" tag, going forward they would not be presented with any Memes in that community. 19 | 20 | Another use for tags is better handling of how posts are displayed. For example some people would like the content of a post to stay hidden for all users. This could be the case in a community focused on release discussions of Books, Movies, TV Shows or communities with content some users might find offensive but which is not neccesarily NSFW (for example jokes about certain topics). 21 | 22 | In order to ensure this consistency while filtering tags can only be created by privileged users, initially that is intended to be Admins and Community moderators. 23 | 24 | Essentially the tags serve as an easier way to message what is _inside_ the post. Combining multiple tags allows for even finer control. Made a post about news in poland? Add the "News" and "Poland" tags to it and people interested exclusively in polish news can find it easily or people not interested can avoid it just as easily. 25 | 26 | # Reference-level explanation 27 | 28 | ## Protocol: 29 | 30 | The [ActivityStreams vocabulary](https://www.w3.org/TR/activitystreams-vocabulary/#dfn-tags) defines that any object can have a list of tags associated with it. Tags in AS can be of any type, so we define our own type `CommunityPostTag`: 31 | 32 | ```jsonc 33 | { 34 | "type": "lemmy:CommunityPostTag", 35 | "id": "community-url/tag/tag-id", // e.g. https://example.org/c/example/tag/News 36 | "name": "Readable Name of Tag", 37 | } 38 | ``` 39 | 40 | In JSON-LD terms, this type will live in the lemmy namespace as `https://join-lemmy.org/ns#CommunityPostTag`), which in objects lemmy sends out is always imported from https://join-lemmy.org/context.json as the prefix `lemmy:`, so we can refer to it as `lemmy:CommunityPostTag`. For example, a lemmy post object (Page in AP terms) would look like this: 41 | 42 | ```json 43 | { 44 | "@context": [ 45 | "https://www.w3.org/ns/activitystreams", 46 | "https://join-lemmy.org/context.json" 47 | ], 48 | "id": "https://enterprise.lemmy.ml/post/55143", 49 | "type": "Page", 50 | "audience": "https://enterprise.lemmy.ml/c/tenforward", 51 | "name": "Post title", 52 | "content": "

This is a post in the /c/tenforward community

\n", 53 | "tag": [ 54 | { 55 | "type": "lemmy:CommunityPostTag", 56 | "id": "https://enterprise.lemmy.ml/c/tenforward/tag/news", 57 | "name": "News" 58 | } 59 | ] 60 | // ... more required props 61 | } 62 | ``` 63 | 64 | Entirely unmoderated tags are not an option for lemmy as the moderation workload would be too much. Additionally users being able to type out tags themselves introduces splintering in the tag contents due to typos. A better solution is a curated list of tags users can attach to their posts. The list of tags can be maintained by both admins and moderators allowing for each community to tailor tags to their specific needs. 65 | Content for tags would be located in the respective root: `https://example.org/c/example/tag/tag` 66 | 67 | The ID of a CommunityPostTag is a URL prefixed with `https://instance/c/community/tags/` and a user-chosen or generated (from the name) ID. The ID itself will rarely be user-visible, since the name is used there. 68 | 69 | For now tags will only be applicable to posts, however the general design allows for them to be attached to any kind of object later on, be that instance, community or user. The limited initial scope allows for easier modifications should any rough edges or missing features be discovered. 70 | Additionally per Tag Inheritance could be added by expanding on this structure, more details can be found in [Future Possibilities > Tag Inheritance](#tag-inheritance). 71 | 72 | Example Tag Objects: 73 | 74 | ```json 75 | { 76 | "type": "lemmy:CommunityPostTag", 77 | "url": "https://example.org/c/news/tag/newspaper-company-1", 78 | "name": "Related to Newspaper Company 1" 79 | } 80 | ``` 81 | 82 | ```json 83 | { 84 | "type": "lemmy:CommunityPostTag", 85 | "url": "https://example.org/c/news/tag/blood-gore", 86 | "name": "Blood/Gore" 87 | } 88 | ``` 89 | 90 | ```json 91 | { 92 | "type": "lemmy:CommunityPostTag", 93 | "url": "https://example.org/c/news/tag/news", 94 | "name": "News" 95 | } 96 | ``` 97 | 98 | Below is an example of a News post in the news community. The post has a communtiy tag for the newspaper company that published it, as well as a content warning for Blood/Gore. 99 | 100 | Example Post json: 101 | 102 | ```json 103 | { 104 | "@context": [ 105 | "https://www.w3.org/ns/activitystreams", 106 | "https://join-lemmy.org/context.json" 107 | ], 108 | "to": [ 109 | "https://example.org/c/news", 110 | "https://www.w3.org/ns/activitystreams#Public" 111 | ], 112 | "audience": "https://example.org/c/news", 113 | "content": ". . .", 114 | "sensitive": true, 115 | "tag": [ 116 | { 117 | "type": "lemmy:CommunityPostTag", 118 | "url": "https://example.org/c/news/tag/newspaper-company-1", 119 | "name": "Related to Newspaper Company 1" 120 | }, 121 | { 122 | "type": "lemmy:CommunityPostTag", 123 | "url": "https://example.org/c/news/tag/blood-gore", 124 | "name": "Blood/Gore" 125 | }, 126 | { 127 | "type": "lemmy:CommunityPostTag", 128 | "url": "https://example.org/c/news/tag/news", 129 | "name": "News" 130 | } 131 | ] 132 | } 133 | ``` 134 | 135 | ## Backend: 136 | 137 | I am not quite familiar with the Lemmy Backend so any corrections or additions for this section are appreciated. 138 | 139 | One new table for "community_post_tag" would be required: 140 | 141 | ```sql 142 | CREATE TABLE community_post_tag ( 143 | id serial PRIMARY KEY, 144 | community_id int REFERENCES community.id, 145 | ap_id text UNIQUE NOT NULL, 146 | name text NOT NULL, 147 | published timestamptz NOT NULL, 148 | deleted timestamptz NULL, 149 | ); 150 | ``` 151 | 152 | Additional columns for tag display style (for example background & text color) and hierarchy could be added later by extending this table. 153 | 154 | Additionally, a way to store the association between posts and tags is needed. This can either be done with a `tags: array[int]` column in the post table and a inverse index (`GIN` or `GIST`) or with a new table `post_tag (post_id, tag_id)` 155 | 156 | Instance Admins should have the option to delete/ban tags. 157 | Instances with nsfw disables/blocked could/should auto reject posts with an nsfw flavor tag. 158 | 159 | The following API routes will need to be added: 160 | 161 | **GET /api/v3/tag/list:** 162 | Parameters: 163 | 164 | - community_id (required) 165 | - auth (optional) 166 | 167 | Returns: 168 | List of all tags in a community. 169 | Deleted tags should not be returned in the list unless an admin/moderator. 170 | 171 | ```json 172 | { 173 | "tags": [ 174 | { 175 | "ap_id": "https://example.org/c/community/tag/foo", // activitypub id 176 | "name": "Foo Tag", 177 | "id": 1, // the lemmy-internal id 178 | "community_id": 1 // lemmy-internal community id 179 | }, 180 | {...} 181 | ] 182 | } 183 | ``` 184 | 185 | **POST /api/v3/tag/create:** 186 | Parameters: 187 | 188 | - id_slug // the generated url will be https://instance/c/community/tags/id_slug 189 | - name 190 | - community_id 191 | 192 | Returns: 193 | Object of freshly created tag 194 | 195 | **PUT /api/v3/tag:** 196 | 197 | Request to update tag object, see the post update API request. 198 | **POST /api/v3/tag/delete:** 199 | 200 | Request to delete tag object, see the post delete API request. 201 | 202 | **ActivityPub Endpoint: GET /c/community/tag/foo (Content-Type: application/activity+json)** 203 | 204 | This is the AP endpoint (not a lemmy api endpoint) and must contain the tag object response in JSON-LD: 205 | 206 | ```json 207 | { 208 | "@context": [ 209 | "https://join-lemmy.org/context.json", 210 | "https://www.w3.org/ns/activitystreams" 211 | ], 212 | "id": "https://example.org/c/community/tag/foo", // activitypub id 213 | "type": "lemmy:CommunityPostTag", 214 | "name": "Foo Tag" 215 | } 216 | ``` 217 | 218 | **Additionally:** 219 | 220 | Posts will need to be made editable by moderators, this is currently not possible but will be required to allow mods to fix missing or misused tags on posts. 221 | Ideally the endpoint that will be opened for this should only allow the addition or removal of tags from a post and nothing else to prevent abuse. 222 | As such I propose the use of: 223 | `POST /post/tag` and `POST /post/tag/delete` for these roles. 224 | Nesting these endpoints under the `/post` endpoint seems appropriate. 225 | Shared parameters would be authentication, `post_id` and `tag_id` with an additional `delete` parameter for the delete endpoint. 226 | 227 | Groups that should be able to add/edit the tags: 228 | 229 | - Instance Admins of the Community 230 | - Moderators of the Community 231 | - Post creator 232 | 233 | ## Frontend: 234 | 235 | **General Changes:** 236 | 237 | Tags can be listed next to the Post title in the feed and at the end of the post in the post view. 238 | Adding tags to a post can be implemented via a separate tag box where they can be typed in with search support. 239 | 240 | ![tags post view iamge](https://github.com/Neshura87/Lemmy-RFC/blob/main/tags_post_view.png?raw=true) 241 | 242 | Tags in the feed should be displayed next to the post interaction elements. 243 | ![tags feed view iamge](https://github.com/Neshura87/Lemmy-RFC/blob/main/tags_feed_view.png?raw=true) 244 | 245 | **Moderator Changes:** 246 | 247 | Moderators need a UI Section in the community settings for adding, edditing and deleting tags. This could also implement a way to "import" a tag from another instance. 248 | Moderators should also be able to add tags to user posts. 249 | 250 | # Drawbacks 251 | 252 | Adding the tag system would increase backend complexity, increased workload for alternative frontends and apps as well as add another barrier for full federation between lemmy and other services. On top of that the moderation workload would somewhat increase since posts would need to be checked for proper usage of tags as well. 253 | 254 | # Rationale and alternatives 255 | 256 | The proposed system aims to be a balance between the extremely limited flair feature of reddit and the often fragmented tag system of image hosting platforms, combining the best properties of both options into a theoretically ideal version of the system. Additionally the current system with a singular NSFW flag is far too inflexible to properly moderate the scope of content that falls under NSFW. Many instances have implemented a blanket NSFW ban because of this, greatly limiting what content can be posted where. Aside from that the inability to better sort content is a often discussed topic, especially story communities are desperately craving for a better option to both sort posts based on story association as well as hide/blur posts if they contain spoilers. Given the very high community demand not implementing a tag system of some sort will likely lead to a (soft-)fork of lemmy. The feature is extremely desired by many communities. An implementation of tags via UI rendering ([] brackets for tags in text would turn into a tag on a post) would be possible but ultimately far more limiting and would lead to an incosistent experience across lemmy apps/frontends as well as an inability to properly federate the tags. 257 | 258 | # Prior art 259 | 260 | Similar implementations can be found on Reddit as well as a great many image hosting platforms. 261 | 262 | Reddit's Flair System is rather restrictive, a Post can only have a single custom Flair (such as "News") greatly limiting the usefullness of the feature. 263 | 264 | Pros: 265 | 266 | - low moderation effort due to predefined tags 267 | - no/little content fragmentation since typos are not possible 268 | - no flair spam due to only 1 flair being allowed at a time 269 | 270 | Cons: 271 | 272 | - extreme moderation effort for 1st time setup due to inability to mix flairs 273 | - filter lists get extremely long because all variants of a flair need to be filtered (for example "News Europe", "News America", etc. instead of just "News") 274 | - flairs need to be created before being usable 275 | 276 | Tag/Flair Systems on Image hosting platform generally tend to favor a more unmoderated experience, often allowing Users to type in the tags themselves. 277 | 278 | Pros: 279 | 280 | - enhanced user freedom when applying tags 281 | - no delay between arising demand for tag and creation of the tag 282 | 283 | Cons: 284 | 285 | - greater moderation demand since tags have to be checked for inappropriate content 286 | - very high chance for content fragmentation (typos, differences in naming things, language barriers) 287 | - almost completely removes the ability of users to blocklist content tags (pronography would slip past a "pornography" blocklist). 288 | 289 | # Unresolved questions 290 | 291 | - How would tags federate/display on other Fediverse services such as Mastodon? 292 | - ~~Should instance wide and community tags be implemented separately or together. If separately which one should be first.~~ 293 | -> resolved, community tags will be implemented first with instance tags to follow some time later. 294 | - There is a discussion about creation permissions for tags however that changes nothing about the fundamental functionality and can be discussed after initial experience is gathered. 295 | - Should there be a limit on how many tags can be applied? If so, should this limit be hard coded or community configurable? 296 | -> should be made configurable, still up for debate whether to be implemented with this RFC or later on. 297 | 298 | # Future possibilities 299 | 300 | ## Global Tags 301 | 302 | Many tags will probably be the same across different communities. As such, it makes sense to create global tags in the future. These tag objects would still be assigned to posts by users or moderators, but their type would be `GlobalPostTag` and their ID would be global (e.g. `https://join-lemmy.org/tags/xxx`). This way, a user could configure user-global allow/block lists of tags in their Lemmy UI / App. For example Spoiler,Gore,NSFL,Trigger Warning, ... 303 | 304 | ## Filtering of user feeds based on tags 305 | 306 | ## Pre-Selected tags determined by Instance/Community/User settings: 307 | 308 | Allows for easier handling for cases where a few tags are used very often (example: a news community could pre-select the "News" tag, thereby automatically adding it to every users post creation form) 309 | 310 | Addition by [RocketDerp](https://github.com/RocketDerp) (Source: [GitHub Comment](https://github.com/Neshura87/Lemmy-RFC/commit/a11727bb992aa91e89354286876d7144b61b926f#commitcomment-125201367)): 311 | 312 | Tagging of Instances, Communitites and Users using the same system. 313 | 314 | > There are issues open on Lemmy project to have flares for users, flares for posts. I think community itself being tagged is another thing to consider and could be a means to implement a multi-community (multi-reddit) presentation system for blending communities on a post list. 315 | > [...] 316 | > Perhaps a scope smallint added to the proposed database table... scope 0 = all, 1 = community itself tagged, 2 = post tagged, 3 = user tagged. And community_id specific ones would have to be 2 = post. 317 | 318 | ## Migration and replacement of current "NSFW" flag in favor of "NSFW" tag: 319 | 320 | The current flag used to mark posts NSFW can be replaced by a Instance wide default "NSFW" flag once the feature has been field tested. 321 | 322 | ## Tag Amount Limit: 323 | 324 | Unlimited Tag usage might lead to undesired situations and extra moderation effort, long term the addition of Instance or Community limits to number of tags on a Post might be useful. 325 | 326 | ## Instance wide or other tags: 327 | 328 | The basic framework should allow this system to be used in many other contexts, however due to the complexity this should be done after an initial implementation. 329 | Areas that could use this system include: 330 | 331 | - Instance wide post tags (for example a single instance wide NSFW tag or some such) 332 | - User flairs 333 | - Tags on Communities (as opposed to on Posts) 334 | 335 | ## Tag Inheritance: 336 | 337 | Initially Tags will have a flat structure, however an inheritance system could be introduced later on to easy usability for both users and moderators. 338 | Such a system would add an attribute `inherits` to the tag object which would then reference the URL of the parent tag. If no or an empty `inherits` field is given the tag is a "root" tag and has no parent. 339 | The inheritance trees could then be used to enhance search filtering, tag settings upon creation and/or cosmetic behaviour of tags. 340 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | GNU AFFERO GENERAL PUBLIC LICENSE 2 | Version 3, 19 November 2007 3 | 4 | Copyright (C) 2007 Free Software Foundation, Inc. 5 | Everyone is permitted to copy and distribute verbatim copies 6 | of this license document, but changing it is not allowed. 7 | 8 | Preamble 9 | 10 | The GNU Affero General Public License is a free, copyleft license for 11 | software and other kinds of works, specifically designed to ensure 12 | cooperation with the community in the case of network server software. 13 | 14 | The licenses for most software and other practical works are designed 15 | to take away your freedom to share and change the works. By contrast, 16 | our General Public Licenses are intended to guarantee your freedom to 17 | share and change all versions of a program--to make sure it remains free 18 | software for all its users. 19 | 20 | When we speak of free software, we are referring to freedom, not 21 | price. Our General Public Licenses are designed to make sure that you 22 | have the freedom to distribute copies of free software (and charge for 23 | them if you wish), that you receive source code or can get it if you 24 | want it, that you can change the software or use pieces of it in new 25 | free programs, and that you know you can do these things. 26 | 27 | Developers that use our General Public Licenses protect your rights 28 | with two steps: (1) assert copyright on the software, and (2) offer 29 | you this License which gives you legal permission to copy, distribute 30 | and/or modify the software. 31 | 32 | A secondary benefit of defending all users' freedom is that 33 | improvements made in alternate versions of the program, if they 34 | receive widespread use, become available for other developers to 35 | incorporate. Many developers of free software are heartened and 36 | encouraged by the resulting cooperation. However, in the case of 37 | software used on network servers, this result may fail to come about. 38 | The GNU General Public License permits making a modified version and 39 | letting the public access it on a server without ever releasing its 40 | source code to the public. 41 | 42 | The GNU Affero General Public License is designed specifically to 43 | ensure that, in such cases, the modified source code becomes available 44 | to the community. It requires the operator of a network server to 45 | provide the source code of the modified version running there to the 46 | users of that server. Therefore, public use of a modified version, on 47 | a publicly accessible server, gives the public access to the source 48 | code of the modified version. 49 | 50 | An older license, called the Affero General Public License and 51 | published by Affero, was designed to accomplish similar goals. This is 52 | a different license, not a version of the Affero GPL, but Affero has 53 | released a new version of the Affero GPL which permits relicensing under 54 | this license. 55 | 56 | The precise terms and conditions for copying, distribution and 57 | modification follow. 58 | 59 | TERMS AND CONDITIONS 60 | 61 | 0. Definitions. 62 | 63 | "This License" refers to version 3 of the GNU Affero General Public License. 64 | 65 | "Copyright" also means copyright-like laws that apply to other kinds of 66 | works, such as semiconductor masks. 67 | 68 | "The Program" refers to any copyrightable work licensed under this 69 | License. Each licensee is addressed as "you". "Licensees" and 70 | "recipients" may be individuals or organizations. 71 | 72 | To "modify" a work means to copy from or adapt all or part of the work 73 | in a fashion requiring copyright permission, other than the making of an 74 | exact copy. The resulting work is called a "modified version" of the 75 | earlier work or a work "based on" the earlier work. 76 | 77 | A "covered work" means either the unmodified Program or a work based 78 | on the Program. 79 | 80 | To "propagate" a work means to do anything with it that, without 81 | permission, would make you directly or secondarily liable for 82 | infringement under applicable copyright law, except executing it on a 83 | computer or modifying a private copy. Propagation includes copying, 84 | distribution (with or without modification), making available to the 85 | public, and in some countries other activities as well. 86 | 87 | To "convey" a work means any kind of propagation that enables other 88 | parties to make or receive copies. Mere interaction with a user through 89 | a computer network, with no transfer of a copy, is not conveying. 90 | 91 | An interactive user interface displays "Appropriate Legal Notices" 92 | to the extent that it includes a convenient and prominently visible 93 | feature that (1) displays an appropriate copyright notice, and (2) 94 | tells the user that there is no warranty for the work (except to the 95 | extent that warranties are provided), that licensees may convey the 96 | work under this License, and how to view a copy of this License. If 97 | the interface presents a list of user commands or options, such as a 98 | menu, a prominent item in the list meets this criterion. 99 | 100 | 1. Source Code. 101 | 102 | The "source code" for a work means the preferred form of the work 103 | for making modifications to it. "Object code" means any non-source 104 | form of a work. 105 | 106 | A "Standard Interface" means an interface that either is an official 107 | standard defined by a recognized standards body, or, in the case of 108 | interfaces specified for a particular programming language, one that 109 | is widely used among developers working in that language. 110 | 111 | The "System Libraries" of an executable work include anything, other 112 | than the work as a whole, that (a) is included in the normal form of 113 | packaging a Major Component, but which is not part of that Major 114 | Component, and (b) serves only to enable use of the work with that 115 | Major Component, or to implement a Standard Interface for which an 116 | implementation is available to the public in source code form. A 117 | "Major Component", in this context, means a major essential component 118 | (kernel, window system, and so on) of the specific operating system 119 | (if any) on which the executable work runs, or a compiler used to 120 | produce the work, or an object code interpreter used to run it. 121 | 122 | The "Corresponding Source" for a work in object code form means all 123 | the source code needed to generate, install, and (for an executable 124 | work) run the object code and to modify the work, including scripts to 125 | control those activities. However, it does not include the work's 126 | System Libraries, or general-purpose tools or generally available free 127 | programs which are used unmodified in performing those activities but 128 | which are not part of the work. For example, Corresponding Source 129 | includes interface definition files associated with source files for 130 | the work, and the source code for shared libraries and dynamically 131 | linked subprograms that the work is specifically designed to require, 132 | such as by intimate data communication or control flow between those 133 | subprograms and other parts of the work. 134 | 135 | The Corresponding Source need not include anything that users 136 | can regenerate automatically from other parts of the Corresponding 137 | Source. 138 | 139 | The Corresponding Source for a work in source code form is that 140 | same work. 141 | 142 | 2. Basic Permissions. 143 | 144 | All rights granted under this License are granted for the term of 145 | copyright on the Program, and are irrevocable provided the stated 146 | conditions are met. This License explicitly affirms your unlimited 147 | permission to run the unmodified Program. The output from running a 148 | covered work is covered by this License only if the output, given its 149 | content, constitutes a covered work. This License acknowledges your 150 | rights of fair use or other equivalent, as provided by copyright law. 151 | 152 | You may make, run and propagate covered works that you do not 153 | convey, without conditions so long as your license otherwise remains 154 | in force. You may convey covered works to others for the sole purpose 155 | of having them make modifications exclusively for you, or provide you 156 | with facilities for running those works, provided that you comply with 157 | the terms of this License in conveying all material for which you do 158 | not control copyright. Those thus making or running the covered works 159 | for you must do so exclusively on your behalf, under your direction 160 | and control, on terms that prohibit them from making any copies of 161 | your copyrighted material outside their relationship with you. 162 | 163 | Conveying under any other circumstances is permitted solely under 164 | the conditions stated below. Sublicensing is not allowed; section 10 165 | makes it unnecessary. 166 | 167 | 3. Protecting Users' Legal Rights From Anti-Circumvention Law. 168 | 169 | No covered work shall be deemed part of an effective technological 170 | measure under any applicable law fulfilling obligations under article 171 | 11 of the WIPO copyright treaty adopted on 20 December 1996, or 172 | similar laws prohibiting or restricting circumvention of such 173 | measures. 174 | 175 | When you convey a covered work, you waive any legal power to forbid 176 | circumvention of technological measures to the extent such circumvention 177 | is effected by exercising rights under this License with respect to 178 | the covered work, and you disclaim any intention to limit operation or 179 | modification of the work as a means of enforcing, against the work's 180 | users, your or third parties' legal rights to forbid circumvention of 181 | technological measures. 182 | 183 | 4. Conveying Verbatim Copies. 184 | 185 | You may convey verbatim copies of the Program's source code as you 186 | receive it, in any medium, provided that you conspicuously and 187 | appropriately publish on each copy an appropriate copyright notice; 188 | keep intact all notices stating that this License and any 189 | non-permissive terms added in accord with section 7 apply to the code; 190 | keep intact all notices of the absence of any warranty; and give all 191 | recipients a copy of this License along with the Program. 192 | 193 | You may charge any price or no price for each copy that you convey, 194 | and you may offer support or warranty protection for a fee. 195 | 196 | 5. Conveying Modified Source Versions. 197 | 198 | You may convey a work based on the Program, or the modifications to 199 | produce it from the Program, in the form of source code under the 200 | terms of section 4, provided that you also meet all of these conditions: 201 | 202 | a) The work must carry prominent notices stating that you modified 203 | it, and giving a relevant date. 204 | 205 | b) The work must carry prominent notices stating that it is 206 | released under this License and any conditions added under section 207 | 7. This requirement modifies the requirement in section 4 to 208 | "keep intact all notices". 209 | 210 | c) You must license the entire work, as a whole, under this 211 | License to anyone who comes into possession of a copy. This 212 | License will therefore apply, along with any applicable section 7 213 | additional terms, to the whole of the work, and all its parts, 214 | regardless of how they are packaged. This License gives no 215 | permission to license the work in any other way, but it does not 216 | invalidate such permission if you have separately received it. 217 | 218 | d) If the work has interactive user interfaces, each must display 219 | Appropriate Legal Notices; however, if the Program has interactive 220 | interfaces that do not display Appropriate Legal Notices, your 221 | work need not make them do so. 222 | 223 | A compilation of a covered work with other separate and independent 224 | works, which are not by their nature extensions of the covered work, 225 | and which are not combined with it such as to form a larger program, 226 | in or on a volume of a storage or distribution medium, is called an 227 | "aggregate" if the compilation and its resulting copyright are not 228 | used to limit the access or legal rights of the compilation's users 229 | beyond what the individual works permit. Inclusion of a covered work 230 | in an aggregate does not cause this License to apply to the other 231 | parts of the aggregate. 232 | 233 | 6. Conveying Non-Source Forms. 234 | 235 | You may convey a covered work in object code form under the terms 236 | of sections 4 and 5, provided that you also convey the 237 | machine-readable Corresponding Source under the terms of this License, 238 | in one of these ways: 239 | 240 | a) Convey the object code in, or embodied in, a physical product 241 | (including a physical distribution medium), accompanied by the 242 | Corresponding Source fixed on a durable physical medium 243 | customarily used for software interchange. 244 | 245 | b) Convey the object code in, or embodied in, a physical product 246 | (including a physical distribution medium), accompanied by a 247 | written offer, valid for at least three years and valid for as 248 | long as you offer spare parts or customer support for that product 249 | model, to give anyone who possesses the object code either (1) a 250 | copy of the Corresponding Source for all the software in the 251 | product that is covered by this License, on a durable physical 252 | medium customarily used for software interchange, for a price no 253 | more than your reasonable cost of physically performing this 254 | conveying of source, or (2) access to copy the 255 | Corresponding Source from a network server at no charge. 256 | 257 | c) Convey individual copies of the object code with a copy of the 258 | written offer to provide the Corresponding Source. This 259 | alternative is allowed only occasionally and noncommercially, and 260 | only if you received the object code with such an offer, in accord 261 | with subsection 6b. 262 | 263 | d) Convey the object code by offering access from a designated 264 | place (gratis or for a charge), and offer equivalent access to the 265 | Corresponding Source in the same way through the same place at no 266 | further charge. You need not require recipients to copy the 267 | Corresponding Source along with the object code. If the place to 268 | copy the object code is a network server, the Corresponding Source 269 | may be on a different server (operated by you or a third party) 270 | that supports equivalent copying facilities, provided you maintain 271 | clear directions next to the object code saying where to find the 272 | Corresponding Source. Regardless of what server hosts the 273 | Corresponding Source, you remain obligated to ensure that it is 274 | available for as long as needed to satisfy these requirements. 275 | 276 | e) Convey the object code using peer-to-peer transmission, provided 277 | you inform other peers where the object code and Corresponding 278 | Source of the work are being offered to the general public at no 279 | charge under subsection 6d. 280 | 281 | A separable portion of the object code, whose source code is excluded 282 | from the Corresponding Source as a System Library, need not be 283 | included in conveying the object code work. 284 | 285 | A "User Product" is either (1) a "consumer product", which means any 286 | tangible personal property which is normally used for personal, family, 287 | or household purposes, or (2) anything designed or sold for incorporation 288 | into a dwelling. In determining whether a product is a consumer product, 289 | doubtful cases shall be resolved in favor of coverage. For a particular 290 | product received by a particular user, "normally used" refers to a 291 | typical or common use of that class of product, regardless of the status 292 | of the particular user or of the way in which the particular user 293 | actually uses, or expects or is expected to use, the product. A product 294 | is a consumer product regardless of whether the product has substantial 295 | commercial, industrial or non-consumer uses, unless such uses represent 296 | the only significant mode of use of the product. 297 | 298 | "Installation Information" for a User Product means any methods, 299 | procedures, authorization keys, or other information required to install 300 | and execute modified versions of a covered work in that User Product from 301 | a modified version of its Corresponding Source. The information must 302 | suffice to ensure that the continued functioning of the modified object 303 | code is in no case prevented or interfered with solely because 304 | modification has been made. 305 | 306 | If you convey an object code work under this section in, or with, or 307 | specifically for use in, a User Product, and the conveying occurs as 308 | part of a transaction in which the right of possession and use of the 309 | User Product is transferred to the recipient in perpetuity or for a 310 | fixed term (regardless of how the transaction is characterized), the 311 | Corresponding Source conveyed under this section must be accompanied 312 | by the Installation Information. But this requirement does not apply 313 | if neither you nor any third party retains the ability to install 314 | modified object code on the User Product (for example, the work has 315 | been installed in ROM). 316 | 317 | The requirement to provide Installation Information does not include a 318 | requirement to continue to provide support service, warranty, or updates 319 | for a work that has been modified or installed by the recipient, or for 320 | the User Product in which it has been modified or installed. Access to a 321 | network may be denied when the modification itself materially and 322 | adversely affects the operation of the network or violates the rules and 323 | protocols for communication across the network. 324 | 325 | Corresponding Source conveyed, and Installation Information provided, 326 | in accord with this section must be in a format that is publicly 327 | documented (and with an implementation available to the public in 328 | source code form), and must require no special password or key for 329 | unpacking, reading or copying. 330 | 331 | 7. Additional Terms. 332 | 333 | "Additional permissions" are terms that supplement the terms of this 334 | License by making exceptions from one or more of its conditions. 335 | Additional permissions that are applicable to the entire Program shall 336 | be treated as though they were included in this License, to the extent 337 | that they are valid under applicable law. If additional permissions 338 | apply only to part of the Program, that part may be used separately 339 | under those permissions, but the entire Program remains governed by 340 | this License without regard to the additional permissions. 341 | 342 | When you convey a copy of a covered work, you may at your option 343 | remove any additional permissions from that copy, or from any part of 344 | it. (Additional permissions may be written to require their own 345 | removal in certain cases when you modify the work.) You may place 346 | additional permissions on material, added by you to a covered work, 347 | for which you have or can give appropriate copyright permission. 348 | 349 | Notwithstanding any other provision of this License, for material you 350 | add to a covered work, you may (if authorized by the copyright holders of 351 | that material) supplement the terms of this License with terms: 352 | 353 | a) Disclaiming warranty or limiting liability differently from the 354 | terms of sections 15 and 16 of this License; or 355 | 356 | b) Requiring preservation of specified reasonable legal notices or 357 | author attributions in that material or in the Appropriate Legal 358 | Notices displayed by works containing it; or 359 | 360 | c) Prohibiting misrepresentation of the origin of that material, or 361 | requiring that modified versions of such material be marked in 362 | reasonable ways as different from the original version; or 363 | 364 | d) Limiting the use for publicity purposes of names of licensors or 365 | authors of the material; or 366 | 367 | e) Declining to grant rights under trademark law for use of some 368 | trade names, trademarks, or service marks; or 369 | 370 | f) Requiring indemnification of licensors and authors of that 371 | material by anyone who conveys the material (or modified versions of 372 | it) with contractual assumptions of liability to the recipient, for 373 | any liability that these contractual assumptions directly impose on 374 | those licensors and authors. 375 | 376 | All other non-permissive additional terms are considered "further 377 | restrictions" within the meaning of section 10. If the Program as you 378 | received it, or any part of it, contains a notice stating that it is 379 | governed by this License along with a term that is a further 380 | restriction, you may remove that term. If a license document contains 381 | a further restriction but permits relicensing or conveying under this 382 | License, you may add to a covered work material governed by the terms 383 | of that license document, provided that the further restriction does 384 | not survive such relicensing or conveying. 385 | 386 | If you add terms to a covered work in accord with this section, you 387 | must place, in the relevant source files, a statement of the 388 | additional terms that apply to those files, or a notice indicating 389 | where to find the applicable terms. 390 | 391 | Additional terms, permissive or non-permissive, may be stated in the 392 | form of a separately written license, or stated as exceptions; 393 | the above requirements apply either way. 394 | 395 | 8. Termination. 396 | 397 | You may not propagate or modify a covered work except as expressly 398 | provided under this License. Any attempt otherwise to propagate or 399 | modify it is void, and will automatically terminate your rights under 400 | this License (including any patent licenses granted under the third 401 | paragraph of section 11). 402 | 403 | However, if you cease all violation of this License, then your 404 | license from a particular copyright holder is reinstated (a) 405 | provisionally, unless and until the copyright holder explicitly and 406 | finally terminates your license, and (b) permanently, if the copyright 407 | holder fails to notify you of the violation by some reasonable means 408 | prior to 60 days after the cessation. 409 | 410 | Moreover, your license from a particular copyright holder is 411 | reinstated permanently if the copyright holder notifies you of the 412 | violation by some reasonable means, this is the first time you have 413 | received notice of violation of this License (for any work) from that 414 | copyright holder, and you cure the violation prior to 30 days after 415 | your receipt of the notice. 416 | 417 | Termination of your rights under this section does not terminate the 418 | licenses of parties who have received copies or rights from you under 419 | this License. If your rights have been terminated and not permanently 420 | reinstated, you do not qualify to receive new licenses for the same 421 | material under section 10. 422 | 423 | 9. Acceptance Not Required for Having Copies. 424 | 425 | You are not required to accept this License in order to receive or 426 | run a copy of the Program. Ancillary propagation of a covered work 427 | occurring solely as a consequence of using peer-to-peer transmission 428 | to receive a copy likewise does not require acceptance. However, 429 | nothing other than this License grants you permission to propagate or 430 | modify any covered work. These actions infringe copyright if you do 431 | not accept this License. Therefore, by modifying or propagating a 432 | covered work, you indicate your acceptance of this License to do so. 433 | 434 | 10. Automatic Licensing of Downstream Recipients. 435 | 436 | Each time you convey a covered work, the recipient automatically 437 | receives a license from the original licensors, to run, modify and 438 | propagate that work, subject to this License. You are not responsible 439 | for enforcing compliance by third parties with this License. 440 | 441 | An "entity transaction" is a transaction transferring control of an 442 | organization, or substantially all assets of one, or subdividing an 443 | organization, or merging organizations. If propagation of a covered 444 | work results from an entity transaction, each party to that 445 | transaction who receives a copy of the work also receives whatever 446 | licenses to the work the party's predecessor in interest had or could 447 | give under the previous paragraph, plus a right to possession of the 448 | Corresponding Source of the work from the predecessor in interest, if 449 | the predecessor has it or can get it with reasonable efforts. 450 | 451 | You may not impose any further restrictions on the exercise of the 452 | rights granted or affirmed under this License. For example, you may 453 | not impose a license fee, royalty, or other charge for exercise of 454 | rights granted under this License, and you may not initiate litigation 455 | (including a cross-claim or counterclaim in a lawsuit) alleging that 456 | any patent claim is infringed by making, using, selling, offering for 457 | sale, or importing the Program or any portion of it. 458 | 459 | 11. Patents. 460 | 461 | A "contributor" is a copyright holder who authorizes use under this 462 | License of the Program or a work on which the Program is based. The 463 | work thus licensed is called the contributor's "contributor version". 464 | 465 | A contributor's "essential patent claims" are all patent claims 466 | owned or controlled by the contributor, whether already acquired or 467 | hereafter acquired, that would be infringed by some manner, permitted 468 | by this License, of making, using, or selling its contributor version, 469 | but do not include claims that would be infringed only as a 470 | consequence of further modification of the contributor version. For 471 | purposes of this definition, "control" includes the right to grant 472 | patent sublicenses in a manner consistent with the requirements of 473 | this License. 474 | 475 | Each contributor grants you a non-exclusive, worldwide, royalty-free 476 | patent license under the contributor's essential patent claims, to 477 | make, use, sell, offer for sale, import and otherwise run, modify and 478 | propagate the contents of its contributor version. 479 | 480 | In the following three paragraphs, a "patent license" is any express 481 | agreement or commitment, however denominated, not to enforce a patent 482 | (such as an express permission to practice a patent or covenant not to 483 | sue for patent infringement). To "grant" such a patent license to a 484 | party means to make such an agreement or commitment not to enforce a 485 | patent against the party. 486 | 487 | If you convey a covered work, knowingly relying on a patent license, 488 | and the Corresponding Source of the work is not available for anyone 489 | to copy, free of charge and under the terms of this License, through a 490 | publicly available network server or other readily accessible means, 491 | then you must either (1) cause the Corresponding Source to be so 492 | available, or (2) arrange to deprive yourself of the benefit of the 493 | patent license for this particular work, or (3) arrange, in a manner 494 | consistent with the requirements of this License, to extend the patent 495 | license to downstream recipients. "Knowingly relying" means you have 496 | actual knowledge that, but for the patent license, your conveying the 497 | covered work in a country, or your recipient's use of the covered work 498 | in a country, would infringe one or more identifiable patents in that 499 | country that you have reason to believe are valid. 500 | 501 | If, pursuant to or in connection with a single transaction or 502 | arrangement, you convey, or propagate by procuring conveyance of, a 503 | covered work, and grant a patent license to some of the parties 504 | receiving the covered work authorizing them to use, propagate, modify 505 | or convey a specific copy of the covered work, then the patent license 506 | you grant is automatically extended to all recipients of the covered 507 | work and works based on it. 508 | 509 | A patent license is "discriminatory" if it does not include within 510 | the scope of its coverage, prohibits the exercise of, or is 511 | conditioned on the non-exercise of one or more of the rights that are 512 | specifically granted under this License. You may not convey a covered 513 | work if you are a party to an arrangement with a third party that is 514 | in the business of distributing software, under which you make payment 515 | to the third party based on the extent of your activity of conveying 516 | the work, and under which the third party grants, to any of the 517 | parties who would receive the covered work from you, a discriminatory 518 | patent license (a) in connection with copies of the covered work 519 | conveyed by you (or copies made from those copies), or (b) primarily 520 | for and in connection with specific products or compilations that 521 | contain the covered work, unless you entered into that arrangement, 522 | or that patent license was granted, prior to 28 March 2007. 523 | 524 | Nothing in this License shall be construed as excluding or limiting 525 | any implied license or other defenses to infringement that may 526 | otherwise be available to you under applicable patent law. 527 | 528 | 12. No Surrender of Others' Freedom. 529 | 530 | If conditions are imposed on you (whether by court order, agreement or 531 | otherwise) that contradict the conditions of this License, they do not 532 | excuse you from the conditions of this License. If you cannot convey a 533 | covered work so as to satisfy simultaneously your obligations under this 534 | License and any other pertinent obligations, then as a consequence you may 535 | not convey it at all. For example, if you agree to terms that obligate you 536 | to collect a royalty for further conveying from those to whom you convey 537 | the Program, the only way you could satisfy both those terms and this 538 | License would be to refrain entirely from conveying the Program. 539 | 540 | 13. Remote Network Interaction; Use with the GNU General Public License. 541 | 542 | Notwithstanding any other provision of this License, if you modify the 543 | Program, your modified version must prominently offer all users 544 | interacting with it remotely through a computer network (if your version 545 | supports such interaction) an opportunity to receive the Corresponding 546 | Source of your version by providing access to the Corresponding Source 547 | from a network server at no charge, through some standard or customary 548 | means of facilitating copying of software. This Corresponding Source 549 | shall include the Corresponding Source for any work covered by version 3 550 | of the GNU General Public License that is incorporated pursuant to the 551 | following paragraph. 552 | 553 | Notwithstanding any other provision of this License, you have 554 | permission to link or combine any covered work with a work licensed 555 | under version 3 of the GNU General Public License into a single 556 | combined work, and to convey the resulting work. The terms of this 557 | License will continue to apply to the part which is the covered work, 558 | but the work with which it is combined will remain governed by version 559 | 3 of the GNU General Public License. 560 | 561 | 14. Revised Versions of this License. 562 | 563 | The Free Software Foundation may publish revised and/or new versions of 564 | the GNU Affero General Public License from time to time. Such new versions 565 | will be similar in spirit to the present version, but may differ in detail to 566 | address new problems or concerns. 567 | 568 | Each version is given a distinguishing version number. If the 569 | Program specifies that a certain numbered version of the GNU Affero General 570 | Public License "or any later version" applies to it, you have the 571 | option of following the terms and conditions either of that numbered 572 | version or of any later version published by the Free Software 573 | Foundation. If the Program does not specify a version number of the 574 | GNU Affero General Public License, you may choose any version ever published 575 | by the Free Software Foundation. 576 | 577 | If the Program specifies that a proxy can decide which future 578 | versions of the GNU Affero General Public License can be used, that proxy's 579 | public statement of acceptance of a version permanently authorizes you 580 | to choose that version for the Program. 581 | 582 | Later license versions may give you additional or different 583 | permissions. However, no additional obligations are imposed on any 584 | author or copyright holder as a result of your choosing to follow a 585 | later version. 586 | 587 | 15. Disclaimer of Warranty. 588 | 589 | THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY 590 | APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT 591 | HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY 592 | OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, 593 | THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 594 | PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM 595 | IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF 596 | ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 597 | 598 | 16. Limitation of Liability. 599 | 600 | IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING 601 | WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS 602 | THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY 603 | GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE 604 | USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF 605 | DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD 606 | PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), 607 | EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF 608 | SUCH DAMAGES. 609 | 610 | 17. Interpretation of Sections 15 and 16. 611 | 612 | If the disclaimer of warranty and limitation of liability provided 613 | above cannot be given local legal effect according to their terms, 614 | reviewing courts shall apply local law that most closely approximates 615 | an absolute waiver of all civil liability in connection with the 616 | Program, unless a warranty or assumption of liability accompanies a 617 | copy of the Program in return for a fee. 618 | 619 | END OF TERMS AND CONDITIONS 620 | 621 | How to Apply These Terms to Your New Programs 622 | 623 | If you develop a new program, and you want it to be of the greatest 624 | possible use to the public, the best way to achieve this is to make it 625 | free software which everyone can redistribute and change under these terms. 626 | 627 | To do so, attach the following notices to the program. It is safest 628 | to attach them to the start of each source file to most effectively 629 | state the exclusion of warranty; and each file should have at least 630 | the "copyright" line and a pointer to where the full notice is found. 631 | 632 | 633 | Copyright (C) 634 | 635 | This program is free software: you can redistribute it and/or modify 636 | it under the terms of the GNU Affero General Public License as published 637 | by the Free Software Foundation, either version 3 of the License, or 638 | (at your option) any later version. 639 | 640 | This program is distributed in the hope that it will be useful, 641 | but WITHOUT ANY WARRANTY; without even the implied warranty of 642 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 643 | GNU Affero General Public License for more details. 644 | 645 | You should have received a copy of the GNU Affero General Public License 646 | along with this program. If not, see . 647 | 648 | Also add information on how to contact you by electronic and paper mail. 649 | 650 | If your software can interact with users remotely through a computer 651 | network, you should also make sure that it provides a way for users to 652 | get its source. For example, if your program is a web application, its 653 | interface could display a "Source" link that leads users to an archive 654 | of the code. There are many ways you could offer source, and different 655 | solutions will be better for different programs; see section 13 for the 656 | specific requirements. 657 | 658 | You should also get your employer (if you work as a programmer) or school, 659 | if any, to sign a "copyright disclaimer" for the program, if necessary. 660 | For more information on this, and how to apply and follow the GNU AGPL, see 661 | . 662 | --------------------------------------------------------------------------------