Re: [License-discuss] Views on React licensing?

[Brian Behlendorf]

On Mon, 12 Dec 2016, John Cowan wrote:

On Mon, Dec 12, 2016 at 5:44 AM, Henrik Ingo  wrote:

  Many people, including significant producers of BSD software, believe
  that the BSD license is also a patent license.


MIT is on record as saying that the MIT license, which is otherwise equivalent 
to the 2-clause BSD license, does *not* grant a patent license.


Is there a link to this?  I've not found anything similar when I've 
looked, though I've made the same claims, in particular in reference to 
recent attempts by fraudsters to claim to be Satoshi Nakamoto so as to 
claim patent rights to his inventions (which were implemented in 
BSD-licensed works he published in ~2009).


Brian

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

[Brian Behlendorf]

Do those follow the same rules as copyright?  E.g., when done by a USG 
employee, it's public domain in the US?


Seems like those should get covered by whatever folks come up with.

Brian

On Fri, 19 Aug 2016, Smith, McCoy wrote:

Yes
USG files patents all the time


On Aug 18, 2016, at 5:51 PM, Brian Behlendorf <br...@behlendorf.com> wrote:


Totally agree.  But can the USG file patents?  I suppose research organizations 
can (MITRE, maybe even NASA?) so it's not that academic; but presumably any 
place where this public domain arises, it applies to patents too.  Would be 
nice to get that sorted.

Brian


On Thu, 18 Aug 2016, Chris DiBona wrote:
In military contracting , patent grants are key to the point where I wouldn't 
consider a non patent granting license from, say, lockheed as being open source 
at all.
On Aug 18, 2016 3:05 PM, "Tzeng, Nigel H." <nigel.tz...@jhuapl.edu> wrote:
 On 8/18/16, 3:57 PM, "License-discuss on behalf of Lawrence Rosen"
 <license-discuss-boun...@opensource.org on behalf of lro...@rosenlaw.com>
 wrote:

>Nigel Tzeng wrote:
>> The issue here is for code that is potentially quite substantial.  I
>>would think that would be a different scenario.
>
>If I include the works of Shakespeare in my software, it would of course
>be substantial and yet still be public domain almost everywhere (?).

 If patents aren't a concern then okay.  Copyright lasts longer than
 patents so for anything that is in the public domain because of age then
 no patents would still apply.

 There isn¹t a lot of code that has aged out.  Only code written between
 before 1963 and didn¹t get a renewal.

 ___
 License-discuss mailing list
 License-discuss@opensource.org
 https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

[Brian Behlendorf]

Totally agree.  But can the USG file patents?  I suppose research 
organizations can (MITRE, maybe even NASA?) so it's not that academic; but 
presumably any place where this public domain arises, it applies to 
patents too.  Would be nice to get that sorted.


Brian

On Thu, 18 Aug 2016, Chris DiBona wrote:

In military contracting , patent grants are key to the point where I wouldn't 
consider a non patent granting license from, say, lockheed as being open source 
at all.


On Aug 18, 2016 3:05 PM, "Tzeng, Nigel H."  wrote:
  On 8/18/16, 3:57 PM, "License-discuss on behalf of Lawrence Rosen"
  
  wrote:


  >Nigel Tzeng wrote:
  >> The issue here is for code that is potentially quite substantial.  I
  >>would think that would be a different scenario.
  >
  >If I include the works of Shakespeare in my software, it would of course
  >be substantial and yet still be public domain almost everywhere (?).

  If patents aren't a concern then okay.  Copyright lasts longer than
  patents so for anything that is in the public domain because of age then
  no patents would still apply.

  There isn¹t a lot of code that has aged out.  Only code written between
  before 1963 and didn¹t get a renewal.

  ___
  License-discuss mailing list
  License-discuss@opensource.org
  https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss


___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] Re: [Non-DoD Source] Re: U.S. Army Research Laboratory Open Source License (ARL OSL) 0.4.0

[Brian Behlendorf]

On Wed, 17 Aug 2016, Smith, McCoy wrote:
I hope you're getting a sense that there are several lawyers on this 
mailing list -- lawyers who have years of experience looking at, 
debating, and giving advice on the issues you identify in this 
submission -- who think that your proposed license is a variant of 
Apache 2.0 designed to solve a "problem" for USG users with Apache 2.0 
that we are skeptical even exists.  Perhaps the ARL lawyers can clarify 
what the problem is, and that we are missing something.  But I think at 
least I am having a hard time understanding how this license does 
anything that Apache 2.0 doesn't.


Is there something that a non-governmental entity can do to help with 
this, by simply redistributing under AL2.0 that which they obtained from 
ARL by "contract" such as this license?  E.g., if this license was used as 
the contributor agreement to a project hosted at the Apache Software 
Foundation, could it then be redistributed by the ASF under AL2.0, with 
appropriate credit given in a Contributing.md?  Being an IP laundry 
service for government is an awful reason to be an Apache project, but if 
there some other reason for ARL's code to be hosted there or at a similar 
organization (whether NGO or for-profit company even) that might solve the 
problem, and then doesn't have to worry about being an "open source 
license".  A government agency (or branch of the U.S. military) isn't 
really a great home for the governance of a code base and community 
anyways.


Brian
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] International Licenses

[Brian Behlendorf]

With regard to language: wouldn't it be more aligned with reducing license 
proliferation to work with existing license stewards to encourage 
authorized translations?  Have there been license submissions in foreign 
languages yet, and have those submitters been resistant to the idea of 
adopting a translated existing license?


With regard to jurisdiction: do we have evidence that existing licenses 
can't be enforced as per the intent of the license stewards in certain 
juridictions because they use terms differently, or there are assumed 
defaults in that jurisdiction that simply don't exist?  If so, wouldn't it 
be more aligned with reducing license proliferation to work with existing 
license stewards to iterate existing licenses to adjust their language (or 
add jurisdiction-specific terms) to address these exceptions?


I recognize the cultural hegemony of suggesting to someone of another 
language or culture to use a translation of an old work, rather than 
respect their original work.  However I believe the risk of duplicative 
projects that don't work together merely because of inconsequential 
license differences to be a greater cost, as well as all the usual 
overhead with license prolif.  I would hope there are ways to bridge the 
cultural differences; the approach that Creative Commons took to 
internationalizing their license may be worth looking at.  I see the GPL 
has a page for unofficial translations; the unofficial status seems to be 
due to a lack of funding rather than cultural import.  And that has not 
kept the GPL from spreading to large parts of the non-English world.


https://www.gnu.org/licenses/translations.en.html

Brian

On Thu, 4 Jun 2015, Mike Milinkovich wrote:

At our last face-to-face meeting, the OSI Board discussed the topic of FLOSS 
licenses targeted at specific languages and jurisdictions. As you can imagine, 
with the interest in
reducing license proliferation, the conversation was quite lively. However, if 
we want open source to be a truly worldwide movement, it seems unreasonable to 
insist that English be
the only language allowed. 

As a result, we would like to propose the following:
 *  A new category of open source licenses would be created for those targeting 
specific languages and jurisdictions.

 *  The normal public license review process would be used to debate the merits 
of the license. However, we would add a criteria targeted at preventing code 
under the class of
licenses from being orphaned. (This may, for example, be addressed in 
candidate licenses by explicitly allowing re-licensing under other well-known licenses.)

 *  A certified English translation must accompany the license. We require a 
certified English language translation of the license in order to conduct the 
license review process,
which uses open discussion between many people who share English as a 
second language regardless of their first language. Submitters can meet this 
requirement by accompanying the
translation with an affidavit from the translator on which the translator 
has sworn, in the presence of a commissioner authorized to administer oaths in 
the place where the
affidavit is sworn, that the contents of the translation are a true 
translation and representation of the contents of the original document. The 
affidavit must include the date of
the translation and the full name and contact details of the translator.

 *  When you offer your license(s) to the review process, you should be aware 
that change to the license is probable and be prepared to iterate. Certified 
translations will not be
essential for every iteration but the final iteration must be accompanied 
by a certified translation.
We would appreciate your thoughts and comments.

___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] license information improvement project - now with a mockup!

[Brian Behlendorf]

On Thu, 7 Nov 2013, Luis Villa wrote:
The board meeting notes, in every case that I'm aware of, are pretty 
uninformative- they simply say approved/not approved. I'm open to 
persuasion on this point, I suppose, but I'm inclined to see it as 
noise/additional clutter.  


It's the validation that indeed the approval happened - sort of like a 
commit message that just references an issue ID.  Even if minimalist, 
useful for traceability.


Brian
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] license information improvement project - now with a mockup!

[Brian Behlendorf]

Nice start!  Quick comments, all in humble opinion which is why I didn't 
make edits directly...


- Any suggestions on the presentation of the information? i.e., is 
simple bold headings OK? Should we do some fancy table thing instead? Do 
you like/dislike the : Information and : License Text I added to the 
h1 headers?


I think it should be clearly visually distinct from the text of the 
license itself, say in a different box with a different background color, 
just to make it clear to the first-time reader within a few seconds that 
this metadata is not the text of the license.  The table of contents for 
the license and the text of the license should be more closely visually 
aligned than this metadata.


- Any comments on what information is/isn't presented? (If you must have 
extensive discussion of the existing categories or the 
desirability/possibility of getting more objective information, please 
change the email subject header :)


A link to both the submission and the notes from the board meeting 
where the license was approved would seem good.


The link to license category should go straight to the license category 
page, not to the proliferation committee report.  On that page, each 
license category really should get the description/criteria for that 
category, rather than making the reader read through the report or guess 
from the list of licenses in each category to understand what the 
categories mean.


- Obviously this information will not all be available for all licenses. 
In those cases, should we simply omit reference to the information, or 
should we say something like Canonical text: the canonical text is no 
longer available or OSI discussion: this license was approved before 
OSI's current mail archive system, and so the discussion is no longer 
available? I think the latter.


The latter, though it would be really good to dig up archives and post 
them, perhaps specifically board meeting minutes where the licenses were 
approved.



- MOST IMPORTANTLY: Any volunteers to gather more information for more licenses?


I'll throw a hat in the ring as this gets more feedback.

Brian
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: testing kit conformance as a condition of distribution

[Brian Behlendorf]

Thank you to everyone who responded on this topic.  I used many of these 
thoughts in my panel appearance at JavaOne on Thursday morning; I can't 
find a video or transcript online anywhere yet, if I do I'll post it. 
8 people and 30 minutes meant the usual limits of getting to say what's on
one's mind.  I wanted to go into some specifics of situations that were
causing grief, but felt it was better to get the higher-level messages
across.  My main points:

- This is not about people asking Sun to give away any of their own IP;
this is about asking Sun to let us give away our own works under the 
copyright licenses we need to be effective.

- Compatibility and open source licensing are not at odds with each other;
the open source community can address compatibility, and usually sees
compatibility issues as defects to be fixed rather than contractual
violations to be litigated.
- Use trademark law as the tool to enforce compliance, not copyright.
Allow people to create non-conformant derivative works, so long as they
aren't claiming conformance.  Creating derivative works is a part of the
every day process of open source projects, and you can't TCK-test
everything.
- There is significant tension in the open source community between those
who want to work within the system, and others who are pushing ahead
with de facto standards, or leaving Java altogether.
- As 'open' as Java is compared to, say, Microsoft windows, we still have
extremely closed attitudes and licenses around TCKs, RI's, expert groups,
and more.  TCKs in *particular* should be open to inspection by all, it's
where peer review matters most.
In retrospect I was a wuss and could have said a few things, given some
specific examples, that I didn't.  I also suspected some Astroturfing 
given the wild applause anytime the we can't sacrifice compatibility! 
meme was said.  But, one less brick in the wall, I hope.

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

testing kit conformance as a condition of distribution

[Brian Behlendorf]

I know this list is supposed to be about reviewing proposed licenses 
rather than speculation, but hopefully you'll at least find this question 
more on-topic than most.

With respect to the language at the top of:
http://geronimo.apache.org/download.html
and for context:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=52
The NOTICE Sun is asking us to post seems, to me, to effectively 
constitute an additional term of copyright.  Such a term would not seem to 
be OSD compliant.  Empirically I can argue this easily, as no open source 
license has been approved with such a conformance requirement on 
derivative works (AFAIK).  The Sun Internet Standards Source License comes 
close, but it also allows the release of non-conformant works so long as 
the full source code to non-conformant works is available.  What I need 
are solid sound-bite-y easy-to-explain but non-dogmatic arguments as to 
why such a conformance requirement is not compatible with the way Open 
Source works (putting aside compatibility with any particular licenses).

Thanks in advance,
Brian
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Sixth Computer/Internet Roundtable: April 20, 2004, 12:00 p.m.-1:30 p.m.

[Brian Behlendorf]

Thought some folks here would be interested in this.

Brian

-Original Message-
From: The Computer Law Committee of the IP Section of the State Bar
Sent: Thursday, April 08, 2004 4:05 PM
Subject: Sixth Computer/Internet Roundtable: April 20, 2004, 12:00 p.m.-1:30 p.m.


The Computer Law Committee of the IP Section of the State Bar and the
National Entertainment and Media Law Institute at Southwestern University
School of Law invite inhouse counsel, private practice lawyers, the
Southwestern community, IP Section members and software executives to the
in-person  telephonic

Sixth Computer/Internet Roundtable

OPEN SOURCE: NEW SOURCE FOR LITIGATION LIABILITY?
RISKS IN THE WORLD OF SCO, LINUX AND OPEN SOURCE

A presentation and discussion with:

Jason Wilson - Willenken Wilson Loh  Stris LLP
Michael D. Scott - Southwestern Law School
Michael Krieger - UCLA Computer Science Department

Tuesday, April 20, 2004, 12:00 p.m.-1:30 p.m.

* Lunch and parking is complementary for in-person attendees

* In person attendance is limited so please register early

* Admission is complementary, but e-mail registration/RSVP is
required

* Conference call-in (800) provided for remote participants

* 1 Hour of MCLE Credit

Location: Southwestern University School of Law
3050 Wilshire Blvd. (the famed Bullocks Wilshire Bldg.)
Second Floor, Los Angeles, CA 90005

Map and driving directions to the school are at
www.swlaw.edu/campus/map.html
http://www.ieventreg.com/r/?MzRlNGZhMTFhZTkwMGExNTMzOTIwNWE2NTJmMTQ3MDQ
tcG1vcmlAY29sbGFiLm5ldA==

The Computer/Internet Law Roundtable is a periodic gathering of those
interested in the ever-evolving law of computers, the Internet and a
chance to learn of recent legal developments, explore the effects of
technology advances and exchange experiences and ideas about litigation,
legislation and policy. All - lawyers and non-lawyers alike - are
welcome.

AGENDA

12:00 Networking and Lunch
12:30 Conference call commences
 1. Introduction of the Roundtable
 2. Featured speaker and topic:

Open source (OS) as an alternative to Microsoft-like development and
licensing has grown into a mainstream issue in recent years. With the
filing of Caldera Systems, Inc. d/b/a/ SCO Group v. IBM Corp. (complaint
at www.caldera.com/scosource/complaint3.06.03.html
http://www.ieventreg.com/r/?OTBlNDRlNzVjZjhkN2EzNWU4YmE1YjYzMTdiMzI3Y2E
tcG1vcmlAY29sbGFiLm5ldA== ) SCO brought real risk, potential liability
and litigation into the Linux and OS worlds. Exposure that was
previously conjectural (the few suits filed had settled early) became
all the more real as SCO made good on threats to IBM's Linux users by
suing Daimler-Chrsyler and AutoZone.

An increasingly adopted software paradigm -- spanning entertainment to
industrial controls -- OS licensing and development holds both promise
and perils for the uninitiated, whether programmers or general counsel.
Yet, Linux -- poster-child of the OS movement and widely used operating
system for devices like cell-phones -- has increasingly unseated Windows
on corporate desktops, a trend accelerated by IBM's Linux evangelism.
Like a gathering lightening storm, SCO's aggressive posture -- said to
be funded by Microsoft -- has created fear and uncertainty among
potential corporate Linux users and their counsel.

Today's seminar, after a backgrounder in OS origins and licensing, will
explore the litigation risk to companies using open source software
internally and in products. Likewise, it will treat the basis, status,
and potential of the various SCO lawsuits with an eye toward how to best
protect one's clients from liability.

Biographies:

