Commentary on how my proposed AL compares to Ben's proposed AL

In this message, I attempt to document how I have addressed all the issues
from Ben's proposed version of the AL.  The easiest way to read this
commentary is have my proposed AL (based on 2.0beta2) along with Ben's open
in other windows/buffers.  I use section numbers to make the commentary less
verbose.

Ben's Preamble:

  The main change that I made is that I no longer declare that it is
  intended for dual-license situations.  I believe that I have cleaned
  things up enough that we might use it in other ways too.  I am checking
  that out for sure now.  But, I will try to write a stabilized AL that
  people can use alone if they want to, even if we don't ask them to.

Ben's Section 1.1:

  This is covered in my proposed Preamble and in my proposed Definitions
  section.  I kept definitions that were closer to the original AL, because
  I believe they were more clear than Ben's.

  For example, saying "Standard Version" is "any such work which falls
  entirely under this AL" may actually preclude the Standard Version from
  being dual-licensed.  I am not sure; but anyway, it's not necessary to say
  that there in the license.  It can be said in the copyright notice if it
  needs to be said at all.

Ben's Section 1.2:

  I don't believe there is a legal idea of "satisfying" a copyright.  A
  copyright license is satisfied, but not a copyright itself.  I do indeed
  address the issue of satisfying the license, mostly in section (10).

Ben's Section 1.3:

  This issue is addressed in sections (1) and (9) of my proposed AL.
  
Ben's Section 1.4:

  While what Ben's 1.4 says is correct, I don't think we need to scare
  people by reminding them that it's true legally under copyright law, since
  the intent of the AL is to allow people to do those things freely.  So, I
  spell out that such things are permitted in sections (8) and (9).

Ben's Section 2:

  The statements made before the subsections are addressed in my Preamble
  and in section (10).

Ben's Section 2.1:

  I cover many of these definitions in the "Definitions" section.  I don't
  think distinction between "Original Version" and "Standard Version" is
  completely clear in Ben's version, and thus it's problematic.  I think
  separating into "Standard Version" and a "Modified Version" is enough.  I
  think Ben was trying to address the issue of "What if someone gets a
  non-Standard Version, which is now a Modified Version---it's not *really*
  a modified version?"

  We don't need to worry too much; under copyright law, the sections
  referring to the "Standard Version" cease to be relevant if someone is
  distributed a Modified Version.  Plus, I addressed the issue of "a
  Modified-Modified version" somewhat in section (4) anyway.

Ben's Section 2.2:

  I don't think that combinations of AL'ed work is something that we need to
  address.  There is no need to "suggest" that one accept an agreement each
  time; there is in fact no other way to do it.  If you all think it's
  completely necessary, we can address this in the Preamble.  However,
  addressing it in the license isn't really correct, since one is required
  to accept each instance of the license, regardless of what we say in the
  text of the license itself.

Ben's Section 2.3:

  I believe this is addressed directly and in the same way in section (3) of
  my proposed license.   I believe my text covers a few more bases, but
  basically it's the same idea: patches from the maintainers themselves
  don't make the work a Modified Version, as defined by the license.

Ben's Section 2.4:

  I address this very issue in the same way (more or less) in section (1).
  One key thing I don't require is that when its modified internally, that
  they note changes made.  This doesn't seem like a key issue---if they
  distribute it outside, they will have to add such notices anyway by
  the redistribution requirements.


Ben's Section 2.5:

  This is a note concerning policy regarding contributions.  I don't believe
  that most of what Section 2.5 says is needed in a license.  (It should
  stated elsewhere as a matter of policy for a given project.)  Anyway, that
  part that is pertinent concerning making contributions available to the
  Standard Version are mentioned in section (4a) of my proposed license.

