Advanced topics

Development

Mayan EDMS is under active development, and contributions are welcome.

If you have a feature request, suggestion or bug report, please open a new issue on the GitLab issue tracker. To submit patches, please send a merge request on GitLab.

Project philosophies

How to think about Mayan EDMS when doing changes or adding new features; why things are the way they are in Mayan EDMS:

  • Functionality must be as market/sector independent as possible, code for the 95% of use cases.
  • Each user must be able to configure and customize it to their needs after install.
  • Abstract as much as possible, each app must be an expert in just one thing, for other things they should use the API/classes/functions of other apps.
  • Assume as little as possible about anything outside the project (hardware, OS, storage).
  • Provide Python based abstraction so that a default install runs with a single step.
  • No hard dependencies on binaries unless there is no other choice.
  • Provide “drivers” or switchable backends to allow users to fine tune the installation.
  • Call to binaries only when there is no other choice or the Python choices are not viable/mature/efficient.
  • Each app is as independent and self contained as possible. Exceptions, the basic requirements: navigation, permissions, common, main.
  • If an app is meant to be used by more than one other app, it should be as generic as possible in regard to the project and another app will bridge the functionality.
    • Example: since indexing (document_indexing) only applies to documents, the app is specialized and depends on the documents app.

Coding conventions

Follow PEP8

Whenever possible, but don’t obsess over things like line length:

$ flake8 --ignore=E501,E128,E122 |less

To perform automatic PEP8 checks, install flake8’s git hook using:

$ flake8 --install-hook git

Imports

Import order should be:

  • Standard Python modules
  • Installed Python modules
  • Core Django modules
  • Installed Django modules
  • Mayan EDMS modules
  • Local imports

Example:

from __future__ import absolute_import

# Standard Python library
import base64

# 3rd party installed Python libraries
import requests

# Django core modules
from django.db.models import Q
from django.template.defaultfilters import slugify
from django.utils.translation import ugettext
from django.utils.translation import ugettext_lazy as _

# 3rd party installed Django libraries
from rest_framework import APIView

# Mayan apps
from metadata.classes import MetadataClass

# Local app imports (relative)
from .conf.settings import (
    AVAILABLE_INDEXING_FUNCTIONS,
    MAX_SUFFIX_COUNT, SLUGIFY_PATHS
)
from .exceptions import MaxSuffixCountReached
from .filesystem import (
    fs_create_index_directory, fs_create_document_link,
    fs_delete_document_link, fs_delete_index_directory,
    assemble_suffixed_filename
)
from .models import Index, IndexInstanceNode, DocumentRenameCount

All local app module imports are in relative form. Local app module name is to be referenced as little as possible, unless required by a specific feature, trick, restriction (e.g., Runtime modification of the module’s attributes).

Incorrect:

# documents app views.py model
from documents.models import Document

Correct:

# documents app views.py model
from .models import Document

Dependencies

Mayan EDMS apps follow a hierarchical model of dependency. Apps import from their parents or siblings, never from their children. Think plugins. A parent app must never assume anything about a possible existing child app. The documents app and the Document model are the basic entities; they must never import anything else. The common and main apps are the base apps.

Variables

Naming of variables should follow a Major to Minor convention, usually including the purpose of the variable as the first piece of the name, using underscores as spaces. camelCase is not used in Mayan EDMS.

Examples:

Links:

link_document_page_transformation_list = ...
link_document_page_transformation_create = ...
link_document_page_transformation_edit = ...
link_document_page_transformation_delete = ...

Constants:

PERMISSION_SMART_LINK_VIEW = ...
PERMISSION_SMART_LINK_CREATE = ...
PERMISSION_SMART_LINK_DELETE = ...
PERMISSION_SMART_LINK_EDIT = ...

Classes:

class Document(models.Model):
class DocumentPage(models.Model):
class DocumentPageTransformation(models.Model):
class DocumentType(models.Model):
class DocumentTypeFilename(models.Model):

Strings

Quotation character used in Mayan EDMS for strings is the single quote. Double quote is used for multiple line comments or HTML markup.

Migrations

Migrations should do only one thing (eg: either create a table, move data to a new table or remove an old table) to aid retrying on failure.

General

