#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_and_SPDX) 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." -- Ticket URL: <https://fedorahosted.org/council/ticket/57#comment:28> council <https://fedorahosted.org/council> Fedora Council Public Tickets _______________________________________________ council-discuss mailing list council-discuss@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct https://lists.fedoraproject.org/admin/lists/council-discuss@xxxxxxxxxxxxxxxxxxxxxxx The Fedora Project's mission is to lead the advancement of free and open source software and content as a collaborative community.
