rabarber 5.0.0 → 5.1.1

data/README.md

@@ -1,60 +1,37 @@
-# Rabarber: Simplified Authorization for Rails
+# Rabarber: Role-Based Authorization for Rails
 
 [![Gem Version](https://badge.fury.io/rb/rabarber.svg)](http://badge.fury.io/rb/rabarber)
 [![Github Actions badge](https://github.com/brownboxdev/rabarber/actions/workflows/ci.yml/badge.svg)](https://github.com/brownboxdev/rabarber/actions/workflows/ci.yml)
 
-Rabarber is a role-based authorization library for Ruby on Rails. It provides a set of tools for managing user roles and defining authorization rules, with support for multi-tenancy and fine-grained access control.
+Rabarber is a role-based authorization library for Ruby on Rails that focuses on controller-level access control. Rather than answering domain questions like "can this user create a post?", Rabarber answers "can this user access the create post endpoint?", providing a clean separation between authorization and business logic.
 
----
+**Key Features:**
 
-**Example of Usage**:
-
-Consider a CRM system where users with different roles have distinct access levels. For instance, the role `accountant` can interact with invoices but cannot access marketing information, while the role `marketer` has access to marketing-related data. You can define such authorization rules easily with Rabarber.
-
----
-
-And this is how your controller might look with Rabarber:
-
-```rb
-class TicketsController < ApplicationController
-  grant_access roles: :admin
-
-  grant_access action: :index, roles: :manager
-  def index
-    # ...
-  end
-
-  def delete
-    # ...
-  end
-end
-```
-
-This means that `admin` users can access everything in `TicketsController`, while `manager` role can access only `index` action.
+- Role-based authorization
+- Controller-level access control
+- Multi-tenancy support through contextual roles
+- Dynamic authorization with conditional logic
+- View helpers for role-based content rendering
 
 ## Table of Contents
 
-**Gem usage:**
+**Gem Usage:**
   - [Installation](#installation)
   - [Configuration](#configuration)
-  - [Role Assignments](#role-assignments)
+  - [User Role Methods](#user-role-methods)
   - [Role Management](#role-management)
-  - [Authorization Rules](#authorization-rules)
-  - [Dynamic Authorization Rules](#dynamic-authorization-rules)
-  - [Context / Multi-tenancy](#context--multi-tenancy)
-  - [When Unauthorized](#when-unauthorized)
-  - [Skip Authorization](#skip-authorization)
+  - [Controller Authorization](#controller-authorization)
+  - [Dynamic Rules](#dynamic-rules)
+  - [Multi-tenancy / Context](#multi-tenancy--context)
   - [View Helpers](#view-helpers)
 
+
 **Community Resources:**
-  - [Problems?](#problems)
-  - [Contributing](#contributing)
+  - [Getting Help and Contributing](#getting-help-and-contributing)
+  - [License](#license)
   - [Code of Conduct](#code-of-conduct)
   - [Old Versions](#old-versions)
 
-**Legal:**
-  - [License](#license)
-
 ## Installation
 
 Add Rabarber to your Gemfile:
@@ -69,19 +46,17 @@ Install the gem:
 bundle install
 ```
 
-Generate a migration to create tables for storing roles. Run the generator with the table name used by the model that represents users in your application. For example, if the table is `users`, run:
+Generate the migration for role storage (replace `users` with your user table name if different):
 
 ```shell
-rails g rabarber:roles users
-```
+# For standard integer IDs
+rails generate rabarber:roles users
 
-Rabarber supports UUIDs as primary keys. If your application uses UUIDs, add `--uuid` option:
-
-```shell
-rails g rabarber:roles users --uuid
+# For UUID primary keys
+rails generate rabarber:roles users --uuid
 ```
 
-Finally, run the migration:
+Run the migration:
 
 ```shell
 rails db:migrate
@@ -89,507 +64,346 @@ rails db:migrate
 
 ## Configuration
 
-If customization is required, Rabarber can be configured using `.configure` method in an initializer:
+Configure Rabarber in an initializer if customization is needed:
 
 ```rb
 Rabarber.configure do |config|
-  config.cache_enabled = true
-  config.current_user_method = :current_user
-  config.user_model_name = "User"
+  config.cache_enabled = true                 # Enable role caching (default: true)
+  config.current_user_method = :current_user  # Method to access current user (default: :current_user)
+  config.user_model_name = "User"             # User model name (default: "User")
 end
 ```
 
-- `cache_enabled` determines whether roles are cached to avoid unnecessary database queries. Roles are cached by default. If you need to clear the cache, use `Rabarber::Cache.clear` method.
-- `current_user_method` defines the method used to access the currently authenticated user. Default is `:current_user`.
-- `user_model_name` sets the name of the model representing the user in your application. Default is `"User"`.
-
-## Role Assignments
-
-Rabarber automatically augments your user model (defined via `user_model_name` configuration) with role-related methods.
-
-**`#assign_roles(*roles, context: nil, create_new: true)`**
-
-To assign roles, use:
-
-```rb
-user.assign_roles(:accountant, :marketer)
-```
-
-By default, it will automatically create any roles that don't exist. To assign only existing roles and prevent automatic creation, pass `create_new: false`:
+To clear the role cache manually:
 
 ```rb
-user.assign_roles(:accountant, :marketer, create_new: false)
+Rabarber::Cache.clear
 ```
 
-The method returns an array of roles assigned to the user.
+## User Role Methods
 
-**`#revoke_roles(*roles, context: nil)`**
+Your user model is automatically augmented with role management methods:
 
-To revoke roles, use:
+### Role Assignment
 
 ```rb
-user.revoke_roles(:accountant, :marketer)
-```
-
-Roles the user doesn’t have are ignored.
+# Assign roles (creates roles if they don't exist)
+user.assign_roles(:accountant, :manager)
 
-The method returns an array of roles assigned to the user.
+# Assign only existing roles
+user.assign_roles(:accountant, :manager, create_new: false)
 
-**`#has_role?(*roles, context: nil)`**
+# Revoke specific roles
+user.revoke_roles(:accountant, :manager)
 
-To check whether the user has a role, use:
-
-```rb
-user.has_role?(:accountant, :marketer)
+# Revoke all roles
+user.revoke_all_roles
 ```
 
-It returns `true` if the user has at least one of the given roles.
-
-**`#roles(context: nil)`**
-
-To get the list of roles assigned to the user, use:
+### Role Queries
 
 ```rb
-user.roles
-```
+# Check if user has any of the specified roles
+user.has_role?(:accountant, :manager)
 
-**`#all_roles`**
-
-To get all roles assigned to the user, grouped by context, use:
+# Get user's roles
+user.roles
 
-```rb
+# Get all roles grouped by context
 user.all_roles
 ```
 
-**`.assignees(role_name, context: nil)`**
-
-To get all the users to whom the role is assigned, use:
-
-```rb
-Rabarber::Role.assignees(:admin)
-```
-
 ## Role Management
 
-To manipulate roles directly, you can use the following methods:
-
-**`.add(role_name, context: nil)`**
-
-To add a new role, use:
+### Direct Role Operations
 
 ```rb
+# Create a new role
 Rabarber::Role.add(:admin)
-```
-
-This will create a new role with the specified name and return `true`. If the role already exists, it will return `false`.
-
-**`.rename(old_role_name, new_role_name, context: nil, force: false)`**
-
-To rename a role, use:
 
-```rb
+# Rename a role
 Rabarber::Role.rename(:admin, :administrator)
-```
-
-The old role must exist. If it doesn’t, an error is raised. If a role with the new name already exists, the method returns `false` and the rename fails.
-
-The rename also fails if the role is assigned to any user. To force it, use:
-
-```rb
-Rabarber::Role.rename(:admin, :administrator, force: true)
-```
-
-**`.remove(role_name, context: nil, force: false)`**
-
-To remove a role, use:
+Rabarber::Role.rename(:admin, :administrator, force: true) # Force if role is assigned to users
 
-```rb
+# Remove a role
 Rabarber::Role.remove(:admin)
-```
-
-The old role must exist. If it doesn’t, an error is raised. The method returns `true` if successful.
-
-If the role is assigned to any user, removal will fail. To force it, use:
-
-```rb
-Rabarber::Role.remove(:admin, force: true)
-```
-
-**`.names(context: nil)`**
-
-If you need to list the roles available in your application, use:
+Rabarber::Role.remove(:admin, force: true) # Force if role is assigned to users
 
-```rb
+# List available roles
 Rabarber::Role.names
-```
-
-**`.all_names`**
+Rabarber::Role.all_names # All roles grouped by context
 
-If you need to list all roles available in your application, grouped by context, use:
-
-```rb
-Rabarber::Role.all_names
+# Get users assigned to a role
+Rabarber::Role.assignees(:admin)
 ```
 
-## Authorization Rules
+## Controller Authorization
 
-Include `Rabarber::Authorization` module in the controller where you want to define authorization rules. Typically, it is `ApplicationController`, but it can be any controller of your choice. Then use `.with_authorization(options = {})` method, which accepts the same options as Rails’ `before_action`, allowing you to perform authorization checks selectively.
+### Basic Setup
+
+Include the authorization module and configure protection:
 
 ```rb
 class ApplicationController < ActionController::Base
   include Rabarber::Authorization
 
-  with_authorization
-
-  # ...
+  with_authorization # Enable authorization for all actions
 end
 
 class InvoicesController < ApplicationController
-  with_authorization only: [:update, :destroy]
-
-  # ...
+  with_authorization only: [:update, :destroy] # Selective authorization
 end
 ```
 
-You must ensure the user is authenticated before authorization checks are performed.
+Authorization requires an authenticated user.
 
-To define authorization rules, use `.grant_access(action: nil, roles: nil, context: nil, if: nil, unless: nil)` method.
+### Skip Authorization
 
-The most basic usage of the method is as follows:
+You can also selectively skip authorization:
 
 ```rb
-module Crm
-  class InvoicesController < ApplicationController
-    grant_access action: :index, roles: [:accountant, :admin]
-    def index
-      @invoices = Invoice.all
-      @invoices = @invoices.paid if current_user.has_role?(:accountant)
-      # ...
-    end
-
-    grant_access action: :destroy, roles: :admin
-    def destroy
-      # ...
-    end
-  end
+class TicketsController < ApplicationController
+  skip_authorization except: [:create, :update, :destroy]
 end
 ```
 
-This grants access to `index` action for users with `accountant` or `admin` role, and access to `destroy` action for `admin` users only.
+### Authorization Rules
 
-You can also define controller-wide rules (without `action` argument):
+Define access rules using `grant_access`:
 
 ```rb
-module Crm
-  class BaseController < ApplicationController
-    grant_access roles: [:admin, :manager]
-
-    grant_access action: :dashboard, roles: :marketer
-    def dashboard
-      # ...
-    end
-  end
-end
+class TicketsController < ApplicationController
+  # Controller-wide access
+  grant_access roles: :admin
 
-module Crm
-  class InvoicesController < Crm::BaseController
-    grant_access roles: :accountant
-    def index
-      # ...
-    end
+  # Action-specific access
+  grant_access action: :index, roles: [:manager, :support]
+  def index
+    # Accessible to admin, manager, and support roles
+  end
 
-    def delete
-      # ...
-    end
+  grant_access action: :destroy, roles: :owner, context: -> { Ticket.find(params[:id]) }
+  def destroy
+    # Accessible to admin and owner of the ticket
   end
 end
 ```
 
-In this example, `admin` and `manager` have access to all actions in `Crm::BaseController` and its descendants, while `accountant` role has access only to the actions in `Crm::InvoicesController`. Users with `marketer` role can only see the dashboard.
+### Additive Rules
 
-You can also omit roles to allow unrestricted access:
+Rules are additive across inheritance chains and for the same actions:
 
 ```rb
-class OrdersController < ApplicationController
-  grant_access
-  # ...
+class BaseController < ApplicationController
+  grant_access roles: :admin # Admin can access everything
 end
 
-class InvoicesController < ApplicationController
-  grant_access action: :index
+class InvoicesController < BaseController
+  grant_access roles: :accountant # Accountant can also access InvoicesController (along with admin)
+
+  grant_access action: :index, roles: :manager
+  grant_access action: :index, roles: :supervisor
   def index
-    # ...
+    # Index is accessible to admin, accountant, manager, and supervisor
   end
 end
 ```
 
-This allows everyone to access `OrdersController` and its descendants as well as `index` action in `InvoicesController`.
+### Unrestricted Access
 
-Rules defined in descendant classes don't override ancestor rules but rather add to them:
+Omit roles to allow unrestricted access:
 
 ```rb
-module Crm
-  class BaseController < ApplicationController
-    grant_access roles: :admin
-  # ...
-  end
+class UnrestrictedController < ApplicationController
+  grant_access # Allow all users
 end
 
-module Crm
-  class InvoicesController < Crm::BaseController
-    grant_access roles: :accountant
-  # ...
+class MixedController < ApplicationController
+  grant_access action: :index # Unrestricted index action
+  def index
+    # Accessible to all users
   end
-end
-```
 
-This means that `Crm::InvoicesController` is still accessible to `admin` but is also accessible to `accountant`.
-
-This also applies when defining multiple rules for the same controller or action:
-
-```rb
-module Crm
-  class OrdersController < ApplicationController
-    grant_access roles: :manager, context: Order
-    grant_access roles: :admin
-
-    grant_access action: :show, roles: :client, context: -> { Order.find(params[:id]) }
-    grant_access action: :show, roles: :accountant
-    def show
-      # ...
-    end
+  grant_access action: :show, roles: :member # Restricted show action
+  def show
+    # Accessible to members only
   end
 end
 ```
 
-This will add rules for `manager` and `admin` roles for all actions in `Crm::OrdersController`, and for `client` and `accountant` roles for the `show` action.
-
-## Dynamic Authorization Rules
+### Custom Unauthorized Handling
 
-For more complex scenarios, Rabarber supports dynamic authorization rules:
+Override `when_unauthorized` method to customize unauthorized access behavior:
 
 ```rb
-module Crm
-  class OrdersController < ApplicationController
-    grant_access roles: :manager, if: :company_manager?, unless: :fired?
-
-    def index
-      # ...
-    end
-
-    private
+class ApplicationController < ActionController::Base
+  include Rabarber::Authorization
 
-    def company_manager?
-      Company.find(params[:company_id]).manager == current_user
-    end
+  with_authorization
 
-    def fired?
-      current_user.fired?
-    end
-  end
-end
+  private
 
-module Crm
-  class InvoicesController < ApplicationController
-    grant_access roles: :senior_accountant
-
-    grant_access action: :index, roles: [:secretary, :accountant], if: -> { InvoicesPolicy.new(current_user).can_access?(:index) }
-    def index
-      @invoices = Invoice.all
-      @invoices = @invoices.where("total < 10000") if current_user.has_role?(:accountant)
-      @invoices = @invoices.unpaid if current_user.has_role?(:secretary)
-      # ...
-    end
-
-    grant_access action: :show, roles: :accountant, unless: -> { Invoice.find(params[:id]).total > 10_000 }
-    def show
-      # ...
-    end
+  def when_unauthorized
+    # Default behavior: redirect back (HTML) or return 403 (other formats)
+    # Custom behavior example:
+    head :not_found # Hide existence of protected resources
   end
 end
 ```
 
-You can pass a dynamic rule as `if` or `unless` argument. You can pass a symbol (method name) or a proc. Symbols refer to instance methods, and procs are evaluated in the controller at request time.
+By default, Rabarber will redirect back (HTML format) or return 403 (other formats).
+
+## Dynamic Rules
 
-You can use only dynamic rules without specifying roles if that suits your needs:
+Add conditional logic to authorization rules:
 
 ```rb
-class InvoicesController < ApplicationController
-  grant_access action: :index, if: -> { current_user.company == Company.find(params[:company_id]) }
+class OrdersController < ApplicationController
+  # Method-based conditions
+  grant_access roles: :manager, if: :company_manager?, unless: :suspended?
+
+  # Proc-based conditions
+  grant_access action: :show, roles: :client, if: -> { current_user.company_id == Order.find(params[:id]).company_id }
+  def show
+    # Accessible to company managers unless suspended, and to clients if the client's company matches the order's company
+  end
+
+  # Dynamic-only rules (no roles required, can be used with custom policies)
+  grant_access action: :index, if: -> { OrdersPolicy.new(current_user).can_access?(:index) }
   def index
-    # ...
+    # Accessible to company managers unless suspended, and to users based on custom policy logic
   end
-end
-```
 
-This allows you to use Rabarber as a policy-based authorization library by calling your own custom policy within a dynamic rule:
+  private
 
-```rb
-class InvoicesController < ApplicationController
-  grant_access action: :index, if: -> { InvoicesPolicy.new(current_user).can_access?(:index) }
-  def index
-    # ...
+  def company_manager?
+    current_user.manager_of?(Company.find(params[:company_id]))
+  end
+
+  def suspended?
+    current_user.suspended?
   end
 end
 ```
 
-## Context / Multi-tenancy
-
-Rabarber supports multi-tenancy through its context feature. This allows you to define and authorize roles and rules within a specific context.
+## Multi-tenancy / Context
 
-Every Rabarber method can accept a context as an additional keyword argument. By default, the context is set to `nil`, meaning the roles are global. Thus, all examples from other sections of this README are valid for global roles. Besides being global, context can also be an instance of an `ActiveRecord` model or a class.
+All Rabarber methods accept a `context` parameter, allowing you to work with roles within specific scopes rather than globally.
 
-E.g., consider a model named `Project`, where each project has its owner and regular members. Roles can be defined like this:
+### Contextual Role Assignment
 
 ```rb
+# Assign roles within a specific model instance
 user.assign_roles(:owner, context: project)
-another_user.assign_roles(:member, context: project)
-```
-
-You can then check roles like this:
+user.assign_roles(:member, context: project)
 
-```rb
-user.has_role?(:owner, context: project)
-another_user.has_role?(:member, context: project)
-```
-
-A role can also be added using a class as a context, e.g., for project admins who can manage all projects:
-
-```rb
+# Assign roles within a model class (e.g., project admin)
 user.assign_roles(:admin, context: Project)
-```
 
-And to check it:
-
-```rb
+# Check contextual roles
+user.has_role?(:owner, context: project)
 user.has_role?(:admin, context: Project)
+
+# Get roles within context
+user.roles(context: project)
+Rabarber::Role.names(context: Project)
 ```
 
-In authorization rules, the context can be used in the same way, but it also can be a proc or a symbol (similar to dynamic rules):
+### Contextual Authorization
 
 ```rb
 class ProjectsController < ApplicationController
+  # Class-based context
   grant_access roles: :admin, context: Project
 
-  grant_access action: :show, roles: :member, context: :project
+  # Instance-based context (method)
+  grant_access action: :show, roles: :member, context: :current_project
   def show
-    # ...
+    # Accessible to Project admin and members of the current project
   end
 
+  # Instance-based context (proc)
   grant_access action: :update, roles: :owner, context: -> { Project.find(params[:id]) }
   def update
-    # ...
+    # Accessible to Project admin and owner of the current project
   end
 
   private
 
-  def project
-    Project.find(params[:id])
+  def current_project
+    @current_project ||= Project.find(params[:id])
   end
 end
 ```
 
-Role names are scoped by context, i.e. `admin` in a project is different from a global `admin`, or from an `admin` in another project.
+### Context Migrations
 
-If you want to see all the roles assigned to a user within a specific context, you can use:
+Handle context changes when models are renamed or removed. These are irreversible data migrations.
 
 ```rb
-user.roles(context: project)
-```
+# Rename a context class (e.g., when you rename your Project model to Campaign)
+migrate_authorization_context!("Project", "Campaign")
 
-Or if you want to get all the roles available in a specific context, you can use:
-
-```rb
-Rabarber::Role.names(context: Project)
+# Remove orphaned context data (e.g., when you delete a model entirely)
+delete_authorization_context!("DeletedModel")
 ```
 
-If a context object (e.g., a project) is deleted, any roles tied to it automatically become irrelevant and are no longer returned by role queries. Rabarber treats them as orphaned and ignores them.
-
-However, if a context class is renamed (e.g., `Project` becomes `Campaign`), an exception will be raised the next time Rabarber attempts to load roles for that class. This is to ensure you explicitly handle the migration, either by migrating existing roles to the new context or by cleaning up old data.
-
-To help with such scenarios, Rabarber provides two helper methods that can be called in migrations:
-
-- `migrate_authorization_context!(old_context, new_context)` - renames a context
-- `delete_authorization_context!(context)` – removes roles tied to a deleted context
-
-These are irreversible data migrations.
-
-## When Unauthorized
-
-By default, Rabarber redirects back on unauthorized access if the request format is HTML (falling back to the root path), and returns a 401 Unauthorized for other formats.
-
-You can customize this behavior by overriding the private `when_unauthorized` method:
-
-```rb
-class ApplicationController < ActionController::Base
-  include Rabarber::Authorization
-
-  with_authorization
-
-  # ...
-
-  private
-
-  def when_unauthorized
-    head :not_found # pretend the page doesn't exist
-  end
-end
-```
-
-The method can be overridden in different controllers, providing flexibility in handling unauthorized access attempts.
-
-## Skip Authorization
-
-To skip authorization, use `.skip_authorization(options = {})` method:
-
-```rb
-class TicketsController < ApplicationController
-  skip_authorization only: :index
-  # ...
-end
-```
-
-This method accepts the same options as Rails’ `skip_before_action`.
-
 ## View Helpers
 
-Rabarber provides two helpers for use in views: `visible_to(*roles, context: nil, &block)` and `hidden_from(*roles, context: nil, &block)`. To enable them, include `Rabarber::Helpers` in your helper module, typically `ApplicationHelper`.
+Include view helpers in your application:
 
 ```rb
 module ApplicationHelper
   include Rabarber::Helpers
-  # ...
 end
 ```
 
-The usage is straightforward:
+Use conditional rendering based on roles:
 
 ```erb
 <%= visible_to(:admin, :manager) do %>
-  <p>Visible only to admins and managers</p>
+  <div class="admin-panel">
+    <!-- Admin/Manager content -->
+  </div>
 <% end %>
-```
 
-```erb
-<%= hidden_from(:accountant) do %>
-  <p>Accountant cannot see this</p>
+<%= hidden_from(:guest) do %>
+  <div class="member-content">
+    <!-- Content hidden from guests -->
+  </div>
+<% end %>
+
+<!-- With context -->
+<%= visible_to(:owner, context: @project) do %>
+  <button>Delete Project</button>
 <% end %>
 ```
 
-## Problems?
+## Getting Help and Contributing
 
-Facing a problem or want to suggest an enhancement?
+### Getting Help
+Have a question or need assistance? Open a discussion in our [discussions section](https://github.com/brownboxdev/rabarber/discussions) for:
+- Usage questions
+- Implementation guidance
+- Feature suggestions
 
-- **Open a Discussion**: If you have a question, experience difficulties using the gem, or have a suggestion for improvements, feel free to use the Discussions section.
+### Reporting Issues
+Found a bug? Please [create an issue](https://github.com/brownboxdev/rabarber/issues) with:
+- A clear description of the problem
+- Steps to reproduce the issue
+- Your environment details (Rails version, Ruby version, etc.)
 
-Encountered a bug?
+### Contributing Code
+Ready to contribute? You can:
+- Fix bugs by submitting pull requests
+- Improve documentation
+- Add new features (please discuss first in our [discussions section](https://github.com/brownboxdev/rabarber/discussions))
 
-- **Create an Issue**: If you've identified a bug, please create an issue. Be sure to provide detailed information about the problem, including the steps to reproduce it.
-- **Contribute a Solution**: Found a fix for the issue? Feel free to create a pull request with your changes.
+Before contributing, please read the [contributing guidelines](https://github.com/brownboxdev/rabarber/blob/main/CONTRIBUTING.md)
 
-## Contributing
+## License
 
-Before creating an issue or a pull request, please read the [contributing guidelines](https://github.com/brownboxdev/rabarber/blob/main/CONTRIBUTING.md).
+The gem is available as open source under the terms of the [MIT License](https://github.com/brownboxdev/rabarber/blob/main/LICENSE.txt).
 
 ## Code of Conduct
 
@@ -601,7 +415,3 @@ Only the latest major version is supported. Older versions are obsolete and not
 
 [v4.x.x](https://github.com/brownboxdev/rabarber/blob/9353e70281971154d5acd70693620197a132c543/README.md) | [v3.x.x](https://github.com/brownboxdev/rabarber/blob/3bb273de7e342004abc7ef07fa4d0a9a3ce3e249/README.md)
  | [v2.x.x](https://github.com/brownboxdev/rabarber/blob/875b357ea949404ddc3645ad66eddea7ed4e2ee4/README.md) | [v1.x.x](https://github.com/brownboxdev/rabarber/blob/b81428429404e197d70317b763e7b2a21e02c296/README.md)
-
-## License
-
-The gem is available as open source under the terms of the [MIT License](https://github.com/brownboxdev/rabarber/blob/main/LICENSE.txt).