Patent Application
20240020358
This disclosure relates generally to open source compliance management, and, more particularly to systems and methods for analyzing software products.
Use of Open source software (OSS) involves compliance with associated licenses that define specific rights made available by the copyright holder of OSS. Such compliance implies compliance with conditions associated with each component of OSS including fragments or sub-components. Currently there are approximately more than 1.2 million OSS components available under more than 2000 OSS license types. The large volume makes it challenging to analyze the OSS components technically and legally while developing a proprietary product and ensure OSS compliance at software packaging level, delivery level and compilation level.
Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems.
In an aspect, there is provided a processor implemented method comprising: receiving, a product under consideration embedded with one or more Open Source Software (OSS) components; comparing each of the one or more OSS components in the product under consideration with OSS components available in the public domain and comprised in a first OSS database (DB1) to identify one or more matches therebetween based on attributes associated thereof; categorizing, the one or more OSS components in the product under consideration having a match with the OSS components available in the first OSS database (DB1) as (i) OSS components having a strong copyleft license, (ii) OSS components having a permissive license or (iii) OSS components having a weak copyleft; identifying a usage type for the one or more OSS components in the product under consideration categorized as having the weak copyleft license and the permissive license, wherein the license usage type is one of a snippet, a file or a library and wherein the library is further identified as one of a library-executable or a library-binary; identifying as one or more unidentified components, the one or more OSS components in the product under consideration having no match with the OSS components available in the first OSS database (DB1) or having a match but characterized by at least one missing attribute; periodically comparing the one or more unidentified components with the OSS components in the first OSS database (DB1) to identify one or more new matches based on continual updation of OSS components available in the public domain; updating a second OSS database (DB2) comprising at least some of the one or more OSS components in the product under consideration having the one or more matches, the one or more new matches, the one or more unidentified components categorized as one or more proprietary components and OSS components previously available in the public domain; performing an OSS compliance analyses for the one or more OSS components in the product under consideration based on the usage type, the attributes associated thereof comprised in the second OSS database (DB2) and one or more pre-defined rules; and generating a comprehensive report (R5) based on the OSS compliance analyses, wherein the comprehensive report (R5) includes a final attribute for each of the one or more OSS components in the product under consideration indicative of compliance with the attributes of each of the one or more OSS components comprised therein.
In another aspect, there is provided a system comprising: one or more data storage devices operatively coupled to the one or more processors and configured to store instructions configured for execution by the one or more processors to: receive, a product under consideration embedded with one or more Open Source Software (OSS) components; compare each of the one or more OSS components in the product under consideration with OSS components available in the public domain and comprised in a first OSS database (DB1) to identify one or more matches therebetween based on attributes associated thereof; categorize, the one or more OSS components in the product under consideration having a match with the OSS components available in the first OSS database (DB1) as (i) OSS components having a strong copyleft license, (ii) OSS components having a permissive license or (iii) OSS components having a weak copyleft; identify a usage type for the one or more OSS components in the product under consideration categorized as having the weak copyleft license and the permissive license, wherein the license usage type is one of a snippet, a file or a library and wherein the library is further identified as one of a library-executable or a library-binary; identify as one or more unidentified components, the one or more OSS components in the product under consideration having no match with the OSS components available in the first OSS database (DB1) or having a match but characterized by at least one missing attribute; periodically compare the one or more unidentified components with the OSS components in the first OSS database (DB1) to identify one or more new matches based on continual updation of OSS components available in the public domain; update a second OSS database (DB2) comprising the one or more OSS components in the product under consideration having the one or more matches, the one or more new matches, the one or more unidentified components categorized as one or more proprietary components and OSS components previously available in the public domain; perform an OSS compliance analyses for the one or more OSS components in the product under consideration based on the usage type, the attributes associated thereof comprised in the second OSS database (DB2) and one or more pre-defined rules; and generate a comprehensive report (R5) based on the OSS compliance analyses, wherein the comprehensive report (R5) includes a final attribute for each of the one or more OSS components in the product under consideration indicative of compliance with the attributes of each of the one or more OSS components comprised therein.
In yet another aspect, there is provided a computer program product comprising a non-transitory computer readable medium having a computer readable program embodied therein, wherein the computer readable program, when executed on a computing device, causes the computing device to: receive, a product under consideration embedded with one or more Open Source Software (OSS) components; compare each of the one or more OSS components in the product under consideration with OSS components available in the public domain and comprised in a first OSS database (DB1) to identify one or more matches therebetween based on attributes associated thereof; categorize, the one or more OSS components in the product under consideration having a match with the OSS components available in the first OSS database (DB1) as (i) OSS components having a strong copyleft license, (ii) OSS components having a permissive license or (iii) OSS components having a weak copyleft; identify a usage type for the one or more OSS components in the product under consideration categorized as having the weak copyleft license and the permissive license, wherein the license usage type is one of a snippet, a file or a library and wherein the library is further identified as one of a library-executable or a library-binary; identify as one or more unidentified components, the one or more OSS components in the product under consideration having no match with the OSS components available in the first OSS database (DB1) or having a match but characterized by at least one missing attribute; periodically compare the one or more unidentified components with the OSS components in the first OSS database (DB1) to identify one or more new matches based on continual updation of OSS components available in the public domain; update a second OSS database (DB2) comprising the one or more OSS components in the product under consideration having the one or more matches, the one or more new matches, the one or more unidentified components categorized as one or more proprietary components and OSS components previously available in the public domain; perform an OSS compliance analyses for the one or more OSS components in the product under consideration based on the usage type, the attributes associated thereof comprised in the second OSS database (DB2) and one or more pre-defined rules; and generate a comprehensive report (R5) based on the OSS compliance analyses, wherein the comprehensive report (R5) includes a final attribute for each of the one or more OSS components in the product under consideration indicative of compliance with the attributes of each of the one or more OSS components comprised therein.
In an embodiment of the present disclosure, the one or more hardware processors are further configured to generate one or more reports comprising: a first report (R1) pertaining to the one or more unidentified components; a second report (R2) pertaining to the one or more OSS components in the product under consideration having the strong copyleft license; a third report (R3) pertaining to the one or more OSS components in the product under consideration having the weak copyleft license; and a fourth report (R4) pertaining to the one or more OSS components in the product under consideration having the permissive license.
In an embodiment of the present disclosure, the one or more hardware processors are further configured to adaptively learn the one or more OSS components and the attributes associated thereof comprised in the comprehensive report (R5) and update the second OSS database (DB2).
In an embodiment of the present disclosure, at least the second OSS database (DB2) has a pre-defined format comprising the attributes including OSS component name, OSS component version, OSS component home page URL, OSS component license type, OSS component license URL, OSS component attribution note, license usage type, commercial distribution permission, OSS component compile permission, license compatibility with the OSS component license type associated with other OSS components comprised in the product or compatibility with proprietary license.
In an embodiment of the present disclosure, the one or more hardware processors are further configured to perform the OSS compliance analyses by: combining the first report (R1), the second report (R2), the third report (R3) and the fourth report (R4); and generating the final attribute, wherein the one or more pre-defined rules comprise: Rule 1 wherein an OSS component is rejected if associated with the strong copy left license; Rule 2 wherein an OSS component is approved for inclusion in the second OSS database (DB2) if associated with the weak copy left license and the OSS usage type is one of the library not compiled with the product or the file not compiled with the product; Rule 3 wherein an OSS component is rejected if associated with the weak copy left license and the OSS usage type is the snippet; Rule 4 wherein an OSS component is approved for inclusion in the second OSS database (DB2) if associated with the permissive license and the OSS usage is one of the library, the snippet, or the file; and Rule 5 wherein an OSS component is rejected if associated with the weak copy left license and the OSS usage type is one of the library compiled with the product or the file compiled with the product.
For example, in one aspect, there is provided a processor implemented method for analyzing open source components in software products. The method comprises receiving an input comprising at least one of (i) one or more Open Source Software (OSS) components, (ii) one or more code blocks comprised in a software product, and (iii) the software product embedded with the one or more OSS components; performing a first comparison of the input with a second database (DB2) to identify a first set of matched OSS components and a first set of unidentified components; performing a second comparison of the first set of unidentified components with a first database (DB1) to obtain a second set of matched OSS components; and categorizing based on licensing information, the first set of matched OSS components and the second set of matched OSS components as (i) OSS components having a strong copyleft license, (ii) OSS components having a permissive license, or (iii) OSS components having a weak copyleft license.
In an embodiment, the method further comprises applying a permission matrix on the first set of matched OSS components and the second set of matched OSS components as having the strong copyleft license, the weak copyleft license and the permissive license to generate a set of recommendations for each license-usage combination, wherein the permission matrix comprises a license information, an associated project type, an associated dependency scenario, and one or more license specific attributes, and a license usage type.
In an embodiment, the method further comprises identifying a second set of unidentified components based on the second comparison; and generating a report based on the second set of unidentified components.
In an embodiment, the method further comprises performing a third comparison of one or more unidentified components from the second set of unidentified components with at least one of (i) one or more logs of a code generation tool that generated the one or more unidentified components, and (ii) one or more associated indicators comprised in the second set of unidentified components, to obtain a first set of generated components, a second set of generated components, and a third set of unidentified components; and generating at least one of a first comprehensive report and a second comprehensive report based on the third comparison.
In an embodiment, the method further comprises performing a fourth comparison of the first comprehensive report and the second comprehensive report for eliminating one or more redundancies comprised therein.
In an embodiment, the code generation tool comprises at least one of a generative artificial intelligence (AI) model, a model-driven generation tool, and a grammar-driven generation tool.
In an embodiment, the second database (DB2) comprises information pertaining to a plurality of OSS components, a license permission pertaining to the plurality of OSS components, the permission matrix comprising the license information, the associated project type, the associated dependency scenario, the license usage type, and one or more license specific attributes.
In an embodiment, the permission matrix enables a permission flag indicating at least one of an allowed flag, a not allowed flag, and a conditionally allowed flag pertaining to the associated dependency scenario and the associated project type.
In an embodiment, the method further comprises periodically updating the second database (DB2) with the second set of matched OSS components.
In an embodiment, the method further comprises generating, in real-time, the one or more recommendations, and the one or more guidelines for each of the plurality of OSS components with respect to one or more license obligations and restrictions during a software product development.
In an embodiment, the one or more recommendations are generated for (i) the allowed flag, (ii) the conditionally allowed flag, and one or more guidelines are generated for each of the plurality of OSS components with respect to one or more license obligations and restrictions for the allowed flag, and the conditionally allowed flag and (iii) one or more associated reasons for the not allowed flag.
In an embodiment, the method further comprises detecting during the software product development, a dependency scenario, a project type, and querying the second database to provide one or more recommendations in real-time.
In an embodiment, the method further comprises detecting, during a software product development, one or more generated components suggested by the code generated tool and accepted for inclusion in the software product; and populating a third database (DB3) with the one or more generated components suggested by the code generated tool.
In an embodiment, the method further comprises performing a fifth comparison of one or more unidentified components from the second set of unidentified components with a third database (DB3) comprising one or more generated components to identify at least one of one or more matched generated components and a fourth set of unidentified components.
In an embodiment, a recommendation report is generated comprising at least one of a name of OSS component, a version of OSS component, a Uniform Resource Locator (URL) for OSS, an Applicable OSS License, License Type, a URL for OSS License, a Project Type, a dependency scenario, the one or more guidelines, and one or more recommendations for conditionally allowed flags.
In another aspect, there is provided a method for analyzing software products. The method comprises: receiving an input comprising at least one of (i) one or more Open Source Software (OSS) components, (ii) one or more code blocks comprised in a software product, and (iii) the software product embedded with the one or more OSS components; performing a first comparison of the input with a second database (DB2) to identify a first set of matched OSS components and a first set of unidentified components; performing a second comparison of the first set of unidentified components with a third database (DB3) comprising one or more generated components suggested by a code generated tool for inclusion in the software product to identify at least one of a first set of generated components and a second set of unidentified components, wherein the first set of matched OSS components is categorized as (i) OSS components having a strong copyleft license, (ii) OSS components having a permissive license, or (iii) OSS components having a weak copyleft license.
In yet another aspect, there is provided a processor implemented system for analyzing open source components in software products. The system comprises: a memory storing instructions; one or more communication interfaces; and one or more hardware processors coupled to the memory via the one or more communication interfaces, wherein the one or more hardware processors are configured by the instructions to: receive an input comprising at least one of (i) one or more Open Source Software (OSS) components, (ii) one or more code blocks comprised in a software product, and (iii) the software product embedded with the one or more OSS components; perform a first comparison of the input with a second database (DB2) to identify a first set of matched OSS components and a first set of unidentified components; perform a second comparison of the first set of unidentified components with a first database (DB1) to obtain a second set of matched OSS components; and categorize based on licensing information, the first set of matched OSS components and the second set of matched OSS components as (i) OSS components having a strong copyleft license, (ii) OSS components having a permissive license, or (iii) OSS components having a weak copyleft license.
In an embodiment, the one or more hardware processors are further configured by the instructions to apply a permission matrix on the first set of matched OSS components and the second set of matched OSS components as having the strong copyleft license, the weak copyleft license and the permissive license to generate a set of recommendations for each license-usage combination, wherein the permission matrix comprises a license information, an associated project type, an associated dependency scenario, and one or more license specific attributes, and a license usage type.
In an embodiment, the one or more hardware processors are further configured by the instructions to identify a second set of unidentified components based on the second comparison; and generate a report based on the second set of unidentified components.
In an embodiment, the one or more hardware processors are further configured by the instructions to perform a third comparison of one or more unidentified components from the second set of unidentified components with at least one of (i) one or more logs of a code generation tool that generated the one or more unidentified components, and (ii) one or more associated indicators comprised in the second set of unidentified components, to obtain a first set of generated components, a second set of generated components, and a third set of unidentified components; and generate at least one of a first comprehensive report and a second comprehensive report based on the third comparison.
In an embodiment, the one or more hardware processors are further configured by the instructions to perform a fourth comparison of the first comprehensive report and the second comprehensive report for eliminating one or more redundancies comprised therein.
In an embodiment, the code generation tool comprises at least one of a generative artificial intelligence (AI) model, a model-driven generation tool, and a grammar-driven generation tool.
In an embodiment, the second database (DB2) comprises information pertaining to a plurality of OSS components, a license permission pertaining to the plurality of OSS components, the permission matrix comprising the license information, the associated project type, the associated dependency scenario, the license usage type, and one or more license specific attributes.
In an embodiment, the permission matrix enables a permission flag indicating at least one of an allowed flag, a not allowed flag, and a conditionally allowed flag pertaining to the associated dependency scenario and the associated project type.
In an embodiment, one or more recommendations are generated for (i) the allowed flag, (ii) the conditionally allowed flag, and one or more guidelines are generated for each of the plurality of OSS components with respect to one or more license obligations and restrictions for allowed flag and conditionally allowed flag, and (iii) one or more associated reasons for the not allowed flag.
In an embodiment, the second database (DB2) is periodically updated with the second set of matched OSS components.
In an embodiment, the one or more hardware processors are further configured by the instructions to generate, in real-time, the one or more recommendations, and the one or more guidelines for each of the plurality of OSS components with respect to one or more license obligations and restrictions during a software product development.
In an embodiment, the one or more hardware processors are further configured by the instructions to detect during the software product development, a dependency scenario, a project type, and querying the second database to provide one or more recommendations in real-time.
In an embodiment, the one or more hardware processors are further configured by the instructions to detect, during a software product development, one or more generated components suggested by the code generated tool and accepted for inclusion in the software product; and populate a third database (DB3) with the one or more generated components suggested by the code generated tool.
In an embodiment, the one or more hardware processors are further configured by the instructions to perform a fifth comparison of one or more unidentified components from the second set of unidentified components with a third database (DB3) comprising one or more generated components suggested by a code generated tool for inclusion in the software product to identify at least one of one or more matched generated components and a fourth set of unidentified components.
In an embodiment, a recommendation report is generated comprising at least one of a name of OSS component, a version of OSS component, a Uniform Resource Locator (URL) for OSS, an Applicable OSS License, License Type, a URL for OSS License, a Project Type, a dependency scenario, the one or more guidelines, and one or more recommendations for conditionally allowed flags.
In a further aspect, there are provided one or more non-transitory machine-readable information storage mediums comprising one or more instructions which when executed by one or more hardware processors cause a method for analyzing open source components in software products by receiving an input comprising at least one of (i) one or more Open Source Software (OSS) components, (ii) one or more code blocks comprised in a software product, and (iii) the software product embedded with the one or more OSS components; performing a first comparison of the input with a second database (DB2) to identify a first set of matched OSS components and a first set of unidentified components; performing a second comparison of the first set of unidentified components with a first database (DB1) to obtain a second set of matched OSS components; and categorizing based on licensing information, the first set of matched OSS components and the second set of matched OSS components as (i) OSS components having a strong copyleft license, (ii) OSS components having a permissive license, or (iii) OSS components having a weak copyleft license.
In an embodiment, the one or more instructions which when executed by one or more hardware processors further cause applying a permission matrix on the first set of matched OSS components and the second set of matched OSS components as having the strong copyleft license, the weak copyleft license and the permissive license to generate a set of recommendations for each license-usage combination, wherein the permission matrix comprises a license information, an associated project type, an associated dependency scenario, and one or more license specific attributes, and a license usage type.
In an embodiment, the one or more instructions which when executed by one or more hardware processors further cause identifying a second set of unidentified components based on the second comparison; and generating a report based on the second set of unidentified components.
In an embodiment, the one or more instructions which when executed by one or more hardware processors further cause performing a third comparison of one or more unidentified components from the second set of unidentified components with at least one of (i) one or more logs of a code generation tool that generated the one or more unidentified components, and (ii) one or more associated indicators comprised in the second set of unidentified components, to obtain a first set of generated components, a second set of generated components, and a third set of unidentified components; and generating at least one of a first comprehensive report and a second comprehensive report based on the third comparison.
In an embodiment, the one or more instructions which when executed by one or more hardware processors further cause performing a fourth comparison of the first comprehensive report and the second comprehensive report for eliminating one or more redundancies comprised therein.
In an embodiment, the code generation tool comprises at least one of a generative artificial intelligence (AI) model, a model-driven generation tool, and a grammar-driven generation tool.
In an embodiment, the second database (DB2) comprises information pertaining to a plurality of OSS components, a license permission pertaining to the plurality of OSS components, the permission matrix comprising the license information, the associated project type, the associated dependency scenario, the license usage type, and one or more license specific attributes.
In an embodiment, the permission matrix enables a permission flag indicating at least one of an allowed flag, a not allowed flag, and a conditionally allowed flag pertaining to the associated dependency scenario and the associated project type.
In an embodiment, the one or more instructions which when executed by one or more hardware processors further cause periodically updating the second database (DB2) with the second set of matched OSS components.
In an embodiment, the one or more instructions which when executed by one or more hardware processors further cause generating, in real-time, the one or more recommendations, and the one or more guidelines for each of the plurality of OSS components with respect to one or more license obligations and restrictions during a software product development.
In an embodiment, the one or more recommendations are generated for (i) the allowed flag, (ii) the conditionally allowed flag, and one or more guidelines are generated for each of the plurality of OSS components with respect to one or more license obligations and restrictions for the allowed flag, and the conditionally allowed flag, and (iii) one or more associated reasons for the not allowed flag.
In an embodiment, the one or more instructions which when executed by the one or more hardware processors further cause detecting during the software product development, a dependency scenario, a project type, and querying the second database to provide one or more recommendations in real-time.
In an embodiment, the one or more instructions which when executed by the one or more hardware processors further cause detecting, during a software product development, one or more generated components suggested by the code generated tool and accepted for inclusion in the software product; and populating a third database (DB3) with the one or more generated components suggested by the code generated tool.
In an embodiment, the one or more instructions which when executed by the one or more hardware processors further cause performing a fifth comparison of one or more unidentified components from the second set of unidentified components with a third database (DB3) comprising one or more generated components suggested by a code generated tool for inclusion in the software product to identify at least one of one or more matched generated components and a fourth set of unidentified components. The expressions ‘third set of unidentified components’ and ‘fourth set of unidentified components’ are referred to as ‘proprietary components’ or human generated components (e.g., components authored by human developer) and interchangeably used herein.
In an embodiment, a recommendation report is generated comprising at least one of a name of OSS component, a version of OSS component, a Uniform Resource Locator (URL) for OSS, an Applicable OSS License, License Type, a URL for OSS License, a Project Type, a dependency scenario, the one or more guidelines, and one or more recommendations for conditionally allowed flags.
In yet a further aspect, there are provided one or more non-transitory machine-readable information storage mediums comprising one or more instructions which when executed by one or more hardware processors cause analyzing software products by receiving an input comprising at least one of (i) one or more Open Source Software (OSS) components, (ii) one or more code blocks comprised in a software product, and (iii) the software product embedded with the one or more OSS components; performing a first comparison of the input with a second database (DB2) to identify a first set of matched OSS components and a first set of unidentified components; and performing a second comparison of the first set of unidentified components with a third database (DB3) comprising one or more generated components suggested by a code generated tool for inclusion in the software product to identify at least one of a first set of generated components and a second set of unidentified components, wherein the first set of matched OSS components is categorized as (i) OSS components having a strong copyleft license, (ii) OSS components having a permissive license, or (iii) OSS components having a weak copyleft license.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles.
Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the scope of the disclosed embodiments.
Systems and methods of the present disclosure aim to overcome legal complications that may arise when using open source software (OSS) and generated components in software products. Solutions that implement open source software components are enforced by open source license terms and conditions such as General Public License (GPL), Lesser General Public License (LGPL), Massachusetts Institute of Technology (MIT) License, Berkeley Software Distribution (BSD), Apache, and the like. These open source licenses have their own attributes which specify distribution rights, sublicense rights, packaging rights, code matches, binary matches, and the like. These attributes differ depending on the license types, permissible usage, license terms, expiry of terms, scope of usage, warranty, etc. There are approximately 2000 license types in the OSS world today which govern more than 12 lakh OSS components. The number of attributes may therefore be at least 10 times more than the license types when summed. The present disclosure provides intelligence to categories of OSS components in such a manner that the systems and methods of the present disclosure can read the categorization logically and can provide appropriate compliance output.
Referring now to the drawings, and more particularly to
The I/O interface device(s) 106 can include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like and can facilitate multiple communications within a wide variety of networks N/W and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. In an embodiment, the I/O interface device(s) can include one or more ports for connecting a number of devices to one another or to another server.
The memory 102 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random-access memory (SRAM) and dynamic-random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment, a database 108 is comprised in the memory 102. The memory 102 further comprises (or may further comprise) information pertaining to input(s)/output(s) of each step performed by the systems and methods of the present disclosure. In other words, input(s) fed at each step and output(s) generated at each step are comprised in the memory 102 and can be utilized in further processing and analysis.
In an embodiment of the present disclosure, the one or more processors 104 are configured to receive, at step 202, a product under consideration embedded with one or more Open Source Software (OSS) components. It may be understood that in the context of the present disclosure, the expression ‘product’ used herein refers to a software product.
Let DB1 represent a first Open Source Software (OSS) database of OSS components available in the public domain. The first OSS database (DB1) may be available in the public domain or may be populated by the system 100 of the present disclosure based on OSS components available in the public domain. An exemplary public OSS database DB1 with OSS components having exemplary attributes may be represented as shown in Table 1 herein below.
indicates data missing or illegible when filed
In an embodiment, a product under consideration embedded with one or more Open source software (OSS) components that need to be analyzed for OSS compliance and also prevent OSS contamination of proprietary components is received by the system 100 of the present disclosure at step 202 (
In an embodiment, the one or more processors 104 are configured to identify, at step 208 (
The OSS components of the product under consideration having no match or having a match but characterized by one or more missing attributes are identified as unidentified components at step 210 (
The OSS components available in the public domain and comprised in the first OSS database (DB1) are updated continually based information available via the World Wide Web. Therefore, in accordance with an embodiment of the present disclosure, the one or more processors 104 are configured to periodically compare, at step 212 (
Furthermore, in accordance with the present disclosure a customized knowledge base is adaptively learnt in the form of a second OSS database (DB2), at step 214 (
In an embodiment, at least the second OSS database (DB2) has a pre-defined format comprising the attributes including OSS component name, OSS component version, OSS component home page URL, OSS component license type, OSS component license URL, OSS component attribution note, license usage type, commercial distribution permission, OSS component compile permission, license compatibility with the OSS component license type associated with other OSS components comprised in the product or compatibility with proprietary license. The pre-defined format is configured to facilitate faster retrieval of information comprised therein as compared to fetching information based on metadata.
In an embodiment, the second OSS database (DB2) having exemplary attributes may be represented as shown in Table 2 herein below.
indicates data missing or illegible when filed
In an embodiment, the one or more processors 104 are configured to generate one or more reports, at step 222. For instance, post identification of the unidentified components at step 210 (
In an embodiment, the one or more processors 104 are configured to perform an OSS compliance analyses, at step 216 (
In an embodiment, an exemplary comprehensive report (R5) may be as represented in Table 3 below.
In an embodiment of the present disclosure, the step of performing an OSS compliance comprises firstly combining the first report (R1), the second report (R2), the third report (R3) and the fourth report (R4). The final attribute is then generated, wherein the pre-defined rules, in accordance with an embodiment of the present disclosure, may include:
Further to Table 3 above, the final attribute in an exemplary comprehensive report (R5) may be generated as shown in Table 4 herein below.
When the final attribute values generated are “Y” for all the OSS components used in a product under consideration, it may be deemed as compliant with attributes of each of the one or more OSS components comprised therein and accordingly safe to use. The above mentioned attributes Commercialization (Com), Snippets(Snip), Modify (Mod) are primarily indicative of the attributes for Open source components used as part of software development; whereas the attributes File (Fil), Components (Static Library) (Comps), Components (Dynamic Library) (Compd) indicate how listed open source components may be used as part of software development. Again, the attributes Distribute with Proprietary code (DP), Compile with Proprietary code (CP) indicate whether the open source component can be compiled with proprietary product code (P1, P2 . . . Pn) and can be distributed with proprietary product code (P1, P2 . . . Pn).
In an embodiment, all the OSS components listed in the second OSS database (DB2) may have defined associated attributes as illustrated in tables herein above. For example Commercialization (Com) may be O1Com, Snippets (Snip) may be O1Snip, Modify (Mod) may be O1Mod, File (Fil) may be O1Fil, Components (Static Library) (Comps) may be O1Comps, Components (Dynamic Library) (Compd) may be O1Compd etc. Further the attributes of each OSS components may be Yes or No based on the determination of commercial usage applicability. For example, if Commercialization (Com) for O1 is Yes then the parameter may be O1ComY. If Commercialization (Com) for O1 is No, then the parameter may be O1ComN. Likewise for Snip, the values are O1 SnipY and O1SnipN, for Mod, the values are O1ModY and O1ModN, for Fil, the values are O1FilY and O1FilN, for Comps, the values are O1CompsY and O1CompsN, for Compd, the values are O1CompdY and O1CompdN etc.
Based on the final attribute generated, the system 100 determines which of the OSS components may be selected for deliverable. Further, there may be scenarios wherein some of the OSS components are compliant and can be part of a final deliverable but cannot be compiled. For example weak copyleft license (GNU lesser general public license, Sun Binary code license as like). In an embodiment, the system is configured to create a list of OSS components which may be compiled with proprietary code; and another set of OSS components which may be part of a final deliverable but may not be compiled.
In an embodiment, the system 100 is configured to define usage of open source components as Snippets (Snip), File (Fil), Components (Static Library) (Comps), Components (Dynamic Library) (Compd), Further the system 100 may be configured to determine if a component is modified. In an embodiment, if the usage is snippets (Snip) for any open source component, then the associated attribute is modification.
In an embodiment the second OSS database (DB2) may be updated with the one or more OSS components and associated attributes comprised in the comprehensive report (R5), at step 220 (
Thus intelligence associated with the systems and methods of the present disclosure facilitate a matrix, by analyzing a set of OSS components (refer Table 2, Table 3 and Table 4 of DB2) to identify OSS components that may be compiled in a final deliverable and also facilitate the product owner to identify proprietary intellectual property that may be suitably protected and licensed without contamination by the accompanying OSS components in the product under consideration. An analysis of the OSS components and their attributes in consideration with the pre-defined rules ensure that inter-license compatibilities are checked and compliance with respect to compilation and distribution in a final deliverable is achieved, thereby ensuring that the OSS components retained in the final deliverable retain their intellectual property. For instance, a final deliverable may be P1 and/or P2 and/or . . . Pn while enforcing proprietary End User License Agreement (PEULA).
At step 402 of the method of the present disclosure, the one or more hardware processors 104 receive an input comprising at least one of (i) one or more Open Source Software (OSS) components, (ii) one or more code blocks comprised in a software product, and (iii) the software product embedded with the one or more OSS components. In other words, the input may be either only OSS component(s), code blocks from a software product, or the software product embedded with the one or more OSS components. The expression ‘software product’ may be referred as software systems delivered or made available as a service to consumers/end user with a documentation that describes how to install and/or use the system. In certain cases, software products may be part of system products where hardware, as well as software, is delivered or made available as a service to the end user. The input is received and is further to be analyzed for OSS compliance and also prevent OSS contamination of proprietary components. Different versions of a product P1, P2, . . . Pn are received by the system 100 as input, in one embodiment of the present disclosure.
At step 404 of the method of the present disclosure, the one or more hardware processors 104 perform a first comparison of the input with a second database (DB2) to identify a first set of matched OSS components and a first set of unidentified components. The second database comprises information pertaining to a plurality of OSS components, a license permission pertaining to the plurality of OSS components, a permission matrix comprising a license information, an associated project type, an associated dependency scenario, and one or more license specific attributes.
In an embodiment, all the OSS components listed in the second database (DB2) may have associated attributes. For example, these associated attributes include Commercialization (Com) may be O1Com, Snippets (Snip) may be O1Snip, Modify (Mod) may be O1Mod, File (Fil) may be O1Fil, Components (Static Library) (Comps) may be O1Comps, Components (Dynamic Library) (Compd) may be O1Compd etc. Further the attributes of each OSS components may be Yes or No based on the determination of commercial usage applicability. For example, if Commercialization (Com) for O1 is Yes then the parameter may be O1ComY. If Commercialization (Com) for O1 is No, then the parameter may be O1ComN. Likewise for Snip, the values are O1 SnipY and O1SnipN, for Mod, the values are O1ModY and O1ModN, for Fil, the values are O1FilY and O1FilN, for Comps, the values are O1CompsY and O1CompsN, for Compd, the values are O1CompdY and O1CompdN, etc.
Additionally, all the OSS components listed in the second database (DB2) may have further associated attributes. For example, these further associated attributes may include, but are not limited to, license usage type, dependency scenarios such as research/study, building/editing/testing, packaging, production and the like, and project type such as customer service delivery, internal applications, software assets codifying intellectual property and the like. Each of the OSS components is also tagged to license types which may also have associated attributes such as usage, distribution, derivation, invocation, rights and obligations and so on.
Based on the recommendations generated, the system 100 determines which of the OSS components may be selected for the software product (which can be dependent on the project type, dependency, scenario, license usage type, and license attributes present in the permission matrix). Further, there may be scenarios wherein some of the OSS components are compliant and can be part of a final deliverable but cannot be compiled, for example weak copyleft license (GNU lesser general public license, Sun Binary code license as like). In an embodiment, the system is configured to create a list of OSS components which may be compiled with proprietary code; and another set of OSS components which may be part of a final deliverable but may not be compiled. In an embodiment, the second database (DB2) having exemplary attributes may be represented as shown in Table 5 herein below.
indicates data missing or illegible when filed
For the sake of brevity, only few attributes are depicted in the above Table 2, however additional attributes as described above also are (or may also be) part of DB2.
It is to be noted that the second OSS database (DB2) has a pre-defined format comprising the attributes including OSS component name, OSS component version, OSS component home page URL, OSS component license type, OSS component license URL, OSS component attribution note, license usage type, commercial distribution permission, and OSS component compile permission, license compatibility with the OSS component license type associated with other OSS components comprised in the product or compatibility with proprietary license. Further, a first report (e.g., say R1) may be generated pertaining to the first set of unidentified components may be generated.
At step 406 of the method of the present disclosure, the one or more hardware processors 104 perform a second comparison of the first set of unidentified components with a first database (DB1) to obtain a second set of matched OSS components. The second comparison is performed to identify one or more matches therebetween based on component attributes and license attributes associated thereof.
The first OSS database (DB1) may be available in the public domain or may be populated by the system 100 of the present disclosure based on OSS components available in the public domain. An exemplary public database DB1 with OSS components having exemplary attributes may be represented as shown in Table 6 herein below.
indicates data missing or illegible when filed
In one embodiment, the step of performing the second comparison further includes identifying a second set of unidentified components. In other words, not only there would be the second set of matched OSS components, but there may also be a possibility of identifying the second set of unidentified components. The system 100 further generates a second report (e.g., say R2) pertaining to the second set of unidentified components.
At step 408 of the method of the present disclosure, the one or more hardware processors 104 categorize based on licensing information, the first set of matched OSS components and the second set of matched OSS components as (i) OSS components having a strong copyleft license, (ii) OSS components having a permissive license, or (iii) OSS components having a weak copyleft license. In other words, the one or more OSS components having a match with the OSS components available in the first database (DB1) are categorized based on associated attributes. In an embodiment the various categories may include (i) OSS components having strong copyleft license such as General Public License (GPL) orAffero General Public License (AGPL), (ii) permissive license such as Massachusetts Institute of Technology (MIT) License or Apache, or (iii) weak copyleft or free public license such as Lesser General Public License (LGPL), Mozilla Public License (MPL), Eclipse Public License (EPL) and the like. A report for each categorization is generated by the system 100, in one embodiment of the present disclosure. For instance, (i) a third report (R3) is generated for OSS components having the strong copyleft license, (ii) a fourth report (R4) is generated for OSS components having the permissive license, and (iii) a first report (R5) is generated for OSS components having the weak copyleft license.
It is to be understood by a person having ordinary skill in the art that rules may vary depending upon the project type, dependency scenario, license usage type, and license attributes. For instance, if dependency scenario is that software is to be packaged and distributed as part of Customer Delivery or as an IP asset (product/solution), and some of the exemplary rules can be applied as follows:
Once the first set of matched OSS components and the second set of matched OSS components are identified, the method of the present disclosure includes applying via the one or more hardware processors 104, a permission matrix on the first set of matched OSS components and the second set of matched OSS components as having the strong copyleft license, the weak copyleft license, and the permissive license to generate a set of recommendations for each license-usage combination. In an embodiment, the license usage type may be one of a code block, a snippet, a file, or a library. Further, the OSS usage type of the one or more OSS components is defined as snippets (Snip), file (Fil), a Static library (Comps), a dynamic library(Compd), and it is determined if a component is modified. When the usage type is the snippets (Snip) for the OSS component then the component to have attribute of modification, and the snippets (Snip) is indicative of one or more attributes for the one or more OSS components used as part of software development. The Static library (Comps) and the dynamic library (Compd) are indicative of one or more listed open source components being used as part of software development. The library may be further identified as one of a library-executable or a library-binary type, in one embodiment of the present disclosure. The permission matrix comprises an associated dependency scenario (e.g., Research/Study, Building/Editing/Testing, Packaging, Production, and so on) and an associated project type (e.g., internal, creation of intellectual property rights type, external for customer, public, and the like), a license information, and one or more license specific attributes, and a license usage type.
An exemplary permission matrix may be represented as shown in Table 7 herein below.
indicates data missing or illegible when filed
In the above Table 7, symbols ‘√’ refers to ‘allowed’, ‘x’ refers to ‘not allowed’, and ‘*’ refers to ‘conditionally allowed’. These symbols serve as flags such as permission flag indicating at least one of an allowed flag, a not allowed flag, and a conditionally allowed flag pertaining to the associated dependency scenario and the associated project type. The system 100 generates recommendations for (i) the allowed flag, (ii) the conditionally allowed flag, and one or more guidelines are generated for each of the plurality of OSS components with respect to one or more license obligations and restrictions for allowed flag and conditionally allowed flag, and (iii) one or more associated reasons for the not allowed flag. A recommendation report is (or may be) generated comprising at least one of a name of OSS component, a version of OSS component, a Uniform Resource Locator (URL) for OSS, an Applicable OSS License, License Type, a URL for OSS License, a Project Type, a dependency scenario, the one or more guidelines, and one or more recommendations for conditionally allowed flags.
Referring to the method of the present disclosure, the one or more hardware processors 104 perform a third comparison of one or more unidentified components from the second set of unidentified components with at least one of (i) one or more logs of a code generation tool that generated the one or more unidentified components, and (ii) one or more associated indicators comprised therein, to obtain a first set of generated components, a second set of generated components, and a third set of unidentified components. The first set of generated components and the second set of generated components include but are not limited to, data types such as text (alphanumeric, multilingual), code, images, audio, video, 3d models and robotic actions which may be included in the software product. In Generative AI terminology, AI Generated Contents may be called as output, responses, suggestions, completions, and so on. The associated indicators comprise but are not limited to, source code comments, identifiers and hash values, citation information, and so on.
Example of log of the code generation tool is as below: 2023-09-21 13:07:20,349 INFO—Thread-11:MainProces:apps.knowledge_manag:vector_engine indexer:0623 Generating code block for provided condition, marked with 35zmh4jrkjocgray4xmpdzdwftrw51co, completed in: 119.39860 secs
Example of source code Comments, with identifier, hash value:
Examples of Citation Information:
The generated response has elements that are source from: 1. Reference 1, Link1 2. 1. Reference 2, Link2, and so on.
The system 100 may be trained or assisted by one or more artificial intelligence (AI) methodologies as known in the art for detecting the indicators or text from the indicators (are from the developer) and interpret the intent from the indicators or text from the indicators.
The code generation tool comprises at least one of a generative artificial intelligence (AI) model, a model-driven generation tool, and a grammar-driven generation tool. Examples of such tools or models may comprise, but are not limited to, (i) Model-Driven Development (MDD) tool, (ii) Template, Rule, Grammar or Annotation based generation tool, (iii) Domain-Specific Language (DSL) based generators, (iv) Application Builders and Low Code No Code platforms, (v) Generative AI and Code Completion technologies, (vi) Code synthesis from Diagrams, (vii) Code scaffoldings & Frameworks, and so on.
Upon obtaining the first set of generated components and a third set of unidentified components, the one or more hardware processors 104 generate at least one of a first comprehensive report and a second comprehensive report. In other words, based on the third comparison, the system 100 generates the first comprehensive report (e.g., say R6) for the first set of generated components, and the second comprehensive report (e.g., say R7) for the second set of generated components. It is to be understood by a person having ordinary skill in the art that the system 100 may generate a single report comprising information pertaining to the first set of generated components and the second set of generated components. The first comprehensive report and the second comprehensive report may also be referred as a sixth report R6, and a seventh report R7 respectively.
Once the reports R6 and R7 are generated, these reports are compared. In other words, the method of the present disclosure includes performing, via the one or more hardware processor 104, a fourth comparison of the first comprehensive report and the second comprehensive report for eliminating one or more redundancies comprised therein. There may be source code comments, identifiers and hash values, and citation information in the report R6 that are identical to source code comments, identifiers and hash values, citation information in the report R7, in one embodiment of the present disclosure. There may be source code comments, identifiers and hash values, and citation information in the report R6 that are similar to source code comments, identifiers and hash values, citation information in the report R7, in another embodiment of the present disclosure. In such scenarios, the reports R6 and R7 may be communicated/notified to a user (e.g., say subject matter expert (SME)) for review via appropriate user interface of the system 100. The user (e.g., the SME) may accordingly remove/delete such source code comments, identifiers and hash values, and citation information from any one of the reports R6 and R7. It is to be understood by a person having ordinary skill in the art that in case the reports R6 and R7 have similar source code comments, identifiers and hash values, citation information but may not be identical, these may be retained in the reports and not necessarily eliminated.
Referring to steps of the method of the present disclosure, the one or more hardware processors 104 further periodically update the second database (DB2) with the second set of matched OSS components. This ensures that that second database (DB2) remains enriched and curated all the time which enables faster retrieval of information as desired.
Since, the input is the software product, there may be scenarios wherein the software product is still under development. In such scenarios, the method of the present disclosure generates in real-time, the one or more recommendations, and the one or more guidelines for each of the plurality of OSS components with respect to one or more license obligations and restrictions. The one or more guidelines may include but are not limited to Do's and Don'ts pertaining to each license-usage combination. A recommendation report is generated that comprises of a Name of OSS component, Version of OSS component, URL for OSS, Applicable OSS License, License Type, URL for OSS License, Project Type, dependency scenario (e.g., Build/Editing/Testing, and so on), guidelines in the form of Dos and Donts, and any further recommendations for conditionally allowed flags.
When the software product is under development, there could be OSS components added as a dependency. In such scenarios, the one or more hardware processors 104 detects a dependency scenario, a project type, and then queries the DB2 and provide one or more recommendations in real-time. Additionally, the system 100 can be configured to check whether the OSS components added as the dependency can be used or not for software product development with other OSS components in the software product. This ensures that during the software product development the developer is provided guidance on use of such OSS components, license information, and their interoperability/compatibility and also saves developer's overall time and effort required for development of the software product. If the second database (DB2) does not have information after querying, then the system 100 queries the first database (DB1) wherein the second database (DB2) is updated with the information (e.g., license type, usage type, and so on) and further re-query the second database (DB2) for providing recommendations. Further, the system 100 detects (or may detect), during a software product development, one or more generated components suggested by the code generated tool and accepted for inclusion in the software product, and a third database (DB3) is populated with the one or more generated components suggested by the code generated tool.
Furthermore, the system 100 performs (or may perform) a fifth comparison of one or more unidentified components from the second set of unidentified components with the third database (DB3) comprising the one or more generated components (wherein the components are suggested by the code generated tool for inclusion in the software product) to identify at least one of one or more matched generated components and a fourth set of unidentified components.
The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
It is intended that the disclosure and examples be considered as exemplary only, with a true scope of disclosed embodiments being indicated by the following claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 201721011464 | Jun 2017 | IN | national |
This U.S. patent application is a continuation in part of U.S. patent application Ser. No. 16/022,079, filed on Jun. 28, 2018, which claims priority under 35 U.S.C. § 119 to: Indian Patent Application No. 201721011464, filed on Jun. 30, 2017. The entire contents of the aforementioned application are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16022079 | Jun 2018 | US |
| Child | 18372217 | US |