Jason H. Wilson, a partner in Willenken Wilson Loh  Stris LLP (Los
Angeles), has extensive experience litigating and trying patent and
other technology matters during the past 17 years. He frequently writes
and speaks on issues of trial and litigation assessment in technology
cases.
He previously was at Morgan Lewis  Bockius. Jason is a graduated of
Pomona College (B.A.), Harvard Law School (J.D. cum laude), and clerked
for the 9th Circuit, first for Judge O'Scainlain and two years later for
Judge Tang.

Michael D. Scott, a professor at Southwestern Law School and 30-year
computer law veteran, is widely known for authoring Scott on Computer
Law, Scott on Multimedia Law, and for editing such journals as the
Cyberspace Lawyer. Most recently, a partner at Perkins Coie LLP, he
also has held executive positions in several multimedia companies.
Michael is a graduate of MIT (B.S.), and holds a J.D. from the UCLA
School of Law.

Michael M. Krieger, has practiced computer law for nearly 20 years,
focusing on preventive and strategic litigation issues. Involved in
cryptology, technology transfer, Internet and open source issues since
they emerged, he has assisted clients ranging from startups to
international corpora-tions. Michael graduated Caltech (B.S.) and UCLA
(Ph.D.) in mathematics 

Re: License Committee report - regarding NASA Open Source Agreement Version 1.1

[Brian Behlendorf]

On Wed, 18 Feb 2004, Rod Dixon, J.D., LL.M. wrote:
 Regarding the issue concerning whether NASA may license software it cannot
 copyright in the U.S., the answer is yes, notwithstanding that significant
 harm to the conception of public domain for digital works is likely to
 follow.

And if there's anything actually useful in what they release, they should
expect U.S. developers to acquire under PD, derive, and sublicense,
thereby avoiding the NOSA requirements altogether.  But sure, go ahead and
approve it.

Brian

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

Re: For Approval: NASA Open Source Agreement Version 1.1

[Brian Behlendorf]

On Tue, 17 Feb 2004 [EMAIL PROTECTED] wrote:
 Brian Behlendorf scripsit:

  So what happens when I download the code under a FOIA/public domain issue,
  and then relicense under a BSD license?  Don't I have the right to
  relicense PD works?

 You can do anything you want to with a public domain work except try to assert
 a valid copyright on it, which is one of the incidents of the BSD or any
 other open-source license.  So, no.

So I have no right to create a derivative work of a public domain work and
release that derivative work under a license of my choice?  For example, I
can not take PD code and incorporate it into Apache httpd? I must
misunderstand what public domain means, then.

Brian

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

Re: apache license 2.0 for consideration

[Brian Behlendorf]

On Tue, 17 Feb 2004, Mahesh T. Pai wrote:
 Russell Nelson said on Mon, Feb 16, 2004 at 05:12:21PM -0500,:

   If nobody else reviews this license, then the license approval
 snip
   comply with the OSD (cough, cough).  But still, could somebody else
   take a gander at this?

 This license was discussed on [EMAIL PROTECTED], and I had seen
 quite a few regulars on this and debian-legal there; and in one mail,
 Eben Moglen of FSF wrote:-

 quote
 FSF notes  that section 5 is the  only element of ASL  2.0 that is
 incompatible  with version 2  of the  GNU General  Public License.
 FSF  continues to  believe that  the achievement  of compatibility
 between ASL and GPL would  be of enormous benefit to the community
 of  free software  developers,  allowing merger  of valuable  code
 bases  currently separated by  license incompatibilities.   FSF is
 pleased to note the convergence implied by the ASL 2.0 draft.  FSF
 will make efforts, in the development, discussion, and adoption of
 GPL  3  to  further  the  process  of  convergence,  by  carefully
 considering the Apache Foundation's approach to the patent defense
 problem.  For this reason, we consider the distinction between the
 approaches contained in the  first and second sentences of section
 5 to be particularly significant.
 /quote

 Sec. 5 referred to by Prof.  Moglen was Sec 5 of the original draft as
 proposed by the Apache Foundation.  This seems to have been renumbered
 as section 3 in the final license.

Also, the second sentence referred to above by Eben in the older draft
was the broader one that applied to any patent action taken against any
open source software product.  It was narrowed, in the draft that was
eventually officially approved, to only cover patent actions regarding
*the licensed software itself*, narrowing the scope but being much more
acceptable.

 Finally, on January 24th, Roy Fielding of the Apache Foundation stated
 on the same list:-

 quote
 They(*) are compatible.   Whether  or  not   they  are  considered
 compatible by the FSF is an  opinion only they can make, but given
 that a derivative work consisting of both Apache Licensed code and
 GPL  code can  be distributed  under the  GPL (according  to *our*
 opinion), there really isn't anything to be discussed.
 /quote

 Guess that settles the matter.

Well, Russ's matter is conformance with the OSD, not the GPL.  Nothing
came up in our own drafting and discussion of the ASL that suggested
something beyond the OSD's constraints.  The same basic contract is there
- use our code for whatever purpose you want, just give us credit, don't
call it Apache if it's your work, and caveat emptor.

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

RE: PCT (Patents, Copyright, Trademark) policy and Open Source

[Brian Behlendorf]

On Wed, 28 Jan 2004, Ken Brown wrote:
 http://www.eweek.com/article2/0,4149,1462778,00.asp

I love it.  They filed a patent for a process my company had a working
example of long before the date of filing, and unlike these guys, we
actually implemented it and ran it.  We don't run our site, SourceXchange,
any longer, but it's still infuriating to see IBM take credit for this.

If anyone had a need to debunk this patent, let me know.  Isn't there some
clearing house for prior art should it ever be needed?

Game theory lesson: file a patent on *anything* you're doing.  I'm
considering filing one on the particular way I walk down the hall after
waking up in the morning.

Brian

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

RE: Promotion of software patents == opposition to Open Source.

[Brian Behlendorf]

On Fri, 16 Jan 2004, Ken Brown wrote:
 I'd like to know this too.  This intrigues me.  Is IBM's proposition
 that they can make money with both IP and open source incorrect?

Of course they can.

 In my opinion, I do not believe that they IBM's model has a long-term
 future.  IP inextricably competes with the existence of GPL open source
 and open source in general.

You're drinking SCO's Kool-Aid.

Brian

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

Re: mysql

[Brian Behlendorf]

On Sat, 22 Nov 2003, Ian Lance Taylor wrote:
 I think a better word here is ``sticky.''  The GPL is a sticky
 license; once it is attached to code, it can't be removed.  The BSD
 license is not sticky; it can be removed (or at least the most
 important provisions can).

No, the terms in the BSD license can not be removed by someone
redistributing the work, or even a derived work from a BSD-licensed work
that is under a different license.  One can *add* new terms, though,
which the GPL forbids.

Brian

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

Re: mysql

[Brian Behlendorf]

On Fri, 21 Nov 2003, Ryan Damon wrote:
 I have a question about mysql's licensing terms.  They provide an
 option to license either under their proprietary license, or the GPL.
 According to their website (and from what I have heard from others),
 mysql says that if you are only going to use their software inhouse
 and not distribute it to others, you can license it under the GPL.
 However, if you want to distribute it to third parties as part of your
 proprietary software, you cannot.  They seem to say that this applies
 even if you keep the mysql code separate from your own code and
 communicate only through some kind of linking or socket.  It seems to
 me that their restrictions on distribution actually go against the
 terms of the GPL.  Are other companies doing the same thing, and is
 this kind of practice generally considered ok by the open source
 community and/or FSF?

I believe this is because the *client* libraries (including, for example,
the JDBC driver) are GPLd, and thus are linked more intimately with the
applications that use them than simply over sockets.  What I'm not clear
on is whether you can distribute an application that requires, but does
not include, the GPL'd JDBC driver or client libraries.  I would assume
MySQL would also argue that such dependency also requires a license, but
may have a tougher time proving that.

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

Re: Silly question: are usage restrictions covered by the OSD?

[Brian Behlendorf]

On Fri, 17 Oct 2003, Chuck Swiger wrote:
 Restrictions on how people _use_ software, such as you may only use my
 editor if you are writing open-source software, are more appropriately
 handled by end-user license agreements and contract law than by
 copyright law, at least if my understanding is correct.  Therefore, if
 the license that Chris has proposed does require active consent from
 the end-user in order to form a contract, it would fail OSD #10:

 10. License Must Be Technology-Neutral

 No provision of the license may be predicated on any individual
 technology or style of interface.  Rationale: This provision is aimed
 specifically at licenses which require an explicit gesture of assent in
 order to establish a contract between licensor and licensee. [ ... ]

It's curious how far apart the wording of #10 and its rationale are.

At any rate, it's been said by lawyers on this list that licenses like the
GPL would probably be evaluated as contracts by a judge, not just as
copyright licenses.  Many open source licenses contain provisions that
affect use - the patent termination clause in the APSL, for example
(paraphrased, your right to *use* APSL software is gone if you file a
patent claim against Apple).  There have been long threads on this list in
days past regarding whether open source authors *should* be seeking assent
before allowing their software to be downloaded, or at least before use -
some claim it would make our licenses that much less vulnerable to being
ignored by the user or mooted by a court, if I'm capturing the discussion
accurately.

Brian

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

Re: Silly question: are usage restrictions covered by the OSD?

[Brian Behlendorf]

On Thu, 16 Oct 2003, Chris F Clark wrote:
 On Wed, 15 Oct 2003, Arnoud Engelfriet wrote:
  This may be a silly question as I'm probably overlooking something,
  but as far as I can tell the Open Source Definition does not
  forbid any general restrictions on usage of software. The closest
  thing is No Discrimination Against Fields of Endeavor, but
  that only forbids exclusion of _some types_ of usage, not exclusions
  on usage by everyone.
 
  Would something like You may only use this editor if you release
  all works you create with it as open source software fail under
  OSD #6, and if not, why would it fail the OSD?

 I would argue that your clause (you may only use this editor if ...)
 fails OSD #6, because it prohibits the field of endeavor creating
 non-open source software.

I believe that's really stretching the term field of endeavor beyond the
original intent: to prevent terms that would prevent use of the software
in a business, or from being used for genetic research, with other
examples I've seen tossed around being:  to police in South Africa, to
Republican politicians, to oil barons, etc.  One could probably attempt to
define a license term that conflicts with any of the other OSD terms and
attempt to call it a field of endeavor, creating a loophole.  So, it's
pretty important to know what we mean about this term.

Searching Google, I've found field of endeavor used in other legal
documents to basically mean career, vocation, scientific pursuit, and
sometimes hobby - though usually more broad categories of
careers/pursuits, like geology, or aerospace engineering.  People seem to
generally refer to being only in one field of endeavor at a time, unless
someone has quite divergent talents and interests, such as simultaneously
being a geologist and a film historian.

 The question that this does not address is how your restriction
 differs from the restriction in the GPL, (you may only create a
 derived work from this software if ...).  That would also seem to
 prohibit the same field of endevour. However, the chief distinction is
 that concept of derived work.  There is no field of endeavor of
 creating derived works from software that you are not the author of
 unless the author grants you that right.  (This is one of the authors
 reserved rights under most theories of IP.)  That is, without
 permission to create a derived work, one cannot create derived works
 at all, and thus it cannot be a field of endeavor.

 However, in distinction, one can create non-open source software using
 ones own IP.  Thus, that can be a field of endeavor.  Moreover, one
 can use a different editor to create such software.  Thus, a usage
 restriction on a particular editor, would prohibit its use in that
 field of endeavor (which would otherwise be legal and thus a valid
 field of endeavor).  And to my mind that contrvenes OSD #6.

 However, IANAL.  Moreover, there is no court that has ever ruled on
 this particular point to say whether the argument is valid or not.

OK, this is an interesting theory, but it still rests on the assumption
that creating non-free software is a field of endeavor, which I'd
dispute.

 Still, I am interested in other peoples impressions of this argument.
 The reason being, I am considering drafting a license which makes
 approximately that distinction.  It is a license that is viral like
 the GPL except that it defines its point of requiring open sourcing
 of the resulting works the point of derivation rather than the point
 of redistribution. That is, one must release an open source copy of the
 derived work when one creates such a derived work, not only when one
 distributes such a derived work.  (There are many details to work out,
 which is why I have not submitted it for review.)

 I am hoping that such a restriction will not be considered
 contravening the OSD, and that the license will become approved.

Interesting twist.  For practical reasons I'd argue that a license clause
that is still triggered on distribution, but applies to all work, is more
likely to make sense than a license that is triggered upon the act of
creation - after all, when is that creative act, is it as soon as you
create a tarball, or is it once you've edited the file?  Are you going to
require public CVS trees for any derivative work?

Brian


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

Re: Silly question: are usage restrictions covered by the OSD?

[Brian Behlendorf]

I used to argue that the OSD should only certify licenses that talked
about redistribution, not use... but lost that argument, and there are
several licenses that limit use.  I can't find anything in the OSD that
would invalidate a term like you describe; I say that partly to dare other
folks on this list to take a look.  Note that it basically reduces your
software to shareware, relying on people to pay appropriately if they
violate that term.  That might not be such a bad thing though.

Brian


On Wed, 15 Oct 2003, Arnoud Engelfriet wrote:
 This may be a silly question as I'm probably overlooking something,
 but as far as I can tell the Open Source Definition does not
 forbid any general restrictions on usage of software. The closest
 thing is No Discrimination Against Fields of Endeavor, but
 that only forbids exclusion of _some types_ of usage, not exclusions
 on usage by everyone.

 Would something like You may only use this editor if you release
 all works you create with it as open source software fail under
 OSD #6, and if not, why would it fail the OSD?

 The FSF says quite clearly that you should have The freedom to
 run the program, for any purpose (freedom 0). Is this the
 same as OSD #6 or do they indeed require something broader here?

 Arnoud


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

RE: OSD#5 needs a patch?

[Brian Behlendorf]

On Wed, 8 Oct 2003, Lawrence E. Rosen wrote:
 6. Open source licenses may not discriminate against persons or groups,
 fields of endeavor or types and brands of technology.

 Proponents of open source software insist that software not be a
 battleground on which political or philosophical or business wars are waged.
 In many jurisdictions around the world, discrimination on the basis of race,
 age, religion, national origin, sex, sexual orientation, health status, and
 other personal characteristics is always illegal.  This open source
 principle is intended to extend that broad list, not to replace it.  To be
 consistent with this open source principle, all terms and conditions of the
 license must demonstrably encourage rather than discourage software freedom
 for all licensees.

My concern is that even with the explanation, simply stating that the
license must not discriminate against persons or groups, without
explaining the *basis* on which the license must not discriminate, is
still too vague, as nearly any criteria one could put in a license leads
to a discrimination between one party and another.

I think we need to be specific about what basis a license is not allowed
to discriminate against.  It's not hard.  Furthermore the rule should be
able to stand on its own when analyzing a license and not require the
explanation to get the complete picture.   A suggestion:

  Open source licenses must not deny any part of the license to any person
  group based on that person's or group's vocation, nationality, language,
  name, age or any other biological attribute.

I think this captures the intent behind the original example (This
software may not be used by the South African Police).  I think
vocation is a much better term for this purpose than fields of
endeavor, for I may endeavor to a business model that requires me to
combine GPL and proprietary code.

Your example also included types and brands of technology.  Is an
application that attempts to link to a GPL'd library a type of technology?
I think licenses that would seek to block specific companies, e.g. no
one from IBM may use this software would be prevented by the group's
name term.

I echo the other comments that state that existing OS license *have* been
used to promote specific political or economic philosophies, by favoring
specific definitions of software freedom.

Brian

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

RE: For Approval: Open Source Software Alliance License

[Brian Behlendorf]

On Sat, 27 Sep 2003, Lawrence E. Rosen wrote:
 I'm sorry that I'm coming in late to this conversation but I've been busy.

 I'm concerned about the following section of the proposed license:

 4. Redistributions of source code must not be used in conjunction
with any software license that requires disclosure of source
code (ex: the GNU Public License, hereafter known as the GPL).

 Licenses seem sometimes to be used as weapons rather than to foster freely
 reusable code.  In this case, the author has made clear, he wants to allow
 his software to be used with proprietary derivative works but not with the
 GPL.  It is, I guess, the anti-GPL license.

 In that sense, I think, it violates the OSD.

Which term?  The discrimination clauses, #4 and #5, talk about persons
or groups, and fields of endeavor.  Defining what either of those mean
has always been troublesome.  An easy test is nationality (can't deny
Polish citizens, for example) or career (can't deny the military).  It's a
big stretch to try and claim that people who use the GPL is a group or
field of endeavor - because if we did, every term of every license could
be challenged as OSI-incompatible.

I suppose we could point to #9, and claim that the word use in the above
section is too vague and could apply to mere aggregation on a single
distribution medium.  Or that use in the context of using OSSAL software
on a GNU-licensed operating system is also too vague.

But as far as I can tell, the proposed license is anti-GPL in the same
way that the GPL itself is anti-everything-that-isn't-a-subset-of-the-GPL.
We may not think it's a very good license, most of us would probably lobby
against its use, but I can't see a term of the OSD that it violates (at
least the section above, I've not read the full OSSAL license).

Whether Sean realizes it or not, I think Ernie Prabhakar captured Sean's
primary concern most closely: that a GPL-only fork would arise and capture
more development momentum than a BSD-licensed original.  I can't recall
that ever happening, but I do hear similar sentiments from Apache members
from time to time.  OpenOffice has had issues with developers fixing bugs
or adding new features but only offering those patches under the GPL,
rather than granting them to Sun to dual-license under GPL and SISSL.

 On 6/30/2003 Brian Behlendorf asked this list to consider a recent Microsoft
 license provision that read as follows:

   [You agree] [t]hat you are not allowed to combine or distribute the
   Software with other software that is licensed under terms that seek to
   require that the Software (or any intellectual property in it) be
   provided in source code form, licensed to others to allow the creation
   or distribution of derivative works, or distributed without charge.

 Once again, this is a license that says don't use that license rather than
 do use this license.  The former wording seems like discrimination to me
 and the latter like any reciprocal license we've approved since the
 beginning.

I don't recall a consensus being formed as to whether the above violated
any OSD term.  Of course I'm not pushing for that license to be certified,
neither do we see anyone from Microsoft here to push it, but it's still an
interesting test case IMHO.

 Is that a distinction without a difference?  Or should we assert that
 licenses of the form don't use that license are contrary to the OSD
 because they discriminate?

I would wonder whether you can reasonably define use above in a way
that doesn't de-qualify the GPL.

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

Re: For Approval: Open Source Software Alliance License

[Brian Behlendorf]

On Sun, 28 Sep 2003, Russell Nelson wrote:
 Brian Behlendorf writes:
   It's not flame bait.  Show me an open source license that specifies that
   each user pay the copyright holder for use.

 You could have a license which specifies that each user have to pay
 the copyright holder when they get the software from the copyright
 holder.  It would have to allow others to redistribute it without fee,
 but the license itself *could* require payment upon recipt from the
 copyright holder.  Some people would be perfectly willing to pay.

That doesn't meet the requirement above.  You're saying I could charge for
the act of allowing a download to someone.  Very different than what I
suggest above.

Note I'm not trying to argue that such a license (every user pays a fee)
is what OSI should be worried about accomodating or anything.  For good
reason any such license would fail the OSD.  I'm just saying that there
are people out there who passionately cling to the notion that if you get
value for using a piece of software, you should be paying the authors of
that software, and that charity as the motivation to pay isn't strong
enough.  Whether that notion, like the notion that a musician or filmmaker
should also be paid by everyone who enjoys their work (see: RIAA, etc),
will die a quick or a slow death, or even die at all, is an open question.

Brian

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

Re: For Approval: Open Source Software Alliance License

[Brian Behlendorf]

Pulling a Kibo:

On Thu, 25 Sep 2003, John Cowan wrote:
 Mike Wattier scripsit:

  yeah.. and IMHO this is the very reason that many who want to support the Open
  Source community, will not do so. It is slowly becoming a cheerleading
  section for the GPL.

 Nonsense.  Tell that to Mr. Behlendorf, open and notorious OSI supporter
 and promulgator of a certain almost-BSD-licensed web server.

Notorious!  I love it.

I don't agree with Mike's claim, but I understand completely where it's
coming from.  It's one thing to talk about a company's preferred licensing
model for software created largely outside that company.  It's quite
another to be a sole or primary author of a piece of software and try to
determine which licensing strategy is optimal, especially when you are
trying to make a living from it, and especially when you're a small
company and can't afford to build all the other associated services you
could actually make money from.

The essential device of an OSI license - the right to distribute modified
works without the copyright holders' consent - does mean there's a whole
host of business models the copyright holder simply can't make viable,
especially on a startup budget.  That's not a defect, or even necessarily
a shame - the balance of power in OSI-approved licenses is intentionally
weighted in favor of everyone but the authors.  This makes it hard to
reconcile, though, with the traditional model for small software
developers - that you get paid proportionate to the amount of value your
product is providing to people, roughly expressed as the number of people
using your product.  The fact that such a philosophy can't be supported
(at least not predictably and directly) by OSI licenses is what causes
people to see OSI licenses as cheerleading for the GPL.

Brian

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

Re: For Approval: Open Source Software Alliance License

[Brian Behlendorf]

On Thu, 25 Sep 2003, Rick Moen wrote:
 Quoting Brian Behlendorf ([EMAIL PROTECTED]):

  The essential device of an OSI license - the right to distribute modified
  works without the copyright holders' consent - does mean there's a whole
  host of business models the copyright holder simply can't make viable,
  especially on a startup budget.  That's not a defect, or even necessarily
  a shame - the balance of power in OSI-approved licenses is intentionally
  weighted in favor of everyone but the authors.  This makes it hard to
  reconcile, though, with the traditional model for small software
  developers - that you get paid proportionate to the amount of value your
  product is providing to people, roughly expressed as the number of people
  using your product.  The fact that such a philosophy can't be supported
  (at least not predictably and directly) by OSI licenses is what causes
  people to see OSI licenses as cheerleading for the GPL.

 I just want to perform a little semantic janitorial duty, here:

 Surely the allegation discussed at the end of your paragraph is
 objectively a factual error.  In anyone else's hands, I'd have suspected
 it was intended as flamebait.

It's not flame bait.  Show me an open source license that specifies that
each user pay the copyright holder for use.  That's the predictable and
direct method to compensate a copyright holder based on the number of
users of their software that just doesn't exist in open-source licensed
software.  I'm not saying it's a problem, I'm just saying it's
incompatible with the traditional way (and I'd suggest, still the
predominant way) software companies sell their goods.  Companies used to
the old model sometimes have trouble dealing with this, and think we're
all about some wacky anticapitalist ideal epitomized in their minds by the
GPL.  They don't see the shift the software economy is making from being a
packaged-goods-like industry to a services industry.

Semantically clean?

Brian

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

Re: Pack of 2 CDs [deleted]

[Brian Behlendorf]

This is so disgusting.  Can we configure the list to only accept messages
from subscribers, PLEASE?  I'd prefer messages were bounced to a moderator
for approval, I'm happy to volunteer.

Brian

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

Re: license idea (revised)

[Brian Behlendorf]

On Wed, 16 Jul 2003, Mark Rafn wrote:
 My strong recommendation:  Ignore antisocial users (whether they be
 individuals or corporations).  The community has it's own strengths, the
 vast majority of which come from freely-chosen cooperation.  Trying to
 make software less useful in order to protect your revenue or brand is
 misguided.

Here here!

Brian

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

Re: license idea (revised)

[Brian Behlendorf]

What, do our opinions need to be OSD-conformant now, too?

Besides, anyone who knows where I'm coming from knows I have no dislike
for revenue or branding.

/me re-lurks

Brian

On Wed, 16 Jul 2003, Mike Wattier wrote:
 Pardon me but, how does a statement like this

  Trying to make software less useful in order to protect your revenue or
  brand is misguided.

 Promote and encourage the diversity and co-operation encourgaged in

 5. No Discrimination Against Persons or Groups
 6. No Discrimination Against Fields of Endeavor

 thanks
 Mike


 On Wednesday 16 July 2003 2:18 pm, Brian Behlendorf wrote:
  On Wed, 16 Jul 2003, Mark Rafn wrote:
   My strong recommendation:  Ignore antisocial users (whether they be
   individuals or corporations).  The community has it's own strengths, the
   vast majority of which come from freely-chosen cooperation.  Trying to
   make software less useful in order to protect your revenue or brand is
   misguided.
 
  Here here!
 
  Brian

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

Microsoft's near-OSD-compliant shared source license

[Brian Behlendorf]

http://www.asp.net/samplessourcelicense/Default.aspx?tabindex=0tabid=1

Any thoughts?

This is perhaps the one segment that makes it not OSD-compliant,
violating OSD #9, but I'm not sure:

  [You agree] [t]hat you are not allowed to combine or distribute the
  Software with other software that is licensed under terms that seek to
  require that the Software (or any intellectual property in it) be
  provided in source code form, licensed to others to allow the creation
  or distribution of derivative works, or distributed without charge.

It even includes a patent poison pill!

Brian

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

Re: commercial application development

[Brian Behlendorf]

On Wed, 4 Jun 2003, John Cowan wrote:
 Sujita Purushothaman scripsit:

  If you use MySQL to develop a closed-source application you have to buy
  the commercial license. If you use the GPLed MySQL then you have to
  release your application under the GPL.

 Not quite, on either count.  If you use MySQL to develop a closed-source
 application *that you distribute to people in binary form*, then you
 have to buy the commercial licnese.  Similarly, if you use the GPLed
 version, and you *release your application in binary form*, then you
 have to provide source to the people who got the binary.

We should be specific here - this only applies, AFAIK, to applications
that statically link with MySQL code, creating a derivative work.  So if
you've got a C app that links to MySQL client libs, and you ship that,
then you are shipping a derivative work of the client libs.  The client
libs, though (at least the Java JDBC driver, AFAIK) are LGPL, meaning the
rules are slightly easier.

Also, if your application doesn't actually link to MySQL code, but instead
talks to MySQL via SQL over a socket, you're not a derivative work.  I
don't know if including MySQL on the same CD counts as mere aggregation
as the GPL uses the term, but in my (non-lawyer) opinion, you should be
able to require the user to independently obtain MySQL in order to run
your app.

Brian

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

Re: Open Source Business Found Parasitic, and the ADCL

[Brian Behlendorf]

  I don't know of one business that is making any money selling Open
  Source Software.

I don't know of a single IT vendor, save perhaps Microsoft (and even
that's in question) who isn't selling a hardware or software product that
at some point incorporates software licensed under an Open Source license.

Brian

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

Re: What about LGPL? Re: Compatibility of the AFL with the GPL

[Brian Behlendorf]

On Fri, 14 Mar 2003, Andrew C. Oliver wrote:
 Lawrence E. Rosen wrote:
  Richard,
 
  Today you finally gave public reasons for your assertion that the AFL is
  incompatible with the GPL.  Because you are simply wrong on the law and
  wrong-headed on a matter of principle, I must file this public response.

 So I think I understand the controvery regarding GPL and why GPL and ASL
 (aka AFL) don't work together.  What about LGPL and ASL in the situation
 of Java?  Apache has a long standing ban on LGPL being used in Java
 projects and I want to know if its justified.

Just to keep everyone clear, the AFL in this week's discussion is the
Academic Free License:

http://www.opensource.org/licenses/academic.php

it is NOT the Apache License.

The Apache license as it currently stands is not compatible with the GPL,
we recognize this; whether it's compatible with the LGPL depends on what
one's definition is of interfaces and derivative works.  We're looking at
a second rev of the Apache license that will be GPL compatible (and thus
also LGPL compatible).  No promises.

 On a personal note, clearing this up would help me greatly as I would
 like to use Trove4J (http://trove4j.sourceforge.net/) in the Apache
 project I founded (http://jakarta.apache.org/poi) instead of our own
 collection classes.

Since it's the Trove4J folks who would have standing in any case involving
LGPL-nonconformance, *not* the FSF, it really only matters how the Trove4J
folks intend the LGPL's language around derivative works and interfaces to
be interpreted.  If the Trove4J developers gave you a statement to the
effect that they do not intend for applications that use the Trove4J
interfaces to be considered derivative works, then your problem is solved,
and you don't need to wait for RMS or Eben.  If instead they want some
sort of canonical interpretation from the authors of the GPL, then all
of us have to wait, no matter what opinions are aired on license-discuss.

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

RE: Open Source Business Found Parasitic, and the ADCL

[Brian Behlendorf]

On Fri, 14 Mar 2003, James Harrell wrote:
 All I know is that the fangs come out whenever this type of
 discussion comes up. :)

Maybe it's because those of us who've figured out how to build businesses
in this space are annoyed by the thesis that it can't be done.

Brian

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

RE: Compatibility of the AFL with the GPL

[Brian Behlendorf]

On Wed, 12 Mar 2003, Mark Rafn wrote:
 On Wed, 12 Mar 2003, Lawrence E. Rosen wrote:

[...]
  Linus Torvalds learns about WhizBanger and he and his team decide to
  include WhizBanger in their new release of Linux.  As usual, they
  release their new Linux, with full source code, under the GPL.  The
  Debian project thinks the new release of Linux is wonderful.  They
  include the modified Linux in their new distribution, also under the
  GPL.

 By doing so, every distributor of Linux+WhizBanger violates the copyright
 of a whole lot of contributors to the Linux kernel.

Yeah, I couldn't get past this part either.  In this hypo, Linus has not
released it under the GPL.  It's under the GPL, and which requires the
recipient to accept the AFL from the WhizBanger developers.  The GPL
forbids this, so Linus can't include WhizBanger in his release.  He could
distribute it separately, of course, under the same (some claim
questionable) theory that allows proprietary kernel modules, etc.

  Brian Behlendorf learns about WhizBanger and he convinces the Apache
  team to include WhizBanger in their new release of Apache.  As usual,
  they release with full source code under the Apache license.

 I'm less familiar with exact requirements of the Apache license.  I don't
 know if it's compatible with the APL.

The Apache license, like most licenses other than the [L]GPL, doesn't
prevent people from adding restrictions to derived works.  So, someone
could combine Apache-licensed code and AFL-licensed code and legally
redistribute it.  Such redistribution would not solely be under the Apache
license, though, it would be via an Apache license from the author of the
derived work, and an AFL to the authors of WhizBanger.  So again, the
example doesn't hold water.

Brian

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

RE: Compatibility of the AFL with the GPL

[Brian Behlendorf]

On Tue, 11 Mar 2003, Lawrence E. Rosen wrote:
 Brian Behlendort wrote:
  All IMHO, and IANAL, coz I get burned every time I post here
  these days...

 Are you afraid I'll slap you 'aside the head?  Relax  :-)

Let's say I'm trying to be more cognizant of my own lack of formal legal
training, and have a strong desire to improve it based on real-world
examples.

  Despite these clauses being within the spirit of the GPL,
  they are still additional restrictions on redistribution.

 If the goal is just the GPL, only the GPL, nothing but the GPL, forever
 and ever, amen then I suppose anything that differs from it has a big
 hurdle to overcome.  But I thought the real goal was *free software*,
 not simply protecting a license.  So what if there are additional
 restrictions (although I quarrel with your use of the word
 restrictions)?  Why is that not within the spirit of the GPL?  RMS
 is challenging compatibility, not testing for equivalence.

I can't speak for RMS and would never want to.  My perception is that one
of the things that attracts people to the GPL is this sense of trust - if
a whole package claims to be GPL, you can combine it with other GPL or
LGPL code, the net result will be GPL, and you can rely on that fact.  I
think most people would prefer a world where there were as few different
licenses they had to read and understand and follow as possible, and the
GPL biases towards that end.  That's not necessarily a free software
goal, but a pretty saavy practical goal.

Section 2b is pretty clear:

  You must cause any work that you distribute or publish, that in whole or
  in part contains or is derived from the Program or any part thereof, to
  be licensed as a whole at no charge to all third parties under the
  terms of this License.

As is section 6:

 You may not impose any further restrictions on the recipients' exercise
 of the rights granted herein.

GPL + anything = GPL, or you can't redistribute.  The GPL *does* allow for
certain kinds of additional restrictions where there are laws one can't
work around - see section 8.  But they're extremely narrow in scope.

  In the case of the trademark/names, one who creates a
  derivative work will always have to worry that your
  interpretation of endorse or promote is broader than
  anticipated.  For example, if a derivative work proudly and
  loudly claimed its heritage, perhaps even named itself
  something similar, there would always be the possibility that
  you would disagree, and the right to redistribute would be
  revoked.  Sure, the GPL has other vague clauses, but I just
  want to point out this is a clause that essentially forms an
  additional restriction.

 Are you suggesting different words besides endorse or promote?  Under
 U.S. trademark law, anyone can say I've built a derivative work of
 Apache without using Apache's good name, or yours, to endorse or
 promote their software.  I think the words endorse and promote are
 clear enough.

By redistributing your work I run the risk that our two interpretations of
endorse and promote may differ, and to wake up one morning to find a
breach of contract claim against me.  That's my worry.  Now, Apache has
used that to *positive* advantage, as it's much easier to go to a party
and tell them they're violating the Apache license by using our name, than
pursuing a claim under trademark law.  But, that's not something the GPL
allows today.  So as I've seen this, being GPL-compatible means giving up
a rather useful device to protect one's name.  It's a tradeoff.

  If instead the license simply *reminded* people that nothing
  gives them the right to use the trademarks or good name of
  the original author, then that wouldn't be an additional restriction.

 That is precisely what it does.  Note that the provision is entitled
 Exclusions from License Grant, and it says, in essence, here's what
 you don't get with this license.  It doesn't say, here's the penalty
 for doing these things without permission.  Do you want me to add the
 phrase pretty please to the end of the provision so that people will
 recognize it is a reminder rather than an order to do or not to do
 something?

 Simply put, if an AFL-licensee infringes an AFL-licensor's trademark, he
 will get sued for trademark infringement rather than breach of contract.
 The infringer won't be able to defend himself by arguing he has an
 implied license, because the AFL contains an express exclusion of
 trademarks from the license grant.  All the provision does is promote
 clarity of the scope of license.  (That's a deficiency of the GPL, by
 the way!)

From the way I read that section, it sounded like the clause was a
condition I had to follow in order to redistribute.  That is, if I publish
a derived work and use language that you find objectionable on those
terms, then I will have broken the contract.  You may not use is, to me,
much different than nothing gives you the right.  Reaching here, I'm
thinking that if I break the 

Re: Compatibility of the AFL with the GPL

[Brian Behlendorf]

Lawrence E. Rosen wrote:
 And anyone who has a copy of W+X or W' has two licenses, one from Person
 A (for that part that was W) and one from Person B (for W+X or W').
 Person A is not responsible in any respect for W+X or W'.

*Sigh*.  OK, now I get it.  W+X and W' has *two* licenses, one each to two
different parties.  The terms of *both* must be followed by Person C.

My common-sense, non-lawyer brain says that if person B says W+X or W' are
under the GPL, it's really GPL to Person B plus AFL to Person A. It
appears to be Stallman's opinion, and it would be mine as well, that this
cannot be the case, as the GPL prevents additional restrictions, without
a qualifier as to which party those restrictions are enforced by.

Brian

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

RE: Compatibility of the AFL with the GPL

[Brian Behlendorf]

Sorry for copying large segments; I have a feeling we're talking past each
other, and I want to try to avoid that.

On Wed, 12 Mar 2003, Lawrence E. Rosen wrote:
 First, as to the Mutual Defense provision and its compatibility with
 the GPL:

 Person A writes W and licenses it to everyone under the AFL.  Person B
 comes along and, in the true spirit of free software, creates and
 distributes collective work W+X and derivative work W' under the GPL.
 No surprises for B.  He's read the AFL and the GPL and he understands
 that he's doing what's allowed.

 Person C gets a copy of W+X or W'.  He knows it is GPL software.  Person
 C now wants to sue Person A for patent infringement by W.  He reads W's
 license and discovers the Mutual Defense provision.  He must evaluate
 his risk of losing rights to copy, modify or distribute W, W+X and W',
 and any other W-based software, if he sues A.  What's wrong with making
 him evaluate that risk before suing for patent infringement?  It's his
 patent, and he's (perhaps) within his rights to sue Person A for
 infringement.  But as the author of an open source license, I don't have
 to make that easy or cheap for him to do.

Nothing is wrong in spirit with the Mutual Defense provision.  That's not
the question here.

When person C gets that copy of W+X or W' from B, they were told that it
is covered by the GPL.  C reads the GPL, understands it, and is led to
believe (barring any situation that B couldn't have prevented, such as a
third-party patent claim on code that W+X or W' implements) that the GPL
completely describes the terms and conditions that C must follow.

When someone downloads Apache software, they read the Apache license, and
are led to believe that's the only license they need to be observant of in
order to exercise the rights the license grants them.  Apache developers
can't guarantee there'll never be patent claims made by third parties of
course, and we indemnify our liability in that event.  But the Apache
developers are very careful to make sure there's no additional clauses in
third-party packages we bundle into tarballs people pull from apache.org.
No one likes surprises.

I think this describes the common interpretation of what it means to say a
particular piece of software has a particular license.  That license
should include all clauses relevant to the exercise of the rights it
claims to give.  If there are additional licenses one must also follow, it
should be included by reference.

John used the example of the Apache license.  What allows a vendor to pick
Apache up and incorporate it into a proprietary work is that we do not
require derived works to also be licensed under the Apache license.  The
GPL, though, *does* require derived works to be licensed under the GPL.

 Perhaps the LICENSE file of any GPL-licensed work that contains an
 AFL-licensed component should contain a warning notice:

WARNING: Your license to this work may automatically terminate
if you sue Person A for patent infringement.  That is because
this work contains a component that is licensed to you by Person A
under the AFL.  You get to decide whether a patent infringement
lawsuit against Person A is worth the loss of your rights to
copy, modify or distribute Person A's contribution to this software.

So in what way does this language not constitute an additional
restriction as defined by section 6 of the GPL?

Every time someone pops up on license-discuss and says I have a new
license, it's just like the GPL but it adds a clause that says you can't
stand on your head and count to ten.  Is it OSI-conformant?
GPL-compatible?  We may hem and haw over whether being able to stand on
your head and count to ten constitutes a discrimination based on field of
endeavor, but it seems that people always say, adding clauses, anything,
makes it not GPL compatible.

 You're right in suggesting that the GPL has fostered a spirit of license
 trust, and that is wonderful.  I'm seeking compatibility between the AFL
 and the GPL because I want to share in that good will and to encourage
 people to release source code that can be incorporated into GPL-licensed
 programs -- as well as into proprietary and other open source programs.

We share the same objective - I'd love to see the Apache license get there
too.  But we hit the same brick wall, and we can't just pretend it doesn't
exist.

 The mutual defense provision of the AFL doesn't detract from that goal.
 It just causes those who would sue free and open source software for
 patent infringment to do their homework first and to recognize that it
 is no longer cheap and risk-free to do so.

Again, no one is criticizing the intent, though I've brought up before
that I'm not sure patent lawsuits are always about evil patent holders
vs. the small guy hero.  That's besides the point.

 They only have to crawl through the source code if they elect to sue
 OSI Certified open source software for patent infringement.  What's

RE: Compatibility of the AFL with the GPL

[Brian Behlendorf]

On Wed, 12 Mar 2003, Lawrence E. Rosen wrote:
 Brian Behlendorf wrote:
  *Sigh*.  OK, now I get it.  W+X and W' has *two* licenses,
  one each to two different parties.  The terms of *both* must
  be followed by Person C.
 
  My common-sense, non-lawyer brain says that if person B says
  W+X or W' are under the GPL, it's really GPL to Person B
  plus AFL to Person A. It appears to be Stallman's opinion,
  and it would be mine as well, that this cannot be the case,
  as the GPL prevents additional restrictions, without a
  qualifier as to which party those restrictions are enforced by.

 I'm sorry, Brian, I just don't view these things as additional
 restrictions -- yet another example of vagueness in the GPL.

They are clauses I need to be aware of because they affect my ability to
use the code.  I guess we'll just have to agree to disagree, because I'm
not sure what else to say that would convince you.

 Regardless, the explicit exclusion of a trademark license and the mutual
 defense provision are not going to disappear from the AFL.

And I wouldn't want them to.  I think they're fine, and I think if
anything the GPLv3 should be amended to allow these kinds of things, if
not pick them up itself.

 You keep worrying about the downstream licensee, but let's think about
 his concerns more carefully.  Why should he care, for the most part,
 about the AFL-licensed component?  By law he cannot use the
 AFL-licensor's trademarks anyway, so as a practical matter who cares
 whether he's actually read the AFL license.  As for the mutual defense
 provision, if he's planning to sue for patent infringement he would be
 well-advised to write a cease-and-desist letter first and understand the
 risks of suing against open source software that very well might have
 been incorporated into his own company's infrastructure by now.  I
 simply don't care about him and our community owes him no consideration
 whatsoever.

Regardless of someone's intent, Larry, they are owed the honesty of being
told when a license applies to them.  The AFL applies to this downstream
licensee.  To say it's not important, because it only matters when they
try and do this evil thing rally makes me queasy.  Of course it's
important, especially if they were led to believe that the GPL described
all the conditions under which they were allowed to use and redistribute
the code.

If a client came to you, Larry, and told you they wanted to sue a
particular company for patent infringement, would you typically recommend
to them that they audit the source code of all the software they used in
their organization, to make sure this company didn't plant any Mutual
Defense clauses in components of that software?  Imagine yourself as
someone unaware of the existance of the AFL.

If your answer is well of course, any entity should already be completely
aware of the licenses on the software they use, you've made my point.

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

Re: Compatibility of the AFL with the GPL

[Brian Behlendorf]

All IMHO, and IANAL, coz I get burned every time I post here these days...

Despite these clauses being within the spirit of the GPL, they are
still additional restrictions on redistribution.

In the case of the trademark/names, one who creates a derivative work will
always have to worry that your interpretation of endorse or promote is
broader than anticipated.  For example, if a derivative work proudly and
loudly claimed its heritage, perhaps even named itself something similar,
there would always be the possibility that you would disagree, and the
right to redistribute would be revoked.  Sure, the GPL has other vague
clauses, but I just want to point out this is a clause that essentially
forms an additional restriction.

If instead the license simply *reminded* people that nothing gives them
the right to use the trademarks or good name of the original author, then
that wouldn't be an additional restriction.

As for the mutual patent termination clause:

 I'll leave for another thread any discussion about whether this is a
 good idea or a bad idea.  But how is it incompatible with the GPL?  The
 provision only applies to software licensed under the AFL and similar
 licenses, and it doesn't affect in any way software that is not licensed
 with this provision.

The whole point of compatibility between licenses is this: if you can
combine (not mere aggregation, but linking, etc) software with license A
with software license B and legally redistribute it with license C, then
licenses A and B are compatible for some values of C.  If either A or B is
the GPL, then C *must* also be the GPL, and nothing more.  But, C must be
comprehensive and cover the license of the whole codebase; which means
your termination clause must be represented in license C, and that
prevents it from being the GPL.

Amateur set theorists will quickly see that the only licenses that are
compatible with the GPL are those whose terms and requirements are a
subset of those of the GPL.  That's always been my understanding.  The
MIT/X licenses are GPL-compatible because there is nothing they demand
from the end-user or redistributor that the GPL doesn't demand.

 ***Anyone*** is free to take software licensed under the AFL and
 re-license it under any license, including licenses not containing the
 Mutual Defense provision [to use, copy, modify, merge, publish,
 perform, distribute and/or sell copies of the Original Work and
 derivative works thereof,...].  In fact, the AFL permits anyone to
 freely relicense their derivative work software under the GPL.

But the license on the parts copied from the original work are still under
the AFL, right?  Which means any new license I put on it has to carry
forward the same terms, at least on that original code, unless I indemnify
those I give software to by meeting the terms on their behalf?

When we use third-party code in Apache, we're careful that the
requirements that code places are *not* more onerous than those of the
Apache license as well.

Surely you're not saying I can add some whitespace to the end of a .c
file, and put the entire codebase under the Apache license, for example.

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

RE: Derivative Work for Software Defined

[Brian Behlendorf]

(Scott, quote the GPL:)
Thus, it is not the intent of this section to claim rights or contest
 your rights to work written entirely by you; rather, the intent is to
 exercise the right to control the distribution of derivative or collective
 works based on the Program.

Can someone clear up the difference between mere aggregation and a
collective work?  Is Red Hat Linux a collective work or a mere
aggregation of many different software packages, some of them GPL,
some under other open source licenses, some of them not?

Brian

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

RE: Derivative Work for Software Defined

[Brian Behlendorf]

On Thu, 16 Jan 2003, Lawrence E. Rosen wrote:
  Can someone clear up the difference between mere
  aggregation and a collective work?

 As far as I can tell, a mere aggregation IS a collective work.  The
 former term has no meaning in the copyright law.

OK, so I thought the GPL distinguished between the two - that having a GPL
program (I'm not thinking of the kernel here or other things reasonably
determined to be part of an operating system, an allowance the GPL
makes) on the same CD as non-GPL bits, in a situation such as a Red Hat
Linux CD, was OK because it was mere aggregation, which the GPL
explicitly allows, and not a collective work, which the GPL states
*would* be under the GPL.  Maybe mere aggregation has no meaning w/r/t
copyright law, but am I mistaken in thinking the GPL makes the
distinction?

Brian

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

Re: MPL section 2.2, and patent grants on derivative works

[Brian Behlendorf]

Keeping the patent discussion on low-boil:

On Fri, 22 Nov 2002, Mitchell Baker wrote:
 The scope of the patent grant is not enlarged by subsequent derivative
 works of the Contributor Version.  If the scope was so enlarged, the
 Contributor would have  no idea how broad a set of patent grants it
 would ultimately end up making.

not enlarged by I totally understand.  I'm asking whether a patent
grant, applying to the specific contributions (and previous contributions)
in that version, survive to a derivative work too.  I'm not asking about a
derivative work with *new* code that would violate another one of
Contributor's patents; assume the change between the Contributor Version
and the derivative work is completely neutral on patent terms.

If not, then the patent grants by contributors ends up being pretty
useless (since they last only one Version), so I've got to believe this is
handled, I'm puzzled as to how though, since the language does not appear
to allow it.

Thanks for the other clarifications.

Brian

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

MPL section 2.2, and patent grants on derivative works

[Brian Behlendorf]

Apologies if this is retreading old ground, and off-topic since it's not
about approval of a license, but we're working on the next version of the
Apache license and are looking at the patent language in various licenses.

I'm trying to tell if the patent grants by Contributors described in
section 2.2 apply to derivative works, either published by the same entity
as the Original Code, or a third party).  My read of 2.2 (IANAL, etc)
suggest that the patent grant *only* applies to the specific Contributor
Version, e.g. the Original Code plus the Contribution to which the patent
applies.  E.g.:

  Each Contributor hereby grants You a world-wide, royalty-free,
  non-exclusive license [...] under Patent Claims infringed by the making,
  using, or selling of Modifications made by that Contributor either alone
  and/or in combination with its Contributor Version (or portions of such
  combination), to make, use, sell, offer for sale, have made, and/or
  otherwise dispose of: 1) Modifications made by that Contributor (or
  portions thereof); and 2) the combination of  Modifications made by that
  Contributor with its Contributor Version (or portions of such
  combination).

