#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