#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. -- Ticket URL: <https://fedorahosted.org/council/ticket/57#comment:3> 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 http://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.
