Software compatibility detection method, device, electronic device and storage medium

Abstract

The present application discloses a software compatibility detection method, device, electronic device and storage medium; the method comprises: obtaining the license selected by each open source component in the software to be tested; wherein the license comprises one or more license clauses; determining the license agreement class to which each license belongs based on a pre-built graph database; and performing compatibility detection on the software to be tested according to the license agreement class to which each license belongs and the pre-built license compatibility graph. The embodiments of the present application can effectively ensure the accuracy and timeliness of compatibility detection, thereby improving software development efficiency and reducing software development costs.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer software technology, and in particular to a software compatibility detection method, device, electronic device and storage medium. Background Art

[0002] Open source software is open source software distributed in accordance with an open source license that complies with the open source definition. Due to its convenience, open source and extensiveness, it is used by many software developers and manufacturers, greatly improving the efficiency of software development and reducing the cost of development. Open source software allows users to use, study, modify and redistribute it for free in accordance with the requirements of the license. Since the open source license contains the rights and obligations that must be followed when using open source software, the open source license is an important part of open source software. The open source software development license clarifies the requirements and rights of the use, modification, redistribution and commercialization of open source software through the license agreement. The compliance of the open source license and the use of open source software are inseparable. There are many legal disputes at home and abroad caused by violations of license agreements.

[0003] When using open source software, multiple open source software is usually used at the same time, involving multiple open source licenses. Different license agreements may have attribute conflicts when combined. The traditional compatibility detection method is to detect according to the requirements of compatibility between various licenses. However, when the software scale is large, due to the large number of license types involved, it is impossible to effectively guarantee the accuracy and timeliness of compatibility detection, which leads to reduced software development efficiency and increased software development costs. Summary of the invention

[0004] The present application provides a software compatibility detection method, device, electronic device and storage medium, which can effectively ensure the accuracy and timeliness of compatibility detection, thereby improving software development efficiency and reducing software development costs.

[0005] In a first aspect, an embodiment of the present application provides a software compatibility detection method, the method comprising:

[0006] Obtaining the license selected by each open source component in the software to be tested; wherein the license includes one or more license clauses;

[0007] Determine the license agreement class to which each license belongs based on a pre-built graph database;

[0008] The compatibility test is performed on the software to be tested according to the license agreement class to which each license belongs and a pre-built license compatibility map.

[0009] In a second aspect, the embodiment of the present application further provides a software compatibility detection device, the device comprising: an acquisition module, a determination module and a detection module; wherein:

[0010] The acquisition module is used to acquire the license selected by each open source component in the software to be tested; wherein the license includes one or more license clauses;

[0011] The determination module is used to determine the license agreement class to which each license belongs based on a pre-built graph database;

[0012] The detection module is used to perform compatibility detection on the software to be tested according to the license agreement class to which each license belongs and a pre-built license compatibility map.

[0013] In a third aspect, an embodiment of the present application provides an electronic device, including:

[0014] one or more processors;

[0015] a memory for storing one or more programs,

[0016] When the one or more programs are executed by the one or more processors, the one or more processors implement the software compatibility detection method described in any embodiment of the present application.

[0017] In a fourth aspect, an embodiment of the present application provides a storage medium on which a computer program is stored, and when the program is executed by a processor, the software compatibility detection method described in any embodiment of the present application is implemented.

[0018] The embodiment of the present application proposes a software compatibility detection method, device, electronic device and storage medium, first obtains the license selected by each open source component in the software to be tested; then determines the license agreement class to which each license belongs based on a pre-built graph database; and then performs compatibility detection on the software to be tested based on the license agreement class to which each license belongs and the pre-built license compatibility map. That is to say, in the technical solution of the present application, a license compatibility map can be pre-built, so that the compatibility detection of the software to be tested can be performed based on the license compatibility map. In the prior art, the traditional compatibility detection method is to detect according to the requirements of compatibility between various types of licenses. However, when the software scale is large, due to the large number of license types involved, it is impossible to effectively guarantee the accuracy and timeliness of compatibility detection, which leads to a decrease in software development efficiency and an increase in software development costs. Therefore, compared with the prior art, the software compatibility detection method, device, electronic device and storage medium proposed in the embodiment of the present application can effectively guarantee the accuracy and timeliness of compatibility detection, thereby improving software development efficiency and reducing software development costs; and the technical solution of the embodiment of the present application is simple and convenient to implement, easy to popularize, and has a wider scope of application. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 A flowchart of a software compatibility detection method provided in an embodiment of the present application;

