diff --git a/docs/enterprise.mdx b/docs/enterprise.mdx index af7893d..55c7efb 100644 --- a/docs/enterprise.mdx +++ b/docs/enterprise.mdx @@ -8,7 +8,7 @@ title: "🏢 Open WebUI for Enterprises" ## Built for Everyone, Backed by the Community -Open WebUI is completely free to use, with no restrictions or hidden limits. +Open WebUI is completely free to use as-is, with no restrictions or hidden limits. It is **independently developed** and **sustained** by its users. **Optional** licenses are available to **support** ongoing development while providing **additional benefits** for businesses. diff --git a/docs/features/sso.md b/docs/features/sso.md index fef5aee..0c764e4 100644 --- a/docs/features/sso.md +++ b/docs/features/sso.md @@ -88,19 +88,30 @@ If changing the role of a logged in user, they will need to log out and log back ### OAuth Group Management -Any OAuth provider that can be configured to return groups in the access token can be used to manage user groups in Open WebUI. -To use this feature set `ENABLE_OAUTH_GROUP_MANAGEMENT` to `true`. -You can configure the following environment variables to match the groups returned by the OAuth provider: +Any OAuth provider that can be configured to return groups in the access token can be used to manage user groups in Open WebUI upon user login. +To enable this synchronization, set `ENABLE_OAUTH_GROUP_MANAGEMENT` to `true`. -1. `OAUTH_GROUP_CLAIM` - The claim that contains the groups. Defaults to `groups`. Can also be nested, for example `user.memberOf`. +You can configure the following environment variables: -:::warning -Admin users do not get their groups updated +1. `OAUTH_GROUP_CLAIM` - The claim in the ID/access token containing the user's group memberships. Defaults to `groups`. Can also be nested, for example `user.memberOf`. Required if `ENABLE_OAUTH_GROUP_MANAGEMENT` is true. +1. `ENABLE_OAUTH_GROUP_CREATION` - If `true` (and `ENABLE_OAUTH_GROUP_MANAGEMENT` is also `true`), Open WebUI will perform **Just-in-Time (JIT) group creation**. This means it will automatically create groups during OAuth login if they are present in the user's OAuth claims but do not yet exist in the system. Defaults to `false`. If `false`, only memberships in *existing* Open WebUI groups will be managed. + +:::warning Strict Group Synchronization +When `ENABLE_OAUTH_GROUP_MANAGEMENT` is set to `true`, a user's group memberships in Open WebUI are **strictly synchronized** with the groups received in their OAuth claims upon each login. + +* Users will be **added** to Open WebUI groups that match their OAuth claims. +* Users will be **removed** from any Open WebUI groups (including those manually created or assigned within Open WebUI) if those groups are **not** present in their OAuth claims for that login session. + +Ensure all necessary groups are correctly configured in your OAuth provider and included in the group claim (`OAUTH_GROUP_CLAIM`). ::: -:::info +:::warning Admin Users +Admin users' group memberships are **not** automatically updated via OAuth group management. +::: -If changing the group of a logged in user, they will need to log out and log back in to receive the new group. +:::info Login Required for Updates + +If a user's groups change in the OAuth provider, they will need to log out of Open WebUI and log back in for the changes to be reflected. ::: diff --git a/docs/getting-started/env-configuration.md b/docs/getting-started/env-configuration.md index 6dbd81e..c48cec6 100644 --- a/docs/getting-started/env-configuration.md +++ b/docs/getting-started/env-configuration.md @@ -932,7 +932,7 @@ modeling files for reranking. - Type: `str` - Options: -- `chroma`, `elasticsearch`, `milvus`, `opensearch`, `pgvector`, `qdrant` +- `chroma`, `elasticsearch`, `milvus`, `opensearch`, `pgvector`, `qdrant`, `pinecone` - Default: `chroma` - Description: Specifies which vector database system to use. This setting determines which vector storage system will be used for managing embeddings. @@ -1126,10 +1126,52 @@ modeling files for reranking. #### `QDRANT_GRPC_PORT` -- Type: `str` -- Default: `"6334"` +- Type: `int` +- Default: `6334` - Description: Sets the gRPC port number for Qdrant. +### Pinecone + +When using Pinecone as the vector store, the following environment variables are used to control its behavior. Make sure to set these variables in your `.env` file or deployment environment. + +#### `PINECONE_API_KEY` + +- Type: `str` +- Default: `None` +- Description: Sets the API key used to authenticate with the Pinecone service. + +#### `PINECONE_ENVIRONMENT` + +- Type: `str` +- Default: `None` +- Description: Specifies the Pinecone environment to connect to (e.g., `us-west1-gcp`, `gcp-starter`, etc.). + +#### `PINECONE_INDEX_NAME` + +- Type: `str` +- Default: `open-webui-index` +- Description: Defines the name of the Pinecone index that will be used to store and query vector embeddings. + +#### `PINECONE_DIMENSION` + +- Type: `int` +- Default: `1536` +- Description: The dimensionality of the vector embeddings. Must match the dimension expected by the index (commonly 768, 1024, 1536, or 3072 based on model used). + +#### `PINECONE_METRIC` + +- Type: `str` +- Default: `cosine` +- Options: `cosine`, `dotproduct`, `euclidean` +- Description: Specifies the similarity metric to use for vector comparisons within the Pinecone index. + +#### `PINECONE_CLOUD` + +- Type: `str` +- Default: `aws` +- Options: `aws`, `gcp`, `azure` +- Description: Specifies the cloud provider where the Pinecone index is hosted. + ## RAG Content Extraction Engine #### `CONTENT_EXTRACTION_ENGINE` diff --git a/docs/license.mdx b/docs/license.mdx new file mode 100644 index 0000000..771a1b2 --- /dev/null +++ b/docs/license.mdx @@ -0,0 +1,147 @@ +--- +sidebar_position: 1900 +title: "⚖️ Open WebUI License" +--- + +## Keeping Open WebUI Free, Fair, and Sustainable + +If you've been following Open WebUI’s journey, you know our mission has always been: empower everyone with cutting-edge AI, no strings attached. We’re an independent, community-powered project. Over the last year, we’ve poured **countless hours, late nights, and real financial resources** into making this tool world-class—**and we trust our users enough to keep it free and open**. + +But with Open WebUI’s rapid growth and success, we started seeing a pattern we couldn’t ignore: **bad actors taking our work, stripping the branding, selling it as their own, and giving nothing back.** That’s not open source—that’s exploitation. When organizations profit off our efforts, misrepresent our work, and box out the real community, it threatens the very spirit of what we’re trying to build. + +That’s why we’ve acted: **with Open WebUI v0.6.6+ (April 2025), our license remains permissive, BSD-3-based, but now adds a fair-use branding protection clause**. This update does **not** impact genuine users, contributors, or anyone who simply wants to use the software in good faith. If you’re a real contributor, a small team, or an organization adopting Open WebUI for internal use—**nothing changes for you**. This change **only affects those who intend to exploit the project’s goodwill**: stripping away its identity, falsely representing it, and never giving back. + +In plain terms: +- **Open WebUI is still free, open source, and permissively licensed.** +- **You can still use, modify, and redistribute it for any purpose—just don’t remove or alter our branding unless you meet one of three clear criteria (see below).** +- **The original BSD-3 license continues to apply for all contributions made to the codebase up to and including release v0.6.5.** + +We remain committed to transparency, openness, and supporting everyone—from hobbyists to enterprise. This is a “semi-copyleft” measure: we protect just the branding, to keep the project honest and sustainable; everything else is as free as you expect from open-source BSD. + +We take your trust seriously. We want Open WebUI to stay **empowering and accessible**, **driven by real community spirit**—not gated, not locked-in, not co-opted by bad actors. We’re a small, lean team—but we care deeply about giving all our users the best experience and keeping our ecosystem clean and fair. **Thank you for supporting us, and for caring about the future of open AI.** + +--- + +## Open WebUI License: Explained + +**Effective with v0.6.6 (April 19, 2025):** + +Open WebUI’s license is now: + +- **BSD-3-Clause based**, with an additional branding restriction clause: + - **You may NOT alter, remove, or obscure any “Open WebUI” branding** (name, logo, UI marks, etc.) in any deployment or distribution, except in the circumstances below. + - Branding must remain clearly visible, unless: + 1. **You have 50 or fewer users** in a 30-day period; + 2. **You are a contributor**, and have gotten written permission from us; + 3. **You’ve secured an enterprise license** from us which explicitly allows branding changes. + +- **All code submitted/merged to the codebase up to and including release v0.6.5 remains BSD-3 licensed** (no branding requirement applies for that legacy code). +- **CLA required for new contributions** after v0.6.5 (v0.6.6+) under the updated license. + +This is not legal advice—refer to the full [LICENSE](https://github.com/open-webui/open-webui/blob/main/LICENSE) for exact language. + +--- + +## Frequently Asked Questions (FAQ) + +### **1. Can I still use Open WebUI freely for personal projects, businesses, or teaching?** + +**Yes!** Just don’t remove or alter the “Open WebUI” branding, and you’re covered by the very permissive BSD-3-Clause plus our light branding protection. Just don’t pretend your distribution is “official” from us if it isn’t. + +### **2. I want to fork Open WebUI and change the UI to fit my use case. Is that allowed?** + +**Absolutely.** You can change, extend, and customize the code or the user interface for your organization’s needs—but you’re required to keep “Open WebUI” branding visible *unless*: +- Your deployment is for **50 or fewer users in any 30-day window**; or +- You’re a recognized project contributor **and** have received written permission to adjust branding; or +- You’ve secured an **enterprise license** with us that explicitly allows branding changes. + +If you remove or modify branding without meeting these criteria, that’s a material breach of the license. + +### **3. Aren’t these clauses contradictory? BSD-3 says you can’t use your name to promote forks, but also requires branding?!** + +**Good question!** Our branding requirement means you **mayn’t falsely promote** your fork as “endorsed by” or “officially part of” Open WebUI (BSD-3-Clause, section 3)—but it *must* still acknowledge its origins for transparency. + +- **You must keep “Open WebUI” branding visible (unless you qualify as detailed above).** +- **You must clarify (in your documentation/about/landing) that it’s a fork, not the official version.** +- **You may not imply endorsement by us** for your derivative. + +This isn’t contradictory—think of it as “must acknowledge, but not misrepresent.” +Your compliance **both** (1) *retains our copyright info/branding* and (2) *avoids false advertising*. + +### **4. Why did you add this clause? Isn’t open source supposed to be fully free?** + +We believe **open source thrives on trust, transparency, and mutual respect**. Open source is about sharing knowledge, empowering others, and building together—but it’s not about letting a handful of bad actors mislead and exploit the community for pure personal gain. + +Here’s what we’ve actually seen, and why we had to act: + +- Entities take the entire work of Open WebUI, quietly strip out all signs of our branding, then present the platform as if it's **their own invention**. +- They market these rebranded solutions in commercial offerings to customers and organizations, sometimes at a massive markup. +- Some go so far as to misleadingly imply their users are dealing with the people behind the original Open WebUI, creating confusion and false expectations about who maintains the software, where it comes from, and what kind of support is available. +- When things break or customers need feature updates, these same groups turn around and *demand support from us—the original developers—**while never having contributed a line of code, a helpful bug report, documentation, or any resources back to the project.*** +- **In effect, they extract value from the collective effort of independent contributors, misrepresent their role in the project, and give nothing back to the ecosystem or its sustainability.** + +Let’s be clear: +- **Not everyone who doesn’t contribute is a bad actor.** Using Open WebUI “as is,” for internal or not-for-profit ways, is absolutely fine. We expect most users will never contribute code, and that’s totally fair—that’s how permissive open source works! +- **But there is a line:** When you start misleading your users about what you’re offering, exploiting the goodwill and energy of independent maintainers, and taking more than you give (especially when making money and actively denying credit), **that’s not collaboration—that’s extraction and misrepresentation.** +- **This is especially demoralizing for us as a small, fully independent and self-funded team**, working incredibly hard to keep Open WebUI both free and at the leading edge of AI. The reality is that open source isn’t “free” for the people building it: it takes huge time investments, personal sacrifice, ongoing infrastructure costs, and dedication. When our goodwill is taken advantage of, it directly threatens our ability to keep this project alive and thriving for everyone else. + +**That’s why** the new branding clause exists. It is a minimal, carefully scoped, and entirely rational measure: +- It preserves openness for genuine users and contributors—anyone can use, deploy, and even build commercial offerings as long as they respect transparency and our community’s work. +- It prevents bad-faith actors from concealing our contributions or misleading users—protecting the project’s identity, trust, and reputation. +- **Importantly, it also incentivizes individuals and organizations to actively contribute back to Open WebUI.** When companies are required to credit and retain the original branding, it creates a virtuous cycle: they’re far more likely to participate in the project, propose improvements, submit bug fixes, contribute features, or start a conversation about open collaboration for everyone’s benefit. +- This collective approach **ensures that enhancements, security fixes, and new features are shared more openly, accelerating progress for the entire ecosystem—rather than being siloed in closed forks nobody else benefits from.** + +We want Open WebUI to remain **free, empowering, and driven by honest spirit—protecting the project so it can serve everyone, not just those looking to exploit others’ effort for unearned gain.** The **branding protection clause targets only those edge-case exploiters**—no one else’s experience is affected. It is our genuine attempt to keep our open-source community healthy, sustainable, and welcoming, while holding the project’s identity safe from predatory appropriation. + +We’re not interested in “locking down” Open WebUI. If we have to revisit the license again, we’ll do it only if truly forced by an escalation of abuse—something we hope won’t happen, because our commitment remains with the wider community. + +We remain as open, reasonable, and fair as ever—and we trust the community to do the right thing. + +### **5. I’m a real contributor. Do these restrictions limit my rights?** + +**No.** If your code was merged/included before v0.6.6, your rights/freedoms under BSD-3 are unchanged. If you want to contribute today, the BSD-3 basis remains, but you agree (via our CLA) to follow the fair-use branding provision (with more flexibility as a contributor). + +If you contributed legacy code and now want it out (don’t want it covered by new branding requirement), we’ll **promptly remove it at your request** per the license. + +### **6. Does this mean Open WebUI is “no longer open source”?** + +**No, not at all.** Our code is fully public, the BSD-3-Clause freedom remains, and forks/contributions are always welcome. Our branding clause is a limited, semi-copyleft protection that only restricts misleading stripping of project identity. **It’s still vastly more open (and less restrictive) than most commercial “open core” models.** + +### **7. What if I want to white-label or deeply customize Open WebUI for my enterprise?** + +Contact us! We offer **proprietary and enterprise licenses** allowing fully custom branding, priority support, feature requests, and more. Email [sales@openwebui.com](mailto:sales@openwebui.com) for details. + +### **8. What if I already deployed Open WebUI before v0.6.6?** + +Anything pre-0.6.6 is pure BSD-3—**these branding limits didn’t exist**. The new branding clause applies only to future versions/releases; retroactive enforcement is not possible. + +### **9. What about forks? Can I start one and remove all Open WebUI mentions?** + +**Only if:** +- Your fork is for “small scale” deployment (**≤50 users/30-day period**), or +- You’re a contributor and have explicit written permission, or +- You have a valid enterprise license. + +Otherwise, you must retain branding and clearly say your fork isn't the official version. + +### **TL;DR: Want to use Open WebUI for free? Just keep the branding.** + +- **No hidden costs, no trickery.** +- **If you want to remove or rebrand, let's talk—contributions and partnerships welcomed.** + +#### Example Fork Branding Disclosure + +If you operate a public fork, or a paid SaaS, and retain the Open WebUI branding: + +> _“This project is a customized fork of [Open WebUI](https://github.com/open-webui/open-webui), the community-driven open-source AI platform. This release is not affiliated with or maintained by the official Open WebUI team.”_ + +Display this message—prominently—in the About section, landing page, or equivalent location. **Transparency is required.** + +--- + +## Proprietary License / Enterprise Branding + +If you are a business that needs private or custom branding, advanced white-label deployments, or tailored features for mission-critical use cases, **we offer proprietary and enterprise licenses**. We’ll work with you to ensure your needs and your branding are fully addressed, with a world-class support and engineering team backing your deployment. + +**Contact [sales@openwebui.com](mailto:sales@openwebui.com) for more information about commercial options.** + diff --git a/docs/tutorials/integrations/okta-oidc-sso.md b/docs/tutorials/integrations/okta-oidc-sso.md index af452b0..7ce50b9 100644 --- a/docs/tutorials/integrations/okta-oidc-sso.md +++ b/docs/tutorials/integrations/okta-oidc-sso.md @@ -11,7 +11,7 @@ This tutorial is a community contribution and is not supported by the Open WebUI ## Overview -This documentation page outlines the steps required to integrate Okta OIDC Single Sign-On (SSO) with Open WebUI. It also covers the **optional** feature of managing Open WebUI user groups based on Okta group membership. By following these steps, you will enable users to log in to Open WebUI using their Okta credentials. If you choose to enable group syncing, users can also be automatically assigned to relevant groups within Open WebUI based on their Okta groups. +This documentation page outlines the steps required to integrate Okta OIDC Single Sign-On (SSO) with Open WebUI. It also covers the **optional** features of managing Open WebUI user groups based on Okta group membership, including **Just-in-Time (JIT) group creation**. By following these steps, you will enable users to log in to Open WebUI using their Okta credentials. If you choose to enable group syncing (`ENABLE_OAUTH_GROUP_MANAGEMENT`), users will be automatically assigned to relevant groups within Open WebUI based on their Okta groups upon login. If you *also* enable JIT group creation (`ENABLE_OAUTH_GROUP_CREATION`), groups present in Okta claims but missing in Open WebUI will be created automatically during login. ### Prerequisites @@ -77,15 +77,34 @@ OAUTH_PROVIDER_NAME="Okta" # --- OAuth Group Management (Optional) --- # Set to "true" only if you configured the Groups Claim in Okta (Step 2) -# and want Open WebUI groups to be managed based on Okta groups. +# and want Open WebUI groups to be managed based on Okta groups upon login. +# This syncs existing groups. Users will be added/removed from Open WebUI groups +# to match their Okta group claims. # ENABLE_OAUTH_GROUP_MANAGEMENT="true" # Required only if ENABLE_OAUTH_GROUP_MANAGEMENT is true. # The claim name in the ID token containing group information (must match Okta config) # OAUTH_GROUP_CLAIM="groups" + +# Optional: Enable Just-in-Time (JIT) creation of groups if they exist in Okta claims but not in Open WebUI. +# Requires ENABLE_OAUTH_GROUP_MANAGEMENT="true". +# If set to false (default), only existing groups will be synced. +# ENABLE_OAUTH_GROUP_CREATION="false" ``` -Replace `YOUR_OKTA_CLIENT_ID`, `YOUR_OKTA_CLIENT_SECRET`, and `YOUR_OKTA_OIDC_DISCOVERY_URL` with the actual values from your Okta application configuration. If enabling group management, ensure `OAUTH_GROUP_CLAIM` matches the claim name you configured in Okta (default is `groups`). +Replace `YOUR_OKTA_CLIENT_ID`, `YOUR_OKTA_CLIENT_SECRET`, and `YOUR_OKTA_OIDC_DISCOVERY_URL` with the actual values from your Okta application configuration. + +To enable group synchronization based on Okta claims, set `ENABLE_OAUTH_GROUP_MANAGEMENT="true"` and ensure `OAUTH_GROUP_CLAIM` matches the claim name configured in Okta (default is `groups`). + +To *also* enable automatic Just-in-Time (JIT) creation of groups that exist in Okta but not yet in Open WebUI, set `ENABLE_OAUTH_GROUP_CREATION="true"`. You can leave this as `false` if you only want to manage memberships for groups that already exist in Open WebUI. + +:::warning Group Membership Management +When `ENABLE_OAUTH_GROUP_MANAGEMENT` is set to `true`, a user's group memberships in Open WebUI will be **strictly synchronized** with the groups received in their Okta claims upon each login. This means: +* Users will be **added** to Open WebUI groups that match their Okta claims. +* Users will be **removed** from any Open WebUI groups (including those manually created or assigned within Open WebUI) if those groups are **not** present in their Okta claims for that login session. + +Ensure that all necessary groups are correctly configured and assigned within Okta and included in the group claim. +::: :::info Session Persistence in Multi-Node Deployments @@ -120,7 +139,7 @@ Restart your Open WebUI instance after setting these environment variables. 1. Navigate to your Open WebUI login page. You should see a button labeled "Login with Okta" (or whatever you set for `OAUTH_PROVIDER_NAME`). 2. Click the button and authenticate through the Okta login flow. 3. Upon successful authentication, you should be redirected back to Open WebUI and logged in. -4. If `ENABLE_OAUTH_GROUP_MANAGEMENT` is true, log in as a non-admin user. Their groups within Open WebUI should reflect their group memberships in Okta (after their first login). Note that admin users' groups are not automatically updated via SSO. +4. If `ENABLE_OAUTH_GROUP_MANAGEMENT` is true, log in as a non-admin user. Their groups within Open WebUI should now strictly reflect their current group memberships in Okta (any memberships in groups *not* in the Okta claim will be removed). If `ENABLE_OAUTH_GROUP_CREATION` is also true, any groups present in the user's Okta claims that did not previously exist in Open WebUI should now have been created automatically. Note that admin users' groups are not automatically updated via SSO. 5. Check the Open WebUI server logs for any OIDC or group-related errors if you encounter issues. ## Troubleshooting