Advertising Clauses in Licenses

[Michael Bauer]

A simple solution seems to be simply requiring a URL for the appropriate 
credit.  The list of credits could be automatically compiled using an 
appropriate convention and be as long as necessary.  It would certainly 
save space.  I suppose there is some technical legal reason why this 
won't work, right?

On Sun, 20 Jan 2002, Karsten M. Self wrote:

> on Sun, Jan 20, 2002 at 12:07:53PM -0800, Lawrence E. Rosen (lrosen at rosenlaw.com) wrote:
> 
> > The FSF website (http://www.fsf.org/philosophy/bsd.html), specifically
> > discussing the "obnoxious" BSD advertising clause, argues that
> > advertising clauses in licenses potentially lead to long lists of
> > acknowledgements in derivative works.  RMS wrote that in 1997 he
> > counted 75 such sentences that needed to be included in one version of
> > NetBSD.  
> > 
> > I am unmoved by this perceived threat to free or open source software.
> > The individuals and communities who create free and open source
> > software deserve to receive credit for their contributions.  Is it
> > asking too much to require the authors of derivative works to
> > acknowledge the contributions through simple notices?
> > 
> > Suppose the list of contributions grows long.  Is it expecting too
> > much for the authors of derivative works to include a text file
> > listing those contributions along with the software?
> 
> These comments are meant to amplify Bruce's comments.
> 
> It depends on where this text must be kept, relative to the software.
> 
> I worked with RMS and Tom Oehser of Tom's Root Boot (TRB), a 1.77 MiB
> formatted floppy disk with a live GNU/Linux system on it.  In this
> particular instance, space (and project management) are at a premium --
> the obligation to carry license on the disk itself means that software
> would be displaced.  TRB is a study in code compaction and squeezing the
> most functionality out of every available byte.  
> 
> In this case, both license and source obligations were managed by
> keeping files separate.  A downside is that the previous symmetry of TRB
> was broken -- there's a component which must be distributed separately
> of the distribution's working files, where previously it was possible to
> create an archive from the floppy, and a floppy from the archive.  The
> result is the following clause in TRB's license file:
> 
>       Caveat Emptor
>      *******************************************************************
>      * This license file must be included with tomsrtbt whenever it is *
>      * redistributed.  If components are redistributed, the respective *
>      * portions must be included, that is, the GPL, LGPL, BSD, and the *
>      * programs they cover, must always be distributed together.  This *
>      * means it must certainly be a violation of license to distribute *
>      * the tomsrtbt floppy to anyone without including these licenses! *
>      * These licenses ARE NOT included on the floppy itself, it breaks *
>      * the license terms if you do not include it ALONG WITH the disk! *
>      * If you really want to be safe, distribute tomsrtbt as a double- *
>      * diskette set, with this file being the contents of diskette #2. *
>      *******************************************************************
> 
> TRB is hardly unique in this regard.  Various bootable media (Trinux,
> muLinux, LNX-BBC, the Linuxcare BBC, Knoppix, etc.) are both
> increasingly popular, and damned useful (I literally never leave home
> without at least two), and we'll likely see migration from floppies and
> CDs to memory sticks and DVDs in the next year or so.  For embedded
> systems (watches, PDAs, various devices) similar size constraints exist.  
> 
> Free software must be careful about thousand-cuts practices.  There are
> requests which seem reasonable in the single instance which become a
> prohibitive burden in aggregate.  Close-binding obligations (e.g.:  the
> obligation follows directly with the software, and can't be satisfied on
> secondary media or means) not directly related to software performance
> runs this risk.  Multiplied out 8,776 times (the number of packages
> listed in my Debian packages list today), they become a nightmare --
> that's 8,776 cuts.
> 
> Peace.
> 
> 

-- 
--------------------------------------------------------------------------
Michael Bauer        me at michaelbauer.com       http://www.michaelbauer.com

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