What happens to a derivative work of the Contributor Version?  E.g., the
developers at Mozilla.org merrily commit the patch corresponding to that
Modification from said Contributor, and then make another commit, and
another, then make a release.  Given the language in the license, how does
that patent grant apply to this new work?  This new work is not the
Modification alone, nor is it the Contributor version, nor really a
portion of such combination - it contains the Modification, but even that
Modification may end up modified at some point.

2.2(d)(3)(i) appears to suggest that third-party [who's a third party?]
modifications of Contributor Version don't get that patent grant; neither
do those who combine with other software.  Yikes!  That only further
confuses the situation.  Does putting Mozilla on a CD with some other
software and calling that a product constitute combination, and thus
lose the patent grants?

The root question for us (Apache) is, does a contributor grant need to
explicitly state that a grant of a patent license on a contribution
applies to derivative works of the resulting contributor version.  If
that's the case, some say we need to limit the types of derivative works
it can apply to, since allowing any derivative work to carry the patent
grant would mean that anyone with a commercial product who wanted to use
that patent without paying could do so by pulling the right Apache code
into their own.  Limiting it to derivative works published by the ASF is
one option, published under any open source license is another.  But we'd
really prefer not to invent new language here, so I'm trying to understand
language like this in existing licenses.

Brian

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

RE: Legal soundness comes to open source distribution

[Brian Behlendorf]

On Wed, 14 Aug 2002, Russell Nelson wrote:
 I like mine (well duh!) because it explicitly says that all is fair in
 love, war, and software use and modification except for a few things.
 That's also its weakness because the list needs to be right; no more
 and no less.

Actually, it's alright if initially it's too restrictive - you can always
add to your list of exceptions over time, but removing exceptions would be
politically tough (while doable) since it would invalidate previously
valid licenses.

Brian




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

Re: Legal soundness comes to open source distribution

[Brian Behlendorf]

On Fri, 2 Aug 2002, Russell Nelson wrote:
 From what various legal scholars
 tell me, a non-contractual license (such as the GPL) cannot cause you
 to give up your warranty rights.

Is there a reference of some sort for this?  It's about the only solid
reason I see to need to go beyond copyright law.  Is there any court
precedent that suggests this?  A case where someone was given something
for free, with warranty disclaimed in a copyright license, and the court
decided that warranty disclaimer was invalid?  This is a pretty big delta
to current understanding, so if a change as large as expanding the OSD to
cover contracts is based upon this, we need more than hearsay.

Are there any other reasons to consider allowing the OSD to cover
contracts?  My sense is that keeping it limited to copyright licenses has
been key to its success to this point.

 Agreed.  That's why I think we need to amend the OSD so that it
 clearly states that a license must not restrict use, modification, or
 redistribution of the software.

The OSD, by applying to copyright licenses, already allows restrictions on
redistribution.  It'd be kinda toothless if it didn't...

Brian


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

Re: Legal soundness comes to open source distribution

[Brian Behlendorf]

On 2 Aug 2002, Russell Nelson wrote:
 The question here is whether we should amend the Open Source
 Definition so that it is clear whether click-wrap licenses are
 allowable or not.  We could go either way, but we want to hear from
 you first.  Your opinions solicited, and engaged!

I see a practical issue - if I install Debian from CD and fire up Mozilla,
I don't want to have to go through ten dozen different dialog boxes with
nearly inscrutable license terms listed in a small scrolling textbox I
then am asked whether I accept or not before I can continue.  Why so many?
In going from bare hardware to loading the OS to browsing a web site, I'm
likely to need to run applications and libraries written by many different
groups of developers, each potentially with their own agreement, and each
agreement potentially having some OSI-conformant-but-really-silly clauses,
like you may not utter the word 'pancreas' while using our software.
Even the BSD advertising clause is less of a potential annoyance than this
could be.

Maybe I'm taking this into reductio ad absurdum, but it's awful nice to
know right now that there are no conditions on use with open source
software, only conditions upon redistribution.  Philosophically, I don't
like the idea of someone being restricted in what they can do once they
have the software in their hands.  But then again, I have a bias towards
minimalism anyways.

Brian



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

Re: discuss: Bento Poetic License (resubmission)

[Brian Behlendorf]

On Fri, 19 Jul 2002, Michael St . Hippolyte wrote:
 On 2002.07.19 19:11 Brian Behlendorf wrote:
  Sun wanted the same thing with Java, to make adherence to a published
  standard part of the copyright license.  Unfortunately for you, it's
  been well established that such a desire is not compatible with the
  Open
  Source definition.

 I'm not sure the situations are comparable.  Our license does not
 require adherence to a standard, it just forbids false claims of
 adherence.

I think in Sun's opinion it ends up being a distinction without a useful
difference.  If someone forked their code and called the result Javuh or
OpenJava, or if someone duplicated yours and called it Bentoh or
OpenBento, then it might be hard to effectively fight.  It becomes a
battle of who's brand is stronger, and I think they assumed that a certain
company in Redmond could always out-spend and thus out-brand them.

Brian


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

Re: UnitedLinux and open source

[Brian Behlendorf]

On Fri, 14 Jun 2002, Rod Dixon wrote:
 Begun, this free software war has!;-)

