[Pkg-rust-maintainers] rust-gestreamer-player sys license questions

[Sebastian Dröge]

On Tue, 2022-08-23 at 15:02 -0700, Sean Whitton wrote:
> 
> Not quite what I said -- for that particular package, it seemed to me
> that the way in which a subset was taken did not mean that the files
> were no longer in their preferred form for modification.  It is
> surely not the case that *any* subset of the preferred form for
> modification of any source file is still the preferred form for
> modification :)

Ok, so let's take some examples here and you can tell me if that's the
"preferred form of modification". It seems to mean more something along
the lines of "possible form of modification".

  1. Trivially minified JavaScript. You just remove all whitespace and
     put everything in a single file.

     This is technically the same as in gobject-introspection. The
     transformation from the original source code to what the source
     package includes is to remove all C code and keep the
     documentation comments, then merge it all into a single file.

     It's clearly not literally the "preferred form of modification"
     because if you can you would modify the original source code
     instead and just let your script run over it again. But you
     *can* modify it and it might be more practical depending on
     circumstances.

  2.a.
     A manpage created from e.g. markdown or docbook-xml. It's a
     relatively trivial transformation and writing troff by hand is
     not a lot of fun.

  2.b.
     Documentation comments/etc extracted from C source code and
     converted into some XML format. Like what most documentation
     tools do at this point (well, they might output HTML but details).


     This is both technically the same as what gobject-introspection is
     doing to go from both the included extracted source code comments
     as well as actual C source code to generate the .gir files we were
     talking about many times here.

     Again, this is clearly not literally the "preferred form of
     modification" because if you can you would modify the original
     source code and run the script again. But you *can* modify it and
     it might be more practical depending on circumstances.

  3. Taking the XML format from 2.b. and converting it to some other
     format via some simple transformation. E.g.

       <function name="foo">
         <args>
           <arg type="int" name="arg1" />
         </args>
         <return type="void" />
       </function>

     to

       void foo(int arg1);   // C

     or alternatively

       fn foo(arg1: i32);    // Rust

     or alternatively

       public void foo(int arg1);   // Vala


     This is technically what happens in rust-gstreamer-player-sys and
     similar packages (including vala) to generate the files that are
     shipped in the source package.

     I'm repeating myself, but this is again clearly not literally the
     "preferred form of modification" because if you can you would not
     modify this, and also not the XML file, but the original C source
     code and regenerate the intermediate steps with your scripts. It
     might however be more practical in some circumstances to just edit
     this until e.g. a bug in one of the scripts is fixed or the
     changes in the original source code propagated through the
     intermediate steps shipped by other packages.


What's your opinion here and why? Especially if your answers are
different for these cases, what is the difference that changes your
answer?


And as a second question would you feel comfortable saying that every
ftp-master would agree with you? And if not, what are the plans to
solve this uncertainty among ftp-masters so that as a package
maintainer there are actual clear rules to follow?

> > In that case we could go here with shipping the .gir XML files with
> > the Rust source packages plus shipping some compatible version of the
> > code generator in the archive.
> > 
> > If that is the ftp-master consensus then we would've found a way
> > forward here. Can you confirm that?
> 
> It sounds plausible if the .gir files are just a subset in the way that
> those files in the other package are -- again, it's case-by-case, and I
> haven't looked at these files.
> 
> I suggest you explain in README.source why you think the .gir files are
> still in their preferred form for modification.  Then the person looking
> at the package in NEW can assess that.

That doesn't seem like a useful approach to solving this. It would only
again mean that it depends on who actually looks at the package in NEW.
Apparently Thorsten comes to different conclusion on the current
package than whoever previously accepted e.g. rust-glib-sys or vala.

Also it means that as a package maintainer a lot of work has to happen
beforehand until this question is actually assessed: packaging another
source package (the code generator), having that go through NEW after a
few days/weeks/months, adding changes to the original source (including
the .gir files), uploading rust-gstreamer-player-sys again, waiting a
couple of days/weeks/months. And then potentially having to redo steps
of this, doing things completely differently, maybe just having to wait
another few days/weeks/months because a line was missing in
debian/copyright, etc.

And maybe for rust-gstreamer-player-sys this time e.g. Thorsten agrees
that it's all fine, and next for rust-gstreamer-whatever-sys e.g. you
come to the conclusion that it's not actually fine and we're back to
where we are now.


Additionally, so far you are the only ftp-master who participated in
this discussion and you apparently never even looked at the packages in
question (I don't expect you too, FWIW, it's your decision what you do
with your time and we're all doing this in our spare time and thanks
for replying at all).

Thorsten apparently looked at *this* package and could provide some
insights into his thought process as to why this package is not
acceptable but others are in his opinion. He must've thought about this
already in detail.
Similarly, the opinion of whoever accepted e.g. rust-glib-sys, vala or
any of the other packages mentioned before must've thought about this
already in detail and considered those cases acceptable for some
reason.

These justifications / thought processes would be interesting to hear
and it would be useful to clearly define what the differences in these
cases are that make it acceptable for one case and not for another and
agree on this among all ftp-masters so we don't end up in the same
situation with the next package.


I would also expect that if a new version of the package is uploaded,
it would likely take months before there is a decision because I don't
think anybody to take a decision now that a) potentially affects many
packages, b) is inconsistent with previous decisions.

Having to first do a considerable amount of work, just to have radio
silence for months and then possibly again getting back an opaque "your
package is not DFSG compatible" without any further details,
justification or steps to solve it is not really great and a waste of
everybody's time.


In summary, I think there's a fundamental problem here and just hiding
behind opaque and inconsistent case-by-case decisions after
considerably amounts of work were done is clearly not the way forward
here. If ftp-masters don't want to decide about this in general and
come up with a clear set of rules for the cases in question here then
maybe this will have to be brought up and decided at a higher level.


PS: From an upstream perspective this is also rather unacceptable. We
saw that distros (including Debian) are apparently fine with this
approach for literally decades, and designed things accordingly. But
now it's suddenly a problem. If this was clear from the beginning we
could've looked for a different approach before a lot of work was put
into the current approach. Think about the signal you're sending here
to other projects.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20220824/3d9fcda6/attachment.sig>