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

Re: GR: GFDL Position Statement

Gerfried Fuchs wrote:
>  Along the same lines of "(3) Why does documentation need to be Free
> Software?" I want to ask if not other media like images or music has to
> meet the same rules? (though with different reasoning, but same impact)
Yes, it does.

>  I can understand that the "source" for those things might be tricky,
> but often images are flattened photoshop files or (with non-free tools)
> rendered graphics, or music converted midi files.
Yes, these are classic "must provide source to be free software" cases.

>  As an example I want to question if I would have to move xblast* to
> contrib, because the graphics are rendered with povray, or if there is
> no need for it?
If you wished to modify the graphics, would you want to do so with the povray 
source?  If the answer is "yes", then the graphics are 'contrib' material.  
If the answer is "no, I'd use the rendered files", then the povray source 
should not be considered "source" for our purposes, and the rendered files 
should be.

Are the graphics essential to the normal use of the package?  If the answer is 
"no", then 'contrib' material can go in the package even though the package 
is in 'main'.

> There are for sure other graphics that fall under the 
> same thing; at least I can say for xblast that I'm in the good position
> to have the povray source available with which the images were rendered.
If you did not have the source of the images, then the images would be 

> But would producing them on build-time really raise the quality, moving
> xblast* to contrib?
You don't actually have to produce them at build-time if there's a good reason 
not to (such as avoiding spurious changes due to incremental changes in 
povray); consider 'configure' scripts and the like, for which the generated 
code is generally shipped in the source tarball along with the source code.  
You do have to ship the source files in the source tarball.

> If this is done then please think of other packages 
> with the same "problem", too.
Thought of long long ago.

Reply to: