Planes y derechos

Opfield usa los planes Community, Personal, Business y Enterprise. La disponibilidad, las condiciones de uso comercial, la licencia de despliegue de Opfield y las cuotas de los servicios alojados por separado son conceptos distintos.

Elige un plan a partir de los requisitos operativos, no del tamaño de la organización. Empieza por los flujos de trabajo que deben admitirse, los límites de recursos que necesitan, los controles de seguridad que exige la política y las condiciones de soporte o comerciales que requiere el comprador. El responsable de la instalación es quien supervisa el estado de la licencia; los responsables de los recursos deben saber qué operaciones dependen de derechos de pago.

Las funciones de pago listas se aplican en el límite de cada operación además de en la interfaz. Cuando termina un plan de pago, la infraestructura existente sigue funcionando: tras el periodo de gracia, crear recursos de pago y cambiar su configuración queda bloqueado, mientras que los recursos de pago existentes siguen funcionando. La revocación, la transferencia a otra instalación y la desactivación no tienen periodo de gracia. Los periodos de gracia y la disponibilidad exacta de las funciones pueden cambiar con las versiones del producto; revisa la matriz actual antes de publicar.

Las instalaciones Community no requieren clave. Una clave Personal, Business o Enterprise representa una instancia activa de Opfield; las cuotas de recursos dentro de una instancia de Opfield no deben confundirse con las cuotas de los servicios alojados por separado.

Autoalojamiento y nube gestionada

Todos los planes (Community, Personal, Business y Enterprise) se pueden autoalojar. Una clave de pago desbloquea funciones y límites de pago en una instalación que ejecutas tú; ningún plan requiere que Opfield aloje el plano de control. La nube gestionada, en la que el equipo de Opfield opera el plano de control, es un complemento de los planes Personal y Business que se vende junto con la clave de licencia en tu cuenta de Opfield; una instalación gestionada se salta el asistente de configuración, y su propietario inicia sesión primero con la cuenta de Opfield y puede pasar después a su propio SSO o a otro método de inicio de sesión. En una instalación autoalojada, las credenciales cifradas y la clave maestra se quedan en tu entorno; consulta Dónde están los secretos en una instalación autoalojada. Para las preguntas habituales previas a la compra, consulta Evaluar Opfield.

Progresión de los planes

Plan	Límite habitual de capacidades
Community	Tráfico entrante, Docker y Apps básicos, descubrimiento de Compose externo, monitorización, identidad, automatización con REST API, OAuth y MCP, chat de AI Workspace, Inference y hasta 25 nodos gestionados, 3 usuarios y 1 grupo de permisos personalizado
Personal	Community más conexiones a bases de datos externas, conexiones de almacenamiento, bases de datos y almacenamiento de objetos gestionados, container links, copia de seguridad y restauración de bases de datos, integración con GitLab, AI Plan Mode, Scenarios y Sandboxes, ciclo de vida gestionado de Compose en un solo nodo, Pages, páginas de estado, operaciones de archivo y migración, y cuotas básicas documentadas ilimitadas
Business	Personal más Workload Availability (HA) en varios nodos, grupos de ingress, bases de datos y almacenamiento de objetos gestionados en varios servidores, push-to-deploy desde Git, Build Workers aislados, Secure Runtime, admisión por vulnerabilidades, logging estructurado, exportación de la auditoría y acceso opcional al registro externo
Enterprise	Business más PKI interna, exportación de la auditoría a SIEM y ventajas comerciales dedicadas

La matriz exacta de funciones depende de cada versión. Las páginas del producto identifican los requisitos previos y esta página explica el comportamiento del ciclo de vida; los precios y las condiciones contractuales corresponden al acuerdo comercial aplicable. Los precios publicados actualmente están en el sitio web de Opfield.

Guided Onboarding and Configuration Review (Business y Enterprise) y Assisted Deployment and Migration (Enterprise) son ventajas del plan que presta el equipo de Opfield, no funciones en tiempo de ejecución; su alcance lo define el acuerdo comercial. En cualquier plan, Lleva tu stack a Opfield indica el orden del traslado.

