SocialText license discussion--call for closure of arguments

[Michael Tiemann]

Last December the SocialText folks made the decision to submit their
licnese for review, which we appreciate.  The license-discuss list has
been full of discussion, but that discussion has not yet been reduced to
a coherent argument either for or against.  Rather, we have heard many
many opinions as to what one person does or doesn't like about the
SocialText license, attribution in general, or positions that others
have advanced for or against either topic.

As I see it right now, either the OSI Board can attempt to pick up all
these disparate pieces, try to place them together (where they fit)
separate them (where they conflict) and then judge whether one position
or another is more compelling in light of the OSD.  That's an easy task
when all the pieces fit together and all land strongly to one side.
In the case of the SocialText license, I feel there's significant risk
that if we take on the responsibility of making the arguments, we may
create a bias that is not faithful to the real arguments you want to
make.  Therefore, we'd like to invite those who think we should not
approve the SocialText license to work out a common position on *why* we
should not approve it, which could inform how SocialText could remedy
your concerns.  And we'd like to invite those who think we should
approve it (or should approve it with some minor change) to work out a
common position on why we *should* approve it.  If one or both sides are
willing to do this, I think that the Board's decision process will
appear much more transparent.

One way or another, the Board owes SocialText and the open source
community a ruling, and we'd like to do as good a job as we can.  If the
challenge to organize is taken up, we'll set a timetable based on input
from the position leaders.  If no organization effort is apparent, the
board will take it upon itself to make the decision by the end of next
month (which gives time for one meeting to discuss and one meeting to
decide).  Thanks!

M

[Andrew C. Oliver-2]

Sounds rational.  Suggestions:

1. Set up two mailing lists (I can do that if Russ's services are not
available to that task)
2. Schedule 3 IRC meetings for each group (temporally separated) - I
don't have an IRC server but we can probably use any number of public ones
3. Set up 3 public read-only, private (for those on the list/IRC chats)
read-write wiki pages (I can also do that) where two separate position
papers can be written.

-Andy

PS I'm willing to coordinate the "against", but there are more qualified
people on this list for that.

Michael Tiemann wrote:

> Last December the SocialText folks made the decision to submit their
> licnese for review, which we appreciate.  The license-discuss list has
> been full of discussion, but that discussion has not yet been reduced to
> a coherent argument either for or against.  Rather, we have heard many
> many opinions as to what one person does or doesn't like about the
> SocialText license, attribution in general, or positions that others
> have advanced for or against either topic.
>
> As I see it right now, either the OSI Board can attempt to pick up all
> these disparate pieces, try to place them together (where they fit)
> separate them (where they conflict) and then judge whether one position
> or another is more compelling in light of the OSD.  That's an easy task
> when all the pieces fit together and all land strongly to one side.
> In the case of the SocialText license, I feel there's significant risk
> that if we take on the responsibility of making the arguments, we may
> create a bias that is not faithful to the real arguments you want to
> make.  Therefore, we'd like to invite those who think we should not
> approve the SocialText license to work out a common position on *why* we
> should not approve it, which could inform how SocialText could remedy
> your concerns.  And we'd like to invite those who think we should
> approve it (or should approve it with some minor change) to work out a
> common position on why we *should* approve it.  If one or both sides are
> willing to do this, I think that the Board's decision process will
> appear much more transparent.
>
> One way or another, the Board owes SocialText and the open source
> community a ruling, and we'd like to do as good a job as we can.  If the
> challenge to organize is taken up, we'll set a timetable based on input
> from the position leaders.  If no organization effort is apparent, the
> board will take it upon itself to make the decision by the end of next
> month (which gives time for one meeting to discuss and one meeting to
> decide).  Thanks!
>
> M
>
>
>
>  

--
No PST Files Ever Again
Buni Meldware Communication Suite
Email, Calendaring, ease of configuration/administration
http://buni.org

[Ernest Prabhakar]

Hi Andrew,

On Jan 19, 2007, at 2:22 PM, Andrew C. Oliver wrote:

