#1

Hi

I’m currently working on a Fedora Core OS based “custom build” based on your toolchain (coreos-assembler & ignition & fedora-coreos-config & …). Since we intend to sell the “final result” (including proprietary software) as product a detail analysis of the different licenses is ongoing.

I had a look at:

I assume our product constitute as “Fedora Remix” (but most likely we won’t use any Fedora labeling).
In addition I understand that we have to assess the licenses of the included RPMs.

  • Is this compliant with Fedora (CoreOS) license?
  • I assume that e.g. coreos-assembler (despite the Apache License 2.0) does not require “License and copyright notice” in the final product. Is this correct?
#2

(I’m not a lawyer)

Is this compliant with Fedora (CoreOS) license?

I’d say “licenses” not “license”, but as far as I know: Yes.

I assume that e.g. coreos-assembler (despite the Apache License 2.0) does not require “License and copyright notice” in the final product. Is this correct?

I was going to say that no code from coreos-assembler ends up in the target system (it’s a tool to build, like gcc or make) but it’s possible there are some small exceptions to that; e.g. the grub.cfg is generated from a script in there.

That said there are other ASL 2.0 projects in there like Ignition, and since you need to comply with the license for those you might as well do so for coreos-assembler as well - it’s not onerous to do so right? (Although it is interesting because basically everything else apart from fedora-coreos-config is an RPM, whereas coreos-assembler is a container)

#3

Submitted https://github.com/coreos/fedora-coreos-config/pull/610 related to the above.

#4

Hi abitzer,

are you planning to use the whole toolchain (eg: fedora-coreos-pipeline, fedora-coreos-releng-automation)?

I’ve been looking at doing a project based on Fedora CoreOS as well (except not proprietary).

#5

Hi @tomleb

Yes, we use the toolchain. It’s definitely not an easy task, but we managed it (to a larger extend).
But we try keep it to a minimum (effort, resources), e.g. we don’t use fedora-coreos-releng-automation.

#6

Hi @walters

Thanks for your support. Works for me.
I add a look on all the requirements and i realized a couple of things:

  • Most likely we will have to remove “zincati”. Is there an other way to remove it then messing around with “fedora-coreos.yaml”. e.g. override?
  • We also will have to adapt: “tracker.motd”. Can this be done via override?
  • Same question for “console-login-helper-messages”?
#7

Most likely we will have to remove “zincati”. Is there an other way to remove it then messing around with “fedora-coreos.yaml”. e.g. override?

rpm-ostree’s manifests don’t support removals, you need to instead just inherit from e.g. bootable-rpm-ostree.yaml. This is what the RHCOS config does.

(Or you could include the binary and add something to disable the service)

I think the same answer applies to the other bits generally.

#8

@walters
Thanks a lot.

If further investigated:

According to:
https://fedoraproject.org/wiki/Legal:Trademark_guidelines

the fedora-logos, fedora-release, and fedora-release-notes RPM packages must be removed in case of “Distributing combinations of Fedora software with non-Fedora or modified Fedora software”

Unfortunately “fedora-release-coreos” contains e.g. presets.
I propose to separate it into different packages to allow fedora-coreos-based products to be compliant.
What do you think?