Matriz de funciones

Función	Estado	Community	Personal	Business	Enterprise
Gestión de nodos de infraestructura	Ready	✅	✅	✅	✅
Gestión de ingress nginx en varios nodos	Ready	✅	✅	✅	✅
Gestión de contenedores Docker: entorno de ejecución predeterminado (runc)	Ready	✅	✅	✅	✅
Descubrimiento, monitorización y logs de Compose Projects externos	Ready	✅	✅	✅	✅
Secure Links Docker ↔ Nginx	Ready	✅	✅	✅	✅
Registro Docker interno privado gestionado por Opfield	Ready	✅	✅	✅	✅
Gestión de certificados SSL/TLS	Ready	✅	✅	✅	✅
Gestión de dominios y DNS	Ready	✅	✅	✅	✅
Monitorización de la infraestructura	Ready	✅	✅	✅	✅
Descubrimiento, conexión y monitorización de GPU físicas	Ready	✅	✅	✅	✅
Alertas y notificaciones por webhook	Ready	✅	✅	✅	✅
Autenticación, OIDC y MFA	Ready	✅	✅	✅	✅
Control de acceso basado en roles con ámbito por carpeta y por recurso	Ready	✅	✅	✅	✅
Apps con entornos, variables compartidas, promoción, apagado y kill switch	Ready	✅	✅	✅	✅
Vínculo con una cuenta de Opfield Cloud	Ready, opt-in	✅	✅	✅	✅
Relays protegidos en máquinas de otros propietarios	Ready, opt-in	✅	✅	✅	✅
Registro de auditoría	Ready	✅	✅	✅	✅
Automatización con REST API, OAuth y MCP	Ready	✅	✅	✅	✅
Chat de AI Workspace	Ready, opt-in	✅	✅	✅	✅
Opfield Inference	Ready, opt-in	✅	✅	✅	✅
Instalación automatizada y actualizaciones firmadas	Ready	✅	✅	✅	✅
Exportación de la configuración de Opfield para trasladarla a otra instancia	Ready	✅	✅	✅	✅
Nodos gestionados	Plan limit	25	Ilimitado	Ilimitado	Ilimitado
Usuarios	Plan limit	3	Ilimitado	Ilimitado	Ilimitado
Grupos de permisos personalizados	Plan limit	1	Ilimitado	Ilimitado	Ilimitado
Nivel de soporte	Service level	Community	Estándar	Prioritario	Prioritario + dedicado
Conexiones a bases de datos externas y exploradores	Ready	—	✅	✅	✅
Conexiones de almacenamiento: S3, R2, MinIO y otros servicios compatibles con S3, FTP, FTPS y SFTP	Ready	—	✅	✅	✅
Integración con GitLab	Ready	—	✅	✅	✅
AI Workspace Plan Mode, Scenarios y AI Sandboxes	Ready, opt-in	—	✅	✅	✅
Exportación e importación de contenedores	Ready	—	✅	✅	✅
Volúmenes Docker de imagen de disco	Ready	—	✅	✅	✅
Deployments blue/green	Ready	—	✅	✅	✅
Migración de contenedores y Deployments entre nodos	Ready	—	✅	✅	✅
Despliegue y ciclo de vida gestionados de Compose en un solo nodo	Ready	—	✅	✅	✅
Bases de datos gestionadas con Secure Links	Ready	—	✅	✅	✅
Páginas de estado públicas	Ready, opt-in	—	✅	✅	✅
Pages	Ready	—	✅	✅	✅
Descubrimiento automático del registro de contenedores de GitLab	Ready	—	✅	✅	✅
Copia de seguridad y restauración de bases de datos gestionadas y externas	Ready	—	✅	✅	✅
Almacenamiento de objetos gestionado (SeaweedFS, un solo nodo) con vinculaciones privadas y Secure Links	Ready	—	✅	✅	✅
Container links entre cargas de trabajo en el mismo nodo o en nodos distintos	Ready	—	✅	✅	✅
Docker Secure Runtime (runsc/gVisor)	Ready	—	—	✅	✅
Push-to-deploy desde repositorios Git para Containers, Deployments, Compose y Pages; Build Workers aislados	Ready	—	—	✅	✅
Acceso de clientes Docker externos al registro interno	Ready, opt-in	—	—	✅	✅
Workload Availability en varios nodos (Container, Deployment, Compose)	Ready	—	—	✅	✅
Grupos de ingress: Routes, dominios, Pages y la página de estado servidos por varios nodos Ingress	Ready	—	—	✅	✅
Bases de datos y almacenamiento de objetos gestionados en varios servidores, con conmutación por error automática o manual	Ready	—	—	✅	✅
Análisis de vulnerabilidades y política de admisión de los builds de Git	Ready	—	—	✅	✅
Logging estructurado	Ready, opt-in	—	—	✅	✅
Exportación del registro de auditoría	Ready	—	—	✅	✅
Guided Onboarding and Configuration Review	Plan benefit	—	—	✅	✅
PKI interna	Ready	—	—	—	✅
Exportación de la auditoría a SIEM	Ready, opt-in	—	—	—	✅
Contacto técnico dedicado	Plan benefit	—	—	—	✅
Assisted Deployment and Migration	Plan benefit	—	—	—	✅

Novedades de la 2.12: Apps en todos los planes, y bases de datos y almacenamiento de objetos gestionados en varios servidores en Business y Enterprise, incluidos los pares replicados con conmutación por error manual. Las apps nunca comprueban la licencia: una app, sus entornos, la promoción, el apagado y el kill switch funcionan igual en todos los planes, mientras que cada recurso dentro de una app conserva su propio requisito de plan. Las conexiones de almacenamiento, el almacenamiento de objetos gestionado y la copia de seguridad y restauración de bases de datos son novedades de la 2.11; Workload Availability (HA) sigue disponible en Business y Enterprise. La exportación de la configuración de Opfield para trasladarla a otra instancia está disponible en la 2.12 en todos los planes. SMB no es un tipo de conexión de almacenamiento compatible.

Consulta Workload Availability para los requisitos previos y los límites de la alta disponibilidad, y Actualizaciones y copias de seguridad para los procedimientos actuales de recuperación manual.

Hoja de ruta

Las capacidades siguientes todavía no están en el producto, así que la matriz anterior no las incluye. Cada una indica los planes a los que está destinada. Una versión objetivo es una estimación; un elemento marcado como Planned todavía no tiene versión objetivo.

Capacidad	Planes previstos	Objetivo
CLI general de Opfield para terminales y CI/CD	Community, Personal, Business, Enterprise	2.13
Daemon de gestión Bastion / SSH	Business, Enterprise	2.14
Análisis más amplio de vulnerabilidades y seguridad de las cargas de trabajo	Business, Enterprise	Planned
Escalado automático por métricas	Business, Enterprise	Planned
Varias instancias de una carga de trabajo en una misma máquina	Business, Enterprise	Planned
Mapeo de grupos OIDC y aprovisionamiento SCIM	Enterprise	Planned

El análisis de vulnerabilidades de los builds de Git ya está disponible y es independiente del análisis más amplio de las cargas de trabajo. El sistema de plugins es infraestructura central de Opfield sin terminar, no una función de un plan; su calendario provisional es no antes de la 2.20, sin una fecha de lanzamiento comprometida.

Aplicación

Las funciones de pago listas se aplican en los límites de las operaciones del backend además de en la consola. REST, OAuth, MCP, AI Workspace, los workers en segundo plano y los endpoints públicos de tokens no eluden las comprobaciones de derechos del plan.