Code should appear in their modules in alphabetic order or in their order of importance if it makes more sense for the specific application. This makes visual scanning easier on modules with a large number of imports, views or classes. Class methods that return a value should be pretended with a get_ to differentiate from an object’s properties. When a variable refers to a file it should be named as follows:

  • filename: The file’s name and extension only.
  • filepath: The entire path to the file including the filename.
  • path: A path to a directory.

Flash messages should end with a period as applicable for the language. Only exception is when the tail of the message contains an exceptions message as passed directly from the exception object.

Source Control

Mayan EDMS source is controlled with Git.

The project is publicly accessible, hosted and can be cloned from GitLab using:

$ git clone https://gitlab.com/mayan-edms/mayan-edms.git

Git branch structure

Mayan EDMS follows a simplified model layout based on Vincent Driessen’s Successful Git Branching Model blog post.

develop
The “next release” branch, likely unstable.
master
Current production release (3.1.7).
feature/
Unfinished/unmerged feature.
series/
Released versions.

Each release is tagged separately.

When submitting patches, please place your code in its own feature/ branch prior to opening a Merge Request on GitLab.

Steps to deploy a development version

$ git clone https://gitlab.com/mayan-edms/mayan-edms.git
$ cd mayan-edms
$ git checkout development
$ virtualenv venv
$ source venv/bin/activate
$ pip install -r requirements.txt
$ ./manage.py initialsetup
$ ./manage.py runserver

Contributing changes

Follow the latest contributing guidelines outlined here: https://gitlab.com/mayan-edms/mayan-edms/blob/master/CONTRIBUTING.md

Debugging

Mayan EDMS makes extensive use of Django’s new logging capabilities. By default debug logging for all apps is turned on. If you wish to customize how logging is managed turn off automatic logging by setting COMMON_AUTO_LOGGING to False and add the following lines to your settings/local.py file:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': True,
    'formatters': {
        'verbose': {
            'format': '%(levelname)s %(asctime)s %(name)s %(process)d %(thread)d %(message)s'
        },
        'intermediate': {
            'format': '%(name)s <%(process)d> [%(levelname)s] "%(funcName)s() %(message)s"'
        },
        'simple': {
            'format': '%(levelname)s %(message)s'
        },
    },
    'handlers': {
        'console':{
            'level':'DEBUG',
            'class':'logging.StreamHandler',
            'formatter': 'intermediate'
        }
    },
    'loggers': {
        'documents': {
            'handlers':['console'],
            'propagate': True,
            'level':'DEBUG',
        },
        'common': {
            'handlers':['console'],
            'propagate': True,
            'level':'DEBUG',
        },
    }
}

Likewise, to see the debug output of the tags app, just add the following inside the loggers block:

'tags': {
    'handlers':['console'],
    'propagate': True,
    'level':'DEBUG',
},

Documentation

The documentation is written in reStructured Text format, processed with Sphinx, and resides in the docs directory. In order to build it, you will first need to install the documentation editing dependencies with:

$ pip install -r requirements/documentation.txt

Then, to build an HTML version of the documentation, run the following command from the docs directory:

$ make docs-serve

The generated documentation can be viewed by browsing to http://127.0.0.1:8000 or by browsing to the docs/_build/html directory.

You can also generate the documentation in formats other than HTML. Consult the Sphinx documentation for more details.

Installable package

Source file package

This is the sequence of step used to produce an installable package:

  1. Generate the packaged version (will produce dist/mayan-edms-x.y.z.tar.gz):

    $ make sdist
    
  2. Do a test install:

    $ cd /tmp
    $ virtualenv venv
    $ source venv/bin/activate
    $ pip install <path of the Git repository>/dist/mayan-edms-x.y.z.tar.gz
    $ mayan-edms.py initialsetup
    $ mayan-edms.py runserver
    

Wheel package

  1. Install the development requirements:

    $ pip install -r requirements/development.txt
    
  2. Create wheel package using the makefile:

    $ make wheel
    
  3. Do a test install:

    $ cd /tmp
    $ virtualenv venv
    $ source venv/bin/activate
    $ pip install <path of the Git repository>/dist/mayan_edms-x.y.z-py2-none-any.whl
    $ mayan-edms.py initialsetup
    $ mayan-edms.py runserver
    

