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
PGP signature