[0020] Figure 2 A flowchart of a software compatibility detection method provided by another embodiment of the present application;

[0021] Figure 3 A flowchart of a method for constructing a license compatibility map provided in an embodiment of the present application;

[0022] Figure 4 A flowchart of a method for constructing a license compatibility map provided in another example of this application;

[0023] Figure 5 A schematic diagram of the structure of a software compatibility detection device provided in one embodiment of the present application;

[0024] Figure 6 A schematic diagram of the structure of an electronic device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0025] The present application will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the present application, rather than to limit the present application. It should also be noted that, for ease of description, only the parts related to the present application, rather than all structures, are shown in the accompanying drawings.

[0026] Figure 1 This is a flowchart of a software compatibility detection method provided by an embodiment of the present application. The method can be executed by a software compatibility detection device or electronic device. The device or electronic device can be implemented by software and / or hardware. The device or electronic device can be integrated in any smart device with network communication function. Figure 1 As shown, the software compatibility detection method may include the following steps:

[0027] S101. Obtain the license of each open source component in the software to be tested; wherein the license includes one or more license clauses.

[0028] In this step, the software to be tested can be analyzed first to obtain a list of open source components corresponding to the software to be tested; then the licenses of each open source component in the list of open source components can be obtained. In one embodiment, SCA analysis can be performed on the software to be tested to obtain a list of open source components corresponding to the software to be tested. SCA refers to Software Composition Analysis, which is a tool for identifying and managing open source components used in a project.

[0029] S102: Determine the license agreement class to which each license belongs based on a pre-built graph database.

[0030] In a specific embodiment of the present application, a graph database can be pre-built, in which a large number of open source software licenses can be stored, and each license can include one or more license terms. The license for open source software is a legal agreement that specifies how users can use, modify, and redistribute the software. These licenses typically allow users to freely access the source code of the software, and can change and distribute it under certain conditions. The license terms specify the specific rules and conditions under a specific open source license. Each open source software license has its own unique terms that define the rights and responsibilities of users in different situations.

[0031] In one example, the name of the current license may be input into a pre-built graph database, and the license agreement class to which the found license belongs may be determined as the license agreement class to which the current license belongs.

[0032] S103: Perform compatibility testing on the software to be tested according to the license agreement class to which each license belongs and a pre-built license compatibility map.

[0033] In a specific embodiment of the present application, a license compatibility map can be pre-constructed, and the license compatibility map can include multiple license protocol classes; wherein the license protocol class can include: a known license protocol class and a virtual license protocol class; there can also be connectivity between two license protocol classes; wherein the connectivity can include: connectable and inconnectable. If the connectivity between two license protocol classes is connectable, it means that the licenses in the two license protocol classes are compatible with each other; if the connectivity between the two license protocol classes is inconnectable, it means that the licenses in the two license protocol classes are not compatible with each other.

[0034] The software compatibility detection method proposed in the embodiment of the present application first obtains the license selected by each open source component in the software to be tested; then determines the license agreement class to which each license belongs based on the pre-built graph database; and then performs compatibility detection on the software to be tested based on the license agreement class to which each license belongs and the pre-built license compatibility map. That is to say, in the technical solution of the present application, a license compatibility map can be pre-built, so that the compatibility detection of the software to be tested can be performed based on the license compatibility map. In the prior art, the traditional compatibility detection method is to detect according to the requirements of compatibility between various types of licenses. However, when the software scale is large, due to the large number of license types involved, it is impossible to effectively guarantee the accuracy and timeliness of compatibility detection, which leads to a decrease in software development efficiency and an increase in software development costs. Therefore, compared with the prior art, the software compatibility detection method proposed in the embodiment of the present application can effectively guarantee the accuracy and timeliness of compatibility detection, thereby improving software development efficiency and reducing software development costs; and the technical solution of the embodiment of the present application is simple and convenient to implement, easy to popularize, and has a wider scope of application.

[0035] Figure 2 A flowchart of a software compatibility detection method provided by another embodiment of the present application is provided. The above technical solution is further optimized and expanded, and can be combined with the above optional implementation methods.

[0036] like Figure 2 As shown, the software compatibility detection method may include the following steps:

[0037] S201. Obtain the license selected by each open source component in the software to be tested; wherein the license includes one or more license clauses.

