Using data from OSI’s community project ClearlyDefined, Aleksandrs Volodjkins explored the ClearlyDefined dataset from September 21, 2023. ClearlyDefined is a collaborative project providing comprehensive and standardized metadata about software components’ origins and licenses, its data shed light on the prevailing trends that shape the Open Source ecosystem.

Overall, MIT and Apache 2.0 are by far the most popular licenses, although popularity of licenses vary greatly depending on the package manager. The simplicity of these licenses, allowing users to modify and distribute code with minimal restrictions without imposing additional requirements, has undoubtedly contributed to their widespread adoption.

The license terrain is not uniform across all package managers. Each programming language has its own set of license preferences within their ecosystems. For instance, the JavaScript community often leans towards the MIT license, while Python developers show a similar affinity for Apache 2.0. The ISC license, with its simplicity and permissiveness, finds its niche in the JavaScript community. BSD licenses, both 3-Clause and 2-Clause, maintain a steady but comparatively lower adoption rate. The GNU General Public License (GPL), embodying the ethos of free software, enjoys a presence but falls behind MIT and Apache 2.0.

The Challenge of Unlicensed Components

Despite the prevalence of well-established licenses, a concerning revelation emerges from the ClearlyDefined dataset – a substantial percentage of Open Source components lack a designated license or carry the SPDX identifier “NOASSERTION.” This ambiguity introduces uncertainty about the permissible use of such components, potentially hindering collaboration, creating legal complexities, and security concerns for developers.

The Need for Clarity and Standardization

Addressing the issue of unlicensed components is crucial for the continued health of the Open Source community. Developers, organizations, and the community at large benefit from clear and standardized licensing. It not only facilitates collaboration but also ensures legal compliance and protects the intellectual property of contributors. Additionally, it helps developers to keep track of components that might have vulnerabilities.

Towards a collaborative solution

The issue of unlicensed components is a community-wide challenge that needs a community-wide approach. The ClearlyDefined project aims to address this challenge by inviting developers across different organizations to crowdsource a global database of licensing metadata for every software component ever published. It allows developers to fetch a cached copy of licensing metadata for each component through a simple API and contribute back with any missing or wrongly identified licensing metadata, helping to create a database that is accurate for the benefit of all. Check it out!

Javascript (npm)

The npm package manager for JavaScript contains components that mostly use the MIT license (53%), followed by Apache 2.0 (14,76%) and ISC (10,48%). The ISC license was published by the Internet Systems Consortium and, while popular among JavaScript projects, it’s not used much by other programming languages. A small percentage of projects don’t have a license (8%) or a SPDX-identified license / NOASSERTION (5.49%).

.NET (Nuget)

One of the most alarming data for Nuget, the package manager for . NET is that a great percentage of its components either don’t have a license (26.76%) or are found to be NOASSERTION (31.95%). Licenses under MIT or Apache 2.0 are at 21.55% and 13.37% respectively.

Java (Maven)

The great majority of components in Maven, the package manager for Java, use the Apache 2.0 license (69.18%). Components with the second most popular license, the MIT, represent only 7.4%. Components with NOASSERTION are at 14.75%.

Python (Pypi)

For Pypi, the package manager for Python, components under the MIT and Apache 2.0 licenses dominate, at 29.14% and 23.98% respectively. Components under BSD 2-Clause and GPL 3.0 are at 6.25% and 6.11%. A substantial percentage of components don’t have a license (23.69%).

Ruby (Gem)

The great majority of components at Gem, the package manager for Ruby, use the MIT license (63.11%). They are followed by the Apache 2.0 and BSD 3-Clause licenses at 8.22% and 6.66% respectively.

PHP (Composer)

The MIT license is a very popular choice among PHP components of the Composer package manager, at 64.37%. Projects under BSD 3-Clause and Apache 2.0 sit at 5.72% and 3.92% respectively. 

Go

Apache 2.0 and MIT licenses dominate Go, with 32.49% and 20.1%. A substantial percentage of Go components don’t have a license (29.67%).

Rust (Crate)

For crate, the Rust package manager, projects under MIT and/or Apache 2.0 dominate. Combined, they represent 83.52%.

Marc Jones is General Counsel at CivicActions, a professional services firm providing design, technology, consulting and training services to the government. He started his law career at Software Freedom Law Center and has advised various open source and free culture organizations over the past nine years. In other words, he has a lot of experience in the licensing of open source software and shared some of his top-level advice for anyone looking to open source a project. Here’s what he had to say:

At the start of the project, these are the basic things to consider:

1. What will you name the project?
2. Where will you publish the code?

Pick a unique name that will have longevity with the project. Down the road it will need to fit into a software distribution ecosystem, so it should not be too common a name, and it should certainly not infringe on any trademarks.

Marc advises making the project publicly available from day one. Giving it to third parties is the whole point of licensing and open sourcing a project. GitHub and GitLab are the most common places to publish code with distributed version control. Coordination of many file changes is what open source software platforms like Git are designed to do. Publishing here means copies can be shared, changes can be made to those copies, and suggestions can be made to those changes. It is this exchange of drafts and changes that makes the project open source.

After your project is named and you’ve chosen a repository in which to publish the code, it’s time to look at licensing options and important steps in setting it up. Marc shares nine popular OSI-approved licenses that lawyers and engineers are most familiar with. He also suggests considering whether you want a Copyleft license, which is designed to encourage users to produce and give back to the comments, or a Permissive license, which maximizes the number of people using the code with less restrictions on how they do it.

If the project was started with a third-party library, it’s wise to license your project under the same license that library uses. If you choose a different license, make sure the licenses are compatible, and be sure to update your LICENSE file with the library’s license. And don’t delete anything from the third-party code. Remember, this is a community: if the ecosystem in which your project lives prefers a certain license, Marc suggests staying aligned with that ecosystem and going with that license.

Finally, once you choose your license, add a copy to the LICENSE file and complete the README file, including a copyright statement and a clear statement of your inbound/outbound policies. These are basic set up procedures that are best not to be overlooked.

Watching Marc’s video will offer more details if you’re serious about open sourcing your project. You can do that below:

Ospos And Lawyers Simplify Open Source License Compliance Or How Most People Do Open Source : OSI : Free Download, Borrow, and Streaming : Internet Archive

This talk would walk through compliance steps from the perspective of a good faith effort to create open source software — in other words, what most people…

archive.org

The previous blog in this series features an OSI board member talking about “How to talk to your boss about open source”. This concludes the blog series for the Practical Open Source Information (POSI) 2021 event–thank you for reading along! To keep up on industry news, events, and insights from open source thought leaders and more, sign up for OSI’s newsletter.

Through featured stories, how-to guides, developer profiles, and podcast conversations, members of GitHub’s open source community regularly publish articles relevant for every stage of the developer journey. From those looking to land their first job to managers or leads onboarding new employees, The ReadME Project aims to elevate the whole community by amplifying expertise and personal stories and giving maintainers and contributors more opportunities to lift each other up.

"A mentor once told me, 'Lift as you climb': As you move up in the tech industry, lift people along with you," said Cassidy Williams in a recent Developer Story. "They’ll fill in the gaps you leave behind, and the industry is so much better when everybody gives back. You get a lot by giving."

This is great advice not just for building a career, but an encapsulation of the open source ethos. Williams shares her conference talk slides and notes, and even her speaker rider, in a repo. She not only shares her technical knowledge, but also helps people learn to give their own talks so they can advance their careers and deepen their own technical knowledge.

Regardless of what motivates them to contribute, they're creating positive feedback loops where the whole community benefits. "Being a developer is priceless," Hoppscotch creator Liyas Thomas shared in an article on his open source journey. "I love building tools that help the community. I want to show others that it is possible for a guy like me to create a tool like Hoppscotch."

Thomas created Hoppscotch initially to scratch his own itch. His job involved testing APIs and he wasn't satisfied with the tools available at the time. "My day-to-day consisted of manually testing each one to get a schema of every response, which was hectic," Thomas wrote. "When I see an opportunity to make something easier from a developer’s point of view, I try to hack a solution and make it open. So I created an MVP called Hoppscotch with buttons, an input path, and a list box, and open sourced it."

It's a project with an amazing multiplier effect. Not only did it help Thomas do his job, and set an example for others to follow, it helped other developers in their own API testing, which in turn helps the end-users of the software built by all of those developers. Hoppscotch, now a thriving open source project with more than 175 contributors, also created a new opportunity for developers, designers, technical writers, community managers, and others to hone their own skills by contributing to the project.

