#198 Let's clarify the trademark guidelines on modified hosted (cloud, vps, etc) Fedora OS images
Opened 2 years ago by mattdm. Modified 8 months ago

We get many reports of hosting/cloud providers who provide some version of Fedora software but have made various config changes. When they do something like replace the kernel, that's very clearly "modified Fedora software", but there's a lot of gray area otherwise. Is putting network configuration into place "modified"? What about user configuration? What about disabling SELinux?

The trademark guidelines contain some wording on "virtual images or appliance distributions", but this doesn't really quite cover what we need.

I talked to legal, and the consensus is that we should describe where we think the line should be, and then they can help update the guidelines to better reflect that.


Here is a straw man

  1. A clearly linked (footnote is fine) description of the configurations and changes made to the stock image. This doesn't have to be a diff but should be a description that a reasonably technical person can read and understand. i.e. "we enabled cloud-init" is fine, imho. This list must include software added to the base install.

  2. Anything that reduces the security settings (i.e. disabling SE linux, opening more ports by default, disabling a firewall) must be disclosed more visibly. Disclosure must also be made about access options for anyone other than the image consumer, i.e. SSH keys from a provider being auto-loaded.

  3. Any auto-starting programs must be disclosed.

In 1 "software added to the base install" means Fedora software added, not third-party, right? I'm still pretty solid on asking people to use the Remix branding if they add non-Fedora bits.

In 1 "software added to the base install" means Fedora software added, not third-party, right? I'm still pretty solid on asking people to use the Remix branding if they add non-Fedora bits.

Agreed 100%

Here is a straw man

A clearly linked (footnote is fine) description of the configurations and changes made to the stock image. This doesn't have to be a diff but should be a description that a reasonably technical person can read and understand. i.e. "we enabled cloud-init" is fine, imho. This list must include software added to the base install.

I agree with this, with the caveat Matt pointed out already.

Anything that reduces the security settings (i.e. disabling SE linux, opening more ports by default, disabling a firewall) must be disclosed more visibly. Disclosure must also be made about access options for anyone other than the image consumer, i.e. SSH keys from a provider being auto-loaded.

That's kind of onerous. Can you tell me, for example, what the default security settings are for Fedora in general? Outside of "SELinux is enabled", I cannot. It also depends on the installed package set and even Edition, given that I think sshd is disabled by default in Workstation but enabled in Server.

Any auto-starting programs must be disclosed.

Why? This one is easier to track given Fedora does have an explicit list for presets, but I think even that differs per Edition slightly.

In 1 "software added to the base install" means Fedora software added, not third-party, right? I'm still pretty solid on asking people to use the Remix branding if they add non-Fedora bits.

This is my intention. I saw this policy as additive so I didn't restate things already in policy.

I believe we should actually consider making them say what image they based their build on and then only speak about variances from that image.

Here is a straw man
A clearly linked (footnote is fine) description of the configurations and changes made to the stock image. This doesn't have to be a diff but should be a description that a reasonably technical person can read and understand. i.e. "we enabled cloud-init" is fine, imho. This list must include software added to the base install.

I agree with this, with the caveat Matt pointed out already.

Anything that reduces the security settings (i.e. disabling SE linux, opening more ports by default, disabling a firewall) must be disclosed more visibly. Disclosure must also be made about access options for anyone other than the image consumer, i.e. SSH keys from a provider being auto-loaded.

That's kind of onerous. Can you tell me, for example, what the default security settings are for Fedora in general? Outside of "SELinux is enabled", I cannot. It also depends on the installed package set and even Edition, given that I think sshd is disabled by default in Workstation but enabled in Server.

I believe this should be done in the form of "We started with image X and made these changes" This way we don't have to say what the default is, they should instead state what they changed.

Any auto-starting programs must be disclosed.

Why? This one is easier to track given Fedora does have an explicit list for presets, but I think even that differs per Edition slightly.

