Software Archives - XpresServers

Understanding Open-Source Software Licenses

Introduction

A software license is a legal agreement that defines how a given piece of software can be used. For software developers who may want to exercise certain rights, permissions, and control over how the work is used, modified, and shared by others, choosing a software license is an important decision. Some developers may want to place strong restrictions over how their software can be used. Others, however, may choose to license their software with few or no restrictions. This may be because they want their software to be as widely used as possible, or perhaps they oppose restrictive software licenses on philosophical grounds.

Regardless of their reasoning, developers can accomplish this by implementing an open-source software license. Broadly speaking, open-source software licenses make the source code available for use, modification, and distribution based on agreed-upon terms and conditions. There are many different open-source software licenses, and they vary based on the restrictions a creator may want future users to abide by.

When it comes to long-term planning for your project, it’s useful to understand the open-source software licenses available so that you can make an informed decision about which one best suits your project’s needs. In this article, we will share information about rights you have when your work is created (such as copyright), and how licensing helps establish the legal agreement you want your users to abide by when using your software. We will also discuss the differences between proprietary, free, and open-source software, permissive and copyleft licenses, and information about the open-source software license options suggested when creating a GitHub project.

Note: This article is not intended to provide any form of legal advice, it’s solely a resource of information on the topic of open-source software licensing.

If you’d like to learn more about patents, trademarks, and intellectual property, you can visit the U.S. Patent and Trademark Office.

Defining Copyright and Licensing

In the U.S. and many countries, there are certain legal protections you are automatically granted for any creative work you produce, one of those being copyright. The U.S. Copyright Office defines copyright as “a type of intellectual property that protects original works of authorship,” specifically when the “author fixes the work in a tangible form of expression.” This means with copyright you are not the owner of the idea, but rather the material expression of the idea. If a copyright owner desires stricter legal protection over their work, this can be achieved through patents, trademarks, and intellectual property laws. Copyrighting your work does not require a formal process to ensure these rights are given.

Copyright grants the owner various rights, such as reproducing and distributing copies of the work. If an owner wants control over how their work can be used by others, then they must implement a license that outlines the rules by which those users must abide. If the copyright owner states the work is “All Rights Reserved”, this means that their work cannot be used or modified by anyone at all, except themselves.

Another complexity to acknowledge is the creative work you produce for your employer. If you’re engaging in what is known as work for hire, this means that any work you create for the company or organization you work for belongs to that entity, since they’re paying you for the work. As a result, sharing this work without permission has legal consequences since you do not have ownership rights to copyright or licensing.

Proprietary Software, Free Software, and Open-Source Software

Proprietary software is any software with a license that restricts how it can be used, modified, or shared. Video games are a common example of proprietary software. If you purchase a video game (whether as a cartridge, disc, or digital download), you aren’t allowed to make a copy of that game to share with friends or sell for profit. It’s also likely you aren’t permitted to modify the game’s code to run it on a different platform than the one you originally bought it for.

Software users are typically held to certain restrictions with an end-user license agreement (EULA). If you’ve ever purchased software, you may have assumed you own that piece of software. However, if you’ve purchased proprietary software, it will likely come with a EULA that specifies you do not own the software. Instead, you’re the owner of a software license that permits you to use that software. EULAs may also define how you can use the license itself, and they typically limit you from sharing it with others without the permission of the software owner (the software’s developer or publisher).

Another legal instrument similar to a EULA is a Terms of Service agreement (ToS). Sometimes known as Terms of Use or Terms and Conditions, a ToS outlines the rules a user must follow in order to be allowed to use a program or service. It’s more common to see an EULA included with software that requires a one-time purchase, while ToS agreements are more common for subscription services and websites. Oftentimes, the first time you start a given piece of proprietary software, a dialog box will appear which explains the EULA or ToS and contains an I Agree button (or something similar) which you must click before you can use the program.

Software with such restrictions hasn’t always been the norm. Before the 1970s, software was typically distributed along with its source code, meaning users were free to modify and share the software as they desired. With time, though, software publishers began imposing restrictions on these activities, typically with the goal of increasing profits by reducing the number of people who used their software but didn’t pay for it.

This development had repercussions in the form of two closely related movements: the free software and the open-source software movements. Although the two are distinct, the free software and open-source software movements both argue that software users should be allowed to access a program’s source code, modify it as they see fit, and share it as often and with whomever they like.

Note: Since free software is generally considered to be open source, but open-source software is not always considered to be free, this guide will default to the more inclusive terms “open-source software” and “open-source software licenses” moving forward. However, please be aware that the two terms are not always interchangeable.

If you’d like a more thorough explanation of the history and differences between free software and open-source software, we encourage you to read our article on The Difference Between Free and Open-Source Software.

Open-source software advocates still encourage developers to distribute their software with a license. However, instead of a proprietary software license outlining what users may not do, they recommend using an open-source software license that outlines the freedoms available to users of the given piece of software. These licenses are often distributed as a single file within the program, typically named LICENSE.txt or a similar naming convention.

Over the years, there has been some disagreement about what specific freedoms should be guaranteed by an open-source software license. This has led to the emergence of many different open-source licenses, but most of these can fall into one of two categories: permissive and copyleft licenses.

Permissive and Copyleft Open-Source Software Licenses

A permissive license, sometimes referred to as a non-copyleft license, grants users permission to use, modify, and share the source code, but users also have the option to change some of those terms and conditions for redistribution, including derivative work. In the context of software, a derivative work is a piece of software that is based on an existing program. If the original was released under a permissive license, a creator can choose to share their derivative work with different terms than what the original work’s license might have required.

A copyleft license, also grants users permission to use, modify, and share the source code, but offers protection against relicensing through specific restrictions and terms and conditions. This means that software users creating derivative work are required to release under the same copyleft license terms and conditions of the original work. This reciprocity is a defining aspect of copyleft licenses, and is intended to protect creators’ intentions by ensuring that users will have the same rights and permissions when using works derived from the original software.

In addition, there are public-domain-equivalent licenses that grant users permission to use copyrighted works without attribution or required licensing compatibility. For a creator, this means that any rights over their work are completely forfeited. Although there is some overlap in the philosophies behind public-domain and free and open-source software licenses, there has been disagreement over the years about whether a public-domain-equivalent license truly qualifies as open source. In 2012, the CC0 license was submitted but ultimately denied approval by the Open Source Initiative (OSI), a nonprofit organization that defines standards for open-source software and maintains a list of approved open source licenses. However, the OSI did approve a public-domain-equivalent license called the Unlicense in 2020.

Why Include an Open-Source Software License?

As a developer starting a project from scratch, it’s important to have some familiarity with the open-source software licenses available to assess how you’d like others to use your work. Recognizing these licenses is also important to users so they can understand the permissions or restrictions set by the agreement they’ve made when using the creator’s work.

Again, any original work will have copyright upon completion, but without a license, it’s unclear what is and isn’t allowed for those who want to use it. Consider the following reasons why you might include an open-source software license:

Improvement: The open-source community prides itself on cultivating a culture that encourages collaboration and innovation. Using an open-source software license invites users to engage in community development. This creates a shared sense of responsibility to consistently improve the source code or expand the program further to everyone’s benefit.
Ownership: If you want to exercise more power over your work, choosing a license that can place those restrictions will help you do so. For instance, if you want any derivative works to grant the same permissions as the one you originally chose, you may want to opt for a copyleft license. Fortunately, an open-source software license provides transparency to future users on how much control you have over the work, whether it’s a lot or a little, is up to you.
Competition: There’s a plethora of software out there and if you want to break into that market, using an open-source license can help put you on the map. Some popular examples of open-source software that were developed to compete with established proprietary alternatives include the Linux operating system, Android by Google, and the Firefox browser.

Keep in mind that it is possible to monetize an open-source software project, but the typical business practice for monetizing software is to use a proprietary license to protect the software from being shared or stolen.

These reasons for using an open-source software license may not all be applicable to you, and we encourage you to do your own research on the subject before choosing a license for your next project. Additionally, you may want to seek the assistance of a legal professional to confirm a full understanding of what a license would signify for your work in the present and future.

As mentioned earlier, this article focuses on the open-source software licenses listed when creating a new repository for your project on GitHub. You’ll notice at the end of the page there is an option for choosing a license. Once you click the box, a drop-down list of licenses will appear for you to select from, like in the following:

In the next sections, we will provide brief descriptions of the types of open-source software licenses you can choose from for your next project, starting with the permissive licenses recommended by GitHub.

Permissive Open-Source Software Licenses

Permissive licenses grant software users permission to use, modify, and share the source code. Additionally, creators of software derived from permissively licensed software can change the licensing conditions for redistribution.

Please note, the following list is not representative of all the permissive open-source software licenses available. Rather, this list is taken from the license options offered by GitHub when starting a new project. Also, these brief descriptions are not comprehensive. We recommend carefully reading through the documentation for any license you’re interested in using or speaking with a legal professional for more information.

Apache License

The Apache License is written by the Apache Software Foundation (ASF). With this license, users do not have to share their modified version of the source code under the same license and can choose to use a different one, this is known as sublicensing.

MIT License

The MIT License is from the Massachusetts Institute of Technology (MIT) and is one of the shortest to read with few restrictions. Similar to the Apache license, it also gives users the option to sublicense the software.

BSD Licenses

GitHub lets you choose between two BSD licenses, the BSD 2-Clause “Simplified” License, sometimes referred to as the “FreeBSD” license; and the BSD 3-Clause “New” or “Revised” License. The main difference between these two licenses is with the 3-clause. This clause restricts software users from using the name of the author, authors, or contributors, to endorse products or services.

Boost Software License

The Boost Software License, is from the Boost Libraries of C++ and was approved by the OSI in 2008. This license is similar to the MIT and BSD licenses, except it does not require attribution when redistributing in binary form.

Copyleft Open-Source Software Licenses

Copyleft licenses grant software users permission to use, modify, and share the source code, but also protect against relicensing through specific restrictions and terms and conditions. This represents the reciprocal characteristic of this license that requires users’ work to adhere to the original rights outlined in the license.

Again, the following list is not representative of all the copyleft open-source software licenses available. Rather, this list is taken from the license options offered by GitHub when starting a new project. Also, these brief descriptions are not comprehensive. We recommend carefully reading through the documentation for any license you’re interested in using or speaking with a legal professional for more information.

GNU Licenses

There have been a number of versions of the GNU General Public License (GPL) that have been released by the Free Software Foundation, four of which users can choose from on GitHub. The GPL v3.0 requires users to state any modifications to the original code and make that original code available when distributing any binaries used on their work under that licensed software. This license also made it easier to work with other licenses such as Apache, which the previous version (v2.0), did not have compatibility with.

Before the current GPL v3.0 version, a second version was created, the GNU Public License v2.0. This license shares similar terms and conditions as v3.0, but is considered a strong copyleft license. A strong copyleft license requires that any modifications to the source code get released using the same license. The primary difference with v2.0 is that software users are allowed to distribute work if they adhere to the requirements of the license, regardless of prior legal obligations. The goal of this clause is to prevent an individual or party from submitting a patent infringement claim that would limit a user’s freedom under this license.

There is also the GNU Lesser General Public License , referred to as LGPL, and also v2.1 of the GPL v2.0. This license is meant to serve as a middle-ground between strong and weak copyleft licenses. The main difference with this license is that software users can combine a software component of the LGPL with their own and are not required to share the source code of their own components. Users can also distribute a hybrid library, which is a combination of functions in the LGPL library and functions from a non-LGPL, but there must be a copy of that non-LGPL library and information on where it’s located.

Another GNU license is the GNU Affero General Public License v3.0, referred to as AGPL. The main difference with this license is that it is specific to software programs used on a server. This license requires users who run a modified program on a server to share this information and make the modified source code available for download to the relevant modified version that is currently running on the server.

Eclipse Public License

The Eclipse Public License, is from the Eclipse Foundation and is considered a weak copyleft license. A weak copyleft license requires software users to share any changes they make to the code. This license chose to implement a weaker copyleft as a way to reduce the stricter requirements users encountered with GNU’s General Public Licenses.

Mozilla Public License

The Mozilla Public License, or MPL, is from the Mozilla Foundation and is also considered a weak copyleft license. The difference with this license (in comparison with the Eclipse Public License) is that it is file-based copyleft, which means code can be combined with open-source or proprietary code.

Public-Domain-Equivalent Licenses

Public-domain-equivalent licenses grant users permission to use copyrighted works without attribution or required licensing compatibility. As you may recall, these licenses are not always OSI-approved.

Creative Commons Zero Universal License

The Creative Commons Zero Universal License, was written by Creative Commons and is considered a public copyright license. This means copyrighted work can be freely distributed. Please be aware that this license is not OSI-approved. The main point about this license is that users can use, distribute, and modify the source code, but must agree to waive any copyrights to ensure this work is accessible in the public domain. Additionally, users do not have to provide any attribution to the work and can use it commercially.

The Unlicense

The Unlicense was released in 2012 and is considered a public-domain-equivalent license that is OSI-approved. With this license, software users can use, modify, distribute source code, and compiled binary for both commercial and non-commercial purposes. This license also advises users who want to ensure contributions to the code or software are available to the public domain by including a statement about their commitment to sharing the code base with the public.

Conclusion

There are many factors to consider when choosing an open-source software license. Yet, there are certainly popular choices among the developer community. Common permissive licenses include the MIT License, Apache License, and BSD License. Some common copyleft licenses include the GNU General Public License and the Mozilla Public License.

