#121 Request for final approval of third party software proposal
Closed: approved a year ago Opened 2 years ago by uraeus.

I went over and tried to clean up the last few items from the 3rd party software proposal. There are a few TBDs left, but not something I think is needed to move this out of draft status.

https://fedoraproject.org/wiki/Workstation/Third_party_software_proposal


I have some minor feedback that in all likelly should not halt this from moving forward (as there are many TBDs in the document):

  • In "Other requirements and considerations" it seems that working groups must sponsor in software but that software upstreams are responsible to notify on changes in ownership of repositories. If this is an accurate reading, does this also mean that no software is allowed in tier 2 that isn't supported by a proposal from an upstream to a Fedora working group? In other words, a Fedora working group is not allowed to put something in tier 2 without approval from the upstream?

  • In "Technical requirements and Submission guidelines: Rules for software packaged as RPMs" it is said that "RPM packages in a third party repository must not break dependencies or otherwise replace packages provided by official Fedora repositories." How does this rule affect vendoring or software that requires older versions of packages?

  • It may be appropriate to replaces references to Docker with Moby in places. I first noticed this In "Technical requirements and Submission guidelines: Registries and similar tools"

  • I understand that the guidelines for FESCo listed in "Technical requirements and Submission guidelines: Replacing a different package format" are not meant to be in a strict order, however, the current ordering of bullets 2 and 3 implies that upstream packaging is preferred over Fedora packaging. Is this the case?

  • I believe it is would be appropriate to call out the need for working groups to establish policies for the "review procedures to ensure users are not provided dead or deprecated repositories." This could be done in a separate section written for working groups that wish to add third-party software and could include the requirements for the review process.

All in all I like the proposal and its current state. It is very RPM centric and it would be interesting to see at least one non-RPM software source explored in the document to see if there are any gotchas or conflicts. Given the current technical challenges, I believe that container images may be the best choice as i think we could set up a federating registry using Pulp if that is a good way to handle the "single source of truth about third-party software repositories" for this format.

I have some minor feedback that in all likelly should not halt this from moving forward (as there are many TBDs in the document):

In "Other requirements and considerations" it seems that working groups must sponsor in software but that software upstreams are responsible to notify on changes in ownership of repositories. If this is an accurate reading, does this also mean that no software is allowed in tier 2 that isn't supported by a proposal from an upstream to a Fedora working group? In other words, a Fedora working group is not allowed to put something in tier 2 without approval from the upstream?

I wouldn't make it absolute, but in practice the amount of repos we would be able to track which doesn't have the support of the upstream (the upstream being a repository) is very limited, so that would be the best practices effort.

In "Technical requirements and Submission guidelines: Rules for software packaged as RPMs" it is said that "RPM packages in a third party repository must not break dependencies or otherwise replace packages provided by official Fedora repositories." How does this rule affect vendoring or software that requires older versions of packages?

Well as long as they rely on or provide compat packages that would be ok, but they can of course not 'lock' a package version into an older one. Also if this is the case we would strongly recommend the vendor doing a flatpak instead as it is more suitable for that kind of usecase.

It may be appropriate to replaces references to Docker with Moby in places. I first noticed this In "Technical requirements and Submission guidelines: Registries and similar tools"

No objection to that, hopefully someone more familiar with the Docker/Moby ecosystem can take this on as I am not 100% clear myself when it would be best to talk about Moby and when it would be best to talk about Docker.

I understand that the guidelines for FESCo listed in "Technical requirements and Submission guidelines: Replacing a different package format" are not meant to be in a strict order, however, the current ordering of bullets 2 and 3 implies that upstream packaging is preferred over Fedora packaging. Is this the case?

In an ideal world I think the answer would be yes, in practice though I am not sure if an absolute rule can be made here as it will probably always come down to an evaluation of strength and dedication of upstream vs strenght and dedication of Fedora packager(s) in question.

I believe it is would be appropriate to call out the need for working groups to establish policies for the "review procedures to ensure users are not provided dead or deprecated repositories." This could be done in a separate section written for working groups that wish to add third-party software and could include the requirements for the review process.

All in all I like the proposal and its current state. It is very RPM centric and it would be interesting to see at least one non-RPM software source explored in the document to see if there are any gotchas or conflicts. Given the current technical challenges, I believe that container images may be the best choice as i think we could set up a federating registry using Pulp if that is a good way to handle the "single source of truth about third-party software repositories" for this format.

Well RPM's are a known entity so it is easier to finalize on them, a lot more open questions about flatpaks, OCI and moby images. To me the importance of the document is more to outline the general principles we are working by as opposed to a detailed tutorial on how we plan every process to work. This is also why I am not to concerned about the TBDs as they are to me more of the type filling in some practical details as we go along as opposed to big principle based issues.

I don't like the

Repositories that mix applications with different purposes are not permitted.

rule. This would rule out RPMFusion, which is probably not intended.

I don't like the

Repositories that mix applications with different purposes are not permitted.

rule. This would rule out RPMFusion, which is probably not intended.

That is actually very much intended. The is a legal limitation, to mitigate having to continually review additions. IIRC, this restriction is a requirement to make this entire proposal feasible at all.

RPMFusion doesn't have the resources to maintain 20 or more separate repositories. This simply doesn't scale. I'd also argue that RPMFusion is the largest value third party software source, so if you exclude it, what other third party software sources are you expecting to get on board given the proposed rules?

RPMFusion doesn't have the resources to maintain 20 or more separate repositories. This simply doesn't scale. I'd also argue that RPMFusion is the largest value third party software source, so if you exclude it, what other third party software sources are you expecting to get on board given the proposed rules?

I cannot be any clearer about this, but RPMFusion and repositories like it are explicitly NOT in scope for this proposal.

Other software sources that are would be things like Chrome, flash, the h264 codec, or any other software provider that ships a single piece of software.

I don't like the
Repositories that mix applications with different purposes are not permitted.
rule. This would rule out RPMFusion, which is probably not intended.

That is actually very much intended. The is a legal limitation, to mitigate having to continually review additions. IIRC, this restriction is a requirement to make this entire proposal feasible at all.

Legal quote needed.

I don't think any 3rd party repository can be tight by a rule that even Fedora could not follow.

Fedora does not "legal review" every single package that are introduced at one point in time in the whole repository. Instead if a package is introduced into the fedora repositories that does not meet the guidelines, the appropriate action is taken. If needed , the package can be removed once escalated to the appropriate channel.

3rd part repositories cannot be tight to a rule that is stricter than what's apply to fedora in that concern. Specially as Fedora isn't redistributing the software itself. The main point is to have a clear statement for the 3rd part repository about how to deal with such situation.

As soon as RPM Fusion is concerned the statement is available here:
https://rpmfusion.org/FoundingPrinciples
This is currently mainly inspired by guidelines needed by RPM. But we might consider Modules, Docker, Flatpak at some point.

Now based on such a weird false premise you should re-design the entire proposal from the ground. Basically allowing the entire RPM Fusion free/nonfree as a possible repository of choice for users.

While I am mostly agreeing with kwizart, I want to point out some things that make it impossible for me to give a +1 to the proposal. You assume we have a low userbase because we don't offer third party software directly, which is not proved and a blogpost is just a personal opinion. I know many people instead, who are using Fedora "because" it is completely free of third party and non free software, that's our strength and I want to keep this feature (we are unique by offering this kind of distro). And yes, users use third party software in some cases, but they do that on their own risk (packages exist and are very easy to install) and Fedora is not in any way responsible for any kind of issue they might encounter.
The whole proposal flies around third party repos without giving clear guidelines or rules. There is always an assumption things should not go that way but the other way, which is rather nebulous IMHO. Furthermore there is no guarantee third party software is not replacing official RPMs with their own releases, which is a no-go for me.
You mention COPR, but COPR has very clear rules and can not offer non free packages.

Finally, I disagree, but I understand this is a proposal only for Workstation, other spins don't have to follow the same guidelines. We should consider that at least for release blocking spins.

While I am mostly agreeing with kwizart, I want to point out some things that make it impossible for me to give a +1 to the proposal. You assume we have a low userbase because we don't offer third party software directly, which is not proved and a blogpost is just a personal opinion. I know many people instead, who are using Fedora "because" it is completely free of third party and non free software, that's our strength and I want to keep this feature (we are unique by offering this kind of distro). And yes, users use third party software in some cases, but they do that on their own risk (packages exist and are very easy to install) and Fedora is not in any way responsible for any kind of issue they might encounter.

This will not change with this proposal, nobody is suggesting we pre-load Fedora with non-free software. The proposal is about listing items in the software store for users to download.

The whole proposal flies around third party repos without giving clear guidelines or rules. There is always an assumption things should not go that way but the other way, which is rather nebulous IMHO. Furthermore there is no guarantee third party software is not replacing official RPMs with their own releases, which is a no-go for me.

That would be a break with the policy and if that happens the 3rd party software repo would be removed. Also over time we hope/expect 3rd parties to ship containers like flatpak or OCI, so the (small) risk of this happening is a transitional one.

You mention COPR, but COPR has very clear rules and can not offer non free packages.
Finally, I disagree, but I understand this is a proposal only for Workstation, other spins don't have to follow the same guidelines. We should consider that at least for release blocking spins.
It is a policy that any edition or spin can make use of, so while it is not only for workstation it does allow the workstation to experiment with listing important 3rd party software in its software store.

That would be a break with the policy and if that happens the 3rd party software repo would be removed.

How long would it take us to realize a 3rd party repo has been infected with spyware and to remove it? What would be the impact of such situation to our brand/community?

That would be a break with the policy and if that happens the 3rd party software repo would be removed.

How long would it take us to realize a 3rd party repo has been infected with spyware and to remove it? What would be the impact of such situation to our brand/community?

This is a strawman, but we can certainly discuss. I would posit that we'd notice spyware in a third party repo faster than we would in the Fedora repos.

We have implicit trust in our process for Fedora reviews, but there is 0 after-review policing of content. This provides ample opportunity for anyone to upload spyware to a package. There was an experiment done several years ago where this was attempted. Nobody noticed. It is exacerbated by the fact that there are multiple orders of magnitude more packages in the Fedora repo than a third party repo would have as outlined by this policy.

I don't like the
Repositories that mix applications with different purposes are not permitted.
rule. This would rule out RPMFusion, which is probably not intended.

I don't actually remember the exact intent behind the wording here, so it would probably be good to edit it. I think the intent was to make the contents of the repo predictable for the working group to decrease the amount of policing needed. EDIT: Actually upon thinking about it while driving I came to the conclusion that the mixing referred to here was between for instance desktop and server software. I think the repositories needs to make sense on a basic level for this to stay maintainable and not have 'random' software grouped together.
That said RPMFusion is as Josh says problematic for other reasons, although we could potentially have a subset of RPMfusion included. But as the other text points out, having multiapps repos is problematic because if we find 1 thing in there that is problematic we would have to pull the entire repo. So let for instance say there is a patent issue, if each app was in a separate repo this would not be a huge issue as you just disable/drop the 1 repo with the 1 app, but if you have a big collection of things then suddenly 50+ apps might become unavailable and not updateable. And in a perfect storm situation there might be a crucial security update users will not get access to due to an unrelated application making the whole repo unavailable.

That is actually very much intended. The is a legal limitation, to mitigate having to continually review additions. IIRC, this restriction is a requirement to make this entire proposal feasible at all.

Legal quote needed.
I don't think any 3rd party repository can be tight by a rule that even Fedora could not follow.
Fedora does not "legal review" every single package that are introduced at one point in time in the whole repository. Instead if a package is introduced into the fedora repositories that does not meet the guidelines, the appropriate action is taken. If needed , the package can be removed once escalated to the appropriate channel.
3rd part repositories cannot be tight to a rule that is stricter than what's apply to fedora in that concern. Specially as Fedora isn't redistributing the software itself. The main point is to have a clear statement for the 3rd part repository about how to deal with such situation.
As soon as RPM Fusion is concerned the statement is available here:
https://rpmfusion.org/FoundingPrinciples
This is currently mainly inspired by guidelines needed by RPM. But we might consider Modules, Docker, Flatpak at some point.
Now based on such a weird false premise you should re-design the entire proposal from the ground. Basically allowing the entire RPM Fusion free/nonfree as a possible repository of choice for users.

But RPMfusion exists to exactly handle stuff that couldn't go into Fedora, and funnily enough free is thus the biggest problem. Non-free might be acceptable as a 3rd party repo, but the problem is as I pointed out above that it creates a lot of overhead for the working group who needs to police it and the risk of 1 problematic app causing us to need to drop the whole repo.

We have implicit trust in our process for Fedora reviews, but there is 0 after-review policing of content. This provides ample opportunity for anyone to upload spyware to a package. There was an experiment done several years ago where this was attempted. Nobody noticed. It is exacerbated by the fact that there are multiple orders of magnitude more packages in the Fedora repo than a third party repo would have as outlined by this policy.

This is all true indeed, but one of the vertue of our system is its openness, it's also one of the "selling" points of FOSS that it being open more people can see/examine the code and find issues. While I believe the 3rd party vendors considered here are not being so open about their practices.
So while in practice you are most probably right, there is still that one system allowing for audit while the other only support reverse-engineering.

Just to keep people updated, I just spoke with Matthew Miller about this, so what I will do is try to split the document in two. One being a policy document which is what the council should care about, and the second being a guidelines document that is more talking about implementation details. The TBDs should be able to move into the guidelines document and thus the policy document should look cleaner. It also should enable the guidelines document to be more of a living document as opposed to something that needs ongoing council review as we establish best practices.

It may be appropriate to replaces references to Docker with Moby in places. I first noticed this In "Technical requirements and Submission guidelines: Registries and similar tools"

No objection to that, hopefully someone more familiar with the Docker/Moby ecosystem can take this on as I am not 100% clear myself when it would be best to talk about Moby and when it would be best to talk about Docker.

Docker refers to Docker, Inc. the sellers of a supported container runtime ecosystem.

Moby refers to the open source project formerly known as docker.

I suspect there is no reason to mention the word "Docker" anywhere in this document. The only exception would be "docker" (lower-case d) when referencing the command in the moby project.

Ok, document is now split and all references to Docker has been replaced by Moby, only exception being a paranthesis saying that Moby images are also known as Docker images. Hopefully document should be ready for approval now.

Okay, calling for consensus votes on this - need three +1s and no -1s by next Wednesday. Any council members who need more time or have major issues please say so sooner rather than later.

I don't see the document has improved in any way.
I see failures to justify in many occurrences, including in comments in this thread.

Again, what if you would find a patent issue in a fedora package ? Do you plan to disable the whole fedora repository itself ? So this doesn't hold. And even, this make the honesty of the argumentation questionable.

Everything else is broken because of this false assumption. And also broken is that the patent concern apply to anything that fedora do not redistribute itself, but only point at. This is not the answer I got when asking. So I'm again asking from Legal clarification on this particular topic.

If this guideline would be to be accepted as it is, then it would be easier for us to produce fedora remix having our community repositories enabled by default than trying to breaks packages into small repositories pieces. I would like to avoid that, but the shortest path to the goal apply.

Please Councils members, don't be afraid to request clarifications and vote -1 to the current proposal.

In the Fedora repositories we have full control and thus if a package if found to have problems and legal asks us to remove it we have the ability to do so immediately, even if the package maintainer objects. That is a fundemental difference.

@kwizart I don't quite understand what you are saying with your second concern starting "And also broken...". Can you clarify this?

I agree with @uraeus that there's a fundamental difference in our control over our own repositories and I really think single-package third-party repos is likely the best compromise we can find.

