cmake/FindSphinx.cmake
New file @@ -0,0 +1,53 @@ # - This module looks for Sphinx # Find the Sphinx documentation generator # # This modules defines # SPHINX_EXECUTABLE # SPHINX_FOUND find_program(SPHINX_EXECUTABLE NAMES sphinx-build PATHS /usr/bin /usr/local/bin /opt/local/bin ~/.local/bin DOC "Sphinx documentation generator" ) if( NOT SPHINX_EXECUTABLE ) set(_Python_VERSIONS 2.7 2.6 2.5 2.4 2.3 2.2 2.1 2.0 1.6 1.5 ) foreach( _version ${_Python_VERSIONS} ) set( _sphinx_NAMES sphinx-build-${_version} ) find_program( SPHINX_EXECUTABLE NAMES ${_sphinx_NAMES} PATHS /usr/bin /usr/local/bin /opt/local/bin ~/.local/bin DOC "Sphinx documentation generator" ) endforeach() endif() include(FindPackageHandleStandardArgs) find_package_handle_standard_args(Sphinx DEFAULT_MSG SPHINX_EXECUTABLE) mark_as_advanced(SPHINX_EXECUTABLE) function(Sphinx_add_target target_name builder conf source destination) add_custom_target(${target_name} ALL COMMAND ${SPHINX_EXECUTABLE} -b ${builder} -c ${conf} ${source} ${destination} COMMENT "Generating sphinx documentation: ${builder}" ) set_property(DIRECTORY APPEND PROPERTY ADDITIONAL_MAKE_CLEAN_FILES ${destination} ) endfunction() doc/Home.md
File was deleted doc/_static/googleae93b5a7f3766641.html
doc/_static/pc-id-selection.pngdoc/analysis/Backoffice.md
doc/analysis/Development-And-Usage-Workflow.md
File was renamed from doc/Development-And-Usage-Workflow.md @@ -1,3 +1,5 @@ # Development and usage workflow Below a description of the planned development and usage process. Comments and progress are reported on [issue #42](https://github.com/open-license-manager/open-license-manager/issues/42)  @@ -8,7 +10,7 @@ ### Binary release contents Binary release contains: * open-license-manager executable (merge of the actual `license_generator` executable and `bootstrap`). * open-license-manager executable (`lcc`). * source code of the unconfigured library. * source code of (part of) the tests. @@ -18,7 +20,7 @@ In this phase the library is configured, compiled (only for the tests sake), linked with a mock executable and tested together with the license generator. ## Initialize library In this phase the signing keys are generated by open-license-manager executable (`olm`), and optionally the source code of the library may be modified or obfuscated. In this phase the signing keys are generated by open-license-manager executable (`lcc`), and optionally the source code of the library may be modified or obfuscated. ### Test (2) @@ -30,6 +32,6 @@ * If we want to link the execution to a specific hardware we need to send the product to the client without a license (or a demo executable, with the sole intent to generate the machine identifier). * If we just want to send a demo product with an expiry date we prepare a license without the machine identifier. # Build process From the process described above, (strange to say) the license generator (`olm`) configures itself as a build ## Build process From the process described above, (strange to say) the license generator (`lcc`) configures itself as a build dependency of the licensing library, thus it needs to be built first. doc/analysis/features.md
File was renamed from doc/features.md @@ -1,5 +1,6 @@ # General features: # Features: ## features and their status | Feature | Implementation status | |--------------------------------------|:---------------------:| | Trial license with expiry date | :heavy_check_mark: | @@ -11,38 +12,38 @@ | Java/C# bindings | Planned | | Floating/network licenses | Planned | ## Issue a "demo" license with only expiry date. ### Issue a "demo" license with only expiry date. Software editors often want to release a trial license that is not linked to a specified machine, but just limit the usage in time or to some other feature (number of cpu, process memory). See [execution limits](Implemented/Planned execution limits) section. ## Licenses linked to "physical" hardware id ### Licenses linked to "physical" hardware id Link the software to a physical hardware (a pc). In this scenario the software editor wants his software to be executed on a specific piece of hardware. We suppose the operating system is installed "bare to metal" and we're able to calculate an identifier of that hardware. This isn't always true for virtualized environments for which alternative strategies must be planned [eg. floating licenses (not yet implemented)]. See the section on [hardware identifiers](hardware-identifiers) for a detailed discussion of the use cases. Depending on the situation there are are different kinds of hardware id that can be used. See [execution limits](Implemented/Planned execution limits) section. ## Virtual machine detection ### Virtual machine detection Detect if the software is running in a virtualized environment and (optionally) forbid the execution. This is useful if software editors want to prevent the execution in virtual machines (lxc/dockers...) and be able to compute a meaningful hardware id. Another use case is the software is to be used only in a specific class of virtualized environments. For instance it was initially packaged as a docker image, the software editor don't want it to be "extracted" and placed elsewhere. ## License retrieval ### License retrieval Open License Manager, when integrated into a licensed software will find its license file based on many different strategies. It can handle multiple licenses at the same time. See the wiki page about [license retrieval](license-retrieval) for details. ## Licensed software features (partially implemented) ### Licensed software features (partially implemented) A licensed software may be composed by many features (functions) each one activable independently. Licensing system tells the licensed software which features are enabled, and which features are disabled. ## License Management (planned) ### License Management (planned) It is necessary to keep track of the licenses that have been issued, of the clients, and their hardware identifier. A web application is planned that will provide integration with payment systems to allow licensed software customers to buy licenses. ## Customizable execution limits (planned) ### Customizable execution limits (planned) It should be easy to add and implement your own "execution limit": that is require/forbid some feature in the application execution environment. ## Java/C# bindings (planned) ### Java/C# bindings (planned) The application should support bindings to java language. The library has to be compiled as a .dll for use with JNI or C# integration layer. This is especially challenging on the api side. Since the api is public, and the library is packaged as a separate .dll/.so everybody can compile a version of it always returning LICENSE_OK easily defeating the license schema. ## Floating licenses (planned) ### Floating licenses (planned) Limit the execution of the licensed software to a certain number of instances per license. This can be done in multiple ways: * without a central server, using broadcast or scanning the local network to find peers. @@ -51,7 +52,7 @@ Status of this implementation is tracked in [issue #4](https://github.com/open-license-manager/open-license-manager/issues/4) # Implemented/Planned execution limits ## Implemented/Planned execution limits Open License Manager can limit execution of licensed software based on some criteria, called "execution limits". Depending on the execution environment some criteria may not be applicable: @@ -69,22 +70,20 @@ | concurrent execution | Planned | Planned | Planned | Planned | | licensed sw version | Planned | Planned | Planned | Planned | ## Date ### Date This is the most common limit set on a license, allow the software to expire after the defined date. ## Disk label/Disk id ### Disk label/Disk id It is possible to limit the execution to a computer that has a certain disk connected. This kind of limitation doesn't make sense in linux containerized environments. ## Cpu Number/Machine memory ### Cpu Number/Machine memory Allow to restrict the execution only to a machine with the specified amount of cpu or memory or less. This is useful in virtualized environments, to create a licensed software demo version with limited performaces or with limited scalability. Status of this implementation is tracked in [issue #4](https://github.com/open-license-manager/open-license-manager/issues/4) ## Virtualization type ### Virtualization type Allow the execution of the licensed software only on some type of hardware or virtualized environment eg. only bare to metal, only in virtual machine, only in docker. ## Licensed software version ### Licensed software version A licensed software may declare a version (eg 1.0.0). A license may span multiple releases of the software e.g. allow version 1.1.1 but not 2.0.0. # doc/api/public_api.rst
New file @@ -0,0 +1,8 @@ Documentation ================== .. doxygennamespace:: license :project: licensecc :members: doc/conf.py
New file @@ -0,0 +1,175 @@ #!/usr/bin/env python3 # -*- coding: utf-8 -*- # # licensecc documentation build configuration file, created by # sphinx-quickstart on Sat Mar 14 13:43:01 2020. # # This file is execfile()d with the current directory set to its # containing dir. # # Note that not all possible configuration values are present in this # autogenerated file. # # All configuration values have a default; values that are commented out # serve to show the default. # If extensions (or modules to document with autodoc) are in another directory, # add these directories to sys.path here. If the directory is relative to the # documentation root, use os.path.abspath to make it absolute, like shown here. # # import os # import sys # sys.path.insert(0, os.path.abspath('.')) # -- General configuration ------------------------------------------------ # If your documentation needs a minimal Sphinx version, state it here. # # needs_sphinx = '1.0' # Add any Sphinx extension module names here, as strings. They can be # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom # ones. extensions = ['sphinx.ext.todo', 'sphinx.ext.githubpages', 'breathe', 'recommonmark', 'sphinx_markdown_tables', 'sphinx_rtd_theme' ] # Breathe Configuration breathe_default_project = "licensecc" # Add any paths that contain templates here, relative to this directory. templates_path = ['_templates'] # The suffix(es) of source filenames. # You can specify multiple suffix as a list of string: # # source_suffix = ['.rst', '.md'] source_suffix = ['.rst', '.md'] # The master toctree document. master_doc = 'index' # General information about the project. project = 'licensecc' copyright = '2020, Open License Manager' author = 'Open License Manager' # The version info for the project you're documenting, acts as replacement for # |version| and |release|, also used in various other places throughout the # built documents. # # The short X.Y version. version = '2.0.0' # The full version, including alpha/beta/rc tags. release = '2.0.0' # The language for content autogenerated by Sphinx. Refer to documentation # for a list of supported languages. # # This is also used if you do content translation via gettext catalogs. # Usually you set "language" from the command line for these cases. language = None # List of patterns, relative to source directory, that match files and # directories to ignore when looking for source files. # This patterns also effect to html_static_path and html_extra_path exclude_patterns = [] # The name of the Pygments (syntax highlighting) style to use. pygments_style = 'sphinx' # If true, `todo` and `todoList` produce output, else they produce nothing. todo_include_todos = True # -- Options for HTML output ---------------------------------------------- # The theme to use for HTML and HTML Help pages. See the documentation for # a list of builtin themes. # html_theme = 'sphinx_rtd_theme' # Theme options are theme-specific and customize the look and feel of a theme # further. For a list of options available for each theme, see the # documentation. # html_theme_options = { 'titles_only': False } # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, # so a file named "default.css" will overwrite the builtin "default.css". html_static_path = ['_static'] # Custom sidebar templates, must be a dictionary that maps document names # to template names. # # This is required for the alabaster theme # refs: http://alabaster.readthedocs.io/en/latest/installation.html#sidebars #html_sidebars = { # '**': [ # 'relations.html', # needs 'show_related': True theme option to display # 'searchbox.html', # ] #} # -- Options for HTMLHelp output ------------------------------------------ # Output file base name for HTML help builder. htmlhelp_basename = 'licenseccdoc' # -- Options for LaTeX output --------------------------------------------- latex_elements = { # The paper size ('letterpaper' or 'a4paper'). # # 'papersize': 'letterpaper', # The font size ('10pt', '11pt' or '12pt'). # # 'pointsize': '10pt', # Additional stuff for the LaTeX preamble. # # 'preamble': '', # Latex figure (float) alignment # # 'figure_align': 'htbp', } # Grouping the document tree into LaTeX files. List of tuples # (source start file, target name, title, # author, documentclass [howto, manual, or own class]). latex_documents = [ (master_doc, 'licensecc.tex', 'licensecc Documentation', 'Open License Manager', 'manual'), ] # -- Options for manual page output --------------------------------------- # One entry per manual page. List of tuples # (source start file, name, description, authors, manual section). man_pages = [ (master_doc, 'licensecc', 'licensecc Documentation', [author], 1) ] # -- Options for Texinfo output ------------------------------------------- # Grouping the document tree into Texinfo files. List of tuples # (source start file, target name, title, author, # dir menu entry, description, category) texinfo_documents = [ (master_doc, 'licensecc', 'licensecc Documentation', author, 'licensecc', 'One line description of project.', 'Miscellaneous'), ]
File was renamed from doc/Build-the-library-windows.md @@ -1,4 +1,4 @@ @ingroup group_02 # Windows This page describes how to build the library. It's a good starting point if you just downloaded it and you want to start explore.
File was renamed from doc/Build-the-library.md @@ -1,5 +1,3 @@ @ingroup group_01 # Linux ## Install prerequisites doc/development/Dependencies.md
File was renamed from doc/Dependencies.md @@ -1,3 +1,5 @@ # Dependencies This page describes the dependencies of open-license-manager and the supported build environments. Dependencies varies with the environment, if you're building the library for the first time we suggest you download or set up one of the supported environments to be sure not to incur in dependency/compiler errors (you can use virtual machines , docker or lxc/lxd technologies). doc/development/Development-Environment-Setup.md
File was renamed from doc/Development-Environment-Setup.md @@ -1,4 +1,4 @@ # Developer's environment setup This guide is just an help in case you haven't decided your development environment or your development environment match ours. We don't have any specific dependency on development tools, you can choose the one you prefer. Though if you want to contribute you're required to format the code using `clang-format` before you submit the pull request. doc/index.rst
New file @@ -0,0 +1,50 @@ Welcome to licensecc's documentation. ===================================== * :ref:`genindex` * :ref:`modindex` * :ref:`search` .. toctree:: :glob: :maxdepth: 2 :hidden: :caption: Build the library: development/* .. toctree:: :glob: :maxdepth: 2 :hidden: :caption: Integrate and use: usage/* .. toctree:: :glob: :maxdepth: 2 :hidden: :caption: API: api/* .. toctree:: :glob: :maxdepth: 2 :hidden: :caption: Analysis: analysis/* .. toctree:: :glob: :maxdepth: 2 :hidden: :caption: Miscellaneous: other/*
File was renamed from doc/CREDITS.md @@ -1,3 +1,4 @@ # Credits The following open source code has been used in OpenLicenseManager. Thanks to every one of the authors of such projects. Without you open license manager would never have been completed.
File was renamed from doc/QA.md @@ -1,3 +1,5 @@ # Q&A ## Development Development related questions.
File was renamed from doc/Basic-concepts.md @@ -1,12 +1,13 @@ #Basic concepts and terminology # Glossary ##Project Some `common` word that recur into the documentation have a specific meaning. Below an explanation of the terms and concepts used. ## Project A project corresponds to one application where the licensing system need to be integrated. Each project has its own private key and its own folder where `licensecc` is compiled. Currently we support only one project per (build) machine. This is especially true in Windows, where the private key has the same name for all the projects. ##Features ## Features Features let licensed application to selectively enable or disable functions in the application, features are part of the original license, they do not have hardware identifications, they only have validity date. #Customizing the build doc/snippets.txt
@@ -18,4 +18,8 @@ echo "Boost installed" cd C:/local/boost dir ) else echo "Boost already installed" ) else echo "Boost already installed" linux cross compile for windows openssl ./Configure no-zlib no-shared --prefix=$PWD/dist-win-64 --cross-compile-prefix=x86_64-w64-mingw32- mingw64 doc/usage/Hardware-identifiers.md
File was renamed from doc/Hardware-identifiers.md @@ -1,5 +1,8 @@ # Hardware Identifiers ## Use cases Linking the execution of a software to a. With the recent coming of virtualized environments the installation of software directly on the machine has been less and less. Linking the execution of a software to a physical hardware (a pc). With the recent coming of virtualized environments the installation of software directly on the machine has been less and less. OpenLicenseManager guess the environment where the user is trying to launch the software, and reports it to the software publisher when he is generating a license in a way that he can decide how to limit the usage on per license basis. @@ -22,4 +25,5 @@ If the licensed software specify the parameter If the licensed software uses `STRATEGY_DEFAULT` and the strategy generates an unstable identifier it is possible to ask the user to set t If the licensed software uses `STRATEGY_DEFAULT` and the strategy generates an unstable identifier it is possible to ask the user to set the environemnt variable. doc/usage/License-retrieval.md
File was renamed from doc/License-retrieval.md @@ -1,4 +1,5 @@ # License retrieval # Place the license file Open License Manager, when integrated into a licensed software can automatically find its license file (or multiple license files) based on: * An environment variable: doc/usage/integration.md
File was renamed from doc/Integration.md @@ -1,3 +1,5 @@ # Integrate license in your application This short guide explain how to integrate `open-license-manager` in your application. Working examples are provided in the [examples](https://github.com/open-license-manager/examples) project. doc/usage/issue-licenses.md
File was renamed from doc/Issue-licenses.md @@ -1,3 +1,4 @@ # Issue licenses The easiest way to issue licenses is to enter the project library and create the following project structure: The projects folder can be anyware. We created one in `open-license-manager/projects` for your convenience (and for testing purposes). A default project<sup>1</sup> named `DEFAULT` has been created for you when you configured the project with cmake.