Wars not make one great.

Brian

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

Re: OSD modification regarding what license can require of user

[Brian Behlendorf]

On Wed, 13 Mar 2002, John Cowan wrote:
 To be concrete, suppose I provide a fast grepping service.  You send me
 a regex and some URLs, and I use GNU grep to to send you specific parts
 of the documents specified by the URLs.  We will neglect whether the
 copyright of the document's author is breached by this.

 If I make private modifications to GNU grep to improve it, I don't see
 that the GPL (in letter or spirit) requires me to redistribute those
 modifications.  I am *using* grep to provide a service.

Or take it even further, and consider the case where people use privately
modified software to provide some other service.  For example, people send
me images via email or Zip disk, and I use a modified Gump to create some
really nice effects and email/Zip disk the modified images back.  Now it's
not even a web service, in that it's not automatically called, but it's
still used as a crucial step in the delivery of a service.  Would I be
(legally, morally, ethically) required to share the code to my
modifications to Gump?  Is the fact that it's automated in John's example
and not automated in mine relevant?

(For the purposes of this example I'm assuming Gump has a GPL license and
doesn't make exceptions for plug-ins)

Brian

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

Re: OSD modification regarding what license can require of user

[Brian Behlendorf]

On Wed, 13 Mar 2002, Bruce Perens wrote:
 Consider Evolution, OpenOffice, or GNU Emacs. Postulate that someone makes
 a way for somebody to use one of those programs as if it were running
 natively on their computer, without ever activating the distribution
 terms of the GPL. And that same someone makes significant enhancements
 which he does not disclose in either source or binary form.

Yep, like making it available through VNC, for example.  A very clear
violation of the spirit of the GPL; but the grey area between this and the
examples in the earlier messages seems very hard to divide between clear
and non.

Brian



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

Re: Copyright in contracts/licenses (was: Re: [Approval request]CMGPL licence)

[Brian Behlendorf]

On Wed, 7 Nov 2001, Karsten M. Self wrote:
 on Wed, Nov 07, 2001 at 03:08:08PM -0500, Russell Nelson ([EMAIL PROTECTED]) wrote:
 
  For better or worse, the GPL is a document copyrighted by the Free
  Software Foundation and they have not granted permission to make
  derivative works.

 I have my own doubts regarding this statment.

 Legal contracts are, in one analysis, functional documents, and as such,
 the language that exists, if it's functional, or if the functional
 characteristics cannot be divorced from the expressive mode, would
 likely not be covered by copyright.

Then why is source code covered by copyright?  Is source code not
functional in the same way legal contracts are?  Aren't legal contracts
just source code for the machine we call society?

Brian


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

Re: VENTURE CAPITAL

[Brian Behlendorf]

On Thu, 9 Aug 2001, Russell Nelson wrote:
 Any objection to my turning on this feature for license-discuss?

No, though I'm a bigger fan of the -mu options to ezmlm, i.e. you must be
a subscriber to post, otherwise the post it bounced for moderation.  It's
100% effective at keeping spam off the list, though it can't stop stuff
like sircam (nothing does except 100% moderation).

Brian

Re: X.Net, Inc. License

[Brian Behlendorf]

On Thu, 9 Aug 2001, Russell Nelson wrote:
 Karsten M. Self writes:
   on Mon, Aug 06, 2001 at 01:19:20PM -0400, John Cowan ([EMAIL PROTECTED]) 
wrote:
Matthew C. Weigel scripsit:
   
 My opinion is that MIT License with specified jurisdiction should be
 approved, as this seems like a valid concern.
   
It should be noted for the record that such licenses are not GPL-compatible.
  
   Why?  Because of the no additional conditions requirement?

 That's the theory.  Given that there's always going to *be* a venue,
 it doesn't seem like a problem to specify which one it is.  However
 RMS says it's a problem, so obviously it's a problem.

IIRC, his issue is that someone may decide to declare the venue in a
country where copyright laws don't allow the GPL to be effectively
enforced.  I don't know of any such country off the top of my head.

Brian

Re: GPLv2 'web-app loophole'

[Brian Behlendorf]

On Wed, 8 Aug 2001, phil hunt wrote:
 On Wednesday 08 August 2001  2:15 am, David Johnson wrote:
 
  My point is not whether a thing can be done, but whether it should
  be done at all. I don't believe that Open Source licenses should
  regulate in any way the actual execution of the software.

 Are you saying that the Open Source Definition should include a
 clause forbidding restrictions on the execution of the software?

It doesn't have to.  Such clauses are only enforceable (IIRC, IANAL, etc)
as a click-through contract, not a copyright.  The OSD only applies to
copyright licenses.

Brian

Re: license submission: qmail

[Brian Behlendorf]

On Thu, 7 Jun 2001, John Cowan wrote:
 I am not an RCS/CVS expert, but it seems to me that it wouldn't be too
 hard to add a mode to download the original source plus forward deltas,
 SCCS-style.  This mode would meet the restrictions of the license:
 the original source is present, and the patches are merely aggregated
 with it, not incorporated into it.  At the receiving end, of course,
 they can be integrated.

If there's a way to manage the toolset to work around this, fine; but it
seems like there are lots of edge cases that become awkward.

 How is this so different from the NPL's treatment of Netscape as a
 privileged participant?  We didn't say that wasn't Open Source.

Privileged participation is fine.  I can fork Mozilla's code and start a
new development project around it if I want to, regardless of Netscape.

Brian

Re: license submission: qmail

[Brian Behlendorf]

On Thu, 7 Jun 2001, Matthew C. Weigel wrote:
 On Thu, 7 Jun 2001, Brian Behlendorf wrote:

  Nope, read more closely at http://cr.yp.to/qmail/dist.html:
 
Exception: You are permitted to distribute a precompiled var-qmail
package if [...list of conditions...]
 
  The OSD doesn't state that there could be no conditions.

 That's semantic pussy-footing.  The license must explicitly allow
 distribution, not explicitly disallow distribution except when certain
 conditions are met.  There is no room in 'grant permission to
 distribute' for 'do not grant permission to distribute.'

This is not pussy-footing.  May I quote from the GPL?

5. You are not required to accept this License, since you have not
   signed it. However, nothing else grants you permission to modify or
   distribute the Program or its derivative works. These actions are
   prohibited by law if you do not accept this License. Therefore, by
   modifying or distributing the Program (or any work based on the
   Program), you indicate your acceptance of this License to do so, and
   all its terms and conditions for copying, distributing or modifying the
   Program or works based on it.

You have to follow the conditions the GPL sets out in order to
redistribute modified source or binaries.  Neither the GPL nor DJB's
conditions listed in his exceptions violate the letter of the OSD.
DJB's might violate the spirit of the OSD, but again, that's my point -
OSD spirit != OSD letter.

  I think that page describes sufficiently how to create binaries of
  derivative works; it just doesn't allow source code releases of those
  derivative works, except as pristine source + patches.  Kinda perverse
  that the OSD has this preferential treatment for binaries over source
  releases, IMHO...

 Kinda perverse that you so strongly insist on misreading the OSD.  It's
 simple; allow distribution of binaries for people who don't want to
 hack, and provide something that those who want to hack, can hack.
 While people on Unix systems tend to take compilers for granted, they
 are not automatically on every platform.  What would you do if every
 open source project that runs on Windows (including gcc) were only
 available in source form?

Let's be clear what I am arguing for: that allowing licenses that only
allow redistribution of modifications as pristine source, plus patches
is not copacetic to what I understand and believe in as the goals of and
positive qualities of Open Source.  I don't see the above situation w/r/t
binaries and source as copacetic to that; it allows for some pragmatic
modifications by distributors, but doesn't really allow the right to fork.

The sensitivity I come to with this is the fact that when I presented a
proposal here a few weeks ago regarding whether a copyright on a codebase
could be used to help enforce standards-compliance, even though no one
could cite a specific clause in the OSD that prevented it, people
despaired over what they felt was a violation of the spirit of the OSD -
that it would give the original copyright holder too much arbitrary power
over deciding whether a derivative work was conformant with a
specification.

I agreed with that sentiment, and let the company who I was asking on
behalf of it just wasn't possible; now most likely something which might
have been open sourced, won't be.  Unfortunately, that event didn't result
in a call for a clarification of the OSD to better map to that spirit
everyone was so passionate about.  Here is a similar situation, and I'm
surprised that people are now arguing the opposite case, that we should
accept vague language in the OSD that creates a poor situation in favor of
a copyright holder, and puts anyone who wants to fork at a significant
operational disadvantage.

Brian

Re: license submission: qmail

[Brian Behlendorf]

On 7 Jun 2001, Ian Lance Taylor wrote:
  Thus, I submit that either qmail's license be approved as an
  OSD-conformant license, or OSI consider whether clause #4 needs, er,
  clarification.  It's hard to argue that neither is the case.

 So you are saying that the question here is what limitations clause #4
 permits on this sentence: ``The license must explicitly permit
 distribution of software built from modified source code.''  After
 all, DJB requires his approval for any such distribution.

Nope, read more closely at http://cr.yp.to/qmail/dist.html:

  Exception: You are permitted to distribute a precompiled var-qmail
  package if [...list of conditions...]

The OSD doesn't state that there could be no conditions.

 The intent
 of clause #4 is presumably that permission beyond adherence to the
 license itself is not required, and so DJB's license would not adhere.

I think that page describes sufficiently how to create binaries of
derivative works; it just doesn't allow source code releases of those
derivative works, except as pristine source + patches.  Kinda perverse
that the OSD has this preferential treatment for binaries over source
releases, IMHO...

Like I did a few months ago with the can-copyrights-enforce-standards
question, I'm exploring the edge cases of the OSD with the intent of
either finding models that accomplish goals that others not currently in
the open source community have (to bring them in) or to force us to ask
ourselves what Open Source really means, and whether the OSD matches
that concept.  I'm not trying to be an ass about this, seriously.  I just
see licenses like Darren Reed's and DJB's, and see some healthy debate
outside of this list and OSI as to whether such terms are Open Source or
not, and see the opportunity for clarification.

Brian

Re: Test

[Brian Behlendorf]

On Tue, 1 May 2001, Randy Kramer wrote:
 (What's the FSB?)  These few bad eggs -- can we do anything about them?
 On another list I subscribe to something similar happens occasionally.
 The list administrator tries to contact the bad eggs and if he gets no
 response he unsubscribes them.

The mailing list management package used by this list, Dan Bernstein's
ezmlm (non-open-source, it's worth noting!) automates this process - it
records bounce messages in a reliable way, noting which addresses bounce
and who they bounce for, and then some set amount of time after the first
bounce (usually 10 days), it sends a probe email to the bouncing
address, the body of which is what you (and I, and others) got, telling us
some messages bounced, what the error was on our side that caused that
bounce, and information on how to get those messages we missed.  Pretty
slick, especially for list admins who now never have to do anything to
remove bouncing addresses.

So, given that two messages bounced for a large number of people, I would
wager that the problem was actually on the mail server side - a
temporarily down DNS server perhaps, or resource problems, or what have
you - and since they only affected two messages, not worth worrying about.
I appreciate the fact, though, that should my own mail systems
accidentally bounce mail for me for a short period of time, I don't have
to worry about missing messages from the list or being unsubscribed.

These aren't the bounce messages you're looking for... move along.

Brian

RE: copyrightable APIs? (was RE: namespace protection compatiblewit

[Brian Behlendorf]

On Fri, 20 Apr 2001, Lawrence E. Rosen wrote:
 Even if a company were to argue successfully that its API is *both*
 expressive and substantive, and thus protectible as copyrightable subject
 matter, I would argue that access to the API for the purpose of preparing
 independent (compatible or incompatible) software, even including making
 copies, is still allowed under the fair use provisions of the copyright act.
 As the court held in Sega v. Accolade, 977 F.2d 1510, 1521-1524 (9th Cir.
 1992), in analyzing the four factors justifying a fair use defense:

Compelling.  If not "ironclad", this does appear to be the decision I was
looking to be able to cite regarding the enforceability of copyright of an
API over implementations.  Thanks Larry; I'm now done with this topic.  =)

Brian

Re: namespace protection compatible with the OSD?

[Brian Behlendorf]

On Thu, 19 Apr 2001, Rod Dixon, J.D., LL.M. wrote:
 I am sorry about joining the discussion late. This sounds interesting.
 Brian, do you mind clarifying your question without rehashing what has been
 discussed? I do not want to bore those who have followed the thread, but
 what do you mean by "implement" and what is the concern you are raising?

I was wondering if there was a way, compatible with the Open
Source Definition as well as acceptable to others in the community, to
create a copyright license for an API specification that helps ensure
compatibility of derivative works.  If the GPL's ethos is "access to
source code is paramount", this one's would be "compatibility between
implementations is paramount".  To try and recap the main argument
against, it was suggested trademarks could be used to enforce that API,
but I still suspect it is too blunt an instrument, since its
enforceability relies upon unwavering strictness on the part of the
trademark holder, and is on less tested ground legally.

Brian

Re: namespace protection compatible with the OSD?

[Brian Behlendorf]

On Thu, 19 Apr 2001, Eric Jacobs wrote:
 Brian Behlendorf [EMAIL PROTECTED]

  I'm saying two things: if you create a derivative work
  from my code, then the license says if you change the behavior of the
  functions or macros, etc., defined in my .h, that you must call it
  something else. However, if you keep the same interface (keep the .h
  consistant, but change the .c, though it's more accurate to say "API"
  and "implementation") then you may continue to call it "mylibrary.h".

 I'm having trouble with the interface/implementation distinction here.
 Is "behavior" the same thing as "interface"?

"API"/"interface" is the set of commands/procedures/methods/macros/
whatever that I expose to people using my software, either at a user level
or a programmatic level.  The intended effect is that someone else who
writes code that exposes the same API can be a drop-in replacement for my
code.  "Implementation" is the code I wrote behind that API which actually
does the work, and can vary even if the API stays the same.

  Secondarily, I'm saying even if you didn't implement my code, but
  followed the published document that describes the spec (which I also
  put under this license), you'd have to follow the same rules.

 This cannot be accomplished with an open source copyright license. This
 sounds like a job for trademarks.

On what basis do you claim I can't do this with an open source copyright
license?  What OSD section does it violate?  That's what I want to
determine.  Think of me as playing devil's advocate on this, because one
side (perhaps the stronger side) of me does want to see this to *not* be
possible, and it might be yet another hole in the OSD - best to patch it
up now than wait for someone to abuse it.  However I want to find an
ironclad argument against it, and I haven't, other than "that would be a
bad thing - e.g., Win32 and Wine".

 All changes potentially introduce incompatibility, even bug-fixes, because
 old code can rely on the buggy behavior.

I would define in/compatibility as that defined by the spec, not the code.
If I expose through the API a routine that (the spec says) returns a float
that's the square root of a float, and it returns in rare circumstances an
incorrect value, fixing that bug is not changing the API as defined by the
spec.  I agree there are more subtle examples that would cause debates to
be had, and if escalated it would ultimately mean a judge being asked to
determine if a change broke compatibility, probably not a good thing.  =)

 Is your intent to prevent people from adding new features and calling it
 the same?

Primarily it's to prevent someone from intentionally removing/breaking
functionality but trying to claim they implement the same API, then adding
new functionality, trying to move people to that new API because it's the
only one that appears to "work".  For example, think Microsoft and Visual
J++ for example, where MS claimed to implement the java.* classes and be
compatible, yet they were broken in subtle ways (intentionally), and the
docs recommended developers use the com.microsoft classes instead.
Trademark in that situation was a weak instrument to try and use to
enforce conformance, for reasons you can read about in the history of the
MS/Sun Java case.  Developers who didn't particularly care about
compatibility and used VJ++ because it came free from MS weren't incented
to mandate compatibility from MS, so market pressure wasn't there.
Outside of the open source community, the drive to standards isn't nearly
as strong as we'd all like to think.

  It doesn't limit the right to fork at all, but it does somewhat carve
  out an API namespace; the example of MS using something like this to
  prevent Win32 reimplementation is probably a good example, where they'd
  put a license like this on their Win32 spec.

 This doesn't seem to be at all the same thing. Nobody has to execute
 a license of Microsoft's in order to implement the same API's as Windows,
 unless doing so involved creating a derivative work of some copyrighted
 material.

That's precisely what I'm saying.  What's the copyright on the
documentation for the Win32 API as provided by MS?

 What you're proposing sounds like it could be accomplished using
 trademark, and avoiding that whole sticky copyright-of-API's issue
 altogether.

Notice that what repels you about my proposal would still be possible in
that case, e.g., MS suing Wine developers for trademark violation.  At
least with the proposed copyright, your right to implement compatible
implementations would still survive.

Brian

Re: namespace protection compatible with the OSD?

[Brian Behlendorf]

On Thu, 19 Apr 2001, phil hunt wrote:
 IMO it could be hard to define what is or isn't the same behaviour.

Granted that "compatible" would need to be rigorously defined by the
license, and it would be up to the original copyright holder to ascertain
if a derivative work was non-compliant; and if the author of the
derivative work felt the original holder was unfairly labelling their work
incompatible, they'd take their debate to the court of public opinion, or
ultimately, a judge, who could rule in favor of the derivative author.

Note that this is the same situation as would be faced by a trademark
holder attempting to accomplish the same goal of API consistancy via
trademark law instead of copyright law - but in the case of trademark law,
if there were any examples of people who created even slightly
incompatible derivative works, my ability to enforce that trademark would
be seriously curtailed.  That would mean that I'd have to be much more of
an asshole to anyone creating derivative works - I'd have to go after the
independent developers just as much as the big guys.  Compared to
copyright, where I can selectively enforce without losing my ability
to enforce at all.  That's a pretty regressive situation, doncha think?

  Secondarily, I'm saying even if you didn't implement my code, but followed
  the published document that describes the spec (which I also put under
  this license), you'd have to follow the same rules.

 Clearly this has nothing to do with Open Source as such, and IMO
 is morally dubious to say the least.

It has everything to do with Open Source.  So far, most OS programs that
implement a published spec do so against specs with very liberal
copyrights - the IETF, the W3C, etc.  I'm worried about the more
"corporate" API's out there.  Wouldn't you be worried that MS might be
able to shut down WINE if they could claim the WINE developers got the
Win32 API docs under a copyright that said they couldn't reimplement it?
Someone already posted a link to the MSDN agreement that states that API's
you get through that service have this quality.  It's probably the main
reason we don't see big companies authoring Win32 alternatives anymore
(OS/2 was the last one, and yes I know that hidden function calls were the
bigger reason).  I would really like to find a good reason to shoot this
down on DFSG/OSD terms, and if I can't, then I'd suggest a patch to the
DFSG/OSD.   =)

  It doesn't limit the right to fork at all, but it does somewhat carve out
  an API namespace;

 So it limits the right to fork something that's plug-in compatible with
 the original? Users would have to make an extra effort to use the forked
 version.

No, if it's really "plug-in compatible", you can use the same API name.
If you change it's behavior in a way that breaks "plug-in compatible", or
however "compatible" is defined, you change the name.  In either case, the
advantages to forking are preserved - you don't have to rewrite code that
already exists.

Brian

RE: namespace protection compatible with the OSD?

[Brian Behlendorf]

On Thu, 19 Apr 2001, Lawrence E. Rosen wrote:
 And this IP lawyer will argue up and down that copyright law protects
 expression and not the underlying ideas.  Implementing a specification
 without copying code is creating neither a copy nor a derivative work of
 that specification.

Would you agree that if I took one of Shakespeare's plays and reworked it
into a screenplay, or novel, that my work would be a derivative work?
Throw in translating to Chinese for good measure.  Throw in adding some
extra scenes and characters to really flesh out my work, or to adapt it to
a new culture.  I think the idea of implementing an API is the same thing.
And I think this is a much closer analogy than using the tax advice given
by a tax book.

Certainly, if I wrote a novel that happened to coincidentally share plot
lines with a Shakespeare play, that's not something to worry about - only
patents and trademarks are so broad as to cover unintended parallels.

I think the issue is sufficiently grey that it's worth considering it a
threat to open source development, and I'd like to find an ironclad
argument against it, or fix the OSD/DFSG.

 I appreciate your informing me that this issue has fomented lots of
 discussion in the past in the open source community.  "Stallman's rebuff to
 Alladin [sic] Software" notwithstanding, the final decision may have to come
 from a court of law.  I, for one, would almost welcome such litigation,
 because I believe the open source community needs to take a stand against
 companies that pay lip service to open source principles while preventing
 open source development with closed specifications and standards.  This is
 hypocrisy.  As the open source community has long since proven repeatedly,
 particularly with its contributions to Internet-related software, the
 enforcement of appropriate standards can be encouraged and achieved without
 recourse to licenses that prevent effective open source development.

So far we have a couple data points - Apache, sendmail, bind - to suggest
that open source drives compatibility.  We have data points to the
contrary as well - glibc, html authoring tools, linux package formats.
We have lots of data points to suggest that the world outside of the
circle we know doesn't give a hoot about compatibility, they just "want to
get the job done" even if the long-term impacts are significant, because
those long-term impacts don't affect the developers in that situation.
I'm suggesting that taking an ostrich approach to those issues isn't good
for the open source community - either we find a way to accomodate these
issues within the open source milieu, or we figure out a way to mitigate
the need for them.

 You said that it's much more efficient to say "you can't use my code
 if you misuse my name" than "you can't use my name because I own the
 trademark."  That misstates the legal significance of the trademark.
 I was trying to point out that you CAN'T ALLOW someone to use your
 name -- e.g., ALL uses, even friendly ones, are misuses -- because it
 is YOUR trademark and not theirs.  If you allow a third party who
 creates a derivative work to market that derivative work under your
 trademark, without exercising control over the quality of his
 derivative works, you will lose your trademark.

OK, so that suggests that the ASF had better *not* go out and get a
trademark on "Apache", because we'll quickly lose it should we not become
Nazis about enforcing it.  This also suggests that anyone who has a
trademark on a name used by an open source package, under a license that
doesn't control how that name is used in a derivative work (a license like
the GPL, for example), has lost the ability to enforce that trademark.
That's absurd.  This is precisely why trademark is a poor instrument for
this purpose.  It also means there's no way we could advocate, say,
org.apache.soap to become an industry-wide API, outside of the ASF's
control.

 It is okay for a third party to say his derivative work is "compatible
 with" Apache, or "equivalent in functionality to" Apache, or "meets
 the specifications of" Apache, or even that it is "better than"
 Apache, but it is NOT okay for him to market his derivative work "as"
 Apache.  Apache should not allow anyone else to adopt its trademark
 for their software!  (The word "should" in that last sentence is as
 close as I'm going to come to giving unsolicited legal advice to
 Apache.)

OK, so when Debian creates an Apache deb package, and calls that package
apache-1.3.19.deb, and tells people "you can install apache by doing
apt-get install apache", are you saying the ASF should not allow
them to do that, without granting them specific approval to do so?  Note
that such an arrangement is not cool with Debian, as it would violate the
DFSG (and the OSD) by creating a second agreement limiting the right to
redistribute, as well as being specific to Debian.

I am not a lawyer, but I'm getting uncomfortably familiar with too many
things 

Re: namespace protection compatible with the OSD?

[Brian Behlendorf]

OK, so we have two new analogies to implementing an API, that of "baking a
cake from a recipe" and "that of building a house from blueprints".  I
still think the line between that and "write a novel based on a
Shakespeare play" is not defined.  What is the relevant case history,
especially in the field of software?  If we can find a precedent for or
against, we have an answer w/r/t the likely way a judge would rule.  And,
if it's true that a copyright on an API can't restrict the rights to
implement it, then my life becomes a lot easier.  =)