Again, I believe we should request documentation on any deviation from an image we produce and distribute.

Anything that reduces the security settings (i.e. disabling SE linux, opening more ports by default, disabling a firewall) must be disclosed more visibly. Disclosure must also be made about access options for anyone other than the image consumer, i.e. SSH keys from a provider being auto-loaded.
That's kind of onerous. Can you tell me, for example, what the default security settings are for Fedora in general? Outside of "SELinux is enabled", I cannot. It also depends on the installed package set and even Edition, given that I think sshd is disabled by default in Workstation but enabled in Server.

I believe this should be done in the form of "We started with image X and made these changes" This way we don't have to say what the default is, they should instead state what they changed.

That's fine. I didn't want people to be required to do a full security audit if they only know "I included packages X, Y, and Z". That's typically the level of change most do, and they aren't likely to be experts in what security implications X,Y, and Z bring.

Any auto-starting programs must be disclosed.
Why? This one is easier to track given Fedora does have an explicit list for presets, but I think even that differs per Edition slightly.

Again, I believe we should request documentation on any deviation from an image we produce and distribute.

I kind of disagree, mostly because we have Spins. Spins don't start from an existing image. They're a net new image. We don't require them to provide a list of changes from one of the Edition images. It is, for the most part, fairly easy for someone to show up and maintain a Spin. I would be willing to bet that the Spins don't get any sort of review for the above in a consistent manner.

Also, it is very easy to install Fedora from an into a VM image with a custom package set then distribute that as a gold master for various usecases. There's nothing to compare that too either.

I understand what you're asking for, but I think it's impractical given that flexibility Fedora has for installation types.

Spins do get different labeling, though — at least, initially. I'm not so sure that we should have reserved the VARIANT in /etc/os-release for editions, but that was the call so that's the current state. Everything not an edition is just generic "Fedora". But anyway, people who are using a spin should know it.

I think we should have stricter rules for using the edition branding, and more relaxed ones for just the Fedora brand. I wonder how specific we need to be. Can we say "clearly state major configuration changes", or "clearly state major configuration changes (for example, disabling SELinux)"?

Here is a straw man

A clearly linked (footnote is fine) description of the configurations and changes made to the stock image. This doesn't have to be a diff but should be a description that a reasonably technical person can read and understand. i.e. "we enabled cloud-init" is fine, imho. This list must include software added to the base install.

I am torn quite a bit here. I strongly feel that we should make sure that all the software is open and ideally in Fedora. However if a cloud provider has some custom code they need to inject in order to provide a seamless great user experience do we really want to then make them say you can not call it Fedora? an example I can think of is google. google has a bunch of binaries, which includes some services so that users can be injected while the machine continues to run. some of it works with cloud-init but is much less seamless. would we want to have our brand continue to be absent? I would like thatany software they add is packaged as rpms and available via a repo so that updates can be pushed. I would also like to have the vendors clearly disclose that they add software, what it is and that they are responsible for supporting it. I think a big issue that we face is that we have made perpetrated a feeling or belief that we are difficult to work with because of our super strict adherence to how people need to do things. We need to let people know we are open for working with and on and that the process of doing so is for the benefit of everyone.

Anything that reduces the security settings (i.e. disabling SE linux, opening more ports by default, disabling a firewall) must be disclosed more visibly. Disclosure must also be made about access options for anyone other than the image consumer, i.e. SSH keys from a provider being auto-loaded.

We disable the firewall in our own cloud images and do not disclose that. workstation has a watered down set of firewall rules https://src.fedoraproject.org/cgit/rpms/firewalld.git/tree/FedoraWorkstation.xml disabling selinux I think is important, also making it clear that they provide external firewalling etc

Any auto-starting programs must be disclosed.

We do not disclose all services running in any of teh editions or spins today. I would not block on this.

Spins do get different labeling, though — at least, initially. I'm not so sure that we should have reserved the VARIANT in /etc/os-release for editions, but that was the call so that's the current state. Everything not an edition is just generic "Fedora". But anyway, people who are using a spin should know it.
I think we should have stricter rules for using the edition branding, and more relaxed ones for just the Fedora brand. I wonder how specific we need to be. Can we say "clearly state major configuration changes", or "clearly state major configuration changes (for example, disabling SELinux)"?

outside of the filename of the image/iso of a spin there is no distinct branding of the spin. there is nothing in the installed spin that definitively says this was installed from Xfce, LXDE, etc the cloud edition differences have been removed in Fedora 28, so it is no longer uniquely identified either.

Here is a straw man
A clearly linked (footnote is fine) description of the configurations and changes made to the stock image. This doesn't have to be a diff but should be a description that a reasonably technical person can read and understand. i.e. "we enabled cloud-init" is fine, imho. This list must include software added to the base install.

I am torn quite a bit here. I strongly feel that we should make sure that all the software is open and ideally in Fedora. However if a cloud provider has some custom code they need to inject in order to provide a seamless great user experience do we really want to then make them say you can not call it Fedora? an example I can think of is google. google has a bunch of binaries, which includes some services so that users can be injected while the machine continues to run. some of it works with cloud-init but is much less seamless. would we want to have our brand continue to be absent? I would like thatany software they add is packaged as rpms and available via a repo so that updates can be pushed. I would also like to have the vendors clearly disclose that they add software, what it is and that they are responsible for supporting it. I think a big issue that we face is that we have made perpetrated a feeling or belief that we are difficult to work with because of our super strict adherence to how people need to do things. We need to let people know we are open for working with and on and that the process of doing so is for the benefit of everyone.

I understand your point, and perhaps we need a label for this. I think plain "Fedora" isn't it, though.

Anything that reduces the security settings (i.e. disabling SE linux, opening more ports by default, disabling a firewall) must be disclosed more visibly. Disclosure must also be made about access options for anyone other than the image consumer, i.e. SSH keys from a provider being auto-loaded.

We disable the firewall in our own cloud images and do not disclose that. workstation has a watered down set of firewall rules https://src.fedoraproject.org/cgit/rpms/firewalld.git/tree/FedoraWorkstation.xml disabling selinux I think is important, also making it clear that they provide external firewalling etc

But ours is the template that they need to show variance from. We should discuss these issues in our docs, but this isn't a reason to not ask someone to disclose their variations.

Any auto-starting programs must be disclosed.

We do not disclose all services running in any of teh editions or spins today. I would not block on this.

see above.

Metadata Update from @mattdm:
- Issue assigned to ausil
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: policies

2 years ago

@ausil Have you had a chance to look at this at all?

Is there any futher comments or feedback on my proposal?

I will read and review. Sorry for missing your update!

I just left some comments. I think it's good generally, but there are some ambiguities and conflicts to resolve.

Metadata Update from @bcotton:
- Issue priority set to: Next Meeting (was: Waiting on Assignee)

a year ago

We agreed in the last meeting that we're going to put this to a full consensus vote. We will vote in tomorrow's meeting. If you cannot attend tomorrow's meeting, please leave your vote here.

It would be nice to have all comments and suggestions resolved so we are sure of what we are voting on

In today's meeting we agreed that we would reopen comments through Friday of this week, at which point we would do a full consensus vote.

Okay, we're at the deadline. Several more comments have been raised. @ausil, will you please update your draft to reflect those comments so we can begin voting?

Metadata Update from @bcotton:
- Issue priority set to: Waiting on Assignee (was: Next Meeting)

a year ago

@bex to take the draft to legal

Metadata Update from @bex:
- Issue unmarked as blocking: #181
- Issue assigned to bex (was: ausil)
- Issue priority set to: Waiting on External (was: Waiting on Assignee)

a year ago

@bex is this in legal's hands?

sort of - I need to go poke this

Login to comment on this ticket.

Metadata