La falta de un derecho del plan falla sin eliminar los recursos existentes. Las comprobaciones del core público de Opfield devuelven LICENSE_ENTITLEMENT_REQUIRED (HTTP 403). Las áreas que implementa el commercial core (por ejemplo, las bases de datos, el almacenamiento, las copias de seguridad, GitLab, Pages y la PKI de cara al usuario) están ocultas en la consola en un plan sin ellas (abrir una por su dirección muestra la cabecera de la página con un aviso del plan) y no están disponibles a través de la API hasta que estén activos el plan y el core necesarios. Un rechazo por el plan nunca aparece como un mensaje de error: la carga de una página no muestra nada, y una acción abre el diálogo del plan. Las cuotas del plan alcanzadas devuelven LICENSE_QUOTA_EXCEEDED (HTTP 409) y conservan los registros actuales. Una incoherencia en una política protegida falla de forma segura en lugar de suponer un plan más permisivo.

Las cuotas de Community de nodos gestionados, usuarios y grupos de permisos personalizados solo se comprueban al crear uno de ellos, cuando se aprovisiona un usuario en su primer inicio de sesión mediante OIDC o cuando se restaura un usuario eliminado. El recuento de nodos incluye los nodos pendientes y sin conexión. Los nodos, usuarios y grupos que ya superan una cuota (por ejemplo, tras una bajada de plan o una actualización desde la 2.10) siguen funcionando y nunca se eliminan ni se desactivan. Las comprobaciones de derechos del plan leen el estado de licencia en caché de la instalación, así que una operación individual nunca espera al servicio de licencias.

Commercial core

Community y los planes de pago ejecutan las mismas imágenes de Opfield. Las funciones de pago se entregan como un commercial core firmado por separado que Opfield descarga del servicio de licencias para una instalación que tiene o tuvo una activación de pago, y que verifica antes de usarlo: deben coincidir la firma, la versión exacta de Opfield, los tamaños de los archivos y los hashes. Opfield solo carga el core al arrancar.

Activar una clave de pago en Settings > General > License prepara el core correspondiente mediante el mecanismo de actualización firmada mientras Opfield sigue atendiendo peticiones, y después reinicia Opfield para cargarlo. Si la preparación falla, la clave sigue activada y Enable paid features la reintenta. Una clave activada durante el asistente de configuración inicial no prepara el core; abre después los ajustes de la licencia y selecciona Enable paid features. Cuando hay una clave válida pero falta el core o se rechaza, la consola informa de que las funciones de pago no están listas, lo que es distinto de un plan insuficiente, y la infraestructura existente sigue funcionando.

Actualización de una instalación Community desde la 2.10

La 2.11 aplica los nuevos límites y la nueva lista de funciones de Community justo después de la actualización:

• Los nodos, usuarios y grupos por encima de 25, 3 y 1 siguen funcionando, pero no puedes añadir más.
• Las conexiones a bases de datos externas, los conectores de GitLab y los datos de AI Plan Mode existentes se conservan en la base de datos, pero no se pueden abrir en Community. La monitorización de bases de datos y la sincronización de GitLab se detienen.
• Las demás funciones de Community, incluidos Docker, el tráfico entrante, TLS, la monitorización, la identidad, la automatización con API y MCP, el chat de AI Workspace y Opfield Inference, siguen sin cambios.

Aplicar una clave Personal o superior restablece el acceso a los registros conservados.

Las claves de pago emitidas antes de la 2.11 conservan su plan. Las claves Personal, Business y Enterprise con un formato de derechos anterior incluyen las nuevas capacidades de conexiones de almacenamiento, conexiones a bases de datos externas, almacenamiento gestionado, container links, volúmenes de imagen de disco y AI Plan Mode, Scenarios y Sandboxes.

Comunicación con el servicio de licencias

Opfield mantiene una lista firmada de las direcciones del servicio de licencias y usa la que responda. Permite https://license.opfield.dev en una lista de salida permitida, junto con el host de actualizaciones https://get.opfield.dev. Para enviar las peticiones de licencia a través de una dirección propia, como un proxy de salida, fija LICENSE_SERVICE_URL en el .env de Opfield (varias direcciones separadas por comas) y reinicia Opfield; esa dirección se prueba primero. Opfield contacta con el servicio de licencias solo para estos fines:

