Clarify trademark guidelines within an organization

Project Discussion
1

Moving this from Making sure you're not a bot!

My read of the he current remix and trademark guidelines is that they have a (reasonable) assumption that one is “publishing” the content in some form (implicitly, for the Internet in general).

My take here is that we should have a similar stance as the GPLv2’s requirements for publishing source code, which hinges on the definition of “distribution”. The FSF GPLv2 FAQ says: Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation

Is making and using multiple copies within one organization or company “distribution”?(#InternalDistribution)
No, in that case the organization is just making the copies for itself. As a consequence, a company or other organization can develop a modified version and install that version through its own facilities, without giving the staff permission to release that modified version to outsiders.
However, when the organization transfers copies to other organizations or individuals, that is distribution. In particular, providing copies to contractors for use off-site is distribution.

My take is that bootc makes publishing modified operating systems much easier, but: would we really require someone who is e.g. taking a classic virtual machine image (qcow2, AMI etc) and injecting their own content (that would violate the trademark guidelines) and only publishing that qcow2/AMI within their organization to drop the Fedora trademarks? I am doubting that’s the case. I think it should only be when “distributing” or “publishing” and we make clear that that happens only when crossing “organization” boundaries.

What I think gets nuanced fast is when people publish derived images that are publicly accessible, but not actually intended for use outside of that “organization”; think e.g. CI image caches, we have some of those in bootc-dev GitHub upstream. There is zero marketing or information for these outside of the CI system.

I guess Making sure you're not a bot! is closest to this topic, but I think was intended for a different case (“slightly tweaked cloud image”), whereas the cases we’re talking about here absolutely do not meet

no non-Fedora Materials are pre-installed in the virtual image or appliance files in which the Fedora operating system is pre-loaded

I think this deserves a clear statement in the guidelines.

2

As I understand these things what you do personally or inside a company is not subject to the licensing or trademark rules.

But as soon as I provide a binary to a customer then I have to follow the trademark and licensing rules.

3

If it published publicly, yes, we do, and we should continue to do so. That is effectively redistribution, since anyone can get it. If it is internal and not redistributed to anyone, then no, we have never required this.

“Intent” doesn’t matter here, if you are using public infrastructure and it is publicly consumable, then it needs the branding to be swapped. If someone can pull them and consume them to produce artifacts or systems, then it can be a problem.

4

I opened that ticket because the prominent Remixes I’m aware of are not observing the requirements described in Making sure you're not a bot!

Those Remixes are not private to any organization, so the framing of this thread focuses on a different context than the ticket I opened earlier.

5

In the paragraph you are replying to I specifically said “and only publishing that qcow2/AMI within their organization”.

What does “using public infrastructure” mean here?

“publicly consumable” seems to be the important operative thing here - and I think we should pick one term. Looking into this a bit more closely, it seems the GPLv2’s usage of “distribute” is actually in law really meaning “publication”, which is defined here Definition: Publication from 17 USC § 101 | LII / Legal Information Institute

Which is pretty bare…but I guess “to the public” has a pretty obvious definition for the most part.

I think at a technical level, that would be a very consistent stance. My intuition is that there’s a rather huge set of things which would be non-compliant however. In practice, I don’t think anyone here will really care to spend the time or energy to hunt down every CI system which does this right?

On the other hand, IANAL but my understanding specifically with trademarks is one really has to try to defend them.

So…would it work for us to include a disclaimer that these cases are technically non-compliant, but unless the derived content is publicized (especially via documentation, blog posts, etc) we may not actively enforce?

6

Also not a lawyer, not legal advice, but it is my understanding that saying that we will not (or may not) actively enforce our mark limits our capacity to protect ourselves in weird related cases.

If a large company took Fedora images, modified them to include bloated spyware, then distributed the images still branded as Fedora across 100,000 employees, it would be plausible for that behavior to negatively impact their perception of the Fedora brand, since they would not know that what they were using was not “Fedora”.

Now, it would have to be egregious for us to even know this is occurring, because there is no public distribution, and even more egregious for us to take legal action, but there’s at least a valid scenario where we’d want that option.

7

This isn’t theoretical at all; a lot of the endpoint HIDS style systems AFAIK end up gathering a lot of data, and probably most companies would tell you not to do anything on work devices you wouldn’t want at least admins at the company to know. Of course there’s a whole other next level to this.

While this does perhaps make the case that we could include in our trademark guidelines something to this effect, my instinct says here that it’d be quite challenging to try to create some kind of clear technical line between “company sends journal/audit logs to remote server” and more intrusive things. If we did, it should be a separate thread from this one at least.

8

My very blunt and straightforward opinion here is that if a (and I’m going to concretely mention it) a bootable container is built from Fedora packages and includes things that are not shipped in Fedora and available to the public then they fall under a remix and must follow remix guidelines; that means using the appropriate branding.

I know there has been some work done to make this easier and it’s mostly an education thing (make people aware that they should be doing this).

9

Yes that’s a straightforward opinion, I think everyone agrees with that. But the reason I brought the topic here is being more precise about cases here, such as if it’s not available to the public.

Since you mention bootable containers as an explicit call out, do you disagree with the premise that this whole topic applies to non-bootable containers, virtual machine and cloud images, etc. too?

On the other hand…I guess the more I think about this there is an angle to this for use cases where it’s just extremely unlikely that the user actually sees the Fedora trademarks at all; non-bootable containers are definitely one of those. Or really almost any “server” style use case.

10

Hmm..

It is assuredly best practice to use the fedora remix branding in this case.

Red Hat already follows some of this practice for its internal Fedora remix.. I’m using it right now.. and when I have the desktop logo on its clearly branded as a remix using the fedora remix brands. Other places in the interface its not so clear. I would like it to be clearer.. for example being able to go to about dialog and see the remix logo instead of the Fedora wordmark and logo would great. I’m not sure that’s actually implementable reasonably easily enough.

When/If Red Hat has an internal image mode based remix relying on bootc.. I expect it will continue to use the same implementable best practice. I certainly don’t want to get confused between using the internal fedora remix and my personal computer running stock fedora.

Regardless of the legal requirements, we should encourage best practice use of the remix brand as widely as possible. The easier we make the remix brand the starting point for derived things the less likely we have friction later with people.

Things we intend to be remixable should likely have the remix branding baked in. And ideally some hotdog shaped cartoon characters as well as an incentive to rebrand accordingly.

A late edit to add context on that last sentence.

I my mind we’re going to need to have bootc based outputs intended primarily to be Fedora branded experiences that represent the intentions of the fedora contributors to provide a an end user experience. But we are also going to have bootc based outputs we intend to be the base of customization.

It would be very interesting if the Fedora opinionated outputs were built from those base outputs as if they were just a particular kind of remix.. a remix that met requirements for the Fedora brand.

That way we are using the exact same process for the Fedore opinionated leaf outputs that we’d want to see other people use with their remixes.

Its one of those constructions I think makes more sense with the bootc based deliverables that is hard to express in the granular package mode deliverables.. this concept of delibrate layering where our own opinionated outputs use the same process we expect other remixes to use. We become a larger family of opinionated experiences in a shared ecosystem..

-jef

11

No sorry; this applies everwhere I just wanted to mention them explicitly since they’re (as you said) prevalent and have made it very easy to create a remix without realizing it and then putting it in a public registry :slight_smile:

12

From what I see, it is a less of the question of clarification, and more that of technical implementation.

Since there is no enforcement, the non-public users are going to be doing the thing which is more convenient to them, than the thing which is described in the policy.

From that point of view, maybe the question will be - what kind of change we can do to the tooling and branding, so that by default whenever people customize something, they will get the Fedora Remix. And making a thing not a Remix would require additional effort.

1 Like
13

We could (in the base bootc containers, in the base kiwi descriptions, and in the base image-builder definitions) swap out the release/logo packages with generics and only switch them over in the build system. That way anyone who builds on top of; or forks either of those things starts off with generics.

Not entirely sure if worth it :slight_smile:

14

It is indeed a bit of a controversy.

On one hand, we want to the remixes to be branded as Fedora Remixes by default.

On the other, it is valuable to show Fedora Spins as Fedora.

So if I am changing the base image only by installing more packages from the Fedora repos - it should be Fedora.

But if I am going for third-party packages or any other third-party content - it should be a remix.

Can we detect this somehow in the tooling?

Maybe a good way to explore this topic is to describe the current way(=best practices) of doing the Fedora Remix, atomic or packaged.

And then use that as a starting point to optimize.

15

I think that’s some of what Gordon is actually trying to do in his approach to what he’s working on. He’s trying to think like a Remix in an atomic context and fix the practises up either with tooling or documentation so we can have a clearer path for everyone working in that space.

I don’t want to put words in his mouth, but my interpretation of what he’s described to me is he’s taking systems approach to the problem so one of the durable outputs, maybe the most valuable durable output actually, from stuff he’s doing is a pattern of practise for remixes.

16

You include generic-release and generic-logos in your transaction and the Provides/Conflicts will handle the rest so it’s not very difficult to build an untrademarked Fedora Remix.

If people want to modify that further then one can create their own release package (which remixes, at least package-based ones tend to do). For example: packages/common/teamsbc-release/teamsbc-release.spec at main · teamsbc/packages · GitHub

This all does need to be documented so it’s easy for people to find the information as well. That’s something @ngompa and I have spoken about but E_NO_TIME.

17

..and then draw the rest of the owl :slight_smile:

Can we make fedora-logos package to conflict with any other -release package? So that if you override the fedora-release with something, you must override the fedora-logos?

Or, if it can not be done on package level, add some kind of vendor check in the build scripts and tooling, which says if release package comes from a different vendor, the -logos package must come from it as well?

18

Also generic-logos are not Fedora Remix logos currently, and i think it is wrong.

We need either to create remix-logos package or to change the generic-logos to be the remix by default.

19

The generic packages were intended to be an ‘example’ a remix could use by
taking it and replacing the various parts and renaming them…

but I admit there’s scantly documentation on that.

20

The purpose of the trademark system is to protect the consumers of a product who might be harmed if they are misled about the source of the product, and to protect trademark holders who should have exclusive rights to their reputation and goodwill in a market.

For anything that isn’t available to the public, I don’t believe trademark questions are relevant because the trademarks are not being used in any market. I don’t think there’s any concern that an organization will mislead itself about the origin of software that it uses internally.

Even for images that are available in public, incidentally (e.g. a container image used for CI that has non-Fedora software included, intended for an organization’s own use but not private), trademark certainly applies but I don’t think it’s possible or useful to try to find them to enforce trademark requirements.

The reason that I opened the ticket is neither of those cases, it is that Fedora’s trademark guidelines contain the specific requirement that “the fedora-logos, fedora-release, and fedora-release-notes RPM packages are removed”. Prominent and widely used Remixes don’t replace all of those packages, and merely replacing all of them breaks COPR, which makes it harder for Remixes to conform to the stated requirements.

@ngompa gave me Asahi’s handling as an example of the right approach (though I can’t find that at the moment), and I took portions of that handling for: Generic logos and release notes must replace Fedora's, as this is a R… · gordonmessmer/cerulean@e73f6b6 · GitHub

I would really like for building a derived system to be as simple as GitHub - ublue-os/image-template: Build your own custom Universal Blue Image! · GitHub , but using that template actually creates an image that doesn’t conform to trademark requirements. That’s not great.

That’s what I’d prefer.

I can think of a bunch of ways to address the problem. We can try to change the requirements so that remixes can use “fedora-release” (which is the most difficult package to replace, logos and release notes seem to be trivial), but the lawyers might not let us. We can write better, more specific documentation or template workflows, but we can’t require people to read it. We can open tickets and ask Remixes to replace the packages in question, but it’s super difficult to use the word “trademark” without causing people to panic.

The surest way to get Remixes to comply with trademark requirements is to give them something that complies with trademark requirements. Developers are not lawyers. Creating a better generic-release package is work that doesn’t really benefit Fedora, but creating builds that are easier to use for derived builds seems like the step that’s most likely to actually achieve that outcome.

Right. I made an intentionally simple Remix and one of the purposes of doing so was to illustrate for other Remixes some of the steps that are necessary. I want it to be easy to do things the right way.

I’ve talked to people about fixing some of these things, but fixing them doesn’t really benefit them much. What’s the up side to legal compliance? Who will notice an improvement?

People don’t want to do work that isn’t visible. Legal compliance, least of all.

Agreed. That does sound like a good idea.