#1201 Enabling third party repositories
Closed None Opened 10 years ago by jwboyer.

= phenomenon =

The Workstation WG is currently discussing enabling third party repositories. The single email that sums this up best can be found here (please read all of the quoted text as well):

https://lists.fedoraproject.org/pipermail/devel/2013-November/191583.html

The term "enable" here seems to map to "discoverable" but not necessarily enabled by default. However, one could imagine also shipping repo files for other things by default, such as Chromium.

So there are two main questions:

1) Can products ship .repo files that point to third party repositories, and if so with what restrictions.

2) Can products make third party repositories discoverable via search terms in some fashion and easily enabled without actually shipping the .repo files.

(Christian, if I have misinterpreted your intentions here, please clarify).

It's worth noting that question 2 might either negate the need for question 1, or require it depending on the implementation.


FWIW, current policy is (from Packaging:Guidelines):

Configuration of Package Managers

Configuration for package managers in Fedora MUST ONLY reference the official Fedora repositories in their default enabled and disabled state (see the yum repo configuration in the fedora-release package for the canonical list). Unofficial and third-party repositories that contain only packages that it is legal for us to direct people to in Fedora (see the Forbidden items and Licensing:Main pages for an explanation of what is legal) may be shipped in %{_docdir}. The idea is that the system administrator would need to explicitly copy the configuration file from doc into the proper location on the filesystem if they want to enable the repository.

ah -- no wonder I couldn't find that as a fesco policy... :-/.

I'd be generally against overriding FPC but I think a case could be made to move this to fesco policy instead of Packaging Guidelines (It can be seen as a what to package question). I'll bring that up at Thursday's FPC meeting.

Here's the previous fesco ticket: https://fedorahosted.org/fesco/ticket/671

That lead to the FPC approving the packaging guideline: https://fedorahosted.org/fpc/ticket/106

Digging even further back at tibbs' request, here's one of the original reports of this happening (as discussed in the original fesco ticket as previous FPC/FESCo discussions): https://www.redhat.com/archives/fedora-packaging/2006-October/msg00132.html

During the FPC meeting, the question of what is legally acceptable came up. Adding Spot to CC for a viewpoint on what is allowable in 3rd party repos that would be enabled.

Things that are considered legally acceptable (in this context):

  • Items without clauses in their licenses which forbid the use cases we are are discussing here (usually "no download from third party sites" clauses, although, each new license would need to be reviewed here).
  • Items without patent concerns
  • Items without US law concerns (e.g. the DMCA)

I would strongly prefer that there be no proprietary software in these 3rd party linked repos, because it would require extensive vetting of those items for legal compliance.

I welcome more repositories easily accessible. I can imagine more than one WG will need it. Not every WG decision should go through FPC or FESCo.
On the other hand formal approval of every new repository should be done by FESCo, such repositories should obey rules, which spot mentioned.

Replying to [comment:8 mmaslano]:

I welcome more repositories easily accessible. I can imagine more than one WG will need it. Not every WG decision should go through FPC or FESCo.
On the other hand formal approval of every new repository should be done by FESCo, such repositories should obey rules, which spot mentioned.

I would not say should obey but must obey. Otherwise I agree. Of course these packages or even products that ship additional repositories should be clearly declaring that.

FPC discussed the Guideline and arrived at this opinion for FESCo:

If FESCo would like to allow pointing to repos that don't have Official Fedora Content they can let us know and have someone propose a guideline draft that we can critique and vote on. However, after talking with Fedora Legal, the requirements for us to be able to point to repositories outside of our control may be so costly that in practice there's very few repositories that we can actually point to. Given the costs to benefits, FPC also recommends that third party repos not be enabled.

