Approval request for BXAPL

[Abe Kornelis]

Dear all,

With Nathan Kelley I have had a discussion, that has
halfway turned private, i.e. we both forgot to cc the
list. Since Nathan agreed with me that it would be a
good idea to let you all in on the discussion, I have
made a surmise of the various mails that have not
yet been on this list, and adding comments to the
last mail I just received from Nathan.

Nathan, should you detect any errors, just holler
and put all the blame on me. I've already shown
how fallible I am, so it's quite ok ;-)

Hope you'll all enjoy.

Abe F. Kornelis.
===========

From: Nathan Kelley <phyax at runbox.com>

> >> I have read the Bixoft Public License (proposal version). I believe
> >> that it is consistent with the Open Source Definition, and meets the
> >> requirements for OSI certification.
> >>
> >> However, I do have a few questions on it:
> >>
> >> Item 10: The stated intention is to "denote software items that use
> >> the Software, but that are not Derivatives of it". But do the
> >> provisions of 10 achieve that? What modifications to the programming
> >> tools, as stipulated in c), are sufficient to make the output a
> >> derived work?
> >
> > Modifications to the Programming Tools will create a Derived work, as
> > dictated by Copyright Law. When I started out, no such thing as
> > Dependent Software existed, neither in my mind nor anywhere else. In
> > the process of refining however, it dawned upon me, that regarding any
> > software made with a programming tool as a Derivative imposes
> > unrealistic restrictions on the author of such 'derived' software. So I
> > introduced the term 'Dependent Software' and tried to define it as
> > software that makes use of the programming tools without modifying
> > them. The distinction thus draws upon the Copyright Holder designating
> > Programming Tools as such. I tried other approached for making the
> > distinction but could not find anything that satisfied. So, as long as
> > Dependent Software contains no Modifications to the Programming Tools
> > in the Software, it is just that; otherwise it becomes a Derivative and
> > must be subjected to the more stringent redistribution rules in the
> > license.
>
> OK. You might then want to use the term "Modifications", capitalised as
> shown, to indicate it refers to modifications as per your glossary
> definition. Otherwise, it *might* technically indicate that even things
> like changing configurations for compilation, like the output path,
> could be classified as modifying the Programming Tools, which would make
> the output derived.

Abe: Such options would normally be passed as invocation parameters,
      passed on the command line or through a script of some kind.
      This in no way constitutes a modification. On the other hand,
      since by copyright law definitions any translation yields a derived
      work, I wonder how relevant this might be? Output of a compilation
      or assembly is *always* a derived work, no matter how the compile
      was done, by which compiler (version), of how it was invoked.

Nathan:
Yes, it does. And this is a *big* practical problem with Item 10. Use of
programming tools licensed under the Bixoft Public License would be very
low, because not only could developers be required to distribute their
work under the Bixoft Public License (even if they don't want to), but
as their software would be a derived work, they could be required to
send it to the copyright holders, gratis, at any time, even if they
built the entire thing from scratch.

This should be fixed in a revised version of the Bixoft Public License.
I believe this can be done in one of two ways:

1. Change c) to read "they do not make Modifications to the Programming
Tools or their function in any way". Since "Modifications" as per the
glossary is limited to source code, c) would only take effect if the
programming tools were actually modified at the source level, or

Abe: That looks like a very good idea. I don't know why I never
      put in Modifications as defined. I think it should have been
      formulated that way. Thanks for suggesting this.

Nathan:
Great! :-)

Nathan: (continued from previous remark)
2. Remove c) altogether, and add a requirement that any Modifications to
the Programming Tools are distributed along with the source of the
software, along with a notice stating which version of what software
from what vendor the modifications apply to.

Abe: If I leave it in, the choice is the author's either distribute it as
      dependent software, including any mod's to the tools,
      or keep the two separate and enjoy the much larger freedom
      granted for dependent software. I might make a choice for
      'all whom it may concern'  but it will never satisfy all of them,
      so I prefer to leave the decision to those who will bear the
      'burden' of living by the consequences of that decision...