[0038] An open source component in the embodiment of the present application may select one license or multiple licenses. The open source licenses in the embodiment of the present application may include: MIT License, BSD 2-Clause, BSD 3-Clause, Apache 2.0, MPL 2.0, etc. The licenses in the embodiment of the present application may be numbered sequentially according to the name of the agreement, and the license terms may include personalized terms, common terms, implied terms, compatibility terms, exception terms, etc.; wherein, the personalized terms include whether there is basic information about the license, whether there is a preface, whether there are instructions for use, etc.; the common terms include whether it can be used commercially, whether copyright authorization can be granted, whether guarantees and authorizations are allowed, etc.; the implied terms include whether trademark rights are granted, whether patent authorization is allowed, etc.; the compatibility terms include whether code modification is allowed, whether code merging is allowed, etc., and the exception terms describe other special claims.

[0039] In one embodiment, the open source license and the corresponding license terms may be as shown in Table 1 below:

[0040]

[0041]

[0042] Table 1

[0043] S202: Calculate the feature vector corresponding to each license clause.

[0044] The feature vector corresponding to the license terms in the embodiment of the present application is a vector representation of the license features; wherein the license features may include but are not limited to one of the following: whether the copyright statement needs to be retained, whether commercial use is allowed, whether source code needs to be provided, whether there are infectious clauses, whether patent authorization is included, whether change records are required, whether a disclaimer is included, and whether there are advertising restrictions. Each of the above license features can be represented by a binary value (0 or 1).

[0045] S203. Compare the feature vectors corresponding to each license clause in each license with the feature vectors corresponding to each target license clause in each target license in the graph database to obtain a comparison result between the feature vectors corresponding to each license clause and the feature vectors corresponding to each target license clause.

[0046] In this step, the similarity between the feature vector corresponding to each license clause in each license and the feature vector corresponding to each target license clause in each target license in the graph database can be calculated; if the similarity between a license clause and a target license clause is greater than or equal to a predetermined threshold, it means that the license clause is similar to the target license clause; if the similarity between a license clause and a target license clause is less than a predetermined threshold, it means that the license clause is not similar to the target license clause.

[0047] S204: Determine the license agreement category to which each license belongs according to the comparison result.

[0048] In this step, one or more licenses can be extracted from all the licenses as the current license; then, based on the above comparison results, it is determined whether the current license is similar to the license in any license protocol class in the graph database; if the current license is similar to the license in any license protocol class in the graph database, the license protocol class to which the current license belongs can be determined as the any license protocol class; if the current license is not similar to the licenses in each license protocol class in the graph database, a new license protocol class can be created in the graph database, and the license protocol class to which the current license belongs can be determined as the new license protocol class; repeat the above operation of extracting the current license until the license protocol class to which each license belongs is determined.

[0049] S205: Perform compatibility testing on the software to be tested according to the license agreement class to which each license belongs and a pre-built license compatibility map.

[0050] In this step, if the license agreement class to which all licenses belong is the same license agreement class in the license compatibility map, it is determined that the open source components in the software to be tested meet the compatibility requirements; if the license agreement classes to which any two licenses belong are two license agreement classes in the license compatibility map, the connectivity between the two license agreement classes can be determined; wherein, connectivity includes: connectable and inconnectable; if the connectivity between the two license agreement classes is connectable, it can be determined that the open source components in the software to be tested meet the compatibility requirements; if the connectivity between the two license agreement classes is inconnectable, it can be determined that the open source components in the software to be tested do not meet the compatibility requirements.

[0051] For example, it is assumed that the licenses selected by the open source components in the software to be tested may include: License 1, License 2, License 3, License 4, and License 5. It is assumed that the license agreement class to which License 1, License 2, and License 3 belong is License Agreement Class A; and the license agreement class to which License 4 and License 5 belong is License Agreement Class B. If the connectivity between License Agreement Class A and License Agreement Class B is connectable, it can be determined that the license selected by the open source component in the software to be tested meets the compatibility requirement; if the connectivity between License Agreement Class A and License Agreement Class B is not connectable, it can be determined that the license selected by the open source component in the software to be tested does not meet the compatibility requirement.

[0052] In one embodiment, the connectivity between license protocol classes may be as shown in Table 2 below:

[0053]

[0054] Table 2

