Re: GR: GFDL Position Statement

[Francesco Poli]

On Sat, 21 Jan 2006 18:55:59 + Andrew M.A. Cater wrote:

> On Sat, Jan 21, 2006 at 10:41:26AM +0100, Francesco Poli wrote:
[...]
> > Or otherwise, povray upstream authors could be persuaded to
> > relicense in a DFSG-free manner, so that we would *gain* one new
> > interesting package for main, rather than *losing* one (that was
> > wrongly placed in main). ;-)
> > 
> If you read the license files, they intend to change the licence with
> the next release. Their problem is that they can't find all
> contributors to release the current version, as far as I can see.
> 
> Povray will, eventually, get into main :)

That is really good news!  :)

They must of course find and persuade all the people whose contribution
is included in the next release. I hope they succeed.

Which license are they trying to switch to?


-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpivVwFAP6Mp.pgp
Description: PGP signature

Re: GR: GFDL Position Statement

[Francesco Poli]

On Sat, 21 Jan 2006 13:17:38 -0800 Josh Triplett wrote:

> Francesco Poli wrote:
> > Or otherwise, povray upstream authors could be persuaded to
> > relicense in a DFSG-free manner, so that we would *gain* one new
> > interesting package for main, rather than *losing* one (that was
> > wrongly placed in main). ;-)
> 
> povray upstream actually *wants* to change the license to be open;
> they simply have the standard problem of being unable to get
> permission from all contributors.  Thus, the only way to relicense is
> to rewrite.

That's the typical difficulty in a relicensing effort.

That's the main reason why I always recommend people to think about
licensing issues as soon as possible and choose an appropriate (and
DFSG-free!) license in the early stages of a project (possibly before
starting to accept external contributions...).

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpmTCZ57HKSm.pgp
Description: PGP signature

Re: GR: GFDL Position Statement

[Jeremy Hankins]

Andy Teijelo Pérez <[EMAIL PROTECTED]> writes:

> I think that's exagerated. That's just a waste of time and
> resources. What else should be done at build time, make all KDE
> artists repaint and re-photograph all KDE wallpapers? I don't think
> art can always be treated the same way software is treated. Many music
> files are just recordings, and many graphic files don't have any
> source, they were just painted or photographed.  That kind of artwork
> is simply imposible to "modify from source". What's Debian going to
> do? Not include any kind of art which was not generated from some
> source? No photographs and no recordings? Just svgs and midis?

I agree that it (may be?) somewhat exaggerated: whether or not to
rebuild such stuff at build time should be decided based on technical
and policy reasons.  Is it feasible, and do the benefits (for example,
automatically ensuring source is available and buildable) outweigh the
costs?

But source (defined as the preferred form for modification -- the best
definition I've heard by far) should be available.  If you wanted to
tweak it or modify it, what would you need?  If the answer involves
starting from scratch, or from the raw image already available, a
separate source probably isn't necessary.  But it sounds like povray
source files would qualify as source, and therefore should be available.

> Regards, and sorry for my english.

Your english was quite good.  :)

-- 
Jeremy Hankins <[EMAIL PROTECTED]>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03

Re: GR: GFDL Position Statement

[Andy Teijelo Pérez]

El Jueves, 19 de Enero de 2006 5:31, Francesco Poli escribió:
> On Wed, 18 Jan 2006 17:32:48 +0100 Gerfried Fuchs wrote:
>
> I think it should be moved to contrib and ...

> ...graphics should be rerendered 
> from its actual source at build time.
I think that's exagerated. That's just a waste of time and resources. What 
else should be done at build time, make all KDE artists repaint and 
re-photograph all KDE wallpapers? I don't think art can always be treated the 
same way software is treated. Many music files are just recordings, and many 
graphic files don't have any source, they were just painted or photographed. 
That kind of artwork is simply imposible to "modify from source". What's 
Debian going to do? Not include any kind of art which was not generated from 
some source? No photographs and no recordings? Just svgs and midis?

Regards, and sorry for my english.
Andy.

Re: GR: GFDL Position Statement

[Josh Triplett]

Francesco Poli wrote:
> Or otherwise, povray upstream authors could be persuaded to relicense in
> a DFSG-free manner, so that we would *gain* one new interesting package
> for main, rather than *losing* one (that was wrongly placed in main).
> ;-)

