Re: DFSG as Licence?
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? IMO, there is something wrong with your statement. The point is that it's very difficult to determine whether a license complies with DFSG. Suppose that someone created a new license which is against DFSG, but s/he can still disclaim it complies with DFSG. You cannot decide that hir license is against the DFSG, nor do the Debian community. If the Debian community say a license is against DFSG, they only express their opinion. And according to their opinion, they won't add any software solely under this license to Debian main. That's what they can do. But they cannot enforce other people to agree with their opinion, nor can they enforce others to obey their decision. Everyone may have their different opinions, the Debian community never want to impose their opinion on others. The decision made by the Debian community only applies to the Debian Project. Even if you take this matter to court, since the DFSG is a publicly stated policy, rather than a legal statement, the case will become very complex. Therefore, IMO, you should not use a statement like any Licence which complay with the DFSG. The licenses below are currently found in Debian main: GNU General Public License (common) GNU Lesser General Public License (common) GNU Library General Public License (common) Modified BSD License (common) Perl Artistic license (common) Apache License MIT/X11-style licenses zlib-style licenses LaTeX Project Public License Python Software Foundation License Ruby's License PHP License W3C Software Notice and License OpenSSL License Sleepycat License Common UNIX Printing System License Agreement vhf Public License No problem Bugroff license You can choose one or more license from them. (Personally, I think use Modified BSD is enough, because it is compatible with many licenses listed above.) If someone want to use other licenses which is not compatible with any license listed above to distribute your software, the license probably doesn't comply with the DFSG. Of course, it is possible that the license they want to use does comply with the DFSG. However, I think few people will need to use such licenses. If they do, they always can ask for your permission. -- 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: 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 impose any technological measures on the Work that | restrict the
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]
