Re: Referencing the DFSG [Re: DRAFT summary of the OPL; feedback requested]
On Thu, 2004-03-11 at 06:54, Branden Robinson wrote: I think Jeremy's concerns about not reinforcing the meme of DFSG as strict ruleset are quite valid, but I think it serves people well if we cite the DFSG wherever applicable in our license analyses. It is also common courtesy among lawyers to cite wherever you got the mustard. First of all, just stating that some clause violates the DFSG in general, would make any lawyer very wary. It makes it more sound as it violates some vague, general principle that we hold dear, but cannot enforce (at least, from a lawyers point of view). Secondly, as legal work often involves a lot of paperwork, is it very nice to cite the exact location, if possible even the exact sentence. Though this is not really a big point concerning the DFSG (considering its length), it would at least make someone unfamiliar with the DFSG more inclined to check out one paragraph than a whole document. And last of all, it's just a sign of professionalism. First impression is oft a first judgement about the intrinsic quality. Compare the outer/inner beauty problem. Polishing outer beauty will make the inner beauty more visible. Batist Paklons -- The first thing we do, let's kill all the lawyers Henry VI, part 2
License for the Torque Resource Manager (RFC)
I would appreciate your comments and advice about the license for the Torque Resource Manager. Some background information that i've found: Torque is a product derived from the OpenPBS source. OpenPBS is a well known software package that is commonly used on HPC clusters, originally developed for NASA, and now it is commercially supported and maintained by Altair Engineering (http://www.pbspro.com/ and http://www.openpbs.org/). The source code for OpenPBS is available, but the current license is not free (http://www.openpbs.org/license.html). This is almost the same license that the one used in Torque, with a only a small but important change; the license for Torque has this additional phrase: After December 31, 2001, only conditions 3-6 must be met I think that Torque was derived from a previous release of OpenPBS that contained such clause, and was removed on subsequent releases of OpenPBS. The rest of the license looks identical, including the title and version: OpenPBS (Portable Batch System) v2.3 Software License Agreement. Torque can be downloaded from here: http://www.supercluster.org/downloads/ This is the license: | | OpenPBS (Portable Batch System) v2.3 Software License | | Copyright (c) 1999-2000 Veridian Information Solutions, Inc. | All rights reserved. | | --- | For a license to use or redistribute the OpenPBS software under conditions | other than those described below, or to purchase support for this software, | please contact Veridian Systems, PBS Products Department (Licensor) at: | |www.OpenPBS.org +1 650 967-4675 [EMAIL PROTECTED] |877 902-4PBS (US toll-free) | --- | | This license covers use of the OpenPBS v2.3 software (the Software) at | your site or location, and, for certain users, redistribution of the | Software to other sites and locations. Use and redistribution of | OpenPBS v2.3 in source and binary forms, with or without modification, | are permitted provided that all of the following conditions are met. | After December 31, 2001, only conditions 3-6 must be met: | | 1. Commercial and/or non-commercial use of the Software is permitted |provided a current software registration is on file at www.OpenPBS.org. |If use of this software contributes to a publication, product, or |service, proper attribution must be given; see www.OpenPBS.org/credit.html | | 2. Redistribution in any form is only permitted for non-commercial, |non-profit purposes. There can be no charge for the Software or any |software incorporating the Software. Further, there can be no |expectation of revenue generated as a consequence of redistributing |the Software. | | 3. Any Redistribution of source code must retain the above copyright notice |and the acknowledgment contained in paragraph 6, this list of conditions |and the disclaimer contained in paragraph 7. | | 4. Any Redistribution in binary form must reproduce the above copyright |notice and the acknowledgment contained in paragraph 6, this list of |conditions and the disclaimer contained in paragraph 7 in the |documentation and/or other materials provided with the distribution. | | 5. Redistributions in any form must be accompanied by information on how to |obtain complete source code for the OpenPBS software and any |modifications and/or additions to the OpenPBS software. The source code |must either be included in the distribution or be available for no more |than the cost of distribution plus a nominal fee, and all modifications |and additions to the Software must be freely redistributable by any party |(including Licensor) without restriction. | | 6. All advertising materials mentioning features or use of the Software must |display the following acknowledgment: | | This product includes software developed by NASA Ames Research Center, | Lawrence Livermore National Laboratory, and Veridian Information Solutions, | Inc. Visit www.OpenPBS.org for OpenPBS software support, | products, and information. | | 7. DISCLAIMER OF WARRANTY | | THIS SOFTWARE IS PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND. ANY EXPRESS | OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES | OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT | ARE EXPRESSLY DISCLAIMED. | | IN NO EVENT SHALL VERIDIAN CORPORATION, ITS AFFILIATED COMPANIES, OR THE | U.S. GOVERNMENT OR ANY OF ITS AGENCIES BE LIABLE FOR ANY DIRECT OR INDIRECT, | INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT | LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, | OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF | LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING |
Re: Referencing the DFSG [Re: DRAFT summary of the OPL; feedback requested]
Don Armstrong [EMAIL PROTECTED] writes: On Wed, 10 Mar 2004, Jeremy Hankins wrote: The interesting part of the claim in a summary isn't that restrictions on modifying make a license non-free, but that the license restricts modifying. The summary doesn't describe the DFSG, it describes the license. Obviously. But in describing a specific case, it's rather trivial to say This section restricts modification (DFSG §3). This allows others reading your arguments to recognize their foundations. The foundations are already clear: the DFSG. I'm not convinced that explicitly specifying a paragraph is better than implicitly specifying a page. You think that the sections of the DFSG provide a useful taxonomy of non-free licenses? In some circumstances, yes. By seeing which clauses of the DFSG are in violation, it becomes much easier for our ftp-masters to see if there is something in the license that would restrict the work from being able to even be redistributed in non-free, as an example. Additionally, it helps others who are attempting to interpret the DFSG to see licenses which have preiviously failed sections of it and understand the line between Free and non-free. This I absolutely disagree with, and is just the idea that I hoped not to encourage by not including section numbers. As this is more of a claim than an argument I can't actually refute your reasoning, since you haven't given it. The only thing I can say is that reducing the reasons for a license to be considered non-free to violates DFSG section N is a gross simplification, and can't in any way improve license analysis. Of course, we'll (I hope!) include more than that in the summaries. But I suspect that those who aren't as interested in the legal details will gloss over that, and simply think in terms of DFSG sections. That would be very surprising, as I don't believe it was written with that in mind. Works often end up in more than the role they were designed for. Of course. But coming up with a good taxonomy is Hard(tm). The idea that Bruce Perens happened upon one by accident while writing the DFSG is very surprising indeed. Perhaps he has a turing-complete compost heap as well? What's far more likely is that it will function (badly) as a taxonomy and introduce unnoticed misconceptions and errors. This is a far more common occurrence, even when the categorization was developed deliberately. The best thing that can happen is it simply won't work at all. I guess we'd have to do a survey of licenses in order to have hard data to support or deny this idea. But my sense (based on my experience reading d-l) is that useful categories of license tend to be largely orthogonal to the way the DFSG is split into sections. Licenses don't tend to neatly and simply fail some section of the DFSG. No, they usually tend to fail multiple sections, and get all sorts of things wrong, some of which aren't even included in the DFSG. They also tend to fail particular sections in all sorts of very different ways, and fail different sections in very similar ways. That's what being orthogonal is all about. I think that the idea that the DFSG neatly and simply captures the ways that licenses can be non-free is very much tied to the idea that the DFSG could be used as a definition. Obviously. But we're not talking about capturing here. Then what are you talking about? If the section of the DFSG a license fails doesn't capture anything, why include that datum? If your contention that a license is not free is based upon the DFSG, it should state so. See my first paragraph (quoted) above. My claim *isn't* that it violates the DFSG, but that it restricts modification. Once you establish that it restricts modification, the rest is trivial. Thus what you're saying applies very well for things like the dissident test, as referring to that is a stand in for more argumentation. But DFSG section numbers don't stand in for much of anything. There are licenses which violate specific sections of the DFSG. We can use that information to compare licenses and become better at interpreting the clauses of the DFSG in an appropriate manner. Can you give an example, or provide more detail? When I'm examining licenses that have a strange set of wording, and seem to fail a particular portion of the DFSG, I often want to go back and look through the discussion of other licenses with similar terms that have also failed the DFSG. So you want a database of similar terms. Great idea, though I don't see how you plan to do it without first coming up with a good taxonomy. What's that have to do with the DFSG? Or are you claiming that everything that fails section 3 of the DFSG will be similar? Examples: A) Derivative works must include your correct address and phone number. B) If you redistribute the original, you must include your address and phone number. C) If you distribute the original, you must first
Re: License for the Torque Resource Manager (RFC)
On 2004-03-11 13:26:49 + Roberto Gordo Saez [EMAIL PROTECTED] wrote: | 5. Redistributions in any form must be accompanied by information on how to |obtain complete source code for the OpenPBS software and any |modifications and/or additions to the OpenPBS software. The source code |must either be included in the distribution or be available for no more |than the cost of distribution plus a nominal fee, and all modifications |and additions to the Software must be freely redistributable by any party |(including Licensor) without restriction. [...] - Looks like it is DFSG-free (please, confirm). Comments, aditional information are welcome, including concerns about the license. I want to be sure that the license is acceptable. As per http://lists.debian.org/debian-legal/2004/debian-legal-200402/msg00132.html (found by searching legal for openpbs), there is no consensus that the above condition clause 5 is DFSG-free because of the lawyerbomb freely redistributable ... without restriction. Other than that, I think your analysis was pretty good. Personally, I wonder about whether we are allowed to make copies instead of just moving the one we are given, but I'd not oppose something just on that wording if no-one else agreed. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ [EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/
Re: Referencing the DFSG [Re: DRAFT summary of the OPL; feedback requested]
Branden Robinson [EMAIL PROTECTED] writes: If my opinion matters, I have to come down more on Don's side of this disagreement. Hrmph. ;) I think Jeremy's concerns about not reinforcing the meme of DFSG as strict ruleset are quite valid, but I think it serves people well if we cite the DFSG wherever applicable in our license analyses. One reason is because it will help us to become better aware of limitations of the DFSG as currently written, and where we might be able to improve it. My fear is that, as Don seems to be showing, people will oversimplify and miss the limitations. Getting people to think in terms of modification instead of DFSG 3 seems useful. But so far I seem to be on the losing side of this debate, at least in terms of numbers, so I don't intend to push too hard. Besides, Batist's point about professionalism and appearing thorough is well taken, though it offends the idealist in me. I guess I need to work on my cynicism. ;) So unless there are others who feel as I do, I'll go ahead and include the DFSG section in the summary when I post it tomorrow. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: License for the Torque Resource Manager (RFC)
Roberto Gordo Saez [EMAIL PROTECTED] writes: | 1. Commercial and/or non-commercial use of the Software is permitted |provided a current software registration is on file at www.OpenPBS.org. |If use of this software contributes to a publication, product, or |service, proper attribution must be given; see www.OpenPBS.org/credit.html It requires registration. | 2. Redistribution in any form is only permitted for non-commercial, |non-profit purposes. There can be no charge for the Software or any |software incorporating the Software. Further, there can be no |expectation of revenue generated as a consequence of redistributing |the Software. It cannot be distributed for money, or for commercial purposes at all. This is non-free. | 5. Redistributions in any form must be accompanied by information on how to |obtain complete source code for the OpenPBS software and any |modifications and/or additions to the OpenPBS software. The source code |must either be included in the distribution or be available for no more |than the cost of distribution plus a nominal fee, and all modifications |and additions to the Software must be freely redistributable by any party |(including Licensor) without restriction. And it requires a more free license for derivative works than it provides for the original work. That is non-free. So it's definitely non-free, in addition to what you say below. I think I understand you to have said that conditions 1 and 2 don't apply any more; in that case, can you have the copyright holder remove them? That would be much, much more clear and safe. -Brian AFAIK: - Has the BSD advertising clause - GPL incompatible. - Source must be provided (like the GPL). - The expiration clause is dated in the past, so i think that sections 1 and 2 can't be enforced anymore. If we ignore those clauses, there is little information about redistribution remaining in the text, but i think that the permissive notice in the header is sufficient. - Looks like it is DFSG-free (please, confirm). Comments, aditional information are welcome, including concerns about the license. I want to be sure that the license is acceptable. -- Roberto Gordo Saez - Free Software Engineer Linalco Especialistas en Linux y Software Libre http://www.linalco.com/ Tel: +34-914561700 -- Brian Sniffen [EMAIL PROTECTED]
Re: DRAFT summary of the OPL; feedback requested
Jeremy Hankins wrote: Don Armstrong [EMAIL PROTECTED] writes: On Wed, 10 Mar 2004, Jeremy Hankins wrote: This is a serious question: how does (DFSG 3) tacked on to the end of a sentence help to explain the issue? In the same way that a footnote or reference does. It's always appropriate to refer to the basis for a specific claim. That's not precisely the situation here. The interesting part of the claim in a summary isn't that restrictions on modifying make a license non-free, but that the license restricts modifying. The summary doesn't describe the DFSG, it describes the license. But even so, it /seems/ appropriate to me (as a newbie here, and I am not ultra-familiar with the letter of the DFSG), so I can take a quick look and say, hmmm, section three (sometimes it's obvious, but sometimes I'll say what?! where is this in the guidelines?) In this case, the claim would be that a particular statement is in direct validation of a particular tenent of the DFSG. Since you're claiming that it's violating the DFSG instead of being mere legal fooery, you should indicate which section(s) of the DFSG is being violated, much like you would in any form of discourse. The DFSG is not a 50-page document. It should be trivial for someone reading a summary to look up the specific section if they need that information for some reason. Why not make it yet more trivial? Even if it's not a 50-page doc, it's not a single paragraph either. What problem are we trying to solve? There may well be cases where someone reading a summary would need this info (though I can't think of any), but is that case frequent enough that we should work to optimize for it? I think so. Makes simple things easier and complex things possible. Obviously, those who know the DFSG know which sections are what, but it's a service to those who are unfamiliar with the document. Me! Me! I'm here! I want to help, but I will know the DFSG by heart in six to nine months! Someone whose not familiar with the document will probably find restricts modifications more useful than violates DFSG 3. Even if you include both, what does the latter add? * Makes simple things easier. * Says DFSG 3 forbids restrictions on modifications. * When there are many, many DFSG violations in a single, copyrights holder wants to help but does not see why his license is non-free case, eases to categorize them and makes suggestions to the copyrights holder. But thinking that the DFSG delineates a bunch of categories into which non-free licenses can fall is a depressingly common, and absolutely *wrong*, viewpoint. Reinforcing that notion is a bad idea. I'm not so sure that it's a wrong viewpoint. Do I understand you properly? You think that the sections of the DFSG provide a useful taxonomy of non-free licenses? That would be very surprising, as I don't believe it was written with that in mind. I tend to agree with you that it's not a comprehensive taxonomy of non-freenesses, but, as I said above, serves as a guideline to enlighten the non-free-for-a-hair people. I guess we'd have to do a survey of licenses in order to have hard data to support or deny this idea. But my sense (based on my experience reading d-l) is that useful categories of license tend to be largely orthogonal to the way the DFSG is split into sections. Licenses don't tend to neatly and simply fail some section of the DFSG. I agree. It seems to me that this is a conflation of DFSG as a guideline vs DFSG as a definition[1] and indicating how the DFSG is used as a guideline. Not at all. I think that the idea that the DFSG neatly and simply captures the ways that licenses can be non-free is very much tied to the idea that the DFSG could be used as a definition. But IMHO how to use DFSG (as a guideline), explicitly, is a good thing. There are licenses which violate specific sections of the DFSG. We can use that information to compare licenses and become better at interpreting the clauses of the DFSG in an appropriate manner. Can you give an example, or provide more detail? I don't see this at all, unless it's based on the idea that the DFSG provides a good taxonomy for non-free licenses. People will continue to erroneously think of the DFSG as a definition, just as people erroneously only read legislation without reading case law. Failing to cite references appropriately isn't really going to cure this. No doubt. But we don't need to contribute to the problem. We can add more information at the end of the summary, saying things like: == summary * clause 23: non-free; restricts modifications; viol DFSG#3; see [1] below; == at the end [1] this clause is very similar to the clause 12 of the license for , that was redeemed non-free in the summary of date, at href; == ! now, if we can organize this right /and/ archive properly the summaries, soon we will have a nice archive of case law... -- HTH, best regards, Massa
Re: Referencing the DFSG [Re: DRAFT summary of the OPL; feedback requested]
On Thu, 11 Mar 2004, Jeremy Hankins wrote: Don Armstrong [EMAIL PROTECTED] writes: On Wed, 10 Mar 2004, Jeremy Hankins wrote: Perhaps [Bruce Perens] has a turing-complete compost heap as well? Way, way, OT, but it's pretty hard not to have a compost machine that does not contain universal turing machines.[1] (Hint: Think bacteria and DNA.) Then what are you talking about? If the section of the DFSG a license fails doesn't capture anything, why include that datum? Just because a single section of the DFSG fails to enclose all of the problems of a license doesn't mean that a a license does not violate a section of the DFSG. Regardless, I think there's a fundamental miscommunication here. I'm suggesting the following: This clause of the license restricts modification (DFSG §3) because ... which was found to a modification restriction in debian-legal thread (link to legal thread via lurker[2]) instead of: This clause of the license restricts modification because ... I'm not proposing: Violates DFSG 3 (Even though I use this shorthand myself for licenses that are trivially non-free.) Don Armstrong 1: Yes, yes, my day job is molecular biology... 2: see http://people.debian.org/~terpstra/ -- links to it are permanent, whereas list.debian.org links currently move about as spam is removed from the archive. -- The attackers hadn't simply robbed the bank. They had carried off everything portable, including the security cameras, the carpets, the chairs, and the light and plumbing fixtures. The conspirators had deliberately punished the bank, for reasons best known to themselves, or to their unknown controllers. They had superglued doors and shattered windows, severed power and communications cables, poured stnking toxins into the wallspaces, and concreted all of the sinks and drains. In eight minutes, sixty people had ruined the building so thouroughly that it had to be condemed and later demolished. -- Bruce Sterling, _Distraction_ p4 http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: [Maybe OT] License problem
Hello Otto, Let me try to summarize your situation to make sure I understand: 1. You have a piece of software that you wish to be Open Source. 2. That software uses icons and images, which are interchangable as a theme. 3. You wish to allow companies to distribute their own icons and images as a replacement for the default -- and have few restrictions on those icons and images. 4. Regardless of what happens with #3, you still want the code itself to reman Open Source. Here's my recommendation: License the code under the GPL. Make the code have hooks to load the icons and images at runtime (so that they are not required at build time). If you want, you can even add something like this to your copyright statement: As a special exception, theme materials such as icons and images that you create for this program are not considered to fall under this License, and you may distribute them with whatever license you choose. Though that is probably not really necessary. -- John On Thu, Mar 11, 2004 at 09:43:50PM +0100, Otto Wyss wrote: I've started a new OpenSource project but can't decide which license is best suited. Since there isn't any other place to ask about licenses I ask it here even if its just partially interesting for Debian. In case there is a better place just say so. My project is OpenSource an should be Debian compliant so if eventually chosen it should fit into main. The project has 2 parts, one is the code which will be OpenSource and one is theme (icons, images, etc.) which might be either OpenSource or propretary. The project will always contain a code part and a theme part, both OpenSource but it should be possible for a company to sell the code part with their own proprietary theme. First I don't know if I have to take any precautions and if I have to license the two parts separatly. Also I don't know which license best fits this case. I currently intent to use the wxWindows license mostly because I use it in other projects. What would you advice me? O. Wyss PS. My project isn't currently public announced, if someone needs to have a look to answer the above question just ask me direct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License for the Torque Resource Manager (RFC)
Roberto Gordo Saez [EMAIL PROTECTED] writes: So it's definitely non-free, in addition to what you say below. I think I understand you to have said that conditions 1 and 2 don't apply any more; in that case, can you have the copyright holder remove them? That would be much, much more clear and safe. -Brian The expiration note is included with the license text, maybe you have missed it. The copyright holder has removed the expiration date in the current version of the license. Because of that, i think that the license used in Torque correspond to a previous release of OpenPBS (?). I can try to contact them anyway... I did see the expiration date, and while its meaning is unambiguous I do not think it clear. Certainly, it would be *more* clear, and better in all ways, to not have those clauses then to have them preceded by a note that they do not apply. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: License for the Torque Resource Manager (RFC)
Roberto Gordo Saez [EMAIL PROTECTED] writes: The source code for OpenPBS is available, but the current license is not free (http://www.openpbs.org/license.html). This is almost the same license that the one used in Torque, with a only a small but important change; the license for Torque has this additional phrase: After December 31, 2001, only conditions 3-6 must be met Conditions 3 and 4 refer to condition 7. Is this license meant as some sort of sadistic logic puzzle for lawyers? -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
