Lucas Gonze

Reply to posts using GitHub (, email (, or the guestbook (

Patterns in Open Source License Compliance

I have been investigating problems incorporating third-party sources into proprietary code bases. The goal is to help companies follow the rules when they work with open source.

I'm looking at snippets, not standalone packages tidily encapsulated in their own directories. This kind of copying is free range and messy. It's everywhere. Copy-pasta is just how developers do their jobs. They snarf code anywhere and everywhere.

That means compliance problems are super common. Managers mainly aren't aware - without tooling they don't have much visibility into which code came from where.

Developers need training in how to incorporate third party code, including Stack Overflow, open source repos with licenses, and sources without license statements. I imagine most of them just don't know how to handle these situations.

Developers need to start caring about compliance problems in third party code. If failures cost them and successes benefitted them they would do the work. CIs should run bots (like Github Actions) to recognize snippets from third party sources and flag it for examination by code reviewers. Reviewers need to know how to evaluate the reports.

Engineering management needs to drive these changes. They need to check whether job candidates know how to comply with copyright. They need to train developers in good practices. They need to ask for compliance checking in pull requests.

These aren't hard problems. They aren't high tech. However they are very large scale: adoption of new practices across the software industry is not a small project.

Pinning Github Actions Project Report

I woke up today to find that a particularly troublesome pull request was merged at last. My PR hardened build security by pinning Github Actions, using a hash to identify the version we intended to use rather than a tagged release.

The idea is that the maintainer of an action can easily inject malicious code into releases that have adoption already. It doesn't matter that the commit labeled v1.2.3 was originally benign if users of their Action are simply adopting any commit with that label. What users of the action must do instead is identify the version they want using the commit hash of the tagged release.

The need to pin actions is widely acknowledged in the security community. It is checked in OSSF Security Scorecards and documented in Github's own security suggestions.

A compromise of a single action within a workflow can be very significant, as that compromised action would have access to all secrets configured on your repository, and may be able to use the GITHUB_TOKEN to write to the repository. Consequently, there is significant risk in sourcing actions from third-party repositories on GitHub.

Despite the obvious need, I came to believe that it is more of a piety than a reality. There were obstacles for which there would be solutions if more people were doing it, and when I asked questions in social media I heard nothing but crickets. I even had to write documentation for Magma contributors.

There was a need for package management tools akin to Yarn, but targeted at Github Actions. I discovered only a single resource in the space, a CLI tool called pin-github-action. This is a modest project with 25 stars, one contributor, and 1090 lines of code, but it occupies a unique and valuable niche. Without it my own deliverable would have been even more work, so I stopped baking my own scripts and became a contributor. I have had 3 features merged and have 2 left to complete. In the long run this project needs a feature set comparable to lockfiles in NPM or the Golang package manager. In addition to new features for managing hashes, the hashes themselves shouldn't be exposed directly to developers. They should exist in a lockfile generated by tooling.

It was the need for tooling and documentation that made Action pinning in Magma so much work. It shouldn't be this way. In the future the open-source security community should converge to bring the infrastructure to maturity.

Open Questions about OSS License Headers

Following up on my blog entry Systemic Improvements to License Preambles , I found that many of my ideas are addressed already in the REUSE guidelines and the SPDX documentation on short identifiers. I was familiar with the SPDX work already, but I didn't focus on it.

On thinking and reading more - this time with explicit awareness of the prior art - some interesting questions remained.

  1. How to contact the developers or copyright holders when there is a need for extended permissions? For example, commercial use of code with a non-commercial license. Right now the email provided with the copyright statement is the default method.

  2. How can I set or get a complete list of copyright holders? The copyright statement in the header only applies to the creator of the project. Each subsequent contributor has their own copyright. Who are they? Were they acting in a personal capacity or did their employer own the rights? If their employer owned the rights, who was it? How can a contributor supply both their own name and their employer? Right now the best approach would be to mine git history for committer identities.

  3. Does the file mix code from different sources, with different copyright holders and license selections? This is particularly relevant to snippets pasted from sources like StackOverflow. There should be a way to mark the beginnings and endings, source, copyright holders, and permissions. Snippets are probably the biggest source of complexity. There should exist a way to verify that copied code is coming from a safe source.

  4. Where is the repo or canonical source on the internet for this file? It might have a tag to identify the source. If you look at the human-visible footer for my transcription of this folk song, you'll notice "Original Musescore file at ...github URL."

  5. How can this file be identified uniquely? How can I get an identifier that persists across modifications, copies, forks, and hosts? A simple solution is a random number embedded in the file at the time of creation.

  6. When I change the license of third-party code, should I record and publish the licensing history? This would apply when the original license permits relicensing. For example, MIT can be converted to Apache 2.0, as far as I understand.

  7. When is it ok to modify the syntax (but not semantics) of license statements (in whatever format)? Can you convert a long license statement such as the classic GPL 1.0 blurb to the equivalent shortform SPDX identifier? Can an SBOM tool that attempts to identify the license on each file save its conclusions into the file? Is there a way to mark such output as tentative?

  8. Should the header be "Copyright", “copyright”, "(c)", "©" or nothing? A single canonical answer is the best path. Ambiguity is bad. A simple solution is a messaging campaign to standardize on just one marker.

  9. Is there a machine-friendly way to mark unlicensable content like generated files? A simple solution is a new license blurb and short-form identifier saying something like "This file contains uncopyrightable information."

Systemic Improvements to License Preambles

Open source is deeply reliant on blurbs in files or directories.

For example, the GPL how-to:

This involves adding two elements to each source file of your program: a copyright notice (such as “Copyright 1999 Terry Jones”), and a statement of copying permission, saying that the program is distributed under the terms of the GNU General Public License (or the Lesser GPL, or the Affero GPL).

There are obvious systemic problems:

  • Free text is hostile to machine processing. Programs to analyze this text are notoriously inaccurate. Human vetting is built in to the process.

  • Lack of clarity in how to handle edge cases. If you fork a library, is the statement "Copyright 1999 Them" or "Copyright 1999 You"?

  • Ambiguity over whether to use "C", "c.", "copyright", (c), ©

  • English only

These items are only the trivial ones that jumped out right away. Improvements are needed and possible.

Some ideas:

  • Program-friendly markup. JSON, for example.

  • Unambiguous syntax amenable to schema validation.

  • Detailed semantics with thorough documentation

  • Move most of this information to an external document on the web. The blurb would be something like\
    # {'license-on-this-file':''}

A question to you, the reader: do you know of innovations in this space? Are there ongoing efforts to work on these issues?

Followup post:

What's Stopping Library Upgrades?

Big vulnerabilities in upstream dependencies can linger in deployed software long past the point when a patch is available. Maven estimates that 35% of Log4J downloads continue to pull the version with the world-famous vulnerability.

What's the cause? Why aren't developers applying patches?

National Ecosystems

If you follow the 35% link above you'll see that countries have characteristic exposure profiles. Taiwan is far and away the worst, and China next.

Taiwan and China share a language but not a government. Maybe the problem is security resources that fit common practices. Is Mandarin well supported by Dependabot and similar tooling? Are technology news sources for developers not covering Log4J? Is there cultural skepticism? Are different development platforms (e.g. Gitea instead of GitHub) popular there, and is there a difference in security resources?

The market share of unpatched L4J in a given country is not the same as the market share at a global scale. Taiwan is tiny - even 80% unpatched downloads would have less impact on the global numbers than 20% of a huge country like China.

The follow-up work here is a country-specific study of China and Taiwan. What's holding back patches may be obvious to developers in these places.

Maturity Levels

When a codebase is mature, there is more resistance to change.

From Beyond Metadata: Code-Centric and Usage-Based Analysis of Known Vulnerabilities in Open-Source Software:

In the early phases of development, updating a library to a more recent release is relatively unproblematic, because the necessary adaptations in the application code can be performed as part of the normal development activities. On the other hand, as soon as a project gets closer to the date of release to customers, and during the entire operational lifetime, all updates need to be carefully pondered, because they can impact the release schedule, require additional effort, cause system downtime, or introduce new defects.

How can patches specifically target mature codebases?

Mature software will have older code and will tend to use older library versions. The biggest issue is simply providing non-breaking patches for older library versions. The older a library the less its developers want to work on it, and the greater the chance that an upgrade will only be available with a major version upgrade.

What can the security community do? Encourage library developers to support old versions. Discourage breaking changes of any kind. Encourage application developers to give preference to libraries with a record of support for older versions.


There may exist a patch but it may not be well vetted. Every upgrade is a chance for something to go wrong. There may be new bugs and vulnerabilities.

Ways to ameliorate the problem:

  • Encourage and help with automated tests
  • Have a trusted third party certify updates
  • Discourage library providers who lack the resources to make trustworthy upgrades

Lack of Auto-Upgrade

The reach of automated vulnerability scanning and patching is probably still pretty low, at a guess.

Vendored (copied and pasted) code is hard to scan or upgrade. Not all languages have high-quality scanning and upgrading. The CI/CD infrastructure for automated scanning and patching is relatively new. Package repositories like Maven lack facilities to force upgrades.


  1. Study improvements to vendored code detection and upgrade
  2. Identify needless gaps in tooling. For example, improve Dependabot availability in Gitea.
  3. Collaborate with package repositories on forced upgrades (or discouragement of known-bad versions)

Vulnerability Fatigue

Developers may be skeptical of vulnerability reports. There is a never-ending stream of announcements, but the daily impact is low.

Vulnerabilities may be in libraries that aren't used in production. Vulnerable open source dependencies: counting those that matter found that "about 20% of the dependencies affected by a known vulnerability are not deployed, and therefore, they do not represent a danger to the analyzed library because they cannot be exploited in practice." Identifying whether a dependency is one of these can take a considerable amount of work.

To ameliorate this problem, security tooling can improve detection of which risks are not a factor in production.

Another source of fatigue is inflation. Developers get cynical about new vulnerability reports when they have ignored old ones without suffering harm.

To ameliorate this problem, there could be checks and limits on new reports. A report and patch should be accompanied by a score from the Common Vulnerability Scoring System Version 3.1 Calculator.

Structural Improvements to ERC-1155 Metadata

NFT metadata could easily be simpler to code, faster to load, less bug-prone, and easier to understand than with current specs. See example at the bottom. To comment, use GitHub Discussions.

ERC-1155 metadata has bits that are clumsy and inefficient.

  1. The decimals feature mixes presentation with data. ("The number of decimal places that the token amount should display - e.g. 18, means to divide the token amount by 1000000000000000000 to get its user representation"). This feature is a product design choice for front end developers. It's irrelevant to a contract and it relies on ultra-pricey on-chain real estate.

  2. The {id} interpolation feature violates the HATEOAS constraint of REST. The feature is defined as: "If the string {id} exists in any JSON value, it MUST be replaced with the actual token ID". Well designed APIs should use literal URIs generated by the servers that are generating the metadata JSON. (I bet the interpolation feature is not necessary.)

  3. The {id} interpolation feature reinvents the concept of server-side programming, like PHP. I doubt this was intentional. I think the data format was intended to be used within Solidity, and accidentally got incorporated into a new context.

  4. Localization support mixes non-localized data with localized data, has a weird extra field for a default locale, and requires a URI to be fetched for each locale. If locale-specific strings were inline, consuming these files would be faster and the code would be a simpler.

  5. Locales are defined by reference to, but this is not a list of locales, it is an organization that shepherds lists of locales.

  6. The example JSON in the published EIP has an obvious bug:

    "image": "https:\/\/\/your-bucket\/images\/{id}.png",

This is simply wrong. A ‘/’ character does not need to be escaped in JSON, and the resulting escaped strings are not legal URIs. The example value should be:

    "image": "{id}.png",
  1. There is no way to map from one of these external JSON documents to the token that it is annotating, so there is no way to know if they can be deleted except by searching every NFT that ever existed.

A future spec would:

  1. Nuke the decimals feature
  2. Nuke {id} interpolation
  3. Put localized data inline
  4. Separate localized and non-localized fields
  5. Eliminate the default locale - this belongs in the user-agent
  6. Fix the example data
  7. Require a locale name to be a subtag in

For the purposes of robustness, I'd also like to have:

  1. Ability to map from the metadata back to the token, so NFTs don't get hooked up to the wrong metadata. This requires a token ID in the JSON.

New and refactored example:

  "imageLink": "",
  "locales": {
    "en": {
      "name": "Advertising Space",
      "description": "Each token represents a unique ad space in the city."
    "es": {
      "name": "Espacio Publicitario",
      "description": "Cada token representa un espacio publicitario único en la ciudad."
    "fr ": {
      "name": "Espace Publicitaire",
      "description": "Chaque jeton représente un espace publicitaire unique dans la ville."
  "tokenID": "0x12f28e2106ce8fd8464885b80ea865e"

For comparison, see

Future topics:

  • I haven't figured out the properties object, which is a can of worms.
  • If the URI in an ERC1155 ERC1155Metadata_URI is IPFS, it is useless unless it is mutable, and it is only mutable if it is IPNS. Therefore, IPFS URIs with a non-IPNS path should be strongly discouraged.
  • Review for best practices
  • Much of the above is not related to metadata. It is about any sort of mutable data with a 1:1 relationship to an on-chain entity.

OSS Contribution Log: Blog on Logs merged into OWASP

I have had a PR merged into OWASP for the first time, a new Attacks On Logs section in the Logging Cheat Sheet. Given how much trouble it can be to get a PR merged into a new project, it's good to get a win.

This grew out of the Blog On Logs entry here.

HTML Should Support Markdown. Seriously.

Markdown has massive adoption. It clearly meets a need. The cost of HTML's power is verbosity, and sometimes that's the wrong tradeoff:

  • More typing. Writing HTML is slow.
  • More visual noise. Reading HTML is hard.

Browsers should support Markdown natively. The syntax should be part of HTML. There should be no need for a shim to translate.

This is very practical:

  • There is no Markdown syntax that can't be represented in HTML.
  • Markdown-to-HTML conversion is easy to implement.
  • Security risks are low.

The only non-trivial task is enabling CSS, which would require a canonical DOM representation of Markdown.

To the standards-mobile! This is a task for the HTML WG. I searched the mailing list and (surprizingly) didn't find discussion.

If you like this idea, all you have to do is discuss it in social media:

Blog on Logs

I am brainstorming security requirements for system logging. Can you think of others? Are some of these too lame to bother with? Do you know of specific attacks that might be relevant?

You can reply using an issue or email.

(Update Feb 21: This is documented by OWASP as Log Injection and by CWE as CWE-117. That documentation includes well-defined threat models).


Who should be able to read what? A confidentiality attack enables an unauthorized party to access sensitive information stored in logs.

  1. Logs contain PII of users. Attackers gather PII, then either release it or use it as a stepping stone for futher attacks on those users.
  2. Logs contain technical secrets such as passwords. Attackers use it as a stepping stone for deeper attacks.


Which information should be modifiable by whom?

  1. An attacker with read access to a log uses it to exfiltrate secrets.
  2. An attack leverages logs to connect with exploitable facets of logging platforms, such as sending in a payload over syslog in order to cause an out-of-bounds write.


What downtime is acceptable?

  1. An attacker floods log files in order to exhaust disk space available for non-logging facets of system functioning. For example, the same disk used for log files might be used for SQL storage of application data.
  2. An attacker floods log files in order to exhaust disk space available for further logging.
  3. An attacker uses one log entry to destroy other log entries.
  4. An attacker leverages poor performance of logging code to reduce application performance


Who is responsible for harm?

  1. An attacker prevent writes in order to cover their tracks.
  2. An attacker prevent damages the log in order to cover their tracks.
  3. An attacker causes the wrong identity to be logged in order to conceal the responsible party.

Liz Cheney's Heel-Face Turn

Cheney: I Do Not Recognize Those In My Party Who Have Abandoned The Constitution To Embrace Donald Trump

That seems familiar. Could it be the The heel-face turn?

When a bad guy turns good. The term "Heel Face Turn" comes from Professional Wrestling, in which an evil wrestler (a "heel") sometimes has a change of heart and becomes good, thereby becoming a "babyface". Magazines and other promotional material from the various wrestling leagues comment on various wrestlers' changes in alignment nearly as frequently as they cover events in the ring themselves.

That depends on who you ask:

The nature of Heel-Face Turn and Face–Heel Turn is subjective (one person's "seeing the light" is another person's "heartless betrayal or fall" depending on what group the individual is going to or leaving).

What do the other members of the league of supervillains think?

Republicans rebuke Liz Cheney in unprecedented moves

Oops. Maybe she has her tropes mixed up and thinks she's in one that ends better for her character.

In movies with more than one supervillain, it's usually only the villain that acts as the Big Bad that perishes; the lesser ones either are captured, reform, or return as the Big Bad in the sequel. --(Superhero Movie Villains Die)

To get a badge

Two years ago I did a lot of work related to badging (Example) using the Open Badges 2.0 standard. At the time I had little intuition about the value. Yesterday I got a certificate for completing a Linux Foundation course. It was surprisingly satisfying, so much so that I added it to my LinkedIn profile.

When I took the course, it was partly for the learning and partly for the badge. I want to be able to position myself as a subject matter expert, and both the learning and the credential are useful. The desire to acquire the badge validated my earlier assumption that badges do lead to action.

This badge does not use Open Badges 2.0 as far as I can tell. That standard appears to be stone cold dead. There was no mention of the standard anywhere in the process or visible code. What makes the badge valuable instead are the signatories and the branding. Hero text: "The Linux Foundation"; then, with facsimile signatures, "Clyde Seepersad, SVP & General Manager, Training and Certification The Linux Foundation" and "Kay Williams, Chair of the Governing Board Open Source Security Foundation (OpenSSF)."

The badges I was issuing wouldn't have been as effective. The signatories would have been missing. The underlying evaluation would be purely algorithmic.The branding would have been an unknown startup.

The badge I did receive is valuable enough that I paid for a course I could have taken for free, just because the certificate might be helpful for my career. Sharing a badge allows me to communicate that I have knowledge. Also, demonstrating completion of the coursework is relevant to The CII Best Practices badge, which has two tests that the certificate would influence:

  • The project MUST have at least one primary developer who knows how to design secure software.

  • At least one of the project's primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them.

You get what you measure. I wanted to show success on the metric, so I went and got the knowledge.

Diversity, equity, and inclusion in open source, and Americanism

If you're working on diversity, equity and inclusion in open source and you're American, don't assume America. The world is big. Don't assume race as understood in the US is the central issue.

Every part of the world has their own hierarchy of privilege.

Diversity and Inclusion in Nigeria:

The issue of diversity has world wide relevance. As Chairman Mao Tse-Tung said: “Let a thousand flowers bloom”. However I believe, like most issues, diversity adopts different meaning and flavor, depending on the locality you situate it.

Although English is the official language, more than half of the population do not understand and or speak formal English. Pidgin English is often a means of reaching out to a significant portion of the population, but it has limited appeal in the Northern part of the country. ... There are two dominant religious groups in Nigeria, namely Moslems and Christians. Unless the workforce reflects the two religious groupings, it stands the risk of being identified as ‘belonging’ to one groups or the other. It also runs the risk of offending members of the religious groups, sometimes out of sheer ignorance.

Castes in India:

Indian Caste System

Discrimination in China:

Although 56 different ethnic groups are officially recognized in China, the nation remains fairly homogenous, with over 90% of its citizens belonging to the Han Chinese group. People from different ethnic backgrounds, as well as foreigners, consequently stand out and may sometimes face discrimination and racism in China.

All you can safely assume is that the other people in your project are smarter than you and will flip the bozo bit if you fail to see beyond your privilege.

OSS Work Log

CHAOSS: created a draft metric model for security facets of sustainability.

XSPF: went to add Tess Gadwa and Evan Boehs to "about" page, made the changes, got ready to push, realize I did this already two months ago.

As a potential consumer of an open-source package, I must judge whether it is likely to introduce vulnerabilities or require updates in order to patch vulnerabilities.

Pwsafe: donated $20 to the maintainer, Rony Shapiro (GitHub).

This is the second donation I have made in roughly ten years of using his software. Then I went and stalked him on GitHub and Sourceforge. Just as I suspected, he's been patiently devoted for decades. I felt grateful and privileged.

Privacy Regulations for OSS Dev


This document is intended as a jumping-off point for people who need specifics about privacy regulations that affect open source development, whether in law or contracts. I can’t and shouldn’t offer legal advice. However, developers need to be able to educate themselves. This is a directory of resources.

This document is intended to evolve and grow. I invite you to contribute information on any jurisdictions you are familiar with.



Article 17 of International Covenant on Civil and Political Rights, 1966





United States


U.S. Code § 552a
(NIST) Guide to Protecting the Confidentiality of PII


OPPA 2003

CCPA 2018

Contract Law


Privacy Statement

Acceptable Use Policy

Linux Foundation

Telemetry Data Policy


Hacker News

Nobody Tells a Volunteer What To Do: Town Meetings and Open Source

The organizational structure of open source teams resembles town meetings - small-scale government with minimal hierarchy.

Huntington town meeting.jpg
(By Redjar, CC BY-SA 2.0, Link)

Wikipedia on town meetings:

A town meeting is a form of direct democracy in which most or all of the members of a community come together to legislate policy and budgets for local government. It is a town- or city-level meeting in which decisions are made, in contrast with town hall meetings held by state and national politicians to answer questions from their constituents, which have no decision-making power.

Town meetings have been used in portions of the United States, principally in New England, since the 17th century.

It's because open-source contributors are free in a way that employees aren't. They determine whether, when, and how to gift their time. If the project wants them - which is not always true - their voice will be valued from early on.

"Nobody puts baby in a corner":

No one with talent should be stopped from expressing it or showing it off. It’s about self-expression – about enabling anyone to be their best self, and a striking call against anyone who strives to keep people’s potential at bay.

The indigenous original-American critique of Europeans, per Graeber/Wengrow "Dawn of Everything", fits beautifully:

A “chief” had to persuade other members of the tribal council to get agreement on an action he thought was needed. He had to convince his fellows; he could not order them to obey. If he tried, tribal members were free to disobey.

Volunteer developers are free to disobey. Leaders must persuade rather than order.

At the same time, there are definite authorities, always.

Somebody owns admin privileges on the shared repo and site. Somebody knows the passwords. Somebody is recognized by outsiders as the voice and face. Somebody owns the domain.

Most importantly, somebody does a large enough proportion of work to dominate the shape of the project. And that goes to the most important force in open-source governance: the tyranny of volunteerism.

Nobody tells a volunteer what to do. A leader gives no orders. A leader helps a volunteer choose what to work on. A leader helps a volunteer learn how to be effective. A leader enables.

Robert's Rules of Order are often used to structure meetings:

Robert's Rules is the most widely used manual of parliamentary procedure in the United States. It governs the meetings of a diverse range of organizations—including church groups, county commissions, homeowners associations, nonprofit associations, professional societies, school boards, and trade unions—that have adopted it as their parliamentary authority.

They're valuable because they enable structure while accommodating widely varying social backgrounds:

A U.S. Army officer, Henry Martyn Robert (1837–1923) ... found San Francisco in the mid-to-late 19th century to be a chaotic place where meetings of any kind tended to be tumultuous, with little consistency of procedure and with people of many nationalities and traditions thrown together.

That "people of many nationalities and traditions thrown together" bit is the key. It fits open source perfectly.

People new to open source often find the pace of meetings maddening. It can be hard to know who, if anyone, is running them. Unlike a corporate environment, there are long pauses and uncomfortable silences. But if you are comfortable with silence, the gaps in such meetings can be very hard working.

Silence serves to draw in contributors. Whereas in a corporate meeting the highest-paid person does most of the talking, in an open-source meeting the leaders are those giving away the most labor. Knowledge and engagement are the coin. Silence serves to draw in comments from those who usually engage less. It sells them on contributing more. By voicing opinions they offer labor.

Silence also disrupts formal hierarchy. In a corporate meeting, the amount of talking each person gets to do corresponds with their salary.

Silence discourages overtalkers. It encourages listening. It makes time to contemplate what has already been said.

Quakerism - another historical Americanism - is relevant.

Quaker weddings are conducted similarly to regular Quaker meetings for worship, primarily in silence and without an officiant or a rigid program of events, and therefore differ greatly from traditional Western weddings.

The attendees gather for silent worship, often with the couple sitting in front of the meeting (this may depend on the layout of the particular Friends meeting house). Out of the silence, the couple will exchange what the Philadelphia Yearly Meeting describes as "promises",[3] and Britain Yearly Meeting describes as "declarations" with each other. The promises are short, simple, and egalitarian, and can vary between different regions and meetings.

Practices rooted in open government are an awkward fit for commercial open-source, such as COSS, OSPOs and Inner Source. Should meetings with commercial projects temporarily adopt open government? Can they?

Maybe commercial open source can thrive without open government. Maybe not. The person who pays the bills will have an outsize influence that can destroy the group's output. For a business to truly benefit from open sourcing, it must create social dynamics like a town meeting.

Comment on this:

Link Dump 1/17/2022

In the spirit of, here are some links I wanted to save without taking action and that might be useful to you as well as me. Web Outside of Browsers

a collection of applications able to interact with websites, without requiring the user to open them in a browser. It also provides well-defined APIs to talk to websites lacking one. Helping FOSS projects be more successful through clearly defined project data.

ClearlyDefined and our parent organization, the Open Source Initiative, are on a mission to help FOSS projects thrive by being, well, clearly defined. Lack of clarity around licenses and security vulnerabilities reduces engagement — that means fewer users, fewer contributors and a smaller community. Our proprietary technology enables us to find embedded open source snippets in your software during build time.

This would be useful as part of an SBOM.

Community CRM Runbook a tool that provides data-based insights into your community's health

It aggregates disparate data pulled from sources such as GitHub, Slack, Twitter providing a unified view of your members. Community managers and developer relations professionals log and manage all their interactions with the members capturing keeping information from their entire teams. This doc summarizes best practices identified by some community CRM users.