the provide, license verbs

[Rick Moen]

Quoting Chris F Clark (cfc at TheWorld.com):

> The "problem" is that corporations like to define their coproprate
> self, including all those that they hire or sub-contract from as a
> single entity, just like the "end user you" (which may by the same
> extension be a family all sharing one computer).

As someone else said, the only opinion that matter, in such cases, are
His Honour's.

> I think that someone will also sue over making a private derivative
> version too.  However, I don't know if such a suit is possible under
> an open source license as I believe all current open source licenses
> reserve the right to make derivatives to the recipient, and I believe
> further that to be OSI-compatible they must do so.

Correct.  (I think you mean "convey", not "reserve".)

> I have often contemplated writing an open source license that requires
> derivatives to be made "publicly" available (either by publishing or
> by sending back to the author who can then publish).  

An earlier version of the Apple Public Source License (currently at 2.0) 
contained such a provision.  It was judged OSD-compliant (because, well,
it _was_ OSD-compliant), occasioning some mildly unpleasant spats between
commentators who found the provision reasonable and others (e.g., Stallman) 
who considered it to infringe privacy rights nobody had previously
considered in that context.

> However, working with a lawyer to get such a license drafted is an
> expensive proposition and would only result in
> yet-one-more-incompatible open source license, which is not a good
> thing in my eyes.

Thank you.  Too few people worry about gratuitous licence
incompatibility and other related problems.

Relevant to that, here's a off-list e-mail I sent to someone whose
company is currently involved in OSI licence certification (but will go
nameless).  About my sketch of stepwise corporate follies, he says
"Bingo".

Would OSI consider trying to do something about its Web site's tendency
to promote creation of basically pointless new open-source licences?
I'd be glad to help.



 Date: Wed, 9 Jun 2004 17:38:41 -0700
 From: Rick Moen <rick at linuxmafia.com>
 To: [omitted]

Quoting [omitted]:

> Yes, we have this lawyering problem here.  At our last
> meeting with our attorney we complained that much bigger
> companies than ours can use the Common Public License,
> why can't we.  Still have no clear answer.  It may be in
> the best interest of the OSI to dig in and declare a
> moratorium on new licenses, except they appear to be
> in the business of reviewing and approving licenses, so...

I wish they would.  In that sense, they're in a tarpit of their own
devising:  If you tell the corporate world "Here are the hoops you must
jump through to get your very own MyOwnDamnedLicence OSI approved"
without giving them a strong disincentive against doing so needlessly, 
it's predictable that vast numbers of them will do so.

The approved list at http://www.opensource.org/licenses/ doesn't even
say the most important thing:  

   "With rare exceptions, if you use a licence other than BSD (new or
   old), MIT/X, GPL, LGPL, MPL, CPL, AFL, OSL, you're probably dooming 
   your project to gratuitous and pointless licence incompatibility with 
   third-party codebases and ensuring that it will be ignored by the 
   very developers you're trying to reach by adopting open source.
   Most of the other licences on this list are traps for the unwary, 
   since their use tends to marginalise any codebase put under them.
   If you secure for your project(s) OSI approval for yet another 
   new licence without an extremely compelling (to outside developers) 
   reason for its existence, you might as well not bother, because,
   in a year or two, you'll either be relicensing everything to one of 
   the main licences or (if you're slow on the uptake) sitting around 
   wondering why open source didn't "work".

Meanwhile, Russ Nelson typically has to plead with the mailing list's
regulars to review new candidate licences, since, statistically, the
latter are almost all pointless.

What might be useful would be an OSI-blessed licence taxonomy covering
the major choices, and a pointedly-worded notice that submitters of new
licences should explain why none of the majors sufficed and what's
innovative in the candidate text.

Unfortunately, firms tend to do the following:

1.  CEO finally decides that open source is worth a try.  Issues
    vague mandate.
2.  Matter is judged to involve legal matters, and so is referred to 
    corporate counsel.
3.  Corporate counsel notes OSI approval process, crafts
    MyOwnDamnedLicence in some eccentric fashion to fit.
4.  Technical flunkie is delegated to shepherd MyOwnDanmedLicence
    through OSI approval process.  Flunkie has no other authority, and
    is merely charged with jumping the hoops.  Thus, complaints from
    OSI land that the initiative is ill-conceived fall on deaf ears,
    since the only parties who could change things are the 
    corporate counsel (who doesn't care) and the CEO (who doesn't know).
5.  OSI approval eventually having been secured, the relicensing occurs.
    Developers note that wacky licence and quietly ignore the project.
6.  Some years later, VP of Engineering announces that "open source 
    doesn't work" and pulls the plug.  CEO is disappointed but never 
    hears relevant details.

Even the Mozilla project has been driven to abandon its former MPL-only
strategy and work on securing permission to dual-license (MPL/GPL) all
the modules -- and that's even though MPL _is_ an innovative and useful
licence.  http://www.mozilla.org/MPL/relicensing-faq.html 

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