Ok, I have read the updated document, but still have many concerns as it is mainly the same as before. I wanted to reply soon to get clarifications and improvements, because as per today I would give my -1 to it. I am saying that mainly because I feel we are approving some very important rules, which are still rather nebulous and generic. I fear they will give freedom to interpret them in very different ways and result in having packages and repos inside our distro which are against our 4Fs and the Mission Statement. (please don't say we will take care about that....we need rules for this)

  • The assumption we have less users just because we are not a copy of Ubuntu is not based on any concrete data. A blogpost is nothing and there are many examples where people say they use Fedora because it is totally free and open source.
  • Legal requirements are not defined and the sentence in the proposal is very generic. Can legal chime in and give us their POV? I feel there are some hurdles if we point to third party repositories not hosted by Fedora. Or which repos do you want to host? I feel that software like chrome will pretend to point to their repo. On the other side, if we host them on a Fedora mirror it is a legal issue because adobe does not permit that at all.
    Normally upstream does not permit to redistribute the software, what about improving lpf framework to work on that?
    If the proprosal is to only care about content or repo hosted by the fp.org, I don't think a 3rd party policy is the correct name
  • @uraeus said: In the Fedora repositories we have full control and thus if a package if found to have problems which is true for Fedora repos, but we can’t control anything outside the Fedora repos.
    It would be probably good to have a tier 3 for software packaged elsewhere, or?
  • I don’t understand why you speak about COPR, which is a Fedora thing with strict rules. You mention it in Tier 2, for what reason?
  • As far as I can understand the proposal, you want to split features into single repositories, but i.e. splitting video players and its dependencies into several repos would be annoying, and who will guarantee one of these dependencies does NOT replace an official Fedora package? And where do you draw the split? Probably you are mainly considering flatpak packages, and not RPMs.
  • All applications that ship as an RPM should conform as closely as possible with the RPM Guidelines found here: https://fedoraproject.org/wiki/How_to_create_an_RPM_package
    This means nothing to me, where to you draw the line of being close enough and not? I want to have these packages being conform with our guidelines, that would be a clear rule to me.
  • A software should only be added if it is stable. Adding development releases for third party software results in highly compromised systems. End users don’t know that and think they install something tested. The public opinion would be "Fedora is unstable and doesn't work", while in reality it is because you install a third party devel package
  • I would prefer an universal approach. This is a proposal for Fedora as a whole and not for workstation only. We have to decide if we really want to add this stuff to a free and open source distro or not. If we decide to go for it, this should apply also for desktop and functional spins, without exceptions.

I know I am not as technical as others here, but I care about our 4Fs and want to have things drawn into stone, without any possibility to interpret generic rules in other ways.

Additionally to what I said above, trying to reply technically, here is my ambassador/user/FOSS reply.
I feel all this proposal is because we want to copy Ubuntu, while there is nothing we need to copy from them. Ubuntu has its user base, Fedora has a different user base. Do we really want to become another click and click distro as the win-like Ubuntu?
I am worried about one of the most important Fs of our 4 foundations, freedom. It is not important to me if we include them officially in a repo or just point to them, although I know there is a big difference. Just offering non-free software links on Fedora makes me feel I am not anymore on a totally free and open source distribution.
We have this value and should be proud of it, nobody else is offering a totally free distribution to end users. Who is interested in non-free applications, already can install as many third party software as he wants, but this is something he is going to do on his own risk and it's not an option offered by Fedora (please note also here the big difference).
Finally, I really think having this option in the software manager is not vital for Fedora. Installing third party software already is very easy and we are not throwing away one of our big Fs the community was worried about when we published the new mission statement.

I will try to reply as best I can here.

The assumption we have less users just because we are not a copy of Ubuntu is not based on any concrete data. A blogpost is nothing and there are many examples where people say they use Fedora because it is totally free and open source.

First of all I find the insinuation that trying to make Fedora Workstation easier to use means 'being copy of Ubuntu' bit offensive. In general I would say that our efforts in trying to make Fedora Workstation more userfriendly has paid of in terms of significant growth in our userbase. One could always try to nitpick one or more of the changes done as being not important, but in general I think we shown very clearly since the introduction of Fedora Workstation that trying to make life better for our users is paying of in usage growth. If some people feel that wanting to have people use Fedora makes us 'a copy of Ubuntu' then so be it.

Legal requirements are not defined and the sentence in the proposal is very generic. Can legal chime in and give us their POV? I feel there are some hurdles if we point to third party repositories not hosted by Fedora. Or which repos do you want to host? I feel that software like chrome will pretend to point to their repo. On the other side, if we host them on a Fedora mirror it is a legal issue because adobe does not permit that at all.

It is essentially a catch all for Fedora/RH legal jumping in and telling us 'you have to stop this' or 'you have to change this'. If that happens we have to act, just like the Fedora project already has to act if that happens with something inside the Fedora repos.
As for your example of Chrome, there would be no pretending to point to their repo, we would just point to their repo as long as it conforms to our requirements like having appstream data, that is what this proposal is about.

Normally upstream does not permit to redistribute the software, what about improving lpf framework to work on that?
If the proprosal is to only care about content or repo hosted by the fp.org, I don't think a 3rd party policy is the correct name

This is not just about repositories hosted o fedoraprojec.org

@uraeus said: In the Fedora repositories we have full control and thus if a package if found to have problems which is true for Fedora repos, but we can’t control anything outside the Fedora repos.
It would be probably good to have a tier 3 for software packaged elsewhere, or?
I don’t understand why you speak about COPR, which is a Fedora thing with strict rules. You mention it in Tier 2, for what reason?
COPRs are Tier 2 in the sense that they are not part of the core Fedora repositories, but they are not 3rd party repos either.

As far as I can understand the proposal, you want to split features into single repositories, but i.e. splitting video players and its dependencies into several repos would be annoying, and who will guarantee one of these dependencies does NOT replace an official Fedora package? And where do you draw the split? Probably you are mainly considering flatpak packages, and not RPMs.

No the idea would not be to split out an application from its dependencies. The single repo setup is to avoid having lets say a pdf viewer application and a video player application in the same repo. And then lets say we get told by legal that the video player app poses a legal risk and we need to immediately stop providing the .repo pointer to it. In which case we also lose the non-problematic pdf viewer. An application here is defined in the same way its defined in GNOME Software, it is only considered an application if it got a .desktop file.

All applications that ship as an RPM should conform as closely as possible with the RPM Guidelines found here: https://fedoraproject.org/wiki/How_to_create_an_RPM_package
This means nothing to me, where to you draw the line of being close enough and not? I want to have these packages being conform with our guidelines, that would be a clear rule to me.

That line is mostly an attempt to provide a strong recommendation to 3rd party packagers to follow the best practices developed in the Fedora guidelines, but for many applications not being able to conform to those rules are part of the reason they are not in the current Fedora repos and thus making conforming to them a hard rule is basically rendering the proposal useless.

A software should only be added if it is stable. Adding development releases for third party software results in highly compromised systems. End users don’t know that and think they install something tested. The public opinion would be "Fedora is unstable and doesn't work", while in reality it is because you install a third party devel package.

I am personally not a huge fan of offering developement versions, but I do think that if we did decide to offer clearly marked developed versions of some core applications, especially as flatpaks, the impact or confusion would not be great.

I would prefer an universal approach. This is a proposal for Fedora as a whole and not for workstation only. We have to decide if we really want to add this stuff to a free and open source distro or not. If we decide to go for it, this should apply also for desktop and functional spins, without exceptions.

The rules are universal in the sense that once this proposal is approved any spin can choose to take advantage off them. The point is that if they don't want to we are not going to force them just because we want to try this out in the workstation edition.

I know I am not as technical as others here, but I care about our 4Fs and want to have things drawn into stone, without any possibility to interpret generic rules in other ways.

The proposal is trying to be as clear as possible, but be careful what you wish for here, because I have seen many organisations that over the years seem to drown themselves in detailed rules and life inside the group seems to be about hitting eachother over the head with the rules.

Repositories that mix applications with different purposes are not permitted.

The sentence above is quite unclear and I propose removing it. It doesn't explain what are "different purposes" or why such repos are not permitted.

Repositories that mix applications with different purposes are not permitted.

The sentence above is quite unclear and I propose removing it. It doesn't explain what are "different purposes" or why such repos are not permitted.

I believe @uraeus explained both that rule and the thinking behind it above. In other words, the policy doesn't permit third party repos that include (for example) a developer IDE app as well as a server monitoring utility. Given that he explained the reasoning, it would be better if you propose a rewording, rather than removing it.

Repositories that mix applications with different purposes are not permitted.

The sentence above is quite unclear and I propose removing it. It doesn't explain what are "different purposes" or why such repos are not permitted.

You keep objecting to the biggest mandate Legal has given this proposal. You need to understand that without the restriction to a single application per repository, this entire proposal will not pass the requirements that have been put in place.

Ok, I tried updating the text about single application repositories to be a big more flexible. I am not sure the changes really address the issues people have with it, but hopefully it is a bit more palatable and also explaining the reasoning a bit more. New text reads:

A yum repository may contain multiple applications. However, third parties are strongly recommended to ship their software in single application repositories as it will greatly increase chances of repository getting accepted for inlusion. Also doing this minimizes the risk of "collateral damage" if one piece of software must be de-listed from Fedora temporarily or permanently for legal or other reasons. A yum repository is a hard requirement for RPM packaged applications to be considered. Repositories that mix applications with different purposes are also strongly discouraged, for instance contains a mixture of desktop and server software. In the end which repositories are acceptable is left to the discretion of the working groups based on an evalution of technical and legal risks posed by a given repository, but as a general rule the easiest path to inclusion is doing single application repositories.

@uraeus Thank you for all of the work you've done so far on this. I have a few questions:

  1. There are two goals listed:

Make software built and provided outside the traditional official Fedora repositories available to our users,

Provide Fedora repositories that contain software packaged in ways other than RPM.

I believe it would be easier to handle these if they were split into separate proposals. I don't believe that enabling alternative formats requires allowing third party software options.

This would allow us to just discuss a third party software policy, which is what seems to be the biggest area of contention.

  1. Will it still be possible to produce a Gnome DE build of Fedora that has no third party software capability? I'm reading part of this proposal as being a request for the council to not just endorse a third-party option policy but to endorse defining Fedora Workstation as having third-party software offerings. Is this correct?

  2. I may have missed it, but does this policy allow a Fedora built output (edition, spin, etc.) to ship with third party software installed by default? Or is the assumption that the user must always "click the button" and there will be no option for an opinionated output from Fedora?

I'm not offering an opinion on technical details and implementation.

I may have missed it, but does this policy allow a Fedora built output (edition, spin, etc.) to ship with third party software installed by default? Or is the assumption that the user must always "click the button" and there will be no option for an opinionated output from Fedora?

Shipping with third party software is not an option for editions or spins. Our own community rules (and trademark policies) make that an option only for remixes.

@uraeus Thank you for all of the work you've done so far on this. I have a few questions:

There are two goals listed:

Make software built and provided outside the traditional official Fedora repositories available to our users,
Provide Fedora repositories that contain software packaged in ways other than RPM.
I believe it would be easier to handle these if they were split into separate proposals. I don't believe that enabling alternative formats requires allowing third party software options.

True, but regardless of document mention of alternative formats that is a debate that seems concluded anyway despite a lot of noise around containers on devel list. Significant work already done and underway around moby images for instance. So as far as I can see the text talking about alternative formats is just re-iterating default policy in the area and thus keeping it in there is just as a way to have a single document we can point 3rd parties to for the general rules about getting their software listed in a Fedora version regardless of packaging methology.

This would allow us to just discuss a third party software policy, which is what seems to be the biggest area of contention.

Seems to me we are already doing that looking at this ticket and I assume if the council wanted to they could even approve this ticket with a caveat that the approval is for 3rd party software getting listed and rules around that, while packaging formats are still being finalized elsewhere.

Will it still be possible to produce a Gnome DE build of Fedora that has no third party software capability? I'm reading part of this proposal as being a request for the council to not just endorse a third-party option policy but to endorse defining Fedora Workstation as having third-party software offerings. Is this correct?

The 3rd party support is in the simplest terms just a text file with a list of repository URLS. Include that and you will have some 3rd party software show up in GNOME Software, exclude it and you have what we have today. So yes, producting a ISO without the 3rd party software listings is about removing one rpm which just contains that text file.

I may have missed it, but does this policy allow a Fedora built output (edition, spin, etc.) to ship with third party software installed by default? Or is the assumption that the user must always "click the button" and there will be no option for an opinionated output from Fedora?

No, it does not. The only thing this proposal allows us to have some 3rd party software be listed in GNOME Software, so the only thing installed by default is that textfile mentioned above with the repostory defintions.

I'm not offering an opinion on technical details and implementation.

Edit: I mostly speak about GNOME Software, but to state the obvious once you have a .repo file installed anything can also be searched for and installed through dnf too.

Repositories that mix applications with different purposes are not permitted.

The sentence above is quite unclear and I propose removing it. It doesn't explain what are "different purposes" or why such repos are not permitted.

You keep objecting to the biggest mandate Legal has given this proposal. You need to understand that without the restriction to a single application per repository, this entire proposal will not pass the requirements that have been put in place.

Then why does the proposal say this?

A yum repository may contain multiple applications. [...]

This is contradictory. If you want this to be about single-app repos, then just say so explicitly. You still haven't explained what a "purpose" is in the first sentence and why "mixed purposes" are forbidden.

Then why does the proposal say this?

A yum repository may contain multiple applications. [...]

This is contradictory. If you want this to be about single-app repos, then just say so explicitly. You still haven't explained what a "purpose" is in the first sentence and why "mixed purposes" are forbidden.

I don't see a problem here. The above is a statement of fact — yes, a yum repo can have multiple applications. Then, an explanation of what is preferred follows. This seems fine. I don't think we need a hard definition of "purpose".

This is contradictory. If you want this to be about single-app repos, then just say so explicitly. You still haven't explained what a "purpose" is in the first sentence and why "mixed purposes" are forbidden.

I don't see a problem here. The above is a statement of fact — yes, a yum repo can have multiple applications.

But this is written in the context of defining what is in scope of the proposal, so it's not a simple statement of fact.

Then, an explanation of what is preferred follows. This seems fine. I don't think we need a hard definition of "purpose".

The given example is a bad one, too. Why would a repo containing both desktop client and a server backend of a client-server application be unwelcome?

Is it the word "may" which is problematic? Would you prefer wording like

"It is, of course, possible for any yum repository to contain multiple applications. However..."

?

And for the second, something like:

"for instance contains a mixture of desktop and unrelated server software."

?

The given example is a bad one, too. Why would a repo containing both desktop client and a server backend of a client-server application be unwelcome?

One reason is that the selection of 3rd party applications is meant to be taken on a per edition basis, and I want to preserve the ability of both the server and the workstation to include something without having to evaluate software outside their own scope. So for instance I want the workstation working group to be able to decide to include a desktop application without having to consider if the server application that is in the same repo is without legal or technical issues.

That said if you check the latest text I have switched it from absolutes to strong recommendations, so that we can make judgement calls here. So if for instance Microsoft decided to host msql and skype in the same yum repo we are not automatically blocked from offering skype in the desktop and msql in the server.

Is it the word "may" which is problematic? Would you prefer wording like
"It is, of course, possible for any yum repository to contain multiple applications. However..."
?

Not really. I don't see the point of mentioning a generally known fact when trying to say you want something opposite. I'd drop the sentence.

And for the second, something like:
"for instance contains a mixture of desktop and unrelated server software."
?

Not really, either. Why can't you just say: "Single application repositories are generally acceptable under this proposal. Repositories with multiple unrelated applications or libraries are unlikely to be considered." or something similar instead of talking about vague purposes and giving bad examples?

Not really, either. Why can't you just say: "Single application repositories are generally acceptable under this proposal. Repositories with multiple unrelated applications or libraries are unlikely to be considered." or something similar instead of talking about vague purposes and giving bad examples?

I am fine with that, I will edit text to use this wording

First of all I find the insinuation that trying to make Fedora Workstation easier to use means 'being copy of Ubuntu' bit offensive. In general I would say that our efforts in trying to make Fedora Workstation more userfriendly has paid of in terms of significant growth in our userbase. One could always try to nitpick one or more of the changes done as being not important, but in general I think we shown very clearly since the introduction of Fedora Workstation that trying to make life better for our users is paying of in usage growth. If some people feel that wanting to have people use Fedora makes us 'a copy of Ubuntu' then so be it.

It is not really an insinuation, it seems pretty much the truth. End users will just click on a software like skype or whatever without knowing who is hosting it, who packaged it and which kind of packaging rules developers follow. That's against what I understand under controlling my system, it's just click and go.

Legal requirements are not defined and the sentence in the proposal is very generic. Can legal chime in and give us their POV? I feel there are some hurdles if we point to third party repositories not hosted by Fedora. Or which repos do you want to host? I feel that software like chrome will pretend to point to their repo. On the other side, if we host them on a Fedora mirror it is a legal issue because adobe does not permit that at all.

It is essentially a catch all for Fedora/RH legal jumping in and telling us 'you have to stop this' or 'you have to change this'. If that happens we have to act, just like the Fedora project already has to act if that happens with something inside the Fedora repos.
As for your example of Chrome, there would be no pretending to point to their repo, we would just point to their repo as long as it conforms to our requirements like having appstream data, that is what this proposal is about.

I would have appreciated a more objective answer, because I still don't know what legal thinks about that.

Normally upstream does not permit to redistribute the software, what about improving lpf framework to work on that?
If the proprosal is to only care about content or repo hosted by the fp.org, I don't think a 3rd party policy is the correct name

This is not just about repositories hosted o fedoraprojec.org

Then write that clearly, not by assumption.

@uraeus said: In the Fedora repositories we have full control and thus if a package if found to have problems which is true for Fedora repos, but we can’t control anything outside the Fedora repos.
It would be probably good to have a tier 3 for software packaged elsewhere, or?
I don’t understand why you speak about COPR, which is a Fedora thing with strict rules. You mention it in Tier 2, for what reason?
COPRs are Tier 2 in the sense that they are not part of the core Fedora repositories, but they are not 3rd party repos either.
As far as I can understand the proposal, you want to split features into single repositories, but i.e. splitting video players and its dependencies into several repos would be annoying, and who will guarantee one of these dependencies does NOT replace an official Fedora package? And where do you draw the split? Probably you are mainly considering flatpak packages, and not RPMs.

No the idea would not be to split out an application from its dependencies. The single repo setup is to avoid having lets say a pdf viewer application and a video player application in the same repo. And then lets say we get told by legal that the video player app poses a legal risk and we need to immediately stop providing the .repo pointer to it. In which case we also lose the non-problematic pdf viewer. An application here is defined in the same way its defined in GNOME Software, it is only considered an application if it got a .desktop file.

Ok.

All applications that ship as an RPM should conform as closely as possible with the RPM Guidelines found here: https://fedoraproject.org/wiki/How_to_create_an_RPM_package
This means nothing to me, where to you draw the line of being close enough and not? I want to have these packages being conform with our guidelines, that would be a clear rule to me.

That line is mostly an attempt to provide a strong recommendation to 3rd party packagers to follow the best practices developed in the Fedora guidelines, but for many applications not being able to conform to those rules are part of the reason they are not in the current Fedora repos and thus making conforming to them a hard rule is basically rendering the proposal useless.

It seems to me you just don't care, it's only important to have non free software packaged, and although you officially say you want to have our packaging rules followed by developers you will in the end accept any kind of package, even if they don't follow our rules at all.

A software should only be added if it is stable. Adding development releases for third party software results in highly compromised systems. End users don’t know that and think they install something tested. The public opinion would be "Fedora is unstable and doesn't work", while in reality it is because you install a third party devel package.

I am personally not a huge fan of offering developement versions, but I do think that if we did decide to offer clearly marked developed versions of some core applications, especially as flatpaks, the impact or confusion would not be great.

The impact on end user systems would be important, they are just clicking on a software, and some of them might click on the "latest release", even if it is not stable.

I would prefer an universal approach. This is a proposal for Fedora as a whole and not for workstation only. We have to decide if we really want to add this stuff to a free and open source distro or not. If we decide to go for it, this should apply also for desktop and functional spins, without exceptions.

The rules are universal in the sense that once this proposal is approved any spin can choose to take advantage off them. The point is that if they don't want to we are not going to force them just because we want to try this out in the workstation edition.

I still disagree with that, but ok.

I know I am not as technical as others here, but I care about our 4Fs and want to have things drawn into stone, without any possibility to interpret generic rules in other ways.

The proposal is trying to be as clear as possible, but be careful what you wish for here, because I have seen many organisations that over the years seem to drown themselves in detailed rules and life inside the group seems to be about hitting eachother over the head with the rules.

Sorry, but you are proposing something which is too important for FOSS entusiasts and users who really care about freedom in Fedora. You can't just say, let's not make too many rules, because that's bad. This proposal needs clear and specific rules, because otherwise we vote on something which will not be applied in reality afterwards (I really fear this will happen).

Furthermore, I understood only in the comments of this ticket the idea is to ship this package by default. You are minimizing the effect of this "beeing just a text file", but in my opinion that's clearly against our Freedom foundation. Shipping it by default is a no-go for me. Having unclear, or better, non strict rules, is making it worse to me.
So, I'm sorry but I'm -1 on this.

As per Council rules I'd like to rediscuss it at least, considering also asking legal for more informations about the pieces which are concerning me. I lead a local community of end-users for many years and also know what it means to offer just a link of skype for example. People will click on it and if there are any issues make Fedora responsible.
In the comments I saw this is a sort of test; then please don't ship anything by default, let's keep Fedora free from any third party stuff. Make a package and who is interested can install it with dnf, but while doing it he should get a clear disclaimer he is now adding a package for third party software, which Fedora doesn't control at all. The user should be aware he could potentially have issues caused by this software and confrim that with a "Y". After that, labeling it is fine.

Robert, for the record Christian has already discussed this with Legal. They put in the restriction of one application per repository and were otherwise fine with it. Also, to be clear, If you are referring to Spot's thoughts on this specifically, then you should say Spot. Spot is the typical interface to Legal, but he is not Legal himself.

The Board and then the Council have also already discussed, at length, the idea of allowing third party software via Fedora. Your -1 stance seems to be counter to the already agreed to approach that it is acceptable and can be decided by the Editions. While you may wish to revisit that decision, I don't think it should be done under this ticket. The Workstation WG has submitted this ticket for approval of the policy draft under the good faith assumption that the Council's prior guidance on this being acceptable still stands. I would find it in very bad taste if we told them to proceed months ago only to throw up major objections to the entire premise at the tail end of the journey.

In keeping with the Council's "-1 with comments" voting approach, I would ask that you please outline in a summary comment the specific items you believe need to be reworked in the proposal, along with suggestions for those items that would allow you to be +1.

Robert, for the record Christian has already discussed this with Legal. They put in the restriction of one application per repository and were otherwise fine with it. Also, to be clear, If you are referring to Spot's thoughts on this specifically, then you should say Spot. Spot is the typical interface to Legal, but he is not Legal himself.

Actually this isn't 100% accurate. What legal didn't want was repositories which where a combination of a) and entity which would not provide a legal shield for Red Hat and b) which contained a changing assortment of software not controlled by Red Hat or the Fedora project.

