{"id":4034,"date":"2026-10-22T11:52:19","date_gmt":"2026-10-22T11:52:19","guid":{"rendered":"https:\/\/sawaryn.com\/?p=4034"},"modified":"2026-10-22T12:01:33","modified_gmt":"2026-10-22T12:01:33","slug":"open-source-product-licenses-investor-due-diligence","status":"publish","type":"post","link":"https:\/\/sawaryn.com\/en\/publikacje\/open-source-product-licenses-investor-due-diligence\/","title":{"rendered":"Open Source in Your Product. How to Organize Licenses Before Your Investor Does."},"content":{"rendered":"

Your code is the company\u2019s most valuable asset. Yet you probably do not know what most of it consists of\u2014or the terms on which you are entitled to use it. You will find out in detail the week an investor opens the data room or an enterprise client sends you an intellectual property<\/a> questionnaire. That is the most expensive time to discover that a copyleft-licensed library sits at the heart of your product.<\/p>\n

Open-source licenses<\/strong> are not a technical detail. They are a source of legal obligations for your company and its product. Each imposes its own set of obligations\u2014from crediting authors and making source code available to complying with patent clauses. Breaching these terms may result in the loss of the legal right to use the component, copyright claims and\u2014often most painful of all\u2014a blocked funding round or enterprise contract.<\/p>\n

In this article, I will walk through the specific risks that open source in a product<\/strong> creates for technology companies and explain how to bring them under control\u2014without bringing the product roadmap to a halt or delivering a lecture on copyleft.<\/p>\n

Key concepts before we move on<\/h2>\n

Before discussing risks and recommendations, it is worth clarifying a few terms that will appear throughout this article.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Term<\/th>\nMeaning<\/th>\n<\/tr>\n<\/thead>\n
Open-source license<\/strong><\/td>\nA license agreement granting broad rights (use, copying, modification, distribution) subject to specific conditions\u2014such as attribution or making source code available<\/td>\n<\/tr>\n
Copyleft<\/strong><\/td>\nA type of license (e.g. GPL, AGPL) requiring derivative code to be made available under the same terms\u2014the so-called “viral” effect<\/td>\n<\/tr>\n
Permissive license<\/strong><\/td>\nA type of license (e.g. MIT, Apache 2.0, BSD) that allows a component to be incorporated into proprietary commercial code with minimal obligations<\/td>\n<\/tr>\n
SBOM<\/strong><\/td>\nA Software Bill of Materials\u2014a list of all dependencies in a product, including their versions and licenses<\/td>\n<\/tr>\n
Chain of title<\/strong><\/td>\nAn unbroken chain of copyright transfers relating to the code\u2014from every individual who created it to the company<\/td>\n<\/tr>\n
Due diligence (DD)<\/strong><\/td>\nA legal and technological review of a company conducted before a transaction (funding round, acquisition, sale)<\/td>\n<\/tr>\n
R&W (representations & warranties)<\/strong><\/td>\nRepresentations and warranties made in a transaction agreement\u2014e.g. regarding title to IP and license compliance<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Computer programs are protected by copyright under the Act of 4 February 1994 on Copyright and Related Rights<\/a> and Directive 2009\/24\/EC<\/a>. An open-source license is not a waiver of rights\u2014it is an instrument granting permission to exercise exclusive rights subject to specified conditions.<\/p>\n

Why open source in a product creates transaction risk<\/h2>\n

96% of organisations increased or maintained their use of open-source software in 2024, while 53% of respondents cited cost reduction as the main reason for choosing OSS. The question is therefore not “do you have open source in your product?”, but “do you know the terms on which you use it?”.<\/p>\n

The problem is that most technology companies do not maintain an inventory of their components. A lack of visibility means a lack of control\u2014the organisation cannot assess the scale of the risk or demonstrate license compliance.<\/p>\n

The issue is ignored until it becomes a real problem. And it materialises in three situations:<\/p>\n

    \n
  1. A funding round or exit<\/strong>\u2014the investor opens the data room and asks for a list of components, licenses and the chain of title<\/li>\n
  2. A sale to an enterprise client<\/strong>\u2014the client requires representations and warranties regarding IP and license compliance<\/li>\n
  3. A change in the distribution model<\/strong>\u2014switching from SaaS to on-premise or vice versa changes the scope of license obligations<\/li>\n<\/ol>\n

    In each of these scenarios, a lack of properly organised documentation means delays, a lower valuation or the loss of a contract.<\/p>\n

    License map\u2014what is and is not permitted<\/h2>\n

    Not every open-source license carries the same risk. The table below shows the practical differences between the most common license families.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
    License<\/th>\nType<\/th>\nSource code disclosure requirement<\/th>\nAttribution<\/th>\nPatent license<\/th>\nRisk to a commercial product<\/th>\n<\/tr>\n<\/thead>\n
    MIT<\/td>\nPermissive<\/td>\nNo<\/td>\nYes<\/td>\nNo<\/td>\nLow\u2014retain the notice and license text<\/td>\n<\/tr>\n
    BSD (2\/3-clause)<\/td>\nPermissive<\/td>\nNo<\/td>\nYes<\/td>\nNo<\/td>\nLow\u2014as with MIT<\/td>\n<\/tr>\n
    Apache 2.0<\/td>\nPermissive<\/td>\nNo<\/td>\nYes + changes must be identified<\/td>\nYes (express)<\/td>\nLow\u2014but do not ignore the patent clauses<\/td>\n<\/tr>\n
    LGPL<\/td>\nCopyleft (limited)<\/td>\nLibrary only<\/td>\nYes<\/td>\nNo<\/td>\nMedium\u2014depends on the linking method<\/td>\n<\/tr>\n
    MPL 2.0<\/td>\nCopyleft (file-level)<\/td>\nModified files<\/td>\nYes<\/td>\nYes<\/td>\nMedium\u2014copyleft limited to the file<\/td>\n<\/tr>\n
    GPL v2\/v3<\/td>\nCopyleft<\/td>\nYes\u2014upon distribution<\/td>\nYes<\/td>\nYes (v3)<\/td>\nHigh\u2014risk of proprietary code becoming “infected”<\/td>\n<\/tr>\n
    AGPL<\/td>\nCopyleft (network)<\/td>\nYes\u2014also in the SaaS model<\/td>\nYes<\/td>\nYes<\/td>\nHigh\u2014covers interaction over a network<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Permissive licenses<\/strong> (MIT, BSD, Apache 2.0) allow a component to be incorporated into proprietary commercial code. The obligations are limited to including information about the use of the component and crediting its authors. Apache 2.0 is not equivalent to MIT\u2014it includes additional provisions granting a patent license and requires modifications to be identified in the source code.<\/p>\n

    Copyleft licenses<\/strong> (GPL, AGPL) work differently. Using GPL means that you must grant a royalty-free license and provide users with free access to the complete source code. Breaching these terms results in the conditional or permanent loss of the right to use the component\u2014and consequently creates a risk of claims arising from the use of code without a legal basis.<\/p>\n

    GPL does not prohibit the commercial use of software. Business models based on paid implementation or maintenance services are possible. The restriction concerns the obligation to make source code available and license it free of charge\u2014which requires deliberate management of architecture and the distribution model.<\/p>\n

    The SaaS trap and the role of AGPL<\/h2>\n

    Many SaaS companies believe that copyleft licenses do not apply to them. The logic is simple: “we do not distribute binaries, so GPL does not apply to us”. This belief is partly justified\u2014but dangerous.<\/p>\n

    Under most licenses in the GPL family, the copyleft effect is not triggered in the SaaS model because the obligation to make code available arises only when the program is “conveyed”. Making functionality available to users over a network does not meet this condition\u2014as confirmed both by the widely accepted interpretation and by the position of the Free Software Foundation.<\/p>\n

    The exception is the AGPL license<\/strong> (GNU Affero GPL), created specifically to address this loophole. AGPL also imposes GPL principles on SaaS applications\u2014if users interact with the program over a network, you must make the source code available to them.<\/p>\n

    Directive 2009\/24\/EC<\/a> does not require a SaaS provider to publish source code\u2014such an obligation arises solely from the terms of the relevant license. AGPL is less common than GPL, but a single component under this license at the heart of a product is enough to change the position of the entire company.<\/p>\n

    What to check:<\/p>\n

      \n
    1. Whether your dependencies include AGPL-licensed components<\/li>\n
    2. How they are integrated with proprietary code\u2014linking, forks, modifications<\/li>\n
    3. Whether changing the distribution model (e.g. adding an on-premise version) will trigger obligations that did not exist under the SaaS model<\/li>\n<\/ol>\n

      What investors examine during technology due diligence<\/h2>\n

      Due diligence takes place after the term sheet<\/a> and before the transaction documents are executed, and covers the verification of IP, liabilities and taxes (PARP\u2014how to sell a startup<\/a>). For a technology company, code is its primary asset\u2014and this is precisely what the technology part of DD focuses on.<\/p>\n

      Documents investors expect<\/h3>\n\n\n\n\n\n\n\n\n\n\n
      Document<\/th>\nWhy it is needed<\/th>\n<\/tr>\n<\/thead>\n
      Repository with commit history<\/td>\nMakes it possible to verify who wrote the code and when<\/td>\n<\/tr>\n
      SBOM with component versions and licenses<\/td>\nShows what the product consists of and the terms governing its components<\/td>\n<\/tr>\n
      Agreements with employees and B2B contractors<\/td>\nConfirm the chain of title\u2014whether the company owns the rights to the code<\/td>\n<\/tr>\n
      NOTICE file \/ attributions<\/td>\nDemonstrates compliance with license obligations<\/td>\n<\/tr>\n
      Open-source policy<\/td>\nShows that the organisation manages risk deliberately<\/td>\n<\/tr>\n
      Exception register<\/td>\nDocuments informed decisions to use higher-risk components<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      Typical investor questions<\/h3>\n
        \n
      1. Does the company have full title to the code\u2014from every employee and contractor?<\/li>\n
      2. Does the product include GPL- or AGPL-licensed components? If so, how are they integrated?<\/li>\n
      3. Is the chain of title from B2B contractors documented in written agreements that expressly specify the fields of exploitation?<\/li>\n
      4. Have there been any security incidents or IP claims?<\/li>\n
      5. Do client agreements contain change-of-control clauses?<\/li>\n<\/ol>\n

        In its Guide for Startups (2024), the Patent Office of the Republic of Poland<\/a> highlights the need to determine who holds the respective IP rights, whether the solutions were created by founders, employees or contractors, and whether agreements governing those rights exist.<\/p>\n

        Consequences for the transaction agreement<\/h3>\n

        Disorganised licensing and an incomplete chain of title from B2B contractors are among the gaps most frequently identified in IP due diligence. In a transaction agreement (SPA), they result in:<\/p>\n

          \n
        1. Representations and warranties (R&W)<\/strong> regarding title to IP and license compliance\u2014if you cannot make them, the transaction becomes more complicated<\/li>\n
        2. Escrow or purchase price holdback<\/strong> where license risks or unclear contractor rights have been identified<\/li>\n
        3. Earn-out<\/strong> linked to measurable technology metrics\u2014instead of the full price being paid at closing<\/li>\n<\/ol>\n

          Each of these mechanisms means less money for the founder, paid later and with greater uncertainty.<\/p>\n

          Rights to code from B2B contractors\u2014the most common gap<\/h2>\n

          Article 74(3) of the Copyright Act<\/a> provides for the statutory acquisition of rights to a program by the employer\u2014but only within an employment relationship. This rule does not apply to B2B arrangements.<\/p>\n

          For a company to own the rights to code written by a contractor, it needs a written agreement transferring economic copyrights<\/a><\/strong> (Article 53 of the Act\u2014written form is required for validity). The agreement must expressly list the fields of exploitation (Article 41(2))\u2014a general clause covering “all rights” without identifying them is insufficient.<\/p>\n

          The appropriate fields of exploitation for a computer program are (Article 74(4)):<\/p>\n

            \n
          1. Reproduction of the program<\/li>\n
          2. Modification of the program (including translation, adaptation and changes to its arrangement)<\/li>\n
          3. Distribution of the program (including lending and rental)<\/li>\n<\/ol>\n

            An invoice or access to the repository alone is not a substitute for a written agreement transferring rights. The chain of title is ready for DD only when there is an unbroken chain of rights acquired from every individual involved in creating the code\u2014including the contractor\u2019s subcontractors.<\/p>\n

            Check:<\/p>\n

              \n
            1. Whether you have written agreements with every contractor who wrote code<\/li>\n
            2. Whether the agreements list the fields of exploitation under Article 74(4)<\/li>\n
            3. Whether the transfer of rights is linked to the acceptance of a specific deliverable (commit, acceptance report)<\/li>\n
            4. Whether the contractor used subcontractors\u2014and, if so, whether you also have agreements with them<\/li>\n<\/ol>\n

              AI coding assistants\u2014a new source of risk<\/h2>\n

              Tools such as GitHub Copilot generate code snippets that may be identical or substantially similar to code covered by an open-source license. If such a snippet enters your repository, three distinct problems may arise:<\/p>\n

                \n
              1. The need to comply with the terms of that component\u2019s license (notices, making code available)<\/li>\n
              2. The risk of a claim alleging infringement of economic copyrights<\/li>\n
              3. The inability to demonstrate the provenance of the code during due diligence<\/li>\n<\/ol>\n

                Article 1(1) and Article 74(1) of the Copyright Act<\/a> provide that a program is protected if it is the author\u2019s own intellectual creation. The mere fact that code was generated by AI does not determine either whether it is creative in nature or who holds the rights to use it. There is no Polish court ruling or public authority position on this issue.<\/p>\n

                Minimum control process:<\/p>\n

                  \n
                1. Review generated code before committing it<\/li>\n
                2. Scan for similarities to public repositories<\/li>\n
                3. Record the source and licenses of components<\/li>\n
                4. Prohibit entering the company\u2019s confidential code into prompts without a legal basis<\/li>\n<\/ol>\n

                  Upcoming regulations\u2014CRA and the SBOM requirement<\/h2>\n

                  CRA Regulation (EU) 2024\/2847<\/a> introduces a requirement to maintain a list of components (SBOM) for products with digital elements. Effective dates:<\/p>\n\n\n\n\n\n\n
                  Obligation<\/th>\nDate<\/th>\n<\/tr>\n<\/thead>\n
                  Vulnerability and incident reporting obligations<\/td>\nFrom 11 September 2026<\/td>\n<\/tr>\n
                  Full manufacturer obligations (including SBOM)<\/td>\nFrom 11 December 2027<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

                  A manufacturer incorporating an open-source component into a product with digital elements is liable as the manufacturer of the final product and should maintain an up-to-date SBOM. The CRA does not prescribe a mandatory format\u2014but CycloneDX and SPDX formats are already being used in public procurement (e.g. by the e-Health Centre) (e-Health Centre\u2014description of the subject matter of the contract<\/a>).<\/p>\n

                  NIS2 Directive (2022\/2555)<\/a>, Article 21(2)(d) and (e), imposes supply-chain security and vulnerability-management obligations on essential and important entities. NIS2 does not explicitly require an SBOM, but an SBOM may be a proportionate means of complying with these obligations.<\/p>\n

                  Enterprise client requirements may precede statutory obligations\u2014in which case they are contractual obligations. If your client requires an SBOM in 2026, the CRA is secondary to the provisions of the agreement.<\/p>\n

                  What to do\u2014a checklist for CTOs and founders<\/h2>\n

                  Bringing open-source licensing under control is a project that can be planned and completed without bringing the roadmap to a halt. Below are specific steps, arranged from urgent to supplementary.<\/p>\n

                  Priority actions<\/h3>\n
                    \n
                  1. Generate a dependency list (SBOM) for every repository and build.<\/strong> Without an inventory, you have nothing to manage. Use SCA (Software Composition Analysis) tools for automated scanning\u2014but remember that the tool identifies components, while the legal assessment requires a separate analysis.<\/li>\n
                  2. Classify the licenses identified into three categories:<\/strong> permitted without restrictions (MIT, BSD), conditionally permitted (Apache 2.0, LGPL, MPL), and prohibited in a commercial product without architectural changes (GPL, AGPL). Assign specific obligations to each.<\/li>\n
                  3. Verify the points where proprietary code interfaces with copyleft components.<\/strong> Check linking, forks and modifications. Identify areas where a component must be replaced or the architecture changed.<\/li>\n
                  4. Adopt an internal open-source policy.<\/strong> Determine who approves a new library, how the decision is documented, what is prohibited and what the exception process looks like. The policy should be brief and understandable to a developer\u2014not a lawyer.<\/li>\n<\/ol>\n

                    Supplementary actions<\/h3>\n
                      \n
                    1. Build license checks into the CI\/CD pipeline<\/strong>\u2014automatically scan dependencies and block prohibited licenses. No law requires this, but it is a reasonable way to enforce the policy without manual oversight.<\/li>\n
                    2. Prepare a document package for DD and enterprise questionnaires:<\/strong> a component inventory, NOTICE file\/attributions, OSS policy and exception register.<\/li>\n
                    3. Train the development team using specific examples:<\/strong> which licenses are safe, what copyleft means in SaaS, why code from Stack Overflow should not be pasted into the production repository, and how to handle AI-generated code.<\/li>\n
                    4. Review IP representations, warranties and indemnity clauses in current client agreements<\/strong>\u2014check whether you can actually comply with them.<\/li>\n
                    5. Schedule a recurring review<\/strong> (e.g. quarterly) of the dependency list and exception register. An audit is not a one-off event\u2014dependencies change with every sprint.<\/li>\n<\/ol>\n

                      Contact us<\/a><\/p>\n

                      How we can help you<\/h2>\n

                      Well-drafted agreements govern the use of open-source components in a project, including their registration, verification and approval. Liability provisions include specific rules relating to the obligation to implement replacement solutions and liability for costs incurred in connection with third-party claims caused by license infringement.<\/p>\n

                      We support technology companies in three areas:<\/p>\n\n\n\n\n\n\n\n
                      Area<\/th>\nWhat it includes<\/th>\n<\/tr>\n<\/thead>\n
                      Inventory and classification<\/strong><\/td>\nAudit of OSS and third-party components, license classification with a risk map, and a report with recommendations<\/td>\n<\/tr>\n
                      Policy and documentation<\/strong><\/td>\nInternal open-source policy, library approval rules for the team, and a document package for DD<\/td>\n<\/tr>\n
                      Transaction safeguards<\/strong><\/td>\nChain-of-title audit (agreements with B2B contractors), review of R&W and indemnity clauses in client agreements, and support in discussions with investors and enterprise clients<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

                      We step in before the transaction, not during it. The objective is to bring matters under control\u2014not restrict developers\u2019 work. We recommend changes to the code only where there is a genuine risk.<\/p>\n

                      Bring your licenses under control before the investor does<\/h2>\n

                      Open source<\/strong> in a product is not a problem in itself\u2014the problem is not knowing what is in your dependencies or the terms on which you use it. Bringing licenses under control in advance is a predictable project. Remediation under transaction pressure creates an opportunity cost in the form of a lower valuation, escrow and unplanned engineering work.<\/p>\n

                      If you are preparing for a funding round, planning to sell to enterprise clients or simply want to know where you stand\u2014contact us<\/a>. We will audit your components, help you implement a licensing policy and prepare the documentation expected by an investor or client.<\/p>\n

                      Frequently asked questions<\/h2>\n

                      Where should we start if we have dozens of repositories and no one knows what is in the dependencies?<\/strong><\/p>\n

                      Start with an inventory. Generate an SBOM (list of components) for every repository and build\u2014SCA tools do this automatically. Without a list, you have nothing to manage. Then classify the licenses identified into three categories: permitted, conditionally permitted and prohibited in a commercial product. Only after this stage will you know where the real risk lies and whether it requires changes to the code or merely completing the documentation.<\/p>\n

                      Do copyleft licenses apply to me at all under the SaaS model?<\/strong><\/p>\n

                      In most cases, GPL does not trigger an obligation to make code available under the SaaS model because the program is not “conveyed”. The exception is the AGPL license, created specifically to address this loophole\u2014it imposes an obligation to make source code available even when users interact with the program over a network. A single AGPL component in the product is enough to change the position of the entire company. Check your dependencies.<\/p>\n

                      What exactly do investors look for during technology due diligence?<\/strong><\/p>\n

                      Full title to the code (a chain of title from every employee and contractor), a list of components and licenses (SBOM), no copyleft components integrated with proprietary code without an informed decision, written agreements with B2B contractors expressly specifying the fields of exploitation, and an open-source management policy. The absence of these documents does not automatically terminate the transaction, but it results in protective mechanisms: escrow, a purchase price holdback or an earn-out\u2014which means less money, paid later and with greater uncertainty.<\/p>\n

                      Are dependency-scanning tools sufficient, or is a legal assessment required?<\/strong><\/p>\n

                      SCA tools identify components and assign licenses to them. This is an essential starting point. But whether a “derivative work” has been created within the meaning of a particular license depends on how the component is integrated\u2014linking, modifications and architecture. This requires a legal assessment. A tool will tell you that you have a GPL component. A lawyer will tell you whether the way you use it triggers the obligation to make your code available.<\/p>\n

                      What about code written by B2B contractors\u2014do we own the rights to it?<\/strong><\/p>\n

                      Not automatically. The statutory acquisition of rights by an employer applies only to an employment relationship (Article 74(3) of the Copyright Act). Under a B2B arrangement, you need a written agreement transferring economic copyrights and expressly listing the fields of exploitation. An invoice or access to the repository alone is not enough. Also check whether the contractor used subcontractors\u2014because you will then need agreements with them as well.<\/p>\n

                      Do AI coding assistants (Copilot) create new licensing risks?<\/strong><\/p>\n

                      Yes. Generated code may be identical or similar to code covered by an open-source license. If such a snippet enters the repository, you may breach the license terms, expose yourself to copyright claims and be unable to demonstrate the code\u2019s provenance during DD. Introduce a minimum process: review generated code before committing it, scan for similarities and prohibit entering the company\u2019s confidential code into prompts.<\/p>\n","protected":false},"excerpt":{"rendered":"

                      Learn how to inventory open-source components, assess copyleft risks and prepare license records and code ownership documents for investor due diligence.<\/p>\n","protected":false},"author":13,"featured_media":4040,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":"","sip_alt_url":"","sip_en_pl_url":"","sip_pair_uuid":"2dfc6204-53ea-4ab6-b004-f2a8f2ab29e3","sip_pair_state":"verified"},"categories":[1577],"tags":[1530,1538,1548,1537,1539],"specialization":[1211],"practice_area":[],"class_list":["post-4034","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-it-ai-ip-law","tag-b2b-agreement","tag-copyright-law","tag-due-diligence-en","tag-intellectual-property-en","tag-license","specialization-it-ai-ip-law"],"acf":[],"_links":{"self":[{"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/posts\/4034","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/comments?post=4034"}],"version-history":[{"count":5,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/posts\/4034\/revisions"}],"predecessor-version":[{"id":4042,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/posts\/4034\/revisions\/4042"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/media\/4040"}],"wp:attachment":[{"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/media?parent=4034"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/categories?post=4034"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/tags?post=4034"},{"taxonomy":"specialization","embeddable":true,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/specialization?post=4034"},{"taxonomy":"practice_area","embeddable":true,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/practice_area?post=4034"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}