Background information/Notes from the meeting:
The vote to approve the opinion was (+1:5, 0:1, -1:0) with 3 members who did not case votes.
Most but not all FPC members agreed that the basic allow or disallow could be decided at FESCo level and then FPC could decide on the how to package in accordance with that decision.
The votes against the proposed message to send to FESCo fell on the side of not wanting to see third party repos enabled.
Fedora Legal (spot) spelled out the requirements for pointing to repositories that we don't control and they are pretty heavy.
* Ongoing vetting of packages inside of the third-party repositories to make sure they do not contain legally problematic packages.
* copr/repos.fedorapeople.org can be considered third-party for the purposes of Fedora Legal's responsibilities.
* These responsibilities also apply to repos listed in %docdir under the current policy but Fedora Legal knows of no repos listed in %docdir and so hasn't had to do any ongoing vetting.
* (I had not realized this... I'm thinking about suggesting we do not allow shipping repos in %docdir because they require ongoing vetting if fesco chooses not to ask us to allow enabling third party repositories)
FPC felt that deciding which repos would be allowed was best done in FPC with collaboration by Fedora Legal
* From the above conversation with Fedora Legal we anticipate that Fedora Legal would disallow a large number of the repositories people might want to point to.
FPC Members were split on the benefits of this but all agreed that there was high cost.
* Benefits seen -- some people don't want to get their packages into Fedora but end users may want to use those packages. So might as well make it easy to find. Counterpoint: If we can point to it from Fedora then we might as well get it into Fedora even if that means a new fedora yum repo or more special cases for specific software.
* Costs: Fedora Legal has to spend much more time vetting the packages in third party repos that we're pointing to on an ongoing basis.

Note: One more -1 FPC vote on the opinion to send to FESCo was officially registered in ticket. As noted in the meeting notes section of comment:10, the voter voted in the negative to express his opposition to enabling third party repositories.

  • AGREED: Defer to the next FESCo meeting and ask further questions in the ticket for clarification. (sgallagh, 19:58:43)

One such question: can we have clarification on "copr/repos.fedorapeople.org can be considered third-party for the purposes of Fedora Legal's responsibilities." Specifically, does this mean: On a pristine installed system, I cannot do
{{{
yum install package-providing-repo-for-a-copr
}}}

Or does it also mean that COPR cannot provide an RPM for a particular repo. For example, if I create a 'myproject-nightly' repo, would it be acceptable for me to build and ship a 'myproject-nightly-repo' RPM that put a .repo file in {{{/etc/yum.repos.d}}} (similar to the way Google provides a Fedora repo for Chrome packages). If this is permissible, is it also permissible for that repo to be enabled by default, or must it be shipped with {{{enabled = 0}}}?

Who are you asking for clarification on the Coprs thing? The FPC, legal, or?

@spot would you be able to attend next week's fesco meeting (or the one after if you're on holiday for the next one)? I think the questions in comment:14 and others unresolved at the meeting were Fedora Legal questions.

I see no legal issue with a copr including a "repo" rpm that enables that copr on a user's system, assuming, of course, that the copr is in compliance with the legal rules binding coprs.

@spot: At today's meeting fesco also wondered about the other half of sgallagh's question:

Can we have clarification on "copr/repos.fedorapeople.org can be considered third-party for the purposes of Fedora Legal's responsibilities." Specifically, does this mean: On a pristine installed system, I cannot do

yum install package-providing-repo-for-a-copr

So:
Would it be legally okay for copr "repo" rpms to be in the main Fedora repository?
If so, what's the additional cost to Fedora Legal to do that considering that people are only supposed to be including things that follow the [https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses Fedora Good Licenses Guideline]?
* (And because there was confusion about what comment:17 was referring to) If the answer to the first is "no", can the Copr repo RPMs we ship from within Copr itself set 'enabled=1'? (I think everyone thinks this is "yes" but wanted to be certain.)

I'll try to answer this two ways, to make clear the separation of "church (legal)" and "state (spot)":

== Spot's Personal Opinion ==

If you can do "yum install package-providing-repo-for-a-copr" to enable a copr repo, that repo is not third-party. Permitting this is effectively circumventing the packaging guidelines (since it is not required that packages in coprs be reviewed or even compliant on good faith). Note that this scenario is different from a copr providing "package-providing-repo-for-a-copr.rpm" and pointing yum at that repo-enablement package in that copr. It is my opinion that the former is improper, while the latter is the intended model.

I also think that an application (or support in an existing gnome-software / PackageKit) which allowed a user to search coprs and opt-in to enabling them would be fine, as would be a model where copr search results were automatically shown to the end-user as long as they opted in to enabling the copr before installing them (e.g. "This package is part of the FOOBAR copr. Coprs are third-party repositories generated by Fedora contributors to add extra packages which are not yet officially part of Fedora. Enabling this repository may result in dependency or quality issues, as these packages are not reviewed or tested. It may feed your baby to dingos. Click here to enable it.")

== Legal Opinion ==

Since everything in coprs must be under a Fedora Good License (and otherwise legally permissible, coprs are not a loophole for circumventing US Law), there is no legal restriction preventing the inclusion of copr "repo" rpms in the main Fedora repository.

There is no additional cost to Fedora Legal for copr "repo" rpm inclusion in the main Fedora repository, since all coprs will have to clear legal anyways. When I say "clear legal", I do not mean that they all must be checked before going live, but rather, that any coprs which do not meet the legal requirements are subject to removal (and the FAS account of the user may be subject to suspension, depending on the specifics of the situation). I expect the cost of this will be notable, but independent of the inclusion of "repo" rpms in the main Fedora repository.

The answer to the first question is not "no" (at least, not in the legal context), however, for completeness sake, there is no legal issue with copr "repo" rpms shipped from within the copr to set "enabled=1", since there is no concern of contributory infringement with compliant packages.

Also, just to avoid it coming up later, from a liability perspective, Red Hat is the builder and distributor of packages in coprs, and thus, bears the liability. This means that Red Hat does not consider copr packages to be "third party" from a liability/responsibility perspective, not like a true independent repository would be.

  • 1201 Enabling third party repositories (sgallagh, 18:09:28)

  • at this time, issues around linking directly to copr repos include
    signing/key management, and mirrored distribution" (mattdm,
    18:34:46)
  • AGREED: At this time, copr-enablement packages cannot be shipped in
    the main repo. (sgallagh, 18:47:28)

Discussion on how to address the above issues will be taken to the infrastructure mailing list and discussed with rel-eng and COPRs devs.

Can someone please summarize the decisions made around 3rd party repositories, and perhaps document them on the FESCo policy wiki pages? Note: I'm asking in a general sense, not just about COPRs.

no further decisions have been made besides what you see on this ticket. I believe that policy for coprs will be less strict than for random third party repositories. so it is highly unlikely that we'd allow shipping third party repo files in the fedora main repositories.

at the meeting I brought up the case of a tool that searches for packages in non-fedora main repositories such as spot mentioned in c:19. sgallagh said msuchy and rhughes were looking at this so we should defer that until they have something to say about that. from spot's description this would have to be a non transparent step (user has to agree to use another repo to get this software). spot's comments about fedora legal costs address coprs but not general third party repositories so we'd also need more input on that.

@spot what's the costs to fedora legal to have a search tool such as you outline in c:19 that searches third party repos that are okay under c:7 in addition to coprs?

would those repos need to be preapproved or would they be able to "clear legal" in the same way as coprs?

There are 22 previous comments here. I asked for a summary because reading them does not lead me to any clear conclusions about the two questions I originally asked. Here's what I've gathered:

A) Coprs is awesome because Fedora (Red Hat) built it (and assumes liability) and people can include packages in their copr that provide .repo files, but those repo-packages can't be in the main Fedora repos because FESCo said so.

B) Coprs can be searched for packages by applications without the .repo files installed for the same reasons that Coprs is awesome and was invented here.

So lots about Coprs, nothing about the general case I asked about in the original ticket description.

I'm going to infer that for the general case of 3rd party repos, the answer to my question 1) is no because of the liability thing and answer A above for Coprs. If, however, some form of vetting was done by legal on a specific 3rd party repo, that might be mitigated and therefore possible. Is that correct?

I cannot infer anything about what the answer to my question 2) is. For a 3rd party repo to be searchable, an application would need to look at the metadata provided. If a package a user is searching for is found there, and a sufficient warning it's from a 3rd party repo, can that application then install that package?

Sorry I wasn't more clear.

Your (A) is correct. FESCo did not specifically decide whether the same would apply to non-copr third party repos but since we have even less control over those repos than we do over coprs I am doubtful that we would allow it.

(B) is incorrect in that FESCo has not yet voted on that. This means that whether repos other than the Fedora main repos can be searched by a tool for applications is not yet decided. This is the question that sgallagh said we should defer a vote on since he wanted feedback from msuchy and rhughes. Being able to apply this to general third party repos as well as copr repos is why I asked my followup questions of spot in comment:22

A true third party repository (not coprs), maintained and controlled by an independent party would be more complicated to include by default, since we would have to be sure that there are no legally troublesome items in that repository. With coprs, if something is found, I could have it removed (or ideally, remove it myself). With a third-party source, I'd have no such control.

In many cases, it may not be obvious whether a third-party distributing an item is permissible for us to point to. We're trying to avoid "contributory infringement" here. To use a known example:

Google Chrome contains a fork of ffmpeg. Let's assume for the sake of argument that Google has paid for a patent license for a media codec included in ffmpeg. That license does not apply to anyone besides Google.

Two scenarios:

A) Google does not distribute Chrome in an RPM for Fedora, so a third-party packages it up and makes a repo.
B) Google distributes Chrome in an RPM for Fedora in a repo they maintain.

Scenario A is something that we could not point to.
Scenario B is something that we could (probably) point to.

When I say "could not point to", I mean that we cannot search it by default, or even with a "warning, this is not us". If a user enables a third-party repo, well, that's their doing. We didn't point them to it and bear minimal liability.

