Author: Matthew Miller (page 2 of 5)

Help shape the Fedora strategy

The Fedora.Next strategy was a key part of the success we’ve enjoyed over the last few years. But we can’t stop there. It’s time to develop a strategy to meet our goal for the next five years: doubling the number of active contributors. To do this, there are a number of technical and community objectives we need to drive. It looks like that number is 18. The Fedora Council developed a list of 18 objectives to support the impacts we’re looking for. Now it’s your turn. Let us know what you think in the Discussion thread.

This is just the first step. We’re looking for discussion at a high level. Over the next few months, we’ll have a thread dedicated to each objective. Once we’ve had a chance to discuss it together, the Council will vote on the final strategy. From there, we’ll start working on the details to make these objectives a reality. I’m super excited to work on this with you.

Fedora Code of Conduct Report 2022

We publish a summary report of Code of Conduct activity each year. This provides transparency to the community. It also shows that we take our Code of Conduct seriously. In 2022, warnings and moderations increased over the previous year, with a slight reduction in total reports.

Continue reading

Help decide how to handle tags on merged Ask Fedora + Fedora Discussion

We are in the process of merging our user-support forum Ask Fedora into Fedora Discussion — our site geared towards contributor and project team conversations. Historically, we’ve used tags differently on those two sites. This means we need to figure out an approach for combining them. Please take a look at the Adding -team to (almost) all of the tags in Project Discussion? thread and add your thoughts.

Continue reading

Important changes to software license information in Fedora packages (SPDX and more!)

On behalf of all of the folks working on Fedora licensing improvements, I have a few things to announce!

New docs site for licensing and other legal topics

All documentation related to Fedora licensing has moved to a new section in Fedora Docs, which you can find at https://docs.fedoraproject.org/en-US/legal/. Other legal documentation will follow. This follows the overall Fedora goal of moving active user and contributor documentation away from the wiki.

Fedora license information in a structured format

The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are now stored in a repository, using a simple structured file format for each license (it’s TOML). You can find this at https://gitlab.com/fedora/legal/fedora-license-data. This data is then presented in easy tabular format in the documentation, at https://docs.fedoraproject.org/en-US/legal/allowed-licenses/.

Historically, this information was listed in tables on the Fedora Wiki. This was hard to maintain and was not conducive to using the data in other ways. This format will enable automation for license validation and other similar process improvements.

New policy for the License field in packages — SPDX identifiers!

We’re changing the policy for the “License” field in package spec files to use SPDX license identifiers. Historically, Fedora has represented licenses using short abbreviations specific to Fedora. In the meantime, SPDX license identifiers have emerged as a standard, and other projects, vendors, and developers have started using them. Adopting SPDX license identifiers provides greater accuracy as to what license applies, and will make it easier for us to collaborate with other projects.

Updated licensing policies and processes

Fedora licensing policies and processes have been updated to reflect the above changes. In some cases, this forced deeper thought as to how these things are decided and why, which led to various discussion on Fedora mailing lists. In other cases, it prompted better articulation of guidance that was implicitly understood but not necessarily explicitly stated. 

New guidance on “effective license” analysis

Many software packages consist of code with different free and open source licenses. Previous practice often involved  “simplification” of the package license field when the packager believed  that one license subsumed the other — for example, using just “GPL” when the source code includes parts licensed under a BSD-style license as well. Going forward, packagers and reviewers should not make this kind of analysis, and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach is easier for packagers to apply in a consistent way. 

When do these changes take effect?

The resulting changes in practice will be applied to new packages and licenses going forward. It is not necessary to revise existing packages at this time, although we have provided some guidance for package maintainers who want to get started. We’re in the process of planning a path for updating existing packages at a larger scale — stay tuned for more on that!

Thank you everyone!

A huge thanks to some key people who have worked tirelessly to make this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav Suchý. Behind the scenes support was also provided by David Levine, Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable feedback from Fedora community members in various Fedora forums. 

Please have a look at the updated information. If you have questions, please post them to the Fedora Legal mailing list: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/ 

Upcoming downtime for Fedora Discussion

Almost three years ago, we moved the existing Ask Fedora site from an engine which attempted to replicate Stack Exchange to a new system (the current Ask Fedora) based on Discourse, a modern open source web forum platform. We had some frustrations with the software, and the Stack-Exchange-like approach wasn’t really working for us. This has been a huge success, and the new Ask is incredibly popular.

At the same time, we also tried an experiment — we set up Fedora Discussion as a parallel site for community and project conversations. This goes hand-in-hand with the (soft-launch, but we’re getting there) Matrix-based Fedora Chat service — Discussion for longer-form, long-lasting asynchronous communication, and Chat for synchronous connections.

This experiment has gone well, and we have solid and increasing use, with several different Fedora teams (including Fedora Council and CommOps) making it their primary place for communication. We’ve had some nice improvements over time as we’ve learned to use the system (not to mention a nice new logo from Máirín Duffy and the Fedora Design Team). But, the site’s basic structure is still what we arbitrarily came up with when we first launched it: kind of a mishmash of categories and concepts. As we’ve had more requests to use the site, it’s become increasingly clear that these early decisions don’t match what we need.

So, I’m going to take the opportunity of the end-of-year break to do a big reorganization. You can read the background and details, and follow along with my task-list if you like. The important details are: I’m going to do most of the work behind the scenes on a temporary staging site, but there’s a lot of shuffling so I’m not sure how long it will take. I plan to put the current site into read-only mode on the 27th or 28th of December, and have it back up and running by January 1st.

When that’s done, we’ll have a structure that will better handle discussion in all the different areas and teams that comprise the whole Fedora Project. I expect this to continue to grow in the years to come, as part of our overall effort to keep Fedora relevant and growing. (Of course, HyperKitty is still there for more traditional mailing lists — Discourse has a fairly decent email interaction model, but it’s definitely web-first in approach.) More about all of that when the new site is in place and ready to show off!

(Oh, and one more thing — based on discussion and broad community consensus, we’re actually planning to merge the two Discourse sites, Ask and Discussion, so that we have both user and contributor conversations close together. This reorganization will make that easier, but we’re not ready for that for a while yet.)

Retiring Taiga instance on teams.fedoraproject.org

When we launched teams.fedoraproject.org a few years ago, we were excited to financially support a great open source project while also providing project management tooling to the community. However, the adoption rate has been pretty low and we have several other tools available. Maintaining redundant tools isn’t a good use of our time and resources, so our Taiga instance will shut down on December 17.

Continue reading

I’m looking for YOUR stories from Fedora history

Hey everyone! In a couple of weeks, I’m going to be giving a talk at Open Source Summit called “35 Fedora Releases in 30 minutes“.

This is basically going to be a whirlwind tour of our history. I was there for a lot of it, but not all, and certainly not from all perspectives. In preparation, I’d like to get more of your input. If you’re interested in sharing what you remember about Fedora Core 3 (Heidelberg), or Fedora Linux 8 (Werewolf!), or even F23 or F27 or whatever, or anywhere in between, I’d love to hear from you.

If you’ve got something interesting to share, please contact me. Reply to this post, send me a message to @mattdm:fedora.im on matrix, send email, tweet at me, etc. We can set up a video call, or you can just send ideas, or whatever.

Special thanks to Nest Platinum Sponsor Amazon AWS

It takes a lot of work to put on our annual contributor conference. Special thanks this year to Amazon AWS for their platinum sponsorship! We really appreciate their generosity, as well as the support and resources for Fedora Cloud, Fedora CoreOS, and more.

Fedora’s default license for content is now CC BY-SA 4.0

The Fedora Project Contributor Agreement (FPCA), which all Fedora contributors sign, exists to make sure that everything in the project is licensed in accordance with our “Freedom” value. The FPCA includes a provision which allows the Council to update the default license for either “code” or “content”:

The Fedora Council may, by public announcement, subsequently designate an additional or alternative default license for a given category of Contribution (a “Later Default License”). A Later Default License shall be chosen from the appropriate categorical sublist of Acceptable Licenses For Fedora.

The Fedora Council has approved a change from from the Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) license to the Creative Commons Attribution-ShareAlike 4.0 (CC BY-SA 4.0) license for material classified as “content”. This message is the official public announcement of that change, which is effective as of today, the 13th of May 2021.

This license applies to content (not code) submitted to Fedora that does not have an explicit license attached. The FPCA is not a copyright assignment, and does not override the explicit license choices of contributors or upstream projects.

Fedora Council March 2021 meeting

In a normal year, the Fedora Council would have held a one-day meeting in Brno the day after DevConf.CZ. Since this isn’t a normal year, we held a half day virtual face-to-face earlier this month. Unlike the longer November meeting, this meeting focused on catching up on a few things instead of larger strategy planning. As usual, the minutes have been fed to Zodbot.

Continue reading
Olderposts Newerposts

Copyright © 2024 Fedora Community Blog

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.

Theme by Anders NorenUp ↑