Brian

namespace protection compatible with the OSD?

[Brian Behlendorf]

Let's say I created a specification for an interface in Perl; call it
Foo::Bar.  Let's further say I published the specification, and a
collection of code that implemented it, under a BSD-style license, with
the sole added clause that any derivative work that changed the
implementation in a way incompatible with the specification for that
interface, needed to call its interface something else; it couldn't be
Foo::Bar, but it could be Foo::Baz, or whatever.

Why do this?  Because I wanted to make sure someone didn't take my code,
slightly modify it in an incompatible way, and try to confuse the public
about what the API Foo::Bar was supposed to do, whether intentional or
unintentional.

I suspect this would pass the OSD tests, but I wanted some validation of
that.  I see it as a cross between the trademark-related covenants of the
Apache license and the interface-changing clauses of the SISSL.

Comments?

Brian

RE: namespace protection compatible with the OSD?

[Brian Behlendorf]

On Tue, 17 Apr 2001 [EMAIL PROTECTED] wrote:
 Trademarks and copyrights, as I'm sure you know, are two entirely different
 types of intellectual property.

Well, sure, but using copyright law to protect naming has served Apache
well, at least.  There is still a substantial reason to not want to try
and fight name-related battles on trademark terms, because they are much
more slippery and consume more legal bills.  It's much more efficient to
say "you can't use my code if you misuse my name" than "you can't use my
name because I own the trademark".

However, my query isn't really about trademarks, it's about APIs.  Sure,
the trademark "Apache" could be embodied in the package name (e.g.
Apache::foo) but let's say I actually do want to incent derivative
implementations in the name of promoting an industry-wide standards; that
would be yet another reason *not* to punt this issue to trademark law, for
the reasons you cited.

 The "interface-changing" clauses of the SISSL create an entirely different
 problem.  A published specification can be USED by anyone who reads the
 specification to design and implement software.  The publisher of a
 specification cannot prevent that USE by those who obtain legitimate copies
 of the specification.  (The owner of the specification can prevent the
 COPYING of the specification under standard copyright provisions.)

There are IP lawyers I know who will argue up and down that software
implemented to a specification is a derivative work of that spec, so that
spec's copyright terms need to be obeyed (which is why I said both the
spec and the code were under my "call it something else if you're not
compatible" license) when creating derivative works.  I don't know that I
like that aspect, but I sure would not want to try and argue against them
in a court of law, because I can't find fault with that logic.

 A timely example I like to cite is the case of a book that teaches you
 how to calculate your income tax; you may be prevented from copying
 the book, but if you buy a legitimate copy you can't be prevented from
 using the techniques it teaches to calculate your taxes, or to
 implement software to do so.

It has been argued, though, that an API is copyrightable; look at
Stallman's rebuff to Alladin Software over implementing a shim for some
GNU library; by implementing the same API, Stallman argued it was a
derivative work, and Alladin's use constituted a GPL violation.  Not that
Stallman's opinion is all that matters, but it's telling that both he and
the hardcore IP lawyers I refer to above agree on this.

 There is a possible further complication with "standards" used for software.
 If the publisher of a standard allows the use of a certification mark -- a
 form of trademark -- on works that are fully compliant with the standard,
 then the certification mark can be limited to such fully compliant
 derivative (or entirely new) works.  I also believe it would be improper for
 the certification mark owner to REFUSE to certify software that meets the
 published standard, even if the software creator didn't obtain permission in
 advance from the certification mark owner to implement to that standard.

That actually sounds like the one positive argument in favor of using
trademark law for this - it helps prevent the spec publisher from
exercising unfair treatment on those who wish to implement an open spec.

 Confusion about these topics in the open source (and the entire) software
 community, reflected in the poor enforcement of trademarks, and in the
 overreaching by certain licensors to prevent things they may not like, is
 not uncommon.

 Does this help answer your questions, Brian?

It's been good feedback, yes.  Thanks!

Brian

Re: Apache vs. BSD licenses

[Brian Behlendorf]

On Tue, 20 Mar 2001, Rodent of Unusual Size wrote:
 Ian Stokes-Rees wrote:
 
  If we were to do this, and subsequent developers were to do the
  same, then each developer who redistributed the accumulated code
  base with new files and entirely new code which they put under
  _their_ version of Apache License, the credits list would grow
  and grow.

 That is a consequence of the ASFisms or their replacements, not
 the licence terms themselves..

Actually, Ken, Ian is right.  If there is a bundle of code that contains
ASF code, which has an Apache License 1.1-style license on it requiring
attribution to this other party, then both the ASF and this other party
need to have their credits remain.  The license terms do require this, and
it's not likely to change in the near future, since people in the ASF
believe pretty strongly in attributing credit where earned.  If you have a
string of derivative works, you have a string of attributions.  You can
remove an attribution from that list only if you're sure none of that
contributor's work is being used anymore.

Personally, I think this is a pretty small thing to ask.  Even with 1000
contributors representing a chain of 1000 derivations (whereas these days
you rarely have two or three) such an atribution would take under 100K of
text, or 10K compressed.  Giving credit is an inexpensive way of spread
the benefits of participation in an open source project, and costs the
current developers essentially nothing.

