Intellectual property rights (IPR) matter when deciding what to build, what to buy, and what a company can claim as its own. Identify the technology that makes the business distinctive: it may be original code, an algorithm, or the way existing components are brought together. Focus custom development there rather than rebuilding solutions available elsewhere. section 8.2 section 14.5.1
Make ownership and permitted use explicit at each handoff:
- For contracted work, state when IPR is assigned—upon payment or completion. Retaining rights to a delivered project does not necessarily give the team the learning gained while it was built. section 10.6 section 4.1.4
- For third-party software and borrowed code, record the licenses and their restrictions. If an open-source license permits copying a code block, register its use as you would use of the library. section 10.6 section 8.7.4
- Before relying on a company’s technology in a deal, ask what is unique, who owns relevant patents, and who owns the source code—particularly if principal development was outsourced. section 14.5.1
Code found on the web
A developer finds an answer in a help forum and pastes it into a company product. Public visibility alone does not make the code free to incorporate. The practical guidance is to use a substantial example for its algorithm rather than copy it with renamed variables, and to check licensing when the code comes from an open-source library. Provenance can matter later: a deal may involve checks of source-code ownership, and one described deal faltered when large portions of purportedly original code proved to come from open-source projects. section 8.7.4
A useful self-check is straightforward: Which parts of the solution are genuinely distinctive? Can you show who owns work delivered by contractors? Can you account for third-party code and its license restrictions? The answers help separate a valuable technical asset from an uncertain ownership claim. section 8.2 section 10.6
