[linux-elitists] RMS is at it again

Heather star@starshine.org
Fri Dec 1 23:01:32 PST 2000


> on Fri, Dec 01, 2000 at 03:11:41PM -0800, Heather (star@starshine.org) wrote:
> 
> > Read again - I suggest that they point to a debian-maintained copy AND 
> > refer to the FSF.  One further assumes that the reference to the copy
> > held at the FSF shouldn't be necessary if you *have* the local copy (as 
> > you should) ... but you could refer to both and compare them.
> 
> OK.
> 
> > > The issue isn't one of finding an appropriate license, it's accommodating
> > > the requirements of the GNU GPL.
> > 
> > Or discovering that too deep a hole is being dug regarding it 8(
> 
> ?

That the problem is a real problem, but lay undiscovered for long enough that
there is no easy way out.  Or the classic comment "when you discover you've
dug yourself a hole that's too deep... stop digging"

Thus the croggle-eyes emoticon
 
> Tantrum or otherwise, his reasoning and line are consistant.

Yes.  
 
> > >   1. Debian as a whole.  In which case, we're compliant.
> > >   2. An individual archive file.  In which case, we're not, and the
> > >      solution is to add a copy of the L/GPL explicitly to each .deb
> > >      governed by the L/GPL.
> > >   3. A set of files, not necessarily integrally combined.  In which
> > >      case, a social and procedural, but not technical, fix is possible.
> > >      In the event of automated downloads, the tools will ensure that
> > >      individuals have a copy of the L/GPL.  In the event of manual
> > >      downloads, the recipient is directed to download a copy of the the
> > >      L/GPL, but the Debian project can't be held accountable for this
> > >      noncompliance.
> >  
> > I can hope for 3, because then my suggestion of a clear (but short)
> > notice and a dependency on a package GPL-version-2 or
> > GPL-version-2plus, etc.  would be fine.  And easy to do in the small
> > scale, though a pain to do to every package til the pot's right...
> >  
> > > The problem isn't Debian CDs and live-system updates, it's individual
> > > .deb distributions.  Agreement on that?
> >  
> > I suppose this is why I am being most snippy about it - I'm directly in the
> > affected group.
> 
> Expand again:  You're in this group because:
> 
>   (a) You're downloading .debs over the net with apt-get

> If the first, I'd make the argument that you're pulling down componenets
> of a work within a framework that assures you've already got the
> license(s) on the system, and will get them for you if you don't.

Well, I am, but that's covered if they allow what debian are planning for.
 
>   (b) You're using individual .debs as part of other projects on
>       non-Debian distributions or installations?

> If the second, well, I hope my option (3) will stand.

possibly yes.  Part of the freedom I enjoy with Linux is taking parts from
whichever distros or source pools work (as long as their licenses like each
other) to end up with a more stable system.  So my SuSE workstation has a 
pure-source derived kernel, lynx-ssl and dependency related parts from .deb's,
and some parts from non-SuSE rpm's.  So at the very least my own personal
setups are a mixture.

    (c) As an avid installfester, I serve as an occasional distribution
        point for Debian, so something that affects the right way to 
        distribute Debian, is something I feel I should pay close attention
        to.

	And yes, if I 'fest for someone but the WORKING parts for a given 
	app are in another distro (or at another sources site), I want to 
	be able to use those parts.  So I hope that they don't make it hard 
	to do so. 

> > > IANAL, this is not legal advice.
> > 
> > As a curiosity: Anyone have a database somewhere of apps by license?
> 
> SourceForge does:
> 
>     http://sourceforge.net/softwaremap/trove_list.php?form_cat=13
> 
> ...drill down and you'll find that this is a software map browser by
> license category.

Hmm.  I'll probably read it a bit during LISA.
 
> I also assume that the vrms package has some way of determining that a
> package is in free or non-free.

Yes and no - it really asks the package system, which could be wrong.  Some
packages are so old that the guidelines have changed slightly too.  For 
instance, when involved with Tuxtops stuff, I felt compelled to actually 
*look* in the font packs (because many font artists are so prissy about
their licenses).  They certainly didn't have enough divisions - do you mean
"non-free" like "has a shareware fee, postcardware insistance, or other
strange How To Get A License thing" or "non-free" like "you scumbag money
grubbing corporate 'shareware library' types aren't allowed to resell this 
at all.  Only real human individual end users need apply."  The current
debian trees lump these together.  
 
> However, my experience in crawling through /usr/doc/*/copyright a few
> weeks back was that there is a strongly pronounced lack of consistancy
> about how project copyrights are reported.  Anything from a
> straightforward presentation to a detailed list of contact attempts with
> original authors and/or transcripts of conversations or email.
> 
> It would be useful to tie this data to the popularity test though....

Interesting, how would we graph that?

* Heather * The chief enemy of creativity is "good" sense -- Picasso



More information about the linux-elitists mailing list