Note that this "advertising clause" is much different in 1.1 than in 1.0.
In fact, it was carefully written to *be* GPL compatible.  The clause
"Alternately, this acknowledgment may appear in the software itself,
if and wherever such third-party acknowledgments normally appear" can
apply to sourcecode as well - that is, if you have a GPL tarball that
contains Xerces code, you are of course distributing source, and that
acknowlegement appears in the source to the Xerces code, where such a
"third-party acknowledgment normally appears".  I've discussed this with
Stallman and he agrees, grudgingly, that clause 3 is not GPL-incompatible.
Such notices will persist, as well, because the GPL does not allow you to
remove copyright notices on included code (I believe...).

He still has an issue with clauses 4 and 5, though, which are a device to
help protect us against someone creating a proprietary fork and calling it
"ApachePro", or "Apache++" or whatever.  Stallman believes such things
should be enforced through trademark law.  I think anyone who's been
through trademark law proceedings would tell you to avoid it at all costs
- trademark law is all about who has the more expensive lawyers arguing
your case.  :/  By making it a term of copyright, we protect that interest
in a much more direct way.

Stallman has indicated to me that clause 4 ("Apache" may not be used to
endorse) will be compatible with the GPL v3, but clause 5 ("Apache" may
not appear in the product name) will not.  I think this is unfortunate, as
in a digital environment, your good name is your only asset, and
protecting it shouldn't be hard.  I don't see asking someone to choose a
different name for a derivative work as not qualifying as "free" as the
FSF defines it.

Brian

Re: Apache vs. BSD licenses

[Brian Behlendorf]

On Tue, 20 Mar 2001, David Johnson wrote:
 On Tuesday March 20 2001 06:12 pm, Brian Behlendorf wrote:

  Stallman has indicated to me that clause 4 ("Apache" may not be used to
  endorse) will be compatible with the GPL v3, but clause 5 ("Apache" may
  not appear in the product name) will not.

 Why is it always the non-GPL license that must conform? Why is the GPL never
 criticized for being incompatible?

Er, actually, it sounds like he's considering substantive changes in
GPLv3, or at least "clarifications" for the pragmatic purpose of
explaining or reconciling compatibility issues, so long as it doesn't
change his core beliefs about what constitutes "free".

Since the Apache community's views on IP are not incompatible with the
FSF's (Apache developers are already comfortable with the idea that
commercial entities can use the code in proprietary products without
contributing anything back; the idea of someone using Apache code in a
GPL-licensed derivative work is no worse) I've been attempting to
reconcile our licenses to allow GPL derived works.  The
managing-our-identity-through-copyright-law-instead-of-trademark-law
issue is now all that separates us.

Brian

Re: boomberg bloopers

[Brian Behlendorf]

On Thu, 15 Feb 2001, Ralf Schwoebel wrote:
 We still wait for comments from the board on our license, but
 meanwhile please comment on that:

 http://news.cnet.com/news/0-1003-200-4833927.html?tag=mn_hd

Heh, I wish they had included the part where I said if MS really said that
Open Source was a threat to "innovation" and inellectual property, then MS
doesn't understand copyright laws OR open source.  I'm glad the opposing
viewpoint made it in there, it was actually an IDC analyst I talked with.

My comment about "fascist" was in the context of explaining that most
companies who are involved in open source development do so because it can
enhance their revenues elsewhere - in hardware, services, or even other
proprietary software.  I gave the example of Linus and Transmeta as one
where there is a mixed model of closed and open.

Note of course, Ralf, that Linus has a very clear notion about what is
Open Source, and what is not, and don't try to claim otherwise.

This is the start of a concerted effort by MS to attack Linux on
non-technical fronts.  I can see them aiming to compare the effect of Open
Source on the software industry to be equivalent to the effect of Napster
on the music industry.  Bullocks - you may agree or disagree with the
contention that swapping someone else's IP against their will is theft,
but you can't claim that someone who writes software and *intentionally*
gives it away for free is a threat to anyone.  This is a pile of manure
so silly that even the press won't buy it.  Next they'll attack it on
patent, trademark, and labor law bases.

 I think, "FREE does not mean GRATIS" is totally stated wrong and
 some native speakers should write to Bloomberg to get their head
 into the right place, and I guess they left half of the statement of Brian
 out. I do not have the perception of Collab.net to put that incomplete...

 Does Microsoft own Bloomberg? Or do they invite journalists to
 cruiseship trips to the carribean sea?

Uh, Bloomburg isn't giving an editorial in this article, they're reporting
what people said.

Brian

Re: OpenDivX license

[Brian Behlendorf]

On Sun, 21 Jan 2001 [EMAIL PROTECTED] wrote:
 A philosophical point first:  I believe that attempting standards
 enforcement through copyright licensing is fundamentally broken.  We've
 seen this tried several times, with the Artistic (control over "Perl"
 name), and SCSL licenses, the results tending to be that the license
 doesn't work as intended or doesn't meet the OSD.  Wrong tool for the
 task.

Thoughts on the SISSL?  It doesn't make adherence mandatory, but it does
say you have to release a reference implementation of your divergence from
the standard.

 I'd argue that tying allowed modification to specific compatibility
 standards is a violation of:
 
   - Condition 3, Derived Works:  Is the original license bound to the
 same terms, or could the authors modify the code to be incompatible
 with the MPEG-4 standard.  This might be a stretch, but I'd argue it
 hard.

The license does *allow* derived work (allow != unconditionally allow),
and that derived work, since it's conformant to the standard, can be
distributed under the *same* terms.  However, the protocol standard
effectively enumerates more conditions on that allow, and if any of those
conditions are not OSD conformant (my CSS example), the license as a whole
is not.

   - Condition 6, Discrimination against fields of endeavor:  This is IMO
 far more clear cut.  Restricting application of the license to code
 meeting specific compatibility requirements is imposing a
 restriction that a work *not* adhering to this standard is not
 permitted.  The discrimination is against any field of endeavor
 which isn't directly focused on MPEG-4.

This whole clause is a seriously vague mess, because "field of endeavor"
isn't defined anywhere and has no (that I know of) rigorous standard
definition in copyright law.  By one stretch, the GPL discriminates
against a field of endeavor: the commercial-license-driven software
market.  You may say, "but what if I just want some small bit
of the code, like a compression algorithm, to use in a web server?  It
doesn't even make sense to talk about MPEG-4 in that case."  Well, that's
a *practical* issue, but many open source licenses have that problem.

On Sun, 21 Jan 2001, Ben Tilly wrote:
 What do you think about permitting any change you want, but
 requiring changes that break a given standard to state that
 fact whenever and wherever they display notifications that
 it is derived from __X__ that it does not actually meet
 standard __Y__?

I don't see it as affecting OSD conformance.  Personally speaking, I don't
think it's strong enough - I prefer the SISSL's requirement of publishing
a reference implementation of your changes, so that you can't use that
noncompliance to gain market advantage.

Brian

Re: Cherry-picking license proposals

[Brian Behlendorf]

Sorry if this seems pedantic...

On Sun, 21 Jan 2001 [EMAIL PROTECTED] wrote:
   - Convergence.  Despite some degree of internal conflict, the final
 nail was really the result of independent external resolution of
 many of the issues we had sought to address.  As of the last meeting
 (O'Reilly Conference, July, 2000), the landscape was clearly
 shifting to focus on what seemed to be three principle licensing
 models:
 
 - GNU GPL/LGPL:  A primary license for HP's EZSpeak (?) project,

e-speak.  Also OpenOffice.

   adopted as part of multi-licensing models by Sun, Mozilla, and
   others.
 
 - Mozilla Public License:  With very minor wording changes, adopted
   by Sun as the SISSL.

Uh, no.  Adopted by Sun for the "SPL", under which they've released
NetBeans.  The SISSL is much different, much shorter, more in spirit with
the BSD licenses than the other two.

 - BSD/MIT style:  Apple's Darwin code is derived from BSD sources,
   and Apple appears more comfortable with the BSD licensing model
   than GPL.  Apple's own licensing has changed within the past
   month, I still need to review the changes.

Yes, but to be clear, Apple's APSL is much different than the BSD license.

Brian

Re: IPL as a burden

[Brian Behlendorf]

On 16 Jan 2001, Ian Lance Taylor wrote:
 Manfred Schmid [EMAIL PROTECTED] writes:
 
  To me, a lot of the discussion gets down to the "free beer" question.
  May I ask the Board for an official statement: Is the charging of
  license fees (or execution fees) definitely a no-go to qualify it as
  OSI-compliant Open Source?
 
 You may ask this question, although I already know what the answer
 will be.  

I'm no longer on the OSI board, but my opinion is, there's no way in
tarnation I can reconcile a mandatory fee for execution (no matter what
name you give it) and OSD conformance.

Brian

Re: Modifying existing licenses in minor ways

[Brian Behlendorf]

On Thu, 14 Dec 2000, Danese Cooper wrote: 
 Second, I might agree with you about the role of OSI in certifying licenses
 which are essentially OEM'd from "approved" licenses...but OSI would
 disagree with you  me.  Sun was required to submit our version of the
 Mozilla Public License (our Sun Public License), even though the changes
 were well documented and not substantive.  I think you need to plan to
 submit your version (and the delta from our SISSL) to OSI, and hopefully
 they'll turn the request around quickly.

To be clear, it was the "and documentation" piece which mandated the
reapproval.  A change in naming is fine and doesn't require explicit OSI
approval, but anything that changes the substance of the license does.  It
would be nice if people named their licenses in a non-company-associating
way, and put definitions for proper nouns at the very top, abstracting all
this out.

Brian

Re: What license to pick...

[Brian Behlendorf]

On Fri, 29 Sep 2000, Lionello Lunesu wrote:
 So we (my company) have decided to make our VR-toolkit open source! 
[...]
 AND we don't want other people to be able to create their
 own distribution of the toolkit. 

These two are inconsistant - the OSD essentially requires that others be
allowed to created their own modified release of your code.  That doesn't
mean you can't prevent them from using your name.

Brian

Re: What license to pick...

[Brian Behlendorf]

On Fri, 29 Sep 2000, Lionello Lunesu wrote:
 Does the GPL allow us (the toolkit creators) to ask a fee for commercial use
 of our toolkit?

Not specifically, but it doesn't prevent you from separately licensing the
code that you own to someone under terms other than the GPL.  You *have*
have the right to relicense that code, though - meaning you'd have to
acquire it from any contributor.

Brian

Re: Qt and the GPL

[Brian Behlendorf]

On Tue, 5 Sep 2000 [EMAIL PROTECTED] wrote:
 The BSD SW would convert to GPL, which is allowable if it doesn't
 contain the advertising clause.

Not according to Stallman, there are issues with other clauses.  This is a
popular misconception.

http://lists.debian.org/debian-legal-0006/msg00119.html

Brian

Re: RMS on OpenMotif

[Brian Behlendorf]

On Sun, 20 Aug 2000, John Cowan wrote:
 RMS writes (copied here under a claim of fair use):
 
  Here are some of the problems of the Motif license:
  
   It claims that you accept the license merely by "using" Motif. Only
   a shrink-wrap license or something similar can do that, and shrink-wrap
   licenses are a bad thing. 
 
 I agree with this, except that I think (without some statutory confirmation
 of the legitimacy of such licenses) that the reference to use is vacuous
 and unenforceable here. (Of course IANAL.)

Agreed; though unenforceable clauses generally have no bearing on OSD
conformance by themselves, unless they specifically contravene the
OSD.  It's within the right of OSI to approve licenses but also include
additional commentary, for instance stating that this would be an
unenforceable provision.

   The license is restricted to use on certain operating systems, those
   which fit a category they call "open source". Both the Free Software
   Movement and the Open Source Movement consider use restrictions
   unacceptable. 

Stallman is correct here, we would not approve such a license.

  Their definition of the term "open source" is very different from the
  one used by the Open Source Movement, thus causing confusion.
 
 Similarly, the FAQ explicitly states an intent to conform to the OSD.  

Yep, we've notified the OpenGroup about this, and received no response.

Brian

Re: License Approval Process

[Brian Behlendorf]

On Thu, 17 Aug 2000, Alexandra White wrote:
 I wanted to get some feedback about the best way to assist in
 streamlining OSI license approval for customers.  

OSI is doing what we can to approve licenses; in fact we approved a couple
at a meeting this week during Linuxworld, once we get our meeting minutes
together we'll post the results.  At the same time, we don't want to be
rushed and make a bad decision, like we did once.  Some of these licenses
also really push us on what OSD conformance means - the OSD is not as
clear as it could be (what does it mean to not discriminate against a
"group of people" - how about the "group of people who refuse to accept
the license"?) So I don't know the right answer to give you, other than,
we're busy but we're trying.

 1) For instance, we have a number of customers who we are helping to
 take their code to the open source and thus are assisting in getting OSI
 approval for them.  While we encourage them to use existing open source
 licenses rather than creating their own, many want to simply rename the
 license with their product name but keep the license identical. Thus,
 they could label it "Acme Software License (BSD)"  In this case, can we
 assume that the license is OSI-approved?

Simple renaming is fine; but then I have to ask, why rename?  Why not just
call it the BSD license?

 2) What minor changes to an existing OSI license are acceptable without
 seeking approval?

Changing the name is about the only one I'd consider.  And it must be
clear that we didn't approve "Acme Software License", we only approved a
*similar* license.  I've proposed to the board that we genericize the
licenses and allow people to change entries in a header at the top, we're
considering it.

I know Vovida's license has only a few minor changes from BSD; to me they
look fine, but they still require discussion amongst the board and
potentially people on os-discuss.  I.e., what does it mean to disclaim
liability, "in excess of $1000"?  I've talked with Alan about it, and it
sounds like a formality associated with the UCC, but why it's $1000 and
not $1, I still don't understand.  Still, that may not matter w/r/t OSD
conformance, but it's still worth pondering.

 3) In the cases where a customer does need OSI approval, how can I help
 them expedite the process to get a timely response?  For example, I
 submitted a license on June 9 for Cadence and have not heard any
 feedback on its progress. 

You're right - it's not on the long list that Larry posted last
week.  Larry, could you make sure it's on the list?

Brian

Re: Does Sun adopt Gnome ?

[Brian Behlendorf]

On Thu, 17 Aug 2000, David Johnson wrote:
 I goes even further than this. One of the founding principles of GNOME
 was that unfree software made people unfree. Praising Sun for choosing
 GNOME as the desktop for their proprietary Solaris seems to throw
 these principles right out the door.

It's a fairly well-known fact that the main reason most of the proprietary
Unix vendor's operating systems are *not* free today is that they all use
a significant amount of licensed third-party code that would be well-next
to impossible to rip out or replace without a seriously huge investment
(more than occurs on most major-version-number releases anyways), and
an open source license would prevent those companies from recouping those 
costs.  In many cases those third-party companies no longer exist except
for a shell that survives on the revenue from continued licensing, and
who thus have no reason to give that revenue up.

Instead, the best approach for those vendors (and one the open source
community *should* be applauding) is for the gradual replacement of closed
components of these systems with open components.  Some people, instead,
prefer an all-or-nothing mindset; I don't think that attitude is why
vendors are picking up on open source these days.

It's like the difference between shoving someone down a flight of stairs,
or leading them by the hand as they walk down.  We're all still arriving
at the same place, but one approach is far more effective than the other.  

Brian

Re: StarOffice under the GPL ?

[Brian Behlendorf]

On Wed, 9 Aug 2000 [EMAIL PROTECTED] wrote:
 I'll have to give it a closer read, but I believe there's also a
 definition of what it is to be an API in the Sun version of the license.
 I'm talking through my hat as I'm not looking at SISSL at the moment.

No need to speculate, it's online and in HTML, at

  http://www.openoffice.org/project/www/sissl_license.html

It doesn't really "define" a standard so much as give a template (in
Exhibit B):

  The Standard is defined as the following: 
* OpenOffice.org XML File Format Specification, Version X.n
  Date: mm/dd/2000 
* OpenOffice.org Application Programming Interface Specification,
  Version X.n
  Date: mm/dd/2000 

The most interesting section of the license is 3.

