It's clear that (e.g.) libc accompanies (e.g.) /bin/ls in Debian: They
are both in main, and the package maintainer makes sure you get libc
when you get /bin/ls. If you also think that libc is a section of
(see section two) /bin/ls and so on, then the conclusion is clear:
You're in
In my opinion, Qt is not a section of KDE, it is not derived from the
KDE and it must be considered independent and separate from the KDE.
In other words: The KDE's usage of the GPL does not cause the GPL, and
its terms, to apply to Qt.
Indeed Qt is not part of the problem
But
If I say, do what you want with my code, and you incorporate it in a GPL
app, do you relicense my work? No, and you can't, because you're not the
Yes, you create a combined work bound by the GPL. And the GPL permits
components of a GPL'd item to be freer than GPL (by the GPL definition of
free)
files and libraries being linked together. Does that mean that you
think Debian should convert libc and so on from the LGPL to the GPL in
order to comply with the license of the GPL'd applications in main?
Arnt if you stuck to using facts you might be able to have a sensible
discussion
The
The GPL'ed apps require that the work as a whole must be distributable
under the terms of the GPL. Do you think that means that I have to
re-license the individual parts?
Will Debian remove Motif linked XEmacs from their ftp server?
According to several Debian developers Motif is not a
However, the license for that derived work (I'll call it A) claims
that the whole of A must be GPL'd. However, Qt is not part of A (the
GPL says section of). Qt provides services to A, and A depends on
those services: A very different thing.
Qt is part of the derived work. It is linked to
It's really a shame KDE chose the GPL. Many BSD people will tell you the
GPL is the most restrictive free software license there is. It's the only
widely used free license that prohibits use with a library like Qt under any
circumstances at all. No special exception for system libraries,
And by now Sun would no doubt be shipping a binary only KDE that forbid
you to redistribute it and contained fixes you couldnt get back off them
Ehm, the world hasn't gone to hell because not everything is GPL. Take
for instance companies using FreeBSD, such as Whistle and Best Internet
And lots of people haven't kicked stuff back. Why doesn't *BSD run on an
SGI Indy - its because the BSD license didnt force all the neat stuff
to be contributed back. And there are thousands of other examples like it.
I fail to see how this is all that much different from the GPL
perhaps
If I use libc, I don't think I am creating a libc. Unless I am, I'm not
deriving, I think. If I use libc, I simply use the services. Hence, libc
is a section of the thing I am making, and does not derive from it.
Your program derives from libc by being linked with it. This is precisely
why an
Alan: This is a perfect example of FUD!
No
SuSE has the biggest rate of growth of all Linux distributors in
the US.
And SuSE and Red Hat and all of them put together are not worth a US lawsuit
yet. Price yourself a US lawsuit then judge again.
Make them 5 times bigger and yes
Just threadening with sueing is simply an action of FUD.
I haven't threatened to sue anyone. You must have been listening to
Matthais foaming at the mouth too much.
Sorry for my harsh words. But it looks to me like some people are trying
to keep kde people from making even better free
I thought the purpose of this project (at least the FHS) is to create a
standard
of what the filesystem should look like, not necessarily what it currently
looks
like. Just because `Everyone is doing it' (tm) doesn't mean it's right.
Personally, I want Linux to be clean and elegant in its
but I haven't heard any technical reasons besides, Moving spool
directories is hard. When I and others have pointed out that moving
the spool directory isn't required; just a symlink, I have heard dead
silence. So the lack of technical discussion, but just a stony-silence
No! is rather
1. Interoperability with other systems.
10+ million Linux boxes use /var/spool/mail. Its also a spurious claim. All
existing tools assume linux uses /var/spool/mail. Other systems even sharing
via NFS dont get problems with this /var/spool usage
2. Disk space management.
We've proved between
But I don't think the FHS should be specifying the actual location of
the files at all. True, the FHS should not cause too much pain for the
Ok good we agree on this
The only thing that really matters is what pathnames applications can
count upon to work. Given that the rest of the world
I'll give you one solid reason, uniformity across unix platforms is a
must have if unix, especially free unices, are going to succesfully
If we are in marketing mode let me point out we are not Unix in the first
place and that C:\ is the standard
I don't see a connection between
Technical reasons for making the change;
a. Compatibility with the majority of existing unix systems.
Incompatibility with the majority of Linux systems. Incompatibility
with the majority of Linux packages.
b. See a. It can not be stressed enough. If FHS is ever to get OUT
of the
18 matches
Mail list logo
