On 27 April 2014 11:05, Solal <solal.rast...@me.com> wrote: > The two documents are incompatible, and the DFSG is very laxist and do > not protects completely freedom. FSDG protects freedoms : it resolves > issues : proprietary software is totally banned, patents are prohibited, > trademarks limited, etc. >
Which freedoms does DFSG not protect? "9. License Must Not Contaminate Other Software" IMHO is a very powerful and required statement. Just like it insure freedom of each individual software package it also, insures that all freedoms are preserved when combined together into a distribution. FSDG on the other hand, takes proactive steps to violate that statement by contaminating other (non-free) software. Some may even say that it's removing freedom of choice. "patents are prohibited" -> FSDG explicitly acknowledges patents but does not require any actions to be taken. Not sure what you mean by "patents are prohibited" either. I as an individual cannot "prohibit all patents" given the current legal frameworks around the world. --- Therefore, we don't generally ask free system distributions to exclude software because of possible threats from patents. --- FSDG trademark policy seems to be inline with DFSG one. And Debian does pro-actively protect its users from trademark policy infringements when those restrict ones freedoms -> see Ice weasel/Firefox > GFDL is free, because Invariant Sections are free if used in opinions > (nobody want peoples modify their opinion in a text). The GFDL prohibit > the use of Invariant Sections in technic texts. > I can't find such statement in the GFDL 1.3 official text at https://gnu.org/licenses/fdl.html Can you please provide citation for this claim? Imho emacs documentation is a technical text and it did contain invariant sections. > The only case where a software respects FSD but not DFSG is good. That > can be a software which prohibit the use of proprietary software in > aggregates. > This is good, totally ethical, and I think a license should do that for > protect uers from proprietary. > I'm not sure how individual software can respect FSDG, given that FSDG applies to complete distributions, not individual software packages. Which is another point in favour of DFSG - it defines what "free" means for individual piece of software, unlike FSDG which merely by large refers to a large list of licenses. > The cases where a software respects DFSG but not respects FSD are bad. > For example, a software which prohibit the distribution of modified > versions respects DFSG if it authorize patch files. > But it's unethical. > > In some years, the patch will maybe be incompatible with the new version. > The Debian project authorize that (but encourage to do not do that, but > that's not suffiscient). > FSGD allows any software from "free" license lists, of which Q Public License https://www.gnu.org/licenses/license-list.html#QPL is marked as free and acceptable. QPL only allows patch form modifications. The example you give is not correct. Since DFSG has very limited scope - define what acceptable licensing terms are for a software package, i was expecting more of a well-used license which happens to _not_ satisfy DFSG but not FSDG. Of the top of my head, I can't think of any obvious examples. > The Debian project authorize too certain licenses which is too vague for > talk about free (the Artistic License 1.0, for example). > Artistic License 1.0 is very old, the Clarified and 2.0 versions are free, both by DFSG and FSDG. And even Artistic License 1.0 is considered free by FSDG if it's part of the disjunctive license of Perl. Note that in dfsg text when "Artistic" license example is given, it does really mean the perl artistic variant in-line with FSDG. The way I read Artistic License 1.0, it does not appear vague to me. FSF claims that it is vague, yet OSI has approved it as free. In practice there is no problem with Artistic License 1.0 as no negative case-law has resulted from it to date. Are you simply quoting FSF here? > The DFSG is really bad, too laxist and useless. > It's a guideline, and a guideline for an individual software package. All guidelines are laxist and useless since they are not clear-cut sets of algorithms or rules, unlike for example standards. I still don't understand what you mean by "really bad" - it appears to be written in correct English with good grammar to me. And I've refuted all examples that you have provided above. It appears that Debian would satisfy all your needs as a free distribution. Regards, Dimitri. > Le 26/04/2014 22:13, Dimitri John Ledkov a écrit : >> On 25 Apr 2014 15:15, "Solal" <solal.rast...@me.com> wrote: >>> >>> Why not just take the Free Software Definition[0] instead lose a lot of >>> time in specific guidelines. >>> I think use the Free System Distribution Guidelines published by the >>> FSF[1] is the best way. Use the FSDG instead of the DFSG will : >>> -Be more efficient instead of lose a lot of time in the DFSG. >>> -Be sure to be in the 100% free GNU/Linux distros list of the FSF. >>> >> >> One is not a superset of the other. The two documents are incompatible. As >> one example each way - In debian, we consider GFDL license with invariant >> texts to be non-free. Whilst FSDG, disqualifies providing compatible >> archives of non-free software. >> >> How are you measuring efficiency / loosing time here? Given the non-trivial >> cost of switch and more restrictive terms of FSDG would require more audit >> and ongoing work. >> >> The FSF 100% free list is not a deal-breaker pretty much for everyone. >> >> What specific aspects of FSDG do you find to not be met by DFSG? >> >> I am not sure if DFSG predates FSDG or not, but DFSG was used as a basis >> for free software definition as published by Opens Source Initiative (OSI) >> thus many organisations, including the Linux Foundation, do recognise >> Debian as a free operating system. >> >> To answer the topic of your email - yes by large DFSG has been extremely >> useful (especially in the early days of pleora of self-written licenses) to >> current times with established license terms and non-trivial >> compatibilities between them. It is concise and easy to read and >> understand. Widely accepted by everyone else. Switching to a different >> metric will not magically resolved all licensin issues (patents, trademark >> violations, copyright assignments etc.) nor make upstream tarballs to be >> magically correct and acceptable. >> >> Regards, >> >> Dimitri. >> > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/535cd661.9080...@me.com > -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canbhluggx_fwatt6ecsvdxipoiubrzespiimnqckcxgty3v...@mail.gmail.com