I believe it's fair to say, as a very gross simplification, that the terms
are this: if you stick to the standards, it's BSD-like (i.e. you may
create a proprietary fork) but if you "deviate" from the standard (i.e.  
fail the "must comply with all specifications set out by the Standards
body" test) then you must release the source of your deviation under the
SISSL, thus GPL-like.  Now, you can actually release just a "reference
implementation" of your change if you like; that seems fair.  

I don't have the faculties to determine this right now, but it seems like
this license might even be GPL-compatible (e.g., the "larger work" made
when combining SISSL and GPL code must be collectively licensed as GPL).

Brian

Re: StarOffice under the GPL ?

[Brian Behlendorf]

On Tue, 8 Aug 2000, Brian Behlendorf wrote:
 There *is* a Sun Public License modeled
 after the NPL, pretty much s/Netscape/Sun/, which Netbeans was released
 under (www.netbeans.org).

Sorry, my bad, the Sun Public License is a verbatim (except for
substitution of the terms "Mozilla" and "Netscape" with the term "Sun" and
addition of "documentation" to the list of covered items) copy of the
Mozilla Public License, NOT the Netscape Public License.  The NPL is not
an open source license, because it has language that carves out some
redistribution rights for Netscape, which the MPL does not.

Brian

Re: StarOffice under the GPL ?

[Brian Behlendorf]

On Tue, 8 Aug 2000 [EMAIL PROTECTED] wrote:
 StarOffice will be released under the GNU General Public License and the
 SISL (a Sun-written variant of the Mozilla Public License) on October
 13, 2000.

Actually SISSL is quite different from Mozilla.  It uses some common
definitions which is why is appears similar at first, but it is much less
restrictive overall than the MPL.  There *is* a Sun Public License modeled
after the NPL, pretty much s/Netscape/Sun/, which Netbeans was released
under (www.netbeans.org).

SISSL has been submitted to OSI for approval and is being considered.

Brian

Re: How About The Apache License?

[Brian Behlendorf]

On Mon, 24 Jul 2000, Rodent of Unusual Size wrote:
 John Cowan wrote:
  
  The Apache license is just the old BSD license, with what is sometimes
  called "the obnoxious advertising clause".
 
 That clause was removed in 1.1 of the Apache licence.

More precisely, replaced with a much less "obnoxious" clause that still
asks for credit.

Brian

Re: Apache v. GPL

[Brian Behlendorf]

On Tue, 11 Apr 2000, Rodent of Unusual Size wrote:
 I should point out that V1.1 of the Apache licence has followed the
 model of new-BSD; see http://www.apache.org/LICENSE.

Note that this new license has only been applied to the current tree,
both 1.3 branch and 2.0 branch; apache 1.3.12 and previous releases are
all under the older license.  Also, the Jakarta and XML Apache projects
have been using this new license since their initial releases.  I'm not
sure if mod_perl has picked this up yet, nor mod_jserv.

 Is this new licence now GPL-compatible?

When I asked Stallman he said he found it much less troublesome than the
older one, but didn't issue an official declaration or anything.  

Brian

Re: OSI board asleep at the switch?

[Brian Behlendorf]

For my part, it's overload.  I filter the messages into a box that
now stands at 1200 messages long, and I never have the 4 hours I would
anticipate it taking just to properly read and delete the messages in
there, let alone keep up.  I also have responsibilities to the Apache
lists (unread mail now standing at 3400 messages).

Bruce is right, if OSI is to claim to represent the interests of this
community, we need to be more responsive.  I've strongly considered
resigning due to lack of time to adequately represent this community by
responding to it.  I've held on because we appear to be making progress on
finding and accomodating an executive administrator - not someone to make
decisions for the board, but someone to handle a lot of the mechanics of
what we do.  For example, we should have a license tracking tool to
monitor submissions, take votes from the board (and the community), and
call and close voting periods.  We should organize some assistance on the
web pages, and perhaps open up the CVS tree for that content so others who
are motivated to help can easily do so.  Etc etc.

Though I can only speak for myself, the simple fact seems to be that
many of us "leaders" in the Open Source community have worked ourselves
into positions where we are now charged with showing that it can work.
The honeymoon is over - the current Linux stock prices and Linuxcare's
delayed IPO should make this pretty clear.  So I've been working 90 hour
weeks (15 hours/day 6days/week) to make both collab.net and apache.org
work; I apologize for not having another 2-5 hours a week to spend
on OSI.  

Since the Open Source method is to always empower those with itches the
ability to scratch them, I suppose what we could do to address this is
send a call out for assistance along these lines.  Anyone want to write a
pile of PHP to build a license submission management tool?  (No, I do not
want to use gnats, jitterbug, or bugzilla for this, thanks)  Is anyone
*serious* about wanting to help the web pages?  (we get inquiries, we ask
for suggestions on what to change, we never get a response back).  Are
there any other things we should be doing, as OSI, that we are not, and
that people would volunteer to help out with?

I am very open to suggestions.  I have not cleared this query with the OSI
board at all; this is me asking independently, so do not confuse this with
a formal invite from OSI to grant access to all comers.  But I think I can
speak for the board to say we realize things are broken, and need help,
but need help figuring out what the best solution is.

Thanks.

Brian



On Wed, 5 Apr 2000, Matthew C. Weigel wrote:
 I am hoping also that the difficulty so many have had with unsusbscribing is
 due to similar issues.  I experienced this recently myself, when I noticed
 that I hadn't seen an OSI board-member post in quite some time, nor indicate
 they'd read a single blessed thing.
 
 The directions to unsubscribe don't work, and while I've tried to be polite
 and simply delete everything as it comes, it's gotten annoying when heated
 discussions ensue.
 
 On Wed, 5 Apr 2000, Bruce Perens wrote:
 
  I'm told privately that this is incompetence and not conspiracy. But that
  doesn't make it any less of a problem. We need to track this.
  
  Thanks
  
  Bruce
  
  
 
  Matthew Weigel
  Programmer/Sysadmin/Student
  [EMAIL PROTECTED]
 

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
collab.net  |  open source  |  do what's right  |  now hiring smart people 

Re: I don't want to see you !!!

[Brian Behlendorf]

On Wed, 16 Feb 2000, Igor Popov wrote:
 how to unsubscribe from this group ???
 please help me!!

email [EMAIL PROTECTED]

Brian

Re: SOS license

[Brian Behlendorf]

On Tue, 9 Nov 1999, Alex Nicolaou wrote:
 I'd appreciate it if you could take the time to point out the
 ambiguities and self-contradictions. I worked hard to make the language
 as plain and unambiguous as possible!

"plain" and "unambiguous" are usually not compatible notions.

 I could not find a license that was simultaneously:
 
 1. less than two pages long

I think the BSD, Apache, and Artistic licenses qualify under that
one.

 2. clear about what was a derived work

Why should a license redefine what copyright law defines?  

 3. permissive in allowing patch distribution under other license terms

An author can *always* distribute patches under a license of their
own choosing, at least by my reading of fair use.  Also, it looks like
even if people modify the software for personal use, they have to publicly
post their patches.

 4. explicit about how the "official" version of the software is
 distributed

That's not a copyright issue, it's a trademark issue, though the
copyright license can tie the use of that trademark to rights granted by
the license.

Brian

Re: Accusations, accusations, always accusations

[Brian Behlendorf]

On Mon, 18 Oct 1999, Richard Stallman wrote:
 Since this concept of getting "credit" for software seems to be so
 important, it probably should be embodied in the license. 
 
 I disagree on principle; however, even if I agreed, I see no way that
 a license could be written to address the issue.

Yay, a discussion about licenses on license-discuss.  In the new Apache
license (which has not yet been applied to the HTTP project, but is being
used on Jakarta), we have changed the much-maligned "advertising clause" 
to read:

   3. The end-user documentation included with the redistribution,
  if any, must include the following acknowledgment:  
 "This product includes software developed by the
  Apache Software Foundation (http://www.apache.org/)."
  Alternately, this acknowledgment may appear in the software itself,
  if and wherever such third-party acknowledgments normally appear.

It may not be satisfactory to Richard, but it does address the issue, and
is much more liberal (by being more specific) than the older one.

Brian

Re: GPL + advertising clause

[Brian Behlendorf]

On 12 Oct 1999 [EMAIL PROTECTED] wrote:
 interesting you should bring this up now. The University of California
 recently removed the advertising clause from the BSD license in order
 to make it GPL-compatible.

Are you sure that was the reason?  Or was it that the clause was
unenforceable as they had not been enforcing it previously?

 Why not just use the GPL and politely request in a notice attached to it
 that you be acknowledged in advertising, packaging, web sites, whatever
 you want? Most people will do it. 

In the situation I was discussing a few days ago, this would almost
certainly not happen.  It's not the open source community that's the
concern, who I agree would most likely give credit where credit is due.
It's the downstream manufacturers of derivative software (and hardware
it's embedded into), who will follow the letter of the GPL by distributing
a CDROM with all the necessary bits, but otherwise will most likely do
everything possible to bury knowlege of the upstream project.  There's
unfortunately no way to really test the waters with this, either.

Brian

Question about GNU/Linux the advertising clause of BSD

[Brian Behlendorf]

So, I've been thinking about Stallman's desire to see people call
Linux GNU/Linux; and comparing that to his stated (if I recall correctly)
criticism of the advertising clause in the original BSD and Apache
licenses.  By the way, the advertising clause in Apache has been changed -
it's now

 * 3. The end-user documentation included with the redistribution, if
 *any, must include the following acknowlegement:  
 *   "This product includes software developed by the 
 *Apache Software Foundation (http://www.apache.org/)."
 *Alternately, this acknowlegement may appear in the software itself,
 *if and wherever such third-party acknowlegements normally appear.

With this as context, let me ask this list a question.  Bruce, I believe
this is on topic for this list, as it does strike at an OSD issue.

I am advising a company that wants to build a significant library of open
source software for a software niche which until this point has been
completely closed and proprietary and expensive.  This niche is usually
combined hardware and software, and this company is hoping to use
commodity hardware and free software to commoditize this niche and
position themselves in a "Red Hat"-equivalent role.

They want to use the GPL and the LGPL for their software - which makes a
lot of sense, this is a community where the liklihood of a commercial
vendor doing a proprietary fork is quite high.  However, even with
competitors following the mandates of the GPL and LGPL when it comes to
releasing modifications, there is a concern that the brand name behind the
original source code would be lost, and that the momentum behind the
original project would not materialize, because most end-users would not
even know about the origins of the code.  This hurts, because it means
that the network effect may never happen, and this single company could
end up paying for development for the rest of the industry, who get a free
ride.

This is an area where the (ex-)BSD or Apache advertising clause would help
- in fact, they'd like a particular logo associated with the project to
appear not just in advertising materials, but on the hardware that when
sold includes this software by default.  This is also a market where the
end-users will typically not even *know* they are dealing with software -
to them it's a hardware piece which performs a particular task
transparantly and usually has no need for customization.  So merely asking
for a note in the README or documentation would be insufficient if part of
the point is to make everyone aware of the upstream origin.

I think, ethically, this is OK - this is one way to prevent "frivolous"
forks, even though I think we all agree the right to fork is essential.
The question is - how do we reconcile it with the GPL/LGPL?  Is this
company forced to create YAOSL (yet another open source license), when all
it is is a GPL with an ad clause?

Anyone else have a good idea on how to make end-users aware of the
upstream origin of the open source software they are using?

Maybe the answer is already there, and my brain cells are just tired
tonight.

Thanks for any insight.

Brian

Re: Question about GNU/Linux the advertising clause of BSD

[Brian Behlendorf]

Small clarification:

On Sun, 10 Oct 1999, Brian Behlendorf wrote:
  ...
  I think, ethically, this is OK - this is one way to prevent "frivolous"
  forks, even though I think we all agree the right to fork is essential.

s/prevent/discourage/

We wouldn't want to prevent forking.

Brian

Re: license-review mailing list

[Brian Behlendorf]

On 23 Sep 1999 [EMAIL PROTECTED] wrote:
 I'm not asking you to be disciplined about you say. I'm just asking for two
 lists, so that it gets said on one and not the other. 

How about instead of changing the list charter (and thus causing those you
brought onto this list and are trying to keep here to have to jump yet
again) we create another list as an "outlet" for discussions that start
here but lose their relevancy to reviewing proposed licenses.  That
second list should have some sort of mission of its own, but it could be
far looser, much like Russ's Free Software Business list.  That mission
will lead to a name for the list.  I don't think something like
[EMAIL PROTECTED] would be productive, though.  =)  Any
suggestions?

Brian

Re: Essay RFC delayed.

[Brian Behlendorf]

On Mon, 23 Aug 1999, Richard Stallman wrote:
  I believe more hackers would rather listen to Richard than to you, Eric.
 
 I disagree.  I think both of them are worth listening to.
 
 I think there is no need to compare, because Eric and I mostly talk
 about different things.
 
 I think Eric has had some worthwhile and insightful things to say.
 I've been impressed and persuaded by some of them.  Convincing
 business with practical arguments can help our community.
 
 However, Eric and the Open Source movement deliberately avoid the
 issues that I focus on most: issues of principle.  They do not say
 that we deserve freedom to share and change software, 

That would be incorrect, at least from my vantage point.  A core principle
of the Open Source Definition is the right to fork - which is, the right
to share and change software beyond the control of the original party.  
Whether this mandate should be viral upon derivatives is, of course, where
we differ.  However I think it is as important as the right to examine
code and be able to modify it for personal use, as it is the main device
for securing the long-term availability of the code - code that can not
be forked can wither and die against the wishes of others, either by
design or accidentally. 

Also, I want to clarify a statement I made earlier regarding GNOME - I did
not mean to imply it wasn't part of the GNU Project.  I still don't think,
though, that everyone who works on GNOME does so for primarily political
reasons, and for that reasons I question those who claim it's part of a
"movement".  Clearly Richard, and Miguel, have a different opinion.
That's fine.

Brian

Re: Essay RFC delayed.

[Brian Behlendorf]

On Thu, 19 Aug 1999, NotZed wrote:
 It just happens to be a little difficult to talk about another project
 in this case, because Gnome is the project under study.
 
 I would have to agree with Richard, it is part of the free software
 movement, not the "open source" one.  Although the means are often
 identical, the goals are not the same at all.

If anything, GNOME is part of the "GNOME movement" - any other group
trying to take credit for it or call it their own, should reconsider
their position. 

Not that this has anything to do with license-discuss.

Brian

Re: Draft 1 of the OpenDesk.com Public Source License

[Brian Behlendorf]

On Thu, 18 Nov 1999, David Starner wrote:
 On Thu, Nov 18, 1999 at 10:38:38AM -0800, Brian Behlendorf wrote:
  
  Sure.  And the amount of code sharing between NetBSD, OpenBSD, and FreeBSD
  is *much* greater, as best I can tell, than the code sharing between the
  various Linux distributions.
 
 How? Linux distributions, for the most part, have the same upstream source
 - to which most apply small, if any, patches to - for the main shell, for the 
 kernel, for shellutils, for fileutils, for libc, 

I'm not just talking about the kernel, I'm talking about the distributions
as a whole.  And I'm not going to get scientific and quantifiable about
it, I'm just relaying my experiences as a serious Linux (I run Debian on
my Vaio) and BSD (FreeBSD is what I run on most of my servers) user.
Dealing with the whole libc debacle has burned me pretty badly.  The LSB
is a great effort and I hope it really does result in less frivolous
divergence between the distributions, but since all but one of the distros
are commercial endeavors, there is always going to be a drive to see
"value-add" and "differentiation" that may not be technically based.
Whereas, *BSDs are all centrally not-for-profit (not non-profit, just
not-for-profit), so there is much less ego attached to the notion of
projects sharing code.  For example, even though OpenBSD might have a more
aggressive pool of code auditors, the bugs they fix do get pulled over to
FreeBSD and NetBSD, by and large.  Things could be better, of course - the
ports collection could be a shared resource between *BSD's.

 for most of the stuff that 
 the BSDs have seperate versions for.  

The utils aren't all that different between them, actually.  

 Anyway, I specifically didn't mention the free BSD's, as the reason they 
 forked probably has little to do with the license. 

Forking usually has very little to do with licenses.

 I was discussing SunOS,
 Aix, BSDi and the other proprietary Unixs that took some to most of their 
 code from BSD.

SunOS has been dead a long time.  BSDI is struggling.  AIX is several
generations past its BSD origins.  *BSD has more market share, I'd
estimate, than the three of those combined.  While BSD gave those
companies a temporary advantage, by keeping the fork proprietary those
companies missed out on further development.  Which is the main point the
BSD advocates make - more often than not, proprietary forks
provide a short-term advantage at best.  Sometimes that short-term
advantage is necessary to bring players into the space, but ultimately
they will find that participating in the project and differentiating
elsewhere is the most successful strategy.

Brian