The short version
Parasolid if robustness matters most and royalties fit your pricing. ACIS as a close commercial alternative. Open CASCADE if royalties would break your model and you can fund a hardening layer. The decision is driven more by your pricing model than by technical merit.
This choice gets made early, is expensive to reverse, and is usually argued on technical grounds when the commercial constraints matter more. Here is an honest comparison.
Side by side
| Parasolid | ACIS | Open CASCADE | |
|---|---|---|---|
| Owner | Siemens | Spatial (Dassault) | Open Cascade SAS / community |
| Licence | Commercial, royalty | Commercial, royalty | LGPL (open source) |
| Boolean robustness | Excellent | Excellent | Good; needs hardening |
| API ergonomics | C, terse but consistent | C++, well structured | C++, verbose and dated |
| Documentation | Strong, licensed | Strong, licensed | Uneven; community-supplemented |
| Support | Commercial SLA | Commercial SLA | Community or paid contract |
| Upfront cost | High | High | None |
| Per-seat cost | Royalty | Royalty | None |
| Source access | No | No | Yes |
The question that actually decides it
Not "which is most robust" but "does a per-seat royalty survive my pricing model?"
- Selling perpetual licences at ₹3–15 lakh per seat? A royalty is a manageable percentage.
- Selling SaaS at ₹2,000/month? A per-seat royalty may exceed your gross margin entirely.
- Shipping embedded in hardware at volume? Per-unit royalties compound fast.
- Building an internal tool with 20 users? Royalty is trivial and robustness wins.
Model this before you evaluate technically. Teams routinely spend months benchmarking kernels, choose the best one, then discover during contract negotiation that the royalty structure is incompatible with how they sell. Run the commercial arithmetic first — it eliminates options faster than any benchmark.
Where Open CASCADE genuinely costs you
OCCT is a serious kernel used in shipping products, and treating it as a free lunch is the mistake. The realistic costs:
- Boolean failures on real geometry Operations that succeed on clean models fail on customer files with tangencies and slivers. You will build fallbacks and repair logic.
- API surface area Verbose, with sharp edges around memory and exception handling. Most teams write a wrapper layer rather than calling it directly.
- Performance tuning Some operations are slower than commercial equivalents and need profiling and caching.
- Documentation gaps You will read source to understand behaviour more often than with a commercial kernel.
- No SLA When a boolean fails in production, it is your engineering problem, not a support ticket.
Open CASCADE does not remove the cost of a kernel. It converts a royalty into engineering salary — which is the right trade for some businesses and the wrong one for others.
LGPL: what it actually requires
OCCT is LGPL, which is more permissive than GPL but not unconditional. In broad terms, dynamic linking lets you keep your own code proprietary, while static linking imposes additional obligations, and modifications to OCCT itself must be made available.
Get this reviewed by a lawyer, not a forum post. Licence obligations depend on how you link and distribute, and the details matter commercially. This is a genuinely important question for any product you intend to sell, and it is cheap to answer properly at the start.
Choosing by product shape
| Your product | Sensible default | Why |
|---|---|---|
| High-priced desktop CAD | Parasolid / ACIS | Royalty is absorbed; robustness is the differentiator |
| Low-priced or freemium SaaS | Open CASCADE | Royalty would exceed margin |
| Embedded / high volume | Open CASCADE or custom | Per-unit royalties compound badly |
| Internal engineering tool | Commercial | Few seats; engineering time is the scarce resource |
| Narrow geometry domain | Custom kernel | Problem may be small enough to own outright |
| Browser-based (WASM) | Open CASCADE | Established WASM builds; no per-user royalty |
Protect yourself whichever you pick
- Abstract behind your own interface. Do not scatter kernel calls through your codebase — it makes any future change catastrophic.
- Build a regression suite of real geometry early, including the ugly files. This is how you detect robustness problems before customers do.
- Design the failure path. Operations will fail; decide what the user sees and how state stays valid.
- Benchmark on your own models, not vendor demos.
Deciding on a kernel for a product? Tell us your pricing model and geometry needs — the commercial constraint usually settles it quickly. See our CAD kernel service, or read what a CAD kernel actually is.