Code Ownership and IP Policy¶
This document defines who owns what across Factory runtime, templates, platforms, generated code, and partner contributions. It is written for architects, product managers, partners, legal reviewers, and anyone negotiating contracts with customers.
ConnectSoft uses a layered IP model that clearly separates ownership of different code types, balancing customer ownership rights with ConnectSoft's IP protection. This policy guides contract discussions, architecture decisions, and partner enablement.
Important
Core Principles: 1. Protect ConnectSoft's core IP (Factory, templates, shared libraries) 1. Give customers clear ownership of their business-specific code and data 1. Enable safe reuse of patterns without leaking customer secrets 1. No surprise IP claims - ownership is clear and documented 1. Customers own all artifacts generated into their repositories
Goals and Principles¶
Goals¶
- Protect Core IP - Protect ConnectSoft's core IP (Factory, templates, shared libraries)
- Customer Ownership - Give customers clear ownership of their business-specific code and data
- Safe Reuse - Enable safe reuse of patterns without leaking customer secrets
- Transparency - Make ownership clear and documented upfront
Principles¶
- No Surprise IP Claims - Ownership is clear and documented from the start
- Customer-First - Customers own their generated code and business logic
- Pattern Reuse - ConnectSoft can reuse non-customer-specific patterns in templates
- Licensing Clarity - Clear licensing terms for all components
Important
Core IP Principles: 1. No Surprise IP Claims - Ownership is clear and documented upfront 1. Customer Ownership - Customers own all artifacts generated into their repositories 1. Pattern Reuse - ConnectSoft retains rights to reuse non-customer-specific patterns 1. Licensing Clarity - Clear licensing terms for Factory, templates, and libraries 1. Partner Contributions - Partner contributions follow agreed ownership model
IP Categories¶
| Category | Description | Typical Examples | Default Ownership |
|---|---|---|---|
| Core ConnectSoft IP | Generic, reusable assets owned by ConnectSoft | Factory engine, templates, generic libs | ConnectSoft |
| Customer-Specific Implementation | Code/config tailored to a customer's domain | Custom microservices, business rules, domain logic | Customer |
| Shared Patterns/Know-How | Non-identifying patterns learned/improved over time | Template improvements, docs, best-practices | ConnectSoft (with attribution) |
| Partner Contributions | Code created by partners under an agreed model | Integrations, customizations, extensions | Negotiated (typically ConnectSoft with attribution) |
Note
Contracts may refine details, but this document describes defaults. Actual ownership and licensing terms are defined in Master Service Agreements (MSA) and Terms & Conditions, which should be reviewed by legal counsel.
Factory, Templates, and Platform Code¶
Factory Runtime¶
Ownership: ConnectSoft retains full IP
Status: Proprietary, closed-source
Components:
- Orchestrator, agent host, schedulers
- UI/console (projects, runs, logs)
- Internal services: knowledge store, vector index, policy engine
- Agent orchestration logic, planning, evaluation
Licensing:
- Hosted SaaS (ConnectSoft runs it)
- Enterprise on-prem/self-hosted under commercial license
Customer Rights: Customers can use the Factory, but not fork or resell the Factory itself.
Templates & Libraries¶
Ownership: Mixed (ConnectSoft owns IP, but some components are open-source)
Open Components:
- Base microservice template (without premium plugins)
- Core ConnectSoft.Extensions building blocks (logging, HTTP/OAuth2, OpenTelemetry)
- Basic DevOps pipeline templates (stripped-down versions)
Closed Components:
- Advanced templates (multi-tenant SaaS template, complex EDA setups)
- Specialized vertical templates (Insurance BCs, VetCare BCs, etc.)
- Premium libraries (compliance, governance, advanced agent blueprints)
Licensing:
- Open components: MIT/Apache 2 or similar permissive license
- Closed components: Commercial license, bundled into paid tiers or marketplace items
Customer Rights: Customers and partners are allowed to use these components under license. They MUST NOT redistribute templates or the Factory engine as their own product.
ConnectSoft Product Code (Identity/Audit/Config/Bot)¶
Ownership: ConnectSoft retains IP
Status: Closed-source (initially)
Deployment Models:
- Hosted SaaS on connectsoft.io (code fully closed)
- Optional self-host license for enterprise (read-only repo or package)
Future Option: Move some parts to open-core model if community play makes sense.
Decision
Core IP Decision: Core Factory and template sources remain proprietary; customers license usage. Factory runtime, templates, and generic platform code remain ConnectSoft IP and are licensed, not sold. Customers and partners can use these components under license but cannot redistribute them as their own product.
Generated Code and Customer Artifacts¶
What Counts as "Generated Code"¶
Generated code includes:
- Microservice repos created by the Factory for a specific customer
- Project code, infrastructure files, tests generated for customer projects
- Configuration files and documentation generated for customer projects
- ADRs/BDRs created for a customer project
Default Ownership Stance¶
Customer Ownership:
- Customers typically own the generated code for their own projects
- ConnectSoft retains rights to reuse non-customer-specific patterns in templates
- Secrets, domain data, and customer-specific logic are not reused generically
Customer Rights:
- Fork it
- Modify it
- Move it to GitHub/Bitbucket
- Stop using Factory and keep code forever
- Copy and adapt freely inside their organization
Ownership by Asset Type¶
| Asset Type | Default Ownership | Notes |
|---|---|---|
| Generated microservice | Customer (project-level) | As part of their solution |
| ConnectSoft.Extensions.* | ConnectSoft | Reusable library; used under license |
| ADRs/BDRs created for a project | Shared / negotiated | Often customer-visible, but method is reusable |
| Customer domain logic | Customer | Business rules, domain entities, customer-specific code |
| Customer secrets/config | Customer | API keys, connection strings, customer-specific configuration |
| Infrastructure code (Bicep/Terraform) | Customer | Generated for customer's Azure subscription |
Important Nuance: Customers may reference ConnectSoft NuGet packages (e.g., ConnectSoft.Extensions.*), which remain under ConnectSoft's package license. That's normal: they own their code, we own our libs.
Warning
Copying Generated Code: Customers copying generated code into other projects must respect licensing of embedded libraries/templates. While customers own their generated code, they cannot redistribute ConnectSoft templates or libraries as standalone products without agreement.
Partner Access and Contributions¶
Partner Access¶
Access Rights:
- Partners can use templates & libs under partner agreement
- Partners can use Factory for customer projects
- Partners can access documentation and training materials
Restrictions:
- Partners MUST follow contribution rules (see Contributing docs)
- Partners may not clone templates to create a competing system
- Partners may not redistribute starters/libraries without agreement
See: Partner Program Overview for partner program details.
See: Contributing Templates for template contribution rules.
See: Contributing Libraries for library contribution rules.
Partner Contributions¶
Ownership Model:
- Contributions to generic starters/libs typically become ConnectSoft IP
- Proper attribution provided if needed
- Partner retains rights to customer-specific implementations
Contribution Process:
- Partner proposes contribution
- ConnectSoft reviews and approves
- Contribution integrated into ConnectSoft starters/libs
- Partner receives attribution (if applicable)
Important
Partner Restrictions: Partners may not clone templates to create a competing system. Partners can use templates and libraries under partner agreement, but cannot redistribute them as standalone products or create competing software factories without explicit written agreement.
Decision Examples and Scenarios¶
Scenario 1: Customer Moves Generated Code to Own Git Hosting¶
Question: Customer A asks to move generated microservices to their own Git hosting (GitHub, Bitbucket, etc.)
Answer:
- Allowed - Customers own their generated code and can move it freely
- Conditions:
- Customer must respect licensing of ConnectSoft.Extensions.* libraries
- Customer cannot redistribute templates as standalone products
- Customer retains ownership of their domain logic and business rules
See: Code Ownership Model for business model details.
Scenario 2: Partner Builds Custom Integration Library¶
Question: Partner builds a custom integration library for a customer project. Who owns it?
Answer:
- Default: Partner owns customer-specific implementation
- If Contributed: If partner contributes generic parts to ConnectSoft starters/libs, those parts become ConnectSoft IP with attribution
- Customer Code: Customer-specific integration code remains customer-owned
See: Partner Program Overview for partner program details.
Scenario 3: Customer Copies Generated Microservice to New Project¶
Question: Customer copies a generated microservice to create a new microservice for a different project. Is this allowed?
Answer:
- Allowed - Customers own their generated code and can copy/adapt it
- Considerations:
- Customer must respect licensing of embedded libraries
- Customer should consider using Factory for consistency
- Copying doesn't give them Factory benefits (updates, support, consistency)
See: Code Ownership Model for practical stance on code copying.
Scenario 4: Customer Stops Using Factory but Keeps Code¶
Question: Customer stops using Factory but wants to keep and maintain generated code. Is this allowed?
Answer:
- Allowed - Customers own their generated code and can keep it forever
- Considerations:
- Customer loses Factory benefits (updates, support, new templates)
- Customer must maintain code themselves
- Customer must respect licensing of embedded libraries
See: Code Ownership Model for value proposition.
Related Documents¶
- Code Ownership Model - Business model view of code ownership
- BDR-0001: Generated Code Ownership - Business decision record
- Business Strategy - Overall business strategy
- Pricing Strategy - Pricing models and strategy
- Marketplace Strategy - Marketplace strategy
- Marketplace Roadmap - Marketplace evolution roadmap
- Partner Program Overview - Partner program details
- Commercial Models and Revenue Share - Partner commercial models
- Contributing Templates - Template contribution rules
- Contributing Libraries - Library contribution rules
- Factory Business Model - Factory business model
- SaaS Platforms Business Model - Platform business model