- opensource-wg - mailman.ripe.net

Cisco ASA 5516-X Firewall (Open Source) Console Bootup Messages and Show Version
by Turritopsis Dohrnii Teo En Ming 18 Mar '24

18 Mar '24

Subject: Cisco ASA 5516-X Firewall (Open Source) Console Bootup Messages and Show Version Good day from Singapore, I have bought this refurbished/second hand/used Cisco ASA 5516-X firewall with FirePOWER Services for SGD$100 at Bukit Panjang Ring Road on 17 Mar 2024 Sunday at about 8.30 PM Singapore Time. Cisco ASA firewalls use open source software. Console Output Below ===================== Rom image verified correctly Cisco Systems ROMMON, Version 1.1.8, RELEASE SOFTWARE Copyright (c) 1994-2015 by Cisco Systems, Inc. Compiled Thu 06/18/2015 12:15:56.43 by builders Current image running: Boot ROM0 Last reset cause: PowerOn DIMM Slot 0 : Present DIMM Slot 1 : Present Platform ASA5516 with 8192 Mbytes of main memory MAC Address: 70:70:8b:67:c9:64 Use BREAK or ESC to interrupt boot. Use SPACE to begin boot immediately. Located '.boot_string' @ cluster 841081. # Attempt autoboot: "boot disk0:" Located 'asa971-4-lfbff-k8.SPA' @ cluster 11. ##################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################### LFBFF signature verified. INIT: version 2.88 booting Starting udev Configuring network interfaces... done. Populating dev cache dosfsck 2.11, 12 Mar 2005, FAT32, LFN There are differences between boot sector and its backup. Differences: (offset:original/backup) 65:01/00 Not automatically fixing this. Starting check/repair pass. Starting verification pass. /dev/sdb1: 116 files, 820003/1798211 clusters dosfsck(/dev/sdb1) returned 0 Mounting /dev/sdb1 IO Memory Nodes: 1 IO Memory Per Node: 499122176 bytes Global Reserve Memory Per Node: 314572800 bytes Nodes=1 LCMB: got 499122176 bytes on numa-id=0, phys=0x1b1400000, virt=0x2aaaaae00000 LCMB: HEAP-CACHE POOL got 314572800 bytes on numa-id=0, virt=0x2aaac8a00000 Processor memory: 4379978902 Compiled on Fri 31-Mar-17 07:21 PDT by builders Total NICs found: 14 i354 rev03 Gigabit Ethernet @ irq255 dev 20 index 08 MAC: 7070.8b67.c964 ivshmem rev03 Backplane Data Interface @ index 09 MAC: 0000.0001.0002 en_vtun rev00 Backplane Control Interface @ index 10 MAC: 0000.0001.0001 en_vtun rev00 Backplane Int-Mgmt Interface @ index 11 MAC: 0000.0001.0003 en_vtun rev00 Backplane Ext-Mgmt Interface @ index 12 MAC: 0000.0000.0000 en_vtun rev00 Backplane Tap Interface @ index 13 MAC: 0000.0100.0001 Verify the activation-key, it might take a while... Running Permanent Activation Key: Licensed features for this platform: Maximum Physical Interfaces : Unlimited perpetual Maximum VLANs : 150 perpetual Inside Hosts : Unlimited perpetual Failover : Active/Active perpetual Encryption-DES : Enabled perpetual Encryption-3DES-AES : Enabled perpetual Security Contexts : 2 perpetual Carrier : Disabled perpetual AnyConnect Premium Peers : 4 perpetual AnyConnect Essentials : Disabled perpetual Other VPN Peers : 300 perpetual Total VPN Peers : 300 perpetual AnyConnect for Mobile : Disabled perpetual AnyConnect for Cisco VPN Phone : Disabled perpetual Advanced Endpoint Assessment : Disabled perpetual Shared License : Disabled perpetual Total TLS Proxy Sessions : 1000 perpetual Botnet Traffic Filter : Disabled perpetual Cluster : Enabled perpetual Cluster Members : 2 perpetual VPN Load Balancing : Enabled perpetual Encryption hardware device : Cisco ASA Crypto on-board accelerator (revision 0x1) Cisco Adaptive Security Appliance Software Version 9.7(1)4 ****************************** Warning ******************************* This product contains cryptographic features and is subject to United States and local country laws governing, import, export, transfer, and use. Delivery of Cisco cryptographic products does not imply third-party authority to import, export, distribute, or use encryption. Importers, exporters, distributors and users are responsible for compliance with U.S. and local country laws. By using this product you agree to comply with applicable laws and regulations. If you are unable to comply with U.S. and local laws, return the enclosed items immediately. A summary of U.S. laws governing Cisco cryptographic products may be found at: http://www.cisco.com/wwl/export/crypto/tool/stqrg.html If you require further assistance please contact us by sending email to export(a)cisco.com. ******************************* Warning ******************************* Cisco Adaptive Security Appliance Software, version 9.7 Copyright (c) 1996-2017 by Cisco Systems, Inc. For licenses and notices for open source software used in this product, please visit http://www.cisco.com/go/asa-opensource Restricted Rights Legend Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) of the Commercial Computer Software - Restricted Rights clause at FAR sec. 52.227-19 and subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS sec. 252.227-7013. Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134-1706 Reading from flash... !.. Cryptochecksum (unchanged): e97ddf36 72cca0b4 515230d7 74abffbe INFO: Power-On Self-Test in process. ....................................................................... INFO: Power-On Self-Test complete. INFO: Starting HW-DRBG health test... INFO: HW-DRBG health test passed. INFO: Starting SW-DRBG health test... INFO: SW-DRBG health test passed. Type help or '?' for a list of available commands. cisco> ************************************************************************************************* ************************************************************************************************* cisco> show version Cisco Adaptive Security Appliance Software Version 9.7(1)4 Firepower Extensible Operating System Version 2.1(1.66) Device Manager Version 7.7(1)151 Compiled on Fri 31-Mar-17 07:21 PDT by builders System image file is "disk0:/asa971-4-lfbff-k8.SPA" Config file at boot was "startup-config" cisco up 1 hour 1 min Hardware: ASA5516, 8192 MB RAM, CPU Atom C2000 series 2416 MHz, 1 CPU (8 cores) Internal ATA Compact Flash, 8000MB BIOS Flash M25P64 @ 0xfed01000, 16384KB Encryption hardware device : Cisco ASA Crypto on-board accelerator (revision 0x1) Number of accelerators: 1 1: Ext: GigabitEthernet1/1 : address is 7070.8b67.c965, irq 255 2: Ext: GigabitEthernet1/2 : address is 7070.8b67.c966, irq 255 3: Ext: GigabitEthernet1/3 : address is 7070.8b67.c967, irq 255 4: Ext: GigabitEthernet1/4 : address is 7070.8b67.c968, irq 255 5: Ext: GigabitEthernet1/5 : address is 7070.8b67.c969, irq 255 6: Ext: GigabitEthernet1/6 : address is 7070.8b67.c96a, irq 255 7: Ext: GigabitEthernet1/7 : address is 7070.8b67.c96b, irq 255 8: Ext: GigabitEthernet1/8 : address is 7070.8b67.c96c, irq 255 9: Int: Internal-Data1/1 : address is 7070.8b67.c964, irq 255 10: Int: Internal-Data1/2 : address is 0000.0001.0002, irq 0 11: Int: Internal-Control1/1 : address is 0000.0001.0001, irq 0 12: Int: Internal-Data1/3 : address is 0000.0001.0003, irq 0 13: Ext: Management1/1 : address is 7070.8b67.c964, irq 0 14: Int: Internal-Data1/4 : address is 0000.0100.0001, irq 0 Licensed features for this platform: Maximum Physical Interfaces : Unlimited perpetual Maximum VLANs : 150 perpetual Inside Hosts : Unlimited perpetual Failover : Active/Active perpetual Encryption-DES : Enabled perpetual Encryption-3DES-AES : Enabled perpetual Security Contexts : 2 perpetual Carrier : Disabled perpetual AnyConnect Premium Peers : 4 perpetual AnyConnect Essentials : Disabled perpetual Other VPN Peers : 300 perpetual Total VPN Peers : 300 perpetual AnyConnect for Mobile : Disabled perpetual AnyConnect for Cisco VPN Phone : Disabled perpetual Advanced Endpoint Assessment : Disabled perpetual Shared License : Disabled perpetual Total TLS Proxy Sessions : 1000 perpetual Botnet Traffic Filter : Disabled perpetual Cluster : Enabled perpetual Cluster Members : 2 perpetual VPN Load Balancing : Enabled perpetual Failover cluster licensed features for this platform: Maximum Physical Interfaces : Unlimited perpetual Maximum VLANs : 150 perpetual Inside Hosts : Unlimited perpetual Failover : Active/Active perpetual Encryption-DES : Enabled perpetual Encryption-3DES-AES : Enabled perpetual Security Contexts : 4 perpetual Carrier : Disabled perpetual AnyConnect Premium Peers : 8 perpetual AnyConnect Essentials : Disabled perpetual Other VPN Peers : 300 perpetual Total VPN Peers : 300 perpetual AnyConnect for Mobile : Disabled perpetual AnyConnect for Cisco VPN Phone : Disabled perpetual Advanced Endpoint Assessment : Disabled perpetual Shared License : Disabled perpetual Total TLS Proxy Sessions : 1000 perpetual Botnet Traffic Filter : Disabled perpetual Cluster : Enabled perpetual VPN Load Balancing : Enabled perpetual The Running Activation Key feature: 2000 TLS Proxy sessions exceed the limit on the platform, reduced to 1000 TLS Proxy sessions. Serial Number: JAD****00ZZ Running Permanent Activation Key: Configuration register is 0x1 Image type : Release Key Version : A Configuration has not been modified since last system restart. cisco> Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore

1 0

Ukrainian open source app for citizen's digital documents & government services
by Shane Kerr 14 Mar '24

14 Mar '24

Comrades in open source, This popped up on my radar today: https://opensource.diia.gov.ua/en.html It seems like a good initiative, and in general I think that governments have a duty to make source code available whenever possible. I checked the GitHub: https://github.com/diia-open-source/ And it looks like all of the code is under the EUPL, which is a nice copyleft license. However if you look at the main page there is a section titled Open Source Usage License, which takes you here: https://opensource.diia.gov.ua/documents/Public_licence.DOCX This license includes things like: 2.6. This License applies to the territory of all states of the world (except for the territories of states recognized by the Verkhovna Rada of Ukraine as aggressor states, states subject to sanctions in accordance with the Law of Ukraine "On Sanctions", states that are members of customs and military unions with such states). And also: 1.3.5. the Licensee – any person (except for persons of states recognized by the Verkhovna Rada of Ukraine as aggressor states, states subject to sanctions in accordance with the Law of Ukraine “On Sanctions”, states that are members of customs and military unions with such states) who voluntarily uses the Diia mobile application software under a public license; Such provisions would likely prevent the license from being considered free (as in freedom) by folks like the OSI. Honestly I'm not really sure where this second license is meant to apply, since the source code currently is under the EUPL which has no such restrictions. Anyway, I thought it was interesting! Cheers, -- Shane

1 0

Call for Open Source WG Presentations (RIPE88, Kraków, 20th -24th May, 2024)
by Marcos Sanz 13 Mar '24

13 Mar '24

Dear all, the next RIPE Meeting is around the corner - your chance to present about some interesting Open Source! Our wg meeting slot is allocated on Thursday, 23rd May 14h-15:30h local time. If you would like to give a presentation during the Open Source WG session, then please contact us (the WG chairs). In general, each talk is 15-30 mins including Q&A (depending on how much time is needed). If you have some idea and are not sure how/if you should present something, then feel free to contact us as well to discuss the idea! Remote presentations are also possible. As always, we are planning to reserve 30 mins again at the end of the WG session for lightning talks. These short 5..10(max) minute updates/talks are decided on the day before the WG session on a time/space available basis. No need to submit to us anything for these talks at this time. Thanks, Marcos, Martin, Sasha Your Open Source WG Chairs

1 0

Call for interviews on contributions and credit policy
by Valerie Aurora 13 Mar '24

13 Mar '24

Hi all, I'm working on an article for Linux Weekly News about the proposed contributions and credit policy (renamed from credit policy) that we have been working on for the past few months. As part of this article, I would like to include opinions and experiences from other folks about conflicts around contributions and/or credit on open source projects. Many of you had interesting and detailed feedback at RIPE 87, and I would like to share your experience and recommendations. If you want to participate, anonymously or on the record, please fill out this Google form: https://forms.gle/FJzAvy4MFjqViECv5 Thank you kindly, Valerie

1 0

Most popular open source firewall in the world
by Turritopsis Dohrnii Teo En Ming 02 Mar '24

02 Mar '24

Subject: Most popular open source firewall in the world Good day from Singapore, I am using pfsense community edition 2.7.2 firewall at home. Recently I asked ChatGPT. ChatGPT says pfsense is the singular most popular open source firewall in the world. Is pfsense really the most popular open source firewall in the world? If there is more than one, please provide a list of the most popular open source firewall(s) in the world as well. Preferably from well accredited sources. Thank you. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore

4 6

OFE: Standardisation and Open Source in the Age of Software Regulation
by Vesna Manojlovic 29 Feb '24

