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

Re: source for artwork



Hi,

On Sat, Feb 22, 2014 at 03:28:37PM +0100, Martin Erik Werner wrote:
> > > I allege that the developers of Red Eclipse don't retain higher
> > > quality artwork deliberately and that they share everything according
> > > to their license agreement.
> > 
> > I agree.

I think this is really the important part.  In some cases, even though
things were originally generated, the generated files become the source.
This is a very subjective thing, but the extremes are clear: if upstream
hides (doesn't distribute) the source, but uses it when they want to
make changes themselves, the generated files are certainly not source.
If they made many manual changes to the art, which would be more work to
redo than recreating the source, and then threw the source away _for
that reason_, it's quite clear that the source isn't the source anymore.

But on the other hand, if they made some changes, _with the intent of
bypassing license requirements_, and then claim to have thrown the
source away, just so they don't need to publish it, that's a different
situation.

> The Red Eclipse project itself does treat these "secondary sources" as
> the preferred form, partly due to the fact that it might have been the
> only format that they could get hold of, partly due to the inconvenient
> size of carrying around the original sources for them, and partly due to
> the fact that for much of the content, it is quite often the case that
> it will never need to be modified at that level, it will either be
> tweaked within the limits of the generated format, or completely
> replaced.

All my examples are very extreme, and this case seems to be somewhere
in the middle.  But if the above is true (which I have no trouble
believing), IMO it's quite close to the "good" extreme case and so the
generated files are the source.

> > > I therefore ask all team members to voice their opinion and to support
> > > my proposal to move Red Eclipse to the main section of the Debian
> > > archive, since it consists of DFSG free software and artwork.
> > 
> > I agree, but (just to be clear) not because I believe that debian should 
> > allow the non-preferred form of modification (I certainly do not believe 
> > this) but rather because, as far as I can tell, this is the preferred 
> > form of modification.

+1

> But I also know that several game packages in Debian does a very nice
> job of keeping proper sources, and hence, it's not an unpractical goal to
> strive for. (It's just something that I have not felt being worthwhile
> doing for Red Eclipse in particular.)

It depends on the situation.  If you have a package, where the copyright
holder has placed the game in the public domain or similar, but even
they don't have the sources anymore, it may be impossible to get them.

I'm particularly thinking of Scummvm games like beneath a steel sky
here; there's not even an editor for this (compiled) format.  I haven't
seen a definition of the format either (except the scummvm source, which
I didn't read; there might well be documentation in there).

> I myself is somewhat torn about the whole thing, since I can both see
> the "noble goal" and "limited usefulness" sides of the whole thing. But
> looking at it from a Debian perspective, I feel that maybe Debian should
> rather be taking the "noble goal" standpoint here?

Debian has a solution to this dilemma, which is called contrib and
non-free.  If you believe that something is not suitable for main, you
don't need to limit the usefulness by omitting it entirely; instead, you
can put it in there.

People who don't have contrib and non-free in their sources.list will be
happy if they _don't_ get to use these programs.  If they wanted such
programs, they wouldn't have left contrib and non-free out.

And obviously, people who do use contrib and non-free don't really care
which section it is in; they are happy that they get to use it.

That being said, from what I read here I think that redeclipse should be
in main.

Thanks,
Bas

Attachment: signature.asc
Description: Digital signature


Reply to: