Re: legal questions regarding machine learning models
> > I agree with you. In particular, in many cases a single 3D model is used
> > to create many 2D images. If you don't have the model, you need to do
> > the modification many times.
> > And then there is the case of increasing the resolution...
> I don't know if it would be technically possible to go to that
> extremes. Having the source code of all the music and video intros for
> all the games, of all the sounds, could be probably 100 times bigger
> than the current archives. Well, you get the idea. I don't think it's
> a single package what we're talking about. I remember there was a
> thread some time ago on what would happen if we took the "having a
> whole free source and toolchain" when applied to music, and how it
> would be absolutely impossible to achieve, at least right now. Any
> idea on what to do in those situations?
That's a mixture of questions. I'll add my 2e-2 Euro to each separately.
Archive size: The case that I had in mind is that the data is purely
synthetic. In those cases the source form is negligibly small when compared
to the binary form. Especially in the cases you mention: Game intros
rendered from some 3D scene. Game music created from some music score.
Sounds which are programmed.
I assume that you have non-synthetic data in mind: Music which is actually
recorded, videos which are shot with real actors, sounds recorded from the
real world. And that what is shipped is a severely compressed form of the
original. In that case I guess one can argue that the source requirement
is void: I always understand source to be preferred form for modifications
among the digital forms of the software. The kind of modifications I see
for e.g. music (replace the violin player by someone who actually can play
the instrument; correct a discord which is due to a typo in the score) is
impossible to achieve without rerecording, so a big digital version of the
music is just as useless as a small one.
Building time: Coming back to purely synthetic data. building time can be
a real pain. Waiting 24 hours (on fast machines) for a build is fine for
me as upstream, but not something I would want to cause to your buildd when
my software is just one out of thousands of packages. There, I do see a
practical problem.
With my upstream hat on, I will continue to ship my data under licenses
that do require source, but I will not care whether you redo the building
or whether you just copy the precompiled data which I give you. Provided
of course, that you also ship the source.
Extremes: I do not agree with this classification of my view.
I value a free game for the fact, that I can fool around with the source
to make it "better". Adding features, levels, characters. If this means
that I have to add long ears to some sprite (which is obviously generated
from some 3D model), then I want to have access to that model and to the
toolchain used to turn the model into the sprite. Because that is much
more simple and robust, and creates a much more consistent set of sprite
animation parts, than doing it with gimp on each part of each animation
sequence individually. Free data is important for the very same reason
that free programs are!
What to do: As always it is a tradeoff between quantity and quality, in
this case of packages. Maintaining a high freeness standard has an impact
on the resources needed, so it limits the number of costly packages that
you can support for any given amount of available resources.
I value Debian because (and as long as) it puts the emphasis on freeness.
> PS:I'm CC'ing to the Debian Games Team mailing list.
Done as well, but I am not subscribed to that list.
Reply to: