Regards,
August
A vanilla ISO filesystem doesn't have case-sensitive filenames, so by
default they all get converted to lower-case.
Try enabling Rock Ridge and Joliet extensions when running mkisofs.
That should get you case-sensitive filenames on most popular OSes.
--
Grant Edwards grant.b.edwards Yow! Everybody is going
at somewhere!! It's probably
gmail.com a garage sale or a disaster
Movie!!
Thanks for the info Grant. However, when I add Joliet extensions the
file names containing å, ä or ö are not displayed correctly - or do the
ISO image have to be mounted with a special UTF-8 option?
Anyway, do you know what the recommended mkisofs options are? I don't
need backward compatibility (with old Windows systems) only forward
compatibility so I will be able to access the data in the future.
Of course, an alternative would be to burn a tarball of the files onto a
disc, thus eliminating the file system issues alltogether.
/August
Presumably the '?' characters aren't really what's supposed to be
there? I don't have UTF support enabled on this system, so I'm
_guessing_ that your problem is with UTF (non-ascii) filenames?
> Anyway, do you know what the recommended mkisofs options are? I don't
> need backward compatibility (with old Windows systems) only forward
> compatibility so I will be able to access the data in the future.
>
> Of course, an alternative would be to burn a tarball of the files onto a
> disc, thus eliminating the file system issues alltogether.
I always use "-r -J", but I only use ASCII filenames.
Presuming you've read the mkisofs man page where it talks about
different UTF charsets, the next thing I'd do is ask Google:
http://www.google.com/search?q=mkisofs+utf+filenames
--
Grant Edwards grant.b.edwards Yow! UH-OH!! We're out
at of AUTOMOBILE PARTS and
gmail.com RUBBER GOODS!
Never had any trouble with it maintaining filenames. Now if you are then
saving to a MS dos system will cause trouble.
> than it should be. I created an iso image with the option `-iso-level 4'
> and everything looks fine when I open the image with the archive
> manager. However, after having burnt the image to a DVD all filenames
> have been converted to lower case. Does anyone know the reason for this
> and/or how to preserve character case? I'm using mkisofs version 2.01 by
> the way.
Soulds like the ancient version included with wodim. YOu could try the
real mkisofs (cdrecord.berlios.de)
But I suspect you are doing something else wrong. Why not tell us
exactly what all the options you use are.
I know you don't want to hear this, but I'll say it anyway: don't allow such
characters in your filenames. I'm talking from years of maintaining and
archiving project data for a major European engineering company: you'll
regret not imposing simple, standard rules on names. I'm not talking DOS 8.3
limits, but simple rules such as:
- don't count on upper/lower case, never allow files only different in case
- don't allow accents, symbols and - might as well - spaces
(we did allow '.' '-' '_')
- limit the length of dir/names to a reasonable length (we chose max 32)
(is ok for Win, Lin, Mac before OS/x, CD/DVD, FTP/SMB transfers, etc...)
> Anyway, do you know what the recommended mkisofs options are? I don't
> need backward compatibility (with old Windows systems) only forward
> compatibility so I will be able to access the data in the future.
I'm really disgusted with Windows lately, and love Linux.
But given the presenct userbase volume, don't you think in the future we're
more likely to get our hands on old Win compatible tools/systems than other?
Go with that, or find a common ground.
Look at the hardware equivalent question: which will you get your hands on
more easily: Iomega ZIP/JAZZ drives, Exabyte tapes, DAT, qic80 tapes, Blue
Ray, ... or a CD/DVD reader? (and yes, I did put Blue Ray in that list).
> Of course, an alternative would be to burn a tarball of the files onto a
> disc, thus eliminating the file system issues alltogether.
Yup, valid solution. But a bit less ease of use, and you still need to
beware of what you put in the name of that tarball.
PS: Don't assume I'm talking from the perspective of someone who doesn't
need accents. My name has an accent in it. I'm working with people who speak
NL, FR, EN, ES, DE, DK, PT, HU, etc... They all want spaces and most would
like accents. Just say no... :-)
--
When in doubt, use brute force.
-- Ken Thompson
Yes, this is all good advice which I currently follow myself. However,
the files I want to archive are from a time when I didn't know better
and I don't want to change the names of existing files and directories.
> I'm really disgusted with Windows lately, and love Linux.
Same here (since 2004).
/August
I use only the POSIX portable character set:
<http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_275>
--
Chris F.A. Johnson, <http://cfajohnson.com>
Author:
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
I do basically the same thing, but it's good to know there's a public
standard. I'll follow it and name it in the future.
Spaces and tabs and newlines in filenames SUCK. And they aren't
necessary.
Sid
>- don't count on upper/lower case, never allow files only different
> in case
>- don't allow accents, symbols and - might as well - spaces
> (we did allow '.' '-' '_')
>- limit the length of dir/names to a reasonable length (we chose
> max 32) (is ok for Win, Lin, Mac before OS/x, CD/DVD, FTP/SMB
> transfers, etc...)
These are good rules, although I'm a bit more liberal when it comes
to spaces (on an "at your own risk" basis - GUIs are usually OK,
it's people who use command-line interfaces and don't know about
quoting who usually get themselves into trouble).
>> Anyway, do you know what the recommended mkisofs options are? I don't
>> need backward compatibility (with old Windows systems) only forward
>> compatibility so I will be able to access the data in the future.
>
> I'm really disgusted with Windows lately, and love Linux.
Lately? I can tell horror stories about Microsoft file systems
going all the way back to the earliest versions of MS-DOS.
For a present-day one, try googling for "Windows file system
tunneling" - but only if you have a strong stomach.
> But given the presenct userbase volume, don't you think in the
> future we're more likely to get our hands on old Win compatible
> tools/systems than other? Go with that, or find a common ground.
We must always keep in mind Postel's Law: "Be conservative in what
you do, be liberal in what you accept from others."
Oh, and my mkisofs parameters are -r -J -joliet-long - if I'm working
in an environment where really long file names are acceptable, I can
burn CDs/DVDs with names that even exceed Windows' 103-character limit.
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Backquotes are even worse ;)
Correct, the characters I referred to are the last three in the Swedish
alphabet (http://en.wikipedia.org/wiki/Swedish_alphabet). Each of these
characters are replaced by two Latin-1 characters.
>> Anyway, do you know what the recommended mkisofs options are? I don't
>> need backward compatibility (with old Windows systems) only forward
>> compatibility so I will be able to access the data in the future.
>>
>> Of course, an alternative would be to burn a tarball of the files onto a
>> disc, thus eliminating the file system issues alltogether.
>
> I always use "-r -J", but I only use ASCII filenames.
I just found that mkisofs is just a link to genisoimage (v1.1.10) on my
system which is Ubuntu 10.04. As far as I know genisoimage should be
able to handle Unicode file names correctly.
/August
Actually I believe the answer is no. It is an ancient version of mkisofs
which has been rebranded (due to copyright issues) because there is a
totally childish battle between Debian and Schilling. Try getting the
real mkisofs and see if it works better.
Now when I run mkisfs (genisoimage) with the options `-iso-level 4 -J
-r' it seems to work. After my previous attempt I looked at the ISO
image with the archive manager in Ubuntu but now it's evident that it
doesn't handle Unicode characters correctly. The mounted image and the
burned DVD looks all right in both Ubuntu and OS X.
Thanks everyone for your suggestions.
Regards,
August
Well, when I tried just recently it seems to have worked (see my last post).
/August
> Now when I run mkisfs (genisoimage) with the options `-iso-level 4 -J
> -r' it seems to work. After my previous attempt I looked at the ISO
> image with the archive manager in Ubuntu but now it's evident that it
> doesn't handle Unicode characters correctly.
Unicode should be encoded as UTF-8. mkisofs also supports the -U option, to
ensure that the filename bytes are used as is, without any attempt at
translation. So if your filenames are UTF-8-encoded, they should go straight
into the disc image byte-for-byte, and come back the same way.
> I know you don't want to hear this, but I'll say it anyway: don't allow
> such characters in your filenames. I'm talking from years of maintaining
> and archiving project data for a major European engineering company:
> you'll regret not imposing simple, standard rules on names.
The big problem, as long as you’re looking at interchange between POSIXish
systems, is deciding on a consistent on-disk encoding for your name strings.
I assume that your “major European” company is based in Western Europe, and
like lots of Western Europeans, they would have been using ISO-8859-1 before
Unicode came along (and probably still are). And then they set up the first
branch in Central or Eastern Europe, which use different flavours of
ISO-8859, and find that their accented characters suddenly don’t make sense
to each other. Or a Japanese office using Shift-JIS, and find that info
turns into total gibberish on the round trip.
Stick to UTF-8 for the on-disk format, and you can avoid this problem.
> ... because there is a totally childish battle between Debian and
> Schilling.
I’ve never heard of Debian doing anything “childish”. Particularly when
other distros were finally goaded into having to dump Schilling in a similar
way <http://lwn.net/Articles/199061/>.
There was childishness from both sides:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377109
--keith
--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
> On 2010-11-11, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand>
> wrote:
>
>> In message <slrnidopjh...@wormhole.physics.ubc.ca>, unruh wrote:
>>
>>> ... because there is a totally childish battle between Debian and
>>> Schilling.
>>
>> I’ve never heard of Debian doing anything “childish”.
>
> There was childishness from both sides:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377109
Quote from the above:
In cdrtools 2.01.01a03 license of several makefiles have been changed to
a custom version of CDDL, which is a non-GPL-compatible license. These
makefiles are used to build GPL-licensed binaries, which is a violation
of paragraph 3 of the GPL:
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the
terms of Sections 1 and 2 above provided that you also do one of
the following:
a) Accompany it with the complete corresponding machine-readable
source code, WHICH MUST BE DISTRIBUTED UNDER THE TERMS OF
SECTIONS 1 AND 2 ABOVE on a medium customarily used for
software interchange;
... and:
For an executable work, complete source code means all the source
code for all modules it contains, plus any associated interface
definition files, PLUS THE SCRIPTS USED TO CONTROL COMPILATION AND
INSTALLATION OF THE EXECUTABLE.
... (emphasis mine). As a result, the package is non-distributable.
Seems clear enough to me. What exactly is supposed to be “childish” about
that?
[snip]
> Seems clear enough to me. What exactly is supposed to be ???childish??? about
> that?
Did you miss the backbiting (by both sides) through the email thread
that's part of the bug? (Please note that I didn't say the bug report
itself was childish!)
It has been childish all along. It started with Schilling selling a
proprietary version which was capable of DVD writing, and various people
then adding dvd writing the free version (so far things went fine). Then
Schilling made his dvd version free (but rereleased the whole thing
under CDDL rather than GPL for a variety ofreasons.) This then allowed
Soem Debian people to jump onto a high horse and ride away from their
users over a religious issue. Schilling was annoyed. The personalitities
of the comabants then ensured that noone would b ack up an inch,
screaming imprications across the bodies of thier users at each other. I
have spent some time on this issue and believe me, both sides are
extremely childish. It reminds me of the screaming at each other that
have accompanied so many of the religious splits in the past-- with
people being harmed over doctrinal differences completely invisible to
anyone not immersed in the "faith".
Note that your article basically says "Debian is on one side, most of
the distros are wait and see".
On the issue of the "legality" of the licenses, I am afraid I agree with
Schilling. The Debianites have taken a psoition that is vitually the
same as that of SCO in their battle with Linux over the definiton of a
"derived work" under copyright law. And as with religious zealots
through the ages, they refuse to even consider that their interpretation of
scripture could be anything but divinely ordained using vituperation and
exile as their answer to any argument. At the same time, as
with most heretics, Schilling is abrasive and stubborn.
In the meantime users suffer.
Case closed. Here in verse 35 of the holy book, the prophet says to
us...
And not the least inkling of any relalisation that the interpretation
could differ from the holy one.
The GPL is a license under colpyright law. As such it is bound by that.
The GPL is trying, badly, to define what "derived work" means.
Unfortunately that is a term of law, not of fiat, and as such must be
interpreted under law, not personal preference.
SCO in thier battle with Linux tried to claim that they could define
"derived work" as they wished, and in a manner quite similar to the one
you are advocating.
>
>
> The GPL is trying, badly, to define what "derived work" means.
Where, in the part being discussed in that bug report, did the word
“derived” come in?
> Note that your article basically says "Debian is on one side, most of
> the distros are wait and see".
Ummm ... that was in 2006. Guess what has happened since then...
Under law, the GPL lices cannot control anything that the law does not
allow. The GPL gets its force from copyright law, and gets its power to
control other things like the linking you are refering to from the
concept of "derived work" under copyright law. Without the force of
copyright law, all of the GPL is so much blather and has no force at
all. The GPL in its discussion about other works is attempting to define
what it means by a derived work. Unfortunately, it does so badly and
almost certainly overreaches itself.
Note by the way that GPL3 is far more incompatible with GPL2 than CDDL
ever was. Has Debian ceased distributing any works licensed under GPL3?
> On 2010-11-12, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand>
> wrote:
>
>> In message <slrnidps74...@wormhole.physics.ubc.ca>, unruh wrote:
>>
>>> The GPL is trying, badly, to define what "derived work" means.
>>
>> Where, in the part being discussed in that bug report, did the word
>> “derived” come in?
>
> Under law, the GPL lices cannot control anything that the law does not
> allow. The GPL gets its force from copyright law, and gets its power to
> control other things like the linking you are refering to from the
> concept of "derived work" under copyright law.
Where, in the part being discussed in that bug report, did the word
“derived” come in?
True, but what the hell, might as well try to convince a few of them to
better themselves. :-)
>> I'm really disgusted with Windows lately, and love Linux.
>
> Lately? I can tell horror stories about Microsoft file systems
> going all the way back to the earliest versions of MS-DOS.
> For a present-day one, try googling for "Windows file system
> tunneling" - but only if you have a strong stomach.
Been there, done that. First use was DOS 2.40, on a PC-XT.
But even if DOS was limited, it was also - in a way - cohently so.
Ever since Win2K the MS attitude of "We'll accept anything, even if we don't
support it" is gettings worse with every generation.
The number of people that create full file names longer than 255 chars
(accepted) and then find themselves unable to access/change/delete then (not
suppoerted) ...
You're right about it beeing the western Europe. But we work with several
eastern-europe countries, too. That's also why we avaided accents likethe
plague.
> Stick to UTF-8 for the on-disk format, and you can avoid this problem.
We can only control our own formats. If we receive files from other
people/organisations we can't rely on anything. They may go for UTF-8, but
have applictions that don't fully respect it and continue using other
formats. Maybe they use several codings mixed, and another one for the
storage/transmission. Mostly they don't know what their applications and
systems use (and neighter do we, in some cases). So limiting ourselves to
the limits described - and asking them to do so too - mostly works.
We used a script to 'clean' the names. The names would typically be compared
to a table of accepted chars, and a table of defined replacements. The chars
not found are signalled, so the replacement table can be completed.
This happens automagically in case you upgrade to a recent cdrtools/mkisofs
version, e.g. the latest 30.1a01 from:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
mkisofs added support for UTF-8 based locales in August 2006, but you are using
a more than 6 year old version of mkisofs.
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) J�rg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
>> Of course, an alternative would be to burn a tarball of the files onto a
>> disc, thus eliminating the file system issues alltogether.
>
>I always use "-r -J", but I only use ASCII filenames.
>
>Presuming you've read the mkisofs man page where it talks about
>different UTF charsets, the next thing I'd do is ask Google:
>
> http://www.google.com/search?q=mkisofs+utf+filenames
Be careful with the results from this search. There are many people giving
wrong advise.
Mkisofs added correctly working support for UTF-8 based locales in August 2006
but there is also a buggy mkisofs fork called "genisoimage" that claims to
include UTF-8 support but this fork does not support UTF-8 in reality.
>I just found that mkisofs is just a link to genisoimage (v1.1.10) on my
>system which is Ubuntu 10.04. As far as I know genisoimage should be
>able to handle Unicode file names correctly.
Ubuntu is based on Debian and a Debian packetizer did ask me in May 2004 to
add a "patch to support UTF-8 in mkisofs" to the official code.
I checked this patch and it turned out that the code in question was full of
bugs. Only half of the places in the mkisofs code that need to be changed have
been touched by the patch and the rest of the code created _many_ compiler
warnings (unfortunately not with GCC). These warnings mostly have been a
result from static structure initializations that initialized structure
members with values that have been intended for other structure members. As a
result I did not accept the patch and asked the person from Debian to fix the
bugs that are indicated by compiler warnings (including the list of warnings
from the Sun Studio Compiler) and asked him to enhance the code to cover
_all_ cases that need UTF-8 specific treatment.
Instead of working on the code, Debian started a social attack against the
cdrtools project and 2.5 years later a fork based on the code from 2004 was
launched. The program called "genisoimage" still uses the unfixed and buggy
code from May 2004. If you like to get working support, please use recent
original software from:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
Mr. Corbet is well known for frequently writing unproven claims in his
articles. You should not believe everything you read from him.....
Yes, there was a license change in cdrtools, but this license change was a
reaction on a social attack against the cdrtools project run by Debian.
The social attack started in May 2004, long time before the license was
changed.
This claim about "GPL compatibility" is completely wrong.
The book "Die GPL kommentiert und erklärt" (published in March 2005)
explicitely mentions that there is of course no such problem. See page 85 of
the book. Note that this book was written by FSF-friendly lawyers!
Please have a look at the explanation
http://cdrecord.berlios.de/private/dvd-source-why.html
on why the first DVD-supporting cdrecord from early 1998 could not be made
OpenSource.
BTW: The social attacks from Debian are not related to licensing. They are the
childish answer to the fact that a buggy patch from a Debian person from May
2004 has not been integrated into the official sources. This person later
created the fairy tale of a license conflict in order to deflect from the
reason for the conflict he created.
See http://www.osscc.net/en/gpl.html for background information from various
international lawyers that include plenty of evidence on how the GPL is in
conflict with the Copyright law.
> In article <ibi1j3$218$2...@lust.ihug.co.nz>,
> Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:
>>In message <lfduq7x...@goaway.wombat.san-francisco.ca.us>, Keith Keller
>>wrote:
>>
>>> On 2010-11-11, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand>
>>> wrote:
>>>
>>>> In message <slrnidopjh...@wormhole.physics.ubc.ca>, unruh wrote:
>>>>
>>>>> ... because there is a totally childish battle between Debian and
>>>>> Schilling.
>>>>
>>>> I’ve never heard of Debian doing anything “childish”.
>>>
>>> There was childishness from both sides:
>>>
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377109
>>
>>Quote from the above:
>>
>> In cdrtools 2.01.01a03 license of several makefiles have been changed to
>> a custom version of CDDL, which is a non-GPL-compatible license. These
>> makefiles are used to build GPL-licensed binaries, which is a violation
>> of paragraph 3 of the GPL:
>
> This claim about "GPL compatibility" is completely wrong.
Not according to the FSF
> The book "Die GPL kommentiert und erkl�rt" (published in March 2005)
> explicitely mentions that there is of course no such problem. See page 85 of
> the book.
Wow. What good "reference".
> Note that this book was written by FSF-friendly lawyers!
Certainly. Those you mention so often? And who exist just the same way as that
famous SCO-briefcase with the "proof of linux copying SCO code"
--
Ignorance is a condition. Stupidity is a way of life.
> Mr. Corbet is well known for frequently writing unproven claims in his
> articles.
Cite?
> See http://www.osscc.net/en/gpl.html for background information from
> various international lawyers that include plenty of evidence on how the
> GPL is in conflict with the Copyright law.
Where does it say “the GPL is in conflict with the Copyright law”?
If fact, the GPL has been upheld by course in various
jurisdictions. That is what determines its validity, not the
opinions of lawyers or other commmentators, no matter how logical
and well-written those opinions are.
--
Chris F.A. Johnson, <http://cfajohnson.com>
Author:
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Die GPL kommentiert und erklärt
Institut für Rechtsfragen der Freien und Open Source Software
1. Auflage März 2005
ISBN 3-89721-389-3
Seiten 208
EUR22.00, SFR35.90
Seit April 2006 steht das Buch unter der Creative Commons in dieser
Version.
And thebook is even free online
http://www.oreilly.de/german/freebooks/gplger/
Sheesh.
Die GPL kommentiert und erklärt
> If fact, the GPL has been upheld by course in various
> jurisdictions. That is what determines its validity, not the
> opinions of lawyers or other commmentators, no matter how logical
> and well-written those opinions are.
You repeat a claim that is frequently seen from people who avoid to read the
substanciation for the related judgements.....
I know of no single judgement that confirms the validity of the GPL.
In contrary, in special the judgements from Germany where Harald Welte
(gplviolations.org) was the plaintiff make it very obvious that the judges
intentionally did only look at a single claim from the GPL. This was done in
order not to compromise the ability to finally have a judgement pro Harald
Welte based on the Copyright law.
Lawyers become judges. Judges read the opinions of lawyers. Yes, the
courts are the final arbitrators, but the courts are not divorced from
other opinion. There are aspects of the GPl that are clearly valid
licenses. There are aspects that are more dubious as I understand it.
Just because the courts uphold one aspect in one case does not make the
GPL as a whole necessarily valid.
An d to make matters worse, copyright law is a bit of a mess, with
undefined terms running amok through it, forcing the courts to make up
the law on their own. In particular, "derived works" is a bit of a mess,
as I understand it (which is the aspect of the law under which the
"viral" nature of GPL obtains its force.)
There are aspects of the the arguments that some of the GPL supporters
make that sound a lot like the arguments that SCO made in its attacks on
Linux, in their treatment of derived works.
Unfortunately or otherwise, one must take heed of the opinions of
lawyers and otehr commentators since almost no cases never go to court,
but you may well need to act despite not knowing how a court would
decide.
> I know of no single judgement that confirms the validity of the GPL.
<http://gpl-violations.org/news/20060922-dlink-judgement_frankfurt.html>
<http://gpl-violations.org/news/20050414-fortinet-injunction.html>
The GPL is a whole bunch of claims and conditions. Ruling on some (eg
source code publication) does not imply that the all are valid. Both of
these cases seem to be irrelevant regarding Schilling/Debian battle,
which has to do with linking, not with souce code publication. The claim
on Debian's behalf is that one cannot link GPL code with CDDL code.
Schilling disputes this. None of these cases address this issue. This
issue swims in the murky waters of "derived works". When is work A
considered a derived work of work B? Since copyright in work B has no
legal hold on independent work A unless work A can be considered a
"derived work" of A, the question is in how far does linking work A to
work B make the result a "derived work" of work B as far as copyright
law is concerned.
So if you have some court cases on this issue, that would be useful.
>
The GPL is a whole bunch of claims and conditions. Ruling on some (eg
The GPL is a whole bunch of claims and conditions. Ruling on some (eg
> On 2010-11-27, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand>
> wrote:
>
>> In message <8lc741...@mid.dfncis.de>, Joerg Schilling wrote:
>>
>>> I know of no single judgement that confirms the validity of the GPL.
>>
>><http://gpl-violations.org/news/20060922-dlink-judgement_frankfurt.html>
>><http://gpl-violations.org/news/20050414-fortinet-injunction.html>
>
> The GPL is a whole bunch of claims and conditions. Ruling on some (eg
> source code publication) does not imply that the all are valid. Both
> of these cases seem to be irrelevant regarding Schilling/Debian
> battle, which has to do with linking, not with souce code publication.
> The claim on Debian's behalf is that one cannot link GPL code with
> CDDL code. Schilling disputes this. None of these cases address this
> issue. This issue swims in the murky waters of "derived works". When
> is work A considered a derived work of work B? [...]
As I understand it, a given project B is considered - at least, in
GPLv2; I don't know about GPLv3 - to be a derivative work of project A
when said project B is statically linked against project A, which, for
all intents and purposes, is pretty much the same as that project B
would include actual code from project A.
So if project B invokes code from project A by symbol substitution, then
it's not a derivative work. If it does so by literally invoking
certain code from project A - e.g. through a GPL'd library - or by
literally including code from project A in its own code, then it is
considered to be a derivative work.
Perhaps a bit oversimplified, but this is my understanding of the issue
at hand. I am however insufficiently informed about the CDDL, nor of
Joerg Schilling's code - I'm not qualified to analyze code written in C
or C++ - so I have no way of knowing whether the above applies to
Joerg's re-released cdrtools or not. The only thing I know - from
whatever discussions on the matter I have observed on Usenet - is that
Joerg and Debian differ in their interpretation.
The FSF states that the CDDL is a valid Free & Open Source license, but
that incompatible with the GPL, and would appear to be consistent with
Debian's opinion in that, but the FSF, being a political organization,
clearly has its own biases.
In the end, it all boils down to pedanticism, which, unfortunately, our
present society has grown to demand.
--
*Aragorn*
(registered GNU/Linux user #223157)
That has frightening implications. That means any code that was ever
written and linked to a fee library is by definition not owned by the
guys that wrote it.
Microsoft ergo would have rights to anything that runs on windows thats
beenm compiled against their libraries.
That judgement is tantamount to saying that the rights to a book are
with the firm that made the paper.
>
> Perhaps a bit oversimplified, but this is my understanding of the issue
> at hand. I am however insufficiently informed about the CDDL, nor of
> Joerg Schilling's code - I'm not qualified to analyze code written in C
> or C++ - so I have no way of knowing whether the above applies to
> Joerg's re-released cdrtools or not. The only thing I know - from
> whatever discussions on the matter I have observed on Usenet - is that
> Joerg and Debian differ in their interpretation.
>
> The FSF states that the CDDL is a valid Free & Open Source license, but
> that incompatible with the GPL, and would appear to be consistent with
> Debian's opinion in that, but the FSF, being a political organization,
> clearly has its own biases.
>
> In the end, it all boils down to pedanticism, which, unfortunately, our
> present society has grown to demand.
>
Too MUCH law.
And the biggest copyright threat not under our jurisdiction. Asia.
"Free Windows good for country. Free Windows declared legal!"
> Aragorn wrote:
>
>> On Sunday 28 November 2010 10:55 in comp.os.linux.misc, somebody
>> identifying as unruh wrote...
>>
>>> The GPL is a whole bunch of claims and conditions. Ruling on some
>>> (eg source code publication) does not imply that the all are valid.
>>> Both of these cases seem to be irrelevant regarding Schilling/Debian
>>> battle, which has to do with linking, not with souce code
>>> publication. The claim on Debian's behalf is that one cannot link
>>> GPL code with CDDL code. Schilling disputes this. None of these
>>> cases address this issue. This issue swims in the murky waters of
>>> "derived works". When is work A considered a derived work of work B?
>>> [...]
>>
>> As I understand it, a given project B is considered - at least, in
>> GPLv2; I don't know about GPLv3 - to be a derivative work of project
>> A when said project B is statically linked against project A, which,
>> for all intents and purposes, is pretty much the same as that project
>> B would include actual code from project A.
>>
>> So if project B invokes code from project A by symbol substitution,
>> then it's not a derivative work. If it does so by literally invoking
>> certain code from project A - e.g. through a GPL'd library - or by
>> literally including code from project A in its own code, then it is
>> considered to be a derivative work.
>
>
> That has frightening implications. That means any code that was ever
> written and linked to a fee library is by definition not owned by the
> guys that wrote it.
Not necessarily. This is - at least, to my knowledge - applicable
specifically to the linking against GPL'd code only. It doesn't say
anything about any other software licenses.
This is one of the reasons why the FSF has also created the LGPL
license, which is less restrictive.
> Microsoft ergo would have rights to anything that runs on windows
> thats beenm compiled against their libraries.
Considering that Microsoft is one of the most significant patent trolls,
I wouldn't be surprised if they're holding that card up their sleeve
until due time.
> That judgement is tantamount to saying that the rights to a book are
> with the firm that made the paper.
Depending on the interpretation, yes, but herein lies the key: it's all
about interpretation, and *that* in itself is thus open for debate, and
may have varying outcomes in litigation, depending on the jurisdiction
where said litigation is conducted. This variation exists due to the
fact that the GPL is not confined to a single nation.
For instance, if there were any litigation conducted within the United
States, then a judge or attorney may refer to decisions ruled in
earlier litigations within the United States with regard to similar
scenarios as in the litigation at hand, but courts in other nations may
interpret things quite differently.
>> Perhaps a bit oversimplified, but this is my understanding of the
>> issue at hand. I am however insufficiently informed about the CDDL,
>> nor of Joerg Schilling's code - I'm not qualified to analyze code
>> written in C or C++ - so I have no way of knowing whether the above
>> applies to Joerg's re-released cdrtools or not. The only thing I
>> know - from whatever discussions on the matter I have observed on
>> Usenet - is that Joerg and Debian differ in their interpretation.
>>
>> The FSF states that the CDDL is a valid Free & Open Source license,
>> but that incompatible with the GPL, and would appear to be consistent
>> with Debian's opinion in that, but the FSF, being a political
>> organization, clearly has its own biases.
>>
>> In the end, it all boils down to pedanticism, which, unfortunately,
>> our present society has grown to demand.
>
> Too MUCH law.
I couldn't agree more.
> And the biggest copyright threat not under our jurisdiction. Asia.
> "Free Windows good for country. Free Windows declared legal!"
Fortunately, the qualities of GNU/Linux and the merits of Free & Open
Source Software are also well-known in Asian countries. ;-) (Among
others, China has its own official GNU/Linux distribution, Red Flag.)
Microsoft mainly relies on its power over the traditional "first world"
nations - the USA, Canada, Australia and just about all of (Western)
Europe. However, more and more nations elsewhere around the globe are
starting to stand up to Microsoft, from South America over the Russian
Federation to Asia.
It's quite amusing actually how Microsoft's FUD with regard to "alleged
copyright or patent infringements" is simply being ignored and the
Microsoft representatives are sent back home to Redmond with their
tails between their legs. ;-)
For those who are not trained to read German substanciations from judges that
made a legal verdict, here is a shortened free translation:
"The decision was based on the Copyright law and we did only look at a single
claim from GPL section 2 (verifying whether this single claim may be in
conflict with the law). Do never try to base a prosecution on the other claims
from GPL section 2 as we believe that they are not valid because they are in
conflict with the law."
><http://gpl-violations.org/news/20050414-fortinet-injunction.html>
This URL does not point to any evidence. It only contains unsourced claims
and does not even permit to verify whether there has been a court case at all.
Conclusion: The URLs you send clearly confirm my statements.
BTW: the attacks from Debian are all based on those parts of the GPL that have
been identified to be in conflict with the law. Evidence for this statement can
be retrieved from the substanciations for the cases won by Harald Welte as well
as from scientific papers from Rosen, Gordon and Determan, see
http://www.osscc.net/en/gpl.html
for background information.
>>> As I understand it, a given project B is considered - at least, in
>>> GPLv2; I don't know about GPLv3 - to be a derivative work of project
>>> A when said project B is statically linked against project A, which,
>>> for all intents and purposes, is pretty much the same as that project
>>> B would include actual code from project A.
GPL2 states exactly what it means by "derivative work"; there is no need
to speculate.
GPL3 does not contain the term.
>>> So if project B invokes code from project A by symbol substitution,
>>> then it's not a derivative work. If it does so by literally invoking
>>> certain code from project A - e.g. through a GPL'd library - or by
>>> literally including code from project A in its own code, then it is
>>> considered to be a derivative work.
>>
>> That has frightening implications. That means any code that was ever
>> written and linked to a fee library is by definition not owned by the
>> guys that wrote it.
Ownership is not affected, only the possible terms of distribution.
That's true of any application that mixes code with more than one
copyright holder (whether by static linking; use of templates or inline
functions; or simply pasting in source code).
That much isn't particularly controversial (except among wingnuts); the
less tractable arguments arise about dynamic linking (does the
executable actually contain any part of the library?) and what terms are
actually chosen.
> Not necessarily. This is - at least, to my knowledge - applicable
> specifically to the linking against GPL'd code only. It doesn't say
> anything about any other software licenses.
>
> This is one of the reasons why the FSF has also created the LGPL
> license, which is less restrictive.
>
>> Microsoft ergo would have rights to anything that runs on windows
>> thats beenm compiled against their libraries.
>
> Considering that Microsoft is one of the most significant patent trolls,
> I wouldn't be surprised if they're holding that card up their sleeve
> until due time.
MS specifically explicitly permit redistribution of relevant libraries
as part of the EULA of their development tools.
It is really easy....Just use cdrkit
>GPL2 states exactly what it means by "derivative work"; there is no need
>to speculate.
The US Copyright law does not permit a license (like the GPL) to redefine the
definition of a "derived work".
Under European law, the rules of law for "terms and conditions" apply to the
GPL and as the GPL is highly imprecise in this area, the best possible
interpretation for a licensee apply.
The result is the same in both jurisdictions: Whatever the GPL tries to
establish while trying to define a "derived work" is void.
The best explanation for this fact can be found in the paper from Lothar
Determan (who is law professor in Berlin and San Francisco).
http://www.osscc.net/en/gpl.html
>It is really easy....Just use cdrkit
If you like to use something that is based on 6 year old code, is unmaintained
since 3.5 years, is full of bugs and that cannot be legally distributed.... go
ahead and use cdrkit.
People who are interested in working software that has no legal problems use
the original cdrtools.
The writers of GPL do not have the power to declare something a
derivative work. That is a term of law, and only the law can decide
whether somehting is a derivative work or not. GPL writers cannot. That
is the problem as far as Schilling is concerned. While some people have
a very broad definition of derivative work (Some of the Debian people,
SCO) at least some lawyers do not believe that that a court would
support that definition-- they have attempted to make it overbroad.
> when said project B is statically linked against project A, which, for
> all intents and purposes, is pretty much the same as that project B
> would include actual code from project A.
>
> So if project B invokes code from project A by symbol substitution, then
> it's not a derivative work. If it does so by literally invoking
> certain code from project A - e.g. through a GPL'd library - or by
> literally including code from project A in its own code, then it is
> considered to be a derivative work.
>
> Perhaps a bit oversimplified, but this is my understanding of the issue
> at hand. I am however insufficiently informed about the CDDL, nor of
> Joerg Schilling's code - I'm not qualified to analyze code written in C
> or C++ - so I have no way of knowing whether the above applies to
> Joerg's re-released cdrtools or not. The only thing I know - from
> whatever discussions on the matter I have observed on Usenet - is that
> Joerg and Debian differ in their interpretation.
>
And since it is Jorg's code his interpretation carries more weight
especially since it is a matter whthr or not Jorg can or would sue
Debian for distributing his own code.
They claim that if they distributed the code, then Jorg would have the
right to sue them. Jorg says he would not. His statements on the matter
would carry a lot of weight in court if he tried to sue anyone.
It is a stupid dispute.
> The FSF states that the CDDL is a valid Free & Open Source license, but
> that incompatible with the GPL, and would appear to be consistent with
> Debian's opinion in that, but the FSF, being a political organization,
> clearly has its own biases.
The problem is that GPL3 is far more incompatible with GPL2 than is
CDDL.
>
> In the end, it all boils down to pedanticism, which, unfortunately, our
> present society has grown to demand.
>
It is a childish bun fight where the only one that gets hurt is the
users.
> In article <751as7-...@lapu-lapu.bildanet.com>,
> GangGreene <GangG...@invalid.com> wrote:
>
>>It is really easy....Just use cdrkit
>
>
> If you like to use something that is based on 6 year old code, is
> unmaintained since 3.5 years, is full of bugs and that cannot be legally
> distributed.... go ahead and use cdrkit.
>
> People who are interested in working software that has no legal problems
> use the original cdrtools.
>
>
<Quote>
This is a little web page for the cdrkit project. If you want to see more
here - feel free to join and help. cdrkit is a suite of programs for
recording CDs and DVDs, blanking CD-RW media, creating ISO-9660 filesystem
images, extracting audio CD data, and more. The programs included in the
cdrkit package were originally derived from several sources, most notably
mkisofs by Eric Youngdale and others, cdda2wav by Heiko Eissfeldt, and
cdrecord by Jörg Schilling. However, cdrkit is not affiliated with any of
these authors; it is now an independent project.
cdrkit, like the programs from which it was derived, is distributed as free
software under the terms of the GNU GPL version 2. (Note, this is not
"version 2 or later" as you see in many software projects.)
2006/12/30 Cdrkit 1.1.2 has been released, featuring various bugfixes.
2007/03/26 Cdrkit 1.1.3 has been released, featuring various bugfixes on
automatic device guessing, device scan and default settings parser.
Experimental extension allows Large File Support with UDF filesystem part
2007/04/01 Cdrkit 1.1.4 has been released, providing some internal fixes.
Now libusal opens the /dev/srX devices rather than /dev/sgX, where possible.
2007/04/21 Cdrkit 1.1.5 has been released, with genisoimage fix for <<4GiB
files and internal restructuring
2007/05/06 Cdrkit 1.1.6 has been released, adding generic drive guessing,
OpenBSD support and some bugfixes
2008/03/17 Cdrkit 1.1.7.1 has been released.
2008/10/26 Cdrkit 1.1.9 has been released.
2009/10/11 Cdrkit 1.1.10 has been release
2010/10/17 Cdrkit 1.1.11 has been released.
</Quote>
Well it looks like it is active and maintained to me.
As they are accepting help and want people to join them,
Why don't you volunteer?
You could be of some help to them, rather than just repeating your stale old
opinions.
I have used cdrkit for about 5 years, it works fine.
> The GPL is a whole bunch of claims and conditions. Ruling on some (eg
> source code publication) does not imply that the all are valid.
Doesn’t matter. As Eben Moglen has pointed out, if the GPL is invalid, then
anybody making a copy of GPL’d software is infringing copyright. Either you
can have the software under the GPL, or you can’t have it at all.
I am sure you are able to explain us why all these "releases" did either
introduce new bugs or did just fix typos. I am sure you are able to explain us
why none from more than 100 well documented major bugs (all known since at
least spring 2007) have never been fixed. I am sure you are able to explain us
why bug reports for this software are ignored.....
>As they are accepting help and want people to join them,
>
>Why don't you volunteer?
You might be astonished, but I am of course contributing to my software on a
daily base. You can see the results here:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
None of the > 100 bugs documented for the fork can be found in this source and
there is plenty of new features, as more than 6 years have past since Debian
stopped collaboration.
The judges that judge by the GPL have far more farsightedness than Eben Moglen
as they know about the invalidity of the GPL and for this reason carefully
overlook the problems in the GPL text when making a decision.
Moglen is a politician, you will rarely see legally valid claims from him in
the public.
> In article <icun9d$rl$1...@lust.ihug.co.nz>,
> Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:
>>In message <slrnif4a1s...@wormhole.physics.ubc.ca>, unruh wrote:
>>
>>> The GPL is a whole bunch of claims and conditions. Ruling on some (eg
>>> source code publication) does not imply that the all are valid.
>>
>>Doesn’t matter. As Eben Moglen has pointed out, if the GPL is invalid, then
>>anybody making a copy of GPL’d software is infringing copyright. Either you
>>can have the software under the GPL, or you can’t have it at all.
>
> The judges that judge by the GPL have far more farsightedness than Eben Moglen
> as they know about the invalidity of the GPL and for this reason carefully
> overlook the problems in the GPL text when making a decision.
Ummmm.. Right. All those judges belong to a vast worldwide conspiracy to
keep GPL legal, even though all of them know that it's not, according to
you.
I'm sure all of that, somehow, makes sense to you.
> Moglen is a politician, you will rarely see legally valid claims from him in
> the public.
Moglen's track record in court, as far as legally valid claims go, is much
better than yours'.
A court could rule that a work does not become a derivstive of a GPLd
work merely because it must be linked to that work in order to be
useful. Another court could rule that the patent stuff is unenforceable
(or, worse, is copyright abuse).
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA
...
>
> I have used cdrkit for about 5 years, it works fine.
This thread started by someone for whom cdrdit did NOT work well. The
UTF support was broken.
Do you have UTF filenames?
>
No. It is not a question of all of GPL being invalid, as has been stated
numerous times, but of parts being invalid. And the courts will
interpret the terms in such a way that they are of greatest benefit to
the user, not ot the issuer. After all the issuer was the one who set
the conditions. The license does not simply evaporate. It simply become
less restrictive than the issuer thought it was. A court would regard
the user as having accepted the license in good faith, and would grant
him everything it could, voiding the invalid parts.
The issuer cannot have it both ways.
> In article <3u2bs7-...@lapu-lapu.bildanet.com>,
> GangGreene <GangG...@invalid.com> wrote:
> ...
>>
>></Quote>
>
> I am sure you are able to explain us why all these "releases" did either
> introduce new bugs or did just fix typos. I am sure you are able to
> explain us why none from more than 100 well documented major bugs (all
> known since at least spring 2007) have never been fixed. I am sure you are
> able to explain us why bug reports for this software are ignored.....
>
>
>>As they are accepting help and want people to join them,
>>
>>Why don't you volunteer?
>
> You might be astonished, but I am of course contributing to my software on
> a daily base. You can see the results here:
>
You know I was not talking about cdrtools. I was talking about volunterring
for cdrkit
No, you are reading /way/ too much into this. Ownership in this case
means "ownership of copyrights", and is not in question.
And questions about what really is a "derived work" or not, according to
different definitions, are also pretty much irrelevant. The important
issue is what does the GPL license say you can and cannot do with other
people's software under that license.
(I know the GPLv2 best here - there may be differences with the GPLv3.)
The GPL considers software to be a "derived work" of GPL'ed software if
it is tightly bound to it - it includes the GPL'ed code in its
compilation or static or /dynamic/ linking. It is perhaps clearer if
you pretend it said "dependent work".
So if you write a program that uses a GPL'ed dynamic linked library
(.dll or .so), then your program can only legally use the library if
your program is also available under the GPL. This doesn't mean that
the GPL'ed library is somehow asserted claims or ownership over your
program, or "infects" your program with the GPL - it simply means that
if you want to use that library, you need to follow it's license.
Consider the situation where you used a commercial library that required
royalties per use. This doesn't mean that the the commercial company
"owns" your software in any way - it just means that if you want to use
their library, you have to follow their license conditions and pay the
fee. It's the same thing with the GPL.
(Actually with the GPL, the license covers distribution - you can /use/
GPL'ed software as you like for your own purposes.)
Note that the GPL explicitly excludes "mere aggregation" - you can
distribute non-GPL and GPL software together as long as they are not
tightly bound and dependent. Thus there is no problem for a Linux
distribution to include non-GPL software along with the GPL'ed stuff.
It's fine to /use/ GPL'ed software along with non-GPL'ed software, and
it is fine to link them together (dynamically, statically, or even in
the same compilation). But you can't then legally distribute the
binary. This is why source-code distributions like Gentoo can give you
a package that's a mixture of GPL and CDDL code, while binary
distributions like Debian cannot. It's just a simple reading of the
GPL, following both the intention of the license and the letter of the
license.
As an example of how the GPL does /not/ make any claims over your
software, there is a possible loophole (perhaps this was closed with the
GPLv3?). Suppose you want to distribute non-GPL software that links to
GPL libraries. You cannot distribute the binaries together, but you may
be able to distribute just your own software binaries, and require users
to get the libraries separately. You will almost certainly lose your
rights to distribute the GPL'ed libraries by doing this, so you can't
just make them a separate download link, but I think you are legally in
the clear - /you/ are not linking your program with GPL'ed libraries, it
is the end use who is doing so. And as long as that end user is not
distributing the combined software, no license has been violated.
The LGPL, which was also mentioned in a post, is slightly different.
The basic requirement to distribute code that makes use of LGPL'ed
software is that the end user must have access to the source of the
LGPL'ed code, be able to modify that code, and use that modified code
with the rest of the program. Typically that means the LGPL'ed code is
in a dynamic library that can be updated independently of the
non-(L)GPL'ed code. But it's also possible to use static linking, in
which case the non-(L)GPL'ed code also has to be available in a linkable
format or source format. Non-gpl'ed source code, such as provided under
the CDDL, is fine.
> Microsoft ergo would have rights to anything that runs on windows thats
> beenm compiled against their libraries.
>
>
> That judgement is tantamount to saying that the rights to a book are
> with the firm that made the paper.
>
No, it's a bit like the paper firm saying "You can only buy our paper to
print books. If you want to make paper aeroplanes, buy paper from
someone else". The analogy is not very accurate, however, since the GPL
is about distribution rather than use.
Yes and UTF file content.
Also
$ echo $LANG
en_US.UTF-8
>>> I have used cdrkit for about 5 years, it works fine.
>>
>> This thread started by someone for whom cdrdit did NOT work well. The
>> UTF support was broken.
>> Do you have UTF filenames
>
>Yes and UTF file content.
>
>Also
>$ echo $LANG
>en_US.UTF-8
Please note that LANG is a fallback only in case there is neither LC_ALL nor
LC_*.
Highest priority has LC_ALL
The next in the priority list is LC_MESSAGES, LC_CTYPE, .....
LANG comes last.
cdrkit has a partially correct UTF-8 "support" for Joliet but no UTF-8 support
for e.g. Rock Ridge and there are known problems with UDF even though the
outdated 6 year old mkisofs genisoimage was based on uses the Joliet name
tables for UDF also.
Mkisofs has full UTF-8 support since November 2006.
Defining/flagging and more on file content is not subject of the filesystems in
question.
No. The licensor has only certain rights given by copyright law. They
cannot claim rights which copyright law does not give them. The GPL
cannot claim rights above and beyond the law.
If it is not the original work in question, but is a new work, then teh
relation between that new work and some other original work it uses is
comes under the heading of "derived work". A derived work fallsunder the
copyright of both the original and the new work, and copyright in the
derived work is owned by both copyright holders. It is that aspect of
the law that the GPL uses to try to exert control over someone else's
new work. If the rights the GPL claims are too broad-- if it tries to
claim rights the law does not give it, then those aspects of the license
become null. The whole license does not become null, just those
sections. (Otherwise someone could issue a license which some minor bit
they knew was illegal, and then start suing people because the license
was invalid because that one small section was invalid).
>
> (I know the GPLv2 best here - there may be differences with the GPLv3.)
>
> The GPL considers software to be a "derived work" of GPL'ed software if
> it is tightly bound to it - it includes the GPL'ed code in its
> compilation or static or /dynamic/ linking. It is perhaps clearer if
> you pretend it said "dependent work".
>
The GPLs definition of "derived work" is compleely irrelevant as people
keep saying. That is a term of law and cannot be defined by anyone but
the courts and the law makers. It cannot be defined by the licensor.
They simply cannot take to themselves the right to make claims that go
beyond those allowed by law and expect any court to uphold them.
> So if you write a program that uses a GPL'ed dynamic linked library
> (.dll or .so), then your program can only legally use the library if
> your program is also available under the GPL. This doesn't mean that
> the GPL'ed library is somehow asserted claims or ownership over your
> program, or "infects" your program with the GPL - it simply means that
> if you want to use that library, you need to follow it's license.
>
> Consider the situation where you used a commercial library that required
> royalties per use. This doesn't mean that the the commercial company
> "owns" your software in any way - it just means that if you want to use
> their library, you have to follow their license conditions and pay the
> fee. It's the same thing with the GPL.
The only reason they can do that is under the "derived works" aspect of
copyright law. And yes, if it is a derived work, they DO own your work.
It is their copyright which applies to the work as much as it is yours.
>
> (Actually with the GPL, the license covers distribution - you can /use/
> GPL'ed software as you like for your own purposes.)
>
> Note that the GPL explicitly excludes "mere aggregation" - you can
> distribute non-GPL and GPL software together as long as they are not
> tightly bound and dependent. Thus there is no problem for a Linux
> distribution to include non-GPL software along with the GPL'ed stuff.
This is their half assed attempt at trying to say what the law means by
derived work. It is also an indication that they have exceeded their
rights. No law would ever even think that their license extended to
"mere aggregation". It is like them putting in a phrase that their
copyright does not apply your telephone conversations. But to the extent
that their license could seem to apply to "mere aggregation" they have
vastly exceeded what they have any right to put into their license.
Anyone can put whatever they want into a license. I could claim that
since you answered my email you owe me a million dollars, since you have
replied to my concepts. No court of law would grant me that money
however, since my claim exceeded the rights I am allowed to claim under
the law.
>
> It's fine to /use/ GPL'ed software along with non-GPL'ed software, and
> it is fine to link them together (dynamically, statically, or even in
> the same compilation). But you can't then legally distribute the
> binary. This is why source-code distributions like Gentoo can give you
> a package that's a mixture of GPL and CDDL code, while binary
> distributions like Debian cannot. It's just a simple reading of the
> GPL, following both the intention of the license and the letter of the
> license.
The quesiton is NOT what the GPL says. The question is what they
allowed, by law, to say.
>
>
> As an example of how the GPL does /not/ make any claims over your
> software, there is a possible loophole (perhaps this was closed with the
> GPLv3?). Suppose you want to distribute non-GPL software that links to
GPL3 is incompatible with GPL2 which is one of the reasons why Linus
refuses to use GPL3 for the kernel.
Were your interetation valid, Linux could contain no GPL3 software.
And it is probably beyond copyright law to use it tolimit what the user
can do with the material. copyright law applies only to copying, not
use.
>
Actually, at least in the US, some types of use _ARE_ governed by
copyright law. For example, read the fine print on commercial
VHS tapes below the headline, "For Home Use Only". I think it
was the "Film Security Office" that published a big write-up
threatening huge fines for anyone who would play such a videotape
outside of a "home" situation, including churches, schools,
hospitals, prisons, etc. They reference public performance
provisions of US copyright law.
--
Robert Riches
spamt...@jacob21819.net
(Yes, that is one of my email addresses.)
While it may be true that Joerg writes very good code, you need
to take what he says (especially on this topic) with a grain of
salt. Some years ago, I had done specific experiments running
cdrecord (pre-fork, IIRC) as a non-root user with_OUT_ suid
root. Joerg said it couldn't possibly work. The CDs I
successfully burned with it contradicted his words.
>While it may be true that Joerg writes very good code, you need
>to take what he says (especially on this topic) with a grain of
>salt. Some years ago, I had done specific experiments running
>cdrecord (pre-fork, IIRC) as a non-root user with_OUT_ suid
>root. Joerg said it couldn't possibly work. The CDs I
>successfully burned with it contradicted his words.
Cdrecord, cdda2wav, readcd and rscsi all need root privileges. People who
claim something else are not informed correctly about Linux.
I agree with most of what you wrote and even that it is "a simple
reading of ... the letter of the license". However, I think it is too
simple and I doubt that it is the intention. For example, one library
with a GPL-incompatible licence is openssl. Openssl is normally
distributed with the OS. There are (or were - there is now gnutls as a
replacement for openssl) GPL programs on Debian linked against openssl.
Some argued (successfully) that this violates the GPL, because both
openssl and those GPL programs are part of the same distribution ("that
component itself accompanies the executable"). It would be ok if the
GPL programs were distributed separately. Firstly, the result of this
interpretation is clearly absurd. Secondly, several commercial Unix
vendors have included GPL programs with their operating systems for many
years. If the FSF was of the opinion that this was a violation of the
GPL, they could have sued them. But they didn't. So if linking a GPL
program against a non-free library (which is "normally distributed with
the major components of the operating system") and distributing it
together with the OS is ok, how can linking against a free library
(which is "normally distributed with the major components of the
operating system") and distributing it together with the OS not be ok?
hp
I assume that the verdict you are talking about is
http://www.jbb.de/urteil_lg_frankfurt_gpl.pdf (linked from the page
above).
> "The decision was based on the Copyright law and we did only look at a
> single claim from GPL section 2 (verifying whether this single claim
> may be in conflict with the law). Do never try to base a prosecution
> on the other claims from GPL section 2 as we believe that they are not
> valid because they are in conflict with the law."
This translation is indeed very free. What the verdict actually says is:
The conditions "must include disclaimer and license" (from GPL section
1) and "must include source code" (from section 3) are an integral part
of the license. Section 4 makes it explicit that the right to
distribute the program is only granted if these conditions are met.
This is "not invalid" and "not unreasonable".
The defendant clearly violated these conditions. Therefore he was not
allowed to distribute the program(s). The defendant apparently already
published the source code during the trial and promised to notify the
customers that the software is distributed under the GPL, so he only
needs to pay the expenses of the plaintiff and the lawers.
What is indeed strange about the verdict is that it several times refers
to section 2 by number, but never to sections 1 or 3, although it
clearly refers to their content (and frankly, they seem more relevant to
the verdict than section 2). I don't draw any conclusions from that.
The verdict also doesn't touch every single point of the GPL (for
example, it doesn't touch the linking problem, because that simply
wasn't relevant in this case), but it does confirm that the basic idea
is sound and that you have conform to the GPL if you want to distribute
GPL'd programs.
hp
> In article <slrnif92p3.9...@one.localnet>,
> Robert Riches <spamt...@verizon.net> wrote:
>
>>While it may be true that Joerg writes very good code, you need
>>to take what he says (especially on this topic) with a grain of
>>salt. Some years ago, I had done specific experiments running
>>cdrecord (pre-fork, IIRC) as a non-root user with_OUT_ suid
>>root. Joerg said it couldn't possibly work. The CDs I
>>successfully burned with it contradicted his words.
>
> Cdrecord, cdda2wav, readcd and rscsi all need root privileges. People who
> claim something else are not informed correctly about Linux.
I regularly and successfully burn CDs and DVDs without resorting to root
privileges.
Maybe it is you who are “not informed correctly about Linux”.
If that is the case, then I guess the two CDs I verified just
this evening don't know much about Linux. On my Mandriva 2010.0
system, 'readcd' goes through a few symlinks and eventually ends
up as /usr/bin/readom:
-rwxr-xr-x 1 root root 217708 Oct 8 2009 /usr/bin/readom
Notice that it's _NOT_ suid root. I ran it from my non-root user
account. It worked fine. The account I used is a member of
group 'cdrom', and the device, /dev/sr1, is rw-able by said group
'cdrom'.
No, I work in what used to be an arsenal in the 19th century. But that's
off-topic. My e-mail address is valid (although heavily spam-filtered),
If you have personal questions you can send me mail.
hp
> On 2010-11-30 20:08, Sidney Lambe
> <sidne...@somewhere.invalid> wrote:
>
>> On comp.os.linux.misc, Peter J. Holzer <hjp-u...@hjp.at>
>> wrote:
>>
>> [delete]
>>
>> You live in an arsenal?
>
> No, I work in what used to be an arsenal in the 19th century.
> But that's off-topic. My e-mail address is valid (although
> heavily spam-filtered), If you have personal questions you can
> send me mail.
>
> hp
>
Why would I do that when you've just answered my question?
Sid
Just for the record, Joerg is citing his own web page here.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
It is a fairytale that there is a difference in license compatibility between a
library that is "normally distributed with the system" and another one that is
not.
1) There is _absolutely_ nothing in the GPL text that allows to prove
such a claim. People who read the GPL know what's really in the GPL
text: There is indeed an exception that allows you to exclude a
library normally distributed with the sytem from the list of parts
that belong to what is called "full source". There is however nothing
that grants better license compatibility for such a library.
2) If OS distributors could influence the effects from the Copyright law
and from the GPL by adding own definitions to software they
distribute for their platform, then the GPL would be worth nothing.
An OS distributor does not own any rights on the software and for this
reason, such a distributor cannot change the rules for licensing.
> On 2010-11-30, Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>
>> Cdrecord, cdda2wav, readcd and rscsi all need root privileges. People who
>> claim something else are not informed correctly about Linux.
>
> If that is the case, then I guess the two CDs I verified just
> this evening don't know much about Linux.
I’m wondering about Schilling. He sounds more and more like one of these
Windows blowhards who tries to put down Linux without really knowing much
about it.
I have no idea why you write things that can esasily proven for being wrong.
For the original cdrecord, your claim is complete nonsense as cdrecord will
prevents you early from starting a job that will fail later.
Even with the intentionally broken "wodim" (where this check has been removed by it's
clueless initiators), your claim is worth no more than the claim of a person that
tells everybody to cross the traffic at the red light because you did it once and
are still alive. There is a sufficient amount of bug reports in the bug-tracker
systems of the related Linux distros....
Why the cdrtools need root privileges has been explained many times and you can
be sure that I do not make them suid root just for fun. On Solaris, cdrecord
needs to have 5 of the non-default fine-grained privileges and Linux may have a
6th reason for more privileges because Linux does not allow to send any SCSI
commands for programs that miss a specific privilege.
Just for the record, neither the FSF nor Debian did ever give any evidence to
prove their claim that GPL and CDDL code is "incompatible".
www.osscc.net on the other side just cites lawyers and internationally acting
professors.
He has written some really good software for Linux, -- software that
everyone uses (even cdrkit is his software). He knows Linux.
I think his argument re the suid issue is that some of the features of
that softwar requires suid to operate properly and efficiently. It is
not that the software does not work without suid, it is that it does not
work well. You might never have run into cases where it causes problems.
It is like someone saying that the antilock brakes on some car do not
work properly and someone else saying they have driven that car for
years and never had problems with the bakes. Both statements can be
true.
Just for record, the ArchLinux distribution has:
bsd@arch ~]$ ls /usr/share/licenses/common
APACHE CDDL EPL FDL1.2 GPL GPL3 LGPL2.1 LPPL PHP PerlArtistic RUBY
CCPL CPL FDL FDL1.3 GPL2 LGPL LGPL3 MPL PSF RALINK ZPL
as commonly accepted F/OSS or licenses.
In addition to above, they also ship 100s of 1000s other F/OSS packages
both in binary as well as source form, particularly some based on the
BSD license. See also http://bit.ly/e0P5iO
--
Balwinder S "bdheeman" Dheeman Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe) Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://werc.homelinux.net/ Visit: http://counter.li.org/
There are thousands of millions of volunteer developers and, or
contribution who don't know what exactly a UNIX philosophy is, but they
are still pushing a lot good as well as spaghetti or buggy code or
packages in to the F/OSS repositories.
I for one, still thank them all, to let me decide which one/package is
best suitable for me.
> In message <slrnifbo81.f...@one.localnet>, Robert
> Riches wrote:
>
>> On 2010-11-30, Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>
>>> Cdrecord, cdda2wav, readcd and rscsi all need root
>>> privileges. People who claim something else are not informed
>>> correctly about Linux.
>>
>> If that is the case, then I guess the two CDs I verified just
>> this evening don't know much about Linux.
>
> I[windows character deleted]m wondering about Schilling. He
> sounds more and more like one of these Windows blowhards who
> tries to put down Linux without really knowing much about it.
Actually, he knows Linux a lot better than you do.
You sound like a windows-weenie trying to pretend that he
knows all about Linux.
You even use weird character set(s) that we usually only
see when windows-weenies invade us.
Joerg has written some excellent and useful software for
Linux
As for running SUID, this is only a big deal to the
truly paranoid, or the people who make a living
feeding Linux runners' paranoia.
Myself and many others run Linux as root all the time.
There are entire distros, like Puppy Linux, that are
designed to be run as root.
Sid
> Just for the record, neither the FSF nor Debian did ever give any evidence
> to prove their claim that GPL and CDDL code is "incompatible".
Just for the record, Debian contributors carefully explained this, drawing
specific attention to the clauses in the GPL and how they clashed with
having parts of the build system being subject to an incompatible licence.
> In article <id3rce$veg$4...@lust.ihug.co.nz>,
> Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:
>
>>In message <8ljveo...@mid.dfncis.de>, Joerg Schilling wrote:
>>
>>> Cdrecord, cdda2wav, readcd and rscsi all need root privileges. People
>>> who claim something else are not informed correctly about Linux.
>>
>>I regularly and successfully burn CDs and DVDs without resorting to root
>>privileges.
>
> I have no idea why you write things that can esasily proven for being
> wrong.
I have done it. Others have done it. We all bear witness to it, contrary to
your hollow, unsubstantiated denials, which are increasingly sounding like
the delusions of somebody who simply refuses to face up to reality.
> On 2010-12-02, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand>
> wrote:
>
>> I’m wondering about Schilling. He sounds more and more like one of
>> these Windows blowhards who tries to put down Linux without really
>> knowing much about it.
>
> He knows Linux.
He’s showing precious little evidence of that in this thread.
> I think his argument re the suid issue is that some of the features of
> that softwar requires suid to operate properly and efficiently.
None of the features of the software require “suid to operate properly and
efficiently”.
These rules define the boundary between "the program" and "the platform
that program runs on". Clearly the license can only cover the program
and not the platform.
There are two constraints that this rule tries to meet:
1) In 1991, when the GPL2 was written, many Unixes didn't have shared
libraries. They did usually ship with a C compiler and libaries.
So anybody who distributed binaries for these systems necessarily
shipped binaries which contained code from the GPL'ed program and
the proprietary libraries. The FSF wanted to allow that. Otherwise
the GPL would not have been accepted by authors who wanted to write
programs for those systems.
2) But if you allow binaries which allow some GPL code and some non-GPL
code there is an obvious loophole for someone who wants to take a GPL
program and make it into a proprietary program: He just puts all his
new code into a library and modifies the program to call that
library. Then he distributes the library under his license and the
modified code under the GPL. Obviously this prevents the licensee of
the modified program from exercising his rights (redistribution,
modification, ...), so this had to be disallowed. (I remember that
somebody tried this with gdb and was successfully sued by the FSF)
The solution for the problem was to declare code that is normally
shipped with the platform as part of the platform, even if that code is
incorporated into the executable. But code not normally shipped with the
platform is not part of the platform and must therefore be part of the
program and covered by the GPL.
Of course in real life there are always some corner cases where it's
hard to decide on this boundary, and there are some people who have
strange ideas about this boundary.
> 1) There is _absolutely_ nothing in the GPL text that allows to prove
> such a claim. People who read the GPL know what's really in the GPL
> text: There is indeed an exception that allows you to exclude a
> library normally distributed with the sytem from the list of parts
> that belong to what is called "full source". There is however nothing
> that grants better license compatibility for such a library.
License compatibility simply isn't an issue in this case.
> 2) If OS distributors could influence the effects from the Copyright law
> and from the GPL by adding own definitions to software they
> distribute for their platform, then the GPL would be worth nothing.
> An OS distributor does not own any rights on the software and for this
> reason, such a distributor cannot change the rules for licensing.
Of course they can't. But that isn't the issue either.
hp
> In message <slrniff54r...@wormhole.physics.ubc.ca>, unruh wrote:
>
>> On 2010-12-02, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand>
>> wrote:
>>
>>> I’m wondering about Schilling. He sounds more and more like one of
>>> these Windows blowhards who tries to put down Linux without really
>>> knowing much about it.
>>
>> He knows Linux.
>
> He’s showing precious little evidence of that in this thread.
Seems obvious, as he is a Solaris user
What he says about linux is all too often simply bollocks
--
This problem was sponsored by Microsoft
Just for the record, Schilling carefully explained why he felt their
intrpretation of the license and of the law was wrong.
The GPL must be interpreted in conformance with the law under which the
license gets its power. Not only musht the clauses in the GPl be read,
but those clauses must be interpreted in such a way that they do not
conflict with the law. As a side issue, it is also their moral duty to
interpret them in way which maximizes the benefits of the users as well.
The users have been screwed by this childish fight.
> The users have been screwed by this childish fight.
Right.
Jörg Schilling really should grow up a little
--
Hanlon's Razor: Never attribute to malice which can be equally well
explained by stupidity
> On 2010-12-02, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand>
> wrote:
>
>> In message <8lpabm...@mid.dfncis.de>, Joerg Schilling wrote:
>>
>>> Just for the record, neither the FSF nor Debian did ever give any
>>> evidence to prove their claim that GPL and CDDL code is "incompatible".
>>
>> Just for the record, Debian contributors carefully explained this,
>> drawing specific attention to the clauses in the GPL and how they clashed
>> with having parts of the build system being subject to an incompatible
>> licence.
>
> Just for the record, Schilling carefully explained why he felt their
> intrpretation of the license and of the law was wrong.
No he didn’t. All he did was insist that “neither the FSF nor Debian did
ever give any evidence”.
> The writers of GPL do not have the power to declare something a
> derivative work. That is a term of law, and only the law can decide
> whether somehting is a derivative work or not. GPL writers cannot. That
> is the problem as far as Schilling is concerned.
What has this got to do with the issue over licensing of the cdrecord build
tools <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350739>?
cdrecord has a license under CDDL, and parts of mkisofs have a GPL
license. Debian claims that they are incompatible and non-distributable
through their reading of the the GPL license with respect to derivative
works. Schilling argues that that that reading is wrong, and is in
conflict with the law. If one interprets the GPL as defining derivative
works in the way that Debian people do, then the GPL exceeds its
authority under copyright law.
> On 2010-12-08, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand>
> wrote:
>> In message <slrnif5lh6...@wormhole.physics.ubc.ca>, unruh wrote:
>>
>>> The writers of GPL do not have the power to declare something a
>>> derivative work. That is a term of law, and only the law can decide
>>> whether somehting is a derivative work or not. GPL writers cannot. That
>>> is the problem as far as Schilling is concerned.
>>
>> What has this got to do with the issue over licensing of the cdrecord
>> build tools <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350739>?
>
> cdrecord has a license under CDDL, and parts of mkisofs have a GPL
> license. Debian claims that they are incompatible and non-distributable
> through their reading of the the GPL license with respect to derivative
> works.
No mention of “derivative works” in the description above.