OSSelot collaboration on legal reviews of community packages
Project Description
Legal reviews have been a quite painful part of our development process. The current situation in Factory waits for legaldb for a limited amount of time and simply proceeds further if the review is not "approved" within a few hours.
Leap currently waits for legal review to be closed (may take weeks), or manually skipped. We typically contact our legal with ask to review specific requests on a weekly basis.
The goal is to improve our best effort on reviews in openSUSE, and ideally "shorten" the time of legal review of our packages.
Project OSSelot and related work on legal reviews seem to be funded by donations to OSADL (based in Germany). The project seems to use fossology underneath.
I highly recomemnd to start by watching OSSelot videos to get some idea about how their process and results look like. The last one seems to be closest to what I've seen in the Open Chain webinar.
GitHub repository of curated data
This project has two parts. Offloading our legal team, where possible, and contributing back.
Goal for this Hackweek
Contributing back results of our reviews Being a good Open Source Community Citizen and publicly sharing results of our legal reviews of community packages.
Offloading reviews of our community packages. There I can see extension of our existing current process. And extending our legal bot to talk to fossology/OSSelot.
An example could be Let's wait for legaldb for n-hours (currently 1-2h), if the review is still open then let's submit it to OSSelot. I see it as a much better alternative to e.g. lkocman skipping the review and taking the change in, in case that review was not closed for days/weeks.
Resources
We could use somebody who has experience with our legal tooling https://github.com/openSUSE/cavil and could help us export data from legaldb.suse.de to https://github.com/Open-Source-Compliance](https://github.com/Open-Source-Compliance/package-analysis/tree/main/analysed-packages)
A person who could tweak our existing legal bot to submit requests to fossology/osselot
This project is part of:
Hack Week 22
Activity
Comments
-
almost 3 years ago by lkocman | Reply
** An agreed first step from our call with Christopher from our legal team would be to compare our cavil report with the fossology report. Sebastian and Christopher recommended to start with comparing results of openssl**
I'd recommend filing an OSSelot project issue containing our review data (perhaps stripped from the SUSE's RISK assestment) and have a discussion about next steps.
*Notes: *
What's interesting for us is the SPDX license mapping to files, we're still using mappings from before the spdx time. What's interesting to our SUSE legal is what are the criteria for rejection on the OSSelot side. I did ask and we do not have any "strategy" or "rules" rejection documented publically.
I'm not sure if OSSelot team would be willing to work on our reviews to the level that we'd expect (to be clarified, see my note about rejection above), but having these reports public e.g. in a pull request, opens a way for volunteers with legal license background to contribute and offload SUSE legal team on community reviews.
-
almost 3 years ago by lkocman | Reply
Another action item from Sebastian:
One more thing for hack week, you could take a look at a rejected review, maybe there is something they have in their data that matches (search https://legaldb.suse.de/reviews/recent for unacceptable)
There were 11 rejected reviews in the past 3 months
Similar Projects
Create a page with all devel:languages:perl packages and their versions by tinita
Description
Perl projects now live in git: https://src.opensuse.org/perl
It would be useful to have an easy way to check which version of which perl module is in devel:languages:perl. Also we have meta overrides and patches for various modules, and it would be good to have them at a central place, so it is easier to lookup, and we can share with other vendors.
I did some initial data dump here a while ago: https://github.com/perlpunk/cpan-meta
But I never had the time to automate this.
I can also use the data to check if there are necessary updates (currently it uses data from download.opensuse.org, so there is some delay and it depends on building).
Goals
- Have a script that updates a central repository (e.g.
https://src.opensuse.org/perl/_metadata) with metadata by looking at https://src.opensuse.org/perl/_ObsPrj (check if there are any changes from the last run) - Create a HTML page with the list of packages (use Javascript and some table library to make it easily searchable)
Resources
Update M2Crypto by mcepl
There are couple of projects I work on, which need my attention and putting them to shape:
Goal for this Hackweek
- Put M2Crypto into better shape (most issues closed, all pull requests processed)
- More fun to learn jujutsu
- Play more with Gemini, how much it help (or not).
- Perhaps, also (just slightly related), help to fix vis to work with LuaJIT, particularly to make vis-lspc working.
Enhance git-sha-verify: A tool to checkout validated git hashes by gpathak
Description
git-sha-verify is a simple shell utility to verify and checkout trusted git commits signed using GPG key. This tool helps ensure that only authorized or validated commit hashes are checked out from a git repository, supporting better code integrity and security within the workflow.
Supports:
- Verifying commit authenticity signed using gpg key
- Checking out trusted commits
Ideal for teams and projects where the integrity of git history is crucial.
Goals
A minimal python code of the shell script exists as a pull request.
The goal of this hackweek is to:
- Add more unit tests
- Make the python code modular
- Add code coverage if possible
Resources
- Link to GitHub Repository: https://github.com/openSUSE/git-sha-verify
Bring to Cockpit + System Roles capabilities from YAST by miguelpc
Bring to Cockpit + System Roles features from YAST
Cockpit and System Roles have been added to SLES 16 There are several capabilities in YAST that are not yet present in Cockpit and System Roles We will follow the principle of "automate first, UI later" being System Roles the automation component and Cockpit the UI one.
Goals
The idea is to implement service configuration in System Roles and then add an UI to manage these in Cockpit. For some capabilities it will be required to have an specific Cockpit Module as they will interact with a reasource already configured.
Resources
A plan on capabilities missing and suggested implementation is available here: https://docs.google.com/spreadsheets/d/1ZhX-Ip9MKJNeKSYV3bSZG4Qc5giuY7XSV0U61Ecu9lo/edit
Linux System Roles: https://linux-system-roles.github.io/
Improve chore and screen time doc generator script `wochenplaner` by gniebler
Description
I wrote a little Python script to generate PDF docs, which can be used to track daily chore completion and screen time usage for several people, with one page per person/week.
I named this script wochenplaner and have been using it for a few months now.
It needs some improvements and adjustments in how the screen time should be tracked and how chores are displayed.
Goals
- Fix chore field separation lines
- Change screen time tracking logic from "global" (week-long) to daily subtraction and weekly addition of remainders (more intuitive than current "weekly time budget method)
- Add logic to fill in chore fields/lines, ideally with pictures, falling back to text.
Resources
tbd (Gitlab repo)
Improve/rework household chore tracker `chorazon` by gniebler
Description
I wrote a household chore tracker named chorazon, which is meant to be deployed as a web application in the household's local network.
It features the ability to set up different (so far only weekly) schedules per task and per person, where tasks may span several days.
There are "tokens", which can be collected by users. Tasks can (and usually will) have rewards configured where they yield a certain amount of tokens. The idea is that they can later be redeemed for (surprise) gifts, but this is not implemented yet. (So right now one needs to edit the DB manually to subtract tokens when they're redeemed.)
Days are not rolled over automatically, to allow for task completion control.
We used it in my household for several months, with mixed success. There are many limitations in the system that would warrant a revisit.
It's written using the Pyramid Python framework with URL traversal, ZODB as the data store and Web Components for the frontend.
Goals
- Add admin screens for users, tasks and schedules
- Add models, pages etc. to allow redeeming tokens for gifts/surprises
- …?
Resources
tbd (Gitlab repo)