29 Feb '24

Series of events by OFE: Standardisation and Open Source in the Age of Software Regulation https://openforumeurope.org/event/ofe-lounge-2024-standardisation-and-open-… Today, 29. February at 18:00 CET : Session 2: The AI Act Location: https://meet.leadingbit.cloud/rooms/9cp-xb1-fb3-zbl/join Feel free to invite colleagues and friends who might be interested in the event series. This webinar series is organised under the umbrella of StandICT.eu 2026. The OFE Lounge 2024 seeks to bridge standardisation and open source organisations, creating a platform to discuss the changing dynamics of software development and ICT standardisation. Drawing from previous iterations of the OFE Lounge Series, as well as studies such as the JRC’s “The Relationship Between Open Source Software and Standard Setting” and OFE’s study “Standardisation and Open Source – Bringing them together” for the European Commission, this series aims to facilitate knowledge transfer between significant open source and standardisation entities, as well as the European Commission. For this iteration of the series, we will focus on the standardisation activities following new EU regulation with implications for software development, such as the Cyber Resilience Act and the AI Act. All sessions will adhere to the Chatham House Rule. Format The webinar series initiates on 22 February, at 18:00 CET, and spans over five weeks, culminating with a comprehensive wrap-up workshop. Each session will last 60 minutes and start with 2 individual 15-minute presentations by representative stakeholder organisations, putting forward their ideas on the role of open source in standardisation, and standardisation for open source, followed by a roughly 30-minute moderated Q&A. The last wrap-up workshop will last 2.5 hours. The series schedule and session descriptions are as follows: 22 February at 18:00 CET - Session 1: Kick-off session This initial session sets the stage for discussions on the regulatory landscape affecting software and the critical role of standardisation. It will cover complexities in software and software supply chains, challenges posed by the AI Act and CRA negotiations related to open source software (OSS), and the needs and expectations of policymakers. 29 February at 18:00 CET - Session 2: The AI Act An exploration of the AI Act and its implications for standardisation and open source, focusing on the ethics of AI and the significant role standards play in this evolving field. 7 March at 18:00 CET - Session 3: The Cyber Resilience Act This session will delve into the CRA, discussing the new requirements it introduces, guidance for compliance, and the perspectives of open source communities and standardisation bodies on what is needed from CRA standards in the software domain. 14 March at 18:00 CET - Session 4: To be announced 21 March at 16:30 CET - Session 5: Workshop to Conclude the Series A concluding workshop designed to bring together insights from the previous sessions. It aims to facilitate engaging discussions on stakeholder perspectives, the EC Strategy on OSS, the EU Standardisation strategy, procurement perspectives, industry groups, and findings from the latest research. -- Senior Community Builder, RIPE NCC https://labs.ripe.net/author/becha/

1 0

Hello!
by Patrick Masson 17 Feb '24

17 Feb '24

