Re: Design Science License (in freevo)
Francesco Poli [EMAIL PROTECTED] wrote: On Wed, 16 Jan 2008 14:47:58 + (GMT) MJ Ray wrote: Francesco Poli [EMAIL PROTECTED] wrote: Only if those graphics files are directly loadable from their Source form. [...] =20 Otherwise, you make a modified work and the meanings of Source Data, Author and Object Form change, as far as I can see. Silly, but helpful. [...] If, on the other hand, you make a dummy modification to an Object Form just to claim that it is Source Data, then I think that you are cheating with the license... For instance, I would not directly modify a PNG image compiled from SVG, unless I really decide to go on maintaining the image in PNG format. I don't see things like svg2png as a dummy modification or as cheating. Hope that explains, -- 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: Design Science License (in freevo)
On Thu, 17 Jan 2008 11:42:11 + (GMT) MJ Ray wrote: Francesco Poli [EMAIL PROTECTED] wrote: [...] If, on the other hand, you make a dummy modification to an Object Form just to claim that it is Source Data, then I think that you are cheating with the license... For instance, I would not directly modify a PNG image compiled from SVG, unless I really decide to go on maintaining the image in PNG format. I don't see things like svg2png as a dummy modification or as cheating. If you perform an automatic format conversion, then you are compiling (i.e.: generating Object Form from Source Data), not changing the Source Data form. Unless you perform the conversion once, and then go on modifying the work directly in the new format, I mean. It's just like gcc -S: if, after translating your C program into assembly code, you go on modifying it directly in assembly, then the source for the modified program is really in assembly language. On the other hand, if you just perform the automatic translation before distributing (but you intend to restart from C code, as soon as a modification is needed), then the source is still C code. As usual: IANAL, TINLA, IANADD, TINASOTODP. -- http://frx.netsons.org/progs/scripts/refresh-pubring.html New! Version 0.6 available! What? See for yourself! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpNSbJPp0VK5.pgp Description: PGP signature
Re: Design Science License (in freevo)
Francesco Poli [EMAIL PROTECTED] wrote: On Tue, 15 Jan 2008 16:29:15 + (GMT) MJ Ray wrote: It seems impractical, but the definition of Object Form and the terms for modified versions make it look to me like it's avoidable by loading the graphic at run-time instead of compiling it into an executable. Only if those graphics files are directly loadable from their Source form. [...] Otherwise, you make a modified work and the meanings of Source Data, Author and Object Form change, as far as I can see. Silly, but helpful. That is to say, you think that it complies with the DFSG, even though it's impractical. Did I get it right? Is this what you mean? Yes. -- 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: Design Science License (in freevo)
On Wed, 16 Jan 2008 14:47:58 + (GMT) MJ Ray wrote: Francesco Poli [EMAIL PROTECTED] wrote: On Tue, 15 Jan 2008 16:29:15 + (GMT) MJ Ray wrote: It seems impractical, but the definition of Object Form and the terms for modified versions make it look to me like it's avoidable by loading the graphic at run-time instead of compiling it into an executable. Only if those graphics files are directly loadable from their Source form. [...] Otherwise, you make a modified work and the meanings of Source Data, Author and Object Form change, as far as I can see. Silly, but helpful. If, for any good reason, you decide to go on modifying a work in a form different from the original Source Data form, then the Source Data for the modified work is really the new form. This is not silly, and it's exactly the way the GPL definition of source code is intended to act, AFAICT. This is one of the aspects where the DSL is very similar to the GNU GPL. I am under the impression that this is not the case you are referring to. If, on the other hand, you make a dummy modification to an Object Form just to claim that it is Source Data, then I think that you are cheating with the license... For instance, I would not directly modify a PNG image compiled from SVG, unless I really decide to go on maintaining the image in PNG format. I don't think you are proposing to cheat the license, are you? Mmmmh, it seems that I am left without a convincing interpretation of your sentence: I give up, could you please elaborate? -- http://frx.netsons.org/progs/scripts/refresh-pubring.html New! Version 0.6 available! What? See for yourself! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp7NbLGXZvyr.pgp Description: PGP signature
Re: Design Science License (in freevo)
Francesco Poli [EMAIL PROTECTED] wrote: I see one possible issue with this license: clause 3(a) states | (a) The Source Data is included in the same distribution, distributed | under the terms of this License; or while the other two options are non-free (just as in the GNU GPL). Option (a) seems to force distributors of the Object Form to *include* Source Data, rather than to *accompany* it with Source Data (compare with GNU GPL v2, clause 3a). Does this mean that Source Data for DSL'ed works *must* be shipped in Debian binary packages, as well as in Debian source packages? If this is the case, does this restriction comply with the DFSG? It sounds really unpractical at best. It seems impractical, but the definition of Object Form and the terms for modified versions make it look to me like it's avoidable by loading the graphic at run-time instead of compiling it into an executable. Is that good enough? I think so. Hope that helps, -- 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: Design Science License (in freevo)
On Tue, 15 Jan 2008 16:29:15 + (GMT) MJ Ray wrote: Francesco Poli [EMAIL PROTECTED] wrote: I see one possible issue with this license: clause 3(a) states | (a) The Source Data is included in the same distribution, distributed | under the terms of this License; or while the other two options are non-free (just as in the GNU GPL). Option (a) seems to force distributors of the Object Form to *include* Source Data, rather than to *accompany* it with Source Data (compare with GNU GPL v2, clause 3a). Does this mean that Source Data for DSL'ed works *must* be shipped in Debian binary packages, as well as in Debian source packages? If this is the case, does this restriction comply with the DFSG? It sounds really unpractical at best. It seems impractical, but the definition of Object Form and the terms for modified versions make it look to me like it's avoidable by loading the graphic at run-time instead of compiling it into an executable. Only if those graphics files are directly loadable from their Source form. I don't know the details for the present case, but AFAICT some formats are not easily loadable from application programs. Or at least, modifying the program to do that could be impractical. As a consequence, we would have simply moved the impracticality from the packaging effort to the programming/maintaining effort... Is that good enough? I think so. That is to say, you think that it complies with the DFSG, even though it's impractical. Did I get it right? Is this what you mean? I'm instead concerned that this restriction could fail to meet the DFSG. I mean: suppose that Source Data for the graphics file is in a form which is 50 times longer than the Object Form. Making the source available (as the GNU GPL would require) is the right thing to do: otherwise recipients cannot fully exercise their freedoms. But being compelled to *include* source in the binary package seems too much. Is it a DFSG-free restriction? Same disclaimers as usual: IANAL, TINLA, IANADD, TINASOTODP. -- http://frx.netsons.org/progs/scripts/refresh-pubring.html New! Version 0.6 available! What? See for yourself! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpRlLNKYOgan.pgp Description: PGP signature
Re: Design Science License (in freevo)
A Mennucc [EMAIL PROTECTED] writes: Some artwork is covered by the attached Design Science License. Thank you for including the license text in full for examination. It appears to be identical to the text published at (not published *by*, note!) the Free Software Foundation on their site URL:http://www.fsf.org/licensing/licenses/dsl.html: a copyleft largely modelled on the terms of the GNU GPLv2. Is it fine to include that stuff in the package and upload? (I would say yes, but you may have a more informed opinion). The FSF recommend against its use URL:http://www.fsf.org/licensing/licenses/, but only on the basis of it being incompatible with the GNU GPL and GNU FDL. Now that I've read the whole license, I would say works licensed under these terms are DFSG-free. -- \ I don't know anything about music. In my line you don't have | `\ to. -- Elvis Aaron Presley (1935-1977) | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Design Science License (in freevo)
On Thu, 10 Jan 2008 22:18:00 +0100 A Mennucc wrote: hi d-legal, Hi! :) [...] Some artwork is covered by the attached Design Science License. Is it fine to include that stuff in the package and upload? (I would say yes, but you may have a more informed opinion). The DSL has already been discussed on d-l, back in 2000: http://lists.debian.org/debian-legal/2000/07/msg00079.html No DFSG-freeness issues were found at the time. Unfortunately the license text was not fully quoted in that thread and the cited URL does not seem to be valid any longer. As a consequence, it's really hard to know if the license text discussed in that past thread is identical to the one we are discussing now, or differs. This is one of the primary reasons behind the recommendation to always fully quote the license text in a license analysis thread! Thanks for doing so! Oh well, back to the current discussion, then. I see one possible issue with this license: clause 3(a) states | (a) The Source Data is included in the same distribution, distributed | under the terms of this License; or while the other two options are non-free (just as in the GNU GPL). Option (a) seems to force distributors of the Object Form to *include* Source Data, rather than to *accompany* it with Source Data (compare with GNU GPL v2, clause 3a). Does this mean that Source Data for DSL'ed works *must* be shipped in Debian binary packages, as well as in Debian source packages? If this is the case, does this restriction comply with the DFSG? It sounds really unpractical at best. My standardized disclaimers: IANAL, TINLA, IANADD, TINASOTODP. -- http://frx.netsons.org/progs/scripts/refresh-pubring.html New! Version 0.6 available! What? See for yourself! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgptQzPu0oxGO.pgp Description: PGP signature
Re: Design Science License (in freevo)
On Thu, Jan 10, 2008 at 10:18:00PM +0100, A Mennucc wrote: hi d-legal, I am taking care of the (forthcoming) freevo packages. Some artwork is covered by the attached Design Science License. Is it fine to include that stuff in the package and upload? (I would say yes, but you may have a more informed opinion). Looks fine to me. John (TINLA) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