Version numbering

Mayan EDMS uses the Semantic Versioning (http://semver.org/) method to choose version numbers along with Python’s PEP-0440 (https://www.python.org/dev/peps/pep-0440/) to format them.

X.YaN # Alpha release X.YbN # Beta release X.YrcN # Release Candidate X.Y # Final release

Release checklist

  1. Check for missing migrations:

    make check-missing-migrations
    
  2. Synchronize translations:

    make translations-pull
    
  3. Compile translations:

    make translations-compile
    
  4. Write release notes.

  5. Update changelog.

  6. Scan the code with flake8 for simple style warnings.

  7. Check README.rst format with:

    python setup.py check -r -s
    

or with:

make check-readme
  1. Bump version in mayan/__init__.py.

  2. Bump version in docker/version.

  3. Update requirements version in setup.py using:

    make generate-setup
    
  4. Build source package and test:

    make test-sdist-via-docker-ubuntu
    
  5. Build wheel package and test:

    make test-wheel-via-docker-ubuntu
    
  6. Tag version:

    git tag -a vX.Y.Z -m "Version X.Y.Z"
    
  7. Switch to the releases branch:

    git checkout releases
    
  8. Push tag upstream:

    git push --tags
    
  9. Push code to trigger builds:

    git push
    
  10. Build and upload a test release:

    make release-test-via-docker-ubuntu
    
  11. Build and upload a final release:

    make release-via-docker-ubuntu
    

App creation

Mayan EDMS apps are essentially Django app with some extra code to register navigation, permissions and other relationships.

App modules

  • __init__.py

    Should be empty if possible. No initialization code should be here, use the ready() method of the MayanAppConfig class in the apps.py module.

  • admin.py

    Standard Django app module to define how models are to be presented in the admin interface.

  • api_views.py

    REST API views go here. Mayan EDMS uses Django REST Framework API view classes.

  • apps.py

    Contains the MayanAppConfig subclass as required by Django 1.7 and up. This is a place to define the app name and translatable verbose name as well as code to be execute when the modules of the app are ready.

  • classes.py

    Hold python classes to be used internally or externally. Any class defined by the app that is not a model.

  • events.py

    Define event class instances that are later committed to a log by custom code.

  • exceptions.py

    Custom exceptions defined by the app.

  • fields.py

    Place any custom form field classed you define here.

  • forms.py

    Standard Django app module that hold custom form classes.

  • handlers.py

    Contains the signal handlers, functions that will process a given signal emitted from this or other apps. Connect the handler functions to the corresponding signal in the ready() method of the MayanAppConfig subclass in apps.py

  • links.py

    Defines the links to be used by the app. Import only from the navigation app and the local permissions.py file.

  • literals.py

    Stores magic numbers, module choices (if static), settings defaults, and constants. Should contain all capital case variables. Must not import from any other module.

  • managers.py

    Standard Django app module that hold custom model managers. These act as model class method to performs actions in a series of model instances or utilitarian actions on external models instances.

  • models.py

    Standard Django app module that defines ORM persistent data schema.

  • permissions.py

    Defines the permissions to be used to validate user access by links and views. Imports only from the permissions app. Link or view conditions such as testing for is_staff or is_super_user flag are defined in this same module.

  • runtime.py

    Use this module when you need the same instance of a class for the entire app. This module acts as a shared memory space for the other modules of the app or other apps.

  • serializers.py

    Hold Django REST Framework serializers used by the api_views.py module.

  • settings.py

    Define the configuration settings instances that the app will use.

  • signals.py

    Any custom defined signal goes here.

  • statistics.py

    Provides functions that will compute any sort of statistical information on the app’s data.

  • tasks.py

    Code to be execute in the background or as an out-of-process action.

  • tests/ directory

    Hold test modules. There should be one test_*.py module for each aspect being tested, examples: test_api.py, test_views.py, test_parsers.py, test_permissions.py Any shared constant data used by the tests should be added to tests/literals.py

  • utils.py

    Holds utilitarian code that doesn’t fit on any other app module or that is used by several modules in the app. Anything used internally by the app that is not a class or a literal (should be as little as possible)

  • widgets.py

    HTML widgets go here. This should be the only place with presentation directives in the app (aside the templates).

Views

The module common.generics provides custom generic class based views to be used. The basic views used to create, edit, view and delete objects in Mayan EDMS are: SingleObjectCreateView, SingleObjectDetailView, SingleObjectEditView, and SingleObjectListView

These views handle aspects relating to view permissions, object permissions, post action redirection and template context generation.

Upload wizard

The steps needed to upgrade a document using form-tools’ SessionWizard were hardcoded in the source app. This made it very difficult to add or remove wizard steps.

The steps of the wizard are now defined by a new class called sources.wizard.WizardStep. The existing steps to select a document type, enter metadata and tag the document, have been converted to function as WizardSteps subclasses. The converted steps now live in

sources.wizards.WizardStepDocumentType, tag.wizard_steps.WizardStepTags, and metadata.wizard_steps.WizardStepMetadata.

The steps need to define the following methods:

  • done: This method is execute when the wizard finished the last step an enter the step where the actual file are uploaded. This steps is used to encode form data into the URL query string that will be passed to the document upload view for each file uploaded.
  • condition: This method is used to display the step conditionally. If this method return True it will be displayed during the upload wizard execution. To skip the step, return False or None.
  • get_form_initial: This method is used to return the initial data for the step form. Use this method to set up initial values for the step’s form fields.
  • step_post_upload_process: This method will be executed once the document finishes uploading. Use this method to process the information encoded in the URL querystring by the step’s done` method.

Once the WizardStep subclass is defined, it needs to be registered. This is done by calling the .register method of the WizardStep class with the subclass as the argument. Example:

WizardStep.register(WizardStepMetadata)

This statement must be located after the subclass definition. Finally, the module defining the wizard step must be imported so that it is loaded with the rest of the code and enabled. The best place to do this is in the .ready method of the apps’ apps.py module. Example:

class TagsApp(MayanAppConfig):
    has_rest_api = True
    has_tests = True
    name = 'tags'
    verbose_name = _('Tags')

    def ready(self):
        super(TagsApp, self).ready()
        from actstream import registry

        from .wizard_steps import WizardStepTags  # NOQA

The WizardStep class also allows for unregistering existing steps. This is accomplished by calling the .deregister method of the WizardStep class and passing the subclass as the argument. This method should also be called inside the .ready method of an apps’ apps.py module. Example:

class TagsApp(MayanAppConfig):
    has_rest_api = True
    has_tests = True
    name = 'tags'
    verbose_name = _('Tags')

    def ready(self):
        super(TagsApp, self).ready()
        from actstream import registry

        from metadata.wizard_steps import WizardStepMetadata  # NOQA
        from sources.wizards import WizardStep  # NOQA
        from .wizard_steps import WizardStepTags  # NOQA

        WizardStep.deregister(WizardStepTags)

This will cause the tags assigment step to not be assigned to the upload wizard anymore.

Translations

Translations are handled online via the Transifex website: https://www.transifex.com/projects/p/mayan-edms/. To create a translation team for a new language or contribute to an already existing language translation, create a Transifex account and contact the team coordinator of the respective language in which you are interested.

Feel free to open translation issues inside Transifex itself if you have a question about the usage or meaning of a source text string. If you open a translation issue, it will be your responsibility to close it after you get an answers that satisfies your question. Administrator will not close new issues as they have no way to determine if your question has been properly answered. However to avoid clutter, answered questions will be scanned periodically and closed if no activity is observed from the original poster in a period of time.

Mayan EDMS Entity Contributor Assignment Agreement

Thank you for your interest in contributing to Mayan EDMS (“We” or “Us”).

This contributor agreement (“Agreement”) documents the rights granted by contributors to Us. To make this document effective, please print it, sign it (by copyright holder or authorized party) and send it to Us by email to caa@mayan-edms.com. This is a legally binding document, so please read it carefully before agreeing to it. The Agreement may cover more than one software project managed by Us.

1. Definitions

“You” means any Legal Entity on behalf of whom a Contribution has been received by Us. “Legal Entity” means an entity which is not a natural person. “Affiliates” means other Legal Entities that control, are controlled by, or under common control with that Legal Entity. For the purposes of this definition, “control” means (i) the power, direct or indirect, to cause the direction or management of such Legal Entity, whether by contract or otherwise, (ii) ownership of fifty percent (50%) or more of the outstanding shares or securities which vote to elect the management or other persons who direct such Legal Entity or (iii) beneficial ownership of such entity.

“Contribution” means any work of authorship that is Submitted by You to Us in which You own or assert ownership of the Copyright. We cannot accept contributions for which you do not own the Copyright or for which you don’t have the necesary legal power to transfer.

“Copyright” means all rights protecting works of authorship owned or controlled by You or Your Affiliates, including copyright, moral and neighboring rights, as appropriate, for the full term of their existence including any extensions by You.

“Material” means the work of authorship which is made available by Us to third parties. When this Agreement covers more than one software project, the Material means the work of authorship to which the Contribution was Submitted. After You Submit the Contribution, it may be included in the Material.

“Submit” means any form of electronic, verbal, or written communication sent to Us or our representatives, including but not limited to electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, Us for the purpose of discussing and improving the Material, but excluding communication that is conspicuously marked or otherwise designated in writing by You as “Not a Contribution.”

“Submission Date” means the date on which You Submit a Contribution to Us.

“Effective Date” means the date You execute this Agreement or the date You first Submit a Contribution to Us, whichever is earlier.

2. Grant of Rights

2.2 Patent License

For patent claims including, without limitation, method, process, and apparatus claims which You or Your Affiliates own, control or have the right to grant, now or in the future, You grant to Us a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable patent license, with the right to sublicense these rights to multiple tiers of sublicensees, to make, have made, use, sell, offer for sale, import and otherwise transfer the Contribution and the Contribution in combination with the Material (and portions of such combination). This license is granted only to the extent that the exercise of the licensed rights infringes such patent claims; and provided that this license is conditioned upon compliance with Section 2.3.

2.3 Outbound License

As a condition on the grant of rights in Sections 2.1 and 2.2, We agree to license the Contribution only under the terms of the license or licenses which We are using on the Submission Date for the Material (including any rights to adopt any future version of a license if permitted).

2.4 Moral Rights

If moral rights apply to the Contribution, to the maximum extent permitted by law, You waive and agree not to assert such moral rights against Us or our successors in interest, or any of our licensees, either direct or indirect.

2.5 Our Rights

You acknowledge that We are not obligated to use Your Contribution as part of the Material and may decide to include any Contribution We consider appropriate.

2.6 Reservation of Rights

Any rights not expressly assigned or licensed under this section are expressly reserved by You.

3. Agreement

You confirm that:

  1. You have the legal authority to enter into this Agreement.
  2. You or Your Affiliates own the Copyright and patent claims covering the Contribution which are required to grant the rights under Section 2.
  3. The grant of rights under Section 2 does not violate any grant of rights which You or Your Affiliates have made to third parties.

4. Disclaimer

EXCEPT FOR THE EXPRESS WARRANTIES IN SECTION 3, THE CONTRIBUTION IS PROVIDED “AS IS”. MORE PARTICULARLY, ALL EXPRESS OR IMPLIED WARRANTIES INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT ARE EXPRESSLY DISCLAIMED BY YOU TO US AND BY US TO YOU. TO THE EXTENT THAT ANY SUCH WARRANTIES CANNOT BE DISCLAIMED, SUCH WARRANTY IS LIMITED IN DURATION TO THE MINIMUM PERIOD PERMITTED BY LAW.

5. Consequential Damage Waiver

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT WILL YOU OR US BE LIABLE FOR ANY LOSS OF PROFITS, LOSS OF ANTICIPATED SAVINGS, LOSS OF DATA, INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL AND EXEMPLARY DAMAGES ARISING OUT OF THIS AGREEMENT REGARDLESS OF THE LEGAL OR EQUITABLE THEORY (CONTRACT, TORT OR OTHERWISE) UPON WHICH THE CLAIM IS BASED.

6. Miscellaneous

6.1 Jurisdiction

This Agreement will be governed by and construed in accordance with the laws of Puerto Rico excluding its conflicts of law provisions. Under certain circumstances, the governing law in this section might be superseded by the United Nations Convention on Contracts for the International Sale of Goods (“UN Convention”) and the parties intend to avoid the application of the UN Convention to this Agreement and, thus, exclude the application of the UN Convention in its entirety to this Agreement.

6.2 Acceptance

This Agreement sets out the entire agreement between You and Us for Your Contributions to Us and overrides all other agreements or understandings.

6.3 Third parties

If You or We assign the rights or obligations received through this Agreement to a third party, as a condition of the assignment, that third party must agree in writing to abide by all the rights and obligations in the Agreement.

6.4 Unmet responsibilities

The failure of either party to require performance by the other party of any provision of this Agreement in one situation shall not affect the right of a party to require such performance at any time in the future. A waiver of performance under a provision in one situation shall not be considered a waiver of the performance of the provision in the future or a waiver of the provision in its entirety.

6.5 Continuation

If any provision of this Agreement is found void and unenforceable, such provision will be replaced to the extent possible with a provision that comes closest to the meaning of the original provision and which is enforceable. The terms and conditions set forth in this Agreement shall apply notwithstanding any failure of essential purpose of this Agreement or any limited remedy to the maximum extent possible under law.

Name: _________________________________________________


Email: ________________________________________________


Address: ______________________________________________


Address (cont): _______________________________________


Country: ______________________________________________


Phone number: _________________________________________


Fax number: ___________________________________________



_______________________________________________________
                         Signature

Mayan EDMS Entity CAA Version 1.0 April 8, 2018

Mayan EDMS Individual Contributor Assignment Agreement

Thank you for your interest in contributing to Mayan EDMS (“We” or “Us”).

This contributor agreement (“Agreement”) documents the rights granted by contributors to Us. To make this document effective, please print it, sign it (by copyright holder or authorized party) and send it to Us by email to caa@mayan-edms.com. This is a legally binding document, so please read it carefully before agreeing to it. The Agreement may cover more than one software project managed by Us.

1. Definitions

“You” means the individual who Submits a Contribution to Us.

“Contribution” means any work of authorship that is Submitted by You to Us in which You own or assert ownership of the Copyright. We cannot accept contributions for which you do not own the Copyright or for which you don’t have the necesary legal power to transfer.

“Copyright” means all rights protecting works of authorship owned or controlled by You, including copyright, moral and neighboring rights, as appropriate, for the full term of their existence including any extensions by You.

“Material” means the work of authorship which is made available by Us to third parties. When this Agreement covers more than one software project, the Material means the work of authorship to which the Contribution was Submitted. After You Submit the Contribution, it may be included in the Material.

“Submit” means any form of electronic, verbal, or written communication sent to Us or our representatives, including but not limited to electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, Us for the purpose of discussing and improving the Material, but excluding communication that is conspicuously marked or otherwise designated in writing by You as “Not a Contribution.”

“Submission Date” means the date on which You Submit a Contribution to Us.

“Effective Date” means the date You execute this Agreement or the date You first Submit a Contribution to Us, whichever is earlier.

2. Grant of Rights

2.1 Copyright Assignment

  1. At the time the Contribution is Submitted, You assign to Us all right, title, and interest worldwide in all Copyright covering the Contribution; provided that this transfer is conditioned upon compliance with Section 2.3.
  2. To the extent that any of the rights in Section 2.1(a) cannot be assigned by You to Us, You grant to Us a perpetual, worldwide, exclusive, royalty-free, transferable, irrevocable license under such non-assigned rights, with rights to sublicense through multiple tiers of sublicensees, to practice such non-assigned rights, including, but not limited to, the right to reproduce, modify, display, perform and distribute the Contribution; provided that this license is conditioned upon compliance with Section 2.3.
  3. To the extent that any of the rights in Section 2.1(a) can neither be assigned nor licensed by You to Us, You irrevocably waive and agree never to assert such rights against Us, any of our successors in interest, or any of our licensees, either direct or indirect; provided that this agreement not to assert is conditioned upon compliance with Section 2.3.
  4. Upon such transfer of rights to Us, the Contribution will be licenses under the terms of the Material.

2.2 Patent License

For patent claims including, without limitation, method, process, and apparatus claims which You own, control or have the right to grant, now or in the future, You grant to Us a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable patent license, with the right to sublicense these rights to multiple tiers of sublicensees, to make, have made, use, sell, offer for sale, import and otherwise transfer the Contribution and the Contribution in combination with the Material (and portions of such combination). This license is granted only to the extent that the exercise of the licensed rights infringes such patent claims; and provided that this license is conditioned upon compliance with Section 2.3.

2.3 Outbound License

As a condition on the grant of rights in Sections 2.1 and 2.2, We agree to license the Contribution only under the terms of the license or licenses which We are using on the Submission Date for the Material (including any rights to adopt any future version of a license if permitted).

2.4 Moral Rights

If moral rights apply to the Contribution, to the maximum extent permitted by law, You waive and agree not to assert such moral rights against Us or our successors in interest, or any of our licensees, either direct or indirect.

2.5 Our Rights

You acknowledge that We are not obligated to use Your Contribution as part of the Material and may decide to include any Contribution We consider appropriate.

2.6 Reservation of Rights

Any rights not expressly assigned or licensed under this section are expressly reserved by You.

3. Agreement

You confirm that:

  1. You have the legal authority to enter into this Agreement.
  2. You own the Copyright and patent claims covering the Contribution which are required to grant the rights under Section 2.
  3. The grant of rights under Section 2 does not violate any grant of rights which You have made to third parties, including Your employer. If You are an employee, You have had Your employer approve this Agreement or sign the Entity version of this document. If You are less than eighteen years old, please have Your parents or guardian sign the Agreement.

4. Disclaimer

EXCEPT FOR THE EXPRESS WARRANTIES IN SECTION 3, THE CONTRIBUTION IS PROVIDED “AS IS”. MORE PARTICULARLY, ALL EXPRESS OR IMPLIED WARRANTIES INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT ARE EXPRESSLY DISCLAIMED BY YOU TO US AND BY US TO YOU. TO THE EXTENT THAT ANY SUCH WARRANTIES CANNOT BE DISCLAIMED, SUCH WARRANTY IS LIMITED IN DURATION TO THE MINIMUM PERIOD PERMITTED BY LAW.

5. Consequential Damage Waiver

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT WILL YOU OR US BE LIABLE FOR ANY LOSS OF PROFITS, LOSS OF ANTICIPATED SAVINGS, LOSS OF DATA, INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL AND EXEMPLARY DAMAGES ARISING OUT OF THIS AGREEMENT REGARDLESS OF THE LEGAL OR EQUITABLE THEORY (CONTRACT, TORT OR OTHERWISE) UPON WHICH THE CLAIM IS BASED.

6. Miscellaneous

6.1 Jurisdiction

This Agreement will be governed by and construed in accordance with the laws of Puerto Rico excluding its conflicts of law provisions. Under certain circumstances, the governing law in this section might be superseded by the United Nations Convention on Contracts for the International Sale of Goods (“UN Convention”) and the parties intend to avoid the application of the UN Convention to this Agreement and, thus, exclude the application of the UN Convention in its entirety to this Agreement.

6.2 Acceptance

This Agreement sets out the entire agreement between You and Us for Your Contributions to Us and overrides all other agreements or understandings.

6.3 Third parties

If You or We assign the rights or obligations received through this Agreement to a third party, as a condition of the assignment, that third party must agree in writing to abide by all the rights and obligations in the Agreement.

6.4 Unmet responsibilities

The failure of either party to require performance by the other party of any provision of this Agreement in one situation shall not affect the right of a party to require such performance at any time in the future. A waiver of performance under a provision in one situation shall not be considered a waiver of the performance of the provision in the future or a waiver of the provision in its entirety.

6.5 Continuation

If any provision of this Agreement is found void and unenforceable, such provision will be replaced to the extent possible with a provision that comes closest to the meaning of the original provision and which is enforceable. The terms and conditions set forth in this Agreement shall apply notwithstanding any failure of essential purpose of this Agreement or any limited remedy to the maximum extent possible under law.

Name: _________________________________________________


Email: ________________________________________________


Address: ______________________________________________


Address (cont): _______________________________________


Country: ______________________________________________


Phone number: _________________________________________


Fax number: ___________________________________________



_______________________________________________________
                         Signature

Mayan EDMS Individual CAA Version 1.0 April 8, 2018