So they where fine with something like Steam even though it contains a changing assortment of software because if someone wanted to sue over something on Steam then the game publisher and Valve would be the natural targets for such a lawsuit, not Red Hat.

They where also fine with community repos as long as the contents where vetted by Fedora and could easily be disabled if need be. Which meant nothing would be added to the repository without some basic vetting of that item and of course contacting legal if we where unsure about something. Ie. basic having a similar level of control that we have with stuff going into (or out of) the Fedora repositories.

The request for single application repos came about as a way to make complying with the second request viable as it means we known exactly what is in there and in the case where we do get a request to stop making something available there is no risk of collatoral damage, meaning we don't risk 20 applications not getting security updates do to legal being concerned with package 21. So it wasn't legal specifically asking for single application repos, it was more that after hearing legals concerns then going for single application repos seemed like the best way to be able to comply with their requirments.

Robert, for the record Christian has already discussed this with Legal. They put in the restriction of one application per repository and were otherwise fine with it. Also, to be clear, If you are referring to Spot's thoughts on this specifically, then you should say Spot. Spot is the typical interface to Legal, but he is not Legal himself.

I am not a lawyer and I respect Spot's answer and I'm always fine with anything he says. However, I see it problematic to point to something which is against Fedora principles and not under our control. Shipping this as "Fedora" makes us at least co-responsible for any issues. Thanks to Christian for clarifying that a bit more detailled, I need to understand what happened, not just get an answer "already done and approved".