Hello list, I just discovered this list and thought I would send out an email to introduce myself (https://www.linkedin.com/in/patrick-masson-apereo) I am currently serving as the executive director at the Apereo Foundation (https://www.apereo.org/) a US based non-profit working to advance open source software in academic and research institutions. Apereo has several projects and members (colleges and universities) located in Europe and we commonly participate in a varsity of European free and open source communities and events. Looking forward to chatting with you all, Patrick -- | |||| | | || | | || | || | | || ||| | | | || | | || ||| || | || | | ||| | | | | || | Patrick Masson Executive Director Apereo Foundation 9450 SW Gemini Dr PMB 98572 Beaverton, OR 97008-7105 Mobile: +1 (970) 4-MASSON Website: www.apereo.org

4 7

See you at FOSDEM?
by tessel-ml＠nlnet.nl 02 Feb '24

02 Feb '24

Hi everyone, Hope to see you at FOSDEM. We (NLnet/NGI0 consortium) have made a list of talks and activities that are related to NGI Zero at FOSDEM, OFFDEM and Fringe. You can find it here: https://nlnet.nl/events/20240203/index.html. We also have a stand in Building K, where FSFE will also have one. Come by and hello! -- Kind regards, Tessel Renzenbrink Communication officer NLnet.nl

2 1

Fwd: Sovereign Tech Fund : FOSDEM, Challenges Round 2
by Vesna Manojlovic 01 Feb '24

01 Feb '24

FYI === Announcing New Investments Sovereign Tech Fund is starting 2024 with a bang and announcing several new open source infrastructure technologies on which the STF is commissioning work. We’re excited to support these maintainers and FOSS communities, and to continue strengthening the foundational software of our shared digital infrastructure. If you’d like to find out about these updates as they happen, you can find the Sovereign Tech Fund on Mastodon, (etc) https://mastodon.social/@sovtechfund Contribute Back Challenges Round 2 Five FOSS teams have been selected for the 2nd round of STF's Contribute Back Challenges! The projects are receiving a total of €858,560 for their work in the three challenge areas : https://www.sovereigntechfund.de/news/contribute-back-challenges-second-rou… - Improving FOSS Developer Tooling: conda-store, Haskell Cabal & Open Web Docs - Securing FOSS Software Production: Rusty SBOMs - FOSS Infrastructure Documentation: p5.js Documentation Organization & Accessibility Events: See you in Brussels! This week, several members of the STF team will be in Brussels. You can catch up with us at CHAOSSCon Europe (Tara) https://chaoss.community/chaosscon-2024-eu/ EU Open Source Policy Summit (Adriana, Fiona, Powen) https://summit.openforumeurope.org/ FOSDEM (Mirko, Tara, and Fiona) https://fosdem.org/2024/ https://b1sp4.r.ag.d.sendibm3.com/mk/mr/sh/1f8JAEjGcfF85y2ImB9lu0WDqg/Q5X0E…

1 0

OpenWrt One: Project Details and Involvement
by Luka Perkov 22 Jan '24

22 Jan '24

Dear RIPE Open Source WG community, I'm pleased to inform you about a new initiative involving OpenWrt, spearheaded by John Crispin. This project, named OpenWrt One, is focused on creating a specialized wireless networking device aimed at open source software enthusiasts. It emphasizes educational aspects, compliance with FOSS licenses, and a rich array of networking features. You can find out more in these threads: https://lists.openwrt.org/pipermail/openwrt-devel/2024-January/042018.html https://lists.openwrt.org/pipermail/openwrt-adm/2024-January/002479.html Additionally, a portion of the sales revenue from this device will directly support the OpenWrt project. For more detailed information and to participate in discussions related to this topic, please consider subscribing to the relevant OpenWrt mailing lists [1]. Take care, Luka [1] https://lists.openwrt.org/mailman/listinfo

1 0

Second draft: Credit policy for open source projects
by Valerie Aurora 22 Jan '24

22 Jan '24

Hi all, Thanks for the useful feedback on the first draft of the credit policy! Thank you especially to Maria, who wrote many useful additions, all of which are now integrated. My plan is to get one more round of comments on this within the OS wg, then do a public call for comments, then make an initial release. Please review the current version, included inline below and in the Google Docs link (suggestions for better co-editing tools welcome). In addition to Maria's contributions, I made one additional change to the document: a proposed credit and license section using Creative Commons Zero 1.0 Universal license: "This credit policy by RIPE NCC Open Source Working Group and lead authors Valerie Aurora, Maria Matějka (project BIRD, CZ.NIC), Martin Winter, and Marcos Sanz is marked with CC0 1.0. If you create a derivative work, we request but do not require that you voluntarily give credit to the above contributors." This is about reducing friction. The CC BY-SA 4.0 license would require crediting every person who ever contributed by name or risk legal problems, which often causes people to decide it is too much trouble to use. CC0 would allow people to use their judgement on who to credit, without worrying about legal requirements. As such, it is in the spirit of the credit policy itself. My personal view is that the kind of person adopting a credit policy will likely give credit voluntarily. Thoughts? https://docs.google.com/document/d/1A4PVQ8iAZFPWySxMdY-EYDArII3BrlK_t70Cek6… Valerie Credit policy for open source projects - working draft Introduction The problem: people disagree about credit for contributions Our solution: a written policy Scope of a credit policy Credit for this policy Real-world examples Policy structure Preamble options We welcome a broad range of contributions from as many contributors as possible We welcome contributions that do not need much work We accept outside contributions rarely We prioritize speed of development Only bug fixes welcome My personal project subject to my personal whims Our corporate project not open to outside contributions Our research project not open to outside contributions [YOUR PREAMBLE HERE] Credit assignment options Correcting mistakes in credit Reporting problems with credit Introduction The purpose of this document is to develop an example credit policy: a written description of how an open source software project gives credit for contributions. This project was created and led by many members of the RIPE NCC Open Source Working Group: https://www.ripe.net/participate/ripe/wg/active-wg/os The problem: people disagree about credit for contributions Open source software projects receive a wide variety of contributions from many different people and organizations. Each contributor has their own assumptions and expectations for what kind of credit contributions should receive. When there is a mismatch between the credit a contributor expects to get and what they actually get, both the project and the people around it suffer. This is an especially important problem for open source software because the main motivation for contributing is often recognition and credit; when people don't receive what they expect, they are less likely to contribute in the future. This also applies for upstreaming local changes. Even though the main motivation may seem to be some reduction of future maintenance costs, all the parties benefit from proper crediting, e.g. when some changes in the contributed code are proposed in future and consulting with the original authors is handy. Two concrete examples: How I got robbed of my first kernel contribution – Ariel Miculas Someone sends in a contribution that needs a little more work. The other contributors are too overworked to review the contribution. Some time later, another person fixes the same problem without ever seeing the first contribution. The first person says, "Hey, why did you rewrite my work without giving me credit?" Our solution: a written policy Our proposed solution to this problem is for each project to write down and publish a formal credit policy (or contribution policy, or anti-plagiarism policy - whatever name seems best). This policy describes what kind of credit and acknowledgement contributors can expect. It also serves as a guide for decision-making for project leaders when they run into more complex problems associated with credit. The end result is that contributors are more likely to contribute to projects with matching credit policies, and project leaders spend less time arguing with contributors or trying to decide how to handle edge cases. The example policy we are writing in this document includes a variety of different ways to assign credit, depending on the project's goals and priorities. Projects can copy parts of the example policy and edit as necessary, or create their own policies from scratch. Scope of a credit policy The policy should cover all types of contribution: documentation, code, tutorials, event organization, testing, design , etc. It should focus primarily on cases in which multiple people or organizations are collaborating on a contribution, when people disagree about who gets credit, and other situations in which credit is less clear. It does not attempt to resolve any legal issues around IP or copyright; that is the domain of contributor agreements, licenses, and other documents. Credit for this policy If you contributed to this policy, please add your name here. We will decide how to credit the contributors as we develop this policy. Valerie Aurora Maria Matějka (project BIRD, CZ.NIC) Martin Winter Marcos Sanz Fair warning: the most successful policies are often the ones with no attribution since people often reject them when their provenance is called out. Ironic, huh? Real-world examples Here are few examples of situations that a credit policy should address: Someone sends a first draft (of a document, code, HTML, etc.). A second person makes significant edits to it. Someone sends a first draft. Another person comments with ideas leading the original sender to incorporate them in the second draft. Someone sends a first draft. Another person entirely rewrites it from scratch. Someone sends a contribution. The contribution does not improve the project. Someone sends a contribution but does not complete the "sign-off" or other process step that the project requires. The first reminder goes unanswered for several days. Someone sends a first draft. It fixes a real problem but in a way that is unacceptable for inclusion. They do not respond or are unwilling to make the necessary changes for inclusion. Someone sends a contribution but no one else in the project notices. Later another person makes a similar contribution and gets credit for it. Someone sends a contribution which is actually valuable to the project but directly conflicts with other project plans and aligning it means to actually rewrite the contribution completely. Someone sends a somewhat useless contribution. When you look at their contribution history, you see them sending a lot of useless contributions to other projects. Someone sends a contribution that seems suspicious. When you look at their contribution history, they seem to have rewritten a lot of other people's contributions. Someone sends a lot of tiny separate trivial contributions. They aren't actually making much difference to the project, but if you accept them all it will look like they should have credit for half the project. Someone sends a contribution. For whatever reason, the contribution does not actually seem to be motivated by a desire to improve the project. Someone sends a contribution but a project leader hates the style. Someone sends a contribution and it seems kind of mean-spirited. Someone sends a complaint which gets ignored or rejected. Later, the maintainers find themselves fixing the subject of the complaint anyway. Policy structure The policy should consist of the following parts: Preamble describing the overall goals and philosophy of the project's credit policy High-level description of how credit is assigned for contributions List of specific situations with step-by-step instructions on what to do in each one How to contact the project if someone thinks that credit has not been given correctly Instructions for people implementing the credit policy, including what to do in difficult situations The last part does not need to be published but can be. Preamble options The preamble describes the overall philosophy of your project towards contributions: what kind of contributions you want to encourage, what kind of contributors you want participating, what your priorities are when it comes to different aspects of quality or productiveness. Your preamble should discourage the kind of contributions you don't want and encourage the kind of contributions you do want. Note: The more contributions you want to encourage, the more documentation you actually need. It’s hard to welcome a broad range of contributions with lack of programmer’s documentation and proper open future planning, including upfront disclosure of (or hosting public discussions on) architectural decisions, to guide the contributors even before they actually start working. Here are some possible preambles that prioritize different goals. We welcome a broad range of contributions from as many contributors as possible We encourage contributions from as many contributors as possible, and strive to make contributing easy and rewarding. We prefer to guide original contributors through the process of making necessary changes to any contributions, and reward mentoring and review. When a contribution is the combined effort of several people, we prefer to give primary credit to newer contributors. We give credit generously for all of the work that goes into making this project a success, including testing, review, debugging, mentoring, operations, documentation, and similar work. We welcome contributions that do not need much work We encourage contributions but our existing contributors have limited time to mentor or guide new contributors. When a contribution needs changes, existing contributors will usually make any necessary changes themselves rather than working with the original contributor to make the changes. However, we strive to give primary credit to the original contributor whenever possible. We especially encourage contributions that make it easier for new contributors to become productive without direct mentoring, such as documentation, tutorials, refactoring, tests, and similar. We accept outside contributions rarely Our priority is quality of contributions and architectural cohesion. We prefer contributions from existing contributors who are already familiar with our processes and standards, and are carrying out the architectural vision of our leaders. We do not mentor or guide new contributors. When existing contributors rewrite, reuse, or are inspired by contributions from new contributors, it is up to the existing contributor to decide how or if to credit the original author. We prioritize speed of development Our priority is speed of development. We reward contributors who send working contributions quickly. We prefer to give credit to the person who sends the first acceptable form of a contribution rather than the original contributor. Only bug fixes welcome [YOUR DRAFT HERE] My personal project subject to my personal whims [YOUR DRAFT HERE] Our corporate project not open to outside contributions [YOUR DRAFT HERE] Our research project not open to outside contributions [YOUR DRAFT HERE] [YOUR PREAMBLE HERE] Credit assignment options Here are a selection of possible rules for assigning credit. You should choose the ones that encourage the behavior you describe in your philosophy. For example, if you want to encourage new contributors, choose rules that give credit more generously to new contributors than existing ones. If you want existing contributors to have strong control over the project, choose rules that give credit more generously to people who edit or rewrite contributions. Note: don’t get too wrapped up in who “really wrote a contribution.” Most contributions are a collaborative effort by multiple people and it would be impossible to give credit to every single person who made a one line contribution to your project possible. Instead, focus on what behaviors you want to reward and which ones you want to discourage, and be creative about how you do that. If a contribution includes substantial work from multiple authors, we will give primary credit to the least experienced contributor. If we need to rewrite a contribution, we will give primary credit to the author of the first version and secondary credit to the person rewriting it. If we need to rewrite a contribution, we will give primary credit to the person rewriting it and secondary credit to the author of the first version. If we need to rewrite a contribution, we will work with the original author to make the necessary changes for as long as they respond in good faith and in a timely manner. In any case, the original author will get primary credit. The project leaders are the sole authority on who gets credit and will assign it to no one, to themselves, or to others as they see fit. All people and companies involved in the contribution get credits equally. If multiple contributors submit similar work, the accepted author gets primary credit and every other contributor, whose work was thus rejected, gets secondary credit. [YOUR SUGGESTION HERE] Please make it easy for us to accept and credit your contribution! Here are the steps to take to get the most credit for your work: [CHOOSE APPLICABLE] Include “Signed-off-by: [YOUR NAME]” Put your name into the AUTHORS file Agree to the CLA Follow the instructions in CONTRIBUTING Respond to requests for changes within N days Cooperate in good faith with our requests for changes If you do not want to make changes, please tell us as soon as possible [YOUR SUGGESTION HERE] If for some reasons you can’t or won’t make necessary changes to your contribution, we will [CHOOSE ONE OR MORE AND EDIT TO FIT] Reject your contribution and take no further action. Incorporate your original contribution as is, then make a second change with any edits. Incorporate your contribution along with any necessary edits with primary credit to the newest contributor, with a link in the change message to your original contribution on our mailing list or other archive of original contributions (e.g. a directory in the source code, a section of the wiki, etc.). If you did not [sign off, agree to the CLA, other necessary process step], we will rewrite from scratch and include a link to the original contribution in the change message. How we give credit: For commits to a repository, the primary author is the commit author. For reviews, editing, testing, debugging, or reporting directly related to a specific contribution, we add a line in the change message such as “Reviewed-by” or “Edited-by”. For contributions that are not specific to an individual change, such as hosting, DevOps, DevRel, issue curation, etc, we will add your name to [LIST AND LOCATION OF PUBLICATION]. To be added to this list, please [INSTRUCTIONS]. [Suggestion: include an option for extremely minor contributions.] [YOUR SUGGESTION HERE] We reserve the right to not grant credit when it seems detrimental to our project. For example, if someone requests credit to a name that is obscene or harmful, if they are spamming multiple projects with minor contributions, or if interacting with a contributor is demoralizing to other contributors. Correcting mistakes in credit Sometimes we make a mistake in how we give credit. In this project: [CHOOSE FROM FOLLOWING] Once credit has been given, we will not go back and correct it. We will correct mistakes in credit attribution for up to [TIME PERIOD] after credit has been given. We will correct mistakes in credit at any point. [YOUR SUGGESTIONS HERE] Reporting problems with credit If someone has not given credit correctly, please contact [CONTACT INFORMATION - COULD BE CODE OF CONDUCT COMMITTEE] and include any relevant information. [NAMES] will review your report and take any action they deem appropriate, including but not limited to updating the credit information, warning the person who did not follow the credit policy, no longer accepting their contributions, or forwarding the complaint to the community code of conduct committee. Credit and license This credit policy by RIPE NCC Open Source Working Group and lead authors Valerie Aurora, Maria Matějka (project BIRD, CZ.NIC), Martin Winter, and Marcos Sanz is marked with CC0 1.0. If you create a derivative work, we request but do not require that you voluntarily give credit to the above contributors.

2 2

Minutes of RIPE87 Open Source wg meeting
by Marcos Sanz 17 Jan '24

17 Jan '24

Dear all, The minutes of our last working group meeting are now online https://www.ripe.net/participate/ripe/wg/active-wg/os/minutes/open-source-wo rking-group-minutes-ripe-87 Thanks to Razvan Oprea for the note taking. Any errors or omissions on me to blame! Yours, Marcos

1 0

Welcome the new open source wg co-chair!
by Marcos Sanz 22 Dec '23

22 Dec '23

Dear working group, dear RIPE community, first of all, we'd like to say a big thank you to all three candidates. Based on the feedback for all the candidates, the expressions of support and the discussion afterwards on which voices to consider, we have decided on Sasha Romijn to join us as the 3rd working group chair. We know that some new individuals on this list will not agree, but we do believe we have decided based on what is best for the WG. After the announcement end of last week that we were prioritizing expressions of support from long-standing members, we have not heard any reason why this would be a bad procedure and we have got a lot of on-list and off-list feedback supporting it. Having said that, we will bring up the chair selection topic at the next RIPE meeting and welcome everyone to join us for that discussion. The last three weeks have showed that we might be needing clearer guidelines in the process. We would like to address this with the group in time before the next election in fall 2024. Now, please welcome to Sasha as a Co-Chair for the Open Source WG! Regards, Martin Winter & Marcos Sanz Open Source WG Chairs

7 6

Re: [opensource-wg] Call for support of co-chair candidates
by Ines Skelac 21 Dec '23

21 Dec '23

Dear Martin, Thank you for your quick response. It's important for me to clarify my position regarding the RIPE chair selection process, and equally important to receive responses to my points that remain unanswered. Firstly, with respect to Luka Perkov, our interactions have been within a professional context. It is through these professional interactions that I have been introduced to RIPE and its various activities on multiple occasions. Regarding the other candidates, I assure you that my vote was cast following a thorough and informed examination of their profiles and contributions. During my research, I observed an instance where an individual associated with RIPE used their official ripe.net email address to cast a vote. The deliberate choice of using a RIPE email implies a certain awareness of the influence it carries. This early vote, seemingly endorsed officially, subtly suggests a process that might appear, to the cautious observer, as conveniently arranged. When combined with the evolving narrative of whose votes count and whose don’t — as if the rules are being written and rewritten in real-time — it certainly raises eyebrows about the true consistency and impartiality of this process. In light of our commitment to transparency, I'm curious – will this vote be counted, or are we continuing to adapt the rules to fit the moment? In our dialogues, a recurrent issue is the cycle of new questions that emerge following my responses, often sidestepping the depth of the answers I've already provided. This pattern of continuously shifting focus hinders our ability to delve deeply and transparently into the core issues. Moreover, when discussions reach a significant point, they are frequently concluded with statements and conclusions like "you did not convince me," which serve more as conversation enders than as constructive contributions. Given this, will my points raised in the previous email be thoroughly addressed? The absence of a detailed response will be quite telling and, in itself, a significant answer, especially in light of the critical issues I have brought forward. To reiterate, my decision to participate in the voting was informed by a thorough understanding of RIPE, the Open Source Working Group, and the qualifications of all the candidates. I trust this message clarifies my position well. Considering the observations and discussions above, I am looking forward to your responses to these points, as well as to the unresolved topics I mentioned in my previous email. Clear answers to these concerns are to allow everyone within the community to contribute more effectively. Warm regards, Ines uto, 19. pro 2023. u 22:06 Martin Winter <mwinter(a)netdef.org> napisao je: > Ines, > > thanks for the introduction. However, I'm less concerned and about > your professional background and was actually asking on how you found > about the Open Source WG and the election going on. You mentioned that > you know Luka and trust him, but do you know the other candidates? I'm > concerned on people voting who did not take the time to look at all > the candidates and just pick a local friend. > > So again, if you think we should count your particular vote, then > please explain: > - How did you learn about the chair selection process? After all, the > email for the selection process was sent before you joined. > - How did you decide that your choice is better than the other > choices? After all you are new to this group and seem to be still > confused about it. (I take this from the mention of the number of > emails on the list. We mainly work on the meeting, so while it would > be nice to have a more active list, our main charter isn't the list. > Go and check out the RIPE websites for our mission on this (and other) > WG > > And if you would have attended the past RIPE or listened to the > recording, then you would probably better understand the selection > process. And yes, things were not done perfectly and I currently plan > to bring this up at the next WG meeting at the RIPE in spring 2024. > Attend the meeting and join in on the discussion on how to make the > selection better. > Also keep in mind, this is a chail selection process. And myself and > Marco (the existing chairs) did not publicly mention as I didn't want > to set an example for others to follow or influence. And yes, my first > choice didn't make it either. > > So far you did nothing to convince me - more to the opposite that I > have the feeling you try to avoid the answers to the questions. But > that's fair. And I don't expect you to open up to everyone, but you > try to make a point that your vote should count and I still haven't > heard an argument about why. > > But please stick around and join us at future RIPE meetings. You may > learn how we may not have fixed rules, but we decide mostly on what is > best for the community. (And you could learn why this helps) > > Regards, > Martin Winter > > > On Tue, Dec 19, 2023 at 2:17 PM Ines Skelac <ines.skelac(a)ffrz.hr> wrote: > > > > Dear Martin, > > > > Thank you for extending a welcome to me and for engaging in this > important dialogue. I am grateful for the opportunity to share my > perspective and to deepen my involvement with the RIPE community. > > > > In your email, you highlighted the importance of being a well-informed > and active member of the community, particularly in the context of voting > for leadership positions. However, the growing inconsistency surrounding > the nature of this process — whether it was intended as a public call for > candidate support, a forum for expressing opinions, or an element of a > specific selection procedure — is of considerable concern. This lack of > clarity, which appears to be more than coincidental, has left myself, and > possibly others, in a state of doubt regarding the appropriate way to > respond and participate. My actions were based on the directives issued by > the current chairs, yet I now find myself questioning if there might be a > deeper, possibly unspoken, agenda underpinning these communications. While > it perhaps truly is coincidentally inconvenient that such ambiguities were > not adequately addressed prior to "unusual traffic in the list”, I would > greatly appreciate your guidance in shedding light on the true purpose and > framework of this initiative. > > > > In my quest to navigate through this entanglement, I delved into the > historical records of our mailing list. My investigation revealed a notably > sparse flow of communication, with only about 20 emails exchanged annually > on average. Given that we are now approaching the year's end, I am > expecting that someone might at some point propose a thoughtful reduction > in email traffic for these remaining days of December. This strategy > potentially could preserve the customary communication patterns, ensuring a > well-balanced and smooth transition into the upcoming year, and potentially > revitalizing the usual dialogue dynamics within the list. > > > > Despite these well designed roadblocks, I would like to offer some > insights into my involvement and interest in the RIPE community, which will > allow you to make informed decisions and not uninformed opinions. > > > > I agree that knowing who we collaborate with is key for effective > teamwork. Acknowledging your concerns, I appreciate the chance to introduce > myself. Surely you have noticed that I've used my official email for group > subscription to affirm my genuine interest and identity, underscoring my > commitment to maintaining the integrity and trustworthiness of our voting > process. > > > > As a philosopher and computational linguist with experience in training > language models and the ethics of big data, I believe I can offer insights > and expertise to the RIPE community. My introduction to RIPE was through a > recommendation by Luka Perkov, a long-time collaborator, and a respected > member of the open source community. Over the past year, my research group > has extensively utilized statistical data, which has been very useful in > our work. At the University of Zagreb as well as at Entimem Ltd, we have > specialized in deep learning analysis of religious texts of various > religions, and RIPE's data has been helpful in measuring activities, aiding > our project proposals and research. > > > > As I have now introduced myself in this e-mail as requested, I am now > very interested to learn more about other members in the same way, namely > those whose opinions are given weight in these discussions and decisions so > that I am at least given an opportunity to engage in the conversation. This > would not only foster a sense of safety and inclusion but also align with > the RIPE’s Code of Conduct, where it is stated that one of the main goals > of the RIPE community is “to help everyone feel safe and included. Many > people will be new to our community. Some may have had negative experiences > in other communities. We want to set a clear expectation that harassment > and related behaviours are not tolerated here. If people do have an > unpleasant experience, they will know that this is neither the norm nor > acceptable to us as a community.” > > > > In closing, I would appreciate any information on how we collaborate and > meet outside of the RIPE meetings, so I can efficiently plan my > involvement. Additionally, if there are any resources, guidelines, or > specific contacts that could help me get started and blend more smoothly > into the team, I would be most grateful for that information. What I have > seen so far is very intriguing and I am very interested to understand the > dynamics of the community. > > > > > > Warm regards, > > > > Ines > > > > > > > > > > > > pon, 18. pro 2023. u 11:25 Martin Winter <mwinter(a)netdef.org> napisao > je: > >> > >> Ines. > >> > >> First of all welcome. And yes, you are one of the impacted persons as > >> well who just joined the list after the RIPE meeting, not attended any > >> recent RIPEs and were still informed well enough to immediatly vote > >> after joining the list. > >> > >> On Sun, Dec 17, 2023 at 9:14 AM Ines Skelac <ines.skelac(a)ffrz.hr> > wrote: > >> > > >> > Dear RIPE Community, > >> > > >> > I am writing to express my disappointment and concern regarding the > recent decision-making process for the open co-chair position in the RIPE > community. As a new member of this esteemed group, I find the approach > taken to be both disheartening and alarming. > >> > >> Is it really alarming that we don't allow votes from people who were > >> not part of the community when the voting started? In all democracies > >> I know, > >> you have to be registered/present some time before the voting starts. > >> If you would be part of the RIPE community for a bit longer then you > >> would be aware that usually the voting would be at the meeting itself. > >> We decided at the last minute to give people a bit more time after > >> they heard each of them introducing themself at the meeting and give > >> them 2 weeks to make up their minds. Maybe we should have been clear > >> that later joins are not eligible to vote, but then you wouldn't have > >> seen or heard that anyway as you were not yet part of the community. > >> > >> So instead of making wild accusations that this is alarming, please > >> take yourself as an example and explain why YOUR vote should count. > >> Explain how you know about the voting and how you heard about ALL of > >> the candidates and about your past experience with RIPE (which got you > >> a bit familiar with the community, our goal of the WG) - which I > >> assume you all know to be able to pick the best candidate. > >> Please be aware, we didn't look for the most popular person or the one > >> with the most followers or the best Open Source background. We were > >> looking for the best choice for a WG chair. How this is defined might > >> be viewed differently by each person. > >> > >> If you can explain this, then we might be happy to reconsider counting > >> your vote. > >> So far, the only ones complaining are the ones who signed up days > >> after the meeting and voted immediately. > >> > >> > The decision to disqualify votes from new members who may not have > had the opportunity to attend a RIPE meeting or were not subscribed to the > mailing list by a specific date seems not only unfair but also > counterproductive. This approach overlooks the potential contributions of > new members and creates an unwelcoming environment. It also appears to be > grounded in logical fallacies, such as the 'post hoc ergo propter hoc' > fallacy, which undermines the rationality of this decision. > >> > >> Please be aware that you can attend RIPE for free from remote. No > >> travel required. No money required. This is a very low entry level. > >> And no, this does not produce a unwelcoming environment, but protects > >> the working group to be not potentially controlled by some outside > >> force. > >> By your definition, welcoming would mean that I can create a bot to > >> create votes and you expect them to be counted. Or I can go and ask > >> all my friends to join and vote in exchange for a beer. This has > >> nothing to do with welcoming, but all about protecting the integrity > >> of the vote. > >> > >> I welcome you to join the next RIPE meeting and bring up this in > >> person to discuss with the whole group. > >> > >> Regards, > >> Martin Winter > >> Open Source WG Chair > >> > >> > > >> > Moreover, such a stance is unacademic and unethical. It disregards > the principles of open dialogue and diversity of perspectives, which are > crucial in any intellectual community. Disqualifying members without > substantial evidence and not acknowledging the value of fresh perspectives > can severely damage the integrity and reputation of the RIPE community. > >> > > >> > As a new member eager to contribute, this experience is not only > disheartening but also raises concerns about the future direction of the > community. I urge the leadership to reconsider this approach and adopt more > inclusive and equitable practices. The strength of a community lies in its > diversity and openness to all voices, including those of its newest members. > >> > > >> > I hope that my concerns will be taken seriously and that we can work > together towards a more inclusive and respectful RIPE community. > >> > > >> > > >> > > >> > Sincerely, > >> > > >> > Ines Skelac, PhD, Assistant Professor > >> > > >> > Vice-dean for Science, International Cooperation, Management and > Quality Assurance > >> > > >> > University of Zagreb, Faculty of Philosophy and Religious Studies > >> > > >> > > >> > > >> > > >> > sub, 16. pro 2023. u 23:45 Ondřej Surý <ondrej(a)dns.rocks> napisao je: > >> >> > >> >> Oh, I didn’t want to imply any intentional wrongdoing. I simply > suggested that stepping down in such situation might be the best way to > acknowledge the less than ideal situation and prevent the possible argument > that might drag for a long time. > >> >> > >> >> Ondrej > >> >> > >> >> On Sat, Dec 16, 2023, at 23:22, Martin Winter wrote: > >> >> > >> >> Ondrej, > >> >> > >> >> On Sat, Dec 16, 2023 at 9:31 PM Ondřej Surý <ondrej(a)dns.rocks> > wrote: > >> >> > The way I read the decision from the chair, they strive to have > the voting process work for the existing community. If suddenly there’s a > surge of people who were never active in this community subscribing to the > mailing list and voting for any of the candidates, I would consider this be > a kind of hostile takeover. > >> >> > > >> >> > Honestly, I think the only fair way out of this would be if the > candidate who received the surge of votes from people outside of this > community stepped down. A co-chair elected with votes from people who never > participated in the RIPE community would not be accepted by this community > and it would be divisive and toxic to the future work. > >> >> > >> >> I don't like to go this far. We (as the chairs) have no proof or > >> >> indication that any of the candidates actively tried to manipulate > the > >> >> voting. However, some candidates might be more popular in their own > >> >> social circles and may have mentioned that they are candidates. And I > >> >> think that's all good and fair. > >> >> I can't blame the candidates for this or for the fact if someone then > >> >> just signed up to vote for him. I have no indication that he/she > >> >> motivated them to do this. > >> >> As such, I assume all candidates are innocent and did not try to > >> >> manipulate the voting. > >> >> > >> >> Regards, > >> >> Martin Winter > >> >> Open Source WG Chair > >> >> > >> >> > >> >> -- > >> >> Ondřej Surý (He/Him) > >> >> ondrej(a)sury.org > >> >> > >> >> _______________________________________________ > >> >> opensource-wg mailing list > >> >> opensource-wg(a)ripe.net > >> >> https://lists.ripe.net/mailman/listinfo/opensource-wg > >> >> > >> >> To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/opensource-wg > >> > > >> > > >> > > >> > _______________________________________________ > >> > opensource-wg mailing list > >> > opensource-wg(a)ripe.net > >> > https://lists.ripe.net/mailman/listinfo/opensource-wg > >> > > >> > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/opensource-wg >

4 3

Call for contributions: Example credit policy
by Valerie Aurora 20 Dec '23

20 Dec '23

Hi all, Thanks for everyone's enthusiasm at the RIPE session about the open source project credit policy! While recovering from COVID I managed to put together a starting draft that included all of the suggestions I could remember. Please edit the draft, via comments, suggestions, or direct edits: https://docs.google.com/document/d/1A4PVQ8iAZFPWySxMdY-EYDArII3BrlK_t70Cek6… Please don't share this link outside this group but do feel free to share copies or solicit outside feedback. A copy of the current text is at the end of this email. Thank you in particular to Maria Matějka, Martin Winter, and Marcos Sanz for many excellent points and solutions. Valerie Link to video and slides: https://ripe87.ripe.net/programme/meeting-plan/os-wg/ Introduction The purpose of this document is to develop an example credit policy: a written description of how an open source software project gives credit for contributions. The problem: people disagree about credit for contributions Open source software projects receive a wide variety of contributions from many different people and organizations. Each contributor has their own assumptions and expectations for what kind of credit contributions should receive. When there is a mismatch between the credit a contributor expects to get and what they actually get, the project suffers. This is an especially important problem for open source software because the main motivation for contributing is often recognition and credit; when people don't receive what they expect, they are less likely to contribute in the future. Two concrete examples: How I got robbed of my first kernel contribution – Ariel Miculas Someone sends in a contribution that needs a little more work. The other contributors are too overworked to review the contribution. Some time later, another person fixes the same problem without ever seeing the first contribution. The first person says, "Hey, why did you rewrite my work without giving me credit?" Our solution: a written policy Our proposed solution to this problem is for each project to write down and publish a formal credit policy (or contribution policy, or anti-plagiarism policy - whatever name seems best). This policy describes what kind of credit and acknowledgement contributors can expect. It also serves as a guide for decision-making for project leaders when they run into more complex problems associated with credit. The end result is that contributors are more likely to contribute to projects with matching credit policies, and project leaders spend less time arguing with contributors or trying to decide how to handle edge cases. The example policy we are writing in this document includes a variety of different ways to assign credit, depending on the project's goals and priorities. Projects can copy parts of the example policy and edit as necessary, or create their own policies from scratch. Scope of a credit policy The policy should cover all types of contribution: documentation, code, tutorials, event organization, testing, design , etc. It should focus primarily on cases in which multiple people or organizations are collaborating on a contribution, when people disagree about who gets credit, and other situations in which credit is less clear. It does not attempt to resolve any legal issues around IP or copyright; that is the domain of contributor agreements, licenses, and other documents. Credit for this policy If you contributed to this policy, please add your name here. We will decide how to credit the contributors as we develop this policy. Valerie Aurora Maria Matějka Martin Winter Marcos Sanz Fair warning: the most successful policies are often the ones with no attribution since people often reject them when their provenance is called out. Ironic, huh? Real-world examples Here are few examples of situations that a credit policy should address: Someone sends a first draft (of a document, code, HTML, etc.). A second person makes significant edits to it. Someone sends a first draft. Another person entirely rewrites it from scratch. Someone sends a contribution. The contribution does not improve the project. Someone sends a contribution but does not complete the "sign-off" or other process step that the project requires. The first reminder goes unanswered for several days. Someone sends a first draft. It fixes a real problem but in a way that is unacceptable for inclusion. They do not respond or are unwilling to make the necessary changes for inclusion. Someone sends a contribution but no one else in the project notices. Later another person makes a similar contribution and gets credit for it. Someone sends a somewhat useless contribution. When you look at their contribution history, you see them sending a lot of useless contributions to other projects. Someone sends a contribution that seems suspicious. When you look at their contribution history, they seem to have rewritten a lot of other people's contributions. Someone sends a lot of tiny separate trivial contributions. They aren't actually making much difference to the project, but if you accept them all it will look like they should have credit for half the project. Someone sends a contribution. For whatever reason, the contribution does not actually seem to be motivated by a desire to improve the project. Someone sends a contribution but a project leader hates the style. Someone sends a contribution and it seems kind of mean-spirited. Policy structure The policy should consist of the following parts: Preamble describing the overall goals and philosophy of the project's credit policy High-level description of how credit is assigned for contributions List of specific situations with step-by-step instructions on what to do in each one How to contact the project if someone thinks that credit has not been given correctly Instructions for people implementing the credit policy, including what to do in difficult situations The last part does not need to be published but can be. Preamble options The preamble describes the overall philosophy of your project towards contributions: what kind of contributions you want to encourage, what kind of contributors you want participating, what your priorities are when it comes to different aspects of quality or productiveness. Your preamble should discourage the kind of contributions you don't want and encourage the kind of contributions you do want. Here are some possible preambles that prioritize different goals. We welcome a broad range of contributions from as many contributors as possible We encourage contributions from as many contributors as possible, and strive to make contributing easy and rewarding. We prefer to guide original contributors through the process of making necessary changes to any contributions, and reward mentoring and review. When a contribution is the combined effort of several people, we prefer to give primary credit to newer contributors. We give credit generously for all of the work that goes into making this project a success, including testing, review, debugging, mentoring, operations, documentation, and similar work. We welcome contributions that do not need much work We encourage contributions but our existing contributors have limited time to mentor or guide new contributors. When a contribution needs changes, existing contributors will usually make any necessary changes themselves rather than working with the original contributor to make the changes. However, we strive to give primary credit to the original contributor whenever possible. We especially encourage contributions that make it easier for new contributors to become productive without direct mentoring, such as documentation, tutorials, refactoring, tests, and similar. We accept outside contributions rarely Our priority is quality of contributions and architectural cohesion. We prefer contributions from existing contributors who are already familiar with our processes and standards, and are carrying out the architectural vision of our leaders. We do not mentor or guide new contributors. When existing contributors rewrite, reuse, or are inspired by contributions from new contributors, it is up to the existing contributor to decide how or if to credit the original author. We prioritize speed of development Our priority is speed of development. We reward contributors who send working contributions quickly. We prefer to give credit to the person who sends the first acceptable form of a contribution rather than the original contributor. Only bug fixes welcome [YOUR DRAFT HERE] My personal project subject to my personal whims [YOUR DRAFT HERE] Our corporate project not open to outside contributions [YOUR DRAFT HERE] Our research project not open to outside contributions [YOUR DRAFT HERE] [YOUR PREAMBLE HERE] Credit assignment options Here are a selection of possible rules for assigning credit. You should choose the ones that encourage the behavior you describe in your philosophy. For example, if you want to encourage new contributors, choose rules that give credit more generously to new contributors than existing ones. If you want existing contributors to have strong control over the project, choose rules that give credit more generously to people who edit or rewrite contributions. Note: don’t get too wrapped up in who “really wrote a contribution.” Most contributions are a collaborative effort by multiple people and it would be impossible to give credit to every single person who made a one line contribution to your project possible. Instead, focus on what behaviors you want to reward and which ones you want to discourage, and be creative about how you do that. If a contribution includes substantial work from multiple authors, we will give primary credit to the least experienced contributor. If we need to rewrite a contribution, we will give primary credit to the author of the first version and secondary credit to the person rewriting it. If we need to rewrite a contribution, we will give primary credit to the person rewriting it and secondary credit to the author of the first version. If we need to rewrite a contribution, we will work with the original author to make the necessary changes for as long as they respond in good faith and in a timely manner. In any case, the original author will get primary credit. The project leaders are the sole authority on who gets credit and will assign it to no one, to themselves, or to others as they see fit. [YOUR SUGGESTION HERE] Please make it easy for us to accept and credit your contribution! Here are the steps to take to get the most credit for your work: [CHOOSE APPLICABLE] Include “Signed-off-by: [YOUR NAME]” Agree to the CLA Follow the instructions in CONTRIBUTING Respond to requests for changes within N days Cooperate in good faith with our requests for changes If you do not want to make changes, please tell us as soon as possible [YOUR SUGGESTION HERE] If for some reasons you can’t or won’t make necessary changes to your contribution, we will [CHOOSE ONE OR MORE AND EDIT TO FIT] Reject your contribution and take no further action Incorporate your original contribution as is, then make a second change with any edits Incorporate your contribution along with any necessary edits with primary credit to the newest contributor, with a link in the change message to your original contribution on our mailing list or other archive of original contributions (e.g. a directory in the source code, a section of the wiki, etc.) If you did not [sign off, agree to the CLA, other necessary process step], we will rewrite from scratch and include a link to the original contribution in the change message How we give credit: For commits to a repository, the primary author is the commit author. For reviews, editing, testing, debugging, or reporting directly related to a specific contribution, we add a line in the change message such as “Reviewed-by” or “Edited-by”. For contributions that are not specific to an individual change, such as hosting, DevOps, DevRel, issue curation, etc, we will add your name to [LIST AND LOCATION OF PUBLICATION]. To be added to this list, please [INSTRUCTIONS]. [Suggestion: include an option for extremely minor contributions.] [YOUR SUGGESTION HERE] We reserve the right to not grant credit when it seems detrimental to our project. For example, if someone requests credit to a name that is obscene or harmful, or if they are spamming multiple projects with minor contributions, or if interacting with a contributor is demoralizing to other contributors. Correcting mistakes in credit Sometimes we make a mistake in how we give credit. In this project: [CHOOSE FROM FOLLOWING] Once credit had been given, we will not go back and correct it. We will correct mistakes in credit attribution for up to [TIME PERIOD] after credit has been given. We will correct mistakes in credit at any point. [YOUR SUGGESTIONS HERE] Reporting problems with credit If someone has not given credit correctly, please contact [CONTACT INFORMATION - COULD BE CODE OF CONDUCT COMMITTEE] and include any relevant information. [NAMES] will review your report and take any action they deem appropriate, including but not limited to updating the credit information, warning the person who did not follow the credit policy, no longer accepting their contributions, or forwarding the complaint to the community code of conduct committee.

4 4

Call for support of co-chair candidates
by Marcos Sanz 20 Dec '23

20 Dec '23

Dear all, as explained today during the working group session, three people have volunteered to fill the one open co-chair vacancy. Sorted by sha256() over their full name, the candidates are -Christian Scheele -Luka Perkov -Sasha Romijn Big thanks to all of them for their offer to support the community, we are happy to see such an interest! The candidates have introduced themselves and their motivations also during today's session. In case you missed it, you can watch the specific recordings here: https://ripe87.ripe.net/archives/video/1214 https://ripe87.ripe.net/archives/video/1217 Now this is a public call for support of the candidates, open for TWO WEEKS starting now and ENDING 14th December (EOB UTC). If you want to support one (or more) candidate(s), please send a public message doing so to this mailing list. Statements of support cannot be anonymous, so please finish the e-mail with your name. It's also possible (even helpful) to support more than one candidate (to be able to break potential ties). If you'd wish to do so, please deliver your statement of support with the candidate names sorted by preference. Now it's your time to contribute by choosing the new co-chair: help the community! Marcos Sanz & Martin Winter

27 36

Re: [opensource-wg] Call for support of co-chair candidates
by Bruno Banelli ＠ Racunarstvo 14 Dec '23

14 Dec '23

Greetings to everyone, pleasantly surprised with Luka's co-chair nomination, I truly believing he can contribute to the operations of the group and will make a fine addition to already fantastic people sitting there. That being said, I vote for: 1. Luka Perkov With my very best regards, Bruno Banelli, Algebra University College Zagreb On Thu, Nov 30, 2023 at 10:27 AM Marcos Sanz via opensource-wg <opensource-wg(a)ripe.net<mailto:opensource-wg@ripe.net>> wrote: Dear all, as explained today during the working group session, three people have volunteered to fill the one open co-chair vacancy. Sorted by sha256() over their full name, the candidates are -Christian Scheele -Luka Perkov -Sasha Romijn Big thanks to all of them for their offer to support the community, we are happy to see such an interest! The candidates have introduced themselves and their motivations also during today’s session. In case you missed it, you can watch the specific recordings here: https://ripe87.ripe.net/archives/video/1214 https://ripe87.ripe.net/archives/video/1217 Now this is a public call for support of the candidates, open for TWO WEEKS starting now and ENDING 14th December (EOB UTC). If you want to support one (or more) candidate(s), please send a public message doing so to this mailing list. Statements of support cannot be anonymous, so please finish the e-mail with your name. It’s also possible (even helpful) to support more than one candidate (to be able to break potential ties). If you’d wish to do so, please deliver your statement of support with the candidate names sorted by preference. Now it’s your time to contribute by choosing the new co-chair: help the community! Marcos Sanz & Martin Winter _______________________________________________ opensource-wg mailing list opensource-wg(a)ripe.net<mailto:opensource-wg@ripe.net> https://lists.ripe.net/mailman/listinfo/opensource-wg To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/opensource-wg

3 2

Re: [opensource-wg] Call for support of co-chair candidates
by Ines Skelac 14 Dec '23

14 Dec '23

Dear Colleagues, I am delighted to learn about Luka Perkov's nomination for the co-chair position. Given his capabilities and dedication, I am confident that he will be a valuable asset to the team. In light of this, I would like to formally cast my vote in favor of Luka Perkov for the co-chair role. Thank you for considering my recommendation. Warm regards, Ines Skelac, PhD, Assistant Professor Vice-dean for Science, International Cooperation, Management and Quality Assurance University of Zagreb, Faculty of Philosophy and Religious Studies www.ffrz.unizg.hr ines.skelac(a)ffrz.unizg.hr > On Thu, Nov 30, 2023 at 10:27 AM Marcos Sanz via opensource-wg < >> opensource-wg(a)ripe.net> wrote: >> >> Dear all, >> >> >> >> as explained today during the working group session, three people have >> volunteered to fill the one open co-chair vacancy. Sorted by sha256() over >> their full name, the candidates are >> >> >> >> -Christian Scheele >> >> -Luka Perkov >> >> -Sasha Romijn >> >> >> >> Big thanks to all of them for their offer to support the community, we >> are happy to see such an interest! The candidates have introduced >> themselves and their motivations also during today’s session. In case you >> missed it, you can watch the specific recordings here: >> >> https://ripe87.ripe.net/archives/video/1214 >> >> https://ripe87.ripe.net/archives/video/1217 >> >> >> >> >> >> Now this is a public call for support of the candidates, open for TWO >> WEEKS starting now and ENDING 14th December (EOB UTC). If you want to >> support one (or more) candidate(s), please send a public message doing so >> to this mailing list. Statements of support cannot be anonymous, so please >> finish the e-mail with your name. >> >> >> >> It’s also possible (even helpful) to support more than one candidate (to >> be able to break potential ties). If you’d wish to do so, please deliver >> your statement of support with the candidate names sorted by preference. >> >> >> >> Now it’s your time to contribute by choosing the new co-chair: help the >> community! >> >> Marcos Sanz & Martin Winter >> _______________________________________________ >> opensource-wg mailing list >> opensource-wg(a)ripe.net >> https://lists.ripe.net/mailman/listinfo/opensource-wg >> >> To unsubscribe from this mailing list, get a password reminder, or change >> your subscription options, please visit: >> https://lists.ripe.net/mailman/listinfo/opensource-wg >> >> > > > > >

1 0

[openource-wg] Call for support of co-chair candidates
by Marin Ajduk 13 Dec '23

13 Dec '23

Hi All, I would like to support Luka Perkov for this role. Best regards, Marin Ajduk Regional Sales Manager marin.ajduk(a)nexperia.com<mailto:marin.ajduk@nexperia.com> nexperia<http://www.nexperia.com/>.<http://www.nexperia.com/>com<http://www.nexperia.com/>

1 0

I am voting for Luka Perkov
by Viacheslav Dubeyko 13 Dec '23

13 Dec '23

Hello, I am voting for Luka Perkov as co-chair candidate. Thanks, Slava Dubeyko.

1 0

Call for support of co-chair candidates
by Filip Bubalo 13 Dec '23

13 Dec '23

Greetings! My vote goes to Luka Perkov, I collaborated with him on multiple projects. He has understanding practical and theoretical understanding of network systems, OpenWRT technology, and all things network. Best regards, Filip

1 0

Call for support of co-chair candidates
by Manuel Brkovic 13 Dec '23

13 Dec '23

Dear all, I would like to support - Luka Perkov - for this role Kind regards Manuel *Manuel Brković* +385 (0)98 316 043 <+385%20(0)98%20316%20043> manuel.brkovic(a)adcora.hr adcora <https://www.adcora.hr/> Baltazara-Adama Krčelića 19, 10290, Zaprešić

1 0

Re: [opensource-wg] Call for support of co-chair candidates
by Andrija Huzjak 12 Dec '23

12 Dec '23

My vote goes to Luka Perkov On 30/11/2023 10:27, Marcos Sanz via opensource-wg wrote: > Dear all, > > as explained today during the working group session, three people have > volunteered to fill the one open co-chair vacancy. Sorted by sha256() > over their full name, the candidates are > > -Christian Scheele > > -Luka Perkov > > -Sasha Romijn

1 0

Subject: Call for support of co-chair candidates
by Jan Vesel 12 Dec '23

12 Dec '23

Dear all, I would like to support - Luka Perkov - for this role. Best regards, Jan -- Jan Vesel *CEO & Founder* *ConVes services d.o.o.* m: +385917867676 <+385%91%786%7676> ConVes services <https://www.linkedin.com/company/conves-services> Dear all, as explained today during the working group session, three people have volunteered to fill the one open co-chair vacancy. Sorted by sha256() over their full name, the candidates are -Christian Scheele -Luka Perkov -Sasha Romijn Big thanks to all of them for their offer to support the community, we are happy to see such an interest! The candidates have introduced themselves and their motivations also during today’s session. In case you missed it, you can watch the specific recordings here: https://ripe87.ripe.net/archives/video/1214 https://ripe87.ripe.net/archives/video/1217 Now this is a public call for support of the candidates, open for TWO WEEKS starting now and ENDING 14th December (EOB UTC). If you want to support one (or more) candidate(s), please send a public message doing so to this mailing list. Statements of support cannot be anonymous, so please finish the e-mail with your name. It’s also possible (even helpful) to support more than one candidate (to be able to break potential ties). If you’d wish to do so, please deliver your statement of support with the candidate names sorted by preference. Now it’s your time to contribute by choosing the new co-chair: help the community! Marcos Sanz & Martin Winter _______________________________________________ opensource-wg mailing list opensource-wg(a)ripe.net https://lists.ripe.net/mailman/listinfo/opensource-wg To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/opensource-wg

1 0

Endorsment
by David Zovko 12 Dec '23

12 Dec '23

Hello, I would like to endorse Luka Perkov for his outstanding abilities in networking and, specifically, OpenWRT. Over the past four years, I have collaborated with Luka on half a dozen networking initiatives. During this time, he has repeatedly proven his remarkable expertise, commitment, and profound knowledge in the field of networking technologies. Regards, [logo]<https://soldered.com/> DAVID ZOVKO FOUNDER & MANAGING DIRECTOR +385 97 616 3556 david(a)soldered.com<mailto:david@soldered.com> On Thu, Nov 30, 2023 at 10:27 AM Marcos Sanz via opensource-wg <opensource-wg(a)ripe.net<mailto:opensource-wg@ripe.net>> wrote: Dear all, as explained today during the working group session, three people have volunteered to fill the one open co-chair vacancy. Sorted by sha256() over their full name, the candidates are -Christian Scheele -Luka Perkov -Sasha Romijn Big thanks to all of them for their offer to support the community, we are happy to see such an interest! The candidates have introduced themselves and their motivations also during today’s session. In case you missed it, you can watch the specific recordings here: https://ripe87.ripe.net/archives/video/1214 https://ripe87.ripe.net/archives/video/1217 Now this is a public call for support of the candidates, open for TWO WEEKS starting now and ENDING 14th December (EOB UTC). If you want to support one (or more) candidate(s), please send a public message doing so to this mailing list. Statements of support cannot be anonymous, so please finish the e-mail with your name. It’s also possible (even helpful) to support more than one candidate (to be able to break potential ties). If you’d wish to do so, please deliver your statement of support with the candidate names sorted by preference. Now it’s your time to contribute by choosing the new co-chair: help the community! Marcos Sanz & Martin Winter _______________________________________________ opensource-wg mailing list opensource-wg(a)ripe.net<mailto:opensource-wg@ripe.net> https://lists.ripe.net/mailman/listinfo/opensource-wg To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/opensource-wg

1 0

Re: [opensource-wg] Call for support of co-chair candidates
by Andrej Mlinarević 12 Dec '23

12 Dec '23

Hi, I am writing to highly recommend Luka Perkov for his networking and OpenWRT technology skills. I have had the pleasure of working closely with Luka for 5+ years on various networking projects, where he has consistently demonstrated exceptional skills, dedication, and a deep understanding of networking technologies. > > On Thu, Nov 30, 2023 at 10:27 AM Marcos Sanz via opensource-wg < > opensource-wg(a)ripe.net> wrote: > >> Dear all, >> >> >> >> as explained today during the working group session, three people have >> volunteered to fill the one open co-chair vacancy. Sorted by sha256() over >> their full name, the candidates are >> >> >> >> -Christian Scheele >> >> -Luka Perkov >> >> -Sasha Romijn >> >> >> >> Big thanks to all of them for their offer to support the community, we >> are happy to see such an interest! The candidates have introduced >> themselves and their motivations also during today’s session. In case you >> missed it, you can watch the specific recordings here: >> >> https://ripe87.ripe.net/archives/video/1214 >> >> https://ripe87.ripe.net/archives/video/1217 >> >> >> >> >> >> Now this is a public call for support of the candidates, open for TWO >> WEEKS starting now and ENDING 14th December (EOB UTC). If you want to >> support one (or more) candidate(s), please send a public message doing so >> to this mailing list. Statements of support cannot be anonymous, so please >> finish the e-mail with your name. >> >> >> >> It’s also possible (even helpful) to support more than one candidate (to >> be able to break potential ties). If you’d wish to do so, please deliver >> your statement of support with the candidate names sorted by preference. >> >> >> >> Now it’s your time to contribute by choosing the new co-chair: help the >> community! >> >> Marcos Sanz & Martin Winter >> _______________________________________________ >> opensource-wg mailing list >> opensource-wg(a)ripe.net >> https://lists.ripe.net/mailman/listinfo/opensource-wg >> >> To unsubscribe from this mailing list, get a password reminder, or change >> your subscription options, please visit: >> https://lists.ripe.net/mailman/listinfo/opensource-wg >> > -- *Andrej Mlinarević* CEO at PROTOTYP andrej(a)prototyp.digital +385 95 5147 795 <+385955147795> prototyp.digital Kordunska 12, 31000 Osijek

1 0

Re: [opensource-wg] Call for support of co-chair candidates
by Alexandru Ardelean 12 Dec '23

12 Dec '23

> Dear all, > Hello, I vote for Luka Perkov. Thank you Alex > as explained today during the working group session, three people have > volunteered to fill the one open co-chair vacancy. Sorted by sha256() over their > full name, the candidates are > > -Christian Scheele > -Luka Perkov > -Sasha Romijn > > Big thanks to all of them for their offer to support the community, we are happy > to see such an interest! The candidates have introduced themselves and their > motivations also during today’s session. In case you missed it, you can watch the > specific recordings here: > > https://ripe87.ripe.net/archives/video/1214 > https://ripe87.ripe.net/archives/video/1217 > > Now this is a public call for support of the candidates, open for TWO WEEKS > starting now and ENDING 14th December (EOB UTC). If you want to support > one (or more) candidate(s), please send a public message doing so to this mailing list. Statements of support cannot be anonymous, so please finish the > e-mail with your name. > > It’s also possible (even helpful) to support more than one candidate (to be able > to break potential ties). If you’d wish to do so, please deliver your statement of > support with the candidate names sorted by preference. > > Now it’s your time to contribute by choosing the new co-chair: help the > community! > Marcos Sanz & Martin Winter > > _______________________________________________ > opensource-wg mailing list > opensource-wg(a)ripe.net > https://lists.ripe.net/mailman/listinfo/opensource-wg > > To unsubscribe from this mailing list, get a password reminder, or change your > subscription options, please visit: https://lists.ripe.net/mailman/listinfo/opensource-wg

1 0

Call for support of co-chair candidates
by Paul Arola 11 Dec '23

11 Dec '23

Long time lurker, first time poster. My vote is for Luka Perkov, I have always been a fan of what he's done at Sartura and DENT. -paul arola > > On Thu, Nov 30 2023 at 10:27 AM, Marcos Sanz <opensource-wg(a)ripe.net> wrote: > > Dear all, > > > > as explained today during the working group session, three people have volunteered to fill the one open co-chair vacancy. Sorted by sha256() over their full name, the candidates are > > > > -Christian Scheele > > -Luka Perkov > > -Sasha Romijn > > > > Big thanks to all of them for their offer to support the community, we are happy to see such an interest! The candidates have introduced themselves and their motivations also during today’s session. In case you missed it, you can watch the specific recordings here: > > https://ripe87.ripe.net/archives/video/1214 > > https://ripe87.ripe.net/archives/video/1217 > > > > > > Now this is a public call for support of the candidates, open for TWO WEEKS starting now and ENDING 14th December (EOB UTC). If you want to support one (or more) candidate(s), please send a public message doing so to this mailing list. Statements of support cannot be anonymous, so please finish the e-mail with your name. > > > > It’s also possible (even helpful) to support more than one candidate (to be able to break potential ties). If you’d wish to do so, please deliver your statement of support with the candidate names sorted by preference. > > > > Now it’s your time to contribute by choosing the new co-chair: help the community! > > Marcos Sanz & Martin Winter > > > _______________________________________________ > opensource-wg mailing list > opensource-wg(a)ripe.net > https://lists.ripe.net/mailman/listinfo/opensource-wg > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/opensource-wg

1 0

Re: [opensource-wg] Call for support of co-chair candidates
by Valerie Aurora 06 Dec '23

06 Dec '23

Hi all, I appreciated everyone's pitches for the co-chair vacancy and think all three would do a good job. After some thought, I support Sasha Romijn for co-chair, based on the ideas and plans she outlined in her talk. Valerie > Dear all, > > > > as explained today during the working group session, three people have > volunteered to fill the one open co-chair vacancy. Sorted by sha256() over > their full name, the candidates are > > > > -Christian Scheele > > -Luka Perkov > > -Sasha Romijn > > > > Big thanks to all of them for their offer to support the community, we are > happy to see such an interest! The candidates have introduced themselves and > their motivations also during today's session. In case you missed it, you > can watch the specific recordings here: > > https://ripe87.ripe.net/archives/video/1214 > > https://ripe87.ripe.net/archives/video/1217 > > > > > > Now this is a public call for support of the candidates, open for TWO WEEKS > starting now and ENDING 14th December (EOB UTC). If you want to support one > (or more) candidate(s), please send a public message doing so to this > mailing list. Statements of support cannot be anonymous, so please finish > the e-mail with your name. > > > > It's also possible (even helpful) to support more than one candidate (to be > able to break potential ties). If you'd wish to do so, please deliver your > statement of support with the candidate names sorted by preference. > > > > Now it's your time to contribute by choosing the new co-chair: help the > community! > > Marcos Sanz & Martin Winter > >

1 0

Re: [opensource-wg] Call for support of co-chair candidates
by Taras Chornyi 04 Dec '23

04 Dec '23

+1 for Luka On Thu, Nov 30 2023 at 10:27 AM, Marcos Sanz <opensource-wg(a)ripe.net<mailto:opensource-wg@ripe.net>> wrote: Dear all, as explained today during the working group session, three people have volunteered to fill the one open co-chair vacancy. Sorted by sha256() over their full name, the candidates are -Christian Scheele -Luka Perkov -Sasha Romijn Big thanks to all of them for their offer to support the community, we are happy to see such an interest! The candidates have introduced themselves and their motivations also during today’s session. In case you missed it, you can watch the specific recordings here: https://ripe87.ripe.net/archives/video/1214 https://ripe87.ripe.net/archives/video/1217 Now this is a public call for support of the candidates, open for TWO WEEKS starting now and ENDING 14th December (EOB UTC). If you want to support one (or more) candidate(s), please send a public message doing so to this mailing list. Statements of support cannot be anonymous, so please finish the e-mail with your name. It’s also possible (even helpful) to support more than one candidate (to be able to break potential ties). If you’d wish to do so, please deliver your statement of support with the candidate names sorted by preference. Now it’s your time to contribute by choosing the new co-chair: help the community! Marcos Sanz & Martin Winter _______________________________________________ opensource-wg mailing list opensource-wg(a)ripe.net https://lists.ripe.net/mailman/listinfo/opensource-wg To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/opensource-wg

1 0

Call for support of co-chair candidates
by Peter Steinhäuser 30 Nov '23

30 Nov '23

First of all thanks to all the candidates for stepping up - it’s great to see many volunteers willing to contribute to the WG’s work! I would like to express my support for Christian whom I know since many years as a skilled and creative mind who’s building innovative network solutions since many years and has the ability to think out of the box. - Peter > Dear all, > > as explained today during the working group session, three people have > volunteered to fill the one open co-chair vacancy. Sorted by sha256() over > their full name, the candidates are > > -Christian Scheele > -Luka Perkov > -Sasha Romijn > > Big thanks to all of them for their offer to support the community, we are > happy to see such an interest! The candidates have introduced themselves and > their motivations also during today's session. In case you missed it, you > can watch the specific recordings here: > > https://ripe87.ripe.net/archives/video/1214 > https://ripe87.ripe.net/archives/video/1217 > > Now this is a public call for support of the candidates, open for TWO WEEKS > starting now and ENDING 14th December (EOB UTC). If you want to support one > (or more) candidate(s), please send a public message doing so to this > mailing list. Statements of support cannot be anonymous, so please finish > the e-mail with your name. > > It's also possible (even helpful) to support more than one candidate (to be > able to break potential ties). If you'd wish to do so, please deliver your > statement of support with the candidate names sorted by preference. > > Now it's your time to contribute by choosing the new co-chair: help the > community! > > Marcos Sanz & Martin Winter

1 0

[Grants | NGI zero] Open calls for free software, hardware and data activists with a FOSS project
by Xavier Coadic 21 Nov '23

21 Nov '23

Hello from somewhere in the EU, There is currently a call for projects to finance them (donations) which is open until 1 December 2023. This could be of interest to you or even help your friends to finance their work and development. Project funding available varies from 5,000 to 50,000 euros (with the possibility to scale them up if there is proven potential) Full summary is here: https://www.apc.org/en/news/open-calls-free-software-hardware-and-data-acti… A consortium of 12 non-profit organisations is involved in managing the NGI zero program. https://nlnet.nl/entrust/background/#organisation 2 Tracks: + NGI Zero Entrust: Trustworthiness and data sovereignty https://nlnet.nl/entrust/guideforapplicants/ + NGI Zero Core: Moving the internet forward https://nlnet.nl/core/guideforapplicants You don't need to reveal your real name prior to the project being granted. Also, young people that have not yet reached the age of legal consent in their country of origin on the date of the deadline can also apply without any constraints. If you are based outside the European Union and still have doubts, please write to hvale(a)apc.org As well as funding from donations, there is specific support (technical, safety, accessibility, licensing, etc.) for the projects selected. Also, if you'd like to talk about it with me, I'd be delighted ;-) For example: https://www.apc.org/en/pubs/feminist-principles-internet-version-20 Maybe see you in Brussels, Feb. 2024 Warm regards, -- Xavier Coadic Association for Progressive Communications Communications associate for NGI Zero initiative

1 0

Draft agenda open source wg RIPE 87
by Marcos Sanz 17 Nov '23

17 Nov '23

Dear all, the draft agenda for the upcoming meeting of the working group is now online: https://ripe87.ripe.net/programme/meeting-plan/os-wg/ As always, we'd still welcome any lighning talks! No formal submission is required ahead of RIPE 87, but please send a short message to the chairs by noon on Tuesday of the meeting week. Talks will be selected on Tuesday afternoon. Best regards, Martin Winter & Marcos Sanz Open Source WG Chairs

1 0

Brussels Open Tech Week 2024 | 31 Jan - 5 Feb (including FOSDEM)
by Vesna Manojlovic 16 Nov '23

16 Nov '23

FYI https://openforumeurope.org/brussels-open-tech-week-2024-open-technology-an… On 14/11/2023 10:09, OpenForum Europe wrote: > > Brussels Open Tech Week 2024 > > > *Brussels is a hub of open technology and digital policy discussions as > of late. OFE organises the EU Open Source Policy Summit on 2 February, but the main momentum for this week comes from the renowned Free and Open Source Software Developers’ European Meeting (FOSDEM), a fixture in Brussels that has engendered an ever increasing number of ancillary activities and events. Open Forum Europe’s team and partners will participate in various capacities throughout the week, whether as speakers or as attendees absorbing knowledge and insights.* > > So, while we make no claims of being the organisers of everything below, > we feel like an umbrella term is needed. So mark your calendars: *The > Brussels Open Tech Week 2024* from 31 January to 5 February. It promises to be an eventful week for all enthusiasts and professionals engaged in the open tech landscape and EU policy. > > *31 January – Wednesday* > > > *Antitrust, Regulation, and the Next World Order* > The digital regulation experiment has started. But we are also going > through simultaneous major paradigm shifts in antitrust, industrial > policy and trade. Competition is not a silo. Join us for a gathering of > top regulators, judges, legislators and academics to discuss challenges > and goals. > > > *1 February – Thursday* > > *OFE Policy Workshop* > An invite-only session that delves into the policy challenges and > opportunities within the open tech realm. To partake in this workshop, > please contact Ciarán at OFE for an invitation. > > /*Other event yet to be announced…*/ > > > *2 February – Friday* > > > *EU Open Source Policy Summit* > Our event largest assembly of policymakers, Open Source businesses, > community members, developers, foundations, and experts engaged in > diverse digital policy matters. Registration is currently open for those > interested in attending. Seats are limited! > > > *3 February – Saturday* > > > *FOSDEM Day 1* > Legal & Policy DevRoom > Join the main event of the week. FOSDEM is a two-day event organised by > volunteers to promote the widespread use of free and open source > software. FOSDEM is widely recognised as the best such conference in Europe. > > > *4 February – Sunday* > > *FOSDEM Day 2* > Foundations’ Policy DevRoom > A specialised series of discussions focusing on the intersection of open > source foundations and policy. > -- Senior Community Builder, RIPE NCC https://labs.ripe.net/author/becha/

1 0

Funding Open Source: a blog post & a web-event
by Vesna Manojlovic 25 Oct '23

25 Oct '23

Dear all, please take a look at a success story of funding open source: https://blog.sentry.io/we-just-gave-500-000-dollars-to-open-source-maintain… ... and join the event on Thursday, October 26th 2023, 7:00 pm GMT+2 "The Future of Open Source: The State of Sustainability" by Chad Whitacre (Sentry), Kara Sowles Deloss (GitHub) & Fiona (*) Krakenbürger (Sovereign Tech Fund) https://sentry.io/resources/the-future-of-open-source-the-state-of-sustaina… Regards, Vesna (*) Fiona is also on the selection committee of RIPE NCC's Community Project Fund) -- Senior Community Builder, RIPE NCC https://labs.ripe.net/author/becha/

1 0

Call for Opensource-WG Presentations (RIPE87, Rome, 27 Nov - 1 Dec 2023)
by Martin Winter 20 Oct '23

20 Oct '23

Call for Opensource-WG Presentations (RIPE87, Rome, 27 Nov - 1 Dec 2023) The next RIPE Meeting is coming up again - your chance to present about some interesting Open Source If you would like to give a presentation during the OpenSource WG session, then please contact us (the WG chairs). In general, each talk is 15-30 mins (depending on how much time is needed). If you have some idea and are not sure how/if you should present something then feel free to contact us as well to discuss the idea. For small project updates, we are planning to reserve 30 mins again at the end of the WG session. These short 5..10(max) min updates/talks are decided on the day before the WG session on a time/space available basis. No need to submit anything for these talks at this time. Thanks, Martin Winter & Marco Sanz OpenSource WG Chairs

3 3

Fwd: Can open source be saved from the EU's Cyber Resilience Act?
by Vesna Manojlovic 16 Oct '23

16 Oct '23

FYI

1 0

Open Source WG - Call for Co-Chairs Nomination
by Martin Winter 26 Sep '23

26 Sep '23

Martin Winter <mwinter(a)netdef.org> Wed, Sep 29, 2021, 1:07 PM to opensource-wg(a)ripe.net It's soon time for our RIPE Fall meeting - which means it’s time for nominations to become a new co-chair of the WG. Please send your nominations by End of October to the WG chairs: opensource-wg-chairs(a)ripe.net Deadline for nominations: Sunday, Oct 31, 23:59 UTC We are currently 2 Chairs: Martin Winter and Marco Sanz. Ondrej Filip stepped down after the past RIPE meeting. Both of the existing chairs are willing to continue. If there are no nominations, then there will be no change, but we are very open to new candidates and would welcome to add another Co-Chair Details on Chair Selection Policy: https://www.ripe.net/participate/ripe/wg /open-source-working-group/open-source-wg-chair-selection-process In short: If there are NO nominations, then the existing chairs will continue. If there are nominations, then the existing chairs will have a discussion with the candidates to see if we can come to an agreement (i.e. expand to 3 chairs, replace one of us etc). If there is no agreement between all the existing chairs and the new nominations until RIPE, then there will be a vote during the RIPE meeting. Regards, Martin Winter & Marco Sanz Open Source WG Chairs

1 0

Events of interest : FLOSS
by Vesna Manojlovic 07 Aug '23

07 Aug '23

Dear colleagues, as part of cross-community connections, I am sharing these upcoming events with you: as an invitation to attend, and to promote/represent RIPE Community if you go there -- and to invite those participants back to RIPE community! Cheers, Vesna === "All Systems Go" (foundational user-space Linux technologies) 13-14th September, Berlin https://all-systems-go.io === Open Source Summit Europe 19-21 September 2023, Bilbao, Spain https://events.linuxfoundation.org/open-source-summit-europe/ === Next Generation Internet (NGI) Forum: Unlocking the power of Digital Commons 15-16 November, Brussels (Belgium) https://www.ngi.eu/event/ngi-forum-2023/ === OpenForum Academy Symposium 2023, 28 November in Berlin. https://symposium.openforumeurope.org The OpenForum Academy, Carnegie Mellon University, FGV Direito Rio, Keio University, TU Berlin and the United Nations University Centre for Policy Research are proud to announce the programme for the OpenForum.. ... insight into the state of art of Open Source today: Open Source Communities and Cooperatives Legal implications from Open Source Open Source and AI Measuring Open Source ... & not limited to the academic public. === For more events, follow: - https://www.ripe.net/participate/meetings/calendar) - https://nsrc.net/calendar - https://pch.net/calendar - https://foss.events/ -- Senior Community Builder, RIPE NCC https://labs.ripe.net/author/becha/

1 0

Fwd: Three Challenges to Contribute Back to Open Source
by Vesna Manojlovic 06 Jun '23

06 Jun '23

Let’s strengthen the Open Source ecosystem together! https://sovereigntechfund.de/en/challenges/ The Sovereign Tech Fund is looking for developers who use open source and want to contribute back. We need a sustainable ecosystem that enables new software development and ensures the ongoing security of existing dependencies. Many more people use open source software every day than contribute to it. It's time to give back and invest in this ecosystem, to increase its security and sustainability. In three challenges, participants can work on contributing back to open source for up to eight months with a budget of up to €300,000 for each of the four-month rounds. We’re accepting proposals starting today through July 6, 2023 (23:59 UTC+2). What are the Contribute Back Challenges about? The Sovereign Tech Fund is issuing three challenges to encourage active participation in open source infrastructure. With the call to “Contribute Back,” we are making it possible for developers, contributors, and maintainers to actively contribute to and work on the open source projects they depend on over a four to eight period. We want to identify critical issues in the open source ecosystem and empower people to work on them. To do this, the Sovereign Tech Fund is offering short-term challenge funding for participants to explore new solutions and focus on implementing them over a limited period of time. Our goal is to use these challenges is to discover the best ways to strengthen the ecosystem together. The Sovereign Tech Fund is providing up to €300,000 per application over a period of four months, with the possibility of a 4-month extension. We will support the creation and improvement of developer tooling, the production security of Free and Open Source Software (FOSS) components, and the documentation of critical open source infrastructure technologies. In the challenges, the STF hopes to answer important questions, for example: Can better developer tooling help FOSS maintainers manage growing technical debt and increase test coverage to provide greater reliability and maintainability in the long term? What software production security mechanisms enable FOSS projects to stay open to contributions while protecting against the increasing threat of supply chain attacks? As the demand on the FOSS infrastructure increases, what documentation is needed to allow new developers to participate and to reduce the load on maintainers? To learn more about the Contribute Back challenges, visit https://sovereigntechfund.de/en/challenges/ Thanks and let’s get to contributing back! The STF Team

1 0

Fwd: Announcement and CfP: OpenForum Academy Symposium 2023
by Vesna Manojlovic 17 May '23

17 May '23

FYI We are excited to invite you to the OpenForum Academy Symposium 2023 The CfP is now open until 29 May Hosted by TU Berlin, the OpenForum Academy Symposium will, on 28 November 2023, bring together researchers and practitioners from all walks of the Open Source research ecosystem at an interdisciplinary conference. Submit a proposal, register to attend and save the date Website and CfP https://symposium.openforumeurope.org As of today there is no academic conference covering questions relating to the social, political and economic impact of Open Source. This hampers the linking of research agendas, growth of the research area, and the societal understanding of the value of the Open Source ecosystem as a whole. The OpenForum Academy Symposium (OFA) fills this space. After a successful first, virtual edition in 2021, the OFA Symposium 2023 will bring together an interdisciplinary set of researchers, practitioners, and policymakers from around the world to Berlin, in order to explore the transformative power of Open Source Software and Hardware. At the OFA Symposium, we will examine the social, political, and economic implications of open source. We will explore how open source is changing the way we work, communicate, and interact with each other, and how it is shaping the future of technology and society. The Symposium will feature a diverse and group of speakers and participants, including researchers, policymakers, developers, and activists. We believe that the OFA Symposium will provide a unique and valuable opportunity for learning, collaboration, and networking. We hope you will join us for this exciting event, and look forward to exploring the social, political, and economic impact of Open Source together. First keynote speaker announnced Andres Guadamuz, Reader in Intellectual Property Law at University of Sussex and technology commentator @technollama

1 0

Agenda Open Source WG RIPE 86
by Martin Winter 09 May '23

09 May '23

Less than 2 weeks until RIPE. Below is the agenda for the Open Source WG Session. The session will be on Thursday afternoon, just after lunch. Hope to see you all in Rotterdam. Open Source WG Chairs A. Administrative Matters - finalize agenda - approval of minutes from previous WG meeting(s) - review of action list B. NGI-Zero: EU-funded framework for supporting FLOSS projects Niall O'Reilly, Tolerant Networks Ltd This presentation will alert participants to the EU Commission's New Generation Internet (NGI), to NGI funding opportunities, and to project support available from the NGI-Zero coalition led by the NLnet Foundation. Tolerant Networks Ltd is a partner in NGI-Zero. C. From Peering Manager features to standalone library Guillaume Mazoyer, Peering Manager Lead Developer During the process of writing the integration code for Peering Manager and IX-API, an opportunity arose to extract the relevant features from the main code base and create a separate library. As a result, pyixapi was born, providing a user-friendly and straightforward interface for interacting with IX-API endpoints. D. BIRD 2 - Overview and Future Outlook Ondřej Zajíček, CZ.NIC Five years ago, we released BIRD 2, the major overhaul of BIRD Internet Routing Daemon. I will recapitulate recent BIRD development, present new interesting features, and discuss the future outlook of BIRD development, including the upcoming multithreaded BIRD 3. E. Update from Route Server Support Foundation Niels Raijer, Chairman RSSF Why RSSF is there, the technological advances in OpenBGPD and rpki-client and a surprising way in which we received some funding. F. Lightning Talks These are short updates on different relevant OpenSource projects. They should be 5 mins (preferably) with a maximum of 10 mins(if space allows). No formal submission required ahead of RIPE, but please send a short message to opensource-wg-chairs(a)ripe.net by noon on Tuesday during the RIPE if you want to present an update. Selection of talks are done on Tuesday afternoon.

1 0

Agenda Open Source WG RIPE 86
by Martin Winter 09 May '23

09 May '23

Below is the Agenda for the Open Source WG Session during RIPE. One thing not mentioned in the agenda (but will be announced during the Admin section), is that Ondrej is stepping down as OS WG Chair. See you all in Rotterdam, Martin ----- A. Administrative Matters - finalize agenda - approval of minutes from previous WG meeting(s) - review of action list B. NGI-Zero: EU-funded framework for supporting FLOSS projects Niall O'Reilly, Tolerant Networks Ltd This presentation will alert participants to the EU Commission's New Generation Internet (NGI), to NGI funding opportunities, and to project support available from the NGI-Zero coalition led by the NLnet Foundation. Tolerant Networks Ltd is a partner in NGI-Zero. C. From Peering Manager features to standalone library Guillaume Mazoyer, Peering Manager Lead Developer During the process of writing the integration code for Peering Manager and IX-API, an opportunity arose to extract the relevant features from the main code base and create a separate library. As a result, pyixapi was born, providing a user-friendly and straightforward interface for interacting with IX-API endpoints. D. BIRD 2 - Overview and Future Outlook Ondřej Zajíček, CZ.NIC Five years ago, we released BIRD 2, the major overhaul of BIRD Internet Routing Daemon. I will recapitulate recent BIRD development, present new interesting features, and discuss the future outlook of BIRD development, including the upcoming multithreaded BIRD 3. E. Update from Route Server Support Foundation Niels Raijer, Chairman RSSF Why RSSF is there, the technological advances in OpenBGPD and rpki-client and a surprising way in which we received some funding. F. Lightning Talks These are short updates on different relevant OpenSource projects. They should be 5 mins (preferably) with a maximum of 10 mins(if space allows). No formal submission required ahead of RIPE, but please send a short message to opensource-wg-chairs(a)ripe.net by noon on Tuesday during the RIPE if you want to present an update. Selection of talks are done on Tuesday afternoon.

1 0

Fwd: Maintaining the Maintainers 🛠️ Open Collective is employing FLOSS developers
by Vesna Manojlovic 06 May '23

06 May '23

I hope you find this information relevant & informative. === Creating a Healthier Ecosystem Open Source Collective was created to help build a healthier and more sustainable ecosystem for open source creators. And a big part of that is personal health. Many open source projects that we love and rely on are maintained and updated by a small group of people, or sometimes just one. The tasks they need to do vary, but the demands on their time can build up fast. Some maintainers might want to devote more time to this kind of work, but fear losing the healthcare and benefits that come with their regular job. This is why OSC is now looking to employ maintainers on select sufficiently-funded projects, providing them with access to things like paid annual leave, healthcare, and sick leave. That way, they can spend more time maintaining their project, and supporting the wider community. Find out more: https://opencollective.com/opensource/updates/open-source-collective-is-hir… https://docs.oscollective.org/what-we-offer/employment-payroll-and-benefits

1 0

Fwd: Request for Implementation Partners for the Bug Resilience Project
by Vesna Manojlovic 02 May '23

02 May '23

I hope you find this information relevant & informative. === From: Sovereign Tech Fund <info(a)sovereigntechfund.de> Dear readers, The Sovereign Tech Fund is pleased to announce a request for partners to help implement a responsible bug bounty program, titled the Bug Resilience Project, to empower small and medium-sized open source projects to lower their risk of harboring bugs and improve their capacity to respond to bugs as they are discovered. The program will provide services to FOSS projects such as helping projects deal with technical debt, working on known security issues, implementing responsible vulnerability disclosure processes, as well as offering a bug bounty for researchers that discover bugs and report them responsibly. We are now accepting applications from interested organizations to partner with us in the implementation of the Bug Resilience Project. We are looking for partners who share our vision of strengthening the open source ecosystem and who are committed to promoting a balanced incentive structure for projects and researchers that fosters an equal and mutually beneficial working relationship. If your organization is interested in becoming a partner for the implementation of the Bug Resilience Project, you can apply to one or more of the following work packages. To find more information on our Bug Resilience Project concept or how to apply, please follow the links below: Work Package 1: Lowering Technical Debt in Participating FOSS Projects and fixing known issues https://www.dtvp.de/Satellite/public/company/project/CXP4YWL6ZF6/en/documen… Work Package 2: Implementing Responsible Bug Disclosure Processes https://www.dtvp.de/Satellite/public/company/project/CXP4YWL6ZFH/en/documen… Work Package 3: Manage a bug bounty program https://www.dtvp.de/Satellite/public/company/project/CXP4YWL6ZF5/en/documen… We look forward to hearing from you and working together to make the open source ecosystem more secure and resilient. Best, the STF team Sovereign Tech Fund Newsletter by Sovereign Tech Fund Lagerhofstr. 4 Leipzig, Sachsen 04103 Germany

1 0

RV: Webinars on software supply chain
by Marcos Sanz 21 Apr '23

21 Apr '23

All, attached some info on a series of webinars on the supply chain management organized by the NLnet colleagues, which I think could be of interest to the wg. Recordings of the two past webinars are available online (s. link further down). Also further down you'll details on the two upcoming ones. Enjoy and have a nice weekend! Marcos > NLnet and NGI Zero/NGI Assure are organising a series of webinars on > *Open Software Supply Chain management*. As the dependency of society > on technology continues to increase in every possible direction, it is of the > utmost importance to understand the dynamic life cycle of the free and open > source building blocks that form the basis of pretty much all technology we > use today - and how these can be kept safe and available. > > Not only do we need to improve our understanding of how and where > software is developed, maintained, built and deprecated at macro scale - but > we also need to create mechanisms to ensure that building blocks are kept > up to date, that different versions don't collide, FOSS packages from public > repositories have not "bit-rotted" or even worse: have been tampered with > by malicious actors as part of a "supply chain attack". There has been an > increasing attention to the fact that with software "eating the world", a > healthy and robust software ecosystem should be a key societal (and thus > political) priority. But at the same time, we should do so with full > understanding of the highly specific nature of "digital commons" - as the > controversy surrounding the upcoming Cyber Resilience Act clearly proves. > > In this series of webinars by leading experts such as Armijn Hemel (Tjaldur), > Shane Coughlan (OpenChain), Carlo Piana (OSI), Alberto Pianon (FSFE) and > Philippe Ombredanne (AboutCode) we look at software supply chains from > different angles. What do modern electronics supply chains look like, how is > provenance handled - and how *should* it be handled? What mechanisms > do we have to verify the integrity of deployed code packages and detect > abnormal code changes that may be signs of malicious modifications and > possible attacks? Where do "Software Bill of Materials" come into play? And > what is being done, and perhaps should be done from a legislative and > governance point of view? > > The entire webinar series is available free of charge, and will allow you a > deep dive into the hidden world behind the software and hardware we use - > and will help you get a clear understanding of how open source supply chains > work, and a grasp of what the policy challenges are. > > You can join the webinars via this BigBlueButton link: > > https://bbb.protagio.nl/b/ron-qed-tog-gey -- > The other episodes in the webinar series on Open Software Supply Chain > management are: > > * Thursday May 4th 2023 // 13.00 - 14.30 CEST (Amsterdam, Berlin, Rome) > > - Speakers: Carlo Piana & Alberto Pianon. > - Topic: The importance of a Software Bill of Materials in light of the > upcoming Cyber Resilience Act and product liability legislation in Europe. > - More info: > https://nlnet.nl/events/20230504/WebinarSoftwareSupplyChain-ep3 > > * Thursday May 11th 2023 // 13.00 - 14.30 CEST (Amsterdam, Berlin, Rome) > > - Speaker: Shane Martin Coughlan > - Topic: ISO standards and certification. (This talk was previously scheduled > for April 27). > - More info: > https://nlnet.nl/events/20230511/WebinarSoftwareSupplyChain- > ep4/index.html > > The first episode with Armijn Hemel already took place on April 6th, with the > topic of Open Source in (Consumer) Electronics Supply Chains. You can find > the link to the recording here: > > https://nlnet.nl/events/20230406/WebinarSoftwareSupplyChain/index.html > > Looking forward to see you there! > > the NLnet team

1 0

Opensource-WG: Call for Presentations (RIPE 86, 22-26 May)
by Martin Winter 13 Mar '23

13 Mar '23

The next RIPE Meeting is coming up - your chance to present about some interesting Open Source If you would like to give a presentation during the OpenSource WG session, then please contact us (the WG chairs). In general, each talk is 15-30 mins (depending on how much time is needed). If you have some idea and not sure how/if you should present something then feel free to contact us as well to discuss the idea. For small project updates, we are planning to reserve 30 mins again at the end of the WG session. These short 5..10(max) min updates/talks are decided on the day before the WG session on a time/space available base. No need to submit anything for these talks at this time. Thanks, Martin Winter, Marco Sanz & Ondrej Filip OpenSource WG Chairs

1 0

concern re: Cyber Resilience Act effects on open source?
by Maarten Aertsen 29 Nov '22

29 Nov '22

good afternoon list, I would like to understand the number of people/organisations on this list who are concerned about the European Commission's Cyber Resilience Act proposal effects on open source software development. This topic was presented at RIPE85 [1] and covered in a recent blog (see below, should have cross-posted), which was republished at RIPE Labs last week: https://labs.ripe.net/author/maarten-aertsen/open-source-software-vs-the-pr… You would help both me and RIPE NCC staff that are tracking the proposal by speaking up on list. Answers by both developers and users are valuable. A simple +1 is fine. Thanks. kind regards, Maarten -------- Forwarded Message -------- Subject: Re: [cooperation-wg] Cyber Resilience Act effects on OSS on agenda of open source-wg Date: Mon, 14 Nov 2022 09:38:00 +0100 From: Maarten Aertsen <maarten(a)nlnetlabs.nl> To: cooperation-wg(a)ripe.net Good morning, I just published an extended, written version of my RIPE talk in the open-source wg [1] with NLnet Labs' perspective on the European Commission's proposal for a Cyber Resilience Act vs. Open Source: https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act/ We feel the current proposal misses a major opportunity. The CRA could bring support to open-source developers maintaining the critical foundations of our digital society. But instead of introducing incentives for integrators or financial support, the current proposal will overload small developers with compliance work. At the same time, this is only the Commission's proposal. I hope there is opportunity to raise awareness and influence the coming positions and negotations. I'm very grateful to the many people in the RIPE community that talked to me after my presentation. I feel my understanding of the issue is improving. Curious to hear what you think, how you feel this affects the projects you rely on and what we have yet to learn about the implications. kind regards, Maarten [1] https://ripe85.ripe.net/archives/video/911 -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/cooperation-wg

5 6

Minutes of RIPE85 opensource wg meeting
by Marcos Sanz 22 Nov '22

22 Nov '22

Dear all, the minutes of the session are online now: https://www.ripe.net/participate/ripe/wg/active-wg/os/minutes/open-source-wo rking-group-minutes-ripe-85 Have a great start in the day Marcos

1 0

Draft Agenda Open Source WG RIPE 85
by Marcos Sanz 10 Oct '22

10 Oct '22

Dear all, please find attached the draft agenda for our upcoming working group meeting during RIPE 85. Looking forward to meeting you all there, Martin Winter & Ondrej Filip & Marcos Sanz Open Source WG Chairs ---- Agenda RIPE 85 Open Source WG Session Wednesday, October 26, 10:30 - 11:30 (CEST) A. Administrative Matters * finalize agenda * approval of minutes from previous WG meeting(s) * review of action list B. "Cyber Resilience Act effects on OSS", Maarten Aertsen, NLnet Labs NLnet Labs is closely following a legislative proposal by the European Commission affecting almost all hardware and software on the European market. The Cyber Resilience Act intends to ensure cybersecurity of products with digital elements by laying down requirements and obligation for economic operators. In this short talk you'll learn what to expect in the Cyber Resilience Act and why this proposal may matter to you as a developer or user of open source software. If so, let's make sure that policy makers take into account its effects on open source development by professional organisations and volunteers alike. Do get in touch with Maarten when you have similar concerns, want to team up or can help us to provide technical expertise in the right places. C. "Infrastructure as code: Managing IXP services using terraform and the IX-API", Annika Hannig The fabric of the internet in recent years has become more and more flexible. Software defined networking enabled us to provision network services in the blink of an eye. Providing services on the internet nowadays involves, rather sooner than later, dealing with things like virtual circuits, peering and route servers. All this is now part of your infrastructure - just like the cloud compute instances where you are running your applications. In this talk I will cover what is what is infrastructure as code and what is terraform. How can you benefit from this, and how this tool can be used to provision services on an IXP using the IX-API. D. "ARTEMIS: An Open-Source Tool for Detecting BGP Prefix Hijacking", Lefteris Manassakis, Code BGP ARTEMIS (Automatic and Real-Time dEtection and MItigation System) is an open-source tool to monitor, detect, and mitigate BGP hijacks. In this talk, after a short introduction to the project, we will demonstrate ARTEMIS, how it works, and how network operators can use it for real-time BGP hijacking detection. E. Lightning Talks These are short updates on different relevant open source projects. They should be 5 mins (preferably) with a maximum of 10 mins (if space allows). No formal submission required ahead of RIPE, but please send a short message to opensource-wg-chairs(a)ripe.net by noon on Monday during the RIPE if you want to present an update. Selection of talks are done on Monday afternoon.

1 0