Spreading these opportunities generally takes active stewardship. According to GitHub's 2021 State of the Octoverse report, projects that use the "Good First Issues" tag see significantly more contributors than those without. For example, projects with around 25% of their Issues marked "Good First Issue" saw 13% more contributors, as opposed to those without.

Others take an even more hands-on approach. For example, CHAOSS, the organization behind the open source community analytics tools Augur and GrimoireLab, shared their experience onboarding new contributors in a ReadME Project article. In particular, they underscored the importance of mentorship.

"Having a dedicated person who engages with new community members helps them overcome hurdles and stay involved with the project,” CHAOSS co-founder Georg Link said. The State of the Octoverse report found that mentorship increased productivity in open source projects by 46% percent and tripled the chances of having a healthy culture.

“It's a paradoxical constraint,” says Sean Goggins, another co-founder of CHAOSS and maintainer of Augur. “Fostering a strong community takes pressure off maintainers so that they can focus more on the technical side because there are other people to take care of non-technical things. But community management takes time away from the technical side of the maintainer role.”

Creating community engagement roles within an open source project also provides still more opportunities for people to get involved and enhance not just the project, but themselves. But the growing pressure facing maintainers is real. The emerging field of "contributor relations" aims to establish healthy best practices for open source communities that benefit both maintainers and contributors.

There are plenty of challenges in the open source community, but they're being met in just the same way that technical challenges are: collaboratively and in the open. And with every advance, the whole community grows stronger. You can follow the latest by subscribing to The ReadME Project newsletter—or help out by pitching your own Guides or suggesting topics for future coverage.

Developers, and the technology industry as a whole, benefit enormously from open source software. Science, businesses, careers and humanity advance on open source platforms like Ruby on Rails, Node.js, and Kubernetes. The culture of open source is full of individuals who want to give back to communities that they've benefitted from, whether that's by contributing code and documentation, building new tools to support an open source ecosystem, or by volunteering time to answer questions, organize events, or help with community management.

In her presentation at POSI 2021, Deborah Bryant, OSI Board Director, recalled that she was first introduced to open source when she ran a commercial ISP earlier in her career. It was there that a 19-year-old developer excitedly told her about Linux and got her permission to work on the open source project and become a contributor. Later, she moved on to serve as the Deputy CIO for the State of Oregon where she was tasked with explaining complex and expensive technical projects to the legislature. She shares a story of the House of Representatives receiving a bill requiring the state of Oregon to consider open source products in software bids. The bill didn’t pass but she learned a lot about open source in the government sector from that experience.

After her time working for the State of Oregon, she moved onto Open Source Lab at the University of Oregon. Today she does a lot of open source advocacy and work, on several boards including DemocracyLab, the Open Source Elections Technology Foundation, the Eclipse Foundation, and as leader of Red Hat’s Open Source Programs Office, and now in her final year on the board of the OSI.

With all this exposure to open source in various sectors, Deborah has a lot of advice to offer when talking to a decision maker about adopting open source. First, she explains that no matter who the audience is, it’s important to keep the following in mind:

1. Understand your own motivation for having this conversation about open source.
2. Understand the motivation of the person you’re talking with; what problems are they trying to solve?
3. Accept that you may not be the one to gain the buy-in. The decision maker will likely go seek other experts to support them in making their decision.
4. Use as much objective information as you can to support your cause, such as research data and use cases.

Deborah introduces us to a heuristic way of thinking known as Systems Thinking. The idea is that every technology project has three components: technical, financial, and political. All of these components should be considered when briginging an open source initiative to the table.

Here are the considerations Deborah suggests anyone take when approaching decision makers who may be unfamiliar with open source from four different industries:

Private Industry: in influencing a manager or peers in a company, one must ensure the open source project they’re proposing is aligned with a company’s business plan and/or technology roadmap. Figure out where open source may fit and enlist others to support the case. Some key reasons why companies work with open source include:

• Innovation/digital transformation
• Cost reduction/avoid lock-in
• Developer happiness/talent (open source attracts great developers in this time of the great resignation)
• Product strategy
• Industry collaboration via standard

Offering statistics is always helpful, such as this one: “83% of IT executives in the software industry (of 1,300 surveyed) were more likely to select a vendor who contributes to the open source community.” (Source: Red Hat-funded research)

Non-profit: philanthropic organizations are using open source solutions frequently because:

• They have shared values with the open source movement
• They want to spend money on mission, not tools
• People in the community can help with infrastructure, like helping them source replacement technology, as an example

Public Sector/Government

• Objective data helps
• Can help gain federal funding
• Local community enhancement like career support for women reentering the workforce

Academia: students and faculty are interested in open source. She encourages identifying a strength or an enthusiastic program to build upon, finding a champion to work with, and making a case to perhaps refresh a stale program or offer something new to attract students. Examples of open source in the field of academia include:

• Open Source Labs
• Computer Science and Engineering programs
• Social innovation through open source projects for students
• Humanitarian open source projects (side note: human benefit in a project draws more women into engineering)

Deborah offers a lot of resources, a couple of which are Teaching Open Source (TOS) and Professor’s Open Source Summer Experience (POSSE). More can be seen in the video.

If you’re interested in watching the full video, which includes some interesting examples of open source projects in all these areas as well as conversation starters, you can watch it below:

The Open Source Journey How To Talk To Your Boss About Open Source : The Open Source Initiative : Free Download, Borrow, and Streaming : Internet Archive

Track: The Open Source Journey Speakers: Deborah Bryant At some point in time, you’re going to want to have that conversation. To explain open source to…

archive.org

The previous blog in this series, “The Business Impact of Open Source” ((add link)), came from the Google Open Source Programs Office. Click the link to read it, and come back to catch our next featured member from the Practical Open Source Information (POSI) 2021 in the coming weeks.

Joining and contributing to an open source community is a great way to use your skills in creative ways while getting exposure to interesting projects that will expand your skill set. This video shared one person’s experience transitioning from a proprietary environment to open source. The path to get started, the challenges along the way, and key lessons learned help viewers anticipate what moving from proprietary to open source culture could be like.

Petra Sargent was a software engineer for Nortel Networks after earning her degree in Computer Science 20 years ago. She had learned Pascal in college, but once she signed on with Nortel she was trained in their proprietary programming language, operating system, and version control software, complete with a confidential system architecture book that she kept locked in her desk when she wasn’t using it.

A question from a middle schooler at a STEM career panel Petra spoke at led her to begin to question her career path. Although she enjoyed her job, Petra began to wonder if she was able to learn different types of technology, if her skills were marketable, and if she was really being challenged creatively in this proprietary environment. Petra ended up leaving Nortel to focus on her family, but when it came time to join the workforce again, these questions lingered in her mind.

Prospective employers were looking for candidates with experience in Java or Python, and she found the proprietary technology she was so well versed in had become obsolete. She took it upon herself to learn Python and noticed a shift in the industry to open source when she was looking for a project to apply her learning. It was a bit intimidating to step into open source communities, but while attending a conference Petra was introduced to the perfect bridge.

She learned of an internship program called Outreachy that offered mentoring to those traditionally underrepresented in tech to help them make their first contributions to Free and Open Source Software (FOSS) communities. In order to be accepted into Outreachy, Petra had to make a contribution to an open source community. With many options to choose from, she selected OpenStack as the community to make her first contribution to. She felt her skillset matched the areas of contribution available in OpenStack and it was a great way to get her feet wet in the world of open source. Her contribution was accepted and she was welcomed into the Outreachy internship program.

Having the support of her mentor helped ease her entry into the open source environment. Working on that first project she began to embrace the open source culture, including the principles of “fail faster,” and “release early, release often.” The collaboration and feedback loop in open source was very different from the proprietary environment, and although it took some getting used to, she found it very empowering.

Petra ultimately gained the skills needed to become a technical writer at Red Hat and really found her home in the open source community. Transitioning from a proprietary environment to open source isn’t always easy, but there are an abundance of resources available to help make that shift.

You can watch Petra’s video from the POSI event below:

The Open Source Journey Moving From A Proprietary To An Open Source Development Culture A Primer : OSI : Free Download, Borrow, and Streaming : Internet Archive

Transitioning from a proprietary into an open source development environment can be daunting, but the move is much easier than it looks. So- how does a…

