Table of contents generated with markdown-toc
Qleany is a streamlined generator designed to integrate Clean Architecture principles within C++ Qt6 applications. Qleany is not a framework, all needed code is generated. The associated library doesn't exist anymore. The only dependencies are Qt and QCoro.
It is built on two core components:
Please avoid using Qt Design Studio version 4.3 (which utilizes Qt 6.6) due to a known issue that impacts Qt versions 6.5.3 and 6.6. This bug can cause crashes in previews (qml2puppet) when working with QML mocks generated by Qleany. We recommend using Qt Design Studio LTS version 4.1 instead, as it is based on Qt 6.5.1 and does not exhibit this problem. Qt Design Studio 4.4 preview seems to run well with Qleany.
In short: Help with creating desktop software in Qt, with an option for KDE software.
Long story: Qleany's primary goal is to automate the generation of a structured project environment for C++/Qt6 applications. This is achieved by interpreting a simple manifest file, named qleany.yaml, located at the root of the project. The tool generates a comprehensive structure including folders, CMakeLists.txt, and more than essential C++ files: it will generate whole libraries adapted to your needs. The generated projects support QWidget, QML, Kirigami GUIs or a combination of all. Upon initial generation, the projects are immediately compilable, requiring developers only to design GUIs and implement custom use cases.
The generator acknowledges the repetitive nature of file creation in Clean Architecture and addresses this by automating the generation of similar files. Tha simplest of the examples in Qleany have 500+ files in 170+ folders, all generated by this tool. So, Qleany generator is doing some heavy lifting, but some places will have to be polished by you.
Additional features include:
Qleany is designed to streamline the development process, offering a range of benefits to developers:
Many developers are likely familiar with the following depiction of Clean Architecture:
It's important to note that this conceptual representation needs to be tailored to fit the specific requirements of the language and project at hand. Qleany presents a distinct interpretation of Clean Architecture, uniquely adapted and structured to suit its specific use cases and environment.
Libraries and their respective functionalities are organized as follows:
Entities: Contains entities and is encapsulated in a library named entities. This is the place where the domain model is defined, including the entities and their relationships. Also known as the "domain" layer or "enterprise business rules".
Application or Interactor: Groups use cases by functionalities, organized within a library called application. This is the place where the application by itself is defined, with its use cases and their handlers. Also known as the "application businness rules" layer or "use cases" layer. One little rule: a use case cannot depend on another use case, even if the temptation is strong. If it's really needed, delegate the duplicate work to a service following the example of Gateway and Infrasturcture, and use the service in the use cases. This way, the use cases are kept independent from each other and one breaking does not break the others.
Persistence: Manages internal data persistence, see the two sub-sections below.
Persistence/repository: It includes a 'repository' wrapper for persistence interactions, with each entity having its repository. Repositories instances are ultimately stored in the RepositoryProvider class. RepositoryProvider is provided by the Qleany library.
Persistence/database:Also, you would normally find a database folder by to the repository folder, containing the SQLite database and its management classes, but these classes are included in the Qleany library. Of course, if needed, you can implement your own database management classes and swap the provided ones with yours.
Contracts: A common library for most other components, housing all interfaces from persistence, gateway, and infrastructure. This design minimizes tight coupling and circular dependencies.
DTO Libraries: Each functionality has its DTO library, facilitating communication with the application layer. DTOs are used for both input and output in interactions with the outer layers, such as controllers.
CQRS Libraries (Command Query Responsibility Segregation): The application layer is designed to support CQRS, with commands and queries being handled separately. This separation is achieved by using the CommandHandler and QueryHandler classes. Other classes, such as CommandValidator and QueryValidator, are used to validate commands and queries, respectively. They are stored away in a separate library called cqrs.
Gateway: Optional library for handling remote connections and services. It can be manually added by the developer and is used similarly to repositories in use cases.
Infrastructure: Optional. Handles actions like file management, local settings, and system queries. It's injected into use cases similar to repositories and gateways.
Controller: Acts as an internal API to invoke use cases, streamlining the interaction between the user interface and application logic.
Presenter: Maintains Qt models and representations of unique entities (referred to as Singles), enhancing their integration and usage within the GUI.
UI: The structure allows the simultaneous use of different fronts, each in its own binary. QML and QWidgets UIs can coexist without any conflict. Same for a CLI, an API ... All these fronts will use the same models and controllers. You can have a single main.cpp file for all fronts, or one for each front. It's up to you. Qleany will only generate one for each front.
Another related point:
persistence, gateway, infrastructure, controller) initializes its classes in a corresponding name_registration.cpp file, typically called together in the main.cpp.Project dependencies:
Example of project structure:
Prerequisites:
On Debian-based distribution, it would be packages like: qtbase6-dev qcoro-qt6-dev cmake extra-cmake-modules cmake-extras Depending of your options: qt6-declarative-dev qt6-svg-dev libkf6*dev kirigami2-dev
Adapt the -j6 to your number of CPU minus one.
CMake options are:
Below is an example of how to compile and install the Qleany static library:
git clone https://github.com/jacquetc/qleany.git
cd qleany
mkdir build
cd build
cmake -DQLEANY_BUILD_EXAMPLES=on -DQLEANY_BUILD_TESTS=off ..
cmake --build . -- -j6
Add -DBUILD_SHARED_LIBS=on to the cmake command line to build shared libraries.
Qleany is building and examples are running well if you use Qt Creator or Visual Studio Code with the CMake Tools extension.
Note: You can find the qleany library documentation at https://jacquetc.github.io/qleany/index.html
To use Qleany, follow these steps:
qleany init in the root of your project. It will create a qleany.yaml file for you. You can use the examples/simple/qleany.yaml or examples/front_ends/qleany.yaml files as references. Read the end of this Readme for more details about the qleany.yaml file.qleany.yaml file for your project.qleany or qleany gui) and select the qleany.yaml file.examples/simple/src/core/CMakeLists.txt and examples/simple/src/gui/CMakeLists.txt files as a reference.Note: I enjoin you to use sccache if you have a slow computer. It will speed up the compilation of your project after the first compilation. You can use it with the CMAKE_CXX_COMPILER_LAUNCHER option set to sccache in your CMakeLists.txt file or -DCMAKE_CXX_COMPILER_LAUNCHER=sccache in your cmake command line. To install sccache, go to https://github.com/mozilla/sccache.
A minimal QtWidgets GUI can be generated by Qleany. You only have to fill front_ends in the qleany.yaml file. Read "Front end Configuration" section below for more details.
If you already have a QtWidgets GUI, you can craete a blank GUI in a sub-folder next to your real one. Then, swap the generated files with your real ones.
Note: You can use the examples/simple/src/gui/desktop_application or examples/front_ends as references of what is running fine.
examples/simple/src/gui/desktop_application.controller for commands/queries and Q_SIGNALS. Also, it will use models from presenter. Refer to the example for guidance at examples/front_ends/src/gui/qt_widgets_application/main.cppA minimal QML GUI can be generated by Qleany. You only have to fill front_ends in the qleany.yaml file. Read "Front end Configuration" section below for more details.
If you already have a QtQuick GUI, you can craete a blank GUI in a sub-folder next to your real one. Then, swap the generated files with your real ones.
Note: You can use the examples/front_ends/src/gui/qt_quick_application as a reference of what is running fine.
examples/simple/src/gui/qml_application.A GUI made with QML will not use controller and presenter. Wrappers around models, Q_SIGNALS, commands and queries all are generated in the QML real_imports folder in the QML folder to be made available from QML. Also, QML mocks are generated in mock_imports, to be filled by the developer. Refer to the example for guidance at examples/front_ends/src/gui/qt_quick_application/main.cpp and examples/front_ends/src/gui/qt_quick__application/CMakelists.txt
A KF6 Kirigami GUI can be generated by Qleany, inspired from the Kirigami template from KDevelop. You only have to fill front_ends in the qleany.yaml file. Read "Front end Configuration" section below for more details.
Also, mocks are generated in mock_imports, to be fine-tuned by the developer. Use the BUILD_WITH_MOCKS cmake definition to include the mocks in the build.
Multiple Uis is considered as a rare use case. This merge of multiple Uis is not perfect. In some cases, you may have to rename some files to avoid conflicts.
You can use multiple Uis, like both QtWidgets and QML GUIs, in the same project. You can use the examples/front_ends as a reference. The QML and QWidgets GUIs are in their own sub-folders, and a main.cpp file is in each folder.
To set multiple GUIs, read "Front end Configuration" section below for more details.
A CMakeLists.txt file adapted to multiple UIs is generated in the root of the project and includes to folders of the QML and QWidgets GUIs. In this configuration, two binaries are generated, one for each GUI.
It's technicaclly possible to use the same main.cpp file for both GUIs, and generate only one binary. It's up to you. Qleany will only offer to write a main.cpp in each GUI folder, and you can modify them as you want.
You can use Qleany with Qt Design Studio. You can use the examples/simple/src/gui/qml_application as a reference of what is running fine. This example folder contains a genuine Qt Design Studio project. The QML file generation is tailor-made to be used after a project is created using Qt Design Studio. This folder uses Qt Design Studio's generated CMakeLists.txt. At the minimum, you only have to include the generated realqmlmodules.cmake file in your project's CMakeLists.txt file and modify the src/main.cpp to register the other librarie, like it's done in the examples/simple/src/gui/qml_application/src/main.cpp file.
Qleany also generates mocks for QML files. You can use them to test your QML files without the need of the C++ backend. You have to add "mock_imports" to the importPaths list in the *.qmlproject file You can use the examples/simple/src/gui/qml_application as a reference of what is running fine.
To summarize the steps needed to use Qleany with Qt Design Studio:
qml_imports_integration to the front_ends section of the qleany.yaml file and give my_qds_gui as the folder_path.realqmlmodules.cmake file in my_qds_gui's CMakeLists.txt file.src/main.cpp to register the other libraries, like it's done in the examples/simple/src/gui/qml_application/src/main.cpp file.Read "Front end Configuration" section below for more details.
You can also create a CLI, an API, a gRPC server, or other fronts. You can use the same models and controllers for all fronts. You can have a single main.cpp file for all fronts, or one for each front. It's up to you.
The gateway and infrastructure are not generated by Qleany. You have to create them manually. You can use the examples/simple/src/core/contracts and examples/simple/src/core/persistence as a reference. The contracts folder contains the interfaces for the gateway and infrastructure, similar to what is done with the repositories of persistence.
So, if I wanted to add a gateway, I would create a gateway folder in the src/core/contracts folder, and add the interfaces for all the public classes offered by the gateway. Then, I would create a gateway folder in the src/core folder, and add the implementation of the gateway classes. When needed, use cases (handler) in application would have a gateway parameter using the interface, like what is already done with the repositories, and the gateway classes would be instanciated and injected into controller from inside the main.cpp file.
Finally, do not forget a gateway_registration.cpp file in the src/core/gateway folder to register the gateway classes.
If you have too much gateway classes, it can be useful to store them inside a "GatewayProvider" class, like what is done with the RepositoryProvider that you can find here.
In a Gateway, we would find connections to remote services like REST APIs and remote databases, and in Infrastructure, we would find connections to local services, like file management, local settings, and system queries. A "loadFile" method in a FileLoader class would be an example of an infrastructure service. Same for a Settings class or "exportToPdf" method in a PdfExporter class.
The names Gateway and Infrastructure are not mandatory, you can use other names, like Remote and Local, or whatever you want. You can also put all inside a single Gateway. It's up to you.
You can add custom commands and queries for each feature in the application.features of the qleany.yaml. You can use the examples/simple/qleany.yaml and examples/simple/src/core/application as references. Search for the Q_UNIMPLEMENTED(); macro in the generated files to find the places to fill with your custom code. Be careful ot not overwrite your custom code when you regenerate the files, use the preview feature of the generator to avoid this or deselect the files you don't want to regenerate.
When you take into account the classes offered by the Qleany library, persistence is actually composed by a repository part and a databasepart, respectively situated in the "Interface Adapters" layer and in the "Frameworks & Drivers" layer of the Clean Architecture circle diagram.
database classes are represented by InterfaceDatabaseTableGroup and InterfaceDatabaseContext interfaces. If the SQLite database management classes provided by Qleany are not enough for your needs, you can implement your own classes and swap the provided ones with yours.
And lastly, if you think that there is a strange behavior, you only have to create an issue and join the qleany.yaml
Qleany tooling can be installed using pip install qleany. Alternatively, for an easier installation, you can install it using pipx install qleany if you have pipx installed, then run qleany.
To access Qleany's user-friendly graphical interface, run qleany or qleany gui in a terminal. This interface allows developers to efficiently manage file generation. This is the recommended way to generate files.
Run the Qleany GUI:
qleany or qleany gui in a terminal.Select the qleany.yaml File:
qleany.yaml file. This configuration file is essential for the GUI to operate correctly. You can generate this file using the qleany init command.List Available Files:
Select Files to Generate:
Preview Files:
qleany.yaml file.Generate Files:
Overwrite Confirmation:
Alternatively, you can list and generate all the files of the project.
The qleany.yaml file is the core configuration file for the Qleany generator. A new qleany.yaml can be generated using qleany init command in the root directory of your project. A working example can be found in example/front_ends/qleany.yaml or example/simple/qleany.yaml. Below are the rules and structure for defining the configuration:
global:
application_name: SimpleExample
application_cpp_domain_name: Simple
organisation:
name: simpleexample
domain: qleany.eu
Defines entities and their properties. Setting parent to EntityBase (provided by Qleany) offers the "id" field of type "int". It's mandatory to use EntityBase as heritage.
entities:
list:
- name: EntityName
parent: ParentEntity
only_for_heritage: true/false
fields:
# basic:
- type: DataType
name: fieldName
hidden: true/false (default: false)
# one-to-one relationship:
- type: OtherEntityName
name: fieldName
strong: true/false
hidden: true/false (default: false)
# one-to-many relationship:
- type: QList<OtherEntityName>
name: fieldName
strong: true/false
ordered: true/false
hidden: true/false (default: false)
# other fields ...
# other entities ...
folder_path: path/to/entity/folder
Specifies settings for entity repositories.
persistence:
list:
- entity_name: EntityName
lazy_loaders: true/false
# other repositories, typically one for each entity
repository_folder_path: path/to/repository/folder
base_folder_path: path/to/base/folder
Configures controller-specific settings.
controller:
folder_path: path/to/controller/folder
create_undo_redo_controller: true/false
Defines application-specific settings and CRUD operations.
application:
common_cmake_folder_path: path/to/application/folder
features:
- name: FeatureName
DTO:
dto_identical_to_entity:
enabled: true/false
entity_mappable_with: EntityName
CRUD:
enabled: true/false (default: false)
entity_mappable_with: EntityName
get:
enabled: true/false
get_all:
enabled: true/false
get_with_details:
enabled: true/false
create:
enabled: true/false
remove:
enabled: true/false
update:
enabled: true/false
insert_relation:
enabled: true/false
remove_relation:
enabled: true/false
commands:
- name: CommandName
entities:
- EntityName
validator:
enabled: true/false
undo: true/false
dto:
in:
enabled: true/false (default: true)
type_prefix: CommandName
fields:
- type: DataType
name: fieldName
out:
enabled: true/false (default: true)
type_prefix: CommandNameReply
fields:
- type: DataType
name: fieldName
queries:
- name: QueryName
entities:
- EntityName
validator:
enabled: true/false
undo: false (useless for queries)
dto:
in:
enabled: true/false (default: true)
type_prefix: QueryName
fields:
- type: DataType
name: fieldName
out:
type_prefix: QueryNameReply
fields:
- type: DataType
name: fieldName
DTOs:
common_cmake_folder_path: path/to/dtos/folder
Defines settings for contracts in the application.
contracts:
inverted_app_domain: domain.identifier
folder_path: path/to/contracts/folder
Configures presenter-specific settings. Note: the name can be set to auto
presenter:
folder_path: path/to/presenter/folder
create_undo_and_redo_singles: true/false (default false)
singles:
- name: SingleName (or "auto")
entity: EntityName
read_only: true/false (default: false)
# Additional singles...
list_models:
- name: ListModelName (or auto)
entity: EntityName
displayed_field: fieldName
in_relation_of: RelationEntity
relation_field_name: relationFieldName
read_only: true/false (default: false)
# Additional list models...
Specifies the front end settings, like the folder path which is mandatory. A folder_path is a sub-folder of the project folder. It will generate basic files for the front end, like a main.cpp file, and a CMakeLists.txt file.
qml_imports_integration is a folder containing generated QML imports. It's useful if you want to integrate imports into your exisiting QML project or you Qt Design Studio project. It's not mandatory.
To set multiple GUIs, fill the front_ends section multiple times, like in the example below.
front_ends:
qt_widgets:
folder_path: path/to/qt_widgets_application_folder
qt_quick:
folder_path: path/to/qt_quick_application_folder
kf6_kirigami:
folder_path: path/to/kf6_kirigami_application_folder
qml_imports_integration:
folder_path: path/to/qml_imports_integration_folder
Be careful while generating CMakeLists.txt files for example projects. Since the examples are built at the same time than the library, you will have to comment out the find_package(qleany CONFIG REQUIRED) in each CMakeLists.txt file of the examples.
You can also install the Qleany generator using poetry. You can use the following commands to install and run the Qleany generator:
poetry install to install the dependencies.
poetry run qleany to run the Qleany GUI.
1.1. "Contributor" means each individual or legal entity that creates, contributes to the creation of, or owns Covered Software.
1.2. "Contributor Version" means the combination of the Contributions of others (if any) used by a Contributor and that particular Contributor's Contribution.
1.3. "Contribution" means Covered Software of a particular Contributor.
1.4. "Covered Software" means Source Code Form to which the initial Contributor has attached the notice in Exhibit A, the Executable Form of such Source Code Form, and Modifications of such Source Code Form, in each case including portions thereof.
1.5. "Incompatible With Secondary Licenses" means
(a) that the initial Contributor has attached the notice described
in Exhibit B to the Covered Software; or
(b) that the Covered Software was made available under the terms of
version 1.1 or earlier of the License, but not also under the
terms of a Secondary License.
1.6. "Executable Form" means any form of the work other than Source Code Form.
1.7. "Larger Work" means a work that combines Covered Software with other material, in a separate file or files, that is not Covered Software.
1.8. "License" means this document.
1.9. "Licensable" means having the right to grant, to the maximum extent possible, whether at the time of the initial grant or subsequently, any and all of the rights conveyed by this License.
1.10. "Modifications" means any of the following:
(a) any file in Source Code Form that results from an addition to,
deletion from, or modification of the contents of Covered
Software; or
(b) any new file in Source Code Form that contains any Covered
Software.
1.11. "Patent Claims" of a Contributor means any patent claim(s), including without limitation, method, process, and apparatus claims, in any patent Licensable by such Contributor that would be infringed, but for the grant of the License, by the making, using, selling, offering for sale, having made, import, or transfer of either its Contributions or its Contributor Version.
1.12. "Secondary License" means either the GNU General Public License, Version 2.0, the GNU Lesser General Public License, Version 2.1, the GNU Affero General Public License, Version 3.0, or any later versions of those licenses.
1.13. "Source Code Form" means the form of the work preferred for making modifications.
1.14. "You" (or "Your") means an individual or a legal entity exercising rights under this License. For legal entities, "You" includes any entity that controls, is controlled by, or is under common control with You. For purposes of this definition, "control" means (a) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (b) ownership of more than fifty percent (50%) of the outstanding shares or beneficial ownership of such entity.
2.1. Grants
Each Contributor hereby grants You a world-wide, royalty-free, non-exclusive license:
(a) under intellectual property rights (other than patent or trademark) Licensable by such Contributor to use, reproduce, make available, modify, display, perform, distribute, and otherwise exploit its Contributions, either on an unmodified basis, with Modifications, or as part of a Larger Work; and
(b) under Patent Claims of such Contributor to make, use, sell, offer for sale, have made, import, and otherwise transfer either its Contributions or its Contributor Version.
2.2. Effective Date
The licenses granted in Section 2.1 with respect to any Contribution become effective for each Contribution on the date the Contributor first distributes such Contribution.
2.3. Limitations on Grant Scope
The licenses granted in this Section 2 are the only rights granted under this License. No additional rights or licenses will be implied from the distribution or licensing of Covered Software under this License. Notwithstanding Section 2.1(b) above, no patent license is granted by a Contributor:
(a) for any code that a Contributor has removed from Covered Software; or
(b) for infringements caused by: (i) Your and any other third party's modifications of Covered Software, or (ii) the combination of its Contributions with other software (except as part of its Contributor Version); or
(c) under Patent Claims infringed by Covered Software in the absence of its Contributions.
This License does not grant any rights in the trademarks, service marks, or logos of any Contributor (except as may be necessary to comply with the notice requirements in Section 3.4).
2.4. Subsequent Licenses
No Contributor makes additional grants as a result of Your choice to distribute the Covered Software under a subsequent version of this License (see Section 10.2) or under the terms of a Secondary License (if permitted under the terms of Section 3.3).
2.5. Representation
Each Contributor represents that the Contributor believes its Contributions are its original creation(s) or it has sufficient rights to grant the rights to its Contributions conveyed by this License.
2.6. Fair Use
This License is not intended to limit any rights You have under applicable copyright doctrines of fair use, fair dealing, or other equivalents.
2.7. Conditions
Sections 3.1, 3.2, 3.3, and 3.4 are conditions of the licenses granted in Section 2.1.
3.1. Distribution of Source Form
All distribution of Covered Software in Source Code Form, including any Modifications that You create or to which You contribute, must be under the terms of this License. You must inform recipients that the Source Code Form of the Covered Software is governed by the terms of this License, and how they can obtain a copy of this License. You may not attempt to alter or restrict the recipients' rights in the Source Code Form.
3.2. Distribution of Executable Form
If You distribute Covered Software in Executable Form then:
(a) such Covered Software must also be made available in Source Code Form, as described in Section 3.1, and You must inform recipients of the Executable Form how they can obtain a copy of such Source Code Form by reasonable means in a timely manner, at a charge no more than the cost of distribution to the recipient; and
(b) You may distribute such Executable Form under the terms of this License, or sublicense it under different terms, provided that the license for the Executable Form does not attempt to limit or alter the recipients' rights in the Source Code Form under this License.
3.3. Distribution of a Larger Work
You may create and distribute a Larger Work under terms of Your choice, provided that You also comply with the requirements of this License for the Covered Software. If the Larger Work is a combination of Covered Software with a work governed by one or more Secondary Licenses, and the Covered Software is not Incompatible With Secondary Licenses, this License permits You to additionally distribute such Covered Software under the terms of such Secondary License(s), so that the recipient of the Larger Work may, at their option, further distribute the Covered Software under the terms of either this License or such Secondary License(s).
3.4. Notices
You may not remove or alter the substance of any license notices (including copyright notices, patent notices, disclaimers of warranty, or limitations of liability) contained within the Source Code Form of the Covered Software, except that You may alter any license notices to the extent required to remedy known factual inaccuracies.
3.5. Application of Additional Terms
You may choose to offer, and to charge a fee for, warranty, support, indemnity or liability obligations to one or more recipients of Covered Software. However, You may do so only on Your own behalf, and not on behalf of any Contributor. You must make it absolutely clear that any such warranty, support, indemnity, or liability obligation is offered by You alone, and You hereby agree to indemnify every Contributor for any liability incurred by such Contributor as a result of warranty, support, indemnity or liability terms You offer. You may include additional disclaimers of warranty and limitations of liability specific to any jurisdiction.
If it is impossible for You to comply with any of the terms of this License with respect to some or all of the Covered Software due to statute, judicial order, or regulation then You must: (a) comply with the terms of this License to the maximum extent possible; and (b) describe the limitations and the code they affect. Such description must be placed in a text file included with all distributions of the Covered Software under this License. Except to the extent prohibited by statute or regulation, such description must be sufficiently detailed for a recipient of ordinary skill to be able to understand it.
5.1. The rights granted under this License will terminate automatically if You fail to comply with any of its terms. However, if You become compliant, then the rights granted under this License from a particular Contributor are reinstated (a) provisionally, unless and until such Contributor explicitly and finally terminates Your grants, and (b) on an ongoing basis, if such Contributor fails to notify You of the non-compliance by some reasonable means prior to 60 days after You have come back into compliance. Moreover, Your grants from a particular Contributor are reinstated on an ongoing basis if such Contributor notifies You of the non-compliance by some reasonable means, this is the first time You have received notice of non-compliance with this License from such Contributor, and You become compliant prior to 30 days after Your receipt of the notice.
5.2. If You initiate litigation against any entity by asserting a patent infringement claim (excluding declaratory judgment actions, counter-claims, and cross-claims) alleging that a Contributor Version directly or indirectly infringes any patent, then the rights granted to You by any and all Contributors for the Covered Software under Section 2.1 of this License shall terminate.
5.3. In the event of termination under Sections 5.1 or 5.2 above, all end user license agreements (excluding distributors and resellers) which have been validly granted by You or Your distributors under this License prior to termination shall survive termination.
*
*
*
*
*
*
Any litigation relating to this License may be brought only in the courts of a jurisdiction where the defendant maintains its principal place of business and such litigation shall be governed by laws of that jurisdiction, without reference to its conflict-of-law provisions. Nothing in this Section shall prevent a party's ability to bring cross-claims or counter-claims.
This License represents the complete agreement concerning the subject matter hereof. If any provision of this License is held to be unenforceable, such provision shall be reformed only to the extent necessary to make it enforceable. Any law or regulation which provides that the language of a contract shall be construed against the drafter shall not be used to construe this License against a Contributor.
10.1. New Versions
Mozilla Foundation is the license steward. Except as provided in Section 10.3, no one other than the license steward has the right to modify or publish new versions of this License. Each version will be given a distinguishing version number.
10.2. Effect of New Versions
You may distribute the Covered Software under the terms of the version of the License under which You originally received the Covered Software, or under the terms of any subsequent version published by the license steward.
10.3. Modified Versions
If you create software not governed by this License, and you want to create a new license for such software, you may create and use a modified version of this License if you rename the license and remove any references to the name of the license steward (except to note that such modified license differs from this License).
10.4. Distributing Source Code Form that is Incompatible With Secondary Licenses
If You choose to distribute Source Code Form that is Incompatible With Secondary Licenses under the terms of this version of the License, the notice described in Exhibit B of this License must be attached.
This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/.
If it is not possible or desirable to put the notice in a particular file, then You may include the notice in a location (such as a LICENSE file in a relevant directory) where a recipient would be likely to look for such a notice.
You may add additional accurate notices of copyright ownership.
This Source Code Form is "Incompatible With Secondary Licenses", as defined by the Mozilla Public License, v. 2.0.
FAQs
Python tool for Qleany
We found that qleany demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
Research
Security News
Attackers used a malicious npm package typosquatting a popular ESLint plugin to steal sensitive data, execute commands, and exploit developer systems.
Security News
The Ultralytics' PyPI Package was compromised four times in one weekend through GitHub Actions cache poisoning and failure to rotate previously compromised API tokens.