The Board and then the Council have also already discussed, at length, the idea of allowing third party software via Fedora. Your -1 stance seems to be counter to the already agreed to approach that it is acceptable and can be decided by the Editions. While you may wish to revisit that decision, I don't think it should be done under this ticket. The Workstation WG has submitted this ticket for approval of the policy draft under the good faith assumption that the Council's prior guidance on this being acceptable still stands. I would find it in very bad taste if we told them to proceed months ago only to throw up major objections to the entire premise at the tail end of the journey.

Where and when did we agree on this? I can only remember a long discussion and a long time ago, without any outcome, about third party software. I also remember there were many contributors who were very upset about the idea. This goes back to the Board, but we are in another and hopefully more transparent timeframe now, aren't we? I think we are in a democracy, and I can vote accordingly to my understandings of what is good for Fedora and what is not. If you want to just make it and don't want discussions because it has been already decided by someone, then please close this ticket as invalid and do it, but don't ask for approval or anything else.
The bad taste here is that the proposal differ very much to what has been discussed in the past. And AFAICS it differs even from the request for feedback (not a proposal at all) we had last year, because we wanted to prioritize open source software if possible (exactly how our Freedom principle tells) and also wanted to explicit ask for user approval for non-free software. All this is not happening, and my concerns from the beginning of that discussion are the same I have now.

In keeping with the Council's "-1 with comments" voting approach, I would ask that you please outline in a summary comment the specific items you believe need to be reworked in the proposal, along with suggestions for those items that would allow you to be +1.

Sure, I tried to do that already, but I will be more specific and list only the most important concerns