archive.org

The previous blog in this series features OSI members from the Rochester Institute of Technology in “Beyond Code and Licenses: Co-developing Community Strategies Within Academia.” Come back to catch our next featured member from the Practical Open Source Information (POSI) 2021 in the coming weeks.

Creative, exciting applications of open source software can be found worldwide, and who better to share the details of new use cases than the practitioners themselves. In this blog series we’ll feature guests who told their open source stories during Practical Open Source Information (POSI) 2021, an online conference hosted by OSI.

The Rochester Institute of Technology (RIT) not only offers a minor in free and open source software and free culture, but it also recently created an official Center of Excellence called Open@RIT. It’s dedicated to fostering the collaborative engine for faculty, staff, and students working on open source projects. The goal is to discover and grow the footprint of RIT’s impact on all things open across many disciplines, both within the university and beyond. This includes open source software, open data, open science, open hardware, and open educational resources and creative commons licensed efforts, which collectively they refer to as Open Work.

Mike Nolan, Assistant Director at Open@RIT and Django Skorupa, Strategic Designer, walked POSI participants through their work, and you can watch their presentation, the video of which is embedded at the end of this post.

Through their Open@RIT Fellowships, students interested in careers working with open source have the opportunity to serve on a project accelerator, offering them exposure to the launch or conversion of projects to open source. Open@RIT Fellows can begin building a community around and collaborating on on-campus projects to get first-hand experience in the maintenance and structure of the community, an important facet of open projects that balances the contribution of community members. Essentially, Open@RIT is a cooperative education program set up as a consultancy where student fellows are placed on a team that provides services such as design, development, technical writing, and project management on Open Work being developed by members of the RIT community.

In its early days, the program focused on the creation of a methodology playbook detailing how Fellows work with faculty members, staff, and students on their open projects and how they create, build, and sustain communities around that work. This methodology playbook offers a framework for fellows to follow in their efforts to better understand and support the community that surrounds the Open Work. Leaders at Open@RIT give credit to the Mozilla Open Leadership Training Series and the work of Nadia Eghbal in her book Working in Public for inspiring their program and the development of the methodology.

The consulting process used by Open@RIT with Fellows has three steps. Step one is contextualization, asking questions that allow student fellows to understand the scope and goals of the project. Step two is identification of stakeholders and contributors and how they’re attracted to a project, examined through an archetypal model. Here, goals of the stakeholders and contributors are compared with the goals of the project, revealing gaps in the contributor pathways. This naturally leads to step three which is identifying shortcomings. This step uncovers the role Open@RIT can play in support of the project, moving it toward a unified goal. This step develops a ground-up solution, reframing the problem as many times as necessary until an end-to-end pathway is established. Services provided by the fellows include project documentation, marketing inbound materials, feedback systems, and outreach and networking strategies.

Many Open@RIT Fellows have never worked in open source before. The program offers them a valuable opportunity to learn about open source terms and methods while actually doing the work. Developing open source projects in an academic setting offers students an ecosystem that embraces questioning, teaching, and mentorship, which aligns with the definition of open source itself and equips these students to step into careers in open source with experience that sets them up for success.

Watch Nolan and Django of Open@RIT at the POSI event:

Come back to catch our next featured member from the Practical Open Source Information (POSI) 2021 next week.

As a reminder, ClearlyDefined is a repository of information about free and open source software (FOSS). You can turn to ClearlyDefined when you want to locate source information for a version (e.g., Git commit), verify licenses, and catch up on vulnerability notifications—all in one place.

ClearlyDefined premiered in 2017. Since then, the community has reached several milestones, including these recent achievements:

• Support for Go components. If you use Go modules, you can now retrieve their license definitions using ClearlyDefined. For more information about how to do this, please see our documentation.
• A redesign of the ClearlyDefined user interface with a focus on usability and accessibility. This redesign should be deployed before the end of 2021.

The community continues to complete curations and contribute code. A recent contribution from from Qing Tomlinson fixed a long standing issue with characters in PyPi definition coordinates.

Moving into the new year, the ClearlyDefined community will be planning its road map and user stories for the new year. Please join in and contribute to a very worthwhile cause that benefits the entire open source community. Learn more and join us at: https://clearlydefined.io/