Petición	Cuándo	Datos enviados
Registrar la instalación	En el primer arranque, o cuando el token de instalación guardado ya no es válido	ID de instalación, un nonce de registro generado localmente, nombre de la instalación, versión de Opfield y versión del esquema de derechos
Heartbeat	Poco después de arrancar, después cada 15 minutos con una clave de pago o cada 30 minutos en Community, y cuando un administrador selecciona una comprobación manual	Token de instalación, nombre de la instalación, versión de Opfield y versión del esquema de derechos
Activar o desactivar una clave	Cuando un administrador aplica o elimina una clave de pago	Token de instalación y versión del esquema de derechos, más la clave de pago en la activación
Autorizar una versión	Antes de una actualización de Opfield y cuando se activan las funciones de pago	Token de instalación, versión de Opfield de destino y versión del esquema de derechos
Descargar el commercial core	Durante una actualización o la activación de las funciones de pago de una instalación que tiene o tuvo una activación de pago	Token de instalación, versión de Opfield de destino, ID de la versión, ruta del archivo y versión del esquema de derechos

Cada petición incluye además un nonce de petición aleatorio y los ID de las claves de firma que fija la versión de Opfield. El ID de instalación es un identificador aleatorio generado por la instalación. El nombre de la instalación es el nombre de host de la URL pública configurada de Opfield, o el nombre de host del servidor cuando no hay ninguna URL pública guardada. Opfield no envía la configuración de la infraestructura, el contenido de los recursos, los secretos, los logs, los recuentos de usuarios o de recursos, los prompts ni las respuestas de los modelos. La clave de licencia, el token de instalación y el nonce de registro se guardan cifrados en la instalación. Las instalaciones Community siguen siendo utilizables mientras el registro está pendiente o el servicio no es accesible. Activar una clave de pago, y actualizar una instalación que tiene o tuvo un plan de pago, requieren que el servicio sea accesible; una actualización rechazada o fallida deja en ejecución la versión actual. Una instalación Community sin clave, sin plan de pago y sin commercial core se actualiza aunque el servicio no sea accesible, porque no descarga nada privado. Consulta Actualizaciones, copias de seguridad y restauración.

Estados de licencia firmados

El servicio de licencias firma con Ed25519 cada estado de licencia que devuelve (para el registro, los heartbeats, la activación, la desactivación y la autorización de versiones). La firma cubre el ID de instalación, la finalidad de la petición, el nonce de la petición, la hora de emisión y el estado completo, incluidos el plan, los derechos, la caducidad y el plazo de gracia. Las versiones de Opfield fijan las claves públicas del servicio y aplican un estado solo cuando:

• la firma es válida para una clave fijada;
• el estado se firmó para esta instalación y para la finalidad y el nonce de esta petición, de modo que una respuesta capturada no se puede repetir ni usar en otra instalación;
• la hora de emisión está dentro de los 15 minutos del reloj local.

Una respuesta sin firmar, falsificada, repetida, ajena o desactualizada se trata como un servicio inaccesible: el último estado firmado válido sigue en vigor y la gracia sin conexión continúa desde su hora de emisión. El registro y la activación fallan en lugar de guardar credenciales de una respuesta sin firmar, y una descarga del commercial core solo se autoriza con un estado firmado para esa petición. Opfield guarda los estados firmados y los vuelve a verificar cada vez que lee la licencia, de modo que editar la licencia en caché en la base de datos no puede subir el plan. Mantén sincronizado el reloj del host de Opfield; un reloj desviado más de 15 minutos hace que todas las respuestas parezcan desactualizadas.

Bajada de plan y caducidad

Un plan de pago puede terminar por caducidad, por una bajada a un plan inferior, por un servicio de licencias inaccesible, por revocación, por transferencia de la clave a otra instalación o por una desactivación explícita. Hasta que termina el periodo de gracia correspondiente, todo sigue funcionando como antes, incluidos el reenvío a SIEM y el acceso de clientes Docker externos al registro interno.

