On Sat, Feb 22, 2014 at 05:24:07PM +0100, Gerfried Fuchs wrote: > * Bas Wijnen <wijnen@debian.org> [2014-02-22 16:39:06 CET]: > > On Sat, Feb 22, 2014 at 04:01:59PM +0100, Gerfried Fuchs wrote: > > > The "preferred form for modification" phrase comes from the GPL, and I > > > don't see redeclipse covered under the GPL? > > > > > > Can we please not apply GPL terms to non-GPL work, pretty please? > > > > The reason everybody does that, is that it seems to be the only place > > where "source code" is defined. And it is a reasonable definition, IMO, > > regardless of what license is used. Do you have a more appropriate > > definition for non-GPL code? > > I don't deny that it sounds like a reasonable definition, but insisting > with exactly that wording is not very constructive. I disagree. > Let's take the redeclipse case again, and a "provided 'as-is'" is clear > to me, insisting on anything else than what's-there-is-there is ignoring > its license. Well, yes, but there's nothing wrong with that. As I wrote, the question is not "are we in compliance with their license?", but rather "is their distribution in compliance with the DFSG?" If I look for example at beneath a steel sky, I see only generated files and a complicated instruction for how to regenerate one of them (which doesn't even seem to be the most important). Also, that instruction includes "download these binary files from elsewhere". There is no editor for the format. I cannot see how this fits in main, even if I try really hard. But, to come back to this discussion, its license says it's all fine. We have the right to modify and redistribute it in this form (and in any other form, but we don't have other forms). My point is that its license is irrelevant for our discussion. So yes, I ignore it. > The appropriate definition for the code at hand is its own license, > not one that "is a reasonable definition". The appropriate definition would be the one from the DFSG. Which unfortunately doesn't exist. The one from the GPL is the only candidate that we can use, which is why I use it. As I wrote, I don't mind using a different definition in principle, but I much prefer "reasonable" over "what the authors say". With upstream, authors may not share our ideas and what they say will not always fit our goals. The separation between main and the rest is not based on upstream's rules; it's our own rules that count here. > Also, we aren't even talking of "code". It is a fine line between code and art. Some say code is art, and I see their point. Some art is obviously code. I think it is a good idea to require source for art, just as we do for code. > I myself am not a music or graphic contributor anywhere and don't > believe I can useful define for them what they might consider source. True. I make some art, but I don't claim to be good at it. It would probably be best if we leave the definition of source to the artists. Do we have any on this list, who would like to share their opinion? I didn't read the page from the Wesnoth artist yet, but that is certainly a valuable opinion in that respect. Thanks, Bas
Attachment:
signature.asc
Description: Digital signature