1:55 p.m.
To the Fedora Community,
The Fedora policy on emulators has been in place for quite some time, it
is one of the first legal rules we put in place. Recently, we
reconsidered that rule and have amended our position (with discussion
from Red Hat Legal).
Previously, the guidelines forbid the majority of emulators from being
included in Fedora, but the new guidelines, while longer, are more
permissive.
=== Emulators ===
Some emulators (applications which emulate another platform) are not
permitted for inclusion in Fedora. These rules will help you determine
whether an emulator is acceptable for Fedora.
* Emulators which depend on firmware or ROM files to function may not be
included in Fedora, unless the copyright holder(s) for the firmware/ROM
files give clear permission for the firmware/ROM files to be distributed
(either under a Fedora permissible license or under the Fedora firmware
exception criteria). Note: This only covers the situation where an
emulator will not run at all without firmware/ROM files. For example,
emulators that compile and run, but ship with no game ROMs are not
covered by this rule.
* Emulators must not ship with any ROM files (e.g. games) unless those
ROM files are available under a Fedora permissible license and have been
built from source code in the Fedora buildsystem.
* Emulators must not point to any third-party sites which provide
firmware or ROM files that are distributed without the clear and
explicit permission of their copyright holders.
* All other Fedora licensing and packaging rules apply to emulators.
=================
The home for this policy is here:
https://fedoraproject.org/wiki/Licensing:SoftwareTypes#Emulators
This change is effective immediately and also applies to Copr.
If you have questions about this change, please feel free to email me
(either directly or on the devel/legal lists).
Thanks,
~tom
==
Red Hat
1:58 p.m.
On 05/03/2016 01:55 PM, Tom Callaway wrote:
[snip]
=================
The home for this policy is here:
https://fedoraproject.org/wiki/Licensing:SoftwareTypes#Emulators
This change is effective immediately and also applies to Copr.
If you have questions about this change, please feel free to email me
(either directly or on the devel/legal lists).
Thanks for the update, Tom.
Michael
2:04 p.m.
On 05/03/2016 02:58 PM, Michael Cronenworth wrote:
On 05/03/2016 01:55 PM, Tom Callaway wrote:
[snip]
> =================
>
> The home for this policy is here:
> https://fedoraproject.org/wiki/Licensing:SoftwareTypes#Emulators
>
> This change is effective immediately and also applies to Copr.
>
> If you have questions about this change, please feel free to email me
> (either directly or on the devel/legal lists).
Thanks for the update, Tom.
Thanks for asking about it! We're happy to revisit any policy, even if
the net result is that nothing changes.
~tom
==
Red Hat
3:18 p.m.
What about things like openmw that in theory can be run with free assests,
but for which there really isn't anything beyond a demo for other than
the assests from a proprietary game?
There also seems to be an agreement not to build the software on some
platforms in place, that isn't reflected in the license, but might attract
a lawsuit if someone did.
5:09 p.m.
On 05/04/2016 04:18 PM, Bruno Wolff III wrote:
What about things like openmw that in theory can be run with free
assests, but for which there really isn't anything beyond a demo for
other than the assests from a proprietary game?
The assets should not be a problem unless they're tied directly into
openmw as a runtime dependency (see Stephen's earlier example of the
PlayStation emulators that require a firmware blob).
There also seems to be an agreement not to build the software on
some
platforms in place, that isn't reflected in the license, but might
attract a lawsuit if someone did.
This is particularly concerning. I'd like to better understand that
situation before giving openmw the all-clear.
~tom
==
Red Hat
7:39 p.m.
On Wed, May 4, 2016 at 6:09 PM, Tom Callaway <tcallawa(a)redhat.com> wrote:
On 05/04/2016 04:18 PM, Bruno Wolff III wrote:
> What about things like openmw that in theory can be run with free
> assests, but for which there really isn't anything beyond a demo for
> other than the assests from a proprietary game?
The assets should not be a problem unless they're tied directly into
openmw as a runtime dependency (see Stephen's earlier example of the
PlayStation emulators that require a firmware blob).
So PCSX-R (which supplies its own replacement for the PS1 BIOS) would
be permissible, while PCSX2 (which requires a Sony BIOS) would not,
right?
--
真実はいつも一つ！/ Always, there's only one truth!
9:38 p.m.
On 05/04/2016 08:39 PM, Neal Gompa wrote:
On Wed, May 4, 2016 at 6:09 PM, Tom Callaway
<tcallawa(a)redhat.com> wrote:
> On 05/04/2016 04:18 PM, Bruno Wolff III wrote:
>> What about things like openmw that in theory can be run with free
>> assests, but for which there really isn't anything beyond a demo for
>> other than the assests from a proprietary game?
>
> The assets should not be a problem unless they're tied directly into
> openmw as a runtime dependency (see Stephen's earlier example of the
> PlayStation emulators that require a firmware blob).
>
So PCSX-R (which supplies its own replacement for the PS1 BIOS) would
be permissible, while PCSX2 (which requires a Sony BIOS) would not,
right?
As long as the PS1 BIOS replacement is FOSS and built from source, yes.
~tom
==
Red Hat
7:07 a.m.
> There also seems to be an agreement not to build the software on some
> platforms in place, that isn't reflected in the license, but might
> attract a lawsuit if someone did.
This is particularly concerning. I'd like to better understand that
situation before giving openmw the all-clear.
Unless you are curious, there is no need to look at it now. The FAQ entry
covering the issue (https://openmw.org/faq/#bethesda_legal) has a link to
a wiki page with their back and forth with Bethsheda which should let
you make a decision, if the people who have packaged it in rpmfusion wish
to try to get it into Fedora proper.
9:33 a.m.
On 05/05/2016 08:07 AM, Bruno Wolff III wrote:
>
>> There also seems to be an agreement not to build the software on some
>> platforms in place, that isn't reflected in the license, but might
>> attract a lawsuit if someone did.
>
> This is particularly concerning. I'd like to better understand that
> situation before giving openmw the all-clear.
Unless you are curious, there is no need to look at it now. The FAQ
entry covering the issue (https://openmw.org/faq/#bethesda_legal) has a
link to a wiki page with their back and forth with Bethsheda which
should let you make a decision, if the people who have packaged it in
rpmfusion wish to try to get it into Fedora proper.
That's a very strange situation, but I don't think it would affect
inclusion of openmw in Fedora.
~tom
==
Red Hat
10:59 a.m.
>>>> "TC" == Tom Callaway
<tcallawa(a)redhat.com> writes:
TC> That's a very strange situation, but I don't think it would affect
TC> inclusion of openmw in Fedora.
I would think that it requiring S3TC would be more of a blocker. But
then again, maybe it's possible for someone to cook up their own game
content that doesn't use compressed textures, but I don't see that as
being particularly useful.
- J<
1:29 p.m.
On 2016-05-05 10:59, Jason L Tibbitts III wrote:
I would think that it requiring S3TC would be more of a blocker.
But
then again, maybe it's possible for someone to cook up their own game
content that doesn't use compressed textures, but I don't see that as
being particularly useful.
Is S2TC a (legally and performance-wise) viable alternative for Fedora?
https://github.com/divVerent/s2tc
--
Yaakov Selkowitz
Software Engineer - Platform Enablement Group
Red Hat, Inc.
10:36 a.m.
On 05/05/2016 02:29 PM, Yaakov Selkowitz wrote:
On 2016-05-05 10:59, Jason L Tibbitts III wrote:
> I would think that it requiring S3TC would be more of a blocker. But
> then again, maybe it's possible for someone to cook up their own game
> content that doesn't use compressed textures, but I don't see that as
> being particularly useful.
Is S2TC a (legally and performance-wise) viable alternative for Fedora?
https://github.com/divVerent/s2tc
I see no legal reason that Fedora could not include that S2TC
implementation. Can't speak to the performance viability of it.
~tom
==
Red Hat
2908
days inactive
2914
days old
11 comments
6 participants
participants (6)
-
Bruno Wolff III -
Jason L Tibbitts III -
Michael Cronenworth -
Neal Gompa -
Tom Callaway -
Yaakov Selkowitz