A security audit is the process of identifying security threats that can lead to unauthorised access to content, data leaks, bypassing the security, and other dangers. In the first part of the series on conducting a security audit, we’ll focus on the overview of the Drupal module versions that we use at Droptica for this purpose, as well as on PHP and JavaScript libraries.
Drupal security audit
At Droptica, we make every effort to ensure that the solutions we provide are as safe as possible. We use the tools provided by the Drupal community, such as the Security Review module, to optimize the process of detecting the most popular security errors. We also use the Security Kit to make the project we’re working on more resistant to attacks. You can learn more about the functionality of these modules in the linked posts, and the information on their operation will be useful in the following parts, in which we’ll talk about the Drupal configuration review and code analysis.
Checking the versions of the installed Drupal modules
Updating modules and libraries is the simplest activity that we can perform to improve the security of our application. Drupal provides a view listing all the modules, which additionally indicates whether a given module is up-to-date, and if it isn’t – whether the update contains security fixes.
To check if the modules are up-to-date, go to /admin/modules/update
In the screenshot above, you can see that some of the modules need updating. Of course, in such cases we always recommend that you update all possible modules. If any of the modules contain a security fix, the update is required to ensure a high level of security for the application.
In the case of Drupal, the information about whether a given module has a security flaw is made available to the public when the author of the module releases its patched version. Module authors usually try to hide which code has been changed to patch a security flaw, but this always means that the attacker just needs more time to find a way to cause the bug and exploit it. Time is important, so you should keep track of security updates regularly, not only during a Drupal security audit. As we mentioned earlier, this is one of the simplest steps we can take to ensure a higher level of security for our application.
Patches review
When updating the Drupal modules, you should also check if a patch has been applied to a given module. If so, we proceed as follows:
We check whether the patch was created by the community and if it concerns a specific issue on drupal.org. If so, we look for the issue that the patch is from. It’s possible that the patch has been applied to one of the newer versions of the module. In such a case, we recommend updating the module and removing the patch with the information that the code that fixes the bug or adds a given functionality has been applied to the official, newer version of the module. If the patch hasn’t yet been applied to the newer version of the module, we still recommend updating and testing if the latest version of the patch serves its purpose.
If the patch wasn’t created by the Drupal community, but is the result of working on the project, we still recommend updating the module. In this case, however, ensuring the correct operation of the patch lies with the people responsible for the custom code of the project. After updating, you should check whether the patch works as intended. If not, we recommend introducing appropriate fixes to the patch which will ensure its correct operation on the latest version of the module.
PHP libraries review
The next step will be reviewing the used PHP libraries. To list them, we can use the composer show command or the local-php-security-checker package. We recommend the latter solution because it significantly speeds up the process.
Result of the composer show command.
If you choose to install the local-php-security-checker package, follow the guidelines in the README.md file.
Result of the scan using local-php-security-checker.
There’s also the little-known Drupal Composer Security Checker module that uses the security-checker package. Currently, this module doesn’t fulfill its task and the security-checker package itself isn’t actively developed (since January 2021), therefore we’ll focus on the local-php-security-checker package itself. If you find a security risk, our recommendation will be to update the library, of course – as in any case. An audit of the PHP libraries should be carried out regularly, the same as in the case of the Drupal modules.
JavaScript libraries review
The next step will be to check if the used JavaScript libraries are up-to-date and if they contain security fixes. To do this, you should review the library directory and the used package.json files.
In the case of the library directory, you need to check the version manually. In the case of package.json, we use the npm-audit command.
Result of the npm-audit command
The npm-audit command will list all known vulnerabilities, determine the threat level, package, dependencies, package path, and show a link with information about the vulnerability.
If you find a vulnerability, as always we recommend the update. JS library scans should be performed routinely, more often than a comprehensive security audit.
Improving the Drupal security – further steps
In this part of the Drupal security audit cycle, we’ve learned how to check whether the used versions of the modules and libraries are up-to-date and don’t contain known security bugs. We also understand how to proceed if there is a patch available for a module – both when the patch comes from the Drupal community and when it was prepared by the developer working on the application.
Acquiring the knowledge provided in this post is the easiest way to improve the security of your application. Checking the versions of the used solutions is the first step that we perform during a security audit – our Drupal support team recommends periodic checking for updates. In the event that an update containing security fixes is released, we recommend that you perform an update as soon as possible.
In the next part of this series of articles, we’ll get to learn more about the Drupal configuration aimed at increasing the security of our application. We’ll also learn how to reduce the number of attack vectors and we’ll find out more about the modules that’ll help us with this.
Drupal’s popularity has lately been rising. It’s a great platform for setting up content management systems and community driven sites. Here, I’ll give a general overview of Drupal and build a simple site for a fake client. We’ll begin with outlining the client’s needs, installing and configuring a few modules, creating user roles and assigning permissions, and finally we’ll add in some content. We won’t go into theming, as it’s a bit out of the scope of this article.
Drupal is a popular open-source content management system written in PHP. Having been created in the early 2000s by a Belgian student, it now powers some of the most prominent websites on the web (WhiteHouse.gov, Weather.com, etc.). It is often regarded as a competitor of CMSs such as WordPress and Joomla.
One of the most important components of the Drupal project is its community of supporters (contributors, developers, evangelists, business owners, etc.). Prominent within this community stands the Drupal Association, responsible for “fostering and supporting the Drupal software project, the community and its growth”.
A giant leap from its predecessor, the 8th major release of the Drupal project has just hit the shelves. It brought about a serious modernisation of its code, practices and mentality. Many regard this shift as a real move away from the traditional notion of a CMS to more of a Content Management Framework (CMF) that provides a great platform for building complex applications.
In this article, I’m going to answer some of the more frequent questions people have about Drupal when starting up for the first time or considering doing so:
Is it right for me? Who is it aimed at?
How can it be installed, and where can I host it?
How can I start working with it as a developer?
What options do I have for extending functionality or styling it?
Who Is Drupal Aimed At?
Since the beginning of the project, Drupal has evolved from being mainly a tool for building smaller sites to one that can now power enterprise-level platforms. Especially with Drupal 8, site builders and developers can easily scale up from small websites to large platforms with many integrations. For example, the adoption of Composer allows you not only to bring external libraries into a Drupal project, but also to use Drupal as part of a bigger project of applications and libraries. It’s safe to say that Drupal is flexible enough to meet the needs of a wide range of projects.
When it comes to development, Drupal has always had a relatively closed community—not because people are unfriendly, quite the contrary, but mainly because of the code typically being written in a Drupal way (resulting in what sometimes is referred to as Drupalisms). This has meant a learning curve for any developer starting up, but also less interest from developers of other PHP projects to jump in and contribute.
This is no longer the case. Especially with the release of Drupal 8, the community now promotes a new mentality of code reusability and best practice across different open-source projects. Active participation in the PHP Framework Interoperability Group is part of this effort, and using a number of popular Symfony components in Drupal 8 core is a testament to this commitment.
With this move, the Drupal community has gotten richer by welcoming many developers from other communities and projects, and it is sure to grow even further. So if you are a Laravel developer, looking at Drupal code will no longer be so daunting.
How Can I Install Drupal, and Where Can I Host It?
Traditionally, Drupal has had a relatively easy installation process, particularly for people who at least knew their way around a Linux environment. The project simply needs to be dropped into a folder your web server can run (which needs to be using PHP and have a MySQL or MariaDB database). Then pointing your browser to the /install.php file and following the steps takes care of the rest. The most important screen you’ll see is the one in which you select a specific database to use.
In terms of requirements, the LAMP stack (Linux, Apache, MySQL and PHP) environment has always been a favourite for Drupal to run in. However, it is in no way restricted to it. Solutions exist for installing it straight on Windows or Mac (e.g. using the Acquia Dev Desktop) but also on a Linux system that runs other web servers.
The easiest approach, if you go with your own setup, is to use a LAMP server for hosting. For a bit more performance you can replace Apache with Nginx, but you’ll then have to take care of some specific configuration that otherwise is handled in the .htaccess file Drupal ships with.
However, if you don’t want the hassle of maintaining your own hosting server, there are three main providers of specialised Drupal managed hosting: Acquia, Pantheon, and Platform.sh. These also provide a workflow for easy updates and development flow. Past that, you are looking at fully managed hosting with a Drupal development company.
How Can I Get Started Developing for It?
Developing Drupal websites has typically been the kind of thing you either liked a lot or didn’t like at all. This is because when you were first introduced to Drupal, you encountered very many specificities that you didn’t see in other projects. So if those tickled your fancy, you loved it forever.
With getting off this island in Drupal 8, this is no longer the case as much. You still have plenty of Drupalisms left that you can love or hate, but you now also have external components like Symfony or Guzzle and, most importantly, a more modern way of writing code in general (OOP, design patterns, reusable components, etc.). So your PHP skills from building websites with Zend will come in handy.
A good way of getting into Drupal development is to follow some online video courses. There are a couple of resources that are excellent for this purpose, most notably Drupalize.me. If, however, video is not your favourite medium, there are also many written tutorials and guides available to get you started. Check out the following links for some of the first steps you can take:
Since Drupal 8 is brand new, you’ll find significantly more learning content for Drupal 7. Nevertheless, the focus in the community has been shifting recently towards Drupal 8, so you can expect more and more of these resources to crop up. And if you have no experience with any version of Drupal, it’s best to focus exclusively on Drupal 8 as the changes between the two are big and perhaps you’d be facing unnecessary challenges.
How Can I Extend Drupal?
The main extension point of a core Drupal installation is its module system.
Modules are used to encapsulate bigger chunks of reusable functionality that can/should work on different sites. Aside from the core modules, there are a large number of contributed ones, available for installation.
Granted, most are still only for Drupal 6 and 7, but the community is catching up also for the newest version. This problem is also mitigated by the incorporation in Drupal 8 of a few popular contributed modules as well as extending the scope of what core can do out of the box (compared to Drupal 7).
Lastly, custom modules (the ones that you write yourself) are the primary way you can add any functionality that you want and that is not available via a contributed module.
Installing modules can allow you to plug in various pieces of functionality, but you should not treat this as a green light for adding too many. It’s always better to stick to the ones you actually need, and don’t be afraid to be critical in this respect. You can also work on finding a good balance between contributed code and the custom one you write yourself.
Additionally, since we are talking about open-source software, you should always evaluate the modules you install. The following indicators are good examples to pay attention to: number of downloads and usage, commit frequency, maintainer engagement, state of the issue queue.
And do keep security in mind as well. It’s highly recommended you keep both Drupal core and any contributed modules up to date as this will significantly help you keep your site and server secure (though it doesn’t ensure it).
What About Styling?
The styling layer of a Drupal site is handled (in large part) by its theme. Themes are similar to modules in that they are an extension point, but they have different responsibilities. They contain the styles, front-end libraries and in most cases template files that are used to output data.
There has been great progress in Drupal 8 compared to the previous version: the popular Twig engine has been adopted for templating, theming has been limited to Twig template files, debugging and overriding templates has been made much easier, etc. Similar to the advances in back-end development experience (DX), the theming layer has been made more appealing to the non-Drupal crowd. Front-end developers can now easily work with Drupal themes without having to understand the ins and outs of the back end.
Drupal core comes with a number of themes that can provide you with examples but also which you can extend from. There are also contributed themes similar to how there are modules. Popular front-end frameworks such as Bootstrap or Zurb Foundation have mature Drupal theme implementations for Drupal 7, which are also readying for Drupal 8. These work very well as base themes but also for quickly scaffolding a website and making it look decent.
Paid themes are also available to try out. Usually they are very cheap and quick to set up. The problem with them is that they are worth exactly as much as you pay for them and usually have gaping holes in their flexibility. As a beginner, these themes can seem like a great way to set up a site, and they very well may be. However, as you progress, you’ll learn to avoid them and build your own, based on external designs or even plain HTML/CSS/JS templates.
Conclusion
Drupal is a powerful tool for building websites and platforms of any kind. With each new major release, Drupal has shown a commitment to better itself, become more robust and flexible, and embrace outside communities as well.
Do you want to learn more about asynchronous Android programming? How about the Ionic framework, or JavaScript design patterns? Our latest batch of eBooks will teach you all you need to know about these topics and more.
Our Latest Selection of eBooks
This month we’ve made eight new eBooks available for Envato Tuts+ subscribers to download. Here’s a summary of those books and what you can learn from them.
Developing a mobile application for just one platform is becoming a thing of the past. Companies expect their apps to be supported on iOS, Android and Windows Phone, while leveraging the best native features on all three platforms. Xamarin’s tools help ease this problem by giving developers a single toolset to target all three platforms. The main goal of this book is to equip you with knowledge to successfully analyze, develop, and manage Xamarin cross-platform projects using the most efficient, robust, and scalable implementation patterns.
Drupal 8 is an open-source content management system and powerful framework that helps deliver great websites to individuals and organizations, including non-profits, commercial, and government around the globe. Starting from the bottom up, in this eBook you will learn to install, set up, and configure Drupal 8. You’ll get a walk-through of a real-world project to create a Twig theme from concept to completion while adopting best practices to implement CSS frameworks and JavaScript libraries. You will see just how quick and easy it is to create beautiful, responsive Drupal 8 websites while avoiding the common mistakes that many front-end developers make.
Asynchronous programming has acquired immense importance in Android programming, especially when we want to make use of the number of independent processing units (cores) available on the most recent Android devices. With this guide in your hands, you’ll be able to bring the power of asynchronous programming to your own projects, and make your Android apps more powerful than ever before!
With Ionic, mobile development has never been so simple, so elegant and obvious. By helping developers to harness AngularJS and HTML5 for mobile development, it’s the perfect framework for anyone obsessed with performance, and anyone that understands just how important a great user experience really is. This book shows you how to get started with Ionic framework immediately. But it doesn’t just give you instructions and then expect you to follow them. Instead it demonstrates what Ionic is capable of through three practical projects you can follow and build yourself.
Sass and Compass Designer’s Cookbook helps you to get most out of CSS3 and harness its benefits to create engaging and receptive applications. This book will help you develop faster and reduce the maintenance time for your web development projects by using Sass and Compass. You will learn how to use with CSS frameworks such as Bootstrap and Foundation and understand how to use other libraries of pre-built mixins. You will also learn setting up a development environment with Gulp.
Android phones available in today’s market have a wide variety of powerful and highly precise sensors. This book will give you the skills required to use sensors in your Android applications. It will walk you through all the fundamentals of sensors and will provide a thorough understanding of the Android Sensor Framework. By the end of the book, you will be well versed in the use of Android sensors and programming to build interactive applications.
The successor of Yii Framework 1.1, Yii2 is a complete rewrite of Yii Framework, one of the most popular PHP 5 frameworks for making modern web applications. This book has been written to enhance your skills and knowledge with Yii Framework 2. Starting with configuration and how to initialize new projects, you’ll learn how to configure, manage, and use every aspect of Yii2 from Gii, DAO, Query Builder, Active Record, and migrations, to asset manager. With this book by your side, you’ll have all the skills you need to quickly create rich modern web and console applications with Yii2.
In this book, you will explore how design patterns can help you improve and organize your JavaScript code. You’ll get to grips with creational, structural and behavioral patterns as you discover how to put them to work in different scenarios. Then, you’ll get a deeper look at patterns used in functional programming, as well as model view patterns and patterns to build web applications. By the end of the book, you’ll be saved of a lot of trial and error and developmental headaches, and you will be on the road to becoming a JavaScript expert.
Start Learning With a Yearly Subscription
Subscribe to Envato Tuts+ for access to our library of hundreds of eBooks. With a Yearly subscription, you can download up to five eBooks per month, while the Yearly Pro subscription gives you unlimited access.
You can also build on your newfound knowledge by using some of the fantastic code scripts and plugins on Envato Market.
Current stats on the high percentage of Drupal websites that are still on version 7, with no apparent migration plan in sight, are sparking concern and curiosity throughout the Drupal sphere. What exactly is standing in the way of decisions to shed this outdated version and start reaping the benefits of better security and a far superior CMS?
Sometimes it can be handy to have extra pages for a node (or any entity). For example:
To show different sets of information on separate pages for a single product, page, or thing.
So you can set different access requirements on each page for a node.
You want to block access to the ordinary route (e.g. node/123 and its aliased equivalent) for some reason, but you still want some other page to represent that node.
I’ve found a few people with that need on Drupal slack before, so I thought I’d write a guide because it’s surprisingly easy!
My imaginary requirement
I’m going to imagine my client has asked me to set up an additional page for products, to show information relevant to someone that has already bought the product. We’ll call it the ‘Product support’ page. This page could be public, but shown as a separate tab for products, or even just hidden as a link only sent out to customers that have ordered the specific product. Access could even be restricted to those people entirely. All the content to show on the page would come from fields on the product. We don’t really want to go creating another separate entity to hold data that’s only relevant to the product in question anyway. This makes sense from a data point of view as all the fields are for one thing, whether for existing or potential customers. (Of course, Field Group could be used to split those things into tabs on the product’s edit form, or a similar technique to this article’s could be used to separate them out into an additional edit page!)
First, set up a view mode for your node/entity
Just like teasers can be configured separately to the full content version of a node, you can create your own view mode. Add it from /admin/structure/display-modes/view on your site, and then enable it from the ‘Custom display settings’ section at the bottom of the ‘Manage display’ tab for your entity type/bundle. Once that’s done, navigate to the sub-tab for your view mode and choose the fields you’ll want to show.
So I’ll make one called ‘Product support’, and configure only fields like ‘Support helpline’, ‘Manuals’ and ‘Returns information’ to show in this view mode. I will probably go hide those fields in the usual (default/full) mode too.
Next, set up the page to use that view mode
HTML page routes for viewing entities are usually set up by the ‘route_provider’ specified in an entity type’s annotation block. For nodes, that’s DrupalnodeEntityNodeRouteProvider, which dynamically sets up the view, edit & delete routes (take a look!). But you can define your route with some simple YAML. In a custom module, add (or use an existing) mymodule.routing.yml file, with the following code. Replace ‘mymodule’ with your module’s machine name, and ‘product_support’ with the machine name of your view mode:
The last line contains the name of a function you might want to use to add any custom access logic. The function could just be in your .module file. In my case, I might look up the current user’s orders to check whether they have bought the product before allowing access. You might want to at least restrict which bundles the route works for, like so:
/**
* Extra access callback for product pages.
*/
function mymodule_product_support_access(DrupalCoreEntityContentEntityInterface $node) {
return DrupalCoreAccessAccessResult::allowedIf($node->bundle() === 'product');
}
But you can just omit that _custom_access: line from the YAML entirely to just use the same access that the ordinary node page has, no problem.
Rebuild the site caches; you’re done!
Now you can access /node/123/product-support to view a different page of content for your product! If you want to set it up as a tab where the usual ‘View’/’Edit’ tabs of a node would be, then use the following YAML in a mymodule.links.task.yml file in your module. Again, replace ‘mymodule’ and ‘product_support’ as appropriate, and then rebuild the site caches to see it work:
All of this can work for any entity type – try just replacing ‘node’ in each of these code snippets with the machine name of the entity type that you want to use.
There’s a module for that
There are modules like View Mode Page which let you set these extra pages up in the UI. But I’ve found my additional pages usually need some additional bespoke logic though, whether for access or something else on the page. So given how little actual code is needed, I tend to just make them this way. But it does have some handy features, like supporting URL aliases for nicer paths.
Entity Form Mode also claims to help you make separate edit pages for form modes, which is very handy. But again, I find these tend to have even more interesting bespoke requirements with custom access logic. But see how you get on. Making these in custom code can be just as easy anyway – just replace the _entity_view: 'node.product_support' part of the routing YAML with _entity_form: 'node.my_form_mode', and the _entity_access part should use ‘node.update’ instead of ‘node.view’.
I’m sure there are some interesting use cases for this – let me know in the comments what you’ve needed custom entity routes for!
Migrating Multilingual Content from CSV to Drupal 8 Suresh Prabhu 13 Jul, 2021
Top 10 best practices for designing a perfect UX for your mobile app
Migrating data from any source to Drupal 8 is now made simple with various modules that allow easy data transfer. Migration in Drupal is a term for any process that moves data from an external source to the current Drupal site. You can migrate data that includes nodes, users, configuration, and any other components of the site.
Drupal provides you many ways to migrate content. Depending on the website and source of the data, you can choose the best way to do it. However, migrating multilingual data can add a few more steps to your migration process. You will first need to migrate the base content and then migrate the translations. In this article, we will elaborate on these steps to help you get a better understanding of migrating multilingual content from CSV to Drupal 8.
Drupal 8 Migration Modules You Will Need
As mentioned earlier, Drupal offers tons of options and modules that can help you with an easy, hassle-free migration. For migrating multilingual content, you will need:
Migrate: Provides a flexible framework for migrating content into Drupal from other sources.
Migrate plus: Provides plugins for migrations like source plugins, process plugins, destination plugins and API extensions.
Migrate Drupal: Provides support for migrating content and configurations.
Migrate source CSV: Provides a plugin to import contents to Drupal from a CSV file.
Migrate tools: This module gives UI tools and Drush commands used for migration.
Configuration development module: This module converts script into configurations.
Make sure that the info.yml has these keys and values.
You will need to create yaml files, which are known as migration scripts, and place it in the config/install directory of the custom module created. The config_devel/install key of info.yml should have all the yaml files written.
This is a sample yaml file for importing taxonomy terms. The migration script has 4 sections:
Metadata: will have the id, label, and migration group id.
Source: The source key should have the path to the CSV file.
Process: The mapping between the fields and the CSV columns.
Destination: The destination where the imported data is saved.
The yaml file node contents should be written similarly. The only difference being the destination.
The destination plugin should be entity:node and the default_bundle will have the machine name of the content type to which the content is imported.
After creating all the yaml files, the IDs of the yaml should be included in the info.yml. Once everything is done, enable the custom module.
Use the Drush command drush cdi . Here the migration id is techx migration. This will convert the script into configurations.
After running the command go to admin>structure>migration. You will find the migration group you created by clicking on list migration. This will show you the list of the migration scripts created.
Clicking on execute tab will show the list of operations available:
Import is to pull the data from the source.
Rollback will delete the data imported.
The Stop is to interrupt the import or rollback process.
Sometimes a process gets stuck. To move the status to idle, Reset is used.
Step 2: Migrating the translations of the base content
If you already have enabled multilingual content on your Drupal 8 website, you can skip the first step. If you want to know how to create multilingual Drupal 8 websites (and why you might need one), check out this article.
1. Adding language to the Drupal website
To import translations, first we must make our website multilingual. Let us see how to download languages to the site.
Enable the Language and Content translation module. These are core modules.
Go to /admin/config/regional and language/language/add language.
Clicking on the dropdown gives you a list of languages. Select the language you want on the site and click on Add language. This will download the language for your site.
2. Enabling translation for entities
Once we have installed the languages we need, we must enable the translations for the entities before importing or adding the translations to the content. For this, go to admin/config/regional/content translation. Select the entities to which you want to enable the translation and click on Save configurations.
In this example, I am importing the blog content type and thus I will enable translation for blog content type.
3. Update the migration files
There are some changes that need be made on the yaml files to import the translations. Give the path of the CSV file of translated content as a base contents and translated contents are stored in different files. Changes in term translation.
Add a new key tid in the process section of the script with the plugin as migration, source as id, and migration value should be the migration id of its base content migration script.
For node migration add a new key nid in the process section. Here the migration key will have the value of the migration id of its base content migration script.
Another key should be added is translations with the value set to true. This should be added in the destination section of all the translation migration scripts irrespective of the entities.
Define the language to which the translation is imported using the langcode key. In this example I am importing Japanese translations, so the value will be ja.
These changes tell the script to take the id of the content from the base content migration from which these contents are treated as translations rather than a new node.
Points to remember
The importing process should go in order. For example, if the terms are referred to in the node, the terms should be imported first before the node contents.
Enable the translation for the entities before importing the translations.
The order of translation contents in the CSV file should be the same as the base content. That is, the base content and its translations should be in the same line in the CSV file.
Import the base content first then the translation content. Else both will be treated as individual contents.
Understanding Open Source Licenses and What Drupal’s Licensed Under Gurpreet Kaur Fri, 07/09/2021 – 17:05
Imagine there is a project that only has one person working on it. All the developments and challenges are going to be performed and overcome by him. Nobody can say that the project would not be successful, it very well can be.
Now compared to the previous project, think of a second one. This has a whole bunch of people working on it. The solutions aren’t coming from a single brain, but from loads of expert brains.
So, if we had to judge the success rates of these two projects, on which would you place your bet on? For many of us the answer would be the second project with a massive team of experts, who’d be able to come up with more solutions and developments than a single person ever can.
And that is open source software for you. It is a platform wherein, one person creates a software, and other developers have an opportunity to read his source code, to use it, to modify it and redistribute it with the modifications. Open source software makes it possible for people to come together and work magic with their intellect and skills.
However, with that kind of liberty in development, there are often times when people after modifying an open source make it a proprietary software. Sometimes an open source developer wouldn’t mind it, but there is also the chance that he’ll feel misused. To overcome these scenarios, a solution was thought and that is what we are going to be discussing today. So, let’s begin.
How Open Source Licensing Came to Be?
You would be surprised to know that the origins of open source licensing can be traced back to a consent decree issued by the United States Government. Yup, you read it right. This was back in the late 60s and early 70s, when the Unix operating system was emerging, being the first general purpose operating system.
The US government barred AT&T, the founders of Unix, from engaging in any commercial activity outside of their primary field of operations, which was telephone services. So, what did AT&T do? It did the next best thing, given the decree.
Making Unix a commercial software was out of the question. So, AT&T gave away its source code to be modified and shared. Of course, this was done under a set of terms and guidelines, but computer scientists of that period didn’t mind that, nor would the computer scientists of today mind it. This open source code made Unix extremely popular.
If we look at this scenario carefully, it is essentially an open source license by definition. Let’s see how.
So, what is an open source license?
Open source licensing is a system that dictates the terms and conditions of the use, modifications and distribution of the software code by people other than the originator of the software. It essentially includes the permissions and rights that would be required to use or repurpose the code for building newer applications with it or adding it into existing projects.
Now, can you possibly tell me that what Unix did was any different? I don’t think so.
Open source software licenses indeed go back to the late 60s, however, its more formal use was witnessed in the 90s with the introduction the GNU project thanks to Richard Stallman. He later created the GNU GPL license. The terms of this license were that anyone could redistribute software, provided that the source code was open and not as secret.
Then with the advent and popularity of the Linux operating system and its adoption of the GNU GPL license, open source licensing became the norm.
According to the Open Source Initiative, today there are about 80 approved open source licenses. And you yourself can create one for your software, the Open Source Initiative would make you go through its license review process. You can very well do it, however, not many would recommend it.
So, in essence open source licenses are contracts for open source projects, which are as legal as they are binding, between the authors of the software and the people who would use its components.
To highlight the importance of an open source license, I’d say that it is these that actually make software development become aligned with open source. Without an open source license, the software cannot be used and redistributed by anyone, despite the fact that its source code is publicly available. And they are similar in cost as compared to OSS, so, when asking, are open source licenses free, the answer is yes, much like the software itself.
How are Open Source Licenses Distinguished?
Now that the meaning of open source licenses is explained, let’s move further along. What started out as a single license by Stallman has become a standard practice in the open source community. I mentioned earlier that there are about 80 open source licenses available today, however, if these were to be categorised, you would only be able to get two. And these two mark the distinction in the form and application of the said licenses.
And here are the open source licenses by category:
Permissive Licenses
Upon looking at the definition of the term permissive, you’d find words like liberal, excessive freedom, non-restrictive and my favourite, open–minded. And these words just about define the scope of these licenses.
As their name implies, the permissive open source licenses provide more freedom to use, to modify and to redistribute software. You can do anything you want, even using the software for proprietary purposes is not off the table.
The only aspect on which these licenses have a restriction on the acknowledgement of the author. What this means is that you have to adhere to the copyright notice and keep that in place when you are distributing your own software. As long as you do that, anything goes here. Even if you do not want to share the source code of the modifications, it is totally alright.
Copyleft Licenses
As far as free softwrae licenses go, copyleft license is at an 180 degree angle from permissive. If one is the North Pole, the other is the South Pole.
Why?
It is because, while permissive licenses boast freedom and liberty, copyleft licenses are the epitome of restrictions. When a copyleft license is issued on a program, other developers can use it, modify it and redistribute it, however, the redistribution has to be aligned with the copyleft license terms. This means the modified program has to make the source code publicly available, just like the original program. And there is no going about it.
The GNU GPL license, now on its third version, is the paradigm here. Stallman did not appreciate companies using his software and then closing it off as proprietary. And that is what this license prevents.
So, what happens when a proprietary software uses a program with a copyleft license in its source code?
It would have to make it public and possibly release the entire software royalty-free, since it would be under the stringent terms of the copyleft license. The risk of exposing your intellectual property comes inherent in these licenses.
Furthermore, you cannot place any more restrictions on the licensee’s way of exercising his license. You could say that the phrase, anything goes, doesn’t come close to the definition of a copyleft license.
Let’s Look at Some of the Popular Open Source Licenses
After the categories of open source licenses, the next thing to know is the licenses that have been issued under them. I wouldn’t be talking about all 80 of the licenses approved by OSI, that would take ages for me to write and you’d get bored halfway through the read. So, I have a list of 9 of the most used open source licenses.
So, let’s begin looking at open source license examples based on the category they fall under.
Permissive licenses
Apache 2.0
Being a liberal license, the Apache license 2.0 allows the freedom of using, modifying and distributing any of its products. The requirement here is to include the license notifications and copyrights on the distributed code or like a notice in the software itself or both.
Under this license’s terms of service, it is not mandatory to release its source code upon distribution, be it a derivative work, a larger project or basic modifications. All of these can carry different licensing terms.
MIT
The simplest type of license of them all, named after the famous university, it’ll only take me a single sentence to explain it. MIT license is the license that allows you to do anything with the original code, with no restrictions on distributions, as long as you keep the original copyright and license notice in the distributed source code or software.
Berkeley Software Distribution
The BSD license, like the other two permissive licenses, lets you freely modify and distribute the software contingent upon you keeping the copyright notice, following the list of conditions along with the disclaimer.
It has three categories to it;
The 4-clause BSD was the original and first BSD license and had an advertising clause and a non-endorsement clause;
The 3-clause BSD was the modified version without the advertising clause;
And the 2-clause BSD, also known as FreeBSD, further removed the non-endorsement clause, making it almost similar to MIT in simplicity and use.
Copyleft licenses
GNU GPL
GNU General Public License is by far one of the most popular open source licenses, being associated with the free software foundation, and pioneer of the copyleft licenses, being the first one to be OSI approved,. It was established to prevent your software from becoming proprietary.
The GNU GPL license states that any software using a GPL component, despite its proportion of use, has to make its source code publicly available upon distributing. You are going to be passing on the same rights you received through the license to the person adopting your software, meaning if your source code is in the public domain, anyone using your component has to do the same. This makes the GPL license the strongest copyleft version.
At present, GPLv3 is the version that is being widely adopted.
Affero GPL
You would think that the GPL license must be full-proof without any loopholes, but there is one. The GNU GPL license only works when the software developed using a GPL component gets distributed. However, when the same is made available over a network, there aren’t going to be any red flags.
To counter this predicament, the Affero GPL license comes in, it essentially monitors the distribution over networks, even remote ones, and sends the right alerts to the GPL license. This makes the AGPL quite important for many.
Lesser GPL
The LGPL license is another variant of the GNU GPL license. There aren’t any more loopholes that it would cover up. It offers much the same license notifications and copyright protection. The only difference here is the size of a project can change the license terms.
For explanation, a smaller project under a larger project would not have to comply with the larger project’s licensing terms. And a smaller project accessed as part of a larger project would not be asked to share the source code of the larger project. I’d say LGPL makes the GPL licenses seem a little liberal.
Mozilla Public License
The MPL, maintained by the Mozilla Foundation, is as liberal a copyleft license as they come. The reason lies in its distribution protocol. As a copyleft license, the MPL does mandate that the modified code of its component be made public, however, this public sharing is only applicable to the modifications that have the licensed components and not the entire software. The stipulation is to store the MPL code in separate files and make that openly available.
The license is compatible with GNU GPL, given its enforced copyright notices and patent grants. Nonetheless, it is often considered to be a balance between permissive and copyleft licenses.
Common Development and Distribution License
Often referred to as the cleaned up version of the MPL, CDDL has much the same attributes of the former. Given the fact that it was inspired by MPL, that comes as no surprise.
Upon distributing the software in executable form, it is mandatory that you make the source code available. However, if your contributions aren’t part of the original software and are separate files, you are not required to make it public by releasing it under CDDL. A lot similar to MPL, right?
With this license, you will have the liberty to modify and distribute the original or derivative works of any CDDL software. The only stipulations are on changes to copyright, patent or trademark notices of the software along with keeping on the contributor acknowledgements and license notices.
Eclipse Public License
Founded by the Eclipse Foundation, the EPL has certain requirements on the distribution of an EPL component. However, these vary given the circumstance of the modified code’s distribution patterns.
Modifying and distributing an EPL component in the source code of your project mandates you to disclose the modified code under the EPL;
While modifying the and distributing the same in the form of object code would mandate you to make the code available upon request. Further, you would also be asked to disclose the way in which the source code can be requested.
What is more is that individual program components, including EPL, non-EPL and proprietary code, can be clubbed together and sub-licensed. All you would have to do for that is ensure that the non-EPL elements are separate objects.
A Quick Look at Open Source License Example Through Drupal
Is Drupal free to use? Yes, it is.
Is Drupal free for commercial use? Yes, it is.
Why?
Drupal is an open source CMS, that is why. And to call itself open source, it had to be registered under a license. And of course, it is. Drupal is licensed under GNU GPL Version 2 or later. All the contributed files that are hosted on Drupal.org are licensed under the same.
You can freely download, reuse, modify and redistribute any component of a Drupal.org project under the terms of the GPL license, that we talked about earlier. The core software on Drupal can also be run and licensed in combination with a version 2 or 3 compatible license. Saying that Drupal projects can very well depend on or be linked to GPL incompatible non-code assets, however this relies on the maintainer possessing the rights to distribute the non-code assets.
Let’s now look at the specific aspects of Drupal and how they are licensed.
The files, be it PHP, JavaScript or images, being a part of a Drupal project are licensed under the license as Drupal.
The modules and themes are considered derivative works and so are to be distributed under the GPL version 2 or 3.
The content, however, is licensed under the Creative Commons Attribution-ShareAlike 2.0.
The sample code follows the same GPL licensing terms.
Considering all of these, who would you guess holds the copyright of the code in Drupal?
The answer is its hundreds and thousands of contributors, who agree to release their code under the same license. However, if a contributor has created a patch, but isn’t willing to license it under the GPL, he should probably not submit it and the point of retaining a copyright on the same would be moot.
When I started writing this blog, I considered the copyleft licenses to be rigid and unattractive. However, realising that its pioneer is the license behind Drupal made me change my perspective. Drupal has helped a community of close to a million come together and build and distribute their work and that would not have been possible or even beneficial, had the source code not been publicly available.
So, open source licenses as per their meaning can be liberal and rigid, but I personally feel that the rigidness serves more purpose than the liberty ever could.
You must be logged in to post a comment.