- opensource-wg - mailman.ripe.net

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