Approval request for BXAPL

Abe Kornelis abe at bixoft.nl
Wed Jul 3 20:26:38 UTC 2002


----- Original Message -----
From: Forrest J. Cavalier III <mibsoft at mibsoftware.com>
To: <license-discuss at opensource.org>
Cc: <mibsoft at mibsoftware.com>
Sent: Wednesday, July 03, 2002 4:45 PM
Subject: Re: Approval request for BXAPL


> This is a very complicated license.   Thanks for providing
> the remarks and annotations.  Very nice.
>
> After a quick read, I think that it should not be OSI approved,
> for numerous reasons, some follow.
>
> Because the license is so complicated, it is not clear
> to me that addressing the following points would be adequate
> to make it OSD compliant.  I think the two fundamental issues
> are
>   it very much seems to be a EULA, trying to function
>   under copyright law, and EULA's are hard to get through OSD.
--> it never was intended as a EULA. I fail to see why you would
       classify it as such. Would you please care to explain just how
       you arrived at this conclusion?

> and
>   the Rationale a) is very difficult to set forth legally.
--> It was indeed very hard - ultimately I found it so hard
      that I gave up trying - to find a 'generalized formulation'
      for creating the intended distinction. So I had to resort
      to each Copyright Holder explicitly stating the quality
      of each Software item, with the default being
      'not a Programming Tool' - for practical reasons.
      Is this legally difficult? As Steve mentioned in his
      reply, neither of us is a lawyer.

>   Any license which attempts to make such distinctions must get
>   extra scrutiny.  After all, the license ends up defining
>   "Programming Tool" as
>      "Any Software or portion of such Software
>      that is declared as being a "programming tool"
>      by the Copyright Holder. Such declaration must
>      be located in the Copyright Notice."
>    which I think is ripe for abuse and inconsistency in itself.
--> I don't see a loophole for inconsistencies. Any Software
       item either is or is not a Programming Tool, the distinction
       being made explicitly (or implicitly when defaulted to No)
       by the Copyright Holder.
       As for abuse: if I write a little "Hello World"-type
       program and designate it a Programming Tool,
       that would be quite silly, but is it abuse? The only
       to 'suffer' from the abuse is the Copyright Holder
       who is giving more freedom to the receivers of the
       Software than he/she would have done by *not*
       declaring the program a Programming Tool.

       Things get more complicated when you write and
       distribute a set of macros. These might be
       designated Programming Tools, or they might
        be distributed as 'not Programming Tools'.
        In the latter case, any software created with
        these macros would become a Derivative,
        implying that any distribution of such Software
        must be under the BXAPL - which would be
        a strange restriction - to say the least.
        Or do you see this differently?

> ------------------------
> The definition of "User" is too broad.  It allows any
> Distributor to force someone to be a "User" simply by
> sending them a copy.
--> As Steve pointed out, there is no harm in that.
      A User may do nearly anything with the Software.
      Serious obligations only raise their (ugly?) head
      when a User wishes to distribute the Software
      or any of his/her Derivatives. Certainly the mere
      fact of finding Software in your inbox does not
      force you to do anything with it? Or do I take this
      too loosely?

> ------------------------
> The "Source code" definition includes this statement, "Source files
> or members that contain obfuscated source do not count
> as Source Code."
>
> "Obsfucated" is not well-defined.  I've see a lot of legitimate
> source files that appear to be obsfucated.
--> Agree. The term "obfuscated" was taken from the OSD.
      I'm willing to consider any proposal for improvement.

> Other OSI-approved licenses have definitions of "Source."
--> So?

> Also, as written, I think this definition includes
> compilers and linkers (and more!  run-time ld? ) as
> Source code.
--> If you prefer to make modifications to the
      compiled version of your programs rather
      than by changing the source and then
      re-generating the objects, load modules,
      or whatever - have it your way. But you
      may find it hard to convince others that this
      would be truly the case.

> ------------------------
> Paragraph 6 says, in part:
>      No right is granted to the trademark(s) of any Contributor even if
such marks
>      are included in the Software. The names of Contributors or any of
>      their products may not be used in any way without prior written
>      permission from the pertinent Contributor. Derivatives and/or
>      Dependent Software may not be named after the Software, nor may
>      they be given a name that might be confused with the name of any
>      Contributor or any Contributor's products and/or trademarks.
>      Remarks
>
> Since "Contributor" is defined as to include any "Distributor" it is
> fundamentally impossible to know the set of Contributors.  Without
> knowing that set, it is impossible to know what names you are
> not permitted to use.
--> Protection of trademarks is covered by various laws.
      The whole point is mainly to close the loophole that might
      exist where an 'infringer' might cite the Software's being
      open or free as an excuse for 'stealing' a known trademark
      or software title.

> The "even if such marks are included" is a problem when you also
> require (in a separate paragraph) verbatim distribution of the
> software.  I read that as "when there is any trademark in the
> software, you are not permitted to distribute."
--> In my opinion that would not constitute the "use" of such
      trademarks. Would this not be so under US law?

> -----------------------
> Paragraph 10 claims that all items which "make use of ...
> the original or modified versions of the Software"
> are "Derivatives."
>
> That is plainly wrong.  md5sum will make use of the Software
> to compute the MD5 sum, and by Paragraph 10, md5sum is a
> "Derivative" of the Software.
--> Indeed. You apparently disagree about that.
      I fail to see why. Please explain.

> -----------------------
> Paragraph 12 uses the term "Distributor" and "Contributor" in
> a manner inconsistent with the definition in the Item 2.
--> I have tried very hard to prevent such things from
      occurring. Now par. 12 is rather large. In what way and in
      what parts of par.12 do you see any inconsistencies?

> -----------------------
> Paragraph 12.2 is unsatisfiable because the set of Contributors
> is unknown.  It is against the OSD because as I read it, any
> new "official" contributed modification will invalidate
> existing versions.  This constitutes the need for a "separate
> license": always checking some official site that there are no
> new contributions.
--> I fail to follow your reasoning. I fear you make steps in
      logic that are too large for me to follow. As it stands I can
      only say that I do not fully understand what you're
      hinting at.

Kind Regards, Abe



--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3



More information about the License-discuss mailing list