I'd have to review every third-party repo (and rereview them regularly) to ensure they didn't contain or add legally troublesome items. We're more flexible with Fedora because our community is operating within our Legal guidelines (and in good faith compliance). We cannot assume this from third parties.

HTH

So in your scenario B (Google creates a Fedora repository for Chrome), would the process to get that discoverable/installable by default to contact you to review and approve it?

There is an interesting example of this already today, with the Adobe flash plugin repo. That seems to fall into scenario B, correct?

From a purely "is this legally permissible", yes, that would fall into scenario B.

Contacting Fedora Legal to review/approve third-party repos would be the way to do this if we opted to go down that bumpy terrible road.

OK, so a summary as I understand things:

1) COPRs can provide RPMS with .repo files in them because Red Hat is the provider and assumes liability, but those cannot be included in the main Fedora repos per FESCo decree.

2) General 3rd party repositories cannot be searched or enabled due to liability concerns.

3) Repositories created by the owner of various packages/content containing only that content are possibly permissible, pending review of Fedora legal. (E.g. Google creating a Chrome repo, or the Adobe flash plugin repo).

The questions that remain are:

Y) Can COPRs be searched for packages without the .repo files being installed. Pending FESCo.

Z) Is there some FESCo jurisdiction required for item 3 above, or does that all fall directly to Fedora Legal and the entity requesting review? (E.g. if Legal approves flash-plugin based on a request from Workstation, Workstation can then include that/make it discoverable)

Does this seem like an accurate summary to everyone?

Re Z) You probably want FESCo/Board to decide whether we want to search/point to non-free legally permissible third-party repos as a manner of policy.

1, 2, 3, and Y seem accurate to me. Z seems accurate but incomplete. I think there's three questions:

  1. (spot) Does FESCo/Board want us to be able to point to non-free, legally permisible repos?
  2. (toshio) Do we want to further limit what repos are permissible over and above what's legal?
  3. (jwb) Who decides what's permissible under #2?

I add the middle question because I think that even if we decide that FESCo doesn't need to review each new repository, we might still want to give Fedora Legal the power to say no to a repository for non-legal reasons. "Legal's experience is that the repository owner is uncooperative when problems do arise", "The software in that repository is decried by the FSF, EFF, and the New York Times for sending details of the user's web browsing to the author's company", or even "Legal doesn't have enough time to take on ongoing review of more repositories at this time".

From the meeting today:

  • Copr repos may be searched for applications to install as long as the user is explicitly asked to enable the copr before installing packages from them (See https://fedorahosted.org/fesco/ticket/1201#comment:19 for details) (+6,-0,0)

  • FESCo is okay with pointing to free software repositories in the same way as COPR repos if they are approved by FESCo and Fedora Legal. They are not limited in the criteria that they can choose to apply. (+7,-0,1)

  • For non-free sofware repositories, FESCo is not changing exisiting policy. If you think the policy should change, talk to the board. (+9,-0,0)

Just for completeness, this should be documented on the FESCo policy pages in the wiki somewhere. Here's a summary to start with:

1) COPRs can provide RPMS with .repo files in them because Red Hat is the provider and assumes liability, but those cannot be included in the main Fedora repos per FESCo decree.

2) COPR repos may be searched for applications to install as long as the user is explicitly asked to enable the copr before installing packages from them.

3) General 3rd party repositories cannot be searched or enabled due to liability concerns.

(NOTE: "searched" in 2 and 3 was intended to cover searching by software. Clearly users can manually search for anything.)

4) FESCo is okay with pointing to specific free software repositories in the same way as COPR repos if they are approved by FESCo and Fedora Legal. They are not limited in the criteria that they can choose to apply.

5) For non-free sofware repositories, FESCo is not changing exisiting policy. Non-free software repositories are not allowed. Permission to make these discoverable via searching software would require a change in policy from the Fedora Board.

https://lists.fedoraproject.org/pipermail/desktop/2013-December/008531.html is the email I sent to the desktop list, as the Workstation WG generated this ticket.

Policy writeup:

https://fedoraproject.org/wiki/Third_Party_Repository_Policy

@everyone: Feel free to point out anything if you think it's not what we decided on at the meeting or specific wording changes if you think you can make something more clear.

Replying to [comment:34 toshio]:

@everyone: Feel free to point out anything if you think it's not what we decided on at the meeting or specific wording changes if you think you can make something more clear.

The policy may need to be clarified to clearly address the case of gnome-software providing downstream metadata for individual nonfree packages in repositories that are not enabled: https://bugzilla.redhat.com/show_bug.cgi?id=1145827

Login to comment on this ticket.

Metadata