Causa	Periodo de gracia	Contado desde
Caducidad	24 horas en Personal, 3 días en Business, 7 días en Enterprise	La fecha de caducidad
Servicio de licencias inaccesible	100 días, nunca más allá de la gracia por caducidad	La hora de emisión del último estado de licencia firmado válido
Bajada a un plan de pago inferior	La gracia del plan superior: 24 horas, 3 días o 7 días	El último estado firmado que todavía indicaba el plan superior
Revocación, transferencia a otra instalación, desactivación, clave no válida	Ninguno	—

Durante la gracia por caducidad, el estado de la licencia es Expired — grace period y el Dashboard muestra una advertencia; mientras el servicio no es accesible, es Licensed with warning. Opfield evalúa los plazos localmente y no espera a otro heartbeat.

Tras el periodo de gracia (o de inmediato tras una revocación, una transferencia o una desactivación), las acciones nuevas usan los derechos de Community, mientras que los recursos de pago existentes conservan un derecho de continuidad para el plan de pago más alto que haya tenido la instalación, según demuestre un estado de licencia firmado guardado:

• Sigue funcionando: todas las cargas de trabajo existentes y el plano de datos: Containers, Deployments, Compose Projects, Routes, Secure Links, vinculaciones de bases de datos y almacenamiento gestionados, Relays, despliegues de Pages publicados, listas de revocación de certificados de la PKI interna e ingesta de logs estructurados. Continúan las copias de seguridad programadas existentes, su retención, Run now, la cancelación y las restauraciones en bases de datos existentes. Workload Availability sigue reparando y puede iniciar, detener y reiniciar las cargas de trabajo existentes. Las bases de datos y el almacenamiento en varios servidores siguen conmutando por error, y todavía puedes cambiar el primario, reconstruir una copia, eliminar un servidor y desactivar la disponibilidad. Los conectores de GitLab existentes siguen sincronizándose. Para los recursos de pago existentes, todavía puedes verlos, leer los logs y la monitorización, probar las conexiones, revelar y rotar las credenciales, revocar y exportar los certificados y eliminarlos.
• Se pausa: el reenvío a SIEM y la emisión de tokens para el acceso de clientes Docker externos al registro interno. Se conservan sus ajustes, el punto de entrada externo del registro y el historial de entregas de SIEM, y los registros ya en cola para SIEM se entregan tras la renovación; los eventos de auditoría que se producen mientras el reenvío está pausado no se ponen en cola. Ambos se reanudan al renovar sin necesidad de reconfigurar.
• Se bloquea: crear recursos de pago, cambiar la configuración de los recursos de pago existentes, escribir datos a través de los exploradores de bases de datos y de almacenamiento de objetos (eliminar filas, claves, objetos y buckets sigue siendo posible), restaurar una copia de seguridad en una base de datos gestionada nueva y las operaciones exclusivas de los planes de pago, como la exportación e importación de archivos, la migración, la exportación de la auditoría y los builds desde orígenes Git. Las creaciones por encima de los límites de nodos, usuarios y grupos de Community se rechazan. Estas devuelven LICENSE_ENTITLEMENT_REQUIRED o LICENSE_QUOTA_EXCEEDED.

Opfield nunca cambia la configuración guardada, desactiva módulos ni elimina recursos gestionados porque haya terminado un plan. Renovar o volver a activar una clave restablece todas las operaciones de pago sin reconstruir la infraestructura existente. Los Paid Key Terms determinan si puedes seguir operando los recursos de pago tras una revocación; el propio Opfield no los detiene.

Una instalación sigue recibiendo actualizaciones después de que termine su plan de pago. Una instalación que tiene o tuvo una activación de pago (incluida una caducada, revocada, transferida o desactivada) recibe el commercial core correspondiente con cada actualización, de modo que sus recursos de pago existentes siguen funcionando según estas reglas. Una instalación que nunca tuvo un plan de pago se actualiza como Community.

Comprobaciones operativas