povray upstream actually *wants* to change the license to be open; they
simply have the standard problem of being unable to get permission from
all contributors.  Thus, the only way to relicense is to rewrite.

- Josh Triplett


signature.asc
Description: OpenPGP digital signature

Re: GR: GFDL Position Statement

[Andrew M.A. Cater]

On Sat, Jan 21, 2006 at 10:41:26AM +0100, Francesco Poli wrote:
> On Sat, 21 Jan 2006 16:53:56 +1100 Andrew Donnellan wrote:
> 
> > I think that KPovModeler was developed with the intention that you
> > have POV-Ray installed. It will work fine without it, but it can only
> > save KPMs and POV files, and at the moment there is no other software
> > that can read it.
> 
> Probably true.
> 
> Or otherwise, povray upstream authors could be persuaded to relicense in
> a DFSG-free manner, so that we would *gain* one new interesting package
> for main, rather than *losing* one (that was wrongly placed in main).
> ;-)
> 
If you read the license files, they intend to change the licence with
the next release. Their problem is that they can't find all contributors
to release the current version, as far as I can see.

Povray will, eventually, get into main :)

Andy



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: GR: GFDL Position Statement

[Francesco Poli]

On Sat, 21 Jan 2006 16:53:56 +1100 Andrew Donnellan wrote:

> I think that KPovModeler was developed with the intention that you
> have POV-Ray installed. It will work fine without it, but it can only
> save KPMs and POV files, and at the moment there is no other software
> that can read it.

Probably true.

As usual, the key question is "does it provide a significant amount of
functionality without povray?".
That is to say, would it be of any significant use without povray?

It seems that playing around with wireframe previews of a scene that I
cannot render is not that useful...


So, if no other package currently in main can make any use of .kpm or
.pov files, I would say kpovmodeler should be moved to contrib...


Or otherwise, povray upstream authors could be persuaded to relicense in
a DFSG-free manner, so that we would *gain* one new interesting package
for main, rather than *losing* one (that was wrongly placed in main).
;-)

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp1ySk4qjo6y.pgp
Description: PGP signature

Re: GR: GFDL Position Statement

[Andrew Donnellan]

I think that KPovModeler was developed with the intention that you
have POV-Ray installed. It will work fine without it, but it can only
save KPMs and POV files, and at the moment there is no other software
that can read it.

andrew


On 1/21/06, Paul Wise <[EMAIL PROTECTED]> wrote:
> On Sat, 2006-01-21 at 00:31 +0100, Francesco Poli wrote:
>
> > I hope some volunteers to install it and check, so that a serious bug
> > can be filed against kpovmodeler, if necessary...
>
> Since I used to play with povray before becoming involved with debian.
>
> I've just installed kpovmodeler 3.5.0-3, and played with it a little.
>
> >  * kpovmodeler works perfectly without povray,
> Without povray, you lose the ability to render your scene in
> non-wireframe format (also you cannot preview textures). You can compose
> your scene fine if you don't mind the wireframe display.
>
> However, you can export scenes to the plain text povray format, which
> you could then manually translate to other formats. Also, the .kpm files
> it saves are gzipped XML that could possibly be converted for use in
> other ray-tracers if they implement enough features. .kpm files
> certainly look more useful for transfer to other ray-tracers than .pov,
> which has some scripting features. kpovmodeler can apparently
> import .pov files (I didn't test that though).
>
> >  * kpovmodeler doesn't work because it needs povray (which is not
> >installed), or
>
> False.
>
> >  * kpovmodeler doesn't seem to work, because I have no clue and don't
> >know how to actually use it...;-)
>
> It works fine and seems to implement support for quite a lot of povray's
> objects/textures/etc.
>
> --
> bye,
> pabs
>
> http://wiki.debian.org/PaulWise
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQBD0crJ5Sc9mGvjxCMRAnIpAJ9e7IsFPVlljyOp5Nt8qvmH6xQrcwCgzawC
> xo7+d7Lue8bRezAagKlv7FY=
> =QQFc
> -END PGP SIGNATURE-
>
>
>



--
Andrew Donnellan
http://andrewdonnellan.com
http://ajdlinux.blogspot.com
Jabber - [EMAIL PROTECTED]
---
Member of Linux Australia - http://linux.org.au
Debian user - http://debian.org
Get free rewards - http://ezyrewards.com/?id=23484
OpenNIC user - http://www.opennic.unrated.net

