On Mon, 2008-02-25 at 09:32 -0800, Russ Allbery wrote:
> I suppose that apt never updates itself unless you have something
> configured to do so (although does synaptic default to running aptitude
> update periodically?). But at least in theory Debian could track all
> sorts of interesting inform
On Mon, 2008-02-25 at 10:16 +0100, Giacomo A. Catenazzi wrote:
> Lars Wirzenius wrote:
> > On su, 2008-02-24 at 16:43 -0600, Raphael Geissert wrote:
> >> * The package/software SHOULD offer a way to disable the 'phoning home'
> >> code
> >> if it contains such kind of 'feature'.
> >
> > Speaking
On Sun, 2008-02-24 at 13:54 +, Ian Jackson wrote:
> I'm involved in sponsoring a proogram (meshlab, ITP #426581) where
> I've discovered that it phones home with statistical information about
> the files being used, and so forth. I'm working with upstream and
> with the prospective maintainer
On Sat, 2006-11-25 at 21:33 +0100, Mike Hommey wrote:
> > As I said, it is perfectly possible for a maintainer to write a script
> > which works on any shell and allows the user to pick at installation
> > time (heck, or even per-user!) which shell to use.
>
> How cool that would be to be asked 10
On Sat, 2006-11-25 at 11:31 +0100, Petter Reinholdtsen wrote:
> [Thomas Bushnell]
> > I'm interested in why we should care at all. Perl is a far bigger space
> > hog than bash.
>
> Debian Edu had to switch /bin/sh from bash to dash to get shutdown to
> umount /usr/ when we use libnss-ldap (bug #1
On Sat, 2006-11-25 at 09:51 +0200, Jari Aalto wrote:
> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
>
> > On Fri, 2006-11-24 at 23:55 +0200, Jari Aalto wrote:
> > > > Instead of focusing and hammering again and again on /bin/sh, why not
> > > >
On Fri, 2006-11-24 at 23:57 +0200, Jari Aalto wrote:
> And why do you think that? please take a look at the RES values.
I know you don't understand it, because you just appealed to the RSS
values.
If many processes are sharing text, they all get accounted with the size
of the resident text in the
On Fri, 2006-11-24 at 23:55 +0200, Jari Aalto wrote:
> > Instead of focusing and hammering again and again on /bin/sh, why not
> > instead ask maintainers to do #!/bin/dash?
>
> Because the correct is #!/bin/sh and not to be tied on particular shell.
I can't tell what you mean. There is nothing
On Fri, 2006-11-24 at 21:08 +0100, David Weinehall wrote:
> You can use whatever bashisms you like when you're working
> interactively, that won't hinder dash from executing shells on boot and
> elsewhere. Using bashisms in scripts does however cause a problem.
I think it's time to realize that "
On Thu, 2006-11-23 at 22:54 +0200, Jari Aalto wrote:
> David Weinehall <[EMAIL PROTECTED]> writes:
>
> > On Thu, Nov 23, 2006 at 07:09:49PM +0100, Steinar H. Gunderson wrote:
> >
> > Now the choice of 464kB or 4528kB on a desktop where you're actually
> > using the shell for interactive things is
On Thu, 2006-11-23 at 22:56 +0200, Jari Aalto wrote:
> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
>
> > On Thu, 2006-11-23 at 19:33 +0200, Jari Aalto wrote:
> > > I don't see perl used that much for maintainer scripts, or daemon
> > > scripts.
> &g
On Thu, 2006-11-23 at 20:46 +0100, David Weinehall wrote:
> Well, let's hope people don't use any of the non-SuSv3 features of cat
> in their shell scripts...
Why? Who cares?
This is some huge amount of work for some very little benefit.
Thomas
signature.asc
Description: This is a digitall
On Thu, 2006-11-23 at 20:07 +0100, David Weinehall wrote:
> On Thu, Nov 23, 2006 at 07:49:10PM +0100, Martijn van Oosterhout wrote:
> [snip]
> >
> > There's a difference between requiring maintainer scripts to say
> > /bin/bash if they need bash constructs and rewriting existing scripts
> > to wor
On Thu, 2006-11-23 at 13:50 +0200, Jari Aalto wrote:
> I'm not suggesting to remove features from essential, but I think the
> policy should take the shells as special case, because the
> sh-compliances (SusV/POSIX) itself is a matter of its own. There are
> no viable alternative implementation of
On Thu, 2006-11-23 at 19:33 +0200, Jari Aalto wrote:
> I don't see perl used that much for maintainer scripts, or daemon
> scripts.
Exactly the *point*. So why isn't this your target?
> Some prefer bash and see no problems. Others consider bash's memory
> consumption a problem when compared to o
On Thu, 2006-11-23 at 13:43 +0200, Jari Aalto wrote:
>
> Bash is not essential for running Debian. It is possible to run old
> PCs and old laptops completely free of bash. The point here is not the
> disk consumption, but the reduced memory constrainsts. When scripts
> are written with only "sh" i
On Thu, 2006-11-23 at 01:15 +0200, Jari Aalto wrote:
>
> I would drop that "special" case and always require explicit
> requirement for the shell. It's more clear to see which packages
> "need" bash to make them work. someone may then provide a patch to
> "make bash go away". I suggest removing th
On Fri, 2006-11-17 at 18:15 -0500, Clint Adams wrote:
> A builtin ls might be a good idea for disaster recovery shells,
> though zsh-static does not have it. posh is not intended to be
> such a shell, nor to be particularly useful interactively.
> Since I cannot think of a legitimate reason for an
On Fri, 2006-11-17 at 17:57 -0500, Clint Adams wrote:
> > Forgive me if I am wrong, but I was under the impression that posh was
> > created for the purpose of providing a shell which supports a minimum
> > of functionality required by policy against which scripts could be
>
> Not exactly a minimu
On Fri, 2006-11-17 at 08:23 +0100, Andreas Barth wrote:
> * Thomas Bushnell BSG ([EMAIL PROTECTED]) [061117 00:48]:
> > On Thu, 2006-11-16 at 20:51 +0100, Mike Hommey wrote:
> > > > I can live with a list of features. But then, geez, don't you think the
> >
On Thu, 2006-11-16 at 21:16 -0600, Manoj Srivastava wrote:
> Your scripts shouuld really just use whatever POSIX mandates
> ls has. Just like it should use whatever POSIX mandates test has.
Ok, so this means something like the following would be good for policy:
"When POSIX specifies a c
> > I know what Posix.2 says, but it does not define the term "POSIX
> > compatible shell". Can you tell me what that means? I really am
> > genuinely stymied. I think some people have an incorrect
> > understanding of what POSIX actually says in this regard, but I'm
> > not sure.
>
>
On Thu, 2006-11-16 at 19:17 -0600, Manoj Srivastava wrote:
>
> Debian Technical policy is applicable to Debian systems. A
> POSIX shell, in this context, lives on a Debian OS. I the shell
> overrides debconf in an incompatible manner, that would break things,
> and would be a grave bu
On Thu, 2006-11-16 at 19:23 -0600, Manoj Srivastava wrote:
> The issue, apparently, is that under policy, some shell can
> come up with all kinds of shadowing of things like debconf. I
> suggest that if brought before the TC, the TC shall decide that is a
> bug in the shell. Policy is
On Thu, 2006-11-16 at 19:17 -0600, Manoj Srivastava wrote:
>
> In this case, your scripts are meant tot be runnable using a
> POSIX (+ a few features) compatible shell on a Debian system. It is
> understood that the shells in question do not have grave bugs.
I know what Posix.2 says,
On Thu, 2006-11-16 at 20:51 +0100, Mike Hommey wrote:
> > I can live with a list of features. But then, geez, don't you think the
> > actual list should be given? Saying "works on a Posix compatible shell"
> > restricts way too much (you can't use "debconf" then) unless we wink and
>
> Could you
On Thu, 2006-11-16 at 09:44 +0100, Andreas Barth wrote:
> * Thomas Bushnell BSG ([EMAIL PROTECTED]) [061116 09:35]:
> > On Thu, 2006-11-16 at 09:30 +0100, Andreas Barth wrote:
> > > * [EMAIL PROTECTED] ([EMAIL PROTECTED]) [061115 18:31]:
> > > > 1. /bin/sh can b
On Thu, 2006-11-16 at 09:30 +0100, Andreas Barth wrote:
> * [EMAIL PROTECTED] ([EMAIL PROTECTED]) [061115 18:31]:
> > 1. /bin/sh can be a symbolic link to any shell.
>
> I don't think we allow to any shell - but there are more possibilities
> than just /bin/bash.
So can we just decide what the po
On Wed, 2006-11-15 at 22:50 -0600, Manoj Srivastava wrote:
> I would rather get away from this wording totally.
> ,
> | "Shell scripts specifying /bin/sh as interpreter must only use POSIX
> | features, additionally, they may assume that echo -n . Also,
> | they may use test -a/
On Wed, 2006-11-15 at 18:13 +0100, [EMAIL PROTECTED] wrote:
> 1. /bin/sh can be a symbolic link to any shell.
This can't be right. For example, it obviously can't be a link
to /bin/csh.
So since it can be a symbolic link to *some* shells and not others,
telling maintainers "you know which ones w
On Tue, 2006-11-14 at 22:15 -0800, Russ Allbery wrote:
> The problem sparking this thread and my initial work on a Policy patch is
> not a problem caused by shells with builtins; it is, in fact, not a
> technical problem at all in the sense that no user has had their system
> broken by the use of
On Tue, 2006-11-14 at 18:59 -0800, Russ Allbery wrote:
> I think this would be a great deal of work for little useful benefit.
Why? Surely it would be useful to know what the differences are between
various shells. The statement "Posix-compatible" was apparently
intended by the authors of that p
On Tue, 2006-11-14 at 18:38 -0800, Russ Allbery wrote:
> > "Two different packages must not install programs with different
> > functionality but with the same filenames."
>
> > There does not seem to be any reason to exempt shell builtins from this
> > requirement.
>
> I think there are obvious
> Not in my experience, but I haven't tested for them in particular. On my
> system, I see one maintainer script using test -o, none using test -a, and
> none using test ().
>
> I currently see no need to require that test () be supported.
I do. Debian test is provided by the coreutils package
On Wed, 2006-11-15 at 02:20 +0100, David Weinehall wrote:
> > and failed
> > miserably.
>
> And you belong to the group of people that caused it to fail...
I refused to stop using test -a in my packages as well, and refused to
declare #!/bin/bash.
Here's why.
test -a is not a "bashism".
It's a
On Mon, 2006-11-06 at 23:51 +0100, Marco d'Itri wrote:
> On Nov 06, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
> > Russ's patch is no good, at least, it does not address the problems I
> > have raised in the past.
> It's still better than
Russ's patch is no good, at least, it does not address the problems I
have raised in the past.
A Posix shell is allowed to have a builtin for ANY command without
restriction, and as long as the builtin has the behavior specified by
Posix for that command, it is a "Posix compatible shell."
For exa
Stephen Gran <[EMAIL PROTECTED]> writes:
> This one time, at band camp, Thomas Bushnell BSG said:
>> Wouter Verhelst <[EMAIL PROTECTED]> writes:
>>
>> > Sbuild explicitely, by design, only looks at build-depends. So in order
>> > for build-depends to
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> Sbuild explicitely, by design, only looks at build-depends. So in order
> for build-depends to be useful at this time if you want a package to
> build, you need to list mostly everything in build-depends right now
> anyway.
Isn't it sbuild's job to co
Manoj Srivastava <[EMAIL PROTECTED] (va, manoj)> writes:
> Seems pretty unambiguous to me, but then, I am biased ;-).
> My take is that Postfix, sendmail, reportbug, and most other programs
> are doing the right thing, and Exim4 needs to be fixed. Received
> lines never contain an user
Anthony Towns writes:
> On Sun, Nov 10, 2002 at 11:02:51PM -0800, Thomas Bushnell, BSG wrote:
> > Still, I'm loath to create extra rules that we don't need. In
> > general, yes, *every* file should be readable, and it's appropriate to
> > file bug r
Anthony Towns writes:
> If you want to share nethack bones files, you put them in /var/games/nethack,
> or similar, then share it.
The problem with this strategy is that it requires administrators to
keep track of which packages can share which directories, and this is
in general hard to figure
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> There is no rule that /usr can always be safely mounted read-only in
> FHS or the GNU Coding Standards. If it works for you, great, but by
> no means would I advise relying on it.
Blech, I was wrong here, for which I apologize. The
Matthew Palmer <[EMAIL PROTECTED]> writes:
> While not being a nethack afficionado, I admin for people who are. Aren't
> bones levels variable, and hence should not be placed in /usr anyway?
> Certainly, I know that bones levels are created on the nethack machine, and
> that machine's /usr is mo
Anthony Towns writes:
> On Sun, Nov 10, 2002 at 11:26:31AM -0800, Thomas Bushnell, BSG wrote:
> > > /usr/share is not appropriate for that, as it is the OS's playground
> > > (and I can't see any use for the OS installing secrets there).
> > > For sit
Robert Bihlmeyer <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > This is incorrect. /usr/share is intended to be shared between
> > cooperating systems, but cooperating systems' root users might well
> > have secrets t
Matthew Swift <[EMAIL PROTECTED]> writes:
> Because files in /usr/share are expected to be shared, they should all
> be world-readable.
This is incorrect. /usr/share is intended to be shared between
cooperating systems, but cooperating systems' root users might well
have secrets that they want
Anthony Towns writes:
> On Tue, Sep 24, 2002 at 09:05:12PM -0700, Thomas Bushnell, BSG wrote:
> > I didn't say that it was the best way to go about things; even Manoj
> > didn't say that.
>
> So you're saying bugs should be filed to encourage packages to
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Policy is not going to be broken by either you having a hissy
> fit, or Thomas proposing silly changes.
I proposed the change because I (mistakenly) though that AJ was
expressing commonly accepted process.
Anthony Towns writes:
> Really? What is it? I only saw comments that amount to "I interpret
> policy this way" and "other things do it this way", neither of which is
> a response to my original request for "someone to give a good reason why
> randomly deleting config files of installed packages i
Anthony Towns writes:
> The. Packages. Are. Not. Broken. It's that simple. How many times have you
> found base-passwd recreating /etc/passwd and /etc/group a nuisance? Never?
> Funny that.
>
> Why the fuck do we have to have a debate about this?
We don't; any behavior here is fine with me, as
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> severity 162120 wishlist
> thanks
>
> justification: this is not a flaw in the policy, at best, this may be
> a proposal to change policy to codifying, in my opinion, a less
> desirable behaviour, and should be treated like any other proposal
>
Peter Palfrader <[EMAIL PROTECTED]> writes:
> Which may not always be the Right Thing. cf. config files in .d
> directories like cron.d, ip-up.d or similar.
Sure; my wording is quite conservative, merely pointing out current
practice more carefully. I have no particular reason to think current
p
Package: debian-policy
Version: 3.5.6.1
Severity: important
Section 11.7.3 says that changes to configuration files are supposed to be
preserved on upgrade. This is not commonly done, however, if the change
consists in deleting the file entirely. Existing practice is probably fine,
but the polic
Joey Hess <[EMAIL PROTECTED]> writes:
> You really don't want to know, but in brief it runs many different
> processes that need to be very isolated from each other and have very
> different permissions given to them. I allocate the uids from the pool
> on the fly and use it for a kind of process
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> You might want to add a warning that this needs to be tested. Some
> packages, like glibc or the Hurd, can not be built without optimization
> (for example because of inline functions not being inlined).
It should be pointed out that this fact repre
Michael Stone <[EMAIL PROTECTED]> writes:
> On Mon, May 20, 2002 at 12:15:39PM -0700, Thomas Bushnell, BSG wrote:
> > Steve Langasek <[EMAIL PROTECTED]> writes:
> > > Sorry. I mean to say, this is effectively what has been requested on
> > > behalf of the
Steve Langasek <[EMAIL PROTECTED]> writes:
> Sorry. I mean to say, this is effectively what has been requested on
> behalf of the Hurd port.
No, it has not been requested on behalf of the Hurd port.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contac
Steve Langasek <[EMAIL PROTECTED]> writes:
> However, the Hurd port is asking for Policy to be
> *relaxed* [...]
NO, the Debian GNU/Hurd porting team has *NOT* asked for any such
relaxation.
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Conta
Steve Langasek <[EMAIL PROTECTED]> writes:
> The problem I have is with the attitude that Policy can be ignored
> for the Hurd port because it's a different architecture, or that
> Policy should be amended to allow libexec as a Hurd-specific
> extension.
Nobody is suggesting that Policy be igno
Daniel Ruoso <[EMAIL PROTECTED]> writes:
> I want to publish the software in different stages (unstable, testing,
> frozen and stable, just like debian itself), because I will have
> machines testing each distribution.
>
> Finally, the question is...
> What's the better strategy to publish packag
[EMAIL PROTECTED] writes:
> 1. Software in non-us was not developed inside the US and should
> not be restricted to 'export' into other countries.
Lots of stuff in non-us was developed in the US.
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> The trend is to hide the differences between storage devices, not to
> make it visible to the user.
This is true, but I'd say it differently. More than saying "trend", I
think better to just say "it's right".
Richard Braakman <[EMAIL PROTECTED]> writes:
> On Fri, Dec 14, 2001 at 09:31:58PM -0800, Thomas Bushnell, BSG wrote:
> > I prefer a proportional limit for two reasons. First, a fixed limit
> > invites the abuse of splitting a big invariant thing into a bunch of
>
I think I would be willing to sign on to Branden's latest proposal (as
referred to in the headers of this message), with two provisos. (I
would also be willing to sign on to Anthony's debian-doc proposal, if
the FSF agrees that it satisfies the licenses on its manuals.)
First, I would like to re
Branden Robinson <[EMAIL PROTECTED]> writes:
> I believe Debian should have a standard a priori the GNU Emacs Manual
> (for example), and not reason backwards on the assumption that
> everything that is in main must belong there. People find DFSG
> violations in main regularly. The intent of my
Branden Robinson <[EMAIL PROTECTED]> writes:
> I intend to. I'm sorry to offend you by asking people more familiar
> with the GNU Emacs Manual to assist.
What bugs me is that you've now issued *TWO* proposals without
ascertaining their effect first. How many more times are you going to
make pro
Branden Robinson <[EMAIL PROTECTED]> writes:
> The arbitrary definition of "software" that you seek undermines your
> objections to my arbitrary threshold on the quantity of invariant text.
I understand what "software" means, and I guess it's quite sad that
you don't. Oh well. I don't claim the
Branden Robinson <[EMAIL PROTECTED]> writes:
> I don't agree with that interpretation. "Software" can be a very
> slippery term. I recall a friend of mine from Purdue who asserted that
> the only real software is processor microcode -- everything else is just
> data files. To get around these a
Branden Robinson <[EMAIL PROTECTED]> writes:
> If it's not *Software* then either,
>
> 1) We must treat it as such, or;
> 2) We have no mandate to deal with it at all.
We don't need a mandate. The US Congress is (theoretically) limited
to the enumerated powers given in the US Constitution, but
Branden Robinson <[EMAIL PROTECTED]> writes:
> On Sat, Dec 01, 2001 at 07:05:10PM -0800, Thomas Bushnell, BSG wrote:
> > I thought there was general agreement that a proportional limit was
> > better than a simple number.
>
> Maybe this is how you feel, but I
Branden Robinson <[EMAIL PROTECTED]> writes:
> Whatever. If fiat is legitimate, that is. I'm not sure what your point
> is. A rose is a rose is a rose. DFSG 3 contains absolutely no
> implication of the existence of any exception to its terms.
You steadfastly want to skip that little word "so
I thought there was general agreement that a proportional limit was
better than a simple number. One disadvantage to a simple per-package
limit is that you can defeat it by splitting something up into more
packages. A proportional limit seems more sensible to me.
Also, I think it should be a co
[EMAIL PROTECTED] (Brian Mays) writes:
> I've learned that too. They also don't read the documentation in
> /usr/share/doc/.
And really, how could they? My *laptop* has 884 packages installed.
If I try "wc /usr/share/doc/*/README.Debian", that alone is:
4449 24692 168612 total
To expect
Branden Robinson <[EMAIL PROTECTED]> writes:
> 1) There is more than one implementation of libGL available in Debian;
> bumping one to standard would require choosing one.
Can the different implementations we have now co-exist?
I'm not sure whether this should be a policy bit (probably not) or a
developer's ref manual thing. And since I don't know how the docs
have been reorganized or what the plan is, I don't want to say. So
it's a proposal for whichever doc it most belongs in, but I think it
belongs somewhere.
I've
Anton Zinoviev <[EMAIL PROTECTED]> writes:
> For example what display manager we will choose: gdm, kdm, wdm or xdm?
> Maybe gdm, because it provides session menu, but it looks to me a little
> buggy. I'm giving this only as an example. Surely there will be
> conflicts.
What does it mean that gd
Adrian Bunk <[EMAIL PROTECTED]> writes:
> I had some time ago a discussion with Paul Slootman in #85936 about the
> removal of old changelog entries. He did remove at one point all changelog
> entries except the latest on (and Raphael Bossek did recently the same in
> some of his packages). Paul s
Josip Rodin <[EMAIL PROTECTED]> writes:
> A solution would be some sort of an essential virtual package that
> editors would provide, but that's not viable, either. So we're
> stuck. :)
Why is that not viable?
Do the following:
* Make all the different editor packages provide the virtual packag
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> A statement that parts of the packagning manualk are now part
> of the policy manual would be correct; and perhaps the description
> can mention that.
Absolutely! Indeed, my own confusion here is a sign that the
descriptions should include m
Package: debian-policy
Version: 3.5.3.0
Severity: normal
The debian-policy manual now includes what used to be in the separate
packaging-manual package, but the description remains unchanged. I was
momentarily confused, and would appreciate it if a suitable note were
in the package description so
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> So, what is the provenance of this CURDIR variable? Has it
> been blessed by POSIX? indeed not. However, I see that both $PWD and
> the pwd utility are sanctioned by POSIX; so for maximal portability
> scripts should *NOT* use CURDIR, the sh
Peter Palfrader <[EMAIL PROTECTED]> writes:
> On Sun, 01 Apr 2001, Bas Zoetekouw wrote:
>
> > Hi Taral!
> >
> > You wrote:
> >
> > > It should most certainly be debian/rulz, not rulez.
> >
> > Why not make it d3b1an/rulz, then?
>
> d3b14n/ru|z seems like a good choice.
No, no. d3b!4n/ru|z i
John Galt <[EMAIL PROTECTED]> writes:
> First of all, what newbie is going to want to run a mailserver? Running a
> mailserver is usually a job for a medium-level sysadmin: certainly not
> a job to add for someone trying to get comfortable with a system. Where's
> the equivalent task-POP?
Um, n
Seth Arnold <[EMAIL PROTECTED]> writes:
> * Raul Miller <[EMAIL PROTECTED]> [001205 20:37]:
> > Fortunately, things aren't very severe right now. And, certainly,
> > I think that if we could pull a solution together by the time that
> > Woody freezes, that would indicate good faith.
>
> It migh
Seth Arnold <[EMAIL PROTECTED]> writes:
> * Thomas Bushnell, BSG <[EMAIL PROTECTED]> [001205 18:49]:
> > For all I know, you're Theo de Raadt, and you're deliberately trying
> > to drive a wedge between the FSF and Debian out of hatred for
> > everyt
John Galt <[EMAIL PROTECTED]> writes:
> Okay, "you". No sweat off my nose if you wish to exclude me.
Well, I ask because again your motives for posting are unclear.
For all I know, you're Theo de Raadt, and you're deliberately trying
to drive a wedge between the FSF and Debian out of hatred for
John Galt <[EMAIL PROTECTED]> writes:
> Can we really expect others to follow the DFSG when we do so
> only when convenient?
"we"?
John Galt <[EMAIL PROTECTED]> writes:
> On Sun, 3 Dec 2000, John Lines wrote:
>
> > By being the first, and most frequently mentions Free Software license the
> > GPL
>
> Survey says...Bzzzt! The GPL is a latecomer in the free software arena.
Um, the Copyleft predates the BSD free license. T
John Galt <[EMAIL PROTECTED]> writes:
> pkg_add -r gcc on a freebsd box will pull down a binary of gcc without a
> copy of the GPL.
Perhaps I'm confused, but I thought the normal procedure was the
"ports" mechanism, which pulls down source and compiles it locally.
If it's actually more like the w
John Galt <[EMAIL PROTECTED]> writes:
> Acvtually, I was thinking trademarks: Kleenex for the prime example. The
> big issue is collateral estoppel. If there is collateral estoppel in
> copyright law, failure to prosecute infringement may disallow you from
> ever prosecuting the same type of inf
John Galt <[EMAIL PROTECTED]> writes:
> Is it? What does Debian have to do with EvilCorp that Red Hat or
> Slackware doesn't? Why is Debian getting singled out? Why haven't I seen
> the same thing on the FreeBSD lists? It looks as if RMS's goal it to make
> Debian his own private whipping boys
John Galt <[EMAIL PROTECTED]> writes:
> RMS is meeting with lawyers. You brought that tidbit up. What are we
> supposed to think: he's there because he likes their office decor?
He sends email to law professors that he respects, who are experts in
intellectual property law, who are personal frie
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> >>"Thomas" == Thomas Bushnell, BSG <[EMAIL PROTECTED]> writes:
>
> Thomas> Let's not drive the rhetoric to a feverish pitch, accusing people of
> Thomas> being unreasonable or unthinking. Conside
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Show me where we have advertized any individual deb for
> download on your non Debian system, as opposed to piecewise upgrade
> of you preexisting Debian machine.
I'm not sure exactly what RMS has in mind. Most of the obvious cases
certainly
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Are you, perchance, advocating we keep several (potentially
> several thousand) copies of the GPL on every Debian machine out there
> on the off chance that the end user (despite pointers in the
> copyright file) is unable to get a copy of th
John Galt <[EMAIL PROTECTED]> writes:
> See Wollensak v. Reiher, 115 U.S. 96, 99 (1885). See also USC Title 17,
> section 507
>
> * (b) Civil Actions. - No civil action shall be maintained under the
>provisions of this title unless it is commenced within three years
>after the cl
John Galt <[EMAIL PROTECTED]> writes:
> www.ll.georgetown.edu/Fed-Ct/Circuit/fed/opinions/97-1425.html
>
> Reasonable man and estoppel are linked, and a choice quote:
>
> A delay of more than six years raises a presumption that it is
>unreasonable, inexcusable, and prejudicial.
>
> _Wanlas
John Galt <[EMAIL PROTECTED]> writes:
> > I know a Randroid might think all lawyers are the same, but amazingly,
> > they are not.
>
> Ahhh! Out of logical refutation, you fall to the last refuge of the
> incompetent: personal attacks.
Um, your the one who launched personal attacks against peop
John Galt <[EMAIL PROTECTED]> writes:
> First of all, knowledge is not that of the actors, but of the "reasonable
> man". The .deb archive standard contents were decided on when Debian was
> still a FSF project, and they certainly haven't been modified to remove
> the license after the separation
1 - 100 of 151 matches
Mail list logo
