Governance

[iamwillbar]

As purl adoption increases, and others consider purl adoption, there is a desire for governance of the project to be more clearly defined. At the current size of the project this governance could be pretty lightweight, but even that would give adopters confidence.

@royaljust from GitHub published an article on Minimal Viable Governance (MVG) that we could use as a baseline:
https://github.blog/2021-07-22-minimum-viable-governance-lightweight-community-structure-foss-projects/

Example documents are here:
https://github.com/github/MVG

To implement this, we'd:

• Create a technical steering committee (we could start with the 5 org owners if they agree).
• Create a charter which the steering committee would vote to adopt.
  • Mission (we can derive this from the content we already have)
  • Decision making process (MVG has a proposed lightweight starting one).
  • Trademark policy.
  • Anti-trust policy.
  • Code of conduct (already in place).
• Add the necessary files to the org's repositories.

If there's no objection to MVG as a starting point, I'm happy to pull together the files and create pull requests that the current org owners can review.

[pombredanne]

@iamwillbar Thanks for bringing this up. Would not antitrust policies and trademark policies likely be overkill at this stage?

[torgo]

Hi @iamwillbar thanks this has been on my mind so I'm glad to see someone else has been thinking about it as well. I recognise this might be opening a can of worms but I'd like to see this effort being run under a specification license such as https://github.com/CommunitySpecification/Community_Specification as well.

[pombredanne]

@torgo Thanks for chiming in! Can you articulate your concerns with the current license?

[torgo]

The issue is that the current license is an open source license which is intended for software. Specification licenses generally are better suited towards specifications. The Readme on the Community Spec says it better than I could. For context, I'm used to working in W3C under the W3C Patent Policy and royalty-free license. I don't think we need a heavy weight process like that. But something light-weight like the Community Specification license I linked above or the w3c version that they use for Community Groups might make sense.

[torgo]

For further context, I'm working for Snyk. We are a consumer and user of the PURL spec.

[jlb-bb]

Efforts like CycloneDX and SPDX are referencing PURL. Has it been considered to move PURL under an OWASP or LF umbrella?

[stevespringett]

@jlb-bb the contents of all repos in the purl GitHub org meet all the criteria for an OWASP project, if that's something the group wants to do.

However, moving it under a foundation isn't automatically going to provide the needed governance. Both CycloneDX and SPDX that you reference, have defined their own governance models, which is what we're trying to do here. A foundation would provide certain protections to the project.

[pombredanne]

Efforts like CycloneDX and SPDX are referencing PURL. Has it been considered to move PURL under an OWASP or LF umbrella?

I am not opposed to this on principle, but can you articulate what would be the benefits?

These are also two rather different organizations: AFAIK OWASP is a 501(c)3 non-profit (charity) while the Linux Foundation is a 501(c)6 corporate business league and their projects are owned by an LLC corporation.

[jlb-bb]

Efforts like CycloneDX and SPDX are referencing PURL. Has it been considered to move PURL under an OWASP or LF umbrella?

I believe the goal of PURL is to be adopted by as many "standards" as possible, at least any/most/key standard(s) that wish(es) to reference or locate a software component. I will be honest: I don't know what some of these standards require when it comes to referencing "outside" work. Some organizations managing standards may be concerned with patent policies (touched upon by @torgo). Others may be concerned with continuity, etc. To guarantee adoption, it is best to ensure that the PURL specification meets the adoption policies of the standards it wishes to be referenced by?

[torgo]

To guarantee adoption, it is best to ensure that the PURL specification meets the adoption policies of the standards it wishes to be referenced by?

I am participating in some Open SSF (Linux Foundation) work streams that make use of PURL which is what drove my original comment. I believe that adoption of a license such as the Community Specification one would tick that box. FWIW I think that apart from the license the “minimal viable governance” approach is a good one, rather than “bringing the spec” to a more heavy-weight org at this time.

[coderpatros]

Efforts like CycloneDX and SPDX are referencing PURL. Has it been considered to move PURL under an OWASP or LF umbrella?

I am not opposed to this on principle, but can you articulate what would be the benefits?

These are also two rather different organizations: AFAIK OWASP is a 501(c)3 non-profit (charity) while the Linux Foundation is a 501(c)6 corporate business league and their projects are owned by an LLC corporation.

They are two very different organisations.

IMHO, the main benefit for the project joining a foundation is to help with project continuity should something happen to the maintainers. There is also some additional credibility that comes along with that too. And I think OWASP would be a good fit for the project.

But, as @stevespringett has pointed out, it doesn't solve project governance.

[iamwillbar]

@pombredanne can we separate the decision of foundation from the decision of governance?

Having a simple governance process in place would make the implicit explicit and give people depending on the project more confidence on the project's longevity.

If in the future the project moves under a foundation then the governance could always be adjusted.

[coderpatros]

+1 to @iamwillbar

And, IMHO, it would be best to have defined project governance in place before any decision to join a foundation is made. That's a significant decision for an OSS project, and its community.

[iamwillbar]

Bringing this back to the surface, what I'll do is I'll go ahead and create a PR with the proposed governance documents, and we can discuss specific concerns with the proposed governance in that PR.

[torgo]

Hi @iamwillbar just a gentle prompt on this. :) I'm happy to help out. I'd like to reiterate my concern regarding the use of an appropriate license. I'd also like to channel some of the conversations we've been having in my employer regarding versioning of the spec.

[torgo]

Pinging this issue again. Has there been any work on these governance issues that could be surfaced here? @iamwillbar @pombredanne

[dlorenc]

Is this project still maintained? There are quite a few PRs and issues waiting for attention, and the lack of clear governance makes it hard to understand if this is working as intended.

[pombredanne]

@dlorenc this is maintained, there are indeed a few PR and issues that need attention alright. This is a spec, so this is usually a good idea to evolve things not too briskly. Help is much welcomed in all cases!

[DennisClark]

Regarding a spec license, I think that the Community-Spec-1.0 license would be quite suitable.
See https://scancode-licensedb.aboutcode.org/csl-1.0.html

[sschuberth]

Ping @seabass-labrax who told me at PackagingCon that he'd be willing to help here.

[jhutchings1]

I just finished attending the Linux Foundation's Open Source Summit this week, and package URL was very well represented in both the formal talks, as well as the hallway track. Unfortunately, a number of people mentioned how PRs and discussions often stall out in this repository. One person even mentioned how they were looking to take a dependency on my githubactions PR, but were worried about potential changes because it has not been approved after 9 months. The much-anticipated version range PR is even older at 2.5 years old.

I think I speak for many of us when I say that we love the spec, and we love the effort you've put into it already, but I worry that the governance isn't meeting the community's needs. @stevespringett @pombredanne have you given thought to donating this spec to a foundation so that a committee could ensure continued momentum on the evolution of it?

[stevespringett]

PURL, VERS, and PURL types are in scope for Ecma TC54-TG2, which we're hoping to establish here soon. The scope and programme of work is currently being drafted in response to #295. TG2 will prepare PURL itself and VERS for standardization, as well as to maintain PURL types.