Re: GR: GFDL Position Statement

[Paul Wise]

On Sat, 2006-01-21 at 00:31 +0100, Francesco Poli wrote:

> I hope some volunteers to install it and check, so that a serious bug
> can be filed against kpovmodeler, if necessary...

Since I used to play with povray before becoming involved with debian.

I've just installed kpovmodeler 3.5.0-3, and played with it a little.

>  * kpovmodeler works perfectly without povray,

Without povray, you lose the ability to render your scene in
non-wireframe format (also you cannot preview textures). You can compose
your scene fine if you don't mind the wireframe display.

However, you can export scenes to the plain text povray format, which
you could then manually translate to other formats. Also, the .kpm files
it saves are gzipped XML that could possibly be converted for use in
other ray-tracers if they implement enough features. .kpm files
certainly look more useful for transfer to other ray-tracers than .pov,
which has some scripting features. kpovmodeler can apparently
import .pov files (I didn't test that though).

>  * kpovmodeler doesn't work because it needs povray (which is not
>installed), or

False.

>  * kpovmodeler doesn't seem to work, because I have no clue and don't
>know how to actually use it...;-)

It works fine and seems to implement support for quite a lot of povray's
objects/textures/etc.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: GR: GFDL Position Statement

[Francesco Poli]

On Thu, 19 Jan 2006 23:20:53 -0800 Josh Triplett wrote:

> Andrew Donnellan wrote:
> > Umm, Kpovmodeler isn't a renderer, it's a modelling program that
> > calls POVRay to actually render it. So KPovModeler should be in
> > contrib.
> 
> Hmmm.  The description certainly didn't give that indication, nor did
> the fact that povray was only in Suggests.
> 
> If it has no functionality without povray, I agree that it should be
> in contrib; if it can be useful without povray, the current situation
> is fine.

I've just did the same checks!
And I am as curious as you to find out whether this package should
Suggest or Recommend povray...

I hope some volunteers to install it and check, so that a serious bug
can be filed against kpovmodeler, if necessary...

Personally, I lack knowledge about povray and similar 3D renderers: as a
consequence I don't feel qualified to determine by myself whether

 * kpovmodeler works perfectly without povray,

 * kpovmodeler doesn't work because it needs povray (which is not
   installed), or
 
 * kpovmodeler doesn't seem to work, because I have no clue and don't
   know how to actually use it...;-)


So, in conclusion, any volunteers?

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpi44uJnQRzZ.pgp
Description: PGP signature

Re: GR: GFDL Position Statement

[Josh Triplett]

Andrew Donnellan wrote:
> Umm, Kpovmodeler isn't a renderer, it's a modelling program that calls
> POVRay to actually render it. So KPovModeler should be in contrib.

Hmmm.  The description certainly didn't give that indication, nor did
the fact that povray was only in Suggests.

If it has no functionality without povray, I agree that it should be in
contrib; if it can be useful without povray, the current situation is fine.

- Josh Triplett


signature.asc
Description: OpenPGP digital signature

Re: GR: GFDL Position Statement

[Andrew Donnellan]

Umm, Kpovmodeler isn't a renderer, it's a modelling program that calls
POVRay to actually render it. So KPovModeler should be in contrib.

Andrew

On 1/20/06, Josh Triplett <[EMAIL PROTECTED]> wrote:
> Francesco Poli wrote:
> > On Wed, 18 Jan 2006 17:32:48 +0100 Gerfried Fuchs wrote:
> >>* Anthony Towns  [2006-01-18 11:01]:
> >> 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? 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. But would producing them on build-time really raise the
> >>quality, moving xblast* to contrib? If this is done then please think
> >>of other packages with the same "problem", too.
> >
> > I think it should be moved to contrib and graphics should be rerendered
> > from its actual source at build time.
> > Consider this: if I wanted to fork xblast by modifying the graphics, I
> > would need the povray source (and the povray program, which is
> > unfortunately non-free).
> > Every attempt to change (for example) the camera positioning would from
> > hard to nearly impossible without povray source files. Hence, the
> > preferred form for making modification to xblast graphics is the
> > corresponding povray files (unless they are on their turn automatically
> > generated from something else...).
>
> One useful point here is that there exist Free renderers for POVRay
> files, such as KPovModeler.  I don't know to what extent they implement
> the features of POVRay.
>
> - Josh Triplett
>
>
>
>


--
Andrew Donnellan
http://andrewdonnellan.com
http://ajdlinux.blogspot.com
Jabber - [EMAIL PROTECTED]
---
Member of Linux Australia - http://linux.org.au
Debian user - http://debian.org
Get free rewards - http://ezyrewards.com/?id=23484
OpenNIC user - http://www.opennic.unrated.net

Re: GR: GFDL Position Statement

[Josh Triplett]

Francesco Poli wrote:
> On Wed, 18 Jan 2006 17:32:48 +0100 Gerfried Fuchs wrote:
>>* Anthony Towns  [2006-01-18 11:01]:
>> 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? 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. But would producing them on build-time really raise the
>>quality, moving xblast* to contrib? If this is done then please think
>>of other packages with the same "problem", too.
> 
> I think it should be moved to contrib and graphics should be rerendered
> from its actual source at build time.
> Consider this: if I wanted to fork xblast by modifying the graphics, I
> would need the povray source (and the povray program, which is
> unfortunately non-free).
> Every attempt to change (for example) the camera positioning would from
> hard to nearly impossible without povray source files. Hence, the
> preferred form for making modification to xblast graphics is the
> corresponding povray files (unless they are on their turn automatically
> generated from something else...). 

One useful point here is that there exist Free renderers for POVRay
files, such as KPovModeler.  I don't know to what extent they implement
the features of POVRay.

- Josh Triplett



signature.asc
Description: OpenPGP digital signature

Re: GR: GFDL Position Statement

[Francesco Poli]

On Wed, 18 Jan 2006 17:32:48 +0100 Gerfried Fuchs wrote:

[...]
> * Anthony Towns  [2006-01-18 11:01]:
> > There are currently two proposals in discussion on debian-vote
> > regarding a position statement on the GNU Free Documentation
> > License. The texts are available at
> > http://www.debian.org/vote/2006/vote_001, and discussion can be
> > found by following:
> 
>  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)

I think every work of authorship needs to be Free Software (at least to
be suitable for Debian main). 

> 
>  I can understand that the "source" for those things might be tricky,

Not so much.
The "preferred form for modification" definition of source code found in
the GPL is flexible enough to be applied to these cases as well.

> but often images are flattened photoshop files or (with non-free
> tools) rendered graphics, or music converted midi files.

See? It's not so difficult...

> 
>  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? 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. But would producing them on build-time really raise the
> quality, moving xblast* to contrib? If this is done then please think
> of other packages with the same "problem", too.

I think it should be moved to contrib and graphics should be rerendered
from its actual source at build time.
Consider this: if I wanted to fork xblast by modifying the graphics, I
would need the povray source (and the povray program, which is
unfortunately non-free).
Every attempt to change (for example) the camera positioning would from
hard to nearly impossible without povray source files. Hence, the
preferred form for making modification to xblast graphics is the
corresponding povray files (unless they are on their turn automatically
generated from something else...). 

> 
>  There is one last point that I really want to raise, though: I guess
>  we
> won't have to discuss that our very own beloved swirl logo has a
> non-free licence. If we are really going to kick out GFDL
> documentation we have to be at least as fair as kicking out our logo
> from the archive, too. Otherwise we will just be laughed at, and not
> fulfilling our own DFSG, where we won't accept a Debian specific
> licence in main.

Our beloved Debian logos are non-free.
The issue is being worked on (at least I hope it's still: very little
news has come to my ears recently...).
This is one of my pet issues and it's one of the most difficult: it
involves both copyright and trademark considerations...

> 
>  Please, think about it. Seriously. Don't let this turn into the next
> flamewar. If there had been past discussions on either of those
> topics, send me along links so I can read up on the reasonings for
> either discussion back then to understand it better.

There were, but now I haven't enough time to dig the archives...
Sorry.

-- 
:-(   This Universe is buggy! Where's the Creator's BTS?   ;-)
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpcpwjAtYFKh.pgp
Description: PGP signature

Re: GR: GFDL Position Statement

[Alexander Terekhov]

On 1/19/06, Glenn Maynard <[EMAIL PROTECTED]> wrote:
[...]
> > Yes, these are classic "must provide source to be free software" cases.
>
> Er, no they're not--"classic", that is.

And here comes Moglen. "Your Honor, all hardcopies of GPL'd works are
object code."

That will quickly become classic.

regards,
alexander.

When can we make some progress on the logo and trademarks? (was Re: GR: GFDL Position Statement

[MJ Ray]

Nathanael Nerode <[EMAIL PROTECTED]>
> This was going to be delayed until a proper trademark policy was in place.  
> -legal came up with a pretty solid plan for what we wanted for a trademark 
> policy; we wanted some review by a lawyer with some knowledge of trademark 
> law.  We haven't heard back since.  For *some reason*, although we've agreed 
> on all of this for *years*, it's stalled somewhere where we can't do anything 
> about it.

There was a draft trademark licence posted to the spi-trademark list
a few months ago. I've no idea of its status now. Not all current
licensed users of the "debian" mark would comply with it today IMO.
That might be part of the reason for delay.

-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: GR: GFDL Position Statement

[Glenn Maynard]

You might consider putting a line of blank space between quotes and
your reply, like everyone else does; it makes it easier to read.

On Wed, Jan 18, 2006 at 10:47:08PM -0500, Nathanael Nerode wrote:
> >  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.

Er, no they're not--"classic", that is.  Whether we want source for them
or not, it's an issue that's only been given much attention relatively
recently, so let's not start calling it "classic".  Programs are the
classic case.

-- 
Glenn Maynard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: GR: GFDL Position Statement

[Nathanael Nerode]

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 
"non-free".

> 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.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

When can we make some progress on the logo and trademarks? (was Re: GR: GFDL Position Statement

[Nathanael Nerode]

Gerfried Fuchs wrote:
>  There is one last point that I really want to raise, though: I guess we
> won't have to discuss that our very own beloved swirl logo has a
> non-free licence. If we are really going to kick out GFDL documentation
> we have to be at least as fair as kicking out our logo from the archive,
> too. Otherwise we will just be laughed at, and not fulfilling our own
> DFSG, where we won't accept a Debian specific licence in main.

We have discussed this.  -legal agreed that the license should be changed, and 
has proposed multiple alternative licenses.  The change to any of those 
licenses was agreed to by the logo's creator, and by the DPL and various 
other people.

This was going to be delayed until a proper trademark policy was in place.  
-legal came up with a pretty solid plan for what we wanted for a trademark 
policy; we wanted some review by a lawyer with some knowledge of trademark 
law.  We haven't heard back since.  For *some reason*, although we've agreed 
on all of this for *years*, it's stalled somewhere where we can't do anything 
about it.

I've Cc:ed this to the DPL in hopes of getting something kickstarted, or at 
least of getting a status report.  As far as I can tell, -legal has done its 
job, and only incomprehensible institutional delays are preventing this from 
actually happening.  Yes, it ticks me off a bit.

If a review of what we decided on is needed, I can whip one up.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: GR: GFDL Position Statement

[Gerfried Fuchs]

Hi!

 Sorry, sent this to the wrong list

- Forwarded message from Gerfried Fuchs <[EMAIL PROTECTED]> -

* Anthony Towns  [2006-01-18 11:01]:
> There are currently two proposals in discussion on debian-vote regarding
> a position statement on the GNU Free Documentation License. The texts
> are available at http://www.debian.org/vote/2006/vote_001, and discussion
> can be found by following:

 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)

 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.

 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? 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.
But would producing them on build-time really raise the quality, moving
xblast* to contrib? If this is done then please think of other packages
with the same "problem", too.

 There is one last point that I really want to raise, though: I guess we
won't have to discuss that our very own beloved swirl logo has a
non-free licence. If we are really going to kick out GFDL documentation
we have to be at least as fair as kicking out our logo from the archive,
too. Otherwise we will just be laughed at, and not fulfilling our own
DFSG, where we won't accept a Debian specific licence in main.

 Please, think about it. Seriously. Don't let this turn into the next
flamewar. If there had been past discussions on either of those topics,
send me along links so I can read up on the reasonings for either
discussion back then to understand it better.

- End forwarded message -

 So long,
Alfie
-- 
Nachdem es SuSE nun endlich geschafft hat, Linux so sehr zu verunstalten, daß
es schlechter als Windows ist, bootet es nun also sogar schon auf der Hardware
von Microsoft.
 -- realborg zu 


signature.asc
Description: Digital signature