Blocking Concerns

  • Freedom: Fedora is free and will always remain free, trying to promote open source software which can equal or exceed closed source software. That's more or less our Freedom foundation, and by adding a third-party-plugin by default you are throwing away one of our principles the new mission statement is built on. (Remember there were many concerns about the mission statement just because we didn't include the free and open source part!) Having this plugin/package installed by deafult prevents me from being free.
  • Rules are non existent; anyone could package an RPM of a closed software, without respecting our packaging guidelines at all, and hosting it wherever. I see this as a wildcard for any kind of software or packaging behavior, just by saying: "Y'are not able to respect the guidelines and aren't a packager? No problem, make it how you like it, set up a repo and we will point to it". I fear we end up in accepting even sh...y packages.
  • End users are not aware where this software comes from (they are not free again), there is nothing which tells them what they are going to install. Do you remember Fedy, easyLife or whatever were their names? People used them but were not able to fix issues afterwards, they didn't know what this tool did to their system. It's the same here, people just click and then cross fingers.

Proposal (compromise)

  • Freedom: Fedora should remain free and nothing should change for those who use Fedora for exactly that reason (you probably understood that I'm one of them and that's the reason why I am contributing to Fedora and not to another distro). To keep Freedom but allowing the proposal to be approved, don't install it by default, but treat it as extra package, or make an extension (better a package).
    People should install it: dnf install third-party-plugin
    INFO: you are going to install a package which acts as a pointer to third party and/or non-free software Fedora doesn't totally control. Do you want to proceed?
    [Y] [n]
    The discalimer should be clear, I am not aware if it needs spot's green light or if we can just make something like that..
  • I understand packaging third party software sometimes can not be made accordingly to our packaging guidelines. I would welcome if we want these packages packaged by Fedora packagers, who at least know our guidelines and will act as close as possible to them. For example, I am packaging sublime-text since a couple of years now for personal purpose, but I can't public it anywhere because it is not distributable. As a packager, even if I have just a few packages and might not have the knowledge others have, I think I did that according to our guidelines. Can we accept only packages done by Fedora packagers? Or at least make them totally preferred over any other package?
  • The fact that people click on something and get a package installed on their system, without knowing where it comes from and who maintains it, is a horror scenario for me. Personally I would never use that, I would install a third party software from a repo I know where it is and where I can eventually also check the maintainer, upstream etc. An acceptable situation could be, after users have accepted the third-party-plugin by installing it:
    Packages are labeled as described in the proposal and once a user clicks on a certain package he will get a informational popup:
    "The third party (non-free) package you are installing is hosted on ${REPO_URL}" This requires just an OK button, but at least users will know where the package they are installing comes from.

It is not ideal, but I could live with that.

Previous ticket is https://pagure.io/Fedora-Council/tickets/issue/57

Robyduck, have you seen the mockups for how this works in GNOME and GNOME Software? It's not a dnf plugin, but it does require clear confirmation and the third-party packages are labeled in Software. (That labeling isn't quite as obvious as I'd like in the last implementation I saw; I think that's still in progress.) If you say no, they aren't included in search results or anything.

I don't see a big difference whether the repo descriptions are on disk by default or not. They're not themselves third-party software or proprietary.

Christian, can you post screenshots of how this looks in the current implementation?

Addendum: I don't think a DNF-based solution is going to be a good approach for Workstation. So, they need a GUI equivalent to the process you suggest, and that's basically what the plan is as I understand it (although there aren't any popups; the information is there on the software install page).

I am going to restrain from expressing my opinion on this topic and side-track the discussion just a quick minute, sorry about that.

The 3rd party support is in the simplest terms just a text file with a list of repository URLS. Include that and you will have some 3rd party software show up in GNOME Software, exclude it and you have what we have today. So yes, producting a ISO without the 3rd party software listings is about removing one rpm which just contains that text file.

Going into the technical details, I wonder if this text file shouldn't be something hosted in the Fedora Infrastructure somewhere for the consumer sto retrieve as that would make removing a repo from the list much easier and propagate the change much more quickly than updating an RPM would. This would also help address legal's concerns about removing 3rd party repo.

Previous ticket is https://pagure.io/Fedora-Council/tickets/issue/57

Correct, and my concerns were the same 1 year ago.

Robyduck, have you seen the mockups for how this works in GNOME and GNOME Software?

No, nobody pointed me to them. I can just read the wiki proposal.

It's not a dnf plugin, but it does require clear confirmation and the third-party packages are labeled in Software. (That labeling isn't quite as obvious as I'd like in the last implementation I saw; I think that's still in progress.) If you say no, they aren't included in search results or anything.

To make sure we still prefer open source software over proprietary software we shouldn't include them in search results. I am on the same boat as cwickert a year ago.

I don't see a big difference whether the repo descriptions are on disk by default or not. They're not themselves third-party software or proprietary.

Well, IMO this makes a big difference. If you don't add it by default I will have a clean system, according to our foundations. Installing it by default has as result that I cannot choose anymore if I want this or not. It makes any difference to me wether this is proprietary by itself or not, it is a passe-partou to non free software, moreover it's given to me automatically by Fedora, not added by the end user. The difference is small but has big consequences.

Christian, can you post screenshots of how this looks in the current implementation?

I am going to restrain from expressing my opinion on this topic and side-track the discussion just a quick minute, sorry about that.

The 3rd party support is in the simplest terms just a text file with a list of repository URLS. Include that and you will have some 3rd party software show up in GNOME Software, exclude it and you have what we have today. So yes, producting a ISO without the 3rd party software listings is about removing one rpm which just contains that text file.

Going into the technical details, I wonder if this text file shouldn't be something hosted in the Fedora Infrastructure somewhere for the consumer sto retrieve as that would make removing a repo from the list much easier and propagate the change much more quickly than updating an RPM would. This would also help address legal's concerns about removing 3rd party repo.

+1 to this, and making it optional and not default would even be better \o/

