[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Free non-software stuff and what does it mean. [was Re: General Resolution: Force AMD64 into Sarge]

Andrew Suffield wrote:

>On Fri, Jul 23, 2004 at 11:35:23AM -0500, Adam Majer wrote:
>>Right. I hope no one is too pedantic about it. This especially applies
>>to data like fonts, graphics and sounds. Sometimes "preferred" format
>>for these cannot be put into source without blowing it up by a factor of
>>10, or more. Furthermore, the "preferred" format might be completely
>>useless to anyone but upstream.
>That is *precisely* why we need to have that format. If upstream dies,
>somebody needs to be able to pick it up.
>Your argument applies equally to software - the source form is useless
>to anybody but developers; most users want binaries. We ship source

A lot of data in Debian are images. I'm quite alright with those staying
in the format that they are. If something needs to be changed, that
change can be done quite easily using Gimp or something. *But* the
format used by upstream might be something different. Instead of a jpeg,
they might have used xcf or bmp, completed the drawing, make a jpeg out
of it and *deleted* the original. Does that mean that the entire
software is now non-free? I *really* hope not. I see a lot of xpm and
other things. I'm quite sure those are not preferred format by current

My entire point here is that,

1. You don't need a .wav "source" for an .ogg "binary"
2. You don't need upstream pic "source" for the {png, jpeg, etc.} "binary"
3. You don't need some native font format if we have the "binaries"

The reason for this is that both are almost identical. It is often
easier to edit the "binary" part since it has a known format - just look
at the application's source code for that. The "source" can be in a
format where there is no free, or even commercial applications available
to edit it (source can be "compiled" with a home brewed "compiler")!

For example, if I make a super thought-compiler that translates my
thoughts into C++ which is then compiled by gcc into opcodes, does that
mean that for the resultant application is non-free even if C++ source
code is provided under GPL? No!

What is wrong with just saying "stuff licensed under a free license that
satisfies the DFSG, is considered free"?? This is the premise that I
assumed when I voted for the removal of "software" from DFSG. I didn't
vote for the craziness that might just end up with Debian going the way
of XFree86!!!

I assumed the change meant that *ALL* parts of the application must
distributed under a free license. This includes the source code to the
application, the graphics, the sounds, etc... Previously, only the
source code needed to be free and pictures, sounds, etc.. could be
distributed under a non-free license (ie. no changes allowed). *BUT*
virtually all applications in Debian are distributed under *one*
license. That is, the entire work is under one, free license. This
includes pics, sounds, etc..

Please tell me that DFSG is going to apply the the *license* of the
application only, as it did. Please tell me we are not going to start
harassing upstream over `flush.ogg` asking them what toilet it was
recorded from and was it a free, public toilet or a non-free one. Oh,
and what happened to the WAVe of the flush?

- Adam

PS. The deal with the kernel and binary blobs in there has *nothing* to
do with the new DFSG, AFAICT. Some binary blobs can be said to violate
GPL, and that is an upstream issue, not Debian's. Blobs that don't
violate GPL, are free by the virtue of the license. Does this make sense? :)

Building your applications one byte at a time

Reply to: