It’s not about failing, but exposing a financial risk of needing to pay backwards for licensing. Not everything has to have a licensing kill-switch to accrue liability (see any intrusive open source license that requires you to open source yourself).
Going lawyery on it, it’s not necessarily 100% clear cut.
From one hand, there’s the indemnification clause:
7.1 UiPath Indemnification. UiPath, at its expense, will defend Customer against any claim, action, or legal proceeding made against Customer by a third-party non-affiliated with the Customer alleging that the use of the Technology, during the License Term
and as delivered by UiPath, infringes the third party’s patent or copyright or that UiPath misappropriated the third party’s trade secret (“IP Claim”) and will indemnify against any damages finally awarded to Customer by a court of competent jurisdiction
(or settlement amounts agreed to in writing by UiPath) in the limits set out in this Agreement
(emphasis mine)
So reading just that, UiPath will indemnify, or in other words, shield if a company like Xceed would start going around and demanding license payment from anyone using UiPath.word.activities package.
That said, the Technology is defined as:
“Technology” means each and together, the (i) Software identified in the applicable Order, (ii) materials developed by UiPath for Customer, including during performance of Services, and (iii) UiPath Background IPR.
And the license granted is:
3.1 License. Subject to the terms and conditions of this Agreement, UiPath grants Customer and its Affiliates, upon delivery and during the License Term, a limited, non-exclusive, non-sublicensable, non-transferable, worldwide right to access and use the
Technology specified in the applicable Order, solely for their internal business purposes and in accordance with the applicable Licensing Policy and the associated Documentation.
Is the Word package part of the licensed Technology? You could argue that it is (it’s an official source tied to the Technology itself), and common sense would agree with you, but when it comes to contracts, and especially IP related stuff in contracts, common sense has no power there (and interpretations can differ in various jurisdictions - f.e. IP rights in EU vs US vs Japan are very different).
On the pure licensing terms perspective, the additional packages you install are your own choice, and you have agreed to their terms and conditions.
So it’s not as clear cut without an explicit waiver.
For example - if I built a wrapper around Xceed for some use case, and license the wrapper itself under MIT (which I can - it’s my creation), that does not waive Xceed’s right to money if you use it without having a license. Or in other words, vetting dependency chains is part of due diligence, and should be commended. So definitely kudos to @gediminas for raising this up.
That 4.3 paragraph is very explicit about open source, but it’s very silent about closed source/paid-license works (btw - a thing can be open source and still require a license payment. Open source != free).
So while it’s 99% fine, and UiPath would expose themselves to a massive class action if Xceed would start suing UiPath users for infringement and they wouldn’t step in, it would be great if the 4.3 paragraph (or the technology definition) would be expanded/clarified to cover licensing of dependencies for UiPath official packages.
@loginerror - tagging you here, as you could probably cut the whole discussion short and confirm that indeed UiPath does secure redistribution licensing from their paid-license dependencies on official packages.