[0055] The software compatibility detection method proposed in the embodiment of the present application first obtains the license selected by each open source component in the software to be tested; then determines the license agreement class to which each license belongs based on the pre-built graph database; and then performs compatibility detection on the software to be tested based on the license agreement class to which each license belongs and the pre-built license compatibility map. That is to say, in the technical solution of the present application, a license compatibility map can be pre-built, so that the compatibility detection of the software to be tested can be performed based on the license compatibility map. In the prior art, the traditional compatibility detection method is to detect according to the requirements of compatibility between various types of licenses. However, when the software scale is large, due to the large number of license types involved, it is impossible to effectively guarantee the accuracy and timeliness of compatibility detection, which leads to a decrease in software development efficiency and an increase in software development costs. Therefore, compared with the prior art, the software compatibility detection method proposed in the embodiment of the present application can effectively guarantee the accuracy and timeliness of compatibility detection, thereby improving software development efficiency and reducing software development costs; and the technical solution of the embodiment of the present application is simple and convenient to implement, easy to popularize, and has a wider scope of application.

[0056] In a specific embodiment of the present application, before performing compatibility testing on the software to be tested, a license compatibility map may be constructed using a detector or a detection model. Figure 3 A flowchart of a method for constructing a license compatibility map provided in an embodiment of the present application. The above technical solution is further optimized and expanded, and can be combined with the above optional implementation methods. Figure 3 As shown, the method for constructing a license compatibility graph may include the following steps:

[0057] S301. Obtain licenses selected by multiple open source components; wherein the license includes one or more license clauses.

[0058] S302: Based on the licenses selected by the multiple open source components, construct connectivity between each license agreement class in the license compatibility map and the license agreement class in the license compatibility map.

[0059] In a specific embodiment of the present application, the licenses selected by multiple open source components are used to construct various license agreement classes in a license compatibility map, which can be performed according to the following operating steps: first, according to the license terms in each license, determine the license type to which each license belongs; then, according to the license type to which each license belongs, calculate the vector representation of each license; and then, according to the vector representation of each license, construct various license agreement classes in the license compatibility map; wherein the license agreement class includes: a known license agreement class and a virtual license agreement class.

[0060] In addition, based on the licenses selected by multiple open source components, the connectivity between the license agreement classes in the license compatibility map can be constructed according to the following steps: first, based on the licenses selected by multiple open source components, obtain the license compatibility sequence corresponding to each license clause; then, based on the license compatibility sequence corresponding to each license clause, cluster the licenses selected by multiple open source components to obtain a license agreement clustering table; and then, based on the license agreement clustering table, construct the connectivity between the license agreement classes in the license compatibility map.

[0061] S303: Construct a license compatibility map based on the connectivity between each license protocol class in the license compatibility map and the license protocol class in the license compatibility map.

[0062] The method for constructing a license compatibility map proposed in the embodiment of the present application first obtains the licenses selected by multiple open source components; then, based on the licenses selected by multiple open source components, the connectivity between each license agreement class in the license compatibility map and the license agreement class in the license compatibility map is constructed; and then, according to the connectivity between each license agreement class in the license compatibility map and the license agreement class in the license compatibility map, a license compatibility map is constructed. That is to say, in the technical solution of the present application, the connectivity between each license agreement class in the license compatibility map and the license agreement class in the license compatibility map can be constructed respectively, so that the compatibility test of the tested software can be performed based on the license compatibility map. A clear license compatibility map can help developers ensure that their products comply with all relevant legal requirements. For example, when using GPLv3 components, knowing which other licenses are compatible can avoid accidental violations of the infectious clause. In the prior art, the traditional compatibility detection method is to detect according to the requirements of compatibility between various licenses. However, when the software scale is large, due to the large number of license types involved, it is impossible to effectively guarantee the accuracy and timeliness of compatibility detection, resulting in reduced software development efficiency and increased software development costs. Therefore, compared with the prior art, the software compatibility detection method proposed in the embodiment of the present application can effectively ensure the accuracy and timeliness of compatibility detection, thereby improving software development efficiency and reducing software development costs; and the technical solution of the embodiment of the present application is simple and convenient to implement, easy to popularize, and has a wider scope of application.

[0063] Figure 4 A flowchart of a method for constructing a license compatibility map provided in another example of this application. The above technical solution is further optimized and expanded, and can be combined with the above optional implementation methods. Figure 4 As shown, the method for constructing a license compatibility graph may include the following steps:

[0064] S401. Obtain licenses selected by multiple open source components; wherein the license includes one or more license clauses.

