package-url / purl-spec

A minimal specification for purl aka. a package "mostly universal" URL, join the discussion at https://gitter.im/package-url/Lobby
https://github.com/package-url/purl-spec
Other
699 stars 161 forks source link

Governance #190

Open iamwillbar opened 2 years ago

iamwillbar commented 2 years ago

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:

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 commented 2 years ago

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

torgo commented 2 years ago

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 commented 2 years ago

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

torgo commented 2 years ago

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 commented 2 years ago

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

jlb-bb commented 2 years ago

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

stevespringett commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

+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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

dlorenc commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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

jhutchings1 commented 7 months ago

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 commented 7 months ago

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.

johnmhoran commented 1 month ago

Hi all. I'm affiliated with nexB and AboutCode, helping @pombredanne with the purl standardization process, and have a few ideas on how we could facilitate the process:

Feedback is welcome and encouraged on all of these suggestions (including timezone constraints and preferences for a community call).

pombredanne commented 1 month ago

@johnmhoran I invited you to join. @oliverchang same, you had expressed interest in helping with this process

Anyone else?

pombredanne commented 1 month ago

@jkowalleck You also expressed interest: invite sent!

johnmhoran commented 1 month ago

Hi all. I've uploaded my latest .xlsx re open issues and PRs as a Google Sheet, available here: https://docs.google.com/spreadsheets/d/1H2QAcADLaMNgcR5BMK7bQxzH5D3X-SdO/edit?gid=1683448428#gid=1683448428

oliverchang commented 1 month ago

@oliverchang same, you had expressed interest in helping with this process

Thanks for thinking of me! Which invite exactly is this?