>> Therefore, we'd like to invite those who think we should not
>> approve the SocialText license to work out a common position on  
>> *why* we
>> should not approve it, which could inform how SocialText could remedy
>> your concerns.  And we'd like to invite those who think we should
>> approve it (or should approve it with some minor change) to work  
>> out a
>> common position on why we *should* approve it.  If one or both  
>> sides are
>> willing to do this, I think that the Board's decision process will
>> appear much more transparent.

> Sounds rational.  Suggestions:
> 1. Set up two mailing lists (I can do that if Russ's services are  
> not available to that task)
> 2. Schedule 3 IRC meetings for each group (temporally separated) -  
> I don't have an IRC server but we can probably use any number of  
> public ones
> 3. Set up 3 public read-only, private (for those on the list/IRC  
> chats) read-write wiki pages (I can also do that) where two  
> separate position papers can be written.

If someone wants to do that, great.  However, I don't think we need  
to wait for that. Plus, there's some value in the "for" and "against"  
crowd (and everyone else) vetting each other's ongoing documents.

I think it would suffice for us to simply have clear subject lines, a  
la:

SocialText: FOR - Draft 1
SocialText: AGAINST - Draft 2
etc.

That is, as long as people kept on-topic within a thread, we could do  
the bulk of the work on this list; if necessary, the primary writers  
could setup their own ad-hoc chats wherever they liked.

Thus, all we need is for one person on each side to kick-off the  
thread with the appropriate Subject, and people can self-select from  
there.  It doesn't have to be a great post, just a strawman to get  
things rolling.

Any takers?

-- Ernie P.

[Rick Moen]

Quoting Michael Tiemann (tiemann@...):

> Last December the SocialText folks made the decision to submit their
> licnese for review, which we appreciate.  

Point of clarification:  _Did_ SocialText in fact submit a licence?  
What I remember seeing was a one-paragraph patch ("GAP" = Generic
Attribution Provision) that could be applied against unspecified
existing licences, presumably including but not limited to MPL v. 1.1
(though the proposal I saw did not say so).

Do I correctly guess that the Board is construing that as, effectively,
a submission for OSI certification of the result of concatenating MPL
v. 1.1 + the GAP paragraph?

It strikes me that before the merits of a licence can be meaningfully
evaluated, the proposer ordinarily needs to... well... submit a licence.
At least, that's what it's always said on
http://www.opensource.org/docs/certification_mark.php#approval , to the
best of my recollection.

(OSI of course may want to construe as indicated, or similar, in the
name of moving things forward.  I just wanted to point out the confusion
that has been caused by SocialText's not following the documented
procedure, to the best of my knowledge.)


--
Cheers,           A mosquito cried out in pain:       The cause of his sorrow
Rick Moen         "A chemist has poisoned my brain!"  Was para-dichloro
rick@...                                   Diphenyltrichloroethane.

[Matthew Flaschen]

Michael Tiemann wrote:
> Therefore, we'd like to invite those who think we should not
> approve the SocialText license to work out a common position on *why* we
> should not approve it, which could inform how SocialText could remedy
> your concerns.  And we'd like to invite those who think we should
> approve it (or should approve it with some minor change) to work out a
> common position on why we *should* approve it.  If one or both sides are
> willing to do this, I think that the Board's decision process will
> appear much more transparent.

I don't understand why the Board feels this is necessary.  This is a
discussion list, and I think people's arguments have naturally developed
that way.  This level of formality has never been requested before (to
my knowledge), and seems a bit like instruction creep.  I certainly
oppose the idea of creating separate lists and IRC channels.

Matthew Flaschen

[Timothy McIntyre]

As for the invitation for submissions "for" and "against" the approval
of the SocialText-submitted "generic attribution provision," I would be
willing to prepare a position in favor of the license, perhaps with a
few small modifications.  I would be happy to work with anyone else who
favors approving the license.

Essentially, I think the SocialText license should be approved for the
same reasons that the OSI approved the Attribution Assurance License.


____________________________________________________
Timothy McIntyre // General Counsel
Terracotta // Open Source Clustering for Java

www.terracotta.org

[Andrew C. Oliver-2]

> I don't understand why the Board feels this is necessary.  This is a
> discussion list, and I think people's arguments have naturally developed
> that way.  This level of formality has never been requested before (to
> my knowledge), and seems a bit like instruction creep.  I certainly
> oppose the idea of creating separate lists and IRC channels.
>
>  
The separate list and channels was just an idea (like working groups).  
I DO think having a few real-time discussions would be good.  No
matter.  I think they're trying to get US to organize the two positions
rather than just hashing it out and then leaving it to them to find
everything and sort through a few megs of data.  Otherwise its just a
lot of back and forth on a mail list and then no formal data on how it
did or did not influence the process.  Are you willing to help put
together an organized set of arguments collaboratively with others?

-Andy
> Matthew Flaschen
>
>  


--
No PST Files Ever Again
Buni Meldware Communication Suite
Email, Calendaring, ease of configuration/administration
http://buni.org

[Ben Tilly]

On 1/19/07, Timothy McIntyre <tmcintyre@...> wrote:
> As for the invitation for submissions "for" and "against" the approval
> of the SocialText-submitted "generic attribution provision," I would be
> willing to prepare a position in favor of the license, perhaps with a
> few small modifications.  I would be happy to work with anyone else who
> favors approving the license.
>
> Essentially, I think the SocialText license should be approved for the
> same reasons that the OSI approved the Attribution Assurance License.

The key argument against the SocialText license is item 10 of the OSD.
 This is a test that the Attribution Assurance License never had to
pass since it was approved before that clause was added to the OSD.
Furthermore the terms of the Attribution Assurance License are
substantially less problematic in this regard than the terms of the
SocialText license.

Therefore that precedent is a very weak argument for approving the
SocialText license.  And does absolutely nothing to address the main
criticism of the license.

Cheers,
Ben

[Rick Moen]

Quoting Timothy McIntyre (tmcintyre@...):

> Essentially, I think the SocialText license should be approved for the
> same reasons that the OSI approved the Attribution Assurance License.

You mean, for the "reason" of having not, at that time, yet gotten around
to writing OSD provision #10?  That reason would seem to no longer apply.

It's funny how many of these Web 2.0 firms seem to think the OSD is just
a series of talking points, that can be selectively ignored.

--
Cheers,      "Transported to a surreal landscape, a young girl kills the first
Rick Moen     woman she meets, and then teams up with three complete strangers
rick@...       to kill again."  -- Rick Polito's That TV Guy column,
              describing the movie _The Wizard of Oz_

[Matthew Flaschen]

Rick Moen wrote:
> Quoting Timothy McIntyre (tmcintyre@...):
>
>> Essentially, I think the SocialText license should be approved for the
>> same reasons that the OSI approved the Attribution Assurance License.
>
> You mean, for the "reason" of having not, at that time, yet gotten around
> to writing OSD provision #10?  That reason would seem to no longer apply.