[0065] S402: Determine the license type of each license according to each license clause in each license.

[0066] S403: Calculate the vector representation of each license according to the license type to which each license belongs.

[0067] S404. Construct each license protocol class in the license compatibility graph according to the vector representation of each license; wherein the license protocol class includes: a known license protocol class and a virtual license protocol class.

[0068] In one embodiment, the construction of each license agreement class in the license compatibility map can be performed according to the following operations: 1) Obtain the license name and clause characteristics of the current open source software. 2) If the current open source software license selects a single license A and only modifies part of the clause content, create a subclass under the license type to which the license belongs, and record the modified clauses under the subclass. In this way, a large number of known licenses may split out subclasses of the license type under the known license type due to changes in individual clauses. 3) If the current open source software license selects license A and license B, and the license type to which license A belongs and the license type to which license B belongs do not belong to the same upstream node, then construct a mixed subclass of license A and license B; in addition, a weight value can be set for the mixed subclass. In one embodiment, a weight value of 5 can be set for the mixed subclass. 4) If the current open source software license selects a single license A, but has the clause characteristics of license B, a subclass can be constructed under the license; in addition, a weight value can be set for the subclass. In one embodiment, a weight value of 1 can be set for the subclass. 5) Through the constructed license type, the embedding vector representation of each license can be learned through DeepWalk. 6) Based on the embedding vector representation of each license, the similarity between license types is calculated. 7) For licenses whose similarity between license types is greater than a predetermined threshold, a license agreement class is constructed.

[0069] S405: Based on the licenses selected by the multiple open source components, obtain a license compatibility sequence corresponding to each license clause.

[0070] S406: Cluster the licenses selected by the multiple open source components based on the license compatibility sequences corresponding to the license clauses to obtain a license agreement clustering table.

[0071] S407: Construct connectivity between license protocol classes in the license compatibility graph according to the license protocol clustering table.

[0072] In one embodiment, the connectivity between license agreement classes in the license compatibility graph is constructed by the following operations: 1) For each license clause, obtain the license compatibility sequence corresponding to each license clause. For example, assuming that license A, license B, and license C all support a certain license clause, the license compatibility sequence corresponding to the license clause is: license A, license B, and license C. 2) Set weight values ​​for each license clause and its corresponding license compatibility sequence, and cluster the licenses selected by multiple open source components according to the weight values ​​to obtain a license agreement clustering table. A license license in the embodiment of the present application can correspond to the identifier cluster_id of a license agreement class. 3) Continue to perform DeelWalk on the relationship diagram of the license agreement class, and train to obtain the embedding vector representation of each license agreement class. 4) Based on all licenses in a license agreement class, calculate the average embedding vector representation of all licenses as the embedding vector representation of the license agreement class. 5) Calculate the similarity between different license agreement classes, and construct the connectivity between license agreement classes based on the similarity calculation results.

[0073] S408: Construct a license compatibility map based on the connectivity between each license agreement class in the license compatibility map and the license agreement class in the license compatibility map.

[0074] The method for constructing a license compatibility map proposed in the embodiment of the present application first obtains the licenses selected by multiple open source components; then, based on the licenses selected by multiple open source components, the connectivity between each license agreement class in the license compatibility map and the license agreement class in the license compatibility map is constructed; and then, according to the connectivity between each license agreement class in the license compatibility map and the license agreement class in the license compatibility map, a license compatibility map is constructed. That is to say, in the technical solution of the present application, the connectivity between each license agreement class in the license compatibility map and the license agreement class in the license compatibility map can be constructed respectively, so that the compatibility test of the software to be tested can be performed based on the license compatibility map. A clear license compatibility map can help developers ensure that their products comply with all relevant legal requirements. For example, when using GPLv3 components, knowing which other licenses are compatible can avoid accidental violations of contagion clauses.

