6 views
-/https://github.com/berriai/litellm/issues/34241
GitHub · issue

#34241 Clear license boundaries between MIT and Enterprise features

  • State: open
  • Author: @No-World
  • Labels: llm translation

# Clear license boundaries between MIT and Enterprise features

## Summary

I'm trying to use LiteLLM in compliance with its licenses. The root `LICENSE` says code outside `enterprise/` is MIT-licensed. But I found that many features documented as "Enterprise" have their gating logic and, in many cases, their entire implementation in MIT-licensed files. So I can't determine which features I can legally use without a subscription. I'm asking for clear, physically-enforced boundaries.

## The Problem

The root `LICENSE` draws a clear rule:

> All content that resides under the "enterprise/" directory [...] is licensed under the license defined in "enterprise/LICENSE". > Content outside of the above mentioned directories [...] is available under the MIT license.

So I should be able to look at any file path and know its license. But the current codebase doesn't follow this boundary:

### Category A: Enterprise feature gating in MIT files (25+ files)

A grep for `premium_user`, `_premium_user_check`, and `not_premium_user` shows that the enforcement mechanism for enterprise features lives almost entirely in MIT-licensed files:

| MIT file | What it gates | |---|---| | `litellm/proxy/co…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (12 events)
#0 of 0 · 31d17h49m11s ago — entered · #import:https:::github.com:berriai:litellm post #3149
34241 requires a broad repository-wide architectural and licensing audit, relocation or redesign of shared gating mechanisms, compatibility review, and coordinated documentation/testing. 32201 is comparatively localized to pass-through response inspection and enforcement, with focused regression coverage.
The right issue is harder because it requires repository-wide architectural, ownership, and compatibility decisions across many components, while the left is a comparatively contained provider-integration and request-plumbing change.
The left issue is substantially harder: it entails a large-scale runtime and language migration across core functionality, with compatibility, performance, rollout, and regression risks. The right issue is broad but comparatively more bounded to auditing ownership boundaries, reorganizing code, and documenting or enforcing licensing distinctions.
34241 requires broad cross-cutting architectural changes, repository-wide dependency and packaging decisions, and careful compatibility and licensing validation. 30460 is a more localized production bug involving distributed state, failure handling, and regression testing.
#34241 is harder because it requires repository-wide architectural and licensing-boundary changes, disentangling shared enforcement from product implementations while preserving behavior and compliance. #26535 is substantial QA and CI work, but it is more bounded and primarily extends test coverage and automation around an existing implementation.
The left requires repository-wide architectural refactoring, dependency auditing, compatibility preservation, and legal-risk validation; the right is a contained proxy configuration feature with narrower implementation and testing scope.
#34241 is harder because it requires a broad architectural reorganization with cross-cutting dependency, packaging, compatibility, and legal-risk implications. #21347 is also substantial, but can be approached as an extensible validation and conformance-testing framework layered over existing provider mappings.
34241 requires cross-cutting repository restructuring, licensing analysis, and careful preservation of enterprise gating and compatibility, creating substantial legal and regression risk. 30421 is a sizeable but comparatively contained CLI integration involving subprocess configuration, discovery, and provider-specific adapters.
31595 is harder because it requires coordinated runtime, persistence, external-service, model-routing, and dashboard work with substantial integration and behavioral risk. 34241 spans many files and carries legal sensitivity, but is primarily repository auditing, boundary refactoring, and validation rather than a new distributed feature.
The left demands cross-cutting runtime architecture, provider-specific behavior, security isolation, configuration, and extensive testing. The right is broad and legally sensitive but primarily involves repository restructuring and policy coordination rather than comparable runtime complexity.
34241 is harder because it requires a broad repository-wide licensing and feature-boundary audit, coordinated refactoring across many modules, and careful validation of legal and architectural consequences. 34497 is comparatively localized to a provider-specific usage-decoding path with focused regression tests.
#0 of 0 · 31d17h25m35s ago — current · #import:https:::github.com:berriai:litellm post #3532
The left task has broader repository-wide scope, architectural implications, and substantial legal/review risk; the right task is technically complex but more bounded to compatibility behavior and targeted fixes.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search