• Verifica el ID de instalación y la instancia activa prevista antes de aplicar una clave.
• Supervisa la caducidad y el plazo de gracia local.
• Prueba las operaciones premium necesarias antes de un lanzamiento en producción.
• Registra qué operaciones se bloquearán tras el periodo de gracia, y que el reenvío a SIEM y los tokens del registro externo se pausan.
• Restablece el derecho del plan antes de sustituir a mano los recursos conservados.

No uses la antigua terminología homelab ni deduzcas la disponibilidad de las funciones a partir de textos de precios, capturas de pantalla o una versión distinta de Opfield.

Elegir y cambiar de plan

Elabora un pequeño registro de decisión que enumere las capacidades necesarias, los recuentos de recursos esperados, los entornos, los controles de cumplimiento y la consecuencia si el derecho del plan deja de estar disponible temporalmente. Prueba las operaciones reales en la versión de destino antes de la aprobación de la compra. El nombre de una función en un contrato o en una matriz no demuestra que la instalación tenga la capacidad de nodo o el proveedor externo necesarios.

Antes de una bajada de plan, una caducidad o una transferencia a otra instalación:

1. identifica los recursos premium y la automatización que dejarán de aceptar trabajo nuevo;
2. conserva los ajustes de origen, los artefactos de build, la PKI y la configuración de logging y de SIEM;
3. confirma qué recursos en ejecución siguen operativos y qué periodo de gracia se aplica;
4. comunica el plazo operativo y su responsable;
5. restablece el derecho del plan y confirma que se han reanudado el reenvío a SIEM y el acceso al registro externo pausados;
6. verifica los caminos de los clientes en lugar de suponer que la configuración anterior se ha reanudado.

No elimines los recursos conservados para «limpiar» una advertencia de derechos del plan. Su estado conservado es el camino de recuperación cuando vuelva el plan correcto.

Límites de la licencia

La licencia de Opfield cubre la instalación activa de Opfield según su clave y su acuerdo. Las credenciales, las cuotas o las suscripciones de proveedores externos (DNS en la nube, control de código fuente, registros, correo, IA u otros servicios alojados) siguen siendo independientes. Del mismo modo, el uso que muestra Opfield Inference es una contabilidad operativa y debe conciliarse con el proveedor para las decisiones comerciales.

El código fuente actual, publicado con el nombre Opfield por su Licenciante, Alexandr Slavinschii ([email protected]), está disponible bajo la PolyForm Perimeter 1.0.1. La PolyForm Perimeter permite el uso, la modificación y la redistribución para fines que no compitan, incluido el uso interno normal en una empresa. El fin excluido es ofrecer a otros un producto comercializado como sustituto de Opfield, ya sea como software, como servicio alojado, como port o como oferta gratuita.

Una clave Personal, Business o Enterprise desbloquea las funciones y los límites de los planes de pago; no es necesaria solo porque una organización use Community internamente. Una clave normal no concede derechos de OEM, marca blanca, reventa, servicio alojado competidor ni otros productos sustitutos. Esos usos requieren un acuerdo escrito aparte con el Licenciante actual. Tras la caducidad normal de una clave, las condiciones de continuidad de la clave conservan los recursos de los planes de pago configurados antes de la caducidad mientras bloquean las nuevas creaciones y ampliaciones exclusivas de los planes de pago.

Cada versión oficial incluye además la Product Continuity Grant. Entra en vigor cuando, durante 12 meses consecutivos, no se publica ninguna versión nueva mientras el servicio de licencias no está disponible, cuando el Licenciante anuncia el fin de Opfield o cuando el Licenciante fallece o ya no puede actuar. El servicio de licencias es el servicio de licencias que el Licenciante opera para Opfield en cualquier dirección que publique; se considera disponible mientras responda cualquiera de esas direcciones. A partir de entonces, el código fuente de la última versión, incluido el commercial core, queda disponible para todos bajo la licencia MIT, y quien tenga una clave válida en ese momento conserva además una licencia perpetua para usar y autoalojar esa versión según su plan y puede ejecutarla sin el servicio de licencias. La propia concesión es la fuente autoritativa sobre su alcance, sus condiciones y sus exclusiones. Los planes de pago se rigen por los Opfield Paid Key Terms.