Open source code is used by developers because it is free to download and use. It can be modified so as to make it work on different or virtual operating systems or also be adapted to fit a specific need. It can be used on software, websites and other applications where a lot of customization is needed.
Open source code allows programmers to study, copy and collaborate directly with fellow developers and programmers. This in turn can help some of these programmers come up with new products and services that they can market and sell. So while they do not completely own the code they write, they can keep the rights to use it once it has been published as open source
If I say that open source developers are driven by altruism and the desire to help others, a lot of people reading this article may smile in disbelief. But this intrinsic motivation is the primary reason most people work on open source projects.
Don’t underestimate the importance of personal benefits – those feelings of being helpful and self-accomplished.
A simple policy for using open source code
The usage policy is an essential component of any compliance program. This set of rules is included in your open source strategy document (you have one, right?) and made available to everyone for easy reference.
The usage policy ensures that any software (proprietary, third-party, or open source) that makes its way into the product base has been audited, reviewed, and approved. It also ensures that your company has a plan to fulfill the license obligations resulting from using the various software components, before your products make it to customers.
There is no need to make a lengthy or complicated document. A good open source usage policy includes six simple rules:
- Engineers must receive approval from the OSRB before integrating any open source code in a product.
- Software received from third parties must be audited to identify any open source code included, which ensures license obligations can be fulfilled before a product ships.
- All software must be audited and reviewed, including all proprietary software components.
- Products must fulfill open source licensing obligations prior to customer receipt.
- Approval for using a given open source component in one product is not approval for another deployment, even if the open source component is the same.
- All changed components must go through the approval process.
Scientists and doctors share their experience by writing scholarly articles and participating in scientific conferences. UI/UX designers share their experience on Behance or Dribbble. Writers print their books or share them via online platforms. Musicians and moviemakers share their work with the world via different streaming services. Why would software developers be any different and want to miss their opportunity to get recognition?
When working on or running open source projects, you can get recognition from the developer community in a number of ways, such as creating a great GitHub-profile and participating in events like Hacktoberfest.
You might also get discounts, free admissions to events, and a well-developed infrastructure to run your projects. Not only does working on open source projects save you money, but also it inspires you to use all the greatest tools available to you in your own projects.
Source Code Scan
In the source code scanning phase, all the source code is scanned using a specialized software tools (there are many commercial vendors that offer such tools in addition to a couple open source alternatives).
This phase typically kicks off when an engineer submits an online usage form. (See the sample usage form and rules for using it, below.) The form includes all the information about the open source component in question, and specifies the location of the source code in the source code repository system.
The form submission automatically creates a compliance ticket in a system such as JIRA or Bugzilla and a source code scanning request will be sent to the designated auditing staff.
Periodic full platform scans should also take place every few weeks to ensure that no open source software component has been integrated into the platform without a corresponding form. If any was found, then a JIRA ticket is automatically issued and assigned to the auditing staff.
Some of the factors that can trigger a source code scan include:
- An incoming usage form, usually filled out by engineering staff.
- A periodically scheduled full platform scan. Such scans are very useful for uncovering open source code that snuck into your software platform without a usage form.
- Changes in a previously approved software component. In many cases, engineers start evaluating and testing with a certain version of an OSS component, and later adopt that component when a new version is available.
- Source code is received from a third-party software provider who may or may not have disclosed open source.
- Source code is downloaded from the web with an unknown author and/or license, which may or may not have incorporated open source code.
- A new proprietary software component enters the build system where engineering may or may not have borrowed open source code and used it in a proprietary software component.
After the code is scanned, the scanning tool produces a report that provides information on:
- Known software components in use, also known as the software Bill of Materials (BoM)
- Licenses in effect, license texts, and summary of obligations
- License conflicts to be verified by legal
- File inventory
- Identified files
- Code matches
- Files pending identification
- Source code matches pending identification
If you or your company actively participate in the open source community, you can earn a great reputation. This way, if you are an individual or self-employed developer, it will be easier for you to find a job as a freelancer or a full-time employee. If you represent a software development company, it will be easier for you to find people willing to work for you, partners willing to cooperate, and clients willing to request your professional services.
This is why developing open source software creates a perfect advertising opportunity – a win-win situation both for developers and development agencies.
Sense of value
No need to hide the truth: job burnout plagues developers’ work and software vendors’ HR strategies. If you are a company owner, by motivating your employees to participate in open source development, you show them that their work has value. Not only will they be working on your commercial projects but they will also be providing value to the wider developer community by working on open source projects.
By helping your developers achieve these feelings of purpose and value, you keep them interested in working with you.
The same is true if you are a self-employed developer. Engaging in open source software development will make your work meaningful, and you will not grow to hate it as time passes.
Identification and Resolution
In the identification and resolution phase, the auditing team inspects and resolves each file or snippet flagged by the scanning tool.
For example, the scanning tool’s report can flag issues such as conflicting and incompatible licenses. If there are no issues, then the compliance office will move the compliance ticket forward to the legal review phase.
If there are issues to be resolved, then the compliance officer creates subtasks within the compliance tickets and assigns them to the appropriate engineers to be resolved. In some cases, a code rework is needed; in other cases it may simply be a matter of clarification. The sub-tasks should include a description of the issue, a proposed solution to be implemented by engineering, and a specific timeline for completion.
The compliance officer may simply close the subtasks once all issues are resolved and pass the ticket along for legal review. Or they might first order a re-scan of the source code and generate a new scan report confirming that earlier issues do not exist anymore. Once they’re satisfied that all issues are resolved, the compliance officer forwards the compliance ticket to a representative from the legal department for review and approval.
In preparation for legal review, you should attach all licensing information related to the open source software to the compliance ticket, such as COPYING, README, LICENSE files, etc.
Open source code is often higher quality. A piece of software created by a team of developers can be lower quality than that developed by thousands of developers from all over the world with experience in different technologies, industries, and projects. And bugs in open source software are identified very quickly as the code is being constantly reviewed by multiple developers.
Even code written by a single developer is often higher quality if it is open sourced. If you write code that only you or your close colleagues will see, you may not care much about code style. But if you write code that everyone can see, you will do all you can not to look like a code monkey. Reviews, contributions, and refactoring from the community are all helpful here.
In the legal review phase, the legal counsel (typically a member of the open source review board, or OSRB) reviews reports generated by the scanning tool, the license information of the software component, and any comments left in the compliance ticket by engineers and members of the auditing team.
When a compliance ticket reaches the legal review phase, it already contains:
- A source code scan report and confirmation that all the issues identified in the scanning phase have been resolved.
- Copies of the license information attached to the ticket: typically, the compliance officer attaches the README, COPYING, and AUTHORS files available in the source code packages to the compliance ticket. Other than the license information, which for OSS components is usually available in a COPYING or a LICENSE file, you need to also capture copyright and attribution notices as well. This information will provide appropriate attributions in your product documentation.
- Feedback from the compliance officer regarding the compliance ticket (concerns, additional questions, etc.).
- Feedback from the engineering representative on the auditing team or from the engineer (package owner) who follows/maintains this package internally.
The goal of this phase is to produce a legal opinion of compliance, and a decision on the incoming and outgoing license(s) for the software component in question. The incoming and outgoing licenses are in the plural form because in some cases, a software component can include source code available under different licenses.
Before your start with open source code, you should understand what it is, why it exists, and how to use it. Open source code is available in a wide range of categories, including C/C++ open source code, PHP open source code, Java open source code, Python open source code and many more.