One place for hosting & domains

      OpenSource

      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.

      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:

      List of open-source software licenses on GitHub

      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

      Hacktoberfest Contributor’s Guide: How To Find and Contribute to Open-Source Projects


      Introduction

      Contributing to open source software is not only a way to share your skill in a particular language or tech stack, it can be a rewarding practice to share your engineering knowledge and collaborate with the developer community. Although there’s a wide range of open source projects out there waiting for your expertise, knowing where to find them and how to contribute in a way that is meaningful to the project can sometimes prove to be a barrier for interested contributors.

      In this Hacktoberfest-flavored guide, we’ll share some tips and information that will aid in finding and contributing meaningfully to open source projects.

      Find a Project

      If you are new to engaging with the open source community, finding a new project to contribute to may feel daunting. Here’s a few resources and ideas to help you find a project you’d love to help thrive.

      What is Open Source?

      Open source software is software that’s freely available to use and modify, typically shared via a public repository hosting service like Github. Projects that follow the open source model usually thrive through contributions from the developer community, and may allow for redistribution depending on which open source license they have adopted.

      Most successful open source projects have transparent, well-delineated processes for maintenance and improvement, which helps to build a community around them. As a result, they benefit from regular contributions from end-users, who bring with them diverse perspectives to solutions that may otherwise be overlooked.

      To learn more in detail about open source, visit our tutorial series, An Introduction to Open Source.

      Consider Familiar Open Source Software

      After deciding to commit your time and talent to an open source project, it’s important to take a moment to consider your passions and the type of project that resonates with you. Considering that you may spend a number of hours contributing to a specific project, you want to select a project that is not only something you’d personally use, but have a deeper interest in beyond contributing for Hacktoberfest. Think about the software you use today and consider the following:

      • In what tech stack and language is the software written?
      • What are some things that could be improved when using the software?
      • Are there any bugs or visible errors that you have the technical proficiency to address?
      • Would you be willing to contribute to this software on an ongoing basis?

      These beginning considerations may lead you to discover that your favorite software is open source and waiting for your contribution. If that’s the case, be sure to dive into the CONTRIBUTING.MD file that typically delineates how to contribute before starting. This resource will usually introduce you to the codebase, conventions, and ways to gain support when contributing to the software.

      Beginner-Friendly Open Source Projects to Try

      If you’re just starting out, the idea of committing large amounts of code to an unfamiliar codebase could bring out the imposter syndrome that lies dormant in many of us. Luckily, each developer was a beginner once, and to foster appreciation and adoption of open source, there’s a wealth of publicly-available repositories shared by fellow developers that are beginner-friendly. Here’s a few that we suggest to browse:

      • Awesome For Beginners- A list of projects by programming language that are noted to be beginner-friendly.
      • Awesome for Non-Programmers- if you’re new to programming, here’s a list of projects that are language-agnostic and help foster learning.
      • Up For Grabs- A resource that lists projects with tasks curated for new contributors.
      • First Timers Only- A resource for beginning contributors that includes links to open source learning resources and links to beginner-friendly projects.
      • Habitica- A habit-forming app that gamifies life. This open source project has detailed documentation and many ways for programmers and non-programmers alike to contribute to the project.

      More resources for open source projects to try can be found on our Hacktoberfest Resources Page.

      Make a Contribution

      Identifying Meaningful Solutions for Open Source Projects

      After identifying an open source project to contribute to and diving into the resource material that the codebase offers, you may be wondering exactly what to contribute. While the way in which you contribute may vary by project, here’s some general ideas of contributions that are impactful and meaningful to the codebase and software you’re working on.

      Fix a Bug

      Bugs are small errors in code that may cause an annoyance, a blocker, or be debilitating to software. Bugs often produce unexpected results that cause incorrect responses or actions — for the sake of a software user’s experience, it’s imperative and important that a codebase is maintained to be bug-free (or as bug-free as possible).

      You can contribute your knowledge and expertise to ‘squash’ or solve the issue surrounding a bug. By working on bugs of varying priorities, your ability to strengthen a codebase by solving errors will grow, and you’ll have a meaningful contribution to add.

      Propose a Feature

      Open source projects benefit from a diversity of thought. Although software may have been developed by one or more engineers with an opinion of how their product can solve an existing problem, your personal experience and outlook on how to improve a project can be invaluable. Once you’re comfortable with a project’s codebase and understand how it works for end users, try to think of a new feature that could be useful or improve the user’s experience and create an issue to propose it to the project maintainers. It is important to have this conversation before investing time in writing code, since sometimes your idea might not coincide with the project’s roadmap. With a positive response, it’s time to implement your idea and bring that feature to production.

      Write Some Documentation

      While there may be a wealth of technical contributions that can be made to a codebase, writing good documentation is a contribution that is often overlooked. If you’re linguistically-inclined or speak a language other than the one reflected in the initial documentation, consider making a contribution. Contributions in documentation can revolve around providing editing help to an existing doc or authoring new pages within the documentation. Refer to your project’s contribution guidelines to learn more about how to contribute this and other non-technical help.

      Submit Your PR

      Submitting Your Pull Request via Github

      After you’ve made a meaningful contribution to an open source project’s codebase, it’s time to submit your pull request. We’ve created a helpful video that walks you through this process via Github, that can be found here.

      Video: How to Submit Your First PR

      Sharing your expertise with an open source project is a rewarding experience that allows you to practice your talent, collaborate with and learn from others, and give back to the developer community. While it may initially seem daunting to find your place within the open source community, finding a project that speaks to your passions and contributing meaningfully to its codebase is a great way to start.

      For Hacktoberfest, while making four (4) meaningful contributions to open source projects will qualify you for prizes, we hope that you’ll continue to enjoy the benefits of contributing to the open source community well beyond the event. For more information or to learn more about open source, Git, or Github, you can visit the Hacktoberfest resources page. Happy hacking!



      Source link

      How To Probe the Depths of Nautically-Themed Open-Source Projects Using Moby Dick


      Introduction

      Despite being a commercial failure after its first publication, Herman Melville’s allegorical adventure novel Moby-Dick; or, The Whale is today one of the most popular and influential novels in the American canon. Artists as diverse as William Faulkner, Ralph Ellison, and Bob Dylan have acknowledged the novel’s impact on their work, and one can spot references to it in films, television, music, and, of course, open-source projects.

      In this article, we will analyze several nautically-themed open-source projects and how they pay tribute to Moby-Dick.

      Warning: While it isn’t necessary that you read Moby-Dick prior to reading this article, this article does contain a few spoilers. If you haven’t read the novel but would like to, you may want to hold off from reading this article until you’ve finished it.

      Prerequisites

      To follow along with this tutorial, you’ll need:

      • Familiarity with 19th-century literature.
      • An appreciation for nautical puns.
      • An adventurous disposition. For example, whenever you find yourself growing grim about the mouth, you account it high time to get to sea as soon as you can.

      Docker

      Docker logo

      Docker is an open-source program that performs operating system-level virtualization, also known as containerization. The influence of Moby-Dick is obvious with this project: Docker’s logo and mascot is a whale affectionately known as Moby Dock. However, there are some substantial differences between Moby Dick and Moby Dock.

      First, Moby Dock’s species isn’t immediately obvious. It’s clear from the beginning of the novel that Moby Dick is a sperm whale, and while it’s possible that Moby Dock is a sperm whale as well, there are several clues that suggest otherwise:

      • The head: Sperm whales have distinctively large, block-shaped heads. Moby Dock, however, has a flat forehead with a snout that slopes smoothly downward to its jaw, which is more suggestive of a right whale or bowhead whale.
      • The blowhole: Moby Dock is always seen from its left side. As any whaler worth their salt knows, a sperm whale’s blowhole always skews slightly to the left side of its head. No blowhole is visible in any known images of Moby Dock, another clue that it isn’t a sperm whale.
      • The fins: Moby Dock doesn’t seem to have any pectoral fins. All sperm whales are born with pectoral fins, adding another strike to the “Moby Dock is a sperm whale” theory. That said, all whales have pectoral fins, so this begs the question of whether or not Moby Dock is a whale at all.

      Another important difference between these Mobys is that Moby Dock is helpfully carrying a few stacks of containers; Moby Dick would never be so accommodating. In fact, one can easily imagine Moby Dick going out of his way to knock over such a neatly organized pile of shipping containers. Perhaps Moby Dock is meant to be seen as a warmer, friendlier cousin of Moby Dick. After all, it’s probably bad marketing to associate one’s product with a ferocious leviathan bent on destroying everything in its path.

      OpenFaaS

      OpenFaaS logo

      OpenFaaS is an open-source project that aims to make serverless functions simple through the use of Docker containers, allowing users to run complex infrastructures with far greater flexibility and without the fear of vendor lock-in.

      The OpenFaaS logo focuses entirely on a whale’s tail, which is significant because Melville dedicates an entire chapter to describing the tails of sperm whales. In it, Ishmael reveals his deep appreciation of whales’ tails:

      Such is the subtle elasticity of [the tail], that whether wielded in sport, or in earnest, or in anger, whatever be the mood it be in, its flexions are invariably marked by exceeding grace. Therein no fairy’s arm can transcend it.

      The OpenFaaS whale is shown to be peaking its flukes, presumably as it is about to dive. In the same chapter, Ishmael opines that “excepting the sublime breach…this peaking of the whale’s flukes is perhaps the grandest sight to be seen in all animated nature.” Perhaps the OpenFaaS team chose a whale’s tail as their logo to convey the grace and power that OpenFaaS brings to managing functions. It could even be that the whale is “diving in” to the realm of functions as a service.

      Because OpenFaaS is closely related to Docker, it’s obvious why the project’s logo also features a whale. However, are these supposed to be the same whale? Let us not forget that Moby Dick was believed to be “ubiquitous”, with sailors swearing up and down that they had encountered him “in opposite latitudes at one and the same instant of time.” This may be a clue that Moby Dock and the OpenFaaS whale are indeed one and the same.

      Perhaps in choosing this logo the OpenFaaS team was trying to signal their hope that the framework would become ubiquitous in future software projects. Interestingly, while an omnipresent whale may strike fear in the hearts of whalers, software is generally seen as safer and more secure if it’s widely used. The OpenFaaS team should be thankful that coders are generally less superstitious than whalers.

      Kubernetes

      Kubernetes logo

      Kubernetes is an open-source container orchestration system that helps to automate the deployment, scaling, and management of applications. The name “Kubernetes” comes from the Greek word “κυβερνήτης,” which translates to English as “captain” or “helmsman.” Appropriately, its logo consists of a ship’s wheel, or helm, conveying the control and steadiness required to manage complex container orchestration with ease.

      Curiously, the Pequod doesn’t have a wheel; instead, it has a tiller made out of a whale’s jawbone. This is seen by some readers as underscoring the shared histories of Captain Ahab and the ship, as Ahab lost his leg to the great white whale and replaced it with a whalebone prosthesis.

      Though a helm or tiller can convey steadiness and control, as the Kubernetes logo designers intended, Moby-Dick shows us the deeper questions that the project maintainers might have brushed aside. Who is at the helm when it comes to Kubernetes? Even more, who is at the helm in our everyday lives? Do we drive software, or does software drive us? Of all these things the helm is the symbol.

      MySQL

      MySQL logo

      MySQL is the world’s most widely deployed open-source database management system (DBMS). MySQL’s logo features the outline of a dolphin, affectionately known as Sakila.

      While dolphins aren’t prominently featured in the plot of Moby-Dick, Melville discusses them at length in one of the books famous pseudoscientific asides. In Chapter 32, “Cetology,” Ishmael refers to dolphins as “Huzza Porpoises,” so called because sailors see them as an omen of good luck:

      Their appearance is generally hailed with delight by the mariner…. If you yourself can withstand three cheers at beholding these vivacious fish, then heaven help ye; the spirit of godly gamesomeness is not in ye.

      Mayhaps the MySQL developers chose a dolphin to represent their DBMS to impart this same sense of hopeful joy to those who use it. By associating the database with a dolphin, they hope users will see it as being similarly fast, agile, and fun-loving. After all, who doesn’t have fun running correlated subqueries?

      MariaDB

      MariaDB logo

      MariaDB is a community-supported fork of MySQL, as indicated by its similarly nautical logo. Both the MariaDB and MySQL logos include the respective RDBMS’s name and feature an aquatic animal: in MariaDB’s case, this animal is a pinniped.

      Interestingly, there’s some confusion about what kind of animal is depicted in the MariaDB logo. According to the project’s trademarks page, the animal in the logo is a sea lion. However, some members of the MariaDB community see it as a seal. MariaDB’s official sources are fairly consistent in referring to their mascot as a sea lion, though not always. Certainly, the mascot’s shape does seem to more closely resemble that of a sea lion, but it’s also missing the telltale ears which would distinguish it as such.

      The idea that human perception is inherently biased and unreliable runs as a theme throughout the novel. Perhaps by keeping the pinniped’s species vague, the MariaDB team is making a Melvillian comment on how truth isn’t always obvious and, in some cases, can never be known for certain. Is it a seal or a sea lion? Is Moby Dick real or imagined? Is Vim or Emacs the superior text editor? Riddles like these abound throughout the world we live in, which, like a magician’s glass, to each and every man in turn but mirrors back his own mysterious self. Great pains, small gains for those who ask the world to solve them.

      Of course, it’s also possible that the logo is simply meant to represent a sea lion. Perhaps when the MariaDB team asked the designer to draw ears, they responded “I would prefer not to.”

      Conclusion

      Clearly, Melville’s influence extends far beyond the realm of literature, and well into the world of open-source technology. As this article has highlighted, these five projects (and likely many more) pay homage to his great whaling tale through subtle references in their names and logos, as well as how they challenge our perceptions of truth and human nature.

      We hope that by reading this article, you’ll go on to create your own Melville-inspired, nautically-themed, open-source project. Here are a few ideas to help you get started:

      • Ishmael: an application that turns any server process into an orphan process.
      • Starbuck: An uptime monitor that swears it will keep everything under control, but in the end just gives up and lets the system crash.
      • Stubb: A program that purports to do lots of important work, but really just takes credit for work done by other applications.

      Note: Some readers may be wondering why this article hasn’t yet mentioned DigitalOcean’s own Sammy the Shark. The simple reason is that Sammy has little in common with the sharks depicted in Moby-Dick. Throughout the novel, sharks are depicted as ravenous beasts dominated by instinct. Melville’s sharks eat anything and everything in their path, and are violent, dangerous creatures who pose a serious risk to the crew of the Pequod (though not as great a risk as whales, apparently).

      Clearly, Melville never encountered a shark like Sammy. After all, Sammy is a vegetarian, and a very friendly one at that!





      Source link