Re: FSDG issues of SCUMMVM-based games

[Tobias Geerinckx-Rice]

I got an auto-reply with a ticket number from the FSF, but no answer yet.

I was aware of and unimpressed by Debian's rationalisations on the matter.

Still, this isn't as clear-cut as (say) the Realtek drivers, so IMO we can 
afford to wait as long as is needed.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Re: FSDG issues of SCUMMVM-based games

[Maxime Devos]

On 24-08-2022 22:24, zimoun wrote:

My understanding of the Debian argument is:

  1. the licence is BSD-like respecting the Debian Free Software Guidelines

  2. point #3 of DFSG [2] says «The license must allow modifications and
  derived works, and must allow them to be distributed under the same
  terms as the license of the original software.»

  3. considering game data, all people are equals – from original author
  to users – because the tool set for modifying these game data does not
  exist anymore

Therefore, drascula is part of the ’main’ Debian archive, scummvm too.


I remember (3). I find this an interesting argument.

As far as I know, the 4 freedoms and the whole 'free software!' thing 
was not a goal in itself, but rather a means to  a goal, a response to 
'many times some people and organisations have imposed impractical 
restrictions on software, causing problems (example: this situation in 
19NN, that situation in 20??, ...) -- can we identify the problems and 
generalize until we have a set of rules (4 freedoms) that need to be 
respected to avoid the problems?'.


As far as I know, drascula situation is not comparable (see: 'all people 
are equals') to the old problems. Yet, I cannot say it's free software 
(without the tools, it's effectively a binary instead of source code 
until, if ever, the tools are reinvented) (see some of my other 
responses in this thread).


As such, do the 4 freedoms need some refinement to accept drascula, do 
we have to weaken our requirement of 'only free software' for special 
situations like this one, or do we remove drascula, or is there somehow 
a fourth option I'm not thinking of?


Myself, I do not know the answer. However, I cannot help with the first 
option, the second sounds iffy to me (the exception would need to be 
worded really well, or it would be a 'case-by-case' matter which could 
take a long time to decide case-by-case, and in both cases it doesn't 
seem to fit in 'GNU: free software!').


As such, for me, only the third (removing drascula) is practical for me, 
but there are other people here too which could perhaps, say, do the 
first or something ...


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: FSDG issues of SCUMMVM-based games

[Maxime Devos]

On 24-08-2022 22:24, Vagrant Cascadian wrote:

Is it Functional Data:

   https://www.gnu.org/distros/free-system-distribution-guidelines.html

   "For example, some game engines released under the GNU GPL have
   accompanying game information—a fictional world map, game graphics,
   and so on—released under such a verbatim-distribution license. This
   kind of data can be part of a free system distribution, even though
   its license does not qualify as free, because it is non-functional."


SCUMMVM, among other things, interprets the bytecode of the games (see: VM).

A long time ago, I looked at the Debian package of one of the games, and 
there appeared to be only a single 'game' file IIRC, presumably this 
includes the bytecode.


Bytecode is code and hence functional, if 'functional' is interpreted in 
the narrow sense of 'it does a practical job'.


As such, I do not think this falls under 'non-functional data'

---

That paragraph also appears inconsistent to me. The world map, game 
graphics, sounds ... are one of the most important components of the 
game. If someone wants to modify the game, I consider it more likely 
they have to modify the world map and maybe add some graphics and sounds 
than that they have to change the engine. Seems pretty 'functional' to 
me. It also does a practical job: entertaining the user.


As such, it appears to me that if the ‘meh, it's non-functional data’ is 
non-free, then the game is effectively non-free  software does not 
just consist of code, the non-code parts are sometimes as important as 
the code or more important -- they belong together, as a whole.


Myself, being able to code but not good at art, I would rather have a 
non-free game engine with free non-functional data than the free game 
engine with non-free non-functional data that the FSDG refers to, at 
least I would with a sufficient amount of work (*) be able to replace 
the non-free engine, but don't ask me to replace the artwork ...


(*) and some assistance, depending on the size and complexity.

---

Another thing I would like to note is that, even if it were 
non-functional data, according to (guix)Software Freedom everything in 
Guix is free software:



The GNU operating system has been developed so that users can have
freedom in their computing.  GNU is “free software”, meaning that users
have the four essential freedoms
(https://www.gnu.org/philosophy/free-sw.html): to run the program, to
study and change the program in source code form, to redistribute exact
copies, and to distribute modified versions.  Packages found in the GNU
distribution provide only software that conveys these four freedoms.
(I'm interpreting 'GNU operating system' and 'GNU distribition' as 
'Guix' here.)


That paragraph, and the web page referred to there does not make an 
exception for non-functional data -- if it's software, the 4 freedoms 
should apply, this is usually code but the freedoms and the reasons for 
them apply to software in general, not for code in specific.


To me, it appears that the SCUMMVM games cannot be in Guix, because of 
that rule.


It is, however, contradicted by the following paragraph, which is also a 
bit misleading:



   In addition, the GNU distribution follow the free software
distribution guidelines
(https://www.gnu.org/distros/free-system-distribution-guidelines.html).
Among other things, these guidelines reject non-free firmware,
recommendations of non-free software, and discuss ways to deal with
trademarks and patents.
I consider it contradictory in the sense that it adds exceptions to the 
'software must be free' claimed by the the previous paragraph, without 
being explicit that there are exceptions (see: non-functional data). I 
consider it misleading in the sense that the phrasing implies it just 
adds a bit of rules (on top of the 4 freedoms thing) and advise on 
potential legal problems, even though it also carves out a few 
exceptions (see: non-functional data).



You cannot sell the game itself, but you can charge "a reasonable
copying fee" and distribute it commercially... while slightly confusing
and seemingly contradictory at a passing glance, those two clauses alone
do not appear to violate any of the four freedoms to me:

   https://www.gnu.org/philosophy/free-sw.html#four-freedoms
While initially I thought of it as 'a no-selling clause -> 
non-commercial only -> non-free', after your explanation I agree -- it 
does not appear to have the potential problems referred to in 'Free 
software can be commercial' and there is no explicit 'The freedom to 
sell software.'.



I'm not really sure you have the right to "sell" most software in GNU
Guix, but you're free to distribute it and even charge for the
distribution of it, and use it in products that you sell to customers.

Most licenses do not give you ownership of the software; they roughly
give you permission to use, study, modify, and share it under the terms
of that license. If you do not own it, I am not 

Re: guix lint should support overrides

[Vagrant Cascadian]

On 2022-08-24, zimoun wrote:
> On Tue, 23 Aug 2022 at 15:22, Vagrant Cascadian  wrote:
>
>> But, because there is no way to silence a particular inappropriate
>> suggestion from guix lint, it becomes noise, and each person evaluating
>> the results of the package in the future then needs to take time to
>> figure out if guix lint is wrong, or something should be changed.
>
> Do you have some packages as example?  In order to be concrete about the
> false-positive and how to programatically fix them.

Off the top of my head, no, though it came up in the course of a
convesation on #guix recently, and it reminded me of advice I've gotten
in the past to just ignore a particular check on a particular package.


> For instance, do you mean exclude on specific checker for one specific
> package?

Yes, this! :)

Maybe something like:

(define-public thispackages
  (package
   (name "thispackages"
   ...
   (lint-overides
(list
;; The upstream name is actually "This Packages", not a typo.
"typo in description: 'This Packages' should be 'This Package'")) 

And then guix lint would hide or ignore things that would otherwise emit
the strings listed in lint-overrides ... or something like that. Maybe
exact match, maybe get into a little pattern matching, not
sure. Implementation is not my strong point here. :)

You might also want to add a guix lint check for unused overrides
(e.g. something that no longer triggers the issue, either fixed upstream
in guix lint itself, or some other way).


> Or teach one specific checker for one specific package in
> order to avoid an error specific to this package running this specific
> checker?

No. Maybe in some cases this might make sense, but was not what I was
suggesting.


>> The downside is this becomes one more thing to maintain... in exchange
>> for making the output having a higher degree of relevency in "guix lint"
>> output, so you can be more confident that someone hasn't already looked
>> at a given issue and decided it was best to just ignore it (not that
>> that will not ever happen anymore, but still).
>
> The cost for a poor maintenance is low compared to the benefit, IMHO.
>
> For instance, it is boring to run massive lint:
>
>  1. because “guix lint” does not support the option --manifest
>  2. because “guix lint” reports some false-positive messages

Yeah, my suggestion was mostly about trying to address aspects of point
2.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: guix lint should support overrides

[Maxime Devos]

On 24-08-2022 10:08, zimoun wrote:

Hi Vagrant,

On Tue, 23 Aug 2022 at 15:22, Vagrant Cascadian  wrote:


But, because there is no way to silence a particular inappropriate
suggestion from guix lint, it becomes noise, and each person evaluating
the results of the package in the future then needs to take time to
figure out if guix lint is wrong, or something should be changed.

Do you have some packages as example?  In order to be concrete about the
false-positive and how to programatically fix them.

For instance, do you mean exclude on specific checker for one specific
package?  Or teach one specific checker for one specific package in
order to avoid an error specific to this package running this specific
checker?


Myself (not Vagrant) I was thinking of the gnu-description linter.

IIRC, there was some package where I proposed to modify the description 
a little to be more informative and fit better in Guix, but then the 
gnu-description proposed to use the upstream description. Consequently, 
it was decided to use the original, IMO worse, description.


Unfortunately I cannot find the relevant e-mails anymore.

This was a true positive, not a false positive, but I think it would 
have been useful to silence the linter there anyway.


At least for these kind of cases, I would go for a package property 
(properties '((silence-linters gnu-description))).


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: FSDG issues of SCUMMVM-based games

[zimoun]

Hi Liliana,

(I have no opinion about this topic.)


Your quote is:

>> The data included in the source package represents the preferred form
>> for modifications.
>> If they were licensed under the G P L it would fail the "preferred
>> form of modification" requirement

but from the mentioned link [1], the quote includes a _but_:

--8<---cut here---start->8---
   If they
 were licensed under the G P L it would fail the "preferred form of
 modification" requirement, but its BSD-like license grants you all the
 necessary rights to modify, use and distribute them.
 .
 While there likely was, once upon a time, a custom set of tools to create this
 game data, those tools do not exist any more.  The original creators of the
 game are in the same situation as Debian's users when it comes to
 modifications.
 .
 Also, the reason for requiring the "preferred form for modification" is to not
 put the creator of the software/data in a "monopoly" situation. This isn't the
 case here.
--8<---cut here---end--->8---


> As far as I'm concerned, "preferred form of modification" should not be
> dependant upon the license in question.  Speaking of the license in
> question, it's prohibition of selling is nowhere mentioned.

My understanding of the Debian argument is:

 1. the licence is BSD-like respecting the Debian Free Software Guidelines

 2. point #3 of DFSG [2] says «The license must allow modifications and
 derived works, and must allow them to be distributed under the same
 terms as the license of the original software.»

 3. considering game data, all people are equals – from original author
 to users – because the tool set for modifying these game data does not
 exist anymore

Therefore, drascula is part of the ’main’ Debian archive, scummvm too.

Tobias wrote [3]:

Either the inclusion of [a subset of] Drascula in Trisquel[0] is
a similar oversight, or we're missing some legal subtlety.

so maybe some legal subtlety is indeed missed.  Let wait an answer by
FSF licensing department… if any. :-)
 

1: 

2: 
3: 


Cheers,
simon

Re: guix lint should support overrides

[zimoun]

Hi Vagrant,

On Tue, 23 Aug 2022 at 15:22, Vagrant Cascadian  wrote:

> But, because there is no way to silence a particular inappropriate
> suggestion from guix lint, it becomes noise, and each person evaluating
> the results of the package in the future then needs to take time to
> figure out if guix lint is wrong, or something should be changed.

Do you have some packages as example?  In order to be concrete about the
false-positive and how to programatically fix them.

For instance, do you mean exclude on specific checker for one specific
package?  Or teach one specific checker for one specific package in
order to avoid an error specific to this package running this specific
checker?


> The downside is this becomes one more thing to maintain... in exchange
> for making the output having a higher degree of relevency in "guix lint"
> output, so you can be more confident that someone hasn't already looked
> at a given issue and decided it was best to just ignore it (not that
> that will not ever happen anymore, but still).

The cost for a poor maintenance is low compared to the benefit, IMHO.

For instance, it is boring to run massive lint:

 1. because “guix lint” does not support the option --manifest
 2. because “guix lint” reports some false-positive messages


Cheers,
simon

Re: FSDG issues of SCUMMVM-based games

[Vagrant Cascadian]

On 2022-08-24, Liliana Marie Prikler wrote:
> Am Mittwoch, dem 24.08.2022 um 14:53 +0200 schrieb Nicolas Goaziou:
>> Liliana Marie Prikler  writes:
>> 
>> > The packages
>> > - drascula,
>> > - lure,
>> > - queen, and
>> > - sky
>> > all share issues that make me question whether they should be in
>> > Guix.
>> > 
>> > 1. Their license explicitly prohibits selling of the games
>> > themselves and may thus be qualified as non-free.
>> > 2. The "sources" consist of binaries that are installed as-is.
>> > 
>> > Given the above, I think we ought not distribute them.  Note that
>> > this is not a statement on SCUMMVM itself, but only the packages
>> > built with it.
>> > 
>> > WDYT?
>> 
>> For the record, I added these games because I agree with Debian
>> packagers on the topic. See
>> <
>> https://metadata.ftp-master.debian.org/changelogs//main/d/drascula/drascula_1.0+ds4-1_copyright
>> >.
> This statement seems to contradict itself.
>> The data included in the source package represents the preferred form
>> for modifications.
>> If they were licensed under the G P L it would fail the "preferred
>> form of modification" requirement
> As far as I'm concerned, "preferred form of modification" should not be
> dependant upon the license in question.

Is it Functional Data:

  https://www.gnu.org/distros/free-system-distribution-guidelines.html

  "For example, some game engines released under the GNU GPL have
  accompanying game information—a fictional world map, game graphics,
  and so on—released under such a verbatim-distribution license. This
  kind of data can be part of a free system distribution, even though
  its license does not qualify as free, because it is non-functional."


> Speaking of the license in question, it's prohibition of selling is
> nowhere mentioned.

It is mentioned in the above link:

"2) You may charge a reasonable copying fee for this archive, and may
distribute it in aggregate as part of a larger & possibly commercial
software distribution (such as a Linux distribution or magazine coverdisk).
You must provide proper attribution and ensure this Readme and all
associated copyright notices, and disclaimers are left intact.
 .
 3) You may not charge a fee for the game itself. This includes reselling the
game as an individual item."

You cannot sell the game itself, but you can charge "a reasonable
copying fee" and distribute it commercially... while slightly confusing
and seemingly contradictory at a passing glance, those two clauses alone
do not appear to violate any of the four freedoms to me:

  https://www.gnu.org/philosophy/free-sw.html#four-freedoms


I'm not really sure you have the right to "sell" most software in GNU
Guix, but you're free to distribute it and even charge for the
distribution of it, and use it in products that you sell to customers.

Most licenses do not give you ownership of the software; they roughly
give you permission to use, study, modify, and share it under the terms
of that license. If you do not own it, I am not sure you can sell it...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: FSDG issues of SCUMMVM-based games

[Liliana Marie Prikler]

Am Mittwoch, dem 24.08.2022 um 14:53 +0200 schrieb Nicolas Goaziou:
> Hello,
> 
> Liliana Marie Prikler  writes:
> 
> > The packages
> > - drascula,
> > - lure,
> > - queen, and
> > - sky
> > all share issues that make me question whether they should be in
> > Guix.
> > 
> > 1. Their license explicitly prohibits selling of the games
> > themselves and may thus be qualified as non-free.
> > 2. The "sources" consist of binaries that are installed as-is.
> > 
> > Given the above, I think we ought not distribute them.  Note that
> > this is not a statement on SCUMMVM itself, but only the packages
> > built with it.
> > 
> > WDYT?
> 
> For the record, I added these games because I agree with Debian
> packagers on the topic. See
> <
> https://metadata.ftp-master.debian.org/changelogs//main/d/drascula/drascula_1.0+ds4-1_copyright
> >.
This statement seems to contradict itself.
> The data included in the source package represents the preferred form
> for modifications.
> If they were licensed under the G P L it would fail the "preferred
> form of modification" requirement
As far as I'm concerned, "preferred form of modification" should not be
dependant upon the license in question.  Speaking of the license in
question, it's prohibition of selling is nowhere mentioned.

Cheers

Re: secure boot

[Maxime Devos]

On 24-08-2022 05:07, Philip McGrath wrote:

I could imagine a process like this:

  1. Build the binary that needs to be signed.
  2. Outside of the Guix build environment, create a detached signature
 for the binary using your secret key.
  3. Add the detached signature to the Guix store, perhaps with 'local-file'.
  4. Use Guix to attach the signature to the built binary.
  5. Use the signed binary in your operating-system configuration.


To implement this, you could have a look at "dynamic dependencies" in 
guix/store.scm and guix/graftsscm.


From the with-build-handler docstring:

Build handlers are useful to announce a build plan with 
'show-what-to-build'
and to implement dry runs (by not invoking CONTINUE) in a way that 
gracefully
deals with \"dynamic dependencies\" such as grafts---derivations that 
depend

on the build output of a previous derivation."


On grafts: the derivation of the grafted version depend on what the 
references of the store item used to be, this can only be decided 
outside the store (kind of similar to this situation).


Greeetings,
Maxime



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: FSDG issues of SCUMMVM-based games

[Nicolas Goaziou]

Hello,

Liliana Marie Prikler  writes:

> The packages
> - drascula,
> - lure,
> - queen, and
> - sky
> all share issues that make me question whether they should be in Guix.
>
> 1. Their license explicitly prohibits selling of the games themselves
> and may thus be qualified as non-free.
> 2. The "sources" consist of binaries that are installed as-is.
>
> Given the above, I think we ought not distribute them.  Note that this
> is not a statement on SCUMMVM itself, but only the packages built with
> it.
>
> WDYT?

For the record, I added these games because I agree with Debian
packagers on the topic. See
.

Regards,
-- 
Nicolas Goaziou