[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New DFSG Draft revision #3



On Thu, Jan 14, 1999 at 11:40:36AM -0800, Darren Benham wrote:
> [I sent this originally to -devel.  Since I don't have a lot of confidence in
> -devel right now (I havn't seen a post most of 1/13 and only 2 on the first
> half of 1/14) I'm going to post this again, to -private]
[..]

I've got many nits to pick and complaints to make.  It's largely better
than the original DFSG2 and much of what's in it I can agree with.  I
still don't like the format.



> Contents
> --------
[...fills a screen...]


Is this really necessary?  =p  This is part of what I mean about format. 
I can understand why seperating things you must allow and things you
might require is probably a good thing, but I don't like it much
personally.  I think we should perhaps not use it if we intend to keep
the social contract and DFSG together in the same file, but it might be
more sane if they were in seperate files and just referred to eachother. 
Cosmetic perhaps, but IMO goes to readability.



> 1. Introduction 
> ----------------
[..]


Again, I don't think this is needed if we're including this with the
social contract as that should define the scope and set forth the goals
and lead into the DFSG.  If the DFSG will stand on its own however this
isn't needed.



> 1.1. Terms 
> -----------
> 
>      _software_ - The work covered by the license. This includes the source
>      code and executables. This does not include third party software. <For
>      example, header files> 
> 
>      _deprecated_ - allowed but discourage and disliked. These items may be
>      done away with in future versions. Also, software without deprecated
>      clauses are recommended over software with such clauses in the
>      license. 
> 
>      _licensee_ - the person who has the software and wants to use, change,
>      distribute or store it. 


Noteworthy that you define software as software, not software and
documentation.  This is intentional I hope?  =>

I'm not sure if these things aren't obvious.  This is one of those
differences between having something clear to begin with and having to
define everything for you.



> 2.1. Use 
> ---------
> 
>      Anyone must be able to use the software in any way without paying a
>      fee or royalty. <Not specificly part of the old DFSG>
> 
>      <This does not prohibit the author from asking for donations as long
>      as the donations are completely voluntary.> 


Guiltware is allowed?  Heh.  While the above is not part of the old DFSG,
it seemed to be pretty much implied/obvious to me at least.



> 2.2. Source Code 
> -----------------
> 
>      Source code must be available and redistributable. <Old DFSG point 2> 


....without royalty or fee.   <--- important



> 2.5. Termination of License 
> ----------------------------
> 
>      The license must remain valid until the licensee terminates it or if
>      the terms of the license are violated. <Not part of the old DFSG> 


IMO important addition.



> 3.1. Limitation of Liability 
> -----------------------------
> 
>      The license can give any warranty or no warranty. It can also have
>      notices saying the copyright holder is not responsible for errors and
>      omissions in the software.
> 
>      _or_<which is better or something else?>
> 
>      It may be a condition of the license that the copyright holders are
>      not held legally responsible for errors and omissions in the software
>      (in so far as permitted by applicable law).
> 
>      <Not part of old DFSG> 

I would probably rewrite this section, but the content is good.



> 3.4. License of Derived Works 
> ------------------------------
> 
>      The license can require modified and derived software be distributed
>      under the same license or with any other restrictions as long as the
>      new software is still DFSG-Free. <Also part of old DFSG point 7> 

This is pretty much saying it'll allow "This is under a GPL-like license,
but you are required to release modifications under MIT license so we can
sell them without permission."  This was a bad move as we saw with the
original QPL (which I could say I'm intimately familiar with) and was not
allowed by the original DFSG.  I am unconvinced we should start allowing
it now, this is the kind of change I am not sure we should make.


>      <Ouch, anyone have a better wording for this? The old was: `The
>      license may make requirements about the kinds of licenses (or the
>      specific license) under which the work, or that part of the work
>      included in derived works, is covered, so long as it remains possible
>      to distribute derived works under these guidelines.'> 

I'll take a closer look after some discussion and see about wording
changes.


>      The license may extend this restriction to third-party libraries
>      linked to the software at compile time, run time or both. It may not
>      apply this restriction to software that merely resides on the same
>      system or distribution as the licensed software. _<OR>_ The license
>      can restrict the third-party libraries used in creating modified or
>      derived works only on the basis that the licenses must be compatible
>      with it's own. It may not restrict software that merely resides on the
>      same system or distribution as the licensed software. 

Here too.



> 3.6. Integrity of the Original Work 
> ------------------------------------
> 
>      The license may use any of the following methods to ensure the
>      integrity of the original work: <Old DFSG point 4> 
[..]
> 3.6.3. Concurrent installation of Official and Derived Works (deprecated) 
> --------------------------------------------------------------------------
> 
>      Modified software may be required to be able to exist on the same
>      system as the official release of the software. <For example by
>      requiring derived works to use different executable names to the
>      official release.> 
[..]
> 3.6.5. Patch clause (deprecated) 
> ---------------------------------
> 
>      Source level modifications may be required to be distributed as the
>      original source with a list of differences. 

I'd merge these with something clever for a heading and indicate the
former is preferred to the latter.



> 4.5. Example Licenses 
> ----------------------
>         * the Q Public License (QPL)
(we hope anyway)  =>


-- 
"Lennier, get us the hell out of here!"
"initiating 'getting us the hell out of here' maneuver."
                               -- Babylon 5


Reply to: