Re: DFSG as Licence?
On 8/12/06, Weakish Jiang <[EMAIL PROTECTED]> wrote: Michelle Konzack wrote: > I was thinking to use the term: > > Licence: This software is under any Licence which complay > with the Debian Free Software Guidelines (DFSG). > > I am thinking, that this makes my standpoint more clear as telling > users: "This software is under GPL vXX". I fully aggree with the > Debian philosophy and this is why I stay with it (even if it steals > me sometimes th last nerv ;-) ) > > What do you think about it? > This is essentially saying 'This is public domain. No rights reserved.' because if anyone wants to just include your code in proprietary software they could just choose to use it under a DFSG-free license that says 'You can use it and modify it for anything.' If you're going to do this then you might want to consider PDing or the BSD license. -- Andrew Donnellan http://andrewdonnellan.com http://ajdlinux.blogspot.com Jabber - [EMAIL PROTECTED] GPG - hkp://subkeys.pgp.net 0x5D4C0C58 --- 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Saturday 12 August 2006 02:47 am, Thomas Bushnell BSG wrote: > Daniel Schepler <[EMAIL PROTECTED]> writes: > > According to the GPL, section 0: > > > > The act of running the Program is not restricted... > > > > And since dynamic linking is done at the time the program is run, this > > would appear to me to be what applies. In particular, it appears to me > > that you could satisfy the GPL and still dynamically link against a > > non-free library, and distribute both, by invoking the "mere aggregation" > > clause of section 2. > > This does not mean that anything that happens when you run the program > is not restricted. For example, the act of running GNU cp and sed is > not restricted, but that cann't possibly mean that the GPL gives you > carte blanche to go ahead and violate the GPL through use of cp and > sed. I'm afraid I don't see what your point is, here. Of course the GPL allowing me to use a GPL'd httpd to distribute non-free software doesn't automatically mean I would be blameless if I used it to distribute, say, a non-free program foo linked against libmad. The point, I think, is that distributing such a thing as the non-free binary of foo along with a package of a shared libmad is essentially the same as distributing a binary with libmad linked in statically, which is clearly disallowed. Both are just different ways of distributing the combined work of foo + libmad. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Daniel Schepler <[EMAIL PROTECTED]> writes: > On Saturday 12 August 2006 02:47 am, Thomas Bushnell BSG wrote: >> Daniel Schepler <[EMAIL PROTECTED]> writes: >> > According to the GPL, section 0: >> > >> > The act of running the Program is not restricted... >> > >> > And since dynamic linking is done at the time the program is run, this >> > would appear to me to be what applies. In particular, it appears to me >> > that you could satisfy the GPL and still dynamically link against a >> > non-free library, and distribute both, by invoking the "mere aggregation" >> > clause of section 2. >> >> This does not mean that anything that happens when you run the program >> is not restricted. For example, the act of running GNU cp and sed is >> not restricted, but that cann't possibly mean that the GPL gives you >> carte blanche to go ahead and violate the GPL through use of cp and >> sed. > > I'm afraid I don't see what your point is, here. Of course the GPL > allowing me to use a GPL'd httpd to distribute non-free software > doesn't automatically mean I would be blameless if I used it to > distribute, say, a non-free program foo linked against libmad. The > point, I think, is that distributing such a thing as the non-free > binary of foo along with a package of a shared libmad is essentially > the same as distributing a binary with libmad linked in statically, > which is clearly disallowed. Both are just different ways of > distributing the combined work of foo + libmad. Yes, I agree completely. This seems to be the exact opposite of what you said in the quoted text above. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Saturday 12 August 2006 14:34 pm, you wrote: > Daniel Schepler <[EMAIL PROTECTED]> writes: > > On Saturday 12 August 2006 02:47 am, Thomas Bushnell BSG wrote: > >> Daniel Schepler <[EMAIL PROTECTED]> writes: > >> > According to the GPL, section 0: > >> > > >> > The act of running the Program is not restricted... > >> > > >> > And since dynamic linking is done at the time the program is run, this > >> > would appear to me to be what applies. In particular, it appears to > >> > me that you could satisfy the GPL and still dynamically link against a > >> > non-free library, and distribute both, by invoking the "mere > >> > aggregation" clause of section 2. > >> > >> This does not mean that anything that happens when you run the program > >> is not restricted. For example, the act of running GNU cp and sed is > >> not restricted, but that cann't possibly mean that the GPL gives you > >> carte blanche to go ahead and violate the GPL through use of cp and > >> sed. > > > > I'm afraid I don't see what your point is, here. Of course the GPL > > allowing me to use a GPL'd httpd to distribute non-free software > > doesn't automatically mean I would be blameless if I used it to > > distribute, say, a non-free program foo linked against libmad. The > > point, I think, is that distributing such a thing as the non-free > > binary of foo along with a package of a shared libmad is essentially > > the same as distributing a binary with libmad linked in statically, > > which is clearly disallowed. Both are just different ways of > > distributing the combined work of foo + libmad. > > Yes, I agree completely. This seems to be the exact opposite of what > you said in the quoted text above. Well, yes, the original text was part of a question I asked on how the GPL was to be interpreted to cover dynamic linking, to which I later found a reasonable answer myself which I repeated in the later mail. (The hypothetical example which really convinced me was of EvilCo trying to circumvent the GPL by distributing their program foo as separate downloads of foo.o and libgpldlib.a and asking users to link the program themselves -- which is more obviously invalid.) -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG as Licence?
On Fri, 7 Jul 2006 13:36:40 +0200 Michelle Konzack wrote: [...] > I was thinking to use the term: > > Licence: This software is under any Licence which complay > with the Debian Free Software Guidelines (DFSG). > [...] > What do you think about it? There are some major problems with such a "mutant" license. First of all, and most importantly, who is going to decide whether a particular license complies with the DFSG? For the purpose of inclusion of a work into Debian, this task is accomplished by the packager, possibly with the help of debian-legal as an advisory group, and ultimately by the ftp-masters (whose decisions could be overruled by the Debian Project as a whole via GR)[1]. [1] anyone more knowledgeable than me about Debian Constitution and Debian Policy is encouraged to correct me, if I'm wrong... But who is going to decide whether a particular license complies with DFSG for the purpose of complying with your "mutant" license? What if I do something with your work and you sue me for copyright infringement? I claim that I was doing something allowed by license XYZ which I think "complies with the DFSG". You claim that license XYZ "does not comply with the DFSG". A court has to decide who is right and who is wrong, but no court is used to determine whether a license "complies with the DFSG". Second, it's not very clear what "complying with the DFSG" means for a *license*. The DFSG are guidelines to determine if a *work* is or isn't Free Software (according to Debian standards). The license plays an important role in making a work Free, but it's not the only thing to be taken into account (availability of source code, actively enforced patents, and other details are to be considered too). Third, your "mutant" license is a contorted way to more or less effectively release a work under in a all-permissive manner. Let's see why: the DFSG never pose upper limits to granted permissions, they only pose lower limits. Hence a license permissive enough "complies with the DFSG" for sure. I, as a licensee, would obviously choose the most permissive license I can, among a set of proposed ones. I could for example choose the Expat license[2] (or even some more permissive one): it definitely "complies with the DFSG" (I think there are no reasonable doubts about it). See? At the end of the day, the result of your "mutant" license is basically the same as having released the work under the Expat license[2]. [2] http://www.jclark.com/xml/copying.txt So, to summarize, I recommend you against adopting your proposed "mutant" license. I suggest you instead release your works in a clearly DFSG-free manner by adopting a suitable license. If you want to be (almost) all-permissive, a good choice is the Expat license: it's simple, short, and compatible with everything else. HTH, IANAL, IANADD. -- But it is also tradition that times *must* and always do change, my friend. -- from _Coming to America_ . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgptwX5oJNwhz.pgp Description: PGP signature
Re: Creative Commons 3.0 Public draft -- news and questions
On Thu, 10 Aug 2006 11:26:13 -0400 Evan Prodromou wrote:
> So, I have big news and a big question.
>
> Big news
>
>
> Creative Commons has announced the public draft of the next version of
> their license suite:
>
> http://creativecommons.org/weblog/entry/6017
[...]
> http://evan.prodromou.name/Debian_Creative_Commons_Workgroup_report
Thanks for the URLs.
I will look at the license as soon as I can...
>
> Big question
>
[...]
> The big question for debian-legal is whether the new license draft is
> compatible with the DFSG. I hope that debian-legal subscribers will
> look over the new license carefully and post opinions here or on the
> cc-licenses mailing list.
I hope I can manage to analyze the rest of the license in the next few
days, but it won't be easy... Too many new drafts to review in this
August! :-(
>
> Creative Commons met almost all of the Workgroup's recommendations,
> and after a lot of review we've agreed that the works licensed solely
> under the CCPL 3.0 draft would be Free... with one exception.
Ouch! :-/
>
> The exception is that the CCPL 3.0 has an anti-DRM (or anti-TPM)
> provision that doesn't allow distribution with copy protection
> features. The traditional wisdom is that prohibiting use of TPM puts
> an undue restriction on developers and doesn't let them experiment
> with TPM-required platforms. (Some console game systems, for example,
> require TPM for a program to run on the system.) Restricting the
> systems that a program can be ported to is incompatible with DFSG#3.
Right.
>
> One way to make anti-TPM clauses compatible with the DFSG is to allow
> "parallel distribution" -- that is, a developer can create a TPM'd
> version of a work as long as they also make available a cleartext one
> that people can modify, copy, etc. This lets developers experiment,
> but also lets downstream users exercise their rights, too.
Exactly.
>
> We'd originally negotiated a parallel distribution proviso, but the
> extra clause was later removed.
By reading the announcement I learn that such removal was due to strong
opposition from other interested parties, rather than the belief that it
was unneeded (being implicitly allowed by the wording of the clause or
something similar). This seems to mean that Creative Commons interprets
the clause as forbidding parallel distribution of DRM-encumbered and
DRM-unencumbered copies... Not a good start. :-(
> So, the CCPL 3.0 license draft has
> this language for DRM restrictions:
>
> You may not impose any technological measures on the Work that
> restrict the ability of a recipient of the Work from You to
> exercise the rights granted to them under the License.
>
> Since we negotiated the license changes, Debian has had a GR to allow
> works licensed under the GFDL into main. The GFDL has the following
> anti-DRM clause:
>
> You may not use technical measures to obstruct or control the
> reading or further copying of the copies you make or
> distribute.
>
[...]
> The Debian Creative Commons Workgroup couldn't come to a clear
> conclusion on the matter, and it's not 100% clear what the effect of
> GR 2006-01 is on Debian as a whole.
>
> In my personal opinion, the question boils down to these points:
>
> 1. Was GR 2006-01 an exception to the DFSG, or a clarification of
> our principles?
It was a single (absurd and mistaken, IMO) decision on the acceptability
of works under a single license.
Let's not extend the mistake to other cases or other licenses. Maybe
someday the Debian Project will fix this mistake, let's not make it
worse than it already is.
> 2. If it was a clarification, does this mean that anti-DRM
> clauses like the one in the FDL are compatible with the DFSG?
If you take GR-2006-001 as a clarification of our principles, you say,
basically, that *any* issue that can be found in the GFDL (besides
clauses that allow unmodifiable & unremovable parts) does comply with
the DFSG. That's a slippery slope ("if we accept that restriction, why
don't we accept that other one, which is similar?") and would quickly
destroy the meaning of the DFSG. Debian should not become another OSI
(which approves and certifies almost any license that passes by)!
> 3. If so, is the anti-DRM clause in the CCPL 3.0 draft similar
> enough to the FDL's anti-DRM clause for us to consider it
> compatible with the DFSG?
Rather than comparing CC anti-DRM clause with the GFDL one, which is
clearly non-free[1], I would like to compare it with the GPLv3draft2
one, which gave me the impression of implicitly allowing parallel
distribution.
[1] regardless of what the GR states: a GR cannot magically change a
third-party license, nor change the DFSG, unless it requires a 3:1
supermajority, which wasn't required by the winning option
Here we go.
This is the CCv3draft0808060 anti-DRM clause, as quoted by Evan:
| You may not imp
Re: Creative Commons 3.0 Public draft -- news and questions
On Sat, 2006-12-08 at 23:05 +0200, Francesco Poli wrote: > Not a good start. :-( Let me take this opportunity to repeat my plea that people who have feelings about this issue join the cc-licenses mailing list and post messages on the topic. http://lists.ibiblio.org/mailman/listinfo/cc-licenses I've been trying to convey ideas from Debian, but it really helps if you can state your ideas in your own voice. ~Evan -- Evan Prodromou <[EMAIL PROTECTED]> The Debian Project (http://www.debian.org/) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