Nathan:
I think you meant "...either distribute it as dependent software,
including any mod's to the tools, or keep the two separate and enjoy the
much larger freedom granted for dependent software...", correct? Either
way, implementing one of those options solves the problem equally well
in my book.

Abe: (new reply)
        Sorry, incorrect. Maybe a typo on your part, using the term
        dependent software twice? What I meant is:
        "... either distribute it as a Derivative, including any mod's to
         the tools, or keep the two separate and enjoy the much
         larger freedom granted for Dependent Software..."

Nathan: (continued from previous remark)
I like option 2 best, since I believe that still embodies the original
intent of what you wanted Item 10 to accomplish.

Abe: As you probably understand by now, for me it is exactly
       the other way around.

Nathan:
Yes, you explained your position quite well.

> >> Item 16: I could be completely wrong here, but a) seems to effectively
> >> create a situation where patent holders would pay others for use of
> >> their own patents, while all third parties would be allowed to
> >> continue infringement - with the only alternative being to withdraw
> >> the claim. Is this correct? While I would love to see some large
> >> patent holders taken down a peg or two, I believe this will be ruled
> >> unenforceable should it ever get to court.
> >
> > Steve already answered this one, but I'd like to add my tuppence:
> > First: an infringement claim does not imply actual infringement until
> > the court's decision has become irrevocable and indisputable. Second:
> > the claim for royalties is for the Software, whether infringing or not.
> > The royalties are not for the patent, since the situation arises only
> > when these are under dispute. It is mainly intended to prevent the
> > 'Patent Holder' from raising a claim and at the same time using the
> > Software without any retribution. If the Patent Holder wants to get
> > something out of his/her patent, then he/she should also be willing to
> > pay a fair amount for using the Software. Third: I did not make this
> > up, I think I have been 'inspired' by the CPL/IBMPL.
>
> I understand that "innocent until proven guilty" is a core tenet here.

Abe: Of course. Apart from that, it is not the Copyright Holder's
      obligation to settle anything with the Users, in case patent
      infringement is proven. If such a thing should ever happen it
      is up to the owner of the patent to settle agreements with
      any User infringing their patents.

Nathan:
OK, I see where you're coming from here. That solves one of the problems
I had with Item 16.

Nathan's text, continued:
> Unfortunately, patent law has always been designed so that the owners of
> the patents receive monies from those using them.

Abe: Just like copyright law has been designed so that the owners of the
      copyrightes works (read software) receive money from those using
      them, right?

Nathan:
...or to make the software open, as in this case :-)

Abe: That is but one of the alternatives... And even so, I doubt it
       was ever envisaged when those laws and related international
       treaties were (de)signed. Even so, open source and asking
       money for the *same* software still is highly viable.
       If I am informed correctly even the GNU license allows
       dual licensing policies. Read: "this software is freely
       available. If you would like our support, please contact
       us, we also sell the software *with* support."

Nathan:
Yes, you can sell the software. Many OSI-certified licenses let you do
this. Most of them don't include a clause to require either people or
organisations based on their status (litigant patent holder) to hand
over the cash. It's not effective at making money, and it's a very close
call when it comes to use as a bargaining chip.

Nathan's text, continued:
> While there isn't really anything wrong with the way item 16 is put
together,

Abe: I just tied the two things together: if you want money from me for your
      patent, then I want money from you for my software. I.e. if you *do*
      use my software. If their is no 'use' it will be hard to charge for
      it, right?

Nathan:
Right. But the point I saw was that the rest of the license, aside from
Item 16, indicates that anyone can use, modify, and re-distribute the
software essentially gratis. My concern was that, in the unlikely event
this ever got to court, it could be ruled unenforceable, on the grounds
that it is essentially a 'retaliatory' clause.

