On Fri, Aug 18, 2006 at 01:24:06PM -0500, Steve Greenland wrote:
No sign of what it actually did, no sign of whether the answer was
yes or no. Yes, there is some stuff in there. But not always enough.
Sometimes it spits out what the compile command was, and the code used,
and sometimes it
On Friday 18 August 2006 06:56, Matthew R. Dempsky wrote:
On Thu, Aug 17, 2006 at 08:48:24PM +0300, George Danchev wrote:
So are some widespread programming languages. If you blindly follow bad
examples and bad styles you can dynamite yourself happily without even
noticing, but that does
I demand that Russ Allbery may or may not have written...
Steve Greenland [EMAIL PROTECTED] writes:
And, for example, all of a sudden (autoconf 2.5, I think) every/many
(newly generated or regenerated) configure script starting checking for
C++ compilers, Fortran compilers, etc. etc. etc.
On 17-Aug-06, 23:33 (CDT), Peter Samuelson [EMAIL PROTECTED] wrote:
[Steve Greenland]
By autoconf related problems I mean things like it suddenly
deciding it's running a cross compiler, or that stdlib.h is
missing. A lot of this kind of stuff could be improved by simply
SHOWING ME THE
Steve Greenland [EMAIL PROTECTED] writes:
On 16-Aug-06, 04:00 (CDT), Gabor Gombas [EMAIL PROTECTED] wrote:
On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote:
And guess what? System tests are actually more reliable, especially
when the user tells you what the system is. You
On Tue, Aug 15, 2006 at 02:42:09AM -0500, Peter Samuelson wrote:
[Michael Poole]
On top of the default automake behavior being horribly broken, does
that make usual revision control practices horribly broken?
It really bothers me to hear people claim as a best practice that you
should
On Wed, Aug 16, 2006 at 07:11:19PM -0500, Steve Greenland wrote:
So you chose to use a function not reliably available. Sounds like bad
planning to me.
More than a year ago the plan was that we'll support Debian Sarge only.
Then a couple of weeks ago our project partner said they'll be using
On 16-Aug-06, 19:23 (CDT), Matthew Garrett [EMAIL PROTECTED] wrote:
Yeah, wanting to use functionality when it's available is always a
dreadful idea. Far better to reimplement it locally in order to ensure
that we have more copies of it to fix should there ever be any sort of
security
On 16-Aug-06, 20:23 (CDT), Miles Bader [EMAIL PROTECTED] wrote:
The main problem with your argument is that you seem to be looking at
poorly written programs that use autoconf, and jumping to the conclusion
that autoconf is the reason for the poor programming -- it's not. Bad
programmers
Steve Greenland [EMAIL PROTECTED] wrote:
On 16-Aug-06, 19:23 (CDT), Matthew Garrett [EMAIL PROTECTED] wrote:
Yeah, wanting to use functionality when it's available is always a
dreadful idea. Far better to reimplement it locally in order to ensure
that we have more copies of it to fix should
On 16-Aug-06, 20:49 (CDT), Peter Samuelson [EMAIL PROTECTED] wrote:
As for useless autoconf tests - have you looked at how autoconf is
used? You pick the tests you think you need. It's not like the system
forces you to use a certain range of obsolete baseline tests. A huge
number of test
On 17-Aug-06, 09:06 (CDT), Gabor Gombas [EMAIL PROTECTED] wrote:
On the other hand, sw with custom build systems were always a pain:
usually they had no idea how to build a shared lib on AIX,
Neither does libtool. But I can usually easily change the Makefile to
fix that problem; libtool is an
Steve Greenland [EMAIL PROTECTED] writes:
And, for example, all of a sudden (autoconf 2.5, I think) every/many
(newly generated or regenerated) configure script starting checking for
C++ compilers, Fortran compilers, etc. etc. etc. even for pure C
projects.
This is a libtool bug.
--
Russ
On Thursday 17 August 2006 19:02, Steve Greenland wrote:
On 16-Aug-06, 20:49 (CDT), Peter Samuelson [EMAIL PROTECTED] wrote:
As for useless autoconf tests - have you looked at how autoconf is
used? You pick the tests you think you need. It's not like the system
forces you to use a certain
[Wouter Verhelst]
It has nothing to do with being afraid to, but everything with not
needing to.
There's lots of things we don't _need_ to do but we do anyway, as a
matter of quality of implementation. I believe that building a package
from source is something we should do as well, if only to
On Thu, Aug 17, 2006 at 08:48:24PM +0300, George Danchev wrote:
So are some widespread programming languages. If you blindly follow bad
examples and bad styles you can dynamite yourself happily without even
noticing, but that does not make them disused or abandoned (on the contrary
some of
[Steve Greenland]
By autoconf related problems I mean things like it suddenly
deciding it's running a cross compiler, or that stdlib.h is
missing. A lot of this kind of stuff could be improved by simply
SHOWING ME THE FSCKING ERROR MESSAGES, rather than just checking the
return code and
as a backend.
We definitely need a functional mkisofs in Debian.
mkisofs is certainly part of cdrtools. But not of cdrecord.
Nothing in mkisofs has weird conditions on the GPL, unlike other parts
of cdrtools (libscg, cdrecord.c), so it should be straightforward to
make a free fork
On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote:
And guess what? System tests are actually more reliable, especially
when the user tells you what the system is. You can simply flip to
compiling foo_linux.c or foo_solaris.c and go on your way.
This will never work. Real life
On 16-Aug-06, 04:00 (CDT), Gabor Gombas [EMAIL PROTECTED] wrote:
On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote:
And guess what? System tests are actually more reliable, especially
when the user tells you what the system is. You can simply flip to
compiling foo_linux.c
Steve Greenland [EMAIL PROTECTED] wrote:
On 16-Aug-06, 04:00 (CDT), Gabor Gombas [EMAIL PROTECTED] wrote:
This will never work. Real life example from a couple of weeks ago: I
wrote a program that was running happily on Sarge, then somebody wanted
to build it on RHEL and failed because the
Steve Greenland [EMAIL PROTECTED] writes:
You figure out where the incompatability points are, and you write
functions to mask them. Of course the functions themselves have
#ifdefs (or some other way of controlling compilation), but you get it
*out* of your main code base.
Gee sounds like a
[Steve Greenland]
My experience is that the ones whose build instructions say edit the
makefile to pick your platform and compiler compile and work, and
when they don't, they're easy to fix. The ones that use autoconf tend
to blow up on non-Linux[1], in ways that are hard to debug and damn
[Michael Poole]
On top of the default automake behavior being horribly broken, does
that make usual revision control practices horribly broken?
It really bothers me to hear people claim as a best practice that you
should never recompile configure.ac or Makefile.am except under
controlled
* Nathanael Nerode:
In reality, as user A, I switched to using cdrdao for making serious audio
CDs and CD-RWs, and for burning disks from .iso files: this uses
Schilling's scsilib, but not the rest of cdrecord.
What about mkisofs?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Florian Weimer [EMAIL PROTECTED] writes:
* Nathanael Nerode:
In reality, as user A, I switched to using cdrdao for making serious audio
CDs and CD-RWs, and for burning disks from .iso files: this uses
Schilling's scsilib, but not the rest of cdrecord.
What about mkisofs?
So far JS has not
need a functional mkisofs in Debian.
mkisofs is certainly part of cdrtools. But not of cdrecord.
Nothing in mkisofs has weird conditions on the GPL, unlike other parts
of cdrtools (libscg, cdrecord.c), so it should be straightforward to
make a free fork. And it was originally written by Eric
with
Debian versions of cdrtools and use self-compiled unmodified
originalsources.
This is of course a lie.or why don't you like to prove it?
You are of course lying...
Neither upstream or debian packaging k3b includes unmodified
originalsources of cdrtools, nor give instructions
On Mon, Aug 14, 2006 at 09:40:41PM -0400, Michael Poole wrote:
Wouter Verhelst writes:
In my experience, this is greatly exacerbated and perhaps even
primarily due to older versions of autotools encouraging or requiring
behavior that later versions of autotools declare to be broken.
* Steve Greenland [EMAIL PROTECTED] [060814 23:30]:
The *real* problem with the whole autotools disaster is that it promotes
a braindead idea of how to achieve portability: a #ifdef branch for
every different system (or library version, or whatever), strewn
throughout the entire codebase. Real
On 14-Aug-06, 17:32 (CDT), Hendrik Sattler [EMAIL PROTECTED] wrote:
Am Montag 14 August 2006 23:27 schrieb Steve Greenland:
The *real* problem with the whole autotools disaster is that it promotes
a braindead idea of how to achieve portability: a #ifdef branch for
every different system
On 14-Aug-06, 23:35 (CDT), Nathanael Nerode [EMAIL PROTECTED] wrote:
Steve Greenland wrote:
Um, this is the exact opposite of the philosophy promoted by Autoconf since
at least version 2.0. Feature tests, not system tests. I can't speak to
other autotools.
Doesn't matter (feature tests was
On Tue, Aug 15, 2006 at 02:11:21PM -0500, Steve Greenland wrote:
No, you don't #ifdef all the users, you write multiple versions of a a
generic function that hides the differences, and compile the appropriate
one. Read the reference I gave.
Sure, you *could* do this with autoconf driving the
Florian Weimer [EMAIL PROTECTED] writes:
* Thomas Bushnell:
As a countermeasure, the FSF tries to extend copyright to interfaces,
so that you do create a derivative work merely by programming to a
specific interface of a library written by someone else, without
copying their code. I'm not
Steve Greenland [EMAIL PROTECTED] writes:
And guess what? System tests are actually more reliable, especially
when the user tells you what the system is. You can simply flip to
compiling foo_linux.c or foo_solaris.c and go on your way.
If you only port to 2 or 3 different very well-defined
* Thomas Bushnell:
As a countermeasure, the FSF tries to extend copyright to interfaces,
so that you do create a derivative work merely by programming to a
specific interface of a library written by someone else, without
copying their code. I'm not sure if this is such a bright idea.
On 8/14/06, Florian Weimer [EMAIL PROTECTED] wrote:
And to some extent, the FSF must claim that it's not possible to
escape the GPL with a second implementation (so that programs linking
to readline must still be GPLed, even though you could use libedit as
a mostly-transparent replacement, for
Hubert Chan [EMAIL PROTECTED] wrote:
The GPL (section 3) does restrict distributions of binaries (object
code or executable form, to use the words of the GPL, to be more
accurate, since the GPL only uses the term binary once, and only to
refer to a completely different issue) and states that
emulation and
install your programs as suid-root.
You again prove that you are uninformed.
If you did really work as Debian cdrtools maintainer, you would have read the
bug reports (in special Debian bug #374685):
/*--*/
I
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Do you really believe that you are able to deflect from the main problem:
The original sources do not have such bugs and many Debian users that
did write bug reports against the Debian version of cdrtools did already
switch to a self
- With Linux 2.6.x, it is impossible to run cdrecord without
root privs.
Do not believe single persons who claim otherwise as Linux-2.6.x
filters away random SCSI commands when cdrecord does not have
root-privs and as cdrecord heavily depends on
against the Debian version of cdrtools did already
switch to a self compiled original source in order to get a working
cdrecord.
Why don't you read my reply?
I rather burn my own CDs/DVDs and see for myself if the program works.
Your source: total failure.
Debian source: works
On Fri, Aug 11, 2006 at 10:57:45PM +0200, Joerg Schilling wrote:
Joerg Jaspert [EMAIL PROTECTED] wrote:
You should look at the video I pointed you at. You just accused me of
being a liar. If i would have your low level I would now do the same you
I did look at this video: it verifies what
On 12-Aug-06, 09:09 (CDT), Jon Dowland [EMAIL PROTECTED] wrote:
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always the autotools while there's this nice
cmake?
I've never used cmake myself, so I can't speak for how nice
it is, but autotools (for all its problems) is
Hello,
On Sat, 12.08.2006 at 20:40:37 +0200, Florian Weimer [EMAIL PROTECTED] wrote:
As a countermeasure, the FSF tries to extend copyright to interfaces,
so that you do create a derivative work merely by programming to a
specific interface of a library written by someone else, without
On Mon, Aug 14, 2006 at 04:09:33PM +0200, Joerg Schilling wrote:
This is of course a lie.or why don't you like to prove it:
http://cdrecord.berlios.de/old/private/problems.html
Come back to reallity, the k3b maintainers did already give up with
Debian versions of cdrtools and use self
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Greenland wrote:
On 12-Aug-06, 09:09 (CDT), Jon Dowland [EMAIL PROTECTED] wrote:
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always the autotools while there's this nice
cmake?
I've never used cmake myself, so I can't
On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
On 12-Aug-06, 09:09 (CDT), Jon Dowland [EMAIL PROTECTED] wrote:
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always the autotools while there's this nice
cmake?
I've never used cmake myself, so I can't
Wouter Verhelst writes:
On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
On 12-Aug-06, 09:09 (CDT), Jon Dowland [EMAIL PROTECTED] wrote:
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always the autotools while there's this nice
cmake?
I've never
On Mon, Aug 14, 2006 at 09:52:01PM +0200, Wouter Verhelst wrote:
On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
On 12-Aug-06, 09:09 (CDT), Jon Dowland [EMAIL PROTECTED] wrote:
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always the autotools while
On 14-Aug-06, 15:59 (CDT), Michael Poole [EMAIL PROTECTED] wrote:
Wouter Verhelst writes:
In the case of autotools, the fact is that usually it's configure.ac or
Makefile.am being horribly broken, rather than the autotools.
In my experience, this is greatly exacerbated and perhaps even
Wouter Verhelst wrote:
On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
On 12-Aug-06, 09:09 (CDT), Jon Dowland [EMAIL PROTECTED] wrote:
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always the autotools while there's this nice
cmake?
I've never used
Steve Greenland [EMAIL PROTECTED] writes:
The *real* problem with the whole autotools disaster is that it promotes
a braindead idea of how to achieve portability: a #ifdef branch for
every different system (or library version, or whatever), strewn
throughout the entire codebase. Real
Am Montag 14 August 2006 23:27 schrieb Steve Greenland:
On 14-Aug-06, 15:59 (CDT), Michael Poole [EMAIL PROTECTED] wrote:
Wouter Verhelst writes:
In the case of autotools, the fact is that usually it's configure.ac or
Makefile.am being horribly broken, rather than the autotools.
In my
Am Montag 14 August 2006 23:10 schrieb Bernd Schubert:
Wouter Verhelst wrote:
If used properly, autotools usually do their job; and pretty well, too.
Just have a look here http://lwn.net/Articles/188693
KDE never used the autotools properly (I'd rather call it hacking into it),
probably
give up with
Debian versions of cdrtools and use self-compiled unmodified
originalsources.
This is of course a lie.or why don't you like to prove it?
I'm not trying to pick on you, Riku, but please, let's stop. It's clear
that on the one side, there's the JS point of view:
Debian only
On Mon, Aug 14, 2006 at 04:59:24PM -0400, Michael Poole wrote:
Wouter Verhelst writes:
On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
On 12-Aug-06, 09:09 (CDT), Jon Dowland [EMAIL PROTECTED] wrote:
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always
Steve Greenland [EMAIL PROTECTED] writes:
The *real* problem with the whole autotools disaster is that it promotes
a braindead idea of how to achieve portability: a #ifdef branch for
every different system (or library version, or whatever), strewn
throughout the entire codebase. Real
On Mon, Aug 14, 2006 at 03:53:40PM -0700, Russ Allbery wrote:
Steve Greenland [EMAIL PROTECTED] writes:
The *real* problem with the whole autotools disaster is that it promotes
a braindead idea of how to achieve portability: a #ifdef branch for
every different system (or library version,
Wouter Verhelst writes:
In my experience, this is greatly exacerbated and perhaps even
primarily due to older versions of autotools encouraging or requiring
behavior that later versions of autotools declare to be broken.
[...]
The situation is not helped when these mutually incompatible
Eduard Bloch wrote:
Then let's see what a user of your software would do, in a
not-so-uncommon use case:
User A wants to burn a CD-ROM. She gets cdrtools,
In reality, as user A, I switched to using cdrdao for making serious audio
CDs and CD-RWs, and for burning disks from .iso files
Hendrik Sattler wrote:
You mean the difference between manpages-posix-dev (in non-free) and
manpages-dev (in main)? The first is not proposed by Debian (I still don't
get why anone would want to change a standards document as not changing it
is the whole purpose of its existence.)
In order to
Steve Greenland wrote:
On 14-Aug-06, 15:59 (CDT), Michael Poole [EMAIL PROTECTED] wrote:
Wouter Verhelst writes:
In the case of autotools, the fact is that usually it's configure.ac or
Makefile.am being horribly broken, rather than the autotools.
Oh yeah. Most people don't know how to
Adam Borowski [EMAIL PROTECTED] writes:
Autotools do require you to do things the way they want, indeed. And
every single autotool uses a different obscure language. Some
consistency would be good -- but, I challenge you: write something
that works better. There's a lot of deficiencies in
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Joerg Schilling [EMAIL PROTECTED] writes:
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Why do you insist on programming bugs into cdrtools that linux
distributions have to fix by patching?
You should inform yourself about reality
. And don't tell me I am lying, our BTS is full of them.
I did never claim that cdrecord is free of bugs, but it works out of the box
on Linux while the version Debian publishes does not because Debian introduced
bugs into cdrtools that are not present in the original.
Then let's see what a user
Joerg Schilling [EMAIL PROTECTED] writes:
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Joerg Schilling [EMAIL PROTECTED] writes:
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Why do you insist on programming bugs into cdrtools that linux
distributions have to fix by patching?
You
On Sun, Aug 13, 2006 at 12:28:15PM +0200, Joerg Schilling wrote:
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Joerg Schilling [EMAIL PROTECTED] writes:
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Why do you insist on programming bugs into cdrtools that linux
distributions have
Daniel Schepler [EMAIL PROTECTED] writes:
According to the GPL, section 0:
The act of running the Program is not restricted...
And since dynamic linking is done at the time the program is run, this would
appear to me to be what applies. In particular, it appears to me that you
could
On Thu, Aug 10, 2006 at 11:25:11PM +0200, Joerg Schilling wrote:
1)Throw out Eduard Bloch.
rotflmao.
--
Fun will now commence
-- Seven Of Nine, Ashes to Ashes, stardate 53679.4
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
The fork-team can look at http://www.arklinux.org/projects/dvdrtools, a
100% free fork of cdrtools.
The SVN is inactive from 6 month, but the autotool-ization is already
done and it can write on DVDs, and probably is better than starting
another fork.
Btw, why always the autotools while
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always the autotools while there's this nice
cmake?
I've never used cmake myself, so I can't speak for how nice
it is, but autotools (for all its problems) is very
widespread.
The cmake build system might even get accepted by
Alle Saturday 12 August 2006 16:09, Jon Dowland ha scritto:
At 1155391794 past the epoch, Bernd Schubert wrote:
Btw, why always the autotools while there's this nice
cmake?
I've never used cmake myself, so I can't speak for how nice
it is, but autotools (for all its problems) is very
Jean Parpaillon [EMAIL PROTECTED] wrote:
Beside the licensing issues, why do you care so much patched version of
your software to be distributed with big WARNINGS, a different name and
tutti quanti ?
Why do Linux distributions insist in applying patches that introduce bugs
into cdrtools
* Daniel Schepler:
And since dynamic linking is done at the time the program is run, this would
appear to me to be what applies. In particular, it appears to me that you
could satisfy the GPL and still dynamically link against a non-free library,
and distribute both, by invoking the mere
users' code be portable?
You are a funny person.
You like to talk avout portabilitiy but the patches that Debian aplies to
cdrtools are only from two categories:
- Patches that introduce bugs that cannot be found in the original
software
- Patches that make the Debian
Florian Weimer [EMAIL PROTECTED] writes:
* Daniel Schepler:
And since dynamic linking is done at the time the program is run,
this would appear to me to be what applies. In particular, it
appears to me that you could satisfy the GPL and still dynamically
link against a non-free library,
patches that introduce bugs
into cdrtools?
Jörg
Why do you insist on programming bugs into cdrtools that linux
distributions have to fix by patching?
Why do you to typos? Why do you stumble sometimes or trip over
something?
Do you see how stupid your question is? Nobody intentionaly introduces
it to become PDF::API2::Debian, how will our users' code be portable?
You are a funny person.
You like to talk avout portabilitiy but the patches that Debian aplies to
cdrtools are only from two categories:
- Patches that introduce bugs that cannot be found in the original
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Why do you insist on programming bugs into cdrtools that linux
distributions have to fix by patching?
You should inform yourself about reality
The original sources do not have such bugs and many Debian users that
did write bug reports against
is not saying that there are no legal issues.
- Eben Moglen tells you that what I do in cdrtools is OK:
They the FSF and Moglen have only be in fear that people
could interpret the GPL in a wrong way and for this reason
added the OS exception, but the GPL does allow to link
Joerg Schilling [EMAIL PROTECTED] writes:
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Why do you insist on programming bugs into cdrtools that linux
distributions have to fix by patching?
You should inform yourself about reality
Are you willing to put money where your mouth
On Sat, Aug 12, 2006 at 09:48:55PM +0200, Goswin von Brederlow wrote:
Joerg Schilling [EMAIL PROTECTED] writes:
Please try to read, understand and answere the question asked in a
mail. Hint: The question wasn't about cdrtools patches.
Please try to take off-topic threads to appropriate mailing
that you cant work with him (and he with you).
2)Update to a recent cdrtools source, do not hide interesting
new features from Debian users and (this may be even more important to
Linux users) workarounds for recent Linux kernel
self-incompatibilities.
You combine CDDL
On 10743 March 1977, Joerg Jaspert wrote:
[1]
http://debian-meetings.debian.net/pub/debian-meetings/2006/debconf6/theora-small/2006-05-14/tower/OpenSolaris_Java_and_Debian-Simon_Phipps__Alvaro_Lopez_Ortega.ogg
[2]
a new maintainer with the following properties:
I know that you cant work with him (and he with you).
I am willing and able to cooperate with any reasonable person.
Eduard Bloch has absolutely no clue and on the other side implicitely claims
in his arrogant habbit that he knows more about cdrtools
side implicitely claims
in his arrogant habbit that he knows more about cdrtools than I do. This
makes
it impussoble to cooperate with him.
You know that this is Rufschädigung übelster Art?
Claiming that Sun did make the CDDL incompatible with the GPL is a deliberate
lie.
You should
reassign 377109 ftp.debian.org
retitle 377109 RM: cdrtools -- RoM: non-free, license problems
thanks
Hi guys,
ok well, as JS stays with an interpretation of CDDL and GPL that the
whole world does not follow (all wrong, of course :) ), lets go and fix
this. The sane way is to remove cdrtools from
not make the CDDL incompatible by intention to the GPL
- The only thing that prevents Linux to use the DTrace code in
Linux is the different threading model
- Eben Moglen tells you that what I do in cdrtools is OK:
They the FSF and Moglen have only be in fear that people
Joerg Jaspert [EMAIL PROTECTED] wrote:
Eduard Bloch has absolutely no clue and on the other side implicitely
claims
in his arrogant habbit that he knows more about cdrtools than I do. This
makes
it impussoble to cooperate with him.
You know that this is Rufschädigung übelster Art
On Friday 11 August 2006 14:48 pm, Joerg Schilling wrote:
The FSF GPL FAQ e.g. incorrectly claims:
Linking ABC statically or dynamically with other modules is making a
combined work based on ABC. Thus, the terms and conditions of the GNU
General Public License cover the
Alle Friday 11 August 2006 22:51, Joerg Jaspert ha scritto:
reassign 377109 ftp.debian.org
retitle 377109 RM: cdrtools -- RoM: non-free, license problems
thanks
Hi guys,
ok well, as JS stays with an interpretation of CDDL and GPL that the
whole world does not follow (all wrong, of course
Jorg Schilling wrote:
[...]
Sorry, but I do not believe people that put things into a GPL FAQ that
are obviously wrong. Let me give a single example to avoid wasting too
much time:
The FSF GPL FAQ e.g. incorrectly claims:
Linking ABC statically or dynamically with other modules is
Hubert Chan [EMAIL PROTECTED] wrote:
No, but the combined work (A+B) (i.e. a binary produced by linking
module A with module B) is a work based on A, and hence (A+B) must be
distributable under the terms of the GPL.
Distributing the sources of A with the sources of B may be fine, but
Daniel Schepler [EMAIL PROTECTED] writes:
Let's put aside for the moment that the FAQ is not meant to be a legal
document as opposed to the GPL itself, and that the FAQ is not saying B would
be a derived work of A, but rather that the combination would be...
I have a general question about
Joerg Jaspert [EMAIL PROTECTED] writes:
reassign 377109 ftp.debian.org
retitle 377109 RM: cdrtools -- RoM: non-free, license problems
thanks
Hi guys,
ok well, as JS stays with an interpretation of CDDL and GPL that the
whole world does not follow (all wrong, of course :) ), lets go
You did write:
...
I have a general question about how the GPL is construed to cover the case of
dynamic linking. According to the GPL, section 0:
...
I am sory to see that you did remove me from the Cc: list
you are the first person at Debian who starts to think the right
way...
If you
On Fri, 2006-08-11 at 23:55 +0200, Joerg Schilling wrote:
Linking a GPLd program against a non-GPLd library does not make the library a
derived work of the GPLd program.
but it does mean you may distribute the resulting binary only if you make the
library
source available under the GPL, and if
Hi,
On Fri, Aug 11, 2006 at 07:04:51PM -0400, Edward Allcutt wrote:
On Fri, 2006-08-11 at 23:55 +0200, Joerg Schilling wrote:
Your discussion is off-topic for debian-devel, please kindly take it
elsewhere.
Thanks,
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
On Fri, 11 Aug 2006 23:25:52 +0200, Joerg Schilling [EMAIL PROTECTED] said:
Hubert Chan [EMAIL PROTECTED] wrote:
No, but the combined work (A+B) (i.e. a binary produced by linking
module A with module B) is a work based on A, and hence (A+B) must
be distributable under the terms of the GPL.
1 - 100 of 266 matches
Mail list logo