Addendum: I don't think a DNF-based solution is going to be a good approach for Workstation. So, they need a GUI equivalent to the process you suggest, and that's basically what the plan is as I understand it (although there aren't any popups; the information is there on the software install page).

My example of a dnf solution was just a thought. The reason behind that is quite clear I think, you can implement it as you like but it should be optional.
A GUI equivalent is fine to me too, but any GUI command can be done also on CL, what I am seeing is that everyone adds "as far as I understand it". You see the rules and plans are somewhat of unclear and I really want to to make sure, whatever we approve here will be done accordingly, not that we approve some ideal plans which then never happen. Strict rules are necessary here.

Please tell me more about my proposal, I don't think a compromise like this is bad or not doable, and we would really make happy also our FOSS and Freedom enthusiasts.

Going into the technical details, I wonder if this text file shouldn't be something hosted in the Fedora Infrastructure somewhere for the consumer sto retrieve as that would make removing a repo from the list much easier and propagate the change much more quickly than updating an RPM would. This would also help address legal's concerns about removing 3rd party repo.

We could do that, but the advantage of the RPM route is that we have a well working system in place inside the communty for dealing with packages. So if a change is needed everyone knows how to update an RPM. If we make this a special thing in the infrastructure the amount of people who have access and know how to update it will be a lot smaller. We been discussing how to move away from how the recommended appliations are 'secret sauce*' in GNOME Software so I don't feel making the 3rd party repositories a special case is the right way to go here.

  • Secret sauce in this case is not actually secret, but not something anyone would know how to do without further research.

Going into the technical details, I wonder if this text file shouldn't be something hosted in the Fedora Infrastructure somewhere for the consumer sto retrieve as that would make removing a repo from the list much easier and propagate the change much more quickly than updating an RPM would. This would also help address legal's concerns about removing 3rd party repo.

We could do that, but the advantage of the RPM route is that we have a well working system in place inside the communty for dealing with packages. So if a change is needed everyone knows how to update an RPM. If we make this a special thing in the infrastructure the amount of people who have access and know how to update it will be a lot smaller. We been discussing how to move away from how the recommended appliations are 'secret sauce*' in GNOME Software so I don't feel making the 3rd party repositories a special case is the right way to go here.

However, in this case I'd be very in favor of this if it would allow us to modify the repo list without the user having done an update first. Unless the GUI app force updates this package we could leave the user in a situation where they pull software we disabled. I realize that users should always be updating, but I don't think that matches reality.

I didn't see a response to this above, is this proposal also authorizing the offering of third party software in Workstation by default?

I didn't see a response to this above, is this proposal also authorizing the offering of third party software in Workstation by default?

Yes, the goal of the proposal is that the 3rd party software offerings the working group selects will be showing up when you search in GNOME Software (and dnf searches). They will be clearly marked with licensing information and source information though, working on getting some screenshots uploaded here per earlier request in this thread.

However, in this case I'd be very in favor of this if it would allow us to modify the repo list without the user having done an update first. Unless the GUI app force updates this package we could leave the user in a situation where they pull software we disabled. I realize that users should always be updating, but I don't think that matches reality.

Chatted with some of the devs about this and the initial response is that setting up a special case system here is a lot of effort for what seems like a very limited gain. Sure there might be a window between us updating the repo file and the end user updating his or her system where they could install a given application, but even with an online file you could end up in such situations. For instance if GNOME Software where in charge of polling that upstream repo, but the user was only using dnf for a while. And as far as legal would be concerned we just need to make a reasonable effort here. This is a corner case situation not to dissimilar to removing a package from Fedora and users still being able to grab it from a mirror for instance.

So here are some scsreenshots of how we distinguish between software provided by Fedora and
3rd party software. The first screenshot shows a dialog that pops up when you first try to install something from a given 3rd party repository. The text can of course be changed to whatever we want it, but it should make it crystal clear to a user that the application in question is not comming from Fedora.
https://uraeus.fedorapeople.org/files/third-party-notice.png

In the application description screen there are also several information items mean to help make the status of the software clear to the end users, like the signal red Proprietary license information and the 'source' line showing where the package comes from.
https://uraeus.fedorapeople.org/files/gnome-software-application-metadata.png

Another example also including a vendor name, we should probably make that mandatory through or policy.
https://uraeus.fedorapeople.org/files/spotify-example.png

There is also since F26 a new dialog in GNOME Initial setup that asks you if you want proprietary software sources listed in GNOME Software. This means that stuff marked as non-free would get filtered out, but free 3rd party software would still show up.
https://uraeus.fedorapeople.org/files/gnome-initial-setup.png

Ok the first screenshot solves my concern #3 I pointed out in https://pagure.io/Fedora-Council/tickets/issue/121#comment-449829, but I still have the feeling we are asked to approve something by innocent sentences, which in reality will turn out as very big changes.

I can't go with this installed by default, and I still think if we want to try this out, we have to make this optional. End users should get a clean system, and with the same easy command as they add RPMFusion free and non-free, they can add this third-party-plugin (rpm, stuff, call it how you like).
After that labeling and pointing out sources etc is fine, as far as I can judge it from a screenshot.
I will not insist with packaging rules if we make this optional.

Ok the first screenshot solves my concern #3 I pointed out in https://pagure.io/Fedora-Council/tickets/issue/121#comment-449829, but I still have the feeling we are asked to approve something by innocent sentences, which in reality will turn out as very big changes.
I can't go with this installed by default, and I still think if we want to try this out, we have to make this optional. End users should get a clean system, and with the same easy command as they add RPMFusion free and non-free, they can add this third-party-plugin (rpm, stuff, call it how you like).
After that labeling and pointing out sources etc is fine, as far as I can judge it from a screenshot.
I will not insist with packaging rules if we make this optional.

It is optional as you see from the GNOME Initial setup screenshot, you asked for a system where the users are asked to specifically enable this and that is exactly what is provided here.

No this is just a switch, like a gnome-extension, which means I already have this rpm installed on my system. You know this is not the same as having a clean system.

@robyduck Personally, I'm not seeing the importance of the installed-or-not distinction you are making for the metadata. But, would it be acceptable if the repo-definition RPM were not installed by default but added when a user turns that switch to "yes"?

Inlining the screenshots Christian provided above for future reference:

gnome-software-application-metadata.png

spotify-example.png

gnome-initial-setup.png

I agree with @mattdm, I don't believe having the code repo with the urls loaded is inherently non-free. It is what happens after that may result in non-free software being loaded.

I am unsure how I feel about Fedora Workstation shipping with non-free-software in the search by default. I can see both sides.

I am concerned about the language on the screenshots. I am worried that the enablement screenshot (number 3) seems to indicate that you get no games or web browsers without clicking yes. That needs to be cleaned up. I am not initially sure how to clean it up thought. I think maybe the best option is to not give examples, but to simply explain the licensing and why you might want it. If we give an example, lets use something like video drivers.

I am also concerned that in the other two screenshots we need to add an explanation of what "proprietary" means. Right now our Workstation edition is pointed at a lot of different non-developer types by our ambassadors. This means that we cannot assume a knowledge of software licensing. (Expecting developers to understand it by default is also a stretch, but I prepared to let that one go.)

I think @spot may have some ideas/text here.

@mattdm no, because as Christian said, the non-free packages will show up in the research list, even if this package is disabled. There is quite a difference from having this installed or not, otherwise you would not insist by having it installed by default.
We are making a try of that, and we are doing that on our main desktop edition, not just on a spin. Moreover these packages probably will not follow our packaging guidelines and we cannot guarantee they will not replace Fedora packages (although we would drop the repo then, but with a delay of some time).
That all said is the reason why we shouldn't act against one of our principles and give users the choice to install it or not.

Christian, can you clarify? It was my understanding that if you choose "no", proprietary software will not show in search even if the repo file is there.

@mattdm
https://uraeus.fedorapeople.org/files/third-party-notice.png

In my understanding this means it shows up in the research list, but before you install the non free software you just have to make a quick click on "OK" to enable the repo (as it's only disabled, but already installed).

@mattdm
https://uraeus.fedorapeople.org/files/third-party-notice.png
In my understanding this means it shows up in the research list, but before you install the non free software you just have to make a quick click on "OK" to enable the repo (as it's only disabled, but already installed).

As I understand the plan, that is the case

  1. if the software is free and open source but third party
  2. or if the software is non-free and the user has opted-in to non-free software sources.

@mattdm
https://uraeus.fedorapeople.org/files/third-party-notice.png
In my understanding this means it shows up in the research list, but before you install the non free software you just have to make a quick click on "OK" to enable the repo (as it's only disabled, but already installed).

As I understand the plan, that is the case

if the software is free and open source but third party
or if the software is non-free and the user has opted-in to non-free software sources.

Yes, Matts understanding is correct. If you choose no in gnome-initial-setup you will not get non-free search results even, but you will still get free software 3rd party software in your search results, an example being the PyCharm copr that we are currently incuding.

I am concerned about the language on the screenshots. I am worried that the enablement screenshot (number 3) seems to indicate that you get no games or web browsers without clicking yes. That needs to be cleaned up. I am not initially sure how to clean it up thought. I think maybe the best option is to not give examples, but to simply explain the licensing and why you might want it. If we give an example, lets use something like video drivers.

I remember discussing this with Allan Day and had the same concern. Allan suggested

"Propriety software sources provide access to additional software, including a greater range of web browsers and games."

Or just "Propriety software sources provide access to additional software, including more web browsers and games."?

I was pointed to the following message from Robyduck on the council list:

I think there is not much more to discuss. Seems I am the only one with
real concerns about Freedom, and there isn't any opening to apply a slight change to the proposal, which would solve that. It is just sad I tried to find a good compromise, while this was not the case from the other side.

I am really disappointed with that message as it is both ignorant and disrespectful of the effort that has been put into this over the last 3 years. For 3 years we been discussing this issue to try to come up with a compromise that everyone can live with, we have iterated on various designs and written code to come up with ways to make our users life easier while preserving Fedora's focus on freedom.
Things like the gnome-initial-setup screen, the enabling of 3rd party repos dialog and adding more metadata to the applications descriptions where all done as part of finding a compromise. So having Robyduck basically be a “Johnny-come-lately” here and claim he is the only one caring about freedom and compromises is deeply disappointing and more than anything shows just how little he followed the work and discussions happening over the last 3 years.

Hey, Christian, can we please assume good faith here? I don't like to hear accusations of "ignorance" cast around.

And Robert is certainly no "Johnny come lately"!

To me this whole initiative is about balancing the aspect of Freedom with that of our many users for whom that is not a priority, and who just want things to work. We have to be careful not to slide the balance so much that we are no longer favoring freedom, but also not enforce a dogmatic approach that drives away users who want easier choice.

I work with Robert (robyduck) often in various places around Fedora and I know he prizes the freedom aspect of Fedora highly. So I think he's coming from a place of guarding that stance. I understand and respect that. At the same time, I also know we've had many discussions about these designs to meet criteria of numerous leaders and Council members in the past. I work with Christian daily as well, and I know he cares about software freedom too.

Impugning other people's motives is not a good way to have a discussion. It's fine to debate the idea and the implementation, but not each other's intentions or experience.

Hey, Christian, can we please assume good faith here? I don't like to hear accusations of "ignorance" cast around.

Maybe I was to harsh, but having worked 3 years on a compromise here I do get annoyed when someone jumps in at the last minute and has the audacity to claim that 'the other side don't don't care about making compromises'. There is no 'good faith' in such a statement.

I was pointed to the following message from Robyduck on the council list:

I think there is not much more to discuss. Seems I am the only one with
real concerns about Freedom, and there isn't any opening to apply a slight change to the proposal, which would solve that. It is just sad I tried to find a good compromise, while this was not the case from the other side.

I am really disappointed with that message as it is both ignorant and disrespectful of the effort that has been put into this over the last 3 years. For 3 years we been discussing this issue to try to come up with a compromise that everyone can live with, we have iterated on various designs and written code to come up with ways to make our users life easier while preserving Fedora's focus on freedom.
Things like the gnome-initial-setup screen, the enabling of 3rd party repos dialog and adding more metadata to the applications descriptions where all done as part of finding a compromise. So having Robyduck basically be a “Johnny-come-lately” here and claim he is the only one caring about freedom and compromises is deeply disappointing and more than anything shows just how little he followed the work and discussions happening over the last 3 years.

Christian, I am not surprised to see you are getting offensive, and I am also not surprised you don't accept any concerns about your proposal. I think I stated why it doesn't work for me, and I also think I proposed a solution which doesn't require many changes.
After @mattdm's reply in the ML, I was trying to think about another compromise, but at this point and on this level of discussion any effort has become useless because there is no open ear for anythink like that.
I even tried to find where we discussed this so many years ago (I was not on the Board at that time), and could find just a ticket from last year, where my concerns were exactly the same as now. Additionally, the ticket #57 I am talking about was just about feedback/inputs, which is far away from discussing this important point and just wanting to have it approved now.
However, I don't think I am a “Johnny-come-lately”, I am doing that in my spare time and I care about Fedora and its foundations. I replied once you asked for approval of a final document. As ambassador I pray Freedom all the time, and now we add just a switch which makes magically appear skype in the software list, which is even non-free and packaged by someone who is not following our guidelines?
These are my concerns, so please don't tell me other stories about Freedom, at least you should point that out clearly and not hide it in some nebulous message about third party stuff when you ask users to turn it on.
"Johnny come lately" has just 1 vote out of 7, so I expect to get that approved anyway, but it will have a high impact to ambassadors and IMHO also to our 4 foundations. That's all from my side, but please don't offend my (free) work for Fedora anymore, because I am not doing that either.

I was pointed to the following message from Robyduck on the council list:
I think there is not much more to discuss. Seems I am the only one with
real concerns about Freedom, and there isn't any opening to apply a slight change to the proposal, which would solve that. It is just sad I tried to find a good compromise, while this was not the case from the other side.
I am really disappointed with that message as it is both ignorant and disrespectful of the effort that has been put into this over the last 3 years. For 3 years we been discussing this issue to try to come up with a compromise that everyone can live with, we have iterated on various designs and written code to come up with ways to make our users life easier while preserving Fedora's focus on freedom.
Things like the gnome-initial-setup screen, the enabling of 3rd party repos dialog and adding more metadata to the applications descriptions where all done as part of finding a compromise. So having Robyduck basically be a “Johnny-come-lately” here and claim he is the only one caring about freedom and compromises is deeply disappointing and more than anything shows just how little he followed the work and discussions happening over the last 3 years.

Christian, I am not surprised to see you are getting offensive, and I am also not surprised you don't accept any concerns about your proposal. I think I stated why it doesn't work for me, and I also think I proposed a solution which doesn't require many changes.
After @mattdm's reply in the ML, I was trying to think about another compromise, but at this point and on this level of discussion any effort has become useless because there is no open ear for anythink like that.
I even tried to find where we discussed this so many years ago (I was not on the Board at that time), and could find just a ticket from last year, where my concerns were exactly the same as now. Additionally, the ticket #57 I am talking about was just about feedback/inputs, which is far away from discussing this important point and just wanting to have it approved now.
However, I don't think I am a “Johnny-come-lately”, I am doing that in my spare time and I care about Fedora and its foundations. I replied once you asked for approval of a final document. As ambassador I pray Freedom all the time, and now we add just a switch which makes magically appear skype in the software list, which is even non-free and packaged by someone who is not following our guidelines?
These are my concerns, so please don't tell me other stories about Freedom, at least you should point that out clearly and not hide it in some nebulous message about third party stuff when you ask users to turn it on.
"Johnny come lately" has just 1 vote out of 7, so I expect to get that approved anyway, but it will have a high impact to ambassadors and IMHO also to our 4 foundations. That's all from my side, but please don't offend my (free) work for Fedora anymore, because I am not doing that either.

Hi Robert,
I have no problems with you having a different view on things or that you where asking a lot of questions about the proposal. I think I been pretty good about trying to answer as many questions that I can on this ticket and providing requested screenshots etc. I been spending a lot of time over the last years working on this and trying to find a middle way. And I been accussed in those discussions of being willing to throw our user experience down the drain by agreeing to putting technical questions about licensing and package origin in front of the users and have 'ugly' dialogs popping us asking the users if they are really really sure this is what they want to do. And then on the other side I get thrown accusations about not caring about freedom or open source and just wanting to be Ubuntu.

So I am sorry if I got a bit fired up when I saw your email portraying yourself as the only one willing to make compromises here after spending so many years trying carefully to craft such a comprise. That said, just because I felt wronged, calling you ignorant and a johnny come lately was not the right thing to do, so appologize for that.

Or just "Propriety software sources provide access to additional software, including more web browsers and games."?

What about just:

Proprietary software sources provide access to additional software that is not able to be distributed directly by Fedora. This software may have licenses we do not support (with link to the licenses list) or may not be able to be packaged for Fedora.

I don't think we need to tell people what is in the list. Games and Web Browsers is a weirdly small list, imho.

@mattdm
https://uraeus.fedorapeople.org/files/third-party-notice.png
In my understanding this means it shows up in the research list, but before you install the non free software you just have to make a quick click on "OK" to enable the repo (as it's only disabled, but already installed).
As I understand the plan, that is the case
if the software is free and open source but third party
or if the software is non-free and the user has opted-in to non-free software sources.

Yes, Matts understanding is correct. If you choose no in gnome-initial-setup you will not get non-free search results even, but you will still get free software 3rd party software in your search results, an example being the PyCharm copr that we are currently incuding.

I hate to restate this a third time, but I am going to try to do it in bullet points (because that is how I roll).

If we approve this proposal we are approving the following:

  • Outputs of Fedora, such as spins, labs, and editions can choose to include third-party free and third-party non-free software as an easily installable option. Today this is only able to done through Gnome software, but that is not a technical requirement of exercising this choice.
  • A user must be prompted during initial setup or at some point to make an affirmative choice to include non-free software in search results or as an easily installable option. This prompting must occur before the first non-free option is displayed. These options must be flagged to indicate their proprietary and third-party status.
  • A user may be prompted for third-party non-free software options similar to above, but is not required to be prompted. Specifically this means that a desktop output is allowed to provide third-party free software options to users without asking for user permission. These options must be flagged to indicate their third-party status.
  • Fedora Workstation is being approved to provide third-party free software by default.
  • Fedora Workstation is being approved to prompt a user about whether they wish to see proprietary software during the initial setup.
  • The specific language for the prompts in Fedora Workstation is still a work in progress.

Is this the guts of the this proposal?

I think you summarized it correctly Bex

As requested today in the Council meeting I'm updating this ticket with a new proposal. Please @eischmann and/or @uraeus weigh in, if I miss something.

Basically the proposal remains the same, but:

3rd party software metadata are NOT on the installation media, but they would
only be downloaded after the user toggles the switcher ON. The default installed system would be free of the 3d party metadata package. The user would boot it for the first time, go through the initial
screens to set up the system and one of the screens would ask about the 3rd party sources just like the one of the mockups linked in the ticket shows. If the user switches it ON, PackageKit on the background downloads and installs e.g. package called 3rd-party-software-metadata
which will add repo metadata for DNF/Flatpak. If the user decides not to switch it on, nothing happens and user's systems stays free of it.

This enables users to add third party stuff if they like, but also doesn't ship anything "non-free related" in our default package set. Therefore it doesn't have any impact on "Freedom".

If this is technically possible (I hope so), I am +1 on this proposal.

Looks correct to me, also Kalev Lember is looking at the implementation of this atm, he hopes to have something ready by the end of the week.

From our meeting today:

This policy is approved. Please create new tickets when the "TBD" sections are to be filled in, or for any major adjustments. Because this is a sensitive area, the council would like input into the final wording of various user-facing texts and etc. and will provide feedback where appropriate.

Metadata Update from @mattdm:
- Issue close_status updated to: approved
- Issue status updated to: Closed (was: Open)

a year ago

Sounds good. I just updated the wiki page to include the description of how this works that robyduck works and also based on todays council discussion I explicitly call out copyright issues in the legal section.

Login to comment on this ticket.

Metadata
Attachments 3