Not to mention the subtle yet significant differences between AAL and
GAP that I reviewed earlier
(http://crynwr.com/cgi-bin/ezmlm-cgi?3:msp:12136:ccpbmhndbgpfnpnikjbp).

Matthew Flaschen

[Rick Moen]

I replied to Timothy McIntyre (tmcintyre@...):

> > Essentially, I think the SocialText license should be approved for the
> > same reasons that the OSI approved the Attribution Assurance License.
>
> You mean, for the "reason" of having not, at that time, yet gotten around
> to writing OSD provision #10?  That reason would seem to no longer apply.
>
> It's funny how many of these Web 2.0 firms seem to think the OSD is just
> a series of talking points, that can be selectively ignored.

And, lo!  Terracotta, Inc. turns out to be _yet another_ Web firm with a
MPL 1.1 + "Exhibit B" badgeware licence, the "Terracotta Public License",
http://www.terracotta.org/confluence/display/orgsite/Download 

...which it's been going around claiming in public to be "open source":
http://www.terracotta.org/

I actually should have remember that datum from my listing of about
twenty members of this little lobbying effort, from my own article
(http://linuxgazette.net/134/moen.html).  But my point is:  I'm getting
the really strong impression that there's been some consultant going
around to all these firms making a modest living telling them:

o  Just append an advertising clause to MPL 1.1 so onerous that no
   competitors are going to be able within reason to assert their OSD#6
   rights to use the code for any purpose.  And then claim in public
   that it's open source, which you'll get away with if you

o  Carefully avoid submitting your licence for OSI certification.
   (Notice that even Socialtext, which has deservedly been praised for
   submitting its GAP patch for scrutiny, has carefully avoided
   submitting the licence it actually _uses_.)  And, if questioned:

o  Claim it's obviously OK because OSI has approved "attribution" licences
   like the Attribution Assurance License in the past.  They'll never
   notice the sleight of hand, because they seldom pay much attention,
   generally.

Well, Timothy, we _are_ paying attention, now.

Anyway, I wonder who that consultant could have been?  


Noted without comment (http://blogs.zdnet.com/BTL/index.php?p=3430):

   Finally, there is also the issue of who some of these companies have
   turned to in order to author these licenses. Mark Radcliffe is an
   attorney who is General Counsel to the Open Source Initiative. But
   Radcliffe has also authored some of these licenses. According to
   Larry Rosen, who used to serve as General Counsel to the OSI, having
   that title doesn't exactly pay the bills. So, its customary for the
   OSI's legal counsel to also practice law in their area of expertise,
   outside of the OSI. For Rosen, that involved writing software licenses
   and the same goes for Radcliffe.  [...]

--
Cheers,              "The front line of defense against such sophisticated
Rick Moen            viruses is a continually evolving computer operating
rick@...  system that attracts the efforts of eager software
                     developers."  -- Bill Gates        

[Matthew Flaschen]

Andrew C. Oliver wrote:
> The separate list and channels was just an idea (like working groups).
> I DO think having a few real-time discussions would be good.  No
> matter.  I think they're trying to get US to organize the two positions
> rather than just hashing it out and then leaving it to them to find
> everything and sort through a few megs of data.  Otherwise its just a
> lot of back and forth on a mail list and then no formal data on how it
> did or did not influence the process.  Are you willing to help put
> together an organized set of arguments collaboratively with others?

Yes.  I suppose this is reasonable, but I will be concerned if a
different process is applied for the next license.  I oppose the
provision in its current form, so I'll first point to some key posts
arguing against it.  My apologies for any misinterpretations or unfair
crediting:

David Woolley originally questioned the "same size" term (something
changed from AA to GAP)
(http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:11904:jfkjkakegkfbihlhcbbn).

Michael Tiemann implied the license may be unjustified special pleading,
and noted that many organizations and companies (including Red Hat) have
succeeded on the current model
(http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:11929:jfkjkakegkfbihlhcbbn)

Nicholas Goodman brought up the still unanswered question of whether two
programs with different GAP brands can be combined
(http://crynwr.com/cgi-bin/ezmlm-cgi?3:msp:11929:jfkjkakegkfbihlhcbbn).
   Rick Moen later elaborated on this in
http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:12034:200612:oiccemjkkoffgnlmoebm
, wondering whether both logos would have to be displayed and asserting
that this could become a substantial burden.

He also later invoked OSD #10 explicitly
(http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:11992:200612:oiccemjkkoffgnlmoebm),
saying that the license should at least have an exception for programs
without a GUI.  John Cowan reiterated this, questioning what would
happen if someone used badgeware code in a commandline app
(http://crynwr.com/cgi-bin/ezmlm-cgi?3:msn:11996:oiccemjkkoffgnlmoebm).

I noted that GAP could not be seen as a "middle ground", because it is
meant for application to any license (not only the more permissive ones
like MPL)
(http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:12080:200612:oiccemjkkoffgnlmoebm)

Rick Moen noted that GAP was different enough from AAL to mandate
separate consideration
(http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:12101:ccpbmhndbgpfnpnikjbp).
   This inspired me to analyze the differences between AAL and GAP, and
conclude they all harmed OSD compliance.
(http://crynwr.com/cgi-bin/ezmlm-cgi?3:msn:12101:ccpbmhndbgpfnpnikjbp)
I believe the most harmful addition is "same size",

Ben Tilly first brought up the vital point that OSD #10 didn't exist
when AAL was approved
(http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:12135:dlaoeafkbfdnkpjnojmk).
 In my own opinion, this makes it fundamentally flawed as a
justification now.

This clearly isn't an organized oppose position, but it has all the
points one should contain (in my view).

Matthew Flaschen

[Lawrence Rosen]

I copied the following from
http://crynwr.com/cgi-bin/ezmlm-cgi?3:msp:11904:jfkjkakegkfbihlhcbbn.

Is there a verb or two missing where I wrote "[+++]" below? Also, where is
the rest of the provision that specifies what must be done with the "display
of the same size...?" The text below can't possibly be the complete
provision because it is not a complete sentence nor does it actually contain
an obligation to do anything specific with attribution notices. /Larry

********************

Generic Attribution Provision

Redistributions of the [original code] in binary form or source code
form, must ensure that each time the resulting executable program [+++],
a display of the same size as found in the [original code] released by
the original licensor (e.g., splash screen or banner text) of the
original licensor's attribution information, which includes:

(a) Company Name
(b) Logo (if any) and
(c) URL

********************

[Matthew Flaschen]

Lawrence Rosen wrote:
> I copied the following from
> http://crynwr.com/cgi-bin/ezmlm-cgi?3:msp:11904:jfkjkakegkfbihlhcbbn.
>
> Is there a verb or two missing where I wrote "[+++]" below? Also, where is
> the rest of the provision that specifies what must be done with the "display
> of the same size...?" The text below can't possibly be the complete
> provision because it is not a complete sentence nor does it actually contain
> an obligation to do anything specific with attribution notices. /Larry
>

This has been brought up before.  That link is of course the real
provision submitted.  I brought this up (and indeed may have
overanalyzed it) at
http://crynwr.com/cgi-bin/ezmlm-cgi?3:msp:12136:ccpbmhndbgpfnpnikjbp ;
basically they modified AAL in a hurried and careless way.  No one has
corrected it (it's kind of a recurring theme that people suggest
improvements, but Socialtext ignores them).

Matthew Flaschen

[Andrew C. Oliver-2]

I'm discounting all emotional content of messages in this thread and
focusing on the
constructive content.
> o  Just append an advertising clause to MPL 1.1 so onerous that no
>    competitors are going to be able within reason to assert their OSD#6
>    rights to use the code for any purpose.  And then claim in public
>    that it's open source, which you'll get away with if you
>  
Do you think this is a fair argument (OSD #6)?  It seems to me for this
to be justified the
license would have to specify this clearly: "Must not be used by FirmX"
or "Must not be used to XYZ"

While other licenses, such as Zimbra's which is mentioned in the license
go far enough I think to make the argument that it would be
"impractical", I don't think the license we're discussing goes that
far.  I interpret it to warrant space on the splash screen or any
startup notice similar to the original software (I see other problems
with this but not OSD #6).

Can you clarify or make a stronger case for why it makes #6 impossible?

-Andy

--
No PST Files Ever Again
Buni Meldware Communication Suite
Email, Calendaring, ease of configuration/administration
http://buni.org

[Andrew C. Oliver-2]

As I have attempted to incorporate each of these arguments where they
seemed
valid here: http://www.buni.org/mediawiki/index.php/GAP_Against

Matthew Flaschen wrote:

> Andrew C. Oliver wrote:
>  
>> The separate list and channels was just an idea (like working groups).
>> I DO think having a few real-time discussions would be good.  No
>> matter.  I think they're trying to get US to organize the two positions
>> rather than just hashing it out and then leaving it to them to find
>> everything and sort through a few megs of data.  Otherwise its just a
>> lot of back and forth on a mail list and then no formal data on how it
>> did or did not influence the process.  Are you willing to help put
>> together an organized set of arguments collaboratively with others?
>>    
>
> Yes.  I suppose this is reasonable, but I will be concerned if a
> different process is applied for the next license.  I oppose the
> provision in its current form, so I'll first point to some key posts
> arguing against it.  My apologies for any misinterpretations or unfair
> crediting:
>
> David Woolley originally questioned the "same size" term (something
> changed from AA to GAP)
> (http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:11904:jfkjkakegkfbihlhcbbn).
>
> Michael Tiemann implied the license may be unjustified special pleading,
> and noted that many organizations and companies (including Red Hat) have
> succeeded on the current model
> (http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:11929:jfkjkakegkfbihlhcbbn)
>
> Nicholas Goodman brought up the still unanswered question of whether two
> programs with different GAP brands can be combined
> (http://crynwr.com/cgi-bin/ezmlm-cgi?3:msp:11929:jfkjkakegkfbihlhcbbn).
>    Rick Moen later elaborated on this in
> http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:12034:200612:oiccemjkkoffgnlmoebm
> , wondering whether both logos would have to be displayed and asserting
> that this could become a substantial burden.
>
> He also later invoked OSD #10 explicitly
> (http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:11992:200612:oiccemjkkoffgnlmoebm),
> saying that the license should at least have an exception for programs
> without a GUI.  John Cowan reiterated this, questioning what would
> happen if someone used badgeware code in a commandline app
> (http://crynwr.com/cgi-bin/ezmlm-cgi?3:msn:11996:oiccemjkkoffgnlmoebm).
>
> I noted that GAP could not be seen as a "middle ground", because it is
> meant for application to any license (not only the more permissive ones
> like MPL)
> (http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:12080:200612:oiccemjkkoffgnlmoebm)
>
> Rick Moen noted that GAP was different enough from AAL to mandate
> separate consideration
> (http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:12101:ccpbmhndbgpfnpnikjbp).
>    This inspired me to analyze the differences between AAL and GAP, and
> conclude they all harmed OSD compliance.
> (http://crynwr.com/cgi-bin/ezmlm-cgi?3:msn:12101:ccpbmhndbgpfnpnikjbp)
> I believe the most harmful addition is "same size",
>
> Ben Tilly first brought up the vital point that OSD #10 didn't exist
> when AAL was approved
> (http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:12135:dlaoeafkbfdnkpjnojmk).
>  In my own opinion, this makes it fundamentally flawed as a
> justification now.
>
> This clearly isn't an organized oppose position, but it has all the
> points one should contain (in my view).
>
> Matthew Flaschen
>
>  

--
No PST Files Ever Again
Buni Meldware Communication Suite
Email, Calendaring, ease of configuration/administration
http://buni.org

[Rick Moen]

Quoting Andrew C. Oliver (acoliver@...):

> I'm discounting all emotional content of messages in this thread and
> focusing on the constructive content.

For Web page summaries and other analysis, that is certainly a good idea.  
I maintain that there is also room, during discussion, for justified
annoyance at transparently and insultingly bogus arguments, especially
from interested parties such as Mr. McIntyre.

By the way, my thanks to you and Matthew for what looks like a good job
of attempting to summarise.  (I'll find time to look more closely, soon.)

> >  Just append an advertising clause to MPL 1.1 so onerous that no
> >   competitors are going to be able within reason to assert their OSD#6
> >   rights to use the code for any purpose.  And then claim in public
> >   that it's open source, which you'll get away with if you
>
> Do you think this is a fair argument (OSD #6)?  It seems to me for
> this to be justified the license would have to specify this clearly:
> "Must not be used by FirmX" or "Must not be used to XYZ"

Yes, I think it's absolutely a fair argument.  OSD #6 originated, I
believe, as a reaction in part to the many "free for non-commercial use"
licences popular in academia prior to the BSD and X11 licences'
emergence at UCB and MIT -- e.g., those of Mosaic from NCSA at U. of
Illinois; COPS (Computer Oracle and Password System), SAINT, and (early)
Tripwire from Perdue University, etc., that put out academic-licensed
"free" products to popularise code, while reserving some or all
commercial rights.

The purport of OSD #6 is that, by contrast, must be freely usable for
any purpose, specifically including commerce on an equal footing.  Thus
the wording of the "Rationale" on the OSD page:

   Rationale: The major intention of this clause is to prohibit license
   traps that prevent open source from being used commercially. We want
   commercial users to join our community, not feel excluded from it.

("Any purpose", above, is not construed to bar licences that withhold
the right to create proprietary forks, i.e., copyleft licences.)

Now, there is no specific part of OSD #6 or anywhere else in that
document that says "must be usable for any purpose other than
(optionally) creation of proprietary derivatives" -- not exactly.  It's
understood, that being one of the core _ideas_ that OSD is trying to
formalise.  OSI hasn't _yet_ felt it necessary to say in the OSD "must
not be commerce-impaired, as long as it's equally commerce-impaired for
everyone but the copyright holder" -- just as OSI didn't find it
necessary to say "License Must Be Technology-Neutral", that being also
an implied consequence of the OSD's core notions, until things like that
Attribution Assurance Licence came around and clarified the need for
that clause.


So, I would maintain, the key question is whether this class of licences
aim to impair commerce.  For the "Exhibit B" licences -- those _actually
used_ by the likes of SugarCRM, Zimbra, Alfresco, Qlusters, Jitterbit,
Scalix, Terracotta, Cognizo Technologies, MuleSource, Communiva, Dimdim,
Agnitas, Openbravo, Emu Software, ValueCard, Open Country, 1BizCom,
KnowledgeTree, and Sapienter Billing Software, I think the answer is
unquestionably "yes", and I'm obliged to Nicholas Goodman for pointing out
that they themselves have made this starkly clear:
http://www.nicholasgoodman.com/bt/blog/2006/12/22/badgeware-ceo-to-community-buy-a-commercial-license/

Googman quoted Mulesource executive Dave Rosenberg to that effect:

    So, if you use Mule in your software product and sell it
    commercially, then you are required to either make a
    licensing deal with us or keep the "power by Mule" logo
    visible. Just as so many other things in OSS are confusing,
    it appears that this too has created some consternation --
    primarily because people want to embed Mule in their products
    and couldn't quite make sense of how the attribution would work.

    My answer was simple. You make a deal with us for a commercial
    license and then you do whatever you want.

So, the idea is "Well, sure you could in theory sort of use our code
in commerce, but we want to make it so unattractive to you that you'll
come back to us and buy a separate commercial-use licence at our asking
rates -- if we're offering one at all."  That's the Mosaic / COPS /
Tripwire / SAINT licensing model, slightly softened and updated for the
new millennium.  It's not open source.


That's the "Exhibit B" licences (that are being actually used).  The
separate question remains of the Generic Attribution Provision patch
paragraph, as applied against MPL 1.1 or one of the other 57
OSI-approved licences.  (Again, Socialtext did not submit a _licence_,
so by implication, in theory we have 58 patch cases to consider.)

Reasonable people might differ as to whether GAP's requirement
substantively impairs commerce for all but the copyright holder.  
(I find it interesting that nobody actually _uses_ GAP + any licence,
yet:  Intalio proposes to use MPL 1.1 + GAP, but hasn't yet done so.)

   Redistributions of the [original code] in binary form or source code
   form, must ensure that each time the resulting executable program, a
   display of the same size as found in the [original code] released by
   the original licensor (e.g., splash screen or banner text) of the
   original licensor's attribution information, which includes:

(I join others in wondering where Ross Mayfield's verb escapted to,
from that "display of the same size" clause:  Mutatis mutandis, it's
good for licence phrasing to be in coherent English.)

Notice that the GAP text (above) doesn't actually place any limit on the
intrusiveness of the "display":  It must be of "the same size".  If
that's a corporate logo in 500 point type, then all derivative works
must include it unchanged.

I submit that that clause as stated -- making allowance for the mangled
English -- _does_ greatly impair commercial use for downstream users,
for that reason alone.

It would be interesting to see a rewrite of GAP -- perhaps one in whole
declarative sentences -- that more arguably doesn't impair commercial
use.  (There's nothing _inherently_ wrong with the idea of a mandatory
advertising clause, per se.)

--
Cheers,                    Higgledy-Piggledy / Kibo Ubiquitous,
Rick Moen                  Greps for his name in the / Happynet spool.
rick@...        Interdimensional / Cyberspace deity:
                           Didaktyliaios / Dada is cool. -- Lewis Stiller

[Michael Tiemann]

On Fri, 2007-01-19 at 18:42 -0500, Matthew Flaschen wrote:

> Michael Tiemann wrote:
> > Therefore, we'd like to invite those who think we should not
> > approve the SocialText license to work out a common position on *why* we
> > should not approve it, which could inform how SocialText could remedy
> > your concerns.  And we'd like to invite those who think we should
> > approve it (or should approve it with some minor change) to work out a
> > common position on why we *should* approve it.  If one or both sides are
> > willing to do this, I think that the Board's decision process will
> > appear much more transparent.
>
> I don't understand why the Board feels this is necessary.  This is a
> discussion list, and I think people's arguments have naturally developed
> that way.

Usually the discussions have led to a fairly strong consensus, making
the approval process quite straightforward.  As I said, if nobody wants
to collect all the bits and try to present them coherently, we'll work
with what we have, but there's already an effort to do that, which I
believe will lead to a better result (both a better decision and a
better understanding as to why the decision was reached).

>   This level of formality has never been requested before (to
> my knowledge), and seems a bit like instruction creep.  I certainly
> oppose the idea of creating separate lists and IRC channels.

Yes--me too.  We can organize the thoughts without excluding people from
the process.

M

[Matthew Flaschen]

Rick Moen wrote:

> Anyway, I wonder who that consultant could have been?  
>
>
> Noted without comment (http://blogs.zdnet.com/BTL/index.php?p=3430):
>
>    Finally, there is also the issue of who some of these companies have
>    turned to in order to author these licenses. Mark Radcliffe is an
>    attorney who is General Counsel to the Open Source Initiative. But
>    Radcliffe has also authored some of these licenses. According to
>    Larry Rosen, who used to serve as General Counsel to the OSI, having
>    that title doesn't exactly pay the bills. So, its customary for the
>    OSI's legal counsel to also practice law in their area of expertise,
>    outside of the OSI. For Rosen, that involved writing software licenses
>    and the same goes for Radcliffe.  [...]

I find the comparison of Rosen and Radcliffe somewhat misleading, since
it doesn't mention that all of Rosen's licenses are now (as far as I can
tell) OSI-approved.

Matthew Flaschen

[Matthew Flaschen]

Rick Moen wrote:
> Notice that the GAP text (above) doesn't actually place any limit on the
> intrusiveness of the "display":  It must be of "the same size".  If
> that's a corporate logo in 500 point type, then all derivative works
> must include it unchanged.
>
> I submit that that clause as stated -- making allowance for the mangled
> English -- _does_ greatly impair commercial use for downstream users,
> for that reason alone.

It simply impairs all derivative work, and thus doesn't fully comply
with OSD #3

> It would be interesting to see a rewrite of GAP -- perhaps one in whole
> declarative sentences -- that more arguably doesn't impair commercial
> use.  (There's nothing _inherently_ wrong with the idea of a mandatory
> advertising clause, per se.)

AAL's language, made gramatically correct and with an exception for
works without an interface, would be interesting.

Matthew Flaschen