Ben's section 2.7:

  This corresponds roughly to "Permissions for Redistribution of Modified
  Versions of the Package as Source" in my proposed license.

  However, I believe that the way Ben's license is written, one must somehow
  always provide source of the Standard Version, either via a *valid* URL or
  via giving a copy upon demand.  I think this requirement in Ben's license
  is to strict.

  It seems reasonable that if you distribute a binary of the Standard
  Version, you should include a pointer to the source that is valid at the
  *time*.  But, it's a big burden to require that a distributor always
  update that upon request.  For example, if Helpful Hacker provides a
  binary for the FooBar architecture of Package on his WWW site, I don't
  think (under the AL) that Helpful Hacker should need to do more than
  provide the link where the source came from, and make sure that link is
  valid as long as that FooBar binary is up.

  If it turns out that Helpful Hacker can't find the source anymore, taking
  down the FooBar binary should be enough to comply with the AL.  Under
  Ben's AL, Helpful Hacker would be required to go and find source upon
  demand.  This is a bit too restrictive, I think.


Ben's section 2.7.1:

  I believe that this issues is addressed in sections (8) and (9) in my
  proposed license.  I spell it out a bit more, but I believe that I cover
  what Ben was trying to cover there.


Ben's section 2.7.2:

  I do make this a requirement in section (5), when people distributed
  binaries built from the Standard Version.  My proposal does not require
  this if source is included, or if they clearly mark what they have
  changed.  I think that fits better with the spirit of the original AL.

  (see more in my discussion of 2.7 above).

Ben's section 2.7.3:

  I address this basic issue in (6) and in (4).  In my proposed license, one
  of the following this must happen:

     * the source of modified versions must be provided back to the
       developers and/or to the community at large.

     * everything must be clearly marked as changed and put in non-canonical
       places so it doesn't look like the user that the program is really
       "Package".

  Thus basically either "the world" has the Freely Available source what has
  been proposed and can consider the changes, or the Modified Version is
  called "FooPackage" instead of "Package".

Ben's section 2.7.4:

  I avoided this one.  I don't think we should put this burden on
  distributors.  If they've made their source Freely Available, or called
  the thing "FooPackage", I don't think we should obligate them to know
  where to get the Standard Version on behalf of someone else.

  (see more in my discussion of 2.7 overall).

Ben's section 2.8:


Ben's section 2.8.1:

   I have trouble figuring out the intent of this section.  I believe,
   though, that it has to do with "marking a modified version as modified",
   which I address in (6b) and (4b).


Ben's section 2.8.2:

   Addressed directly in (6b) and (4b).


Ben's section 2.8.3:

   I think this is just a special case of what 2.8.2 is trying to address,
   and I believe that (6b) and (4b) address them in my proposed version.

Ben's section 2.9:

   I believe that it is very difficult to make points like 2.9 tries in a
   copyright license without creating very unfriendly obligations for the
   redistributor, and thus I avoided it.

    For example, if someone introduces an honest bug, but doesn't have time
   to research it, it could put them in quite a pickle, requiring them to
   stop distributing.  And, distribution may still be useful for others to
   study the bug, so Ben's requirement that distribution be stopped might
   actually make things worse, not better.

   So, I don't have an equivalent section, but I try to address a similar
   issue in (9), stating that you get extra permissions relating to
   distributing things that don't *mean* to make the program work
   differently.

Ben's Section 2.10:

   You aren't permitted to this anyway, and saying it in a copyright license
   doesn't make it more true, since copyright law doesn't cover this issue
   at all.  I think a section like this just give the copyright holders and
   contributors a false sense of security, so I didn't add one.  This issue
   is addressed in libel and trademark law.

Ben's Section 2.11:

   I am not sure what 2.11 is trying to do.  It seems like it might be
   trying to avoid licensing conflicts, which it really can't do with a
   statement of that nature.  Conflicts are conflicts, no matter what a
   license says about trying to resolve them.

Ben's Section 2.12:

   This seems to be rehash of the permissions already given, so I didn't
   include it.


Ben's Section 3:

I used this almost verbatim.  It seems good.



-- 
Bradley M. Kuhn  -  http://www.ebb.org/bkuhn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE50pt+53XjJNtBs4cRAsbfAJ9lmM32MYYt2mP6oLueyCOYyysBbACeNnOT
tvyMCP/hhTtp2NmdY2c6ywg=
=HQwb
-----END PGP SIGNATURE-----