[0075] The software compatibility detection method provided by the present application has the following technical effects: 1) Through the study of the license agreements and compatibility knowledge of a large number of open source software, on the basis of known license agreement categories, by splitting and clustering the license agreements, a virtual license agreement category is formed, which covers the situation where the software involves multiple license agreements and agreement terms. When the software to be tested has multiple license agreements and agreement terms requirements, the corresponding license compatibility requirements can be quickly retrieved; compared with first providing a license list of the software to be tested, and then comparing the compatibility rules between the licenses and the compatibility of the license terms, the error detection efficiency is faster and more accurate. 2) For known license categories and virtual license categories that show similar characteristics when reorganized with other licenses, a virtual cluster of license agreements is formed through a clustering algorithm. When a large number of license agreements in the virtual cluster appear in the software to be tested, the efficiency of license conflict detection can be greatly simplified because the license agreements in the same cluster have the same external representation in terms of compatibility. 3) The graph database can be used to construct the compatibility relationship between the license agreement class and the virtual class, and the graph database can be used to describe the license terms attributes of the license agreement class and the virtual class, so that the relationship between the license classification and the license terms, as well as the compatibility relationship between the licenses can be clearly stated. The search for compatibility between licenses through the graph database can be significantly improved compared to the traditional database retrieval method. For different licenses combined into new virtual license types, the graph database can quickly build the connection between different licenses, and at the same time improve the efficiency of retrieval. 4) Traditional license conflict detection relies on the existing knowledge of license compatibility. When a new license appears or the license terms are updated, the license compatibility knowledge must be updated. In the detection of software, if a new license agreement or extended license terms are found, they can be classified into a virtual license agreement class according to the terms and feature similarity of the license. If a suitable license agreement class cannot be found, a new virtual license agreement class is created, and based on the similarity of the license terms, the compatibility of the license and other license agreements is inferred, and the license compatibility knowledge is supplemented, which reduces the cost of updating the prior knowledge of license compatibility and improves the accuracy of detection.

[0076] Figure 5 This is a schematic diagram of the structure of a software compatibility detection device provided by an embodiment of the present application. Figure 5 As shown, the software compatibility detection device includes: an acquisition module 501, a determination module 502 and a detection module 503; wherein,

[0077] The acquisition module 501 is used to acquire the license selected by each open source component in the software to be tested; wherein the license includes one or more license clauses;

[0078] The determination module 502 is used to determine the license agreement class to which each license belongs based on a pre-built graph database;

[0079] The detection module 503 is used to perform compatibility detection on the software to be tested according to the license agreement class to which each license belongs and the pre-built license compatibility map.

[0080] The above-mentioned software compatibility detection device can execute the method provided by any embodiment of the present application, and has the corresponding functional modules and beneficial effects of the execution method. For technical details not described in detail in this embodiment, please refer to the software compatibility detection method provided by any embodiment of the present application.

[0081] Figure 6 A schematic diagram of the structure of an electronic device provided in one embodiment of the present application. Figure 6 A block diagram of an exemplary electronic device suitable for implementing the embodiments of the present application is shown. Figure 6 The electronic device 12 shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0082] like Figure 6 As shown, the electronic device 12 is in the form of a general purpose computing device. The components of the electronic device 12 may include, but are not limited to: one or more processors or processing units 16, a system memory 28, and a bus 18 that connects various system components (including the system memory 28 and the processing unit 16).

[0083] Bus 18 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor or a local bus using any of a variety of bus architectures. By way of example, these architectures include, but are not limited to, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MAC) bus, an Enhanced ISA bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0084] The electronic device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by the electronic device 12, including volatile and non-volatile media, removable and non-removable media.

[0085] The system memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. The electronic device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 34 may be used to read and write non-removable, non-volatile magnetic media ( Figure 6 not shown, usually called a "hard drive"). Although Figure 6 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk"), and an optical drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, a DVD-ROM, or other optical medium) may be provided. In these cases, each drive may be connected to the bus 18 via one or more data medium interfaces. The memory 28 may include at least one program product having a set (e.g., at least one) of program modules that are configured to perform the functions of the various embodiments of the present application.

[0086] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in the memory 28, such program modules 42 including, but not limited to, an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment. The program modules 42 generally perform the functions and / or methods of the embodiments described herein.

[0087] The electronic device 12 may also communicate with one or more external devices 14 (e.g., keyboards, pointing devices, displays 24, etc.), may communicate with one or more devices that enable a user to interact with the electronic device 12, and / or may communicate with any device that enables the electronic device 12 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication may be performed via an input / output (I / O) interface 22. Furthermore, the electronic device 12 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 20. As shown, the network adapter 20 communicates with other modules of the electronic device 12 via the bus 18. It should be understood that although Figure 6 Not shown, other hardware and / or software modules may be used in conjunction with the electronic device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0088] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the software compatibility detection method provided in the embodiment of the present application.

[0089] The embodiment of the present application also provides a computer storage medium.

[0090] The computer-readable storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, - but not limited to - a system, device or device of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination of the above. More specific examples (non-exhaustive lists) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, a device or a device or used in combination with it.

[0091] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0092] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0093] Computer program code for performing the operation of the present application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., using an Internet service provider to connect through the Internet).

[0094] The embodiment of the present application also provides a computer program product.

[0095] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include: being implemented in one or more computer program products, which can include one or more computer programs, which can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor, which can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0096] Note that the above are only preferred embodiments of the present application and the technical principles used. Those skilled in the art will understand that the present application is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present application. Therefore, although the present application is described in more detail through the above embodiments, the present application is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of the present application, and the scope of the present application is determined by the scope of the appended claims.

Claims

1. A software compatibility detection method, characterized in that: The method comprises: Obtaining the license selected by each open source component in the software to be tested; wherein the license includes one or more license clauses; Determine the license agreement class to which each license belongs based on a pre-built graph database; The compatibility test is performed on the software to be tested according to the license agreement class to which each license belongs and a pre-built license compatibility map.

2. The method according to claim 1, characterized in that Determine the license agreement category to which each license belongs based on a pre-built graph database, including: Calculate the feature vector corresponding to each license clause in each license; Compare the feature vectors corresponding to each license clause in each license with the feature vectors corresponding to each target license clause in each target license in the graph database to obtain a comparison result between the feature vectors corresponding to each license clause and the feature vectors corresponding to each target license clause; The license agreement category to which each license belongs is determined according to the comparison result.

3. The method according to claim 1, characterized in that According to the license agreement class to which each license belongs and the pre-built license compatibility map, compatibility testing is performed on the software to be tested, including: If the license agreement class to which all licenses belong is the same license agreement class in the license compatibility map, it is determined that the open source components in the software to be tested meet the compatibility requirements.

4. The method according to claim 3, characterized in that The method further comprises: If the license protocol classes to which any two licenses belong are two license protocol classes in the license compatibility map, then determining connectivity between the two license protocol classes; wherein the connectivity includes: connectable and non-connectable; If the connectivity between the two license agreement classes is connectable, determining that the open source component in the software to be tested meets the compatibility requirement; If the connectivity between the two license agreement classes is not connectable, it is determined that the open source component in the software to be tested does not meet the compatibility requirement.

5. The method according to claim 1, characterized in that Before obtaining the licenses of each open source component in the software to be tested, the method further includes: Obtaining licenses selected by a plurality of open source components; wherein the licenses include one or more license clauses; Based on the licenses selected by the plurality of open source components, constructing connectivity between each license agreement class in the license compatibility graph and the license agreement class in the license compatibility graph respectively; The license compatibility map is constructed according to the connectivity between each license protocol class in the license compatibility map and the license protocol classes in the license compatibility map.

6. The method according to claim 5, characterized in that Based on the licenses selected by the multiple open source components, constructing various license agreement classes in the license compatibility graph, including: Determine the license type to which each license belongs based on the license terms in each license; Calculate the vector representation of each license according to the license type to which each license belongs; Each license protocol class in the license compatibility graph is constructed according to the vector representation of each license; wherein the license protocol class includes: a known license protocol class and a virtual license protocol class.

7. The method according to claim 5, characterized in that Building connectivity between license agreement classes in the license compatibility graph based on the licenses selected by the multiple open source components includes: Based on the licenses selected by the multiple open source components, obtaining a license compatibility sequence corresponding to each license clause; Clustering the licenses selected by the plurality of open source components based on the license compatibility sequences corresponding to the respective license clauses to obtain a license agreement clustering table; Connectivity between license protocol classes in the license compatibility graph is constructed according to the license protocol clustering table.

8. A software compatibility detection device, characterized in that: The device comprises: an acquisition module, a determination module and a detection module; wherein, The acquisition module is used to acquire the license selected by each open source component in the software to be tested; wherein the license includes one or more license clauses; The determination module is used to determine the license agreement class to which each license belongs based on a pre-built graph database; The detection module is used to perform compatibility detection on the software to be tested according to the license agreement class to which each license belongs and a pre-built license compatibility map.

9. An electronic device, characterized in that: include: one or more processors; a memory for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the software compatibility detection method as described in any one of claims 1 to 7.

10. A storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the software compatibility detection method according to any one of claims 1 to 7 is implemented.

Images