Re: motion to take action on the unhappy GNU FDL issue
Well, listening to Georg Greve it sounded like the FSF wanted an official statement from Debian regarding the problems with non-removability of invariant sections. In my very humble opinion, Debian should try giving them that before taking (what would appear to be) the more hostile actions suggested by you. Sunnan
Debian Free Software License?
Hi fellows, is there anything like a Debian Free Software License? A license that is modelled after the DFSG? For me as free software developer, that would be a nice to have. I couldn't find a discussion about something similar in the list archives. Is this worth a discussion? Regarding the latest FDL discussion, would it be feasible to create a Debian Free Documentation License? Questions over questions and thanks for your time, Joerg -- Joerg joergland Wendland GPG: 51CF8417 FP: 79C0 7671 AFC7 315E 657A F318 57A3 7FBD 51CF 8417 pgpqvKt8zlRq6.pgp Description: PGP signature
Re: Debian Free Software License?
On Thu, Apr 17, 2003 at 02:47:20PM +0200, Joerg Wendland wrote: Hi fellows, is there anything like a Debian Free Software License? A license that is modelled after the DFSG? For me as free software developer, that would be a nice to have. I couldn't find a discussion about something similar in the list archives. Is this worth a discussion? There are a sufficient number and scope of widely examined Free Software licenses that we do not need to add to the confusion. Regarding the latest FDL discussion, would it be feasible to create a Debian Free Documentation License? It has been suggested that we write a license that we believe is unambiguously Free. It has also been suggested that we take this slowly and try to get the GNU project to make the GNU FDL free. This has not yet been decided. Simon
Re: Debian Free Software License?
Joerg Wendland [EMAIL PROTECTED]: is there anything like a Debian Free Software License? A license that is modelled after the DFSG? For me as free software developer, that would be a nice to have. I couldn't find a discussion about something similar in the list archives. Is this worth a discussion? Regarding the latest FDL discussion, would it be feasible to create a Debian Free Documentation License? http://www.debian.org/intro/free says that different circumstances call for different licenses and refers to the GPL, Artistic and BSD-style licences. http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html says that for documentation the chosen license is usually GNU's GPL, but that the GFDL is acceptable provided that there are no Cover Texts or Invariant sections, as is the Open Publication License (OPL) when none of the license options are exercised, or Sun's documentation licence. It might undermine the DFSG if Debian were to recommend its own licences. Edmund
Re: Suggestion to maintainers of GFDL docs
On 20030416T094049-0400, Peter S Galbraith wrote: * Why you shouldn't use the GFDL:: Debian doesn't recommend using this license. And what if this new section listing reasons _not_ to use this license were made... invariant! If we were to add to each GFDL'd document a section (invariant or not) saying, essentially, that we consider GFDL a non-free license (what else can that section say?), we would have to start moving such documents to nonfree at the same time. Otherwise we'd be hypocrites. Personally I believe that simply moving them to nonfree is far more effective than such an added section. Look at the publicity our stance against KDE used to generate when it had its license problem. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Taiteellisen ohjelmoinnin ystävien seura Toys - Ohjelmointi on myös taidetta http://www.cc.jyu.fi/yhd/toys/ pgpCgRIpUXBQM.pgp Description: PGP signature
Re: Debian Free Software License?
Edmund GRIMLEY EVANS [EMAIL PROTECTED] wrote: Joerg Wendland [EMAIL PROTECTED]: is there anything like a Debian Free Software License? A license that is modelled after the DFSG? For me as free software developer, that would be a nice to have. I couldn't find a discussion about something similar in the list archives. Is this worth a discussion? Regarding the latest FDL discussion, would it be feasible to create a Debian Free Documentation License? http://www.debian.org/intro/free says that different circumstances call for different licenses and refers to the GPL, Artistic and BSD-style licences. http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html says that for documentation the chosen license is usually GNU's GPL, but that the GFDL is acceptable provided that there are no Cover Texts or Invariant sections, I think we should shy away from it more since it allows derived works to _add_ these, making them difficult to merge back in. Someone picking the BSD license has this permission in mind, but someone picking the GFDL might think they are protected from this as they are with the GPL. My two cents anyway. Peter
Re: Suggestion to maintainers of GFDL docs
On Wed, Apr 16, 2003 at 09:40:49AM -0400, Peter S Galbraith wrote: Consider this a suggestion to maintainers of packages that contain documentation that are under the GFDL, especially if it contains invariant sections. Imagine if an Emacs user visited Info and saw this: * Menu: * Distrib:: How to get the latest Emacs distribution. * Copying:: The GNU General Public License gives you permission to redistribute GNU Emacs on certain terms; it also explains that there is no warranty. * GNU Free Documentation License:: The license for this documentation. * Why you shouldn't use the GFDL:: Debian doesn't recommend using this license. Debian can't legally distribute such an info document. Because the GFDL is incompatible with the GPL, it is prohibited to even create an info document from GFDL'd texinfo source. See #183860. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgp1MByC1oaVL.pgp Description: PGP signature
Re: Suggestion to maintainers of GFDL docs
Antti-Juhani Kaijanaho [EMAIL PROTECTED] wrote: On 20030416T094049-0400, Peter S Galbraith wrote: * Why you shouldn't use the GFDL:: Debian doesn't recommend using this license. And what if this new section listing reasons _not_ to use this license were made... invariant! If we were to add to each GFDL'd document a section (invariant or not) saying, essentially, that we consider GFDL a non-free license (what else can that section say?), we would have to start moving such documents to nonfree at the same time. Otherwise we'd be hypocrites. You're quite right. Forget about making it invariant. Personally I believe that simply moving them to nonfree is far more effective than such an added section. Look at the publicity our stance against KDE used to generate when it had its license problem. You're probably right. But I still wouldn't encourage the use of the license without the invariant parts being used since it allows derived works to add them. Peter -- Peter S. Galbraith, Debian Developer [EMAIL PROTECTED] http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E
Re: Debian Free Software License?
Edmund GRIMLEY EVANS, on 2003-04-17, 14:41, you wrote: It might undermine the DFSG if Debian were to recommend its own licences. Sure, but I did not say recommend a license but having a license that does not only fit the DFSG but reflects the DFSG and Debian's sense of free software in general. If I wrote software and put it under that license I could be certain that my software could be included in main without having to worry about OpenSSL and such... Regards, Joerg -- Joerg joergland Wendland GPG: 51CF8417 FP: 79C0 7671 AFC7 315E 657A F318 57A3 7FBD 51CF 8417 pgpVo0vSi4mTc.pgp Description: PGP signature
Re: information law online course for the interested..
--- James Miller [EMAIL PROTECTED] からのメッセー ジ： I have been teaching an information law course for a [...] I wanted to add that I would be glad to welcome other free and open source software developers to the course. I didn't intend to limit this section just to debian core or other developers. Sorry for any confusion. Please feel free to pass the invitation along to people who might be interested elsewhere... best regards, -- James Miller [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! BB is Broadband by Yahoo! http://bb.yahoo.co.jp/
Re: LPPL, take 2
Branden Robinson writes: Are you gravely opposed to external changelogs, as might be generated by, say, cvs2cl -- even if those changelogs have to be distributed along with the modified files of the Derived Work? yes, we are. This is not how the LaTeX world works. The license is to support the users, the authors, and the maintainers of the Work and Changelogs are totally alien to LPPL type of software; there is no requirement to produce, let alone distribute, them. Very few users (authors or system maintainers) would know how to look for one. Furthermore distributions are usually splitting things up into runnable versions, often source and extra documentation are quite difficult to find, other than documentation directly in the files being used. I understand that, but again there is a difference between exhortation and requirement. The GNU GPL has a similar requirement, but the FSF itself does not generally follow this practice, since it *is* part of their culture to use ChangeLog files and tools like cvs2cl. well i guess the above part of the license is essentially derived from GPL (one way or the other) ... and since GPL is a free software license ... and perhaps even DSFG free :-) ... i could probably end the argument here --- except that I happen to agree with you mostly Can you predict that the LaTeX community will never change such that revision-control systems will be used which track rationales for committed changes as file metadata? certainly not, if could predict future i would be in a different business then i'm now. I use cvs and changelogs etc all the time so do others. BUT ... I'm not saying that your requirement should be dropped altogether; your intention is perfectly reasonable. I'm saying that it shouldn't be a license violation for someone to check an LPPLed LaTeX package into CVS and maintain their own version, tracking the reasons for their changes via CVS commit messages and a ChangeLog file, as long as if and when they distribute it they either: 1) distribute the complete and accurate ChangeLog corresponding to the modified LPPL-licensed file(s) in question; OR 2) insert the contents of the complete and accurate ChangeLog into the body of the modified LPPL-licensed file(s) in question Both approaches seem reasonable to me, and to reflect real-world software development practice. they are reasonable approaches and reflect real-world software development practice of a certain kind but not more. TeX world has a two-level distribution process in which packaging in major distributions (external to the distribution of the author of the Work) is done according to runtime and space considerations with the result that it is often very difficult for a user to reconstruct the full original distribution of the author. This is not really a good situation in several respects but it is real life software practice in this part of the world. So users often only have direct and easy access to the actual runtime files and everything else including readmes etc are difficult to obtain or find. And while I agree that future working in the community may change, this is not the case right now, so to have a license that requires things in a way useful to the user is important in our opinion. On the other hand this is mainly a requirement for the case 5a2; for 5a1 the situation is different as the Derived Work is experienced as a seperate entity that can stay alongside with the original Work. However, as compromise we suggest 5. If you are not the Current Maintainer of The Work, you may modify your copy of The Work, thus creating a Derived Work based on The Work. You may distribute your Derived Work as long as the following conditions are met: a. You must ensure that each modified file of the Derived Work is clearly distinguished from the original file. This must be achieved by ensuring that at least one of the following additional conditions is met: 1. The modified file is distributed with a different Filename than the original file. 2. If the original Work identifies itself to the user when run then the Derived Work clearly identifies itself as a modified version of the original Work to the user when run. 3. The license notice for The Work specifies that the file or class of files (for example, files that are named a certain way) may be modified without renaming. b. You must ensure that no part of the Derived Work identifies itself as the original, unmodified Work to the user in any way when run. c. You must ensure that each such modified file carries prominent notices detailing the nature of the changes, or a prominent reference to another file containing a complete and accurate log of the changes that is distributed as part of the Derived Work. d. You must change or remove
Re: motion to take action on the unhappy GNU FDL issue
On Thu, Apr 17, 2003 at 12:44:32PM +0200, Sunnanvind Fenderson wrote: Well, listening to Georg Greve it sounded like the FSF wanted an official statement from Debian regarding the problems with non-removability of invariant sections. In my very humble opinion, Debian should try giving them that before taking (what would appear to be) the more hostile actions suggested by you. I'm sorry you perceive hostility; that's not my intent. However, it seems like what you're asking us to try giving them is exactly what I recommended as the first course of action. You did not quote my message, so here's the part in question: I propose that we: * draft a comprehensive critique of the GNU FDL 1.2, detailing section-by-section our problems with the license -- G. Branden Robinson| A fundamentalist is someone who Debian GNU/Linux | hates sin more than he loves [EMAIL PROTECTED] | virtue. http://people.debian.org/~branden/ | -- John H. Schaar pgpSuMPsggRIk.pgp Description: PGP signature
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
On Tue, Apr 15, 2003 at 09:10:00AM -0700, Mark Rafn wrote: Good luck with that, and I look forward to hearing from you and/or other FSF representatives soon. I hope it's not terribly much longer, as the current semi-consensus is likely to congeal into an actual necessity to remove un-free emacs documentation from Debian. Not if people don't second my motion, or propose something similar. It may be that we're content to complain but lack the will to act. -- G. Branden Robinson|Build a fire for a man, and he'll Debian GNU/Linux |be warm for a day. Set a man on [EMAIL PROTECTED] |fire, and he'll be warm for the http://people.debian.org/~branden/ |rest of his life. - Terry Pratchett pgpyfzVFrRReL.pgp Description: PGP signature
Re: Debian Free Software License?
On Thu, Apr 17, 2003 at 02:47:20PM +0200, Joerg Wendland wrote: is there anything like a Debian Free Software License? A license that is modelled after the DFSG? For me as free software developer, that would be a nice to have. I couldn't find a discussion about something similar in the list archives. Is this worth a discussion? Regarding the latest FDL discussion, would it be feasible to create a Debian Free Documentation License? One way to think about the DFSG[1] is to conceive of it as a sequence of tests that is applied to a license. If it passes all the tests, it *might* be a DFSG-free license. If it fails one or more, it most likely is not. This a gray endeavor, not a scientific one like chemical analysis. But even in chemical qualitative analysis, it is the case that knowing how to distinguish an acid from a base doesn't of itself tell you how to stick together atoms to create an acid. It is partly for this reason that I feel that the DFSG is an inadequate tool -- when taken all by itself -- for constructing a license. It's a good thing to read and have in mind when writing one, but it doesn't tell you everything you need to know. [1] I don't claim that everyone thinks about it this way -- G. Branden Robinson|Imagination was given man to Debian GNU/Linux |compensate for what he is not, and [EMAIL PROTECTED] |a sense of humor to console him for http://people.debian.org/~branden/ |what he is. pgpHdBlLX5B7v.pgp Description: PGP signature
Re: LPPL, take 2
Branden Robinson [EMAIL PROTECTED] writes: c. In every file of the Derived Work you must ensure that any addresses for the reporting of errors do not refer to the Current Maintainer's addresses in any way. This is somewhat new ground for a DFSG-free license. Is it *really* that important? If so, I'd like to hear advocates of it explain why it's more free than, say, a prohibition against the creator of a Derived Work calling the Current Maintainer on the phone to ask for technical support. This is sufficiently awful as to be unacceptible. For example, suppose Debian takes the package, and modifies it. We prune all the previous bug reporting addresses, and mention only normal Debian addresses, including debian-devel. And then one of the Current Maintainers subscribes to debian-devel. It now becomes *Debian's* responsibility to deal. Eek!
Re: Suggestion to maintainers of GFDL docs
On Thu, Apr 17, 2003 at 02:34:36PM +, Brian M. Carlson wrote: Debian can't legally distribute such an info document. Because the GFDL is incompatible with the GPL, it is prohibited to even create an info document from GFDL'd texinfo source. See #183860. Hrm, if that's the case, we can't distribute, eg, the pcl-cvs.texi file either -- after all, it's licensed under a verbatim copying only license, but has the \input texinfo line at the top. I don't think that is the case though, for two reasons: (1) we don't actually distribute pcl-cvs anything that's made use of the TeX stuff; so we haven't made copies of texinfo.tex, and don't need to be concerned with its copyright (2) the TeX output probably comes under the exemption in section 0 of the GPL -- `...the output from the Program (texinfo.tex) is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program).' Either reason alone should be enough to make this not a real concern. The FSF might like to clarify their intentions here. Bug cc'ed. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpyyf3bgYuxH.pgp Description: PGP signature
Re: Suggestion to maintainers of GFDL docs
Peter S Galbraith [EMAIL PROTECTED] writes: And what if this new section listing reasons _not_ to use this license were made... invariant! I think writing such a new section is a reasonable thing, but of course, we can't make in invariant without violating our own principles.
Re: Debian Free Software License?
Scripsit Joerg Wendland [EMAIL PROTECTED] Sure, but I did not say recommend a license but having a license that does not only fit the DFSG but reflects the DFSG and Debian's sense of free software in general. I think it would be stretching the truth to say that Debian, as a project, has any sense of free software in general that could back such kind of official approval. We can usually agree about whether a given license is free or not. But there is nothing like consensus about which of the many ways to construct a free license is the best. We have valued and well-spoken contributors on debian-legal who personally think that a license ought to be viral, forcing freedom on derived works. We have other valued and well-spoken contributors on debian-legal who personally think that a license is more free if it allows derived works to be less free. Usually our consensus does its best to respect both points of view, but that would be impossible if we were to single out a particular license as the ideal one. If I wrote software and put it under that license I could be certain that my software could be included in main without having to worry about OpenSSL and such... It is impossible to construct a single license that can be guaranteed to allows unlimited linking to each and every library in Debian. (This is because two such libraries, while individually free, may have mutually incompatible licenses that prevent both from being included in the same derived work). -- Henning Makholm Nemo enim fere saltat sobrius, nisi forte insanit.
Re: motion to take action on the unhappy GNU FDL issue
Scripsit Sunnanvind Fenderson [EMAIL PROTECTED] Well, listening to Georg Greve it sounded like the FSF wanted an official statement from Debian regarding the problems with non-removability of invariant sections. I don't think the FSF is prepared to change their licensing practise no matter how eloquent statements we can draft here. IIRC, a couple of iterations back we had a subthread on d-l where Stallman himself participated. He did not seem to attach any particular weight by our objections. In my very humble opinion, Debian should try giving them that before taking (what would appear to be) the more hostile actions suggested by you. The three initial of Branden's proposed actions do not seem to be hostile. They say that we make up our mind and draft a self-contained descriptions of why we think the invariant-section stuff (etc.) is evil. Surely that is a prerequisite for doing *anything* else than bitch about the problem internally on debian-legal. -- Henning Makholm So? We're adaptable. We'll *switch missions*!
Re: LPPL, take 2
On Thu, Apr 17, 2003 at 10:53:30AM -0700, Thomas Bushnell, BSG wrote: Branden Robinson [EMAIL PROTECTED] writes: c. In every file of the Derived Work you must ensure that any addresses for the reporting of errors do not refer to the Current Maintainer's addresses in any way. This is somewhat new ground for a DFSG-free license. Is it *really* that important? If so, I'd like to hear advocates of it explain why it's more free than, say, a prohibition against the creator of a Derived Work calling the Current Maintainer on the phone to ask for technical support. This is sufficiently awful as to be unacceptible. For example, suppose Debian takes the package, and modifies it. We prune all the previous bug reporting addresses, and mention only normal Debian addresses, including debian-devel. And then one of the Current Maintainers subscribes to debian-devel. It now becomes *Debian's* responsibility to deal. Eek! Simple. We kick him off the list with a we're sorry, your license prevents us from letting you subscribe. In all seriousness, though, Thomas raises a good point. But I think that Frank's recent e-mail deals with this issue already. You're suffering from lag, my friend. Simon
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
|| On Tue, 15 Apr 2003 09:10:00 -0700 (PDT) || Mark Rafn [EMAIL PROTECTED] wrote: mr Indeed. Ensuring that Debian remains free is the primary reason mr for this list's existence, and it can be an emotional topic. True. All of us are probably feeling strongly about freedom. The fact that Debian works so hard to do these questions justice is one of the reasons that I have been so supportive of Debian in the past. [...] right now I need to set up a Free Software project with the European Commission, for which April 24th is the deadline. mr Good luck with that, and I look forward to hearing from you mr and/or other FSF representatives soon. Thanks, lets hope this project comes through. If it does, I think we can also expect Debian to benefit from it. mr I hope it's not terribly much longer, as the current mr semi-consensus is likely to congeal into an actual necessity to mr remove un-free emacs documentation from Debian. Are you referring to documentation under the GFDL? Why would that have to be removed? Regards, Georg -- Georg C. F. Greve [EMAIL PROTECTED] Free Software Foundation Europe (http://fsfeurope.org) Brave GNU World(http://brave-gnu-world.org) pgp2fWKoMDTiF.pgp Description: PGP signature
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
|| On Tue, 15 Apr 2003 10:37:57 -0400 || [EMAIL PROTECTED] (Brian T. Sniffen) wrote: bts You've heard all this before, but I haven't seen you answer it. bts Why does the GFDL prohibit me from making an emacs reference bts card from the manual? Sure, I could make a one-sided card where bts the other side is the Manifesto, but that wastes half my space. That is most likely a special case. Technical tables are not Copyrightable per se. Their special formatting or composition might be, but generally the table itself is not. This will probably also apply to such reference cards, which is a table mapping key presses to functions of a program. So it should be perfectly fine if you took the content of that reference card and printed it as long as you took care to not include things like special formatting or logos. bts In addition, how does the FSF expect anybody other than itself bts to distribute a GPL'd emacs with a GFDL manual? As far as I can bts see, they cannot be distributed together. Why would that be? Documents and software are different domains by law. Just putting them together -- even if one links to the other -- does not constitute one assembled work. In fact it is probable that not even hard-linking them by compiling a document into a program would legally form one work. For a somewhat definitive answer to that we'd need to have a study performed; but it is the estimation of a lawyer specialized on Copyright that I have run this through. Regards, Georg -- Georg C. F. Greve [EMAIL PROTECTED] Free Software Foundation Europe (http://fsfeurope.org) Brave GNU World(http://brave-gnu-world.org) pgpJBxXfvMn8U.pgp Description: PGP signature
Re: Suggestion to maintainers of GFDL docs
On Fri, Apr 18, 2003 at 04:16:57AM +1000, Anthony Towns wrote: On Thu, Apr 17, 2003 at 02:34:36PM +, Brian M. Carlson wrote: Debian can't legally distribute such an info document. Because the GFDL is incompatible with the GPL, it is prohibited to even create an info document from GFDL'd texinfo source. See #183860. Hrm, if that's the case, we can't distribute, eg, the pcl-cvs.texi file either -- after all, it's licensed under a verbatim copying only license, but has the \input texinfo line at the top. I don't think that is the case though, for two reasons: (1) we don't actually distribute pcl-cvs anything that's made use of the TeX stuff; so we haven't made copies of texinfo.tex, and don't need to be concerned with its copyright (2) the TeX output probably comes under the exemption in section 0 of the GPL -- `...the output from the Program (texinfo.tex) is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program).' In this case, texinfo.tex is akin to a header file that a program. The program would be TeX (or a variant that implements the TeX macro language.) However, this only applies to DVI and PDF forms of this work. The info documentation is generated by makeinfo, which does not put any significant chunks of itself within the output. Simon
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
Georg C. F. Greve [EMAIL PROTECTED] writes: || On Tue, 15 Apr 2003 10:37:57 -0400 || [EMAIL PROTECTED] (Brian T. Sniffen) wrote: bts You've heard all this before, but I haven't seen you answer it. bts Why does the GFDL prohibit me from making an emacs reference bts card from the manual? Sure, I could make a one-sided card where bts the other side is the Manifesto, but that wastes half my space. That is most likely a special case. Technical tables are not Copyrightable per se. Their special formatting or composition might be, but generally the table itself is not. This will probably also apply to such reference cards, which is a table mapping key presses to functions of a program. So it should be perfectly fine if you took the content of that reference card and printed it as long as you took care to not include things like special formatting or logos. I suspected you were trolling before, and am now essentially convinced of it. But what the heck, I'll feed you: You're horribly confused about copyright law, reference cards, or both. A reference card has a subset of commands, chosen for usefulness, elegance, or aesthetic appeal. It has succinct descriptions, which are a creative effort. It is definitely copyrightable on either of those points. But the issue here is not copying or modifying an existing card, but deriving a reference card from the Emacs manual. bts In addition, how does the FSF expect anybody other than itself bts to distribute a GPL'd emacs with a GFDL manual? As far as I can bts see, they cannot be distributed together. Why would that be? Documents and software are different domains by law. Just putting them together -- even if one links to the other -- does not constitute one assembled work. In fact it is probable that not even hard-linking them by compiling a document into a program would legally form one work. For a somewhat definitive answer to that we'd need to have a study performed; but it is the estimation of a lawyer specialized on Copyright that I have run this through. I'm not at all sure what to say to this. Are you talking about Berne Convention copyright law? Are you really asserting that the comments and strings in a source file labelled as being under the GPL might not be under the GPL? -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: LPPL, take 2
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: Branden Robinson [EMAIL PROTECTED] writes: c. In every file of the Derived Work you must ensure that any addresses for the reporting of errors do not refer to the Current Maintainer's addresses in any way. This is somewhat new ground for a DFSG-free license. Is it *really* that important? If so, I'd like to hear advocates of it explain why it's more free than, say, a prohibition against the creator of a Derived Work calling the Current Maintainer on the phone to ask for technical support. This is sufficiently awful as to be unacceptible. For example, suppose Debian takes the package, and modifies it. We prune all the previous bug reporting addresses, and mention only normal Debian addresses, including debian-devel. And then one of the Current Maintainers subscribes to debian-devel. It now becomes *Debian's* responsibility to deal. Eek! I think tb's problem is with the in any way phrasing. How's this for an alternative: c. The Current Maintainer may have included an offering of technical support for his work, labelled Support Information. You must remove any such offerings, though you may add your own. If there is other information regarding support from or contact information for the Current Maintainer, you may treat it under the other terms of this License. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
On Thu, 17 Apr 2003, Georg C. F. Greve wrote: mr I hope it's not terribly much longer, as the current mr semi-consensus is likely to congeal into an actual necessity to mr remove un-free emacs documentation from Debian. Are you referring to documentation under the GFDL? Why would that have to be removed? Not all GFDL documentation, only that which contains invariant sections which cannot be removed or modified. They'd have to be removed for the same reason than any component of Debian would have to be removed if it was discovered to be non-free. Debian does not contain non-free components. We do make available archives of useful-but-unfree software which could contain this documentation, but it wouldn't be part of Debian. I expect there will be more time for debate and discussion before the actual removal takes place. Branden's proposal for documenting and writing a FAQ seems like the proper next step. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: motion to take action on the unhappy GNU FDL issue
On Wed, 16 Apr 2003, Branden Robinson wrote: This is the stuff of which nasty flamewars and misspelled Slashdot headlines are made, hence my unwillingness to do it, but it is clear to me that letting this issue languish in ambiguity isn't good for us or our users. I agree both with your reluctance and your assessment of the harm caused by inaction. I am seeking seconds for this proposal. I think this proposal is the right thing to do, especially the hard work of creating the documents before filing bugs. Unfortunately, I am unwilling to take on the task myself, though I'm happy to provide feedback and sections of text where I can. Between this and the fact that IANADD, I don't think I have standing to provide a second. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: LPPL, take 2
Frank Mittelbach [EMAIL PROTECTED] wrote: Note that above we also addressed the concern by (I think Walter) concerning 5a2 so that it now only requires run-time identification if the original used runtime identification Thank you. It is extremely close. It doesn't quite allow me to take out parts of the program and use it in grep if the original program identified itself originally. A possible rewording: 2. If the Derived Work identifies itself to the user when run then it must clearly identify itself as a modified version of the original Work to the user when run. This is similar to GPL 2c, which only requires notification if the _modified_ program is interactive. Regards, Walter Landry [EMAIL PROTECTED]
Re: LPPL, take 2
Walter Landry writes: Frank Mittelbach [EMAIL PROTECTED] wrote: Note that above we also addressed the concern by (I think Walter) concerning 5a2 so that it now only requires run-time identification if the original used runtime identification Thank you. It is extremely close. It doesn't quite allow me to take out parts of the program and use it in grep if the original program identified itself originally. yes it does. because if you use parts of the original work as part of something else you would do so under 5a1 so 2 would be not required at all. remember 5a are alternatives. A possible rewording: 2. If the Derived Work identifies itself to the user when run then it must clearly identify itself as a modified version of the original Work to the user when run. wouldn't serve the purpose. The purpose is to inform the user that he is not getting the original (which is the normal expectation). if the derived work could decide whether or not to give this information this would be pointless frank
Re: LPPL, take 2
Frank Mittelbach [EMAIL PROTECTED] wrote: Walter Landry writes: Frank Mittelbach [EMAIL PROTECTED] wrote: Note that above we also addressed the concern by (I think Walter) concerning 5a2 so that it now only requires run-time identification if the original used runtime identification Thank you. It is extremely close. It doesn't quite allow me to take out parts of the program and use it in grep if the original program identified itself originally. yes it does. because if you use parts of the original work as part of something else you would do so under 5a1 so 2 would be not required at all. remember 5a are alternatives. 5a1 is not a free alternative. 5a2 approaches that, but it has to cover _every_ occasion where 5a1 fails, not just most of them. Regards, Walter Landry [EMAIL PROTECTED]
Re: query from Georg Greve of GNU about Debian's opinion of the F DL
On Wed, Apr 16, 2003 at 01:59:37PM -0400, Peter S Galbraith wrote: If the manifesto marked as invariant? I didn't know that! It doesn't seem to be in the visible info text, but the top of each of the info files has a GFDL blurb. I grepped for Invariant in my emacs-21 info files. The main manual lists The GNU Manifesto, Distribution and GNU GENERAL PUBLIC LICENSE as Invariant Sections. There are also some smaller manuals that list none. That's 930 lines of material, about 46 kB. Richard Braakman
Re: LPPL, take 2
Walter Landry writes: 5a1 is not a free alternative. 5a2 approaches that, but it has to cover _every_ occasion where 5a1 fails, not just most of them. I don't think it is acceptable that you take a list of ors, judge each of them individually and conclude that each of them is not 100% therefore the whole can't be either. Not 5a2 has to fullfil DSFG but 5a. if i distribute FOO (that does runtime info to users ie is interactive in this sense) under lppl you can of course use parts of foo in grep since FOO neq grep there is no requirement for at all. if you want to distribute a variant FOO as a replacement for the original FOO then it would be interactive as well, thus the requirement in 5a2 would be reasonable where would that conflict with DSFG? frank ps your suggested rewrite is by no means similar to GPL 2c since 2c depends on an external fact about the modified program being interactive or not while your rewrite makes the applicability a decision of the author of the Derived Work which has no binding at all
Re: motion to take action on the unhappy GNU FDL issue
On Wed, Apr 16, 2003 at 03:09:17PM -0500, Branden Robinson wrote: I propose that we: * draft a comprehensive critique of the GNU FDL 1.2, detailing section-by-section our problems with the license (Branden, didn't you construct such a critique a while ago? I remember reading one.) * draft a FAQ regarding why we differ with FSF orthodoxy on this issue * draft a document advising users of the GNU FDL how to add riders to their license terms such that works so licensed are DFSG-free, and pointing out alternative documentation licenses that are also DFSG-free Then: * exhaustively identify works in main and contrib using the GNU FDL[1] * contact[2] the package maintainers and upstream authors of each affected source package, and include pointers to the above documents * post a list of affected packages to debian-devel-announce and/or debian-announce, so that no one is surprised by whatever later actions occur * give people some time to consider and act upon the above contact (some may relicense, some will tell us to go pound sand, others won't reply at all) * remove packages from main and contrib whose licenses have not been brought into compliance with the DFSG I second this proposal, with the addition that I wouldn't be opposed to passing a General Resolution at some point before any removals. This is the stuff of which nasty flamewars and misspelled Slashdot headlines are made, hence my unwillingness to do it, but it is clear to me that letting this issue languish in ambiguity isn't good for us or our users. Indeed. In fact, I now have the impression that the FSF was waiting for us to come up with an official statement, while we were waiting for a response from the FSF. The first three steps of your proposal seem to be a good way to resolve that. I think it's also time to get the rest of the project involved. I expect that a lot of people who don't ordinarily care about license details will suddenly become interested when packages like glibc-doc are affected. This probably means all of the issues will be rehashed on debian-devel, so it will be good to have such a FAQ available. (I'm not advocating this rehashing, I'm just speaking from past experience :) Richard Braakman
Re: motion to take action on the unhappy GNU FDL issue
Scripsit Mark Rafn [EMAIL PROTECTED] I think this proposal is the right thing to do, especially the hard work of creating the documents before filing bugs. Unfortunately, I am unwilling to take on the task myself, though I'm happy to provide feedback and sections of text where I can. Between this and the fact that IANADD, I don't think I have standing to provide a second. What he said. -- Henning Makholm Det er du nok fandens ene om at mene. For det ligger i Australien!