Abe: I've never heard the term before, but I get the meaning.
      Essentially, it *is* a 'retaliatory' clause. Does that invalidate
      it? In some jurisdictions it may, in others it may not.
      If ever anyone needs to go to court with the BXAPL in
      hand, then resorting to this clause apparently will have to
      be done judiciously. If it's unenforcible under your
      particular circumstances, then don't resort to it. Or try
      anyway - barking sometimes helps... But again: I only see
      disadvantages, no advantages, if I am to make the
      descision beforehand, and for all jurisdictions,
      worldwide.

Nathan:
That's a very good point. It probably wouldn't be invalidated by
jurisdiction, but rather ruled on by a judge at proceedings. My concern
falls into two categories:

- If the litigant patent holder does not use the software, and has only
obtained it insofar as to look for patent infringement, then Item 16
gives the author(s) no bargaining power. As you pointed out before, this
is not the BXAPL's problem.

- If the litigant patent holder does use the software, then I can see
them petitioning the judge for Item 16 to be ruled unenforceable. The
essential argument would be that Item 16 only exists to hamper the
ability of patent holders to legally and fairly enforce their patents.
To some degree this is true.

Abe: (new reply)
      No, no, no!
      Sorry, but I must disagree most vehemently. Par.16 does not
      exist to hamper patent holders. It only says: If you want money
      for a license on your patent, fine, if it is indeed yours. But don't
      expect us to allow you to use our software for nothing in return.
      In return for the money we owe you for a license to your
      patent we request that you pay us a reasonable sum for using
      our software.
      I might have put it otherwise: the license might forbid any
      User to claim patent infringement. Then par.3
      http://www.bixoft.nl/english/license.htm#par03
      says that the User either must comply or obtain a different
      license. Does it make a large difference?

Nathan: (continued from previous remark)
Cases I've read about in
the past saw the judge set aside 'retaliatory' clauses in license
agreements, although those were admittedly U.S. law, not Dutch (as in
your case) or Australian (as in my case).

Nathan's text, continued once again:
> I still see
> the fact that a well-worded petition to the judge would see it ruled
> unenforceable...

Abe: According to dutch law, this seems rather unlikely, but i'm not
      a lawyer, so I cannot be too sure. American law might see this
      differently, but it seems illogical to me, that I may not ask money
      for my software, even if I allow others to use it freely.

Nathan:
See above. Asking for money in this way doesn't technically violate the
OSD, but has practical problems as Forrest J. Cavalier III already
pointed out on the list.

Abe: Quite indeed. It's main purpose is not to raise money,
      rather it *may* serve as a negotiation factor. That's what it
      is there for. It might raise opportunities for talking things out
      in bilateral negotiations, rather than going to court.

Nathan:
Based on the above, I don't think it will work. But that's all me. If
you believe it will, then leave it in as is.

And the last strand of Nathan's text:
> at which point we get precedent, at which point item 16
> becomes essentially useless for protecting open-source developers.

Abe: I don't know. It sounds rather pessimistically to me, and
      quite a long shot on top of that.

Nathan:
See above. I agree with you it's a very long shot... it's just that Item
16 stuck in my mind while I was reading the license :-) The fact that
it's such a long shot was why I suggested that Item 16 may not need any
modification, even though I would like to see the practical problems
with it eliminated.

Abe: Ah, that would be nice. I've reworked that text many times over.
      The original IBM and Jabber texts contain a comparable clause.
      As stated in the remarks, I've done my best to 'translate' their
      legalese into decent English. So, don't blame me for inventing
      it, even though I assume full responsibility for copying and
      adapting it in my own BXAPL.

P.S. Thus far our dsicussion has been private,
not on the list that is. Do you have any objections
if I'd resend my messages to the list? That way
others have a chance of joining in and giving
their opinion.

Nathan:
Not at all! I've left the thread intact above so you can do that easily.

Abe: I've tried to make somewhat more accessible. Hope I succeeded.



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