#57: Seeking Council feedback/input on draft third party software policy ----------------------+------------------------ Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Keywords: workstation ----------------------+------------------------ The Workstation WG has been collaborating for some time on a third party software policy that would make the widest possible range of software available to Fedora users in a easily consumable format, while ensuring users have all the information necessary to decide on the software they install. A draft of the policy is available here:
https://fedoraproject.org/wiki/Workstation/Third_party_software_proposal
The WG has reached the point that it wants direct Council feedback, questions, concerns, etc. before further action. We're not looking yet for technical changes to the distribution, release mechanisms, etc., although we ''are'' happy to receive questions about that from the Council. However, we're specifically looking for Council feedback on the principles and practices in the policy to see that they align with what the Council would like to see in Fedora's future.
The WG members would be happy to have a Council or Workstation WG meeting dedicated to this topic if desired. I can help with scheduling that if needed.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by jwboyer):
A few comments:
The inclusion of "legal restrictions" in the Tier 2 definition is odd, particularly when using COPRs as an example. I think it would be better phrased as:
"Tier Two: software hosted and packaged elsewhere, but discoverable and installable through Fedora software tooling. This software might be hosted elsewhere due to simple preference of upstream maintainer, legal restrictions, or inability to comply with Fedora packaging guidelines."
Alternatively, remove "legal restrictions" from the Tier 2 definition and then define a Tier Three:
"Tier Three: software hosted and packaged elsewhere, but discoverable and installable through Fedora software tooling. This software is hosted elsewhere due to upstream preference or legal restrictions. An example of software in the third tier is the Adobe Flash plugin repository. This software must be freely redistributable."
or something along those lines. Reasoning is that COPRs must follow the same legal inclusion rules that any other Fedora package does, so leaving "legal restrictions" in Tier 2 seems ill placed.
"Registries and similar tools:"
How feasible is it to enforce the requirements here on third party registries? I don't see us having much influence on how rubygems, NPM, or Steam work installing their content both in terms of location of installation and ability for our tooling to work with it.
"Principles/Submitting the application for consideration:"
Is the audience for this section intended to be the third party application provider, or an interested user/community member looking to get a third party application included? I'm concerned about ability to influence upstreams here as well. I would think inclusion would be more of a Fedora looking outward process rather than a third party looking into Fedora.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by jwboyer):
Specific comments above aside, I think the intention of the document is fairly clear. The labeling of third party software is paramount to any sort of traction and it needs to be clear to a novice user. I believe the Council should focus on the principles around allowing such labeled software to be presented in Fedora in our discussions.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by uraeus):
Replying to [comment:1 jwboyer]:
A few comments:
The inclusion of "legal restrictions" in the Tier 2 definition is odd,
particularly when using COPRs as an example. I think it would be better phrased as:
"Tier Two: software hosted and packaged elsewhere, but discoverable and
installable through Fedora software tooling. This software might be hosted elsewhere due to simple preference of upstream maintainer, legal restrictions, or inability to comply with Fedora packaging guidelines."
Alternatively, remove "legal restrictions" from the Tier 2 definition
and then define a Tier Three:
"Tier Three: software hosted and packaged elsewhere, but discoverable
and installable through Fedora software tooling. This software is hosted elsewhere due to upstream preference or legal restrictions. An example of software in the third tier is the Adobe Flash plugin repository. This software must be freely redistributable."
or something along those lines. Reasoning is that COPRs must follow the
same legal inclusion >rules that any other Fedora package does, so leaving "legal restrictions" in Tier 2 seems ill
placed.
To be clear I think in our writeup anything that is not in a standard Fedora repository is 'elsewhere', this includes COPRs even though they are hosted by Fedora. So the reasons listed as just meant as examples of why the software might be elsewhere, but each individual reason might or might not apply to a given packaged. And example of a legal restrictions here is meant to for instance cover the OpenH264 package, where it needs to be hosted by Cisco to be covered by their patent license.
"Registries and similar tools:"
How feasible is it to enforce the requirements here on third party
registries? I don't see us having much influence on how rubygems, NPM, or Steam work installing their content both in terms of location of installation and ability for our tooling to work with it.
I think the idea would be that the rules we have for the most part is something that a lot of these repositories conform to anyway, so it would more be that we might exclude some due to the upstream doing things we can not live with rather than have them change. Of course for some of them it might only be small changes needed and it could be that it would be something they agree to do, or maybe there is a packager involved who can cover the gaps.
"Principles/Submitting the application for consideration:"
Is the audience for this section intended to be the third party
application provider, or an interested user/community member looking to get a third party application included? I'm concerned about ability to influence upstreams here as well. I would think inclusion would be more of a Fedora looking outward process rather than a third party looking into Fedora.
It can be either, the rules are not so difficult to live up to that a packager could 'bridge the gap' in many cases, but it is also to give a 3rd party an idea of what we expect of them. I am hoping the inclusion process ends up being both us looking outward and actively soliciting 3rd party offerings, but also of 3rd parties reaching out to us because they want to get listed.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
Sorry Paul -- this got back-burnered because of the long budget discussion. Let's move this forward now. I have a lot of technical, social, and practical concerns with specifics, but I'm in support of the general goal of advancing Fedora by making more software easily available to users without compromising the fundamentals of the "tier one" Fedora OS.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
So, having re-read this, I think my main concerns are:
1) Presentation of external vs. maintained by Fedora Project must be very clear 2) Presentation of free software vs. non-free must also be clear, with non-free being opt-in 3) The process for inclusion is community-based and community-driven.
I think the proposed design for Software covers the clarity issues of points 1 and 2. I'm don't see the opt-in process mentioned, although I know we've talked about this previously. Fedora has a mission to actively support and promote free and open source software and I want to see this policy take an *active* part in that.
On point 3, the document strongly notes that the enablement of various third party repositories will be done by working groups or SIGs. That's fine, but I'd also like to add that any group doing so must have a documented process which allows community input and which produces a traceable history (a ticket or something).
Those are the big things. On a smaller note, I also am not sure about the There Can Only Be One goal. I can see value in that, but I can also see value in having both upstream and Fedora-packaged versions and letting users decide which they prefer. I'd also like to see "higher technical quality" prioritized over "provided by upstream" — I mean, it's great if upstream does the work, but if someone else can and will do it better, shouldn't we encourage that?
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by uraeus):
In regards to 2 there is code for doing an extra dialog before enabling the installation of the software, including putting up a warning, I haven't really looked at it for a while as I felt the labelling stuff mostly made it redundant in the sense that it felt a bit over the top to both clearly label something as 3rd party and non-free and then also pop up a dialog asking the user if they really want to install this non-free 3rd party software.
As for 3, I agree about having a clear process, as for the details on 1 or more versions or who provides it I tried to leave it open to be something we could evolve and refine over time without having to make a big policy change process for it. I think when I wrote the original text I mostly thought about who would be the most likely party to be around for the longer run and I thought that if the upstream handles it then the upstream is likely to keep doing it for as long as the upstream is maintained, but I realize that we would need to evaluate the truth and validity of that one a case by case basis.
2016-06-16 20:53 GMT+02:00 council trac@fedorahosted.org:
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by uraeus):
In regards to 2 there is code for doing an extra dialog before enabling the installation of the software, including putting up a warning, I haven't really looked at it for a while as I felt the labelling stuff mostly made it redundant in the sense that it felt a bit over the top to both clearly label something as 3rd party and non-free and then also pop up a dialog asking the user if they really want to install this non-free 3rd party software.
As for 3, I agree about having a clear process, as for the details on 1 or more versions or who provides it I tried to leave it open to be something we could evolve and refine over time without having to make a big policy change process for it. I think when I wrote the original text I mostly thought about who would be the most likely party to be around for the longer run and I thought that if the upstream handles it then the upstream is likely to keep doing it for as long as the upstream is maintained, but I realize that we would need to evaluate the truth and validity of that one a case by case basis.
-- Ticket URL: https://fedorahosted.org/council/ticket/57#comment:6 council https://fedorahosted.org/council Fedora Council Public Tickets _______________________________________________ council-discuss mailing list council-discuss@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
https://lists.fedoraproject.org/admin/lists/council-discuss@lists.fedoraproj...
The Fedora Project's mission is to lead the advancement of free and open source software and content as a collaborative community.
Finally I've read this document, but I really have some concerns about third party software. I'm one of those users who believes in Fedora, because it has no third party software in it. It's all open source, that makes it different to other distributions, otherwise I could use plenty of other distros. And I think we should care about this value, and also about all the users who chose Fedora because it has this characteristic. Furthermore, it is very very easy nowadays to install third party software, and people (already) do that on their own risk because often it compromises the Fedora system. Even COPR is a third party repo, but it respects at least the Fedora guidelines, which other repos don't do.
That said, I'm not against enabling a sort of shared installer which labels third party software, but it should not only label it but also pop up a warning that the end user is going to install software outside of the Fedora universe, and that this can in some cases compromise his system. People are used to click and don't think about what they are doing, so we should remember that clearly. I have also some concerns about replacing package formats, we should encourage community members to make Fedora packages, and not just allow upstream package formats. Like Matt I don't understand why we should prefer upstream packages, which very often care more about other distributions...let's prefer community member's packages.
The document actually is still rather generic, if we want to allow third party software in some kind we need to write a very strict document about what we allow and what not. We can facilitate the use of third party software, but Fedora is free and should remain free and open source.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by robyduck):
ah, I only replied to the mail...pasting here again.
Finally I've read this document, but I really have some concerns about third party software. I'm one of those users who believes in Fedora, because it has no third party software in it. It's all open source, that makes it different to other distributions, otherwise I could use plenty of other distros. And I think we should care about this value, and also about all the users who chose Fedora because it has this characteristic. Furthermore, it is very very easy nowadays to install third party software, and people (already) do that on their own risk because often it compromises the Fedora system. Even COPR is a third party repo, but it respects at least the Fedora guidelines, which other repos don't do.
That said, I'm not against enabling a sort of shared installer which labels third party software, but it should not only label it but also pop up a warning that the end user is going to install software outside of the Fedora universe, and that this can in some cases compromise his system. People are used to click and don't think about what they are doing, so we should remember that clearly. I have also some concerns about replacing package formats, we should encourage community members to make Fedora packages, and not just allow upstream package formats. Like Matt I don't understand why we should prefer upstream packages, which very often care more about other distributions...let's prefer community member's packages.
The document actually is still rather generic, if we want to allow third party software in some kind we need to write a very strict document about what we allow and what not. We can facilitate the use of third party software, but Fedora is free and should remain free and open source.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by uraeus):
Replying to [comment:7 robyduck]:
ah, I only replied to the mail...pasting here again.
Finally I've read this document, but I really have some concerns about
third party software.
I'm one of those users who believes in Fedora, because it has no third
party software in it. It's all open source, that makes it different to other distributions, otherwise I could use plenty of other distros. And I think we should care about this value, and also about all the users who chose Fedora because it has this characteristic. Furthermore, it is very very easy nowadays to install third party software, and people (already) do that on their own risk because often it compromises the Fedora system.
Even COPR is a third party repo, but it respects at least the Fedora
guidelines, which other repos don't do.
That said, I'm not against enabling a sort of shared installer which
labels third party software, but it should not only label it but also pop up a warning that the end user is going to install software outside of the Fedora universe, and that this can in some cases compromise his system. People are used to click and don't think about what they are doing, so we should remember that clearly.
I think the proposal also addresses most of your concerns, as there is no suggestion to ship Fedora with non-free software out of the box (well not beyond the firmware we already ship), but in terms of the warning do you want that to happen on every application install? Or on the first time the user tries to install a given piece of 3rd party software? I don't mind the first, but if you want the second I think we cross the line from informative to annoying.
I have also some concerns about replacing package formats, we should
encourage community members to make Fedora packages, and not just allow upstream package formats. Like Matt I don't understand why we should prefer upstream packages, which very often care more about other distributions...let's prefer community member's packages.
Well the document leaves it up to the working groups to decide which package they want to go with, and I think that is a better solution than mandating one or the other package. Which package is the best will be different on a case to case basis and it might even change over time, so tying the hands of the working groups is just shooting ourselves in the foot. In practice I would think that a Fedora specific package would be the best simply because it has been built and configured for Fedora, but I don't want one or the other to be hardcoded in the policy.
The document actually is still rather generic, if we want to allow third
party software in some kind we need to write a very strict document about what we allow and what not. We can facilitate the use of third party software, but Fedora is free and should remain free and open source.
Well remember this is a proposal for software to be available, not bundled or pre-installed, and once again I think we need the working groups to have the ability to evaluate this on an ongoing basis instead of coming up with detailed and inflexible rules and regulations.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
I'd like to separate my feedback on this into two parts. I think the first is relatively easy. That is:
mattdm proposal part 1:
The Fedora Council is generally in favor of a policy like this for third-party software which conforms to Fedora's definition of free and open source software. The policy must specify that the distinction between software provided by Fedora and external software is clear to non-advanced end users. The process for selection/curation of third-party software by Working Groups or SIGs must be community-based and transparent.
I think that's pretty straightforward. Maybe a little wordy. :) Does anyone have objections to tthat? This would allow references to, for example, third-party FlatPak or Docker repositories of free software.
The second part is dealing with non-free third-party software. We know that many of our users use Google Chrome or Steam on Fedora Workstation, for example. I can see that the basic thesis of the proposal is that by making it more apparent to users that they can easily get this popular software on Fedora in an integrated way, we'll grow Fedora usage overall and therefore have a net benefit towards our mission of advancing free and open source software and culture.
Honestly, I'm not sold on that alone. I think our users have no problem going to the web sites for that popular software, and if there are FlatPaks or whatever there, that's probably fine. However, I think by doing that, we actually miss an opportunity for education: when they go to the site for some proprietary software, users just see that. We can use our power in Fedora to gently educate about the value of free software and promote alternatives.
I agree with Josh that we shouldn't dictate implementation details at the council level, but I'd ''really'' like the designers to think about truly advancing this goal through UX design - something ''beyond'' annoying pop- up dialogs. As an example, if someone searches for "web browser", Firefox should come up above Chrome or Opera or whatever.
In fact, I'm inclined to prefer a design where unless an opt-in has been configured (the search tags in one mock-up I saw), only free and open source software would show by default, with perhaps a message like ''"Other results appear in the [nonfree] tag, which is currently filtered out. Click to reset this filter. Fedora does not endorse non-free software. Learn more about [free software and open source software and why this matters....]"''. I know that's implementation, but I mean it by way of example.
If someone searches for particular software and there is an exact match by name, that could show up as ''"{Chrome} appears in the [nonfree] tag, which is ... (then same as above)"''.
I'm willing to try something like this to see if it works. Fedora ''should'' have the flexibility to try things, after all, and I see this as a way to try a new way to advance our ultimate mission. If it is not successful, we can revisit.
So:
mattdm proposal part 2:
The Council recognizes the inclusion of select third-party non-free software in search results as a valid experiment in advancing Fedora's mission. Such search results should prioritize free and open source software, clearly specify that there is no endorsement, and offer links to Fedora-prepared educational information. Additionally, default configuration in Fedora Editions and Spins must hide non-free results from search - although opting in need not be onerous (i.e., it can be a visible filter rather than a buried checkbox, and there can be an indicator that non-free results were hidden).
Council, What do you all think? Paul/Christian/Workstation, does this meet what you're looking for? Rest of Fedora community, what do you think and how do you feel about all this?
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by pfrields):
Replying to [comment:9 mattdm]:
I'd like to separate my feedback on this into two parts. I think the
first is relatively
easy. That is:
mattdm proposal part 1:
The Fedora Council is generally in favor of a policy like this for
third-party software which conforms to Fedora's definition of free and open source software. The policy must specify that the distinction between software provided by Fedora and external software is clear to non-advanced end users. The process for selection/curation of third-party software by Working Groups or SIGs must be community-based and transparent.
I think that's pretty straightforward. Maybe a little wordy. :) Does
anyone have objections to tthat? This would allow references to, for example, third-party FlatPak or Docker repositories of free software.
*Slightly* less wordy? "The Fedora Council supports a third-party software policy that conforms to Fedora's definition of free and open source software. The policy must require a distinction between Fedora-provided and third-party software that is clear to novice users. The selection and curation process for third-party software must be community-based and transparent."
Honestly, I'm not sold on that alone. I think our users have no problem
going to the web sites for that popular software, and if there are FlatPaks or whatever there, that's probably fine. However, I think by doing that, we actually miss an opportunity for education: when they go to the site for some proprietary software, users just see that. We can use our power in Fedora to gently educate about the value of free software and promote alternatives.
I agree with Josh that we shouldn't dictate implementation details at
the council level, but I'd ''really'' like the designers to think about truly advancing this goal through UX design - something ''beyond'' annoying pop-up dialogs. As an example, if someone searches for "web browser", Firefox should come up above Chrome or Opera or whatever.
In fact, I'm inclined to prefer a design where unless an opt-in has been
configured (the search tags in one mock-up I saw), only free and open source software would show by default, with perhaps a message like ''"Other results appear in the [nonfree] tag, which is currently filtered out. Click to reset this filter. Fedora does not endorse non-free software. Learn more about [free software and open source software and why this matters....]"''. I know that's implementation, but I mean it by way of example.
I think putting a click in front of people is bad behavior -- like the "Are you sure? Y/N" prompt, or security related dialogs that reduce security by training people to react without thinking. I feel like labeling in Software, for example, already neatly solves this problem. I immediately know I'm getting something non-free. Perhaps there are changes that could even more effectively make it clear I'm getting something not endorsed by Fedora. But the filter/click doesn't seem useful to me.
Nevertheless, I'd rather get somewhere with this proposal than argue about whether or not to require a click-thru to opt in. As long as we can make the choice persistent, I could live with this. I'm not speaking for the whole Workstation WG here, though. I expect more feedback there, and I don't know the technical constraints for design or development.
I'm willing to try something like this to see if it works. Fedora
''should'' have the flexibility to try things, after all, and I see this as a way to try a new way to advance our ultimate mission. If it is not successful, we can revisit.
This. Thanks.
mattdm proposal part 2:
The Council recognizes the inclusion of select third-party non-free
software in search results as a valid experiment in advancing Fedora's mission. Such search results should prioritize free and open source software, clearly specify that there is no endorsement, and offer links to Fedora-prepared educational information. Additionally, default configuration in Fedora Editions and Spins must hide non-free results from search - although opting in need not be onerous (i.e., it can be a visible filter rather than a buried checkbox, and there can be an indicator that non-free results were hidden).
Council, What do you all think? Paul/Christian/Workstation, does this
meet what you're looking for? Rest of Fedora community, what do you think and how do you feel about all this?
I think part 2 wording is confusing, for instance using "hide" where either you may not mean hide, or you specifically said you don't want to dictate implementation. I understand what you mean but the language is confusing. Again, this is why I feel like the labeling effectively solves the problem already. Perhaps "delineate" would be better here, but I understand you may not feel labeling is *enough* delineation. I would encourage some better language here, though, and that if you don't want to dictate implementation, don't. :-)
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
Replying to [comment:10 pfrields]:
I think part 2 wording is confusing, for instance using "hide" where
either you may not mean hide, or you specifically said you don't want to dictate implementation. I understand what you mean but the language is confusing.
Just re-read and I'm not sure how to rephrase. Suggestions? I definitely _did_ mean "hide", and I don't think that's high level enough that I don't consider it an implementation detail. (_How_ they're hidden — now that is implementation.)
Again, this is why I feel like the labeling effectively solves the
problem already. Perhaps "delineate" would be better here, but I understand you may not feel labeling is *enough* delineation. I would encourage some better language here, though, and that if you don't want to dictate implementation, don't. :-)
Do you have a suggestion for alternate wording? I know you're not on the council, but anyone is free to help. :)
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by pfrields):
Replying to [comment:11 mattdm]:
Again, this is why I feel like the labeling effectively solves the
problem already. Perhaps "delineate" would be better here, but I understand you may not feel labeling is *enough* delineation. I would encourage some better language here, though, and that if you don't want to dictate implementation, don't. :-)
Do you have a suggestion for alternate wording? I know you're not on the
council, but anyone is free to help. :)
What about:
"The Council recognizes including select third-party non-free software in search results is a valid experiment to advance Fedora's mission. Search results should prioritize free and open source software, clearly specify that there is no endorsement, and offer links to Fedora-prepared educational information. Additionally, default configuration in Fedora Editions and Spins must not show non-free search results initially without an additional user interface action. This action need not be onerous, can be persistent, and the interface can indicate these non-free results are available upon action."
Only slightly different, but I think it avoids a bit of potential bikeshedding and is easier to read.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
Thanks. With minor re-rewording:
mattdm proposal part 2:
The Council recognizes including select third-party non-free software in search results as a valid experiment in advancing Fedora's mission. Search results should prioritize free and open source software, clearly specify that there is no endorsement, and offer links to Fedora-prepared educational information. Additionally, default configuration in Fedora Editions and Spins must not show non-free search results initially without an additional user interface action. This action need not be onerous, can be persistent, and the interface can indicate that these non-free results are available upon action.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by rhughes):
Replying to [comment:13 mattdm]:
mattdm proposal part 2:
So, as the person that's going to have to implement this, I have very little idea what the above means, nor whether the upstream designs from Allan and Jimmac are suitable. You are really going to need to elaborate on nearly all of those points to specify something I can implement or test against.
For instance:
"should prioritize" -- this refers to the search ordering in gnome- software, or the shell? or both? If the user searches for "chrome" are you seriously suggesting we should show "Nomacs Image Viewer" first and "Google Chrome" second? If you want me to return firefox when the user searches for chrome then I'm going to need a large table of data of translated keywords and the application-id you'd like me to return for those...
"specify that there is no endorsement" -- in the search results (in which case you're going to need to come up with a way to say "we'd prefer you use free software" in about 40x200px of space...) or in the details page? Can we show it at the bottom under the screenshot and long description or does it have to be some huge modal-style warning box?
"Fedora-prepared educational information" -- do we have URLs to cover non- free and patented available in all supported languages? At the moment we just show a localized description explaining what nonfree software is and allow the user to see the specific licenses (with links to the SPDX site) for free licenses.
"must not show non-free search results" -- do we have to ask the user "your search for 'google chrome' will only show google chrome when you click this button [okay]" as this seems somewhat pointless.
Could someone (mattdm?) test the gnome-software in rawhide (3.21.4) and tell me if what I've implemented is "good enough" for this ticket? In the case where the .repo file is installed but not enabled we still show the dialog to enable the nonfree source just before starting the install action. Thanks.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
Replying to [comment:14 rhughes]:
So, as the person that's going to have to implement this, I have very
little idea what the above means, nor whether the upstream designs from Allan and Jimmac are suitable. You are really going to need to elaborate on nearly all of those points to specify something I can implement or test against.
Sure. I'm happy to clarify.
For instance:
"should prioritize" -- this refers to the search ordering in gnome-
software, or the shell? or both? If the user searches for "chrome" are you seriously suggesting we should show "Nomacs Image Viewer" first and "Google Chrome" second? If you want me to return firefox when the user searches for chrome then I'm going to need a large table of data of translated keywords and the application-id you'd like me to return for those...
It refers to wherever it shows up. I am suggesting that if someone searches for "web browser", open source web browsers be prioritized. "Nomacs Image Viewer" seems to show up on searches for "chrome" because it includes the word "chromeless" in its description; I don't see a problem with putting ''exact'' name matches first (when other settings are such that that result would be shown, of course). It *would* be nice if open source alternatives (rather than random description hits) would show up as alternatives even to exact match searches -- again, the key guidance is that the entire reason to allow non-free software is only in the larger context of our free software mission. If we can't figure out how to do that, we shouldn't do it at all.
"specify that there is no endorsement" -- in the search results (in
which case you're going to need to come up with a way to say "we'd prefer you use free software" in about 40x200px of space...) or in the details page? Can we show it at the bottom under the screenshot and long description or does it have to be some huge modal-style warning box?
I am not a designer, but I'm confident that the designers can come up with a solution that fits within the technical constraints and satisfies our needs. If they can't, we need to either change the technical constraints in some clever way, or just not do it.
Again, I'm not a designer and am trying to steer clear of implementation details, but I think a huge modal warning box would be horrible. On the other hand, burying it in the fine print doesn't seem to advance our goals, either. I'm sure the designers can come up with something better than either of those.
"Fedora-prepared educational information" -- do we have URLs to cover
non-free and patented available in all supported languages? At the moment we just show a localized description explaining what nonfree software is and allow the user to see the specific licenses (with links to the SPDX site) for free licenses.
We can start with English and ask the translation teams to expand those. A localized description seems like a good start, but I do think it'd would be valuable to also have links to more information than can easily fit.
Please don't use SPDX for Fedora license tags. There is not a 1:1 mapping. See https://lists.stg.fedoraproject.org/archives/list/legal@lists.stg.fedoraproj... for discussion.
"must not show non-free search results" -- do we have to ask the user
"your search for 'google chrome' will only show google chrome when you click this button [okay]" as this seems somewhat pointless.
That particular phrasing would be pointless, yes. But that's a caricature of the request. I don't think the phrasing I actually suggested above would be pointless at all.
Could someone (mattdm?) test the gnome-software in rawhide (3.21.4) and
tell me if what I've implemented is "good enough" for this ticket? In the case where the .repo file is installed but not enabled we still show the dialog to enable the nonfree source just before starting the install action. Thanks.
Sure, I'll take a look.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
Replying to [comment:14 rhughes]:
and "Google Chrome" second? If you want me to return firefox when the
user searches for chrome then I'm going to need a large table of data of translated keywords and the application-id you'd like me to return for those...
On this point in specific: since the proposed policy calls for Working Groups to curate the list of third-party repositories (free software and non-free alike), there's actually a natural point for this. We could add that when a third-party non-free application is approved for inclusion in search results, the approving group should also submit a list of free software alternatives.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by tc01):
Rest of Fedora community, what do you think and how do you feel about
all this?
Well, I'm very much in the "rest of Fedora community" camp, but I did have one thought when reading this that does not seem to have been discussed yet, so I figured I'd mention it:
I'm somewhat curious how this would interact with user-added third party repositories with packages that provide GNOME Software metadata. For example, if I enabled RPM Fusion on my system, and there are RPM Fusion packages with Gnome Software metadata, how are they listed when I search for them? Especially if a third-party repo *I* add to my system provides an application that's also being added through this potential procedure and tagged as third-party or non-free, what happens?
I get that we don't officially endorse projects like RPM Fusion, of course, but I would wager many desktop Fedora users install packages from either it or a competing project, so it might be something important to think about?
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
Replying to [comment:18 aday]:
Some comments from your friendly local UX designer... (sorry I'm late to
the party). First, some general comments:
- Please try and state your requirements in abstract terms as much as
possible. I realise that it's difficult to avoid any mention of UI, but it is far better for us on the implementation side if you stick to abstract requirements rather than specifying UI.
I have tried to do this, at least in terms of specific UI, but I think there are some requirements which need to apply to any UI. I want to avoid being so abstract that Richard comes back with "I have no idea how any of this applies". :)
- Please remember "third party" is a distribution specific concept
which will not necessarily fit into the world view of users (since not all users have the role of the distribution firmly established in their minds). While it is obviously fine to use this terminology in your own policies, please don't inadvertently mandate its use in UI: there are ways that we can communicate that software is from a third party without having to specifically use a label that says "third party".
Understood. The relevant part of my proposed statement is: "The policy must specify that the distinction between software provided by Fedora and external software is clear to non-advanced end users." If we can ''help'' make the role of the distribution more clear in the users' minds through this, so much the better.
I realize this wording is a bit awkward, but note that we're trying to establish overall guidance for the specific policy, not the specific policy itself, which can go into more details.
- My impression is that you are mandating the use of confirmation
dialogs as a part of this policy. I wouldn't be doing my job if I didn't point out that these are generally considered to be rather poor UX, not just because they are an inconvenience for users, but also because they are often skipped over without being paid attention to (precisely because they are an inconvenience, I think). Generally speaking I would encourage clear, prominent and easy to understand information about software rather than putting barriers in the way (as Paul has already argued).
I don't know why you have that impression. I said "I'd really like the designers to think about truly advancing this goal through UX design - something beyond annoying pop-up dialogs." I absolutely agree with you here.
mattdm proposal part 1: The Fedora Council is generally in favor of a policy like this for
third-party software which conforms to Fedora's definition of free and open source software. The policy must specify that the distinction between software provided by Fedora and external software is clear to non-advanced end users. The process for selection/curation of third-party software by Working Groups or SIGs must be community-based and transparent.
...
It's not practically possible to solely apply the policy to novice or
advanced users. It might therefore be better to talk about the kinds of interface the policy should be applied to. For example, you could apply the policy to any GUI that presents software installation options. Alternatively, you could talk about "the primary software installation interface" or similar.
The above doesn't say that there should be different policies for novice and advanced users. It says that the distinction must be made clear in a way that non-advanced users can understand. I think you basically make this point as well, which is that just having a small label which says "third-party" probably isn't sufficient as that doesn't necessarily mean anything to many people.
...
mattdm proposal part 2:
The Council recognizes including select third-party non-free
software in search results as a valid experiment in advancing Fedora's mission. Search results should prioritize free and open source software, clearly specify that there is no endorsement, and offer links to Fedora- prepared educational information. Additionally, default configuration in Fedora Editions and Spins must not show non-free search results initially without an additional user interface action. This action need not be onerous, can be persistent, and the interface can indicate that these non- free results are available upon action.
...
Why the sole focus on search? What about other ways that software can be
presented and discovered? In general it would be better if the mechanisms through which software might be present weren't specified at all.
The emphasis on search is because that's the software and shell interface I've been looking at, but I definitely agree with you here too: this should apply to all presentation, not just search.
The part about endorsement of non-free software is unclear. Is the
requirement that Fedora's position on free versus non-free software be communicated to users as an explicit policy statement? Or is it the case that the UI should communicate that free/open software is preferable to non-free software in a more general sense, and therefore communicate Fedora's policy in a non-explicit, implied manner? For what it's worth, my personal preference is the latter option: it is more effective than an official pronouncement and can be done in a way that more effectively promotes free/open software.
It's currently Fedora's position that we don't present any non-free software at all. We're talking about changing that, which is a big move. I think that if we do make such a change, an explicit statement is important. I'm concerned that a "non-explicit, implied manner" to one person may be "oh, I didn't notice that at all" to... most people. Additionally, there is significant value in Fedora being seen as taking a stance here.
Again, I don't want a big horrible dialog box, but the position should be unmistakable.
Without committing to a specific implementation, can you give an example of what a non-explicit, implied manner might look like, and particularly how it might more effectively promote free/open software?
What is "Fedora-prepared educational information"? What is its purpose?
Why does it have to be Fedora-prepared? Why are you specifying that it should be linked to, rather than being presented in some other way? (Apologies if I've missed the answers to these questions somewhere.)
It should be Fedora-prepared because Fedora's particular stance and voice on free and open source software is not necessarily 100% the same as that of organizations. While we respect and value the FSF, OSI, SPI, GNOME, and other organizations, we don't have exactly the same positions and might explain things in a different way. The use of SPDX resources for license tags is an example; they mean something different than Fedora does when we use "License: MIT".
I'm generally unconvinced by the idea of prioritising apps in search
results based on whether they are free or not. In terms of the Software app, I doubt very much that the position of an app in the results will influence user behaviour or communicate anything worthwhile: we don't have many apps and the lists on-target search results are never than long. I mean, how many web browsers do you expect to show up?! And again, a more abstract statement would be desirable from my point of view, like "when presenting equivalent software options, an effort should be made to ensure that free/open software alternatives are given prominence alongside non- free options". This captures the intent behind the policy and ensures that it will be implemented across whatever UI comes up, rather than being restricted to a particular part of the UI.
Right now, I count 11 results for "web browser" in Software. Not all of them are "good" results.
I like your general approach here, but I'd like:
* something wider than "equivalent" (because I don't want to get into "oh, Firefox isn't equivalent to Chrome because it doesn't include $somefeature") * something stronger than "an effort should be made" (because "an effort" could be anything, and I don't want to get into quibbling over whether some token reference counts) * "over" instead of "alongside". That's kind of the point.
I don't understand the final sentence. It seems to say that users are
required to explicitly enable non-free software before it is made visible to them, but then it goes on to state "the interface can indicate that these non-free results are available upon action". Are you suggesting that the UI should indicate that there are hidden results, somehow? Again, please state your requirements in abstract terms if possible.
My proposal is that by default, non-free software must not be shown, but when presenting software options, it is okay to indicate that non-free software ''could'' be shown by changing those options — and again, with some faith that you can come up with an elegant way to do this.
Previously, I gave an example ''"Other results appear in the [nonfree] tag, which is currently filtered out. Click to reset this filter. Fedora does not endorse non-free software. Learn more about [free software and open source software and why this matters....]"''. This is obviously implementation, but I hope it's illustrative. Or, if someone searches for particular software and there is an exact match by name, that could show up as ''"{Chrome} appears in the [nonfree] tag, which is ... (then same as above)"''.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
Replying to [comment:14 rhughes]:
Could someone (mattdm?) test the gnome-software in rawhide (3.21.4) and
tell me if what I've implemented is "good enough" for this ticket? In the case where the .repo file is installed but not enabled we still show the dialog to enable the nonfree source just before starting the install action. Thanks.
So, I installed that and dropped in Google's chrome repo file, but I don't see Chrome showing up in search -- do you have a test-case?
I see various software has "third-party" tags, which is weird, because this system has no non-Fedora software. It's labeled Midori as third- party, for example. That seems more like a bug than a policy problem. I don't see any way to as a user to filter by tags, though.
I know we're way into the implementation details that Alan wants me to stay away from, but the blue boxes with information describing what the tags mean seem fine to me in placement (although the text could use expansion), at least for within the display of individual applications.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by rhughes):
Replying to [comment:19 mattdm]:
The use of SPDX resources for license tags is an example; they mean
something different than Fedora does when we use "License: MIT".
Okay, this might be a concrete issue. The AppStream specification explicitly specifies SPDX (and is shipped in AppStream and specified by AppData files) as it's designed to be used by multiple distributions and has already been adopted natively by both Debian and Suse. Being blunt, although Fedora did a lot of "picking apart" of the license issues back in the day, we can't base a freedesktop spec on the specific wording of how Fedora Legal interprets specific parts of a license text. If SPDX and Fedora disagree on the meaning of MIT we should probably fix that.
Upstream is now specifying the license as an SPDX string in the AppData file, and we're showing that in preference to the license specified in the spec file. If that needs to change then we're going to need pages like https://spdx.org/licenses/GPL-2.0 specifically for Fedora license IDs, and we're also going to need an explicit grammar for the License: line in the spec file -- at the moment lots of packages are just specifying case- incorrect text not designed for machine reading.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by aday):
This is a selective reply. If I haven't responded to an issue it is either fine or doesn't require follow up.
But first, a general request: please make an effort to keep the amount of Fedora specific links and text to an absolute minimum. They result in a heavy maintenance and testing burden.
Replying to [comment:19 mattdm]: ...
- My impression is that you are mandating the use of confirmation
dialogs as a part of this policy. I wouldn't be doing my job if I didn't point out that these are generally considered to be rather poor UX, not just because they are an inconvenience for users, but also because they are often skipped over without being paid attention to (precisely because they are an inconvenience, I think). Generally speaking I would encourage clear, prominent and easy to understand information about software rather than putting barriers in the way (as Paul has already argued).
I don't know why you have that impression. I said "I'd really like the
designers to think about truly advancing this goal through UX design - something beyond annoying pop-up dialogs." I absolutely agree with you here.
I did work on a set of confirmation dialogs in the past, which I was led to believe was a Fedora requirement - I was probably thinking of that. Great if those aren't required!
Why the sole focus on search? What about other ways that software can
be presented and discovered? In general it would be better if the mechanisms through which software might be present weren't specified at all.
The emphasis on search is because that's the software and shell
interface I've been looking at, but I definitely agree with you here too: this should apply to all presentation, not just search.
It would be good if the policy could be updated to reflect this.
The part about endorsement of non-free software is unclear. Is the
requirement that Fedora's position on free versus non-free software be communicated to users as an explicit policy statement? Or is it the case that the UI should communicate that free/open software is preferable to non-free software in a more general sense, and therefore communicate Fedora's policy in a non-explicit, implied manner? For what it's worth, my personal preference is the latter option: it is more effective than an official pronouncement and can be done in a way that more effectively promotes free/open software.
It's currently Fedora's position that we don't present any non-free
software at all. We're talking about changing that, which is a big move. I think that if we do make such a change, an explicit statement is important. I'm concerned that a "non-explicit, implied manner" to one person may be "oh, I didn't notice that at all" to... most people. Additionally, there is significant value in Fedora being seen as taking a stance here.
Again, I don't want a big horrible dialog box, but the position should
be unmistakable.
Without committing to a specific implementation, can you give an example
of what a non-explicit, implied manner might look like, and particularly how it might more effectively promote free/open software?
We've been working on improving the UI for this recently. The details page for each app now shows a prominent colour coded badge that indicates whether an app is free or proprietary. If you click on the badge, a popover is shown which explains what "free" or "proprietary" means, as well as details like which licenses are used. The explanation text is value driven but also tries to be informative. It's clear that free software is being presented positively and proprietary software negatively.
The user is always exposed to the badges prior to installing an app.
Now, you could add some "Fedora officially disapproves of proprietary software" text but I'd recommend against doing that. Telling your users off for something they're doing is one of the worst things you can do from a branding/user experience point of view. Much better to sell the benefits of free software and explain the issues with proprietary software in a way that doesn't imply a judgement on the user.
What is "Fedora-prepared educational information"? What is its
purpose? Why does it have to be Fedora-prepared? Why are you specifying that it should be linked to, rather than being presented in some other way? (Apologies if I've missed the answers to these questions somewhere.)
It should be Fedora-prepared because Fedora's particular stance and
voice on free and open source software is not necessarily 100% the same as that of organizations. While we respect and value the FSF, OSI, SPI, GNOME, and other organizations, we don't have exactly the same positions and might explain things in a different way. The use of SPDX resources for license tags is an example; they mean something different than Fedora does when we use "License: MIT".
I really have to question whether this is necessary. We already provide a simple explanation in the UI. It might not communicate the Fedora world view in all its nuanced subtly, but I would be *really* surprised if there is any appetite amongst users to read detailed licensing information and adding these links will be a lot of work.
I'm generally unconvinced by the idea of prioritising apps in search
results based on whether they are free or not. In terms of the Software app, I doubt very much that the position of an app in the results will influence user behaviour or communicate anything worthwhile: we don't have many apps and the lists on-target search results are never than long. I mean, how many web browsers do you expect to show up?! And again, a more abstract statement would be desirable from my point of view, like "when presenting equivalent software options, an effort should be made to ensure that free/open software alternatives are given prominence alongside non- free options". This captures the intent behind the policy and ensures that it will be implemented across whatever UI comes up, rather than being restricted to a particular part of the UI.
Right now, I count 11 results for "web browser" in Software. Not all of
them are "good" results.
Right, you only get 2 or 3 actual browsers. The order of these isn't going to make any difference to how the user perceives the options.
I like your general approach here, but I'd like:
- something wider than "equivalent" (because I don't want to get into
"oh, Firefox isn't equivalent to Chrome because it doesn't include $somefeature")
- something stronger than "an effort should be made" (because "an
effort" could be anything, and I don't want to get into quibbling over whether some token reference counts)
- "over" instead of "alongside". That's kind of the point.
Feel free to reword as you see fit, but I would prefer a bit of room for manoeuvre - in most contexts minor ordering differences aren't going to make a meaningful difference and it's more work for us to implement this. I accept that you wouldn't want big banners for non-free apps and little tiles for free ones, of course. Maybe something like:
"when presenting software that has the same functionality, non-free alternatives should not be given a non-trivial degree of prominence over free/open software options" ?
I don't understand the final sentence. It seems to say that users are
required to explicitly enable non-free software before it is made visible to them, but then it goes on to state "the interface can indicate that these non-free results are available upon action". Are you suggesting that the UI should indicate that there are hidden results, somehow? Again, please state your requirements in abstract terms if possible.
My proposal is that by default, non-free software must not be shown, but
when presenting software options, it is okay to indicate that non-free software ''could'' be shown by changing those options — and again, with some faith that you can come up with an elegant way to do this.
Previously, I gave an example ''"Other results appear in the [nonfree]
tag, which is currently filtered out. Click to reset this filter. Fedora does not endorse non-free software. Learn more about [free software and open source software and why this matters....]"''. This is obviously implementation, but I hope it's illustrative. Or, if someone searches for particular software and there is an exact match by name, that could show up as ''"{Chrome} appears in the [nonfree] tag, which is ... (then same as above)"''.
Please remember that software can be presented in multiple ways - in search results in the shell, when browsing using the Software app, when an app is requested to open a particular file type, when an app requests a particular codec, and who knows what other ways. We can't go embedding this choice into every one of those situations.
With that in mind, this "action" would probably have to be presented as an option to enable non-free software as a part of the initial setup process. Again, please try and keep your UI prescriptions to a minimum: the policy could simply state "non-free software must be explicitly enabled by a user before it is made visible in any UI". That's short and clear, and leaves us to figure out the details.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by rhughes):
Replying to [comment:22 aday]:
With that in mind, this "action" would probably have to be presented as
an option to enable non-free software as a part of the initial setup process.
This makes a lot of sense to me, if it works for you Matt. Allan, do you have any tentative mockups to how this might look? I'd really much prefer to get this upstream (also, so other distros can use it) so that we don't have to monkey-patch this in and get the various translations manually fudged in after the GNOME UI freeze. I guess doing it in anaconda might also be acceptable, but I'd defer to Allan on that.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by spot):
Replying to [comment:21 rhughes]:
Replying to [comment:19 mattdm]:
The use of SPDX resources for license tags is an example; they mean
something different than Fedora does when we use "License: MIT".
Okay, this might be a concrete issue. The AppStream specification
explicitly specifies SPDX (and is shipped in AppStream and specified by AppData files) as it's designed to be used by multiple distributions and has already been adopted natively by both Debian and Suse. Being blunt, although Fedora did a lot of "picking apart" of the license issues back in the day, we can't base a freedesktop spec on the specific wording of how Fedora Legal interprets specific parts of a license text. If SPDX and Fedora disagree on the meaning of MIT we should probably fix that.
*deep breath* Boy, that'd be nice. I'm not sure it is ever going to happen. We've got different philosophies. Take a look at the MIT subsection at Fedora:
https://fedoraproject.org/wiki/Licensing:MIT
It begins with this text:
"There are many MIT variants, all of which are functionally identical."
SPDX disagrees. They think that any wording change in a license, no matter how trivial, results in a new license. Fedora decided a long time ago that all of these MIT variants, as long as they resulted in the same basic set of permissions/restrictions, would be called "MIT". I've been talking to the SPDX project team since they formed, and we long ago determined to simply agree to disagree here. Fedora calls all 33 (known) MIT variants "MIT", and SPDX only calls the one MIT entry from the OSI list as "MIT" (and doesn't have a classification for the other 32 variants).
Upstream is now specifying the license as an SPDX string in the AppData
file, and we're showing that in preference to the license specified in the spec file. If that needs to change then we're going to need pages like https://spdx.org/licenses/GPL-2.0 specifically for Fedora license IDs, and we're also going to need an explicit grammar for the License: line in the spec file -- at the moment lots of packages are just specifying case- incorrect text not designed for machine reading.
Citation needed on "lots of packages". We also have an explicit grammar for the License: line. https://fedoraproject.org/wiki/Packaging:LicensingGuidelines
That said, I _do_ understand why you're using SPDX strings in the AppData files. SPDX (with my help) has been putting in significant effort to ensure that the majority of Fedora licenses have matching SPDX entries. MIT is an exception, rather than the rule. I'm not concerned about how you are currently using SPDX resources in this context.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
Replying to [comment:22 aday]:
This is a selective reply. If I haven't responded to an issue it is
either fine or doesn't require follow up.
Yep; I'll follow the same. Ideally we'll get down to nothing here. :)
But first, a general request: please make an effort to keep the amount
of Fedora specific links and text to an absolute minimum. They result in a heavy maintenance and testing burden.
That makes sense, but I'm also mindful that Fedora's mission and agenda aren't shared by all consumers of the software impacted by this. Fedora's mission isn't just to create an operating system that happens to be open source, but to actively "lead the advancement of Free and open source software and content". Since including curated links to proprietary software is on its face a non-neutral change, I want to make sure that we firmly place it in context. If we can do that in a way that meets our needs and also is acceptable as general defaults, that's even better, really.
I did work on a set of confirmation dialogs in the past, which I was led
to believe was a Fedora requirement - I was probably thinking of that. Great if those aren't required!
We are in new waters here. That includes that so far I've made most of the commentary on this ticket, and I don't alone speak for the whole community or Council.
The emphasis on search is because that's the software and shell
interface I've been looking at, but I definitely agree with you here too: this should apply to all presentation, not just search.
It would be good if the policy could be updated to reflect this.
I'll think about some updated wording taking your comments into account.
We've been working on improving the UI for this recently. The details
page for each app now shows a prominent colour coded badge that indicates whether an app is free or proprietary. If you click on the badge, a popover is shown which explains what "free" or "proprietary" means, as well as details like which licenses are used. The explanation text is value driven but also tries to be informative. It's clear that free software is being presented positively and proprietary software negatively.
Ok. In the rawhide version I'm looking at right now, the tags are gray rather than colored and there's no popover. What you describe seems good to me.
Now, you could add some "Fedora officially disapproves of proprietary
software" text but I'd recommend against doing that. Telling your users off for something they're doing is one of the worst things you can do from a branding/user experience point of view. Much better to sell the benefits of free software and explain the issues with proprietary software in a way that doesn't imply a judgement on the user.
That sounds reasonable. As above, I was thinking more along the lines of ''Learn more about free software and open source software and why this matters....'' than "you are a terrible person for using proprietary software".
I really have to question whether this is necessary. We already provide
a simple explanation in the UI. It might not communicate the Fedora world view in all its nuanced subtly, but I would be *really* surprised if there is any appetite amongst users to read detailed licensing information and adding these links will be a lot of work.
If we provide links to license information, it does need to at least be the right mapping, even if it's a lot of work. I agree with Richard that it's unfortunate that we're not regularized with SPDX, but we're not the only ones (see Debian https://wiki.debian.org/Proposals/CopyrightFormat#Differences_between_DEP5_a...) and it's not an easy thing to fix.
But I wasn't talking about the specific license information; I was thinking more of a "why open source is awesome". In talking to Christian, one case for presenting proprietary software is to bring in new users who don't understand our values or culture. I don't think there's a lot of value in doing that if we don't take the opportunity to help them learn. You can disagree with me, and that's fine -- but also exactly why I thought it might be a good idea to have something Fedora-specific here. I'd be just as happy with non-specific materials which are well-aligned with our mission.
I'm generally unconvinced by the idea of prioritising apps in search
results based on whether they are free or not. In terms of the Software app, I doubt very much that the position of an app in the [...]
Right now, I count 11 results for "web browser" in Software. Not all
of them are "good" results.
Right, you only get 2 or 3 actual browsers. The order of these isn't
going to make any difference to how the user perceives the options.
Really? To me at least, ordering matters quite a lot. There's a reason people want to be the top hit on Google, etc.
"when presenting software that has the same functionality, non-free
alternatives should not be given a non-trivial degree of prominence over free/open software options" ?
I like that, but I guess I'd prefer "when presenting software that has the same functionality, free/open source software ''should'' be given a non-trivial degree of prominence over non-free options".
Previously, I gave an example ''"Other results appear in the [nonfree]
tag, which is currently filtered out. Click to reset this filter. Fedora does not endorse non-free software. Learn more about [free software and open source software and why this matters....]"''. This is obviously implementation, but I hope it's illustrative. Or, if someone searches for particular software and there is an exact match by name, that could show up as ''"{Chrome} appears in the [nonfree] tag, which is ... (then same as above)"''.
Please remember that software can be presented in multiple ways - in
search results in the shell, when browsing using the Software app, when an app is requested to open a particular file type, when an app requests a particular codec, and who knows what other ways. We can't go embedding this choice into every one of those situations.
I guess I see it as an extra bonus towards discoverability, and something which could easily just be left off in cases where there's no opportunity (and just not show currently-filtered-out options at all in those cases).
With that in mind, this "action" would probably have to be presented as
an option to enable non-free software as a part of the initial setup process. Again, please try and keep your UI prescriptions to a minimum: the policy could simply state "non-free software must be explicitly enabled by a user before it is made visible in any UI". That's short and clear, and leaves us to figure out the details.
I don't have a strong opinion on this — seems like an implementation detail. I guess my two concerns are first that existing users won't see the initial setup screen (I can't remember the last time I saw it other than when intentionally testing!) and second that it's my impression that many new users click through that setup screen quickly and then later forget what was there, so I presume you'd want it somewhere else easily discoverable as well. (That's one thing I liked about the search-tags mockup I saw — it wasn't a "buried setting".)
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
Replying to [comment:24 spot]:
That said, I _do_ understand why you're using SPDX strings in the
AppData files. SPDX (with my help) has been putting in significant effort to ensure that the majority of Fedora licenses have matching SPDX entries. MIT is an exception, rather than the rule. I'm not concerned about how you are currently using SPDX resources in this context.
Thanks Tom. I'll drop that as a concern, then.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
Also: I think we're mostly discussing nuances of what I called "the second part". Aside from possible clarifications of phrasing, are all Council members okay with "part 1"? That is, something like:
The Fedora Council supports a third-party software policy that conforms to Fedora's definition of free and open source software. The policy must require a distinction between Fedora-provided and third-party software that is clear to novice users. The selection and curation process for third-party software must be community-based and transparent.
?
Is anyone ''opposed'' to this?
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by aday):
Replying to [comment:25 mattdm]: ...
But first, a general request: please make an effort to keep the amount
of Fedora specific links and text to an absolute minimum. They result in a heavy maintenance and testing burden.
That makes sense, but I'm also mindful that Fedora's mission and agenda
aren't shared by all consumers of the software impacted by this. Fedora's mission isn't just to create an operating system that happens to be open source, but to actively "lead the advancement of Free and open source software and content". Since including curated links to proprietary software is on its face a non-neutral change, I want to make sure that we firmly place it in context. If we can do that in a way that meets our needs and also is acceptable as general defaults, that's even better, really.
I understand that there has to be balance. I am simply requesting that maintenance burden be factored in - our resources are limited and this policy is going to generate additional ongoing work for the team.
I did work on a set of confirmation dialogs in the past, which I was
led to believe was a Fedora requirement - I was probably thinking of that. Great if those aren't required!
We are in new waters here. That includes that so far I've made most of
the commentary on this ticket, and I don't alone speak for the whole community or Council.
Sure, we'll certainly wait before the policy is finalised before making any changes.
I really have to question whether this is necessary. We already
provide a simple explanation in the UI. It might not communicate the Fedora world view in all its nuanced subtly, but I would be *really* surprised if there is any appetite amongst users to read detailed licensing information and adding these links will be a lot of work.
This comment was made under the assumption that "Fedora educational materials" was some additional information about the licenses themselves, such as which licenses are approved by Fedora and how they should be interpreted - detailed legal and political interpretation, in other words. From your response below I see that that is probably incorrect; if this part of the policy remains, it might help for it to elaborate on what "Fedora educational materials" are and what their purpose is.
If we provide links to license information, it does need to at least be
the right mapping, even if it's a lot of work. I agree with Richard that it's unfortunate that we're not regularized with SPDX, but we're not the only ones (see Debian https://wiki.debian.org/Proposals/CopyrightFormat#Differences_between_DEP5_a...) and it's not an easy thing to fix.
But I wasn't talking about the specific license information; I was
thinking more of a "why open source is awesome". In talking to Christian, one case for presenting proprietary software is to bring in new users who don't understand our values or culture. I don't think there's a lot of value in doing that if we don't take the opportunity to help them learn. You can disagree with me, and that's fine -- but also exactly why I thought it might be a good idea to have something Fedora-specific here. I'd be just as happy with non-specific materials which are well-aligned with our mission.
I think it's important to provide links to the full license text; I'll leave you to argue over the details for that with Richard. I'm also fine with linking to generic "why open source is awesome" material. However, it would be really preferable if this could be non-Fedora specific - it will be a lot less work for us.
I'm generally unconvinced by the idea of prioritising apps in
search results based on whether they are free or not. In terms of the Software app, I doubt very much that the position of an app in the
[...]
Right now, I count 11 results for "web browser" in Software. Not all
of them are "good" results.
Right, you only get 2 or 3 actual browsers. The order of these isn't
going to make any difference to how the user perceives the options.
Really? To me at least, ordering matters quite a lot. There's a reason
people want to be the top hit on Google, etc.
I'm largely thinking about cases where there is some familiarity with the applications on offer, which is somewhat different from the generic search engine case. That said I see the point about search results ordering having an impact. At the same time I would still argue against the necessity of tweaking search results in this way, since we'd be adding extra logic for a case that will be fairly infrequent. Do we really want to spend developer time on tweaking what happens when someone searches for "web browser"?
"when presenting software that has the same functionality, non-free
alternatives should not be given a non-trivial degree of prominence over free/open software options" ?
I like that, but I guess I'd prefer "when presenting software that has
the same functionality, free/open source software ''should'' be given a non-trivial degree of prominence over non-free options".
That's an inversion of the logic I was suggesting. :) My point was: let's only make special effort when it is going to have a significant impact. You're saying that we should always make a special effort.
While I'm happy for us to make an effort when it counts, it's simply not practical to change the logic in every case that software might be presented to a user.
Previously, I gave an example ''"Other results appear in the
[nonfree] tag, which is currently filtered out. Click to reset this filter. Fedora does not endorse non-free software. Learn more about [free software and open source software and why this matters....]"''. This is obviously implementation, but I hope it's illustrative. Or, if someone searches for particular software and there is an exact match by name, that could show up as ''"{Chrome} appears in the [nonfree] tag, which is ... (then same as above)"''.
Please remember that software can be presented in multiple ways - in
search results in the shell, when browsing using the Software app, when an app is requested to open a particular file type, when an app requests a particular codec, and who knows what other ways. We can't go embedding this choice into every one of those situations.
I guess I see it as an extra bonus towards discoverability, and
something which could easily just be left off in cases where there's no opportunity (and just not show currently-filtered-out options at all in those cases).
With that in mind, this "action" would probably have to be presented
as an option to enable non-free software as a part of the initial setup process. Again, please try and keep your UI prescriptions to a minimum: the policy could simply state "non-free software must be explicitly enabled by a user before it is made visible in any UI". That's short and clear, and leaves us to figure out the details.
I don't have a strong opinion on this — seems like an implementation
detail. I guess my two concerns are first that existing users won't see the initial setup screen (I can't remember the last time I saw it other than when intentionally testing!) and second that it's my impression that many new users click through that setup screen quickly and then later forget what was there, so I presume you'd want it somewhere else easily discoverable as well. (That's one thing I liked about the search-tags mockup I saw — it wasn't a "buried setting".)
We can work on the specific design - I don't think we need to figure out the exact solution here. My point was that the proposed policy specified a UI which wasn't practical. It would be preferable if you didn't specify the exact UI to be used, so we can figure out the best solution - those of us who work on the software are in a better position to do that. Again, my suggestion for the policy would be something simple and abstract:
"Non-free software must be explicitly enabled by a user before it is made visible in any UI."
You could add an additional clause like:
"However, the availability of non-free software options can be advertised prior to its enablement, provided that specific details about that software are not displayed."
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by jwboyer):
Replying to [comment:27 mattdm]:
Also: I think we're mostly discussing nuances of what I called "the
second part". Aside from possible clarifications of phrasing, are all Council members okay with "part 1"? That is, something like:
The Fedora Council supports a third-party software policy that
conforms to Fedora's definition of free and open source software. The policy must require a distinction between Fedora-provided and third-party software that is clear to novice users. The selection and curation process for third-party software must be community-based and transparent.
?
Is anyone ''opposed'' to this?
I'm fine with this part of the proposal.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by jwboyer):
Replying to [comment:28 aday]:
Replying to [comment:25 mattdm]:
I'm generally unconvinced by the idea of prioritising apps in
search results based on whether they are free or not. In terms of the Software app, I doubt very much that the position of an app in the
[...]
Right now, I count 11 results for "web browser" in Software. Not
all of them are "good" results.
Right, you only get 2 or 3 actual browsers. The order of these isn't
going to make any difference to how the user perceives the options.
Really? To me at least, ordering matters quite a lot. There's a reason
people want to be the top hit on Google, etc.
I'm largely thinking about cases where there is some familiarity with
the applications on offer, which is somewhat different from the generic search engine case. That said I see the point about search results ordering having an impact. At the same time I would still argue against the necessity of tweaking search results in this way, since we'd be adding extra logic for a case that will be fairly infrequent. Do we really want to spend developer time on tweaking what happens when someone searches for "web browser"?
It seems this could be done generically based on the tags in the metadata. If something is tagged with "non-free" or "proprietary", you sort it after things that aren't. It avoids very specific case by case implementations.
Previously, I gave an example ''"Other results appear in the
[nonfree] tag, which is
We can work on the specific design - I don't think we need to figure out
the exact solution here. My point was that the proposed policy specified a UI which wasn't practical. It would be preferable if you didn't specify the exact UI to be used, so we can figure out the best solution - those of us who work on the software are in a better position to do that. Again, my suggestion for the policy would be something simple and abstract:
"Non-free software must be explicitly enabled by a user before it is
made visible in any UI."
You could add an additional clause like:
"However, the availability of non-free software options can be
advertised prior to its enablement, provided that specific details about that software are not displayed."
I actually think that additional clause is counter to what Matt is aiming for. Or perhaps I'm misunderstanding. Why would we advertise e.g. Chrome as available but having no details without the user explicitly opting in to non-free software?
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by jwboyer):
Replying to [comment:13 mattdm]:
Thanks. With minor re-rewording:
mattdm proposal part 2:
The Council recognizes including select third-party non-free software
in search results as a valid experiment in advancing Fedora's mission. Search results should prioritize free and open source software, clearly specify that there is no endorsement, and offer links to Fedora-prepared educational information. Additionally, default configuration in Fedora Editions and Spins must not show non-free search results initially without an additional user interface action. This action need not be onerous, can be persistent, and the interface can indicate that these non-free results are available upon action.
To be honest, I'm not convinced the additional educational information requirement is worthwhile. If this was 10 years ago, I would whole- heartedly agree. Today though, I think it would come off as preachy and dated. The only situation I can think of where a user might be using Fedora and NOT know about open source in general are student lab or employer supplied machines where they (or someone close to them) didn't do the install themselves. I understand the material would be in line with our Mission, so I'm not opposed to it per se. I think if we're going to include it, it should be presented on the initial "show non-free results" option though. NOT for every search result. That seems like a quick way to irritate people.
And that detail seems to highlight a specific problem with the currently worded proposal. Despite best intentions, it is very implementation oriented. That is further affirmed by the entire rest of this ticket discussion.
It might be better to simply state it as:
"The Council recognizes including selected third-party non-free software in search results as a valid experiment in advancing Fedora's mission. Search results for non-free software may not be presented without explicit user enablement in any Fedora Edition or Spin."
I do like the prioritization/ordering issue discussed above, but it is very difficult to work into a proposal without dictating implementation.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by aday):
Replying to [comment:30 jwboyer]:
"However, the availability of non-free software options can be
advertised prior to its enablement, provided that specific details about that software are not displayed."
I actually think that additional clause is counter to what Matt is
aiming for. Or perhaps I'm misunderstanding. Why would we advertise e.g. Chrome as available but having no details without the user explicitly opting in to non-free software?
That suggestion was my attempt to rephrase Matt's original proposal, so maybe there was a misunderstanding along the way (or maybe I'm just not communicating well). The idea, I thought, was to indicate that non-free software is available in a generic way, without giving details about the individual non--free apps (imagine something like "enable non-free software to see more").
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by aday):
Replying to [comment:31 jwboyer]:
Replying to [comment:13 mattdm]:
Thanks. With minor re-rewording:
mattdm proposal part 2:
The Council recognizes including select third-party non-free
software in search results as a valid experiment in advancing Fedora's mission. Search results should prioritize free and open source software, clearly specify that there is no endorsement, and offer links to Fedora- prepared educational information. Additionally, default configuration in Fedora Editions and Spins must not show non-free search results initially without an additional user interface action. This action need not be onerous, can be persistent, and the interface can indicate that these non- free results are available upon action.
To be honest, I'm not convinced the additional educational information
requirement is worthwhile. If this was 10 years ago, I would whole- heartedly agree. Today though, I think it would come off as preachy and dated. The only situation I can think of where a user might be using Fedora and NOT know about open source in general are student lab or employer supplied machines where they (or someone close to them) didn't do the install themselves. I understand the material would be in line with our Mission, so I'm not opposed to it per se. I think if we're going to include it, it should be presented on the initial "show non-free results" option though. NOT for every search result. That seems like a quick way to irritate people.
And that detail seems to highlight a specific problem with the currently
worded proposal. Despite best intentions, it is very implementation oriented. That is further affirmed by the entire rest of this ticket discussion.
It might be better to simply state it as:
"The Council recognizes including selected third-party non-free software
in search results as a valid experiment in advancing Fedora's mission. Search results for non-free software may not be presented without explicit user enablement in any Fedora Edition or Spin." ...
Again, this policy is about more than search: there are other ways that software is presented and can be discovered. For example you could rephrase to something like:
"The Council recognizes that allowing selected third-party non-free software to be installed is a valid experiment in advancing Fedora's mission. Non-free software may not be presented to the user without explicit user enablement in any Fedora Edition or Spin."
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
Okay, getting back to this.... first,
The Fedora Council supports a third-party software policy that conforms
to Fedora's definition of free and open source software. The policy must require a distinction between Fedora-provided and third-party software that is clear to novice users. The selection and curation process for third-party software must be community-based and transparent.
is '''approved'''.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
For the second part,
"The Council recognizes that allowing selected third-party non-free
software to be installed is a valid experiment in advancing Fedora's mission. Non-free software may not be presented to the user without explicit user enablement in any Fedora Edition or Spin."
This covers the opt-in aspect, but it loses a couple of things that I feel are really important -- in fact, ''more'' important.
First, whether it's in search or any other interface, I think there needs to be a distinction in presentation between non-free and free/open software which is understandable to all levels of user.
Second, I want this whole thing to be in service of promoting free/open software. Prioritizing search results is a suggestion for one way that could manifest, and the educational materials are another way, but I hope the design will really reflect that goal throughout.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by jwboyer):
Replying to [comment:35 mattdm]:
For the second part,
"The Council recognizes that allowing selected third-party non-free
software to be installed is a valid experiment in advancing Fedora's mission. Non-free software may not be presented to the user without explicit user enablement in any Fedora Edition or Spin."
This covers the opt-in aspect, but it loses a couple of things that I
feel are really important -- in fact, ''more'' important.
First, whether it's in search or any other interface, I think there
needs to be a distinction in presentation between non-free and free/open software which is understandable to all levels of user.
That is hopefully achievable with the tagging/labeling that Software is already planning on doing.
Second, I want this whole thing to be in service of promoting free/open
software. Prioritizing search results is a suggestion for one way that could manifest, and the educational materials are another way, but I hope the design will really reflect that goal throughout.
The problem I have with this is that it's very much a subjective thing. It's one of those "I'll know it when I see it" items, which has the potential to drag on with a lot of back and forth.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by cwickert):
Sorry for joining the discussion so late. Overall I'm happy with what I read, most importantly that people brought up the same concerns I share.
I'm +1 on the first part of the statement that was already ratified in comment:34 and I definitely want opt-in.
I don't care much how 'explicit' the graphical presentation of the opt-in is, this is up to the UI designers. Including non-free apps may be suggested (e.g. ''"some results were excluded from your search. Click here to show them"'') but not recommended. A simple confirmation of a default is not enough, I want the user to actively do it. And we need a "More Info" link that explains the background, e.g. why we believe in FLOSS.
What I want most of all is that FLOSS is preferred over non-free software. Searching for Chrome should return "Chromium" before "Chrome" if possible.
This being said I'm happy with
"The Council recognizes that allowing selected third-party non-free
software to be installed is a valid experiment in advancing Fedora's mission. Non-free software may not be presented to the user without explicit user enablement in any Fedora Edition or Spin."
but I think we need one more sentence for the issues mattdm raised in comment:35.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
We discussed the second part at the meeting today. Rather than driving things into the ground with theoretical back-and-forth, we're in favor of a general "okay, with the input given in the ticket already". We'd like to see concrete design mockups which we can give feedback on.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by uraeus):
Replying to [comment:37 cwickert]:
Sorry for joining the discussion so late. Overall I'm happy with what I
read, most importantly that people brought up the same concerns I share.
I'm +1 on the first part of the statement that was already ratified in
comment:34 and I definitely want opt-in.
I don't care much how 'explicit' the graphical presentation of the opt-
in is, this is up to the
UI designers. Including non-free apps may be suggested (e.g. ''"some
results were excluded from
your search. Click here to show them"'') but not recommended. A simple
confirmation of a default > is not enough, I want the user to actively do it. And we need a "More Info" link that explains
the background, e.g. why we believe in FLOSS.
I can't help but feel that most of this discussion is done thinking of generic searches. I mean this kind of hiding can sorta work if people search for a term like 'games', but if a user searches for 'Steam' then hiding the search results like this comes of as annoying and stupid.
What I want most of all is that FLOSS is preferred over non-free
software. Searching for Chrome
should return "Chromium" before "Chrome" if possible.
Again I wonder if this is one of those things that works as a specific example, but quickly falls down in the general case. As mentioned just above, if we are talking a general search term like 'web browser' than sorting free first seems not unreasonable. And to some degree if people search for Chrome then prioritizing Chromium could maybe be justified although I am already feeling we are close to being annoying with such a move. And it also feels very Chrome specific, as the number of 'non-free' applications with a open source twin is a very small club. And of course returning for instance Web or Firefox on a 'Chrome' search is without a doubt crossing the line from trying to gently push people in the right direction to just being obnoxious.
This being said I'm happy with
"The Council recognizes that allowing selected third-party non-free
software to be installed is a valid experiment in advancing Fedora's mission. Non-free software may not be presented to the user without explicit user enablement in any Fedora Edition or Spin."
but I think we need one more sentence for the issues mattdm raised in
comment:35.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
Replying to [comment:39 uraeus]:
And to some degree if people search for Chrome then prioritizing
Chromium could maybe be justified although I am already feeling we are close to being annoying with such a move. And it also feels very Chrome specific, as the number of 'non-free' applications with a open source twin is a very small club. And of course returning for instance Web or Firefox on a 'Chrome' search is without a doubt crossing the line from trying to gently push people in the right direction to just being obnoxious.
I think reasonable people can disagree on where exactly that line is. A gentle push that no one notices is... too gentle. Personally, I'm willing for us to err on the "obnoxious" side if that best advances the mission of promoting free/open source software. Of course, ideally, we have a solution that's both non-obnoxious *and* pro-free-software. In the real world, there's a balance somewhere; in finding that balance, communicating the preference for free software should be a primary objective, not something done only if it can be done without annoying anyone.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by uraeus):
I understand, but a tool meant to help you search for stuff need to help you do that to remain useful. If you everytime you searched for China in Google only got results relating to Taiwan or got results about Canada when searching for USA, with a little notice at the bottom saying 'click here to view less ethical search results' you would probably stop using Google at some point.
Which is why I been advocating the labelling as a better approach than trying to distort search results. As it lets us communicate our views without giving people random search results. So to follow up on my example above instead of returning Canada when people search for the USA, we instead return USA but put up labels like 'No universal healthcare' and 'Practices death penalty'. Which is still making a clear political statement, yet returning information about the thing people actually searched for.
Replying to [comment:40 mattdm]:
Replying to [comment:39 uraeus]:
And to some degree if people search for Chrome then prioritizing
Chromium could maybe be justified although I am already feeling we are close to being annoying with such a move. And it also feels very Chrome specific, as the number of 'non-free' applications with a open source twin is a very small club. And of course returning for instance Web or Firefox on a 'Chrome' search is without a doubt crossing the line from trying to gently push people in the right direction to just being obnoxious.
I think reasonable people can disagree on where exactly that line is. A
gentle push that no one notices is... too gentle. Personally, I'm willing for us to err on the "obnoxious" side if that best advances the mission of promoting free/open source software. Of course, ideally, we have a solution that's both non-obnoxious *and* pro-free-software. In the real world, there's a balance somewhere; in finding that balance, communicating the preference for free software should be a primary objective, not something done only if it can be done without annoying anyone.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+--------------------- Reporter: pfrields | Owner: Status: new | Priority: normal Component: General | Resolution: Keywords: workstation | -------------------------+---------------------
Comment (by mattdm):
Okay, to recap. The first part is fully approved; see comment #34. For the second part, we are not at a complete final statement, but are okay with the general concept, given a strong focus on our overall mission. We don't want to get too deeply into specifics, or on the other hand do too much of "we'll know it when we see it!" I'm going to work with Allan to come up with a design spec and some prototypes, and we'll come back with something I hope everyone is happy to agree on.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+----------------------- Reporter: pfrields | Owner: Status: closed | Priority: normal Component: General | Resolution: approved Keywords: workstation | -------------------------+----------------------- Changes (by mattdm):
* status: new => closed * resolution: => approved
Comment:
With that, I'm going to mark this APPROVED. Let's open a further ticket for future discussion when appropriate.
In our meeting today, Josh volunteered to take this to FESCo to ask FESCo to update their policies accordingly.
#57: Seeking Council feedback/input on draft third party software policy -------------------------+----------------------- Reporter: pfrields | Owner: Status: closed | Priority: normal Component: General | Resolution: approved Keywords: workstation | -------------------------+-----------------------
Comment (by jwboyer):
Replying to [comment:43 mattdm]:
With that, I'm going to mark this APPROVED. Let's open a further ticket
for future discussion when appropriate.
In our meeting today, Josh volunteered to take this to FESCo to ask
FESCo to update their policies accordingly.
FYI https://fedorahosted.org/fesco/ticket/1617
council-discuss@lists.fedoraproject.org
-
fedora-badges -
Robert Mayr