Remember, this article only provided information about a few common open-source software licenses, specifically the ones suggested by GitHub. We encourage you to explore all of your available licensing options or consult the help of a legal professional to make an informed decision about what best fits the needs of your project.

Source link

How To Install Umami Web Analytics Software on Ubuntu 20.04

Introduction

Umami is an open-source, self-hosted web analytics application written in Node.js. It focuses on being simple, well-designed, fast, and privacy-focused. It can store data about your website’s visitors in either a MySQL or PostgreSQL database.

In this tutorial you will install Umami and a PostgreSQL database using Docker Compose, then install Nginx to act as a reverse proxy for Umami. Finally, you will enable secure HTTPS connections by using Certbot to download and configure SSL certificates from the Let’s Encrypt Certificate Authority.

Prerequisites

In order to complete this tutorial, you’ll first need the following:

Note: These prerequisite steps can be skipped if you’re using DigitalOcean’s 1-Click Docker Image. This image will have Docker, Docker Compose, and UFW already installed and configured.

Launch a new Docker image in the region of your choice, then log in as the root user and proceed with the tutorial. Optionally, you could leave off the sudo parts of all commands, but it’s not necessary.

Finally, to enable SSL you’ll need a domain name pointed at your server’s public IP address. This should be something like example.com or umami.example.com, for instance. If you’re using DigitalOcean, please see our DNS Quickstart for information on creating domain resources in our control panel.

When you’ve satisfied all the prerequisites, proceed to Step 1, where you’ll download and launch the Umami software.

Step 1 — Installing Umami and PostgreSQL with Docker Compose

Your first step will be to clone the Umami Git repository, update the docker-compose.yml configuration file, and then start the Umami and PostgreSQL containers.

You’ll download the repo into the /opt directory. Use the cd command to go there now:

Then use the git command to clone the repo from GitHub:

sudo git clone https://github.com/mikecao/umami.git

This will pull all the software and configuration files into /opt/umami. Move into the newly created umami directory now:

Now you need to update the project’s docker-compose.yml file. This file is what the docker-compose command uses to configure and launch multiple Docker containers at once. We need to change two options in this file: the IP that Umami binds to, and a random hash used as a salt when encrypting things in the database.

Before you open docker-compose.yml to edit it, let’s generate a new random hash to paste into the file:

OutputtCgKyCWc/3C9VH+Ex0TysXsGEKQklQXm0H3nSnlR48g=

This uses the openssl command to generate 32 random characters. Copy the output to your clipboard, then open the configuration file:

sudo nano docker-compose.yml

Find the HASH_SALT option, delete the placeholder text, and paste in the random hash you just generated:

docker-compose.yml

. . .
      HASH_SALT: replace-me-with-a-random-string
. . .

Next, find the ports: portion of the configuration:

docker-compose.yml

. . .
    ports:
      - "127.0.0.1:3000:3000"
. . .

Update the "3000:3000" value by prepending 127.0.0.1: to it. This ensures that Umami is only listening on the localhost interface, and is not publicly available. Even though you have a UFW firewall set up, due to some quirks in how Docker networking works, if you didn’t take this step your Umami container would be accessible to the public on port 3000.

With those configuration changes complete, save the file (CTRL+O then ENTER in nano) and close out of your editor (CTRL+X).

Now, use docker-compose to start up your two containers:

sudo docker-compose up --detach

The --detach flag tells docker-compose to create the containers in the background, detached from our terminal session:

Output. . .
Creating umami_db_1 ... done
Creating umami_umami_1 ... done

Umami and PostgreSQL are now running. You can verify this by using the curl command to fetch the homepage of your new Umami container running on localhost:

Output<!DOCTYPE html><html><head><meta charSet="utf-8"/> . . .

If a large chunk of HTML is output to your terminal, you know the Umami server is up and running.

Next, we’ll set up Nginx to reverse proxy Umami from localhost:3000 to the public.

`Step 2 — Installing and Configuring Nginx`

Putting a web server such as Nginx in front of your Node.js server can improve performance by offloading caching, compression, and static file serving to a more efficient process. We’re going to install Nginx and configure it to proxy requests to Umami, meaning it will take care of handing requests from your users to Umami and back again.

First, refresh your package list, then install Nginx using apt:

sudo apt update
sudo apt install nginx

Allow public traffic to ports 80 and 443 (HTTP and HTTPS) using the “Nginx Full” UFW application profile:

sudo ufw allow "Nginx Full"

OutputRule added
Rule added (v6)

Next, open up a new Nginx configuration file in the /etc/nginx/sites-available directory. We’ll call ours umami.conf but you could use a different name:

sudo nano /etc/nginx/sites-available/umami.conf

Paste the following into the new configuration file, being sure to replace your_domain_here with the domain that you’ve configured to point to your Umami server. This will be something like umami.example.com, for instance:

/etc/nginx/sites-available/umami.conf

server {
    listen       80;
    listen       [::]:80;
    server_name  your_domain_here;

    access_log  /var/log/nginx/umami.access.log;
    error_log   /var/log/nginx/umami.error.log;

    location / {
      proxy_pass http://localhost:3000;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

This configuration is HTTP-only for now, as we’ll let Certbot take care of configuring SSL in the next step. The rest of the config sets up logging locations and then passes all traffic along to http://localhost:3000, the Umami instance we started up in the previous step.

Save and close the file, then enable the configuration by linking it into /etc/nginx/sites-enabled/:

sudo ln -s /etc/nginx/sites-available/umami.conf /etc/nginx/sites-enabled/

Use nginx -t to verify that the configuration file syntax is correct:

Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

And finally, reload the nginx service to pick up the new configuration:

sudo systemctl reload nginx

Your Umami site should now be available on plain HTTP. Load http://your_domain_here and it will look like this:

Now that you have your site up and running over HTTP, it’s time to secure the connection with Certbot and Let’s Encrypt certificates.

`Step 3 — Installing Certbot and Setting Up SSL Certificates`

Thanks to Certbot and the Let’s Encrypt free certificate authority, adding SSL encryption to our Umami app will take only two commands.

First, install Certbot and its Nginx plugin:

sudo apt install certbot python3-certbot-nginx

Next, run certbot in --nginx mode, and specify the same domain you used in the Nginx server_name config:

sudo certbot --nginx -d your_domain_here

You’ll be prompted to agree to the Let’s Encrypt terms of service, and to enter an email address.

Afterwards, you’ll be asked if you want to redirect all HTTP traffic to HTTPS. It’s up to you, but this is generally recommended and safe to do.

After that, Let’s Encrypt will confirm your request and Certbot will download your certificate:

OutputCongratulations! You have successfully enabled https://umami.example.com

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=umami.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/umami.example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/umami.example.com/privkey.pem
   Your cert will expire on 2021-12-06. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Certbot will automatically reload Nginx to pick up the new configuration and certificates. Reload your site and it should switch you over to HTTPS automatically if you chose the redirect option.

Your site is now secure and it’s safe to log in with the default user admin and password umami. Please do this immediately, and follow the official first login documentation to get logged in and change your admin password to something more secure.

When you first log in, you’ll see a somewhat bare dashboard:

You have successfully installed and secured your Umami analytics software. In the conclusion of this tutorial you’ll find links to documentation that will get you started with adding your site to Umami, and adding Umami tracking snippet to your site.

`Conclusion`

In this tutorial, you launched the Umami app and a PostgreSQL database using Docker Compose, then set up an Nginx reverse proxy and secured it using Let’s Encrypt SSL certificates.

Also, you should have logged in and updated the default password already. If not, do that now.

Afterwards, continue with the official documentation to learn how to add a website to Umami, then start collecting data by installing the tracking code on your website.

Source link

1
2
3
4
…
6
Next Page »

Shared

Cloud VPS

Dedicated

Software

Turning Infrastructure Into Software Through Cloud Engineering

Video

About the Talk

What You’ll Learn

This Talk Is Designed For

Resources

About The Presenter

Understanding Open-Source Software Licenses

Introduction

Defining Copyright and Licensing

Proprietary Software, Free Software, and Open-Source Software

Permissive and Copyleft Open-Source Software Licenses

Why Include an Open-Source Software License?

Permissive Open-Source Software Licenses

Apache License

MIT License

BSD Licenses

Boost Software License

Copyleft Open-Source Software Licenses

GNU Licenses

Eclipse Public License

Mozilla Public License

Public-Domain-Equivalent Licenses

Creative Commons Zero Universal License

The Unlicense

Conclusion

How To Install Umami Web Analytics Software on Ubuntu 20.04

Introduction

Prerequisites

Step 1 — Installing Umami and PostgreSQL with Docker Compose

Step 2 — Installing and Configuring Nginx

Step 3 — Installing Certbot and Setting Up SSL Certificates

Conclusion

`Step 2 — Installing and Configuring Nginx`

`Step 3 — Installing Certbot and Setting Up SSL Certificates`

`Conclusion`