Please include original cdrecord (cdrtools) package in Ubuntu

Bug #213215 reported by pandion on 2008-04-07
168
This bug affects 34 people
Affects Status Importance Assigned to Milestone
Linux Mint
Confirmed
Medium
Clement Lefebvre
Baltix
Medium
Mantas Kriaučiūnas
cdrtools (Fedora)
Invalid
Medium
cdrtools (Ubuntu)
Wishlist
Unassigned

Bug Description

After receiving an update for Ubuntu Gustsy Gibbon v7.10, CD and DVD burning is now broken (other versions may also be affected). I remember seeing the original cdrtools files listed as being replaced or removed during the update, but didn't know the problems it was going to cause so I allowed the update to proceed. After the update, all I am able to burn are coasters. Initially I thought K3B was the cause, but Brasero and Nautilus also have the same problems and are unable to successfully burn CDs or DVDs properly (I am writing this from a different PC so I don't have the error messages at the moment). After doing some research on this problem, I found that the original cdrools utilities (which worked and were able to successfully burn both CDs and DVDs on the affected PC prior to the update) had been replaced with a broken fork (which explains the messages I saw regarding replacing/removing these files during an update). The presence of the broken version can be confirmed by checking the Programs being used for burning within K3B or from the command line. The link below to the cdrecord website has some information regarding this broken fork and how to confirm the version installed. Last time I checked, this problem has not been corrected through an update and fixing it manually is not something I know how to do yet. This needs to be fixed through an update. Hopefully this broken fork has not found it's way into the upcoming Hardy Heron release.

http://cdrecord.berlios.de/private/linux-dist.html

Thanks, and keep up the good work!

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

I'd like to ask, why on every Fedora system I install I have to manually install cdrecord/mkisofs (since wodim rarely works correctly, often failing to finalize images, etc).

According to the spec file for cdrtools, the cause was some licensing issues.

According to the original author:
http://cdrecord.berlios.de/private/linux-dist.html
Fedora should be free to include cdrtools as an rpm.

What's the problem? Could the decision to drop cdrtools be re-examined? At least make it an optional package?

Our lawyers have other view to this problem. If this issue will be solver I'd glad make a new package and maintained it.

See:
https://www.redhat.com/archives/fedora-legal-list/2009-July/msg00000.htm

(In reply to comment #3)
> https://www.redhat.com/archives/fedora-legal-list/2009-July/msg00000.html is
> probably the URL you meant.

Yes that's it.

The redhat/fedora URL you mention above contains FUD :-(
The person who wrote the mail (somebody who calls himself
"tom") confirms that he is no lawyer and from reading his
mail it it obvious that he is even missing basic legal skills.

The cdrkit "fork" is in conflict with the copyright law
and cannot be distributed legally. The initiators
of the fork have been informed in detail about the copyright
problems but they are not interested in making the fork legal.
Why is Readhat distributing software that cannot be
legally distributed? Why does readhat consider unmaintained
software? The fork did _never_ _ever_ in it's full lifetime
deliver any even halfway bug free release. There are more than
100 well documented bugs in the fork, many of them have been
created by the initiators of the fork. There is no viable
project activity anymore since May 6th 2007.

The original software however is if course legal and this
has even be verified by several lawyers.

see:
http://cdrecord.berlios.de/private/linux-dist.html

for more information (updated).

Note that the original software is well maintained and that
reported bugs are usually fixed within a few hours. This is
why the original software did deliver more than 50 releases
that had no known bugs at time of release during the lifetime
of the "fork".

Redhat should decide whether Redhat is interested in distributing
legal software that is to the benefits of it's users or whether
redhat like to continue to distribute illegal software that does
not even work correctly.

Changed in cdrtools (Ubuntu):
status: Incomplete → New
summary: - Broken Fork of cdrtools Installed with Updates
+ Please include original cdrecord (cdrtools) package in Ubuntu

There is no special information to provide. It's just a fact that cdrkit packages are illegally distributed (by creating illegal links named cdrecord etc.) and is even so flawed that if you install original cdrtools, they will keep replacing its executables.

We just should go back to the original tools, that's all.

Marking as Wishlist and Confirmed.

Changed in cdrtools (Ubuntu):
importance: Undecided → Wishlist
status: New → Confirmed

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 11 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

The current problem with Readhat is not fixed by making a specific
Redhat release outdated. It is a general problem that RedHat ships
the fork "cdrkit" that cannot be legally distributed but refuses
to ship the legal original software.

Until any decision will be made, you can use this ppa:

ppa:brandonsnider/cdrtools

Runs much better than the Ubuntu-Packages. Another thing to meantion is that since Ubuntu provides the "Fake"-Packages, I've got burning Problems very often. Erasing a DVD failed always, only buying Nero-Linux solved the Problem for me.

Download full text (3.7 KiB)

Hey thanks! It's been awhile since I've checked that bug report. They've asked if I've had the same issue with newer versions of Ubuntu.. but the PC gets used a lot and I just haven't had the time for a complete new install etc. (it's planned though).

I added that to my Software Sources on Gutsy and also added the Signing Key as in the instructions. After updating the Sources, do I just have to install/reinstall "cdrecord" and "mkisofs", or is there also supposed to be a "CDRTools" package that should be installed to replace "CDRKit"?

When I finally get around to it I plan to reinstall the PC with a clean install of Lucid Lynx (or possibly Hardy Heron). I just have so much other stuff to do that I'm still running Gutsy for now, and have been dual booting WinXP when I need to burn something (which is a pain when I'm working on something and have to boot XP just to burn a disc). I haven't tried burning with either Hardy or Lucid, so I thought I'd ask.. Do those versions have the same issues?

Thanks again!

https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215
https://launchpad.net/~brandonsnider/+archive/cdrtools

--- On Wed, 5/12/10, Thorsten Reinbold <email address hidden> wrote:

> From: Thorsten Reinbold <email address hidden>
> Subject: [Bug 213215] Re: Please include original cdrecord (cdrtools) package in Ubuntu
> To: <email address hidden>
> Date: Wednesday, May 12, 2010, 8:30 AM

> Until any decision will be made, you
> can use this ppa:
>
> ppa:brandonsnider/cdrtools
>
> Runs much better than the Ubuntu-Packages. Another thing to
> meantion is
> that since Ubuntu provides the "Fake"-Packages, I've got
> burning
> Problems very often. Erasing a DVD failed always, only
> buying Nero-Linux
> solved the Problem for me.
>
> --
> Please include original cdrecord (cdrtools) package in
> Ubuntu
> https://bugs.launchpad.net/bugs/213215
> You received this bug notification because you are a direct
> subscriber
> of the bug.
>
> Status in “cdrtools” package in Ubuntu: Confirmed
>
> Bug description:
> After receiving an update for Ubuntu Gustsy Gibbon v7.10,
> CD and DVD burning is now broken (other versions may also be
> affected).  I remember seeing the original cdrtools
> files listed as being replaced or removed during the update,
> but didn't know the problems it was going to cause so I
> allowed the update to proceed.  After the update, all I
> am able to burn are coasters.  Initially I thought K3B
> was the cause, but Brasero and Nautilus also have the same
> problems and are unable to successfully burn CDs or DVDs
> properly (I am writing this from a different PC so I don't
> have the error messages at the moment).  After doing
> some research on this problem, I found that the original
> cdrools utilities (which worked and were able to
> successfully burn both CDs and DVDs on the affected PC prior
> to the update) had been replaced with a broken fork (which
> explains the messages I saw regarding replacing/removing
> these files during an update).  The presence of the
> broken version can be confirmed by checking the Programs
> being used for burning within K3B or from the command
> line.  The...

Read more...

This is the Statement of Jörg Schilling, the creator of cdrtools, from our Forum (www.ubuntuusers.de). I've translated this to english:

"It is up to Mark Shuttleworth, who has not met his promise, unfortunately, to integrate the cdrtools again in Ubuntu. This promise he has given me at OSCON 2008 in Portland. Then he let himself be persuaded by people that, unfortunately, have persuaded him against their better knowledge, there were licensing issues with the cdrtools. Sun says although the legal department clearly, there are no problems and also the advisory attorney OpenSource.org a generalized statement (with legal documents) to add in a positive form."

So, whats up here?

Just to be complete: the original Quote can be found here:

http://forum.ubuntuusers.de/topic/kleines-projekt-mit-paketverwaltung-die-schil/3/

@16:54

I just want to add that I am *forced* to build the original cdrecord on Fedora to get a reasonable experience. Out of the box, writing discs is horribly slow, often fails or even worse: it seems to succeed but the resulting medium is not really usable.

As you are not alone and as there are people on other platforms
that created own binary packets, it would be a nice idea to also
create redhat packages for cdrtools.

Let me give some background information:

cdrtools-3.0-final will be out within this week

SuSE includes packages for the original software since
September 2009 after a private person created these packages
for a longer time.

Since a while there are binary packages for Ubuntu created by
private people.

RedHat seems to be the only remaining white spot that misses
recent software.

Are you able to help with creating a binary package for RadHat?

(In reply to comment #5)
> The cdrkit "fork" is in conflict with the copyright law
> and cannot be distributed legally. The initiators
> of the fork have been informed in detail about the copyright
> problems but they are not interested in making the fork legal.

You don't seem to get the concept of free software. When you released cdrtools under the GPL, at that moment you gave permission to take the code and fork it as according to the license. Those versions are still under the GPL. You just not might not be able to call the fork "cdrecord"; that's why it's called cdrkit.

(In reply to comment #9)
> As you are not alone and as there are people on other platforms
> that created own binary packets, it would be a nice idea to also
> create redhat packages for cdrtools.

So do so.

> SuSE includes packages for the original software since
> September 2009 after a private person created these packages
> for a longer time.

A *private* person. It's not a part of SuSe.

> Since a while there are binary packages for Ubuntu created by
> private people.

Again, *private* people, not Ubuntu.

> RedHat seems to be the only remaining white spot that misses
> recent software.

No, you've just shown yourself that other distributions such as SuSE and Ubuntu do not include the CDDA-licensed cdrtools, either.

(In reply to comment #10)
> (In reply to comment #5)
> > The cdrkit "fork" is in conflict with the copyright law
> > and cannot be distributed legally. The initiators
> > of the fork have been informed in detail about the copyright
> > problems but they are not interested in making the fork legal.
>
> You don't seem to get the concept of free software. When you released cdrtools
> under the GPL, at that moment you gave permission to take the code and fork it
> as according to the license. Those versions are still under the GPL. You just
> not might not be able to call the fork "cdrecord"; that's why it's called
> cdrkit.

You don't get the concept of Open Source Software and you
don't get the concept of a legal system and the concept of
a legal pyramid. The Copyright law rules everything that is
not mentioned in a license and in addition it even forbids
some things to be ruled in a license in in a way that is in
conflict with the law.

> (In reply to comment #9)

[Some missunderstood comments removed]

I cannot comment things that you did completely missunderstand.

> > RedHat seems to be the only remaining white spot that misses
> > recent software.
>
> No, you've just shown yourself that other distributions such as SuSE and Ubuntu
> do not include the CDDA-licensed cdrtools, either.

Cdrtools is "collective work" that is _fully_ compliant with OSS.

The CDDL is a _fully_ accepted OSS license.

No license mix exist in the cdrtools: every single
project (work) is completely under a single license.

Even the GPL is an acepted OSS License and thus _needs_
to meet the rules in http://www.opensource.org/docs/definition.php
so the GPL _cannot_ forbid to ship different projects under
different licenses in the same tar ball.

And last: Suse included cdrtools in the official list of packets.

I have no idea why RedHat is not following the rules of the
OpenSource Initiative that is the only neutral and unbiased
entity in OSS rules.

Bart Verwilst (verwilst) wrote :

Wodim really is a very broken and obsolete package, while it should be providing an important part of the Linux 'desktop' experience. Please cut the licensing b/s and switch Ubuntu back to cdrtools, which actually _works_... Thanks!

Mårten Woxberg (maxmc) wrote :

Everything is explained in detail here:
http://cdrecord.berlios.de/private/linux-dist.html

André Cotte (acotte) wrote :

i've also had problems with CD and DVD burning with Ubuntu Now that I'm aware of this bad fork, I ask you to replace all these programs with the original.

I'm not shure if it is Ok to post this here, but Jörg Schilling (cdrtools Developer) and another User (Antiqua) from our Forum are building actual Ubuntu-Packages in this Thread, where you can download them:

http://forum.ubuntuusers.de/topic/kleines-projekt-mit-paketverwaltung-die-schil/5/

http://cid-29bdd7826332657e.office.live.com/browse.aspx/.Public/cdrtools-fedora?uc=4

fedora 13 x64 packages of cdrtools 3.0 adapted from opensuse srpm.
Note that I just chmod u+s'ed cdrecord binary so there might be security issues. I don't care about it though as I doubt it would be accepted into fedora.

Still wondering why someone keeps interpreting the license crap differently from rest of the world even after several years which caused all of the issue though :(

Hi Whistler,

could you please send your "spec file" or whatever is needed to build
a redhat rpm?

A friend is currently trying to use suse's build service to build
for all Linux target platforms (including redhat), but he seems to
have problems.

Created attachment 426139
spec file

the spec file is included in the srpm. I've attached it separately

anyways I do hope the GPL'ed stuff in cdrtools (specially mkisofs) can be relicensed to CDDL as well though, which would fix everything.

Just run rpmlint;
rpmlint cdrtools.spec
cdrtools.spec:5: W: non-standard-group Productivity/Multimedia/CD/Record
cdrtools.spec:32: W: non-standard-group Development/Libraries/Other
cdrtools.spec:47: W: non-standard-group Productivity/Multimedia/CD/Record
cdrtools.spec:65: W: non-standard-group Productivity/Multimedia/CD/Grabbers
cdrtools.spec:79: W: non-standard-group Hardware/Other
cdrtools.spec:90: W: non-standard-group Productivity/Multimedia/CD/Record
cdrtools.spec:104: W: rpm-buildroot-usage %build smake INS_BASE=/usr INS_RBASE=/ DESTDIR=$RPM_BUILD_ROOT MANDIR=man
cdrtools.spec:111: E: hardcoded-library-path in $RPM_BUILD_ROOT/usr/lib/lib*.a
cdrtools.spec:114: E: hardcoded-library-path in $RPM_BUILD_ROOT/usr/lib/profiled
cdrtools.spec:170: E: hardcoded-library-path in /usr/lib/siconv
cdrtools.spec:171: E: hardcoded-library-path in /usr/lib/siconv/*
cdrtools.spec:89: W: mixed-use-of-spaces-and-tabs (spaces: line 3, tab: line 89)
cdrtools.spec: W: invalid-url Source0: cdrtools-3.00.tar.bz2
0 packages and 1 specfiles checked; 4 errors, 9 warnings.

I guess after few changes specfile could be good. Nevertheless, regard the license problems, this one is not usable in fedora. No offence, just the statement due to fedora legal...

Unfortunately, Redhat legal does not follow usual rules for legality.

The real problem seems to be that Redhat does not like the CDDL but
does not tell this is the public (I have private statements from
Redhat employees that verify this statement).

Cdrkit is in conflict with the Copyright law and cannot be legally distributed.
Redhat distributes cdrkit ignoring legal background.

Cdrtools however is completely legal and completely following the rules
for all used licenses (including of course the rules of the GPL).

If Redhat employs real lawyers, Redhat is expected to know that
any interpretation of the GPL that is not ignoring the high-order
legal rules from:

1) http://www.opensource.org/docs/definition.php
    otherwise the GPL would not be an accepted free license

2) The US Copyright law

3) The European Copyright law

of course permits the "collective works" used in cdrtools.

See:
http://www.osscc.net/en/gpl.html
http://www.osscc.net/en/licenses.html
http://www.rosenlaw.com/Rosen_Ch06.pdf
http://www.rosenlaw.com/oslbook.htm
http://www.osscc.net/pdf/QualipsoA1D113.pdf

Note that the FSF is _very_ eager to define the GPL as a US-license
and not a contract, therefore the GPL is not permitted to redefine
the definition for a "derived work", see

http://www.copyright.gov/title17/92chap1.html#106

and the legal essay from Tomas Gordon mentioned above.

In Europe, the general conditions of business apply to the GPL
and make sure that for all doubtful cases in the GPL the
interpretation that is better for the licensee has to be applied.

It is a commonly accepted truth that linking two independend
works (like a GPLd program and a CDDLd library) just creates
a collective work permitted by the GPL. A derived work is only
if there was a modification of a significant threshold of
originality.

As you see, there are _many_ lawyers that in a legally correct
way explain why there is _no_ problem in cdrtools.

From Redhat legal and from the FSF, there is only FUD but not
a single legally useful statement.

Do you really like us to follow people who just spread FUD?

I understand that you (Roman) get payed from Redhat, so I
do not expect any useful statement from you in the public, but
I hope that you are still able to understand in private that your
employer is an actor in an anti-OSS campaign.

Note that _all_ works in cdrtools (except mkisofs) are pure CDDL
and that the work mkisofs just links against libraries that
are much older than mkisofs and used not only by mkisofs but by
many other programs. So there is doubtlessly a permitted
collective work.

Do we really need to warn people about Redhat's aparent anti OSS goals
or is there a chance that Redhat will act seriously in future?

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 12 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Still no proper fix for this in F14. Someone should bump up the version.

This is a problem that exists independent of the fedora release.

It will exist as long as Redhat continues to distribute the buggy fork.

Hello,

I have exactly the same problems, since its first inception cdrkit/wodim never worked for me, especially with dvds. Time has passed and now with mmc drives everywhere the compatibility has improved a bit but nevertheless most of the problems I had are still there.

So here are the packages I use in my Fedora / RHEL installations. The spec file is inside the specs directory.

http://www.kosgroup.com/simosimo/
http://www.kosgroup.com/simosimo/specs/
http://www.kosgroup.com/simosimo/RPM-GPG-KEY-slaanesh

A few things about the packages:

1- The Epoch goes to 10 to be newer than cdrkit "obsoletes" statements and to be newer than the old epoch 9 of cdrtools that's declared in cdrkit spec file; this avoids yum loops.
2- It provides "genisoimage", "icedax" and "wodim" for the package that require them (such as Anaconda and others). No symlinks to binaries are defined.
3- It does not use the alternative system cdrkit uses, in this case I found it useless.
4- There are no patches to modify behaviour or code, binary runs as root (btw, I personally don't use it as suid and never had a single problem).
5- There's a default configuration in the /etc/default/cdrecord file that points to /dev/cdrom as default, this is for obvious compatibility reasons with Fedora defaults. My package goes into the updates of a lot of computers and works as cdrkit replacement without configuration.
6- There's a conversion of utf8 in C and man files prior to building to correctly show "ö" instead of a "?".
7- If you check the spec with rpmlint there are a few errors but you can check inside the spec files why those "errors" are there.
8- It has been built with mock on both platforms, I've cut the changelog.

I'll be happy to mantain a yum repository for the latest Fedora and RHEL (x86_64 and i386) if someone gives me some little space (ftp://ftp.berlios.de/pub/cdrecord/ maybe?)

Regards,
--Simone

Thank you for your work!

Please note that it seems that k3b recently started to call mkisofs
with -sort sortfile by default and that this will trigger a bug in
mkisofs in case at least one of the files is > 4 GB.

I published a new version with a fix for this problem last wednesday:

ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-3.01a01.tar.bz2

BTW: future versions of cdrtools will include support for NLS and
implement a workaround for the problem that UTF-8 is not able to
display 8 bit UNICODE characters like ö correctly.

I'll fetch your packages in the evening and probably copy them to
berlios.

Created attachment 463520
Fix some rpmlint errors and warnings

I have played a bit with rpmlint and fix some errors and warnings. But, it needs a fix for rpmlint; see bug #657593.
There is still few errors which should be fixed - rpmlint run:
---
$ rpmlint cdrtools-devel-3.00-2.fc13.x86_64.rpm cdrecord-3.00-2.fc13.x86_64.rpm mkisofs-3.00-2.fc13.x86_64.rpm cdda2wav-3.00-2.fc13.x86_64.rpm btcflash-3.00-2.fc13.x86_64.rpm cdrtools-debuginfo-3.00-2.fc13.x86_64.rpm
cdrtools-devel.x86_64: E: description-line-too-long C Cdrtools is a set of command line programs that allows to record CD/DVD/BluRay media.
cdrecord.x86_64: E: description-line-too-long C A program to create hybrid ISO9660/JOLIET/HFS file systems with optional Rock Ridge attributes.
cdrecord.x86_64: E: binary-or-shlib-defines-rpath /usr/sbin/rscsi ['/usr/lib', '/opt/schily/lib']
cdrecord.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/readcd ['/usr/lib', '/opt/schily/lib']
cdrecord.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/cdrecord ['/usr/lib', '/opt/schily/lib']
cdrecord.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/scgskeleton ['/usr/lib', '/opt/schily/lib']
cdrecord.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/scgcheck ['/usr/lib', '/opt/schily/lib']
cdrecord.x86_64: E: non-readable /usr/sbin/rscsi 0711L
cdrecord.x86_64: E: non-standard-executable-perm /usr/sbin/rscsi 0711L
cdrecord.x86_64: E: non-readable /usr/bin/readcd 0711L
cdrecord.x86_64: E: non-standard-executable-perm /usr/bin/readcd 0711L
cdrecord.x86_64: E: setuid-binary /usr/bin/cdrecord root 04755L
cdrecord.x86_64: E: non-standard-executable-perm /usr/bin/cdrecord 04755L
mkisofs.x86_64: E: description-line-too-long C A program to create hybrid ISO9660/JOLIET/HFS file systems with optional Rock Ridge attributes.
mkisofs.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/isovfy ['/usr/lib', '/opt/schily/lib']
mkisofs.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/isodebug ['/usr/lib', '/opt/schily/lib']
mkisofs.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/mkisofs ['/usr/lib', '/opt/schily/lib']
mkisofs.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/devdump ['/usr/lib', '/opt/schily/lib']
mkisofs.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/isodump ['/usr/lib', '/opt/schily/lib']
mkisofs.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/isoinfo ['/usr/lib', '/opt/schily/lib']
mkisofs.x86_64: W: only-non-binary-in-usr-lib
cdda2wav.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/cdda2wav ['/usr/lib', '/opt/schily/lib']
cdda2wav.x86_64: E: non-readable /usr/bin/cdda2wav 0711L
cdda2wav.x86_64: E: non-standard-executable-perm /usr/bin/cdda2wav 0711L
btcflash.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/btcflash ['/usr/lib', '/opt/schily/lib']
6 packages and 0 specfiles checked; 24 errors, 1 warnings.
---

rpaths should be removed. Any hints how to do it (and not using chrpath)?
I'm not sure about permissions.
Is it safe to move /usr/lib files to /usr/share in mkisofs package?

Hello, thanks for feedback.

Didn't know I could run rpmplint on rpms, just thought it was meant for spec files. Here are the fixed packages (only for Fedora 14 atm):

http://www.kosgroup.com/simosimo/
http://www.kosgroup.com/simosimo/RPM-GPG-KEY-slaanesh

1. A rebuilt rpmlint with the fix you specified.

2. Rebuilt cdrtools rpms with most of the aforementioned warnings fixed:

[slaanesh@buko repo]$ rpmlint *3.00*
cdrecord.x86_64: E: setuid-binary /usr/bin/cdrecord root 04755L
cdrecord.x86_64: E: non-standard-executable-perm /usr/bin/cdrecord 04755L
cdrtools.src:96: E: hardcoded-library-path in $RPM_BUILD_ROOT/usr/lib/profiled
cdrtools.src:102: E: hardcoded-library-path in $RPM_BUILD_ROOT/usr/lib/lib*.a
cdrtools.src:150: E: hardcoded-library-path in /usr/lib/siconv/*
mkisofs.x86_64: W: only-non-binary-in-usr-lib
7 packages and 0 specfiles checked; 5 errors, 1 warnings.

A note on warnings:

- cdrecord.x86_64: I personally don't run cdrecord as root and never had a single problem, can we remove this or use File Capabilities?
- cdrtools.src: These are only used during the build phase, how are they marked as errors?
- mkisofs.x86_64: I don't know if I can move everything somewhere else; I'l look into it.

File Capabilities: https://fedoraproject.org/wiki/Features/RemoveSETUID

Regards,
--Simone

Added rpmlint and cdrtools packages for rhel5 at the same url.

All files that get 0711 need to be installed 04711 as they require root
privileges in order to be able to do certain tasks correctly.

Many applications _need_ RPATH as RPATH is the official method to let
applications find their libraries in case they are not in /usr/lib. If you
install all needed libs into /usr/lib, you may remove RPATH.

A typical command line for this case would be:

smake INS_BASE=/usr INS_RBASE=/ DESTDIR=/home/you/schilyutils/ STRIPFLAGS=-s
install CCOM=gcc RUNPATH=

The needed files for mkisofs are looked for in $INS_BASE/lib/siconv/
if you install the files in a different path, mkisofs will not find them and as
a result not work correctly at least for all calls that create Apple
extensions.

Thanks for the info, since we're using packages and libraries are strictly controlled it seems RUNPATH is not needed.

I made a simple

sed -i -e 's@-R$(INS_BASE)/lib -R/opt/schily/lib@@g' DEFAULTS/* DEFAULTS_ENG/*

in the spec file but sure passing the empty variable is much more cleaner.

I'll upload a correct package as soon as possible.

Regards,
--Simone

Here it is again, everything updated:

http://www.kosgroup.com/simosimo/

[slaanesh@buko repo.el5]$ rpmlint *3.00*
cdda2wav.x86_64: E: setuid-binary /usr/bin/cdda2wav root 04755L
cdda2wav.x86_64: E: non-standard-executable-perm /usr/bin/cdda2wav 04755L
cdrecord.x86_64: E: setuid-binary /usr/sbin/rscsi root 04755L
cdrecord.x86_64: E: non-standard-executable-perm /usr/sbin/rscsi 04755L
cdrecord.x86_64: E: setuid-binary /usr/bin/readcd root 04755L
cdrecord.x86_64: E: non-standard-executable-perm /usr/bin/readcd 04755L
cdrecord.x86_64: E: setuid-binary /usr/bin/cdrecord root 04755L
cdrecord.x86_64: E: non-standard-executable-perm /usr/bin/cdrecord 04755L
cdrtools.src:96: E: hardcoded-library-path in $RPM_BUILD_ROOT/usr/lib/profiled
cdrtools.src:102: E: hardcoded-library-path in $RPM_BUILD_ROOT/usr/lib/lib*.a
cdrtools.src:146: E: hardcoded-library-path in /usr/lib/siconv/*
mkisofs.x86_64: W: only-non-binary-in-usr-lib
6 packages and 0 specfiles checked; 11 errors, 1 warnings.

Is there a way to set the option at compile time to make mkisofs look for lib/siconv files somewhere else?

Fedora sets some permission on cd/dvd burners for the user that is logged into the first graphical console, I think that these permissions are enough to remove the setuid bit at least for commands that just require r/w access to the device. Is it correct?

[slaanesh@buko ~]$ ls -al /dev/sr* /dev/cd* /dev/dvd*
lrwxrwxrwx. 1 root root 3 Nov 29 08:37 /dev/cdrom -> sr0
lrwxrwxrwx. 1 root root 3 Nov 29 08:37 /dev/cdrw -> sr0
lrwxrwxrwx. 1 root root 3 Nov 29 08:37 /dev/dvd -> sr0
lrwxrwxrwx. 1 root root 3 Nov 29 08:37 /dev/dvdrw -> sr0
brw-rw----+ 1 root cdrom 11, 0 Nov 29 08:37 /dev/sr0
[slaanesh@buko ~]$ getfacl /dev/sr0
getfacl: Removing leading '/' from absolute path names
# file: dev/sr0
# owner: root
# group: cdrom
user::rw-
user:slaanesh:rw-
group::rw-
mask::rw-
other::---

Thanks,
--Simone

Cdrtools use an open development process. During the design of a new feature it is always possible to influence the implementation by making better proposals. This allows the best idea to win. The design of libsiconv happened in May 2007 and proposing to use $DEST_DIR/lib/share/siconv before the end of Summer 2007 did most likely have a 100% chance to get accepted.

Now the implementation exists since 3.5 years and it seems to be too late to modify a path that exists since a long time on various platforms. Since June 2010, there is cdrtools-3.00-final and this creates a need to maintain binary compatibility.

Regarding the need for suid root:

The permission of the files mentioned above has little influence on the behavior of cdrtools. There are other reasons that require root privileges. There have been some people that in the past tried to remove related error messages in the code. The result of such changes has been unspecific late abortions that make it impossible to debug the related problem.

In theory, Linux could be enhanced to permit a root-less installation of cdrtools. This root-less feature is possible on Solaris since at least year 2004 and since then, I am trying to get in contact with Linux distributions to add the needed features. Once a notable Linux distribution will add the needed userland support for fine-grained privileges as a non-deselectale part of the base system, I see nothing that prevents to create a root-less cdrtools installation for Linux as well. For now, there is no way to avoid suid-root for cdrtools on Linux.

Regarding file capabilties...

This may be a way to avoid suid root. The URL you mentioned however does not point to the needed information:

So far, I am only aware of a Linux distro from Turkey that supports them. What is the state in Redhat? Is it a base feature that cannot be removed from the system?

Are the support-commands always present?

If the feature is not in libc, is the related library always present?

Is is easy to set up a VirtualBox with an installation that allows to check the features on whether they support everything that is needed?

If the basic constraints are met, it may be something that could be added next year.....

(In reply to comment #30)
> Regarding file capabilties...
>
> This may be a way to avoid suid root. The URL you mentioned however does not
> point to the needed information:
>
> So far, I am only aware of a Linux distro from Turkey that supports them. What
> is the state in Redhat? Is it a base feature that cannot be removed from the
> system?
Just nit picking - Not Redhat, but Fedora. And I don't know.
>
> Are the support-commands always present?
Which commands? When?
>
> If the feature is not in libc, is the related library always present?
You can specify needed library in spec file (for building). For runtime, rpm and yum solves dependencies, libraries are autorequired and installed with package.
>
> Is is easy to set up a VirtualBox with an installation that allows to check the
> features on whether they support everything that is needed?
I don't know.
>
> If the basic constraints are met, it may be something that could be added next
> year.....

I checked the content of the RPMs on Solaris and it seems to be OK. I do not
have a RedHat system running here.

Hello,

I'mm currently in a job transfer and cannot look at it, I'll check how difficult is to add support for libcap-ng to cdrtools.

The policycoreutils_setuid.patch is pretty neat, I'll check the capabilities along with the pfexec settings that can be done on Solaris for cdrtools and see if there's a match.

http://people.fedoraproject.org/~dwalsh/policycoreutils_setuid.patch

According to the %caps line in the patch this seems pretty easy to do, I'll check it on Thursday back home.

Regards,
--Simone

A few years ago, I checked the Linux caps and it seems that except for the needed SCSI settings that seem to be unclear for me on Linux, there is a 1:1 match with the other privileges used with pfexec on Solaris.

In any case, cdrecord, cdda2wav and readcd all need to actively maintain the capabilities at runtime as they need to give up "file_dac_read" after opening the SCSI devices. For this reason, there is a need for similar support code as already present for Solaris. If this would not be done, cdrecord could burn any local file (regardless of the calling user) which is not intended.

Mantas Kriaučiūnas (mantas) wrote :

It seems, that Jörg Schilling recommends to use cdrtools from ppa:brandonsnider/cdrtools repository, see https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/556595/comments/4 :

Schily wrote on 2010-04-07:
> I recommend you to first upgrade to recent original software:
> http://cdrecord.berlios.de/
> https://launchpad.net/~brandonsnider/+archive/cdrtools

I've checked cdrtools_3.00-0ubuntu1~ppa1 from ppa:brandonsnider/cdrtools sources packaging and can confirm, that these packages are original cdrtools-3.00 packages without any patches applied.

Also I copied cdrtools-3.00 from ppa:brandonsnider/cdrtools to main Baltix GNU/Linux repository - ppa:baltix-members/ppa

Changed in baltix:
assignee: nobody → Mantas Kriaučiūnas (mantas)
importance: Undecided → Medium
status: New → In Progress

BTW: Could you please pack cdrtools-3.01a01?

It fixes a bug that has been recently unveiled by k3b.

Hello, I've been on holiday, here are the rpms.

http://www.kosgroup.com/simosimo/

I made a %global define at the beginning of the spec file, by setting the alpha version and bumping the version the Source URL and other pointers gets updated.

I can also supply 32 bit builds built with mock if someone needs them.

btw, I'm no programmer but I tried anyway to add libcap-ng to cdrecord. Of course this comes without success, I was able to link cdrecord to libcap-ng.so.0 but didn't get the capabilities, probably there's the need for some other patch.

If someone wants to add support I'll be happy to test it on RHEL and Fedora. According to the documents it should just be a matter of adding something like tis:

#ifdef HAVE_LIBCAP_NG
#include <cap-ng.h>
#endif

#ifdef HAVE_LIBCAP_NG
        capng_clear(CAPNG_SELECT_BOTH);
        capng_updatev(CAP_IPC_LOCK, CAPNG_EFFECTIVE|CAPNG_PERMITTED, CAP_SYS_ADMIN, CAP_SYS_NICE, -1);
        capng_apply(CAPNG_SELECT_BOTH);
#endif

libcap-ng is not included yet in RedHat Enterprise Linux, just Fedora. RHEL 5+ has just libcap.

I can make a conditional build for rhel 5/6 and Fedora in the same rpm if someone provides the patches.

Regards,
--Simone

Hello, just re-uploaded the packages for a typo.

I just noticed that setting an empty RUNPATH doesn't seem to work anymore for cdda2wav, here's the output of rpmlint:

cdda2wav.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/cdda2wav ['/usr/lib', '/opt/schily/lib']
cdda2wav.x86_64: E: setuid-binary /usr/bin/cdda2wav root 04755L
cdda2wav.x86_64: E: non-standard-executable-perm /usr/bin/cdda2wav 04755L
cdrecord.x86_64: E: setuid-binary /usr/sbin/rscsi root 04755L
cdrecord.x86_64: E: non-standard-executable-perm /usr/sbin/rscsi 04755L
cdrecord.x86_64: E: setuid-binary /usr/bin/readcd root 04755L
cdrecord.x86_64: E: non-standard-executable-perm /usr/bin/readcd 04755L
cdrecord.x86_64: E: setuid-binary /usr/bin/cdrecord root 04755L
cdrecord.x86_64: E: non-standard-executable-perm /usr/bin/cdrecord 04755L
mkisofs.x86_64: W: only-non-binary-in-usr-lib
mkisofs.x86_64: W: manual-page-warning /usr/share/man/man8/isoinfo.8.gz 33: a special character is not allowed in a name
6 packages and 0 specfiles checked; 9 errors, 2 warnings.

Setting an empty RUNPATH works perfectly for me. What make program do you use?

If you have the standard ELF utilities installed, you can call:

dump -Lv cdda2wav

to get a list that includes the RUNPATH if present.

BTW: there seems to be something wrong in the check program as it gives a strange complaint about isoinfo.8

Sorry no elfutils here, the machines I currently use are in production. Running mock avoids me installing anything that relates to development but have all dependencies and checks controlled in a chroot environment.

I made a few test, with 3.00 setting an empty RUNPATH doesn't set rpaths, in 3.01a01 an empty RUNPATH generates the above situation. Putting again the following in the spec file solves the problem:

sed -i -e 's@-R$(INS_BASE)/lib -R/opt/schily/lib@@g' DEFAULTS/* DEFAULTS_ENG/*

I've updated the packages again with that and the isoinfo.8 encode.

http://www.kosgroup.com/simosimo/

Regards,
--Simone

I did just run a test on Linux and I cannot reproduce your problem. Calling:

smake RUNPATH=

definitely does not use any -R option for the final link commands.

Could you explain what's about isoinfo.8?

This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.

Bart Verwilst (verwilst) wrote :

Ok great.. so when do we - after more than 2 years - see these packages FINALLY in Ubuntu?

Simone, it seems your link gives a 404 now. Any plans to re-post your packages, or repackage for Fedora 15?

Hello,

I've put again 3.01a05 signed packages for fc15/el5 at the same link:

http://www.kosgroup.com/simosimo/

Unfortunately in a month I will not be able to access that site anymore, so if someone could offer some space I'd be happy to mantain packages for el5/6 and fc14/15.

Regards,
--Simone

you of course could start a project at berlios.de

I still don't understand why RedHat distributes 6 year old software that
misses 50% of the features of a recent version? Cdrkit in addition is of
dubious legality while the original software hat positive legal reviews
from several lawywers.

Is RedHat really interested in actively supporting anti-OSS campaigns?

Simone, thanks for the updated package. Maybe you can package these for rpmfusion? They take packages with a variety of licences, so if the issue for fedora is just the license then shouldn't this be fine?

Jörg, thanks for all the work on cdrtools. I'm genuinely curious in the following, not trying to troll. Now that Sun has been swallowed up by Oracle, which I think we can all agree really is anti-OSS in that they have effectively killed a number of open source projects since buying Sun, why not switch your code back to GPL? Wouldn't that at least be a good test of the veracity of Red Hat/Fedora/Debian claims that they truly believe the CDDL is an incompatible license?

I know this isn't a place for a long discussion, so I'm just going to bow out now.

The change towards the CDDL was not related to Sun but was a reaction
on an anti-OSS anti-GPL act from Debian.

At a time when cdrecord was 100% GPL (in Summer 2005), Debian started
to claim that there was a license change in cdrecord although absolutely
nothing was changed in cdrecord. Debian claimed there was a GPL
violation as a result of a non-existent and just alleged license change.

At that time, people could have given help to me.....

Nobody helped. In special, the FSF did not help against this anti-OSS
anti-GPL act from Debian.

As a reaction on the attacks from Debian and as a restult on the missing
help from others, I decided to change the license so Debian could no
longer claim that there was a GPL license violation as there was no
GPL anymore in cdrecord. After the license change on May 15 2006,
cdrecord was 100% CDDL. Debian continued to claim a GPL violation
in cdrecord. So it is obvious that Debian is not interested in any
kind of relation to reality.

As a result, the FSF did loss one of the top 10 GPL OSS projects in the world.
Why do they now weep bitter tears on the lost project?

As the reason for the license change still exists, why do you believe that
another license change would help?

The current situation is a result from the attacks from Debian and a result
from the missing help from the FSF and from the OSS community.

Jörg, I have been following this since the beginning. I still do not understand every single bit of the story but I can say that people have been doing strange and also stupid things. Even worse, people have tried to discredit you personally for whatever reasons.

In the end, the situation is bad for everyone, especially users, most of which don't even care about the license and just want their CD recording software to work. But companies like Red Hat have to care about licenses. Not being a lawyer, I cannot judge the legal aspect myself. Personally, I don't really have a problem with the CDDL, but I have to give credit to Red Hat who have been around for a long time and have made a lot of correct decisions (even if this particular one may not be the correct one...)

So, would another license change help? I can't tell. But I know the best thing for users would be to get cdrecord 3.x shipped by default in Fedora, Red Hat, etc. This should be the goal and I would advice all parties involved to get over the problems of the past. Red Hat legal should have another look and propose whatever license they think would meet their needs... I am sure that whatever license that would be, it would be fine for cdrecord to use (provided a license change is possible). Anyway, a first step would be to declare willingness to change license.

It is obvious that RedHat does not care about legality.

Cdrkit is of questionable legality - RedHat is informed but RedHat
does not care and ships cdrkit.

During the past 10 Years, GNU VCDimager was illegal and based on
a Copyright violation (this was recently confirmed by Suse lawyers).
The FSF and RedHat have both been informed - nobody cared about the
legality. With the help from Suse, we have been able to fix this
two months ago.

On the other side, the Sun legal department made a legal review
with the original cdrtools and confirmed that there is no problem.
Early this year, Orcale made a second legal review with a different
background with Oracle lawyers and confirmed that there is no problem.

RedHat legal is unfortunately just trolling and denying a fact based
discussion.

Those who checked legality distribute the original software and do
not distribute cdrkit. Why does RedHat behave different?

If there really was any legal argument against cdrtools, it would be
easy to publish the argument and to have a fact based discussion with
various other lawyers. The fact that Redhat does not give any argument
against cdrtools confirms that RedHat legal has no legal argument
against cdrtools.

Ask RedHat for the real reasons for their decision, it cannot be
based on a legal fact.

Bart Verwilst (verwilst) wrote :

Another 6 months have passed without any progress here.. Just checking in, showing that somebody still cares about this.. *sigh*

Ben M. (bmhm) wrote :

If there were source-only-packages (i.e. no pre-built binaries), there would be no licencing-problems. Because of this, Gentoo can provide (source-)packages without violating any licences[1].

Also, Canonical might want to spend some money on this issue as Oracle (former: SUN) did to prove whether there is a licence violation in distributing binaries or not. See #7.

[1] http://de.wikipedia.org/wiki/Cdrtools

Schily (schilling-fokus) wrote :

Nobody is violating a license for distributing cdrtools either in source or in binary form.

If you believe the people who claim that there is a problem, then Ubuntu as a whole would be undistributable as Ubuntu is full of similar constructions.

I had a discussion with Till Jaeger (the most well known OSS lawyer) and he confirmed that under the most pessimistic assumptions (that come from people only who do not own Copyright on cdrtools and thus are irrelevant anyway) you may need to use dynamic linking.....to avoid any problems.

But let us look at the current situation: Ubuntu is distributing cdrkit that is definitely in conflict with the Copyright

http://www.gesetze-im-internet.de/urhg/__14.html because it intentionally introduced bugs to attack my reputation

http://www.gesetze-im-internet.de/urhg/__13.html because Copyright signs have been removed

It seems that it is Ubunu's intention to be in conflict with the law - is this the reason why Ubuntu does not like to distribute a legal solution based on the original sources?

Ben M. (bmhm) wrote :

Jörg, I did not want to propose the idea that there actually are licencing problems. I just wanted to point out that distributing the source only would *definitely* have no licencing problems at all - regardless of Debian's understanding of licence compatiblity.

Would be a win-win for all of us, wouldn't it?

Schily (schilling-fokus) wrote :

If Ubuntu did not distribute the illegal cdrkit, I would fully agree with you.

Please note that I as the Copyright holder also need to admonish people or companies that do not follow a legal path and Ubuntu is in not on a legal path because they publish cdrkit.

On the other side, users like binary installs....

Bart Verwilst (verwilst) wrote :

Schily, can't you as copyright holder 'sort' this licensing stuffs once and for all, to finally get Ubuntu in the 21st century wrt to cd burning ( even though cd burning is becoming sooo 90's by itself .. ;) ) cdrkit just froze on me again while trying to burn an audio cd.

Schily (schilling-fokus) wrote :

I have no idea how I could change things since the original software has no license
problems.

Ubuntu just seem to ignore facts and instead ships dead software that even has
problems with legality.

Ubuntu obviously is not independent and is no more than a vassal of Debian that
verified that they are not interested in OSS and did not start shipping cdrtools even
though they gave the promise to do so to Simon Phipps.

Do you have an idea (an explicit proposal) on how to change this situation?

Changed in linuxmint:
status: New → Incomplete
importance: Undecided → Medium
assignee: nobody → Clement Lefebvre (clementlefebvre)
milestone: none → lmde-upcoming

I'm marking this as affecting Linux Mint and I'd be happy to chat with you Schily to understand the problem fully and to see if we can solve it. Feel free to contact me by email, or directly via IRC at #pimpmymint on irc.spotchat.org.

If after this discussion we decide that we want to fix this issue in Linux Mint we'll try to convince Debian first in an attempt to let it flow from upstream to all derivatives.

Mantas Kriaučiūnas (mantas) wrote :

Hi Clement,

Please inform us (Baltix GNU/Linux operating system developers) here about
the results of your conversation with Schily.
We also wanna to include original up-to-date cdrecord instead of old and
buggy fork wodim.
It would be nice to use the same cdrecord package for Linux Mint and Baltix GNU/Linux

On Sat, Sep 03, 2011 at 03:36:10AM -0000, Clement Lefebvre wrote:
> I'm marking this as affecting Linux Mint and I'd be happy to chat with
> you Schily to understand the problem fully and to see if we can solve
> it. Feel free to contact me by email, or directly via IRC at #pimpmymint
> on irc.spotchat.org.
>
> If after this discussion we decide that we want to fix this issue in
> Linux Mint we'll try to convince Debian first in an attempt to let it
> flow from upstream to all derivatives.

--
Labanaktis/Good luck,
Mantas Kriaučiūnas Jabber ID: <email address hidden> GPG ID: 43535BD5
Public organization "Open Source for Lithuania" - www.akl.lt
Geriausios biuro programos verslui ir namams - http://openoffice.lt
Prekyba naujais ir atnaujintais kompiuteriais su Linux OS - http://tinklas.eu
Naudok Baltix GNU/Linux sistemą savo kompiuteryje - http://baltix.lt

Schily (schilling-fokus) wrote :

Hi Mantas,

what kind of discussion do you believe is necessary?

Cdrtools is legal OSS and thus there is no need for a contract to use it.

As Debian did change seveal users of cdrtools with the intention to make it hard to replace cdrkit by the original software, you may need to remove these changes in order to get a usable overall system.

BTW: I tried to see Clement in the IRC to no avail. It may be a good idea to have a dicsussion via mail.

Mantas Kriaučiūnas (mantas) wrote :

Hi Schily,

I don't need any discussion, I just don't have enough time to maintain
cdrecord package, so, I simply need good cdrecord package + bugreporters
and deb package maintainers, which can help to fix major problems :)

On Sun, Sep 04, 2011 at 01:32:41PM -0000, Schily wrote:
> what kind of discussion do you believe is necessary?
>
> Cdrtools is legal OSS and thus there is no need for a contract to use
> it.
>
> As Debian did change seveal users of cdrtools with the intention to make
> it hard to replace cdrkit by the original software, you may need to
> remove these changes in order to get a usable overall system.
>
> BTW: I tried to see Clement in the IRC to no avail. It may be a good
> idea to have a dicsussion via mail.

--
Labanaktis/Good luck,
Mantas Kriaučiūnas Jabber ID: <email address hidden> GPG ID: 43535BD5
Public organization "Open Source for Lithuania" - www.akl.lt
Geriausios biuro programos verslui ir namams - http://openoffice.lt
Prekyba naujais ir atnaujintais kompiuteriais su Linux OS - http://tinklas.eu
Naudok Baltix GNU/Linux sistemą savo kompiuteryje - http://baltix.lt

@Schily: I should be on #pimpmymint (irc.spotchat.org) most of the time. If I'm not there, you can contact oscar799 and she should be able to get in touch with me. I'm working on the code at the moment so I tend to turn the IRC off (too distracting), sorry for my absence :) I'd like to chat with you, because it's not only about the technical side of things, there's a whole political/social element to it and so rather than asking questions by email, I'd love to be able to have an interactive chat and a proper discussion with you. Do you spend time on freenode otherwise? If so what's your nick over there?

@Mantas: I'll update the bug report to let everyone know. Ideally I'd like the solution to be the same across all Debian derivatives, especially for a component of this importance.

Changed in linuxmint:
status: Incomplete → Confirmed

Well, I had a conversation with Schily. As far as the political/social aspects go, I'm satisfied with his explanations and I strongly feel he needs our support. As much as possible, we should push to get the original cdrecord, mkisofs, cdda2wav... into Debian.

I'm still not at ease with the technical side of things and I don't fully comprehend the extent of the problem.. how wide it is, how many packages it affects and how many use cases can be impacted by possible regressions.

I need to know more about Brasero, libburn etc.. so I'm hoping we'll have another chat about these.

The status of packages like "wodim" (aka cdrecord), "genisoimage" (aka mkisofs), "icedax" (aka cdda2wav), who are not only based on the 2004 codebase of the tools they renamed, but apparently filled with patches the original developer finds buggy ... these, in my opinion, need to be dropped.

I'll be happy to talk about this on the Debian derivatives mailing list in an effort to get Debian to tackle the problem upstream, so it can flow downstream towards LMDE, Debian derivatives, Ubuntu and Linux Mint.

If we don't get anything done upstream, we'll need to assess how this would affect compatibility and maintenance for us. At the very least we could maintain Jorg's current codebase and make it easier for Mint/LMDE users to switch to it.

So in brief, I can't guarantee anything yet, but I can confirm the problem and the fact that this needs a solution.

Schily (schilling-fokus) wrote :

I did not publish a new cdrtools release since june even though there is
new code (e.g. available in the "schily" source consolidation).

If you like to make a binary package, please contact me so I can make a new
cdrtools source release and give some advise on how to compile things the
best way.

Schily (schilling-fokus) wrote :

A new cdrtools version has been released, if you like to create a binary package, please use this one.

BTW: Meanwhile, the only currently known bugreport has been verified to be a false alarm.

For:
 https://bugs.kde.org/show_bug.cgi?id=257241

the reporter send the CLI parameter to repeat the call and I cannot see any problem here.

Bart Verwilst (verwilst) wrote :

Any update? :)

Schily (schilling-fokus) wrote :

Clement told me that he likes to approach Debian at <email address hidden> but I did not hear from him since 3 weeks.

Hello,

I'm still building rpms with the latest versions of cdrtools for el5, el6 and fc15.

Sorry to ask here, but how can I push the rpms on repos.fedorapeople.org? I already have an account @fedorapeople.org but the instructions say I have to apply to a group before having the rights to upload.

Apart from cdrtools I have other rpmlint/mock built packages that I would like to host somewhere.

Thanks,
--Simone

(In reply to comment #49)
> Sorry to ask here, but how can I push the rpms on repos.fedorapeople.org? I
> already have an account @fedorapeople.org but the instructions say I have to
> apply to a group before having the rights to upload.
>
> Apart from cdrtools I have other rpmlint/mock built packages that I would like
> to host somewhere.

Unfortunately, I can't give you an answer, I've no experiences with that.

Generally, you can ask on fedora list, but please mind that "Do not distribute anything on fedorapeople.org that Fedora itself cannot distribute for legal reasons. Nothing on the ForbiddenItems list or otherwise non distributable by Fedora." [1], so cdrtools shouldn't be included in repos.fedorapeople.org, AFAIK.

[1] http://fedoraproject.org/wiki/Infrastructure/fedorapeople.org#Allowable_content

Well, according to:

http://fedoraproject.org/wiki/Licensing#Good_Licenses

my understanding is that CDDL programs are fine for distributing inside Fedora and that licenses identified as "good" could be in the main repositories as well. CDDL is also a valid license value when checking packages with rpmlint.

It's funny because this debate about the license of cdrtools shouldn't even exist, but I'm not there to start a flame.

Do you know which list among the many provided of the Fedora Project is the right one?

Thanks,
--Simone

(In reply to comment #51)
> my understanding is that CDDL programs are fine for distributing inside Fedora
> and that licenses identified as "good" could be in the main repositories as
> well. CDDL is also a valid license value when checking packages with rpmlint.

You're right that CDDL itself isn't problem, but combination of CDDL and GPL code seems to be (see http://www.redhat.com/archives/fedora-legal-list/2009-July/msg00000.html).

> Do you know which list among the many provided of the Fedora Project is the
> right one?

I'd go for the devel list.

There is no combination of CDDL and GPL in cdrtools.

Cdrtools is a set of more than 25 separate projects (or "works" when using the wording of lawyers). Each of the different projects is completely under a single license only. 4 projects are still under GPL, 2 projects are under the BSD license, the rest is CDDL.

A detailed decription is available in the file COPYING, but it seems that the linux distributors that support the attacks from Debian did never read that file...

BTW: The whole dispute was initiated by by some unfriendly people from Debian and was nothing but a red herring to distract from the real problem: the Debian packetizer changed and the new packetizer that was unwilling to collaborate.

And in case you don't know, the license change was a reaction on the attacks against the project. If people did like to have everything stay unter GPL, these people would need to have supported me in 2005, but this did not happen.

Anyway, Linux distributions are made from many projects under many different licenses and nobody reported a problem resulting from that aggregation.

Jörg, thanks for explanation how you understand that. But we just have to follow our lawyers' status.

I am not sure what you like to tell me with this text....

There is not is single lawyer that could find any legal problem in the cdrtools package, so what problem do you have?

Please note that the mail you quoted in your previous post is from a person who is not willing to expose himself with the problems. The quoted mail contains nothing than a bunch of unlrelated blabla. (*)

If one of your lawyer did really see a problem, why does he keep it secret? Why did companies like Sun that really asked laywers made a decission against cdrkit and pro cdrtools?

What redhat is doing with cdrtools is called pointless bashing, as there was never a single legal argument from redhat against cdrtools. Do you really like to continue this way?

RedHat lost it's credability with the way it deals with cdrtools. It would be nice to see this changed and it would be nice if we could start a fact based discussion. Are you ready for a fact based discussion?

*) redhat e.g. closed many still valid bug reports against cdrkit; arguing with the number of bugs in the redhat buglist is childish. In special if you watch related discussions in the net where more and more people inform others that they needed to go to cdrtools in order to be able to work again.

Download full text (6.4 KiB)

I've seen that there's a06 available, but I'm not able to build it.
I just swapped the version in the spec file and tried to rebuild but it seems to get stuck in a loop:

EBUG: make[1]: Entering directory `/builddir/build/BUILD/cdrtools-3.01/btcflash'
DEBUG: ==> MAKING SYMLINKS in .
DEBUG: ==> MAKING DIRECTORY "OBJ/x86_64-linux-cc"
DEBUG: ==> MAKING SYMLINKS in .
DEBUG: ==> MAKING SYMLINKS in .
DEBUG: ==> MAKING SYMLINKS in .
DEBUG: ln: failed to create symbolic link `./cd_misc.c': File exists
DEBUG: ln: failed to create symbolic link `./cd_misc.c': File existsln:
DEBUG: failed to create symbolic link `./io.c': File exists
DEBUG: ln: failed to create symbolic link `./io.c': File exists
DEBUG: cp: `../cdrecord/cd_misc.c' and `./cd_misc.c' are the same file
DEBUG: cp: `../readcd/io.c' and `./io.c' are the same file
DEBUG: ln: failed to create symbolic link `./misc.c': File exists
DEBUG: ln: failed to create symbolic link `./misc.c': File exists
DEBUG: cp: `../cdrecord/misc.c' and `./misc.c' are the same file
DEBUG: ln: ln: failed to create symbolic link `./scsi_cdr.c': File exists
DEBUG: failed to create symbolic link `./scsi_cdr.c' ==> MAKING DEPENDENCIES "OBJ/x86_64-linux-cc/misc.d"
DEBUG: : File exists
DEBUG: ln: failed to create symbolic link `./scsi_scan.c': File exists
DEBUG: ln: failed to create symbolic link `./scsi_scan.c': File exists
DEBUG: cp: `../cdrecord/scsi_cdr.c' and `./scsi_cdr.c' are the same file
DEBUG: ==> MAKING DEPENDENCIES "OBJ/x86_64-linux-cc/skel.d"
DEBUG: cp: `../cdrecord/scsi_scan.c' and `./scsi_scan.c' are the same file
DEBUG: make[1]: Leaving directory `/builddir/build/BUILD/cdrtools-3.01/btcflash'
DEBUG: make[1]: Entering directory `/builddir/build/BUILD/cdrtools-3.01/btcflash'
DEBUG: ==> MAKING DEPENDENCIES "OBJ/x86_64-linux-cc/scsi_scan.d"
DEBUG: ==> MAKING DEPENDENCIES "OBJ/x86_64-linux-cc/scsi_cdr.d"
DEBUG: ==> MAKING DEPENDENCIES "OBJ/x86_64-linux-cc/cd_misc.d"
DEBUG: ==> MAKING DEPENDENCIES "OBJ/x86_64-linux-cc/io.d"
DEBUG: make[1]: Leaving directory `/builddir/build/BUILD/cdrtools-3.01/btcflash'
DEBUG: make[1]: Entering directory `/builddir/build/BUILD/cdrtools-3.01/btcflash'
DEBUG: ==> COMPILING "OBJ/x86_64-linux-cc/skel.o"
DEBUG: ==> COMPILING "OBJ/x86_64-linux-cc/io.o"
DEBUG: ==> COMPILING "OBJ/x86_64-linux-cc/cd_misc.o"
DEBUG: ==> COMPILING "OBJ/x86_64-linux-cc/scsi_cdr.o"
DEBUG: ==> COMPILING "OBJ/x86_64-linux-cc/scsi_scan.o"
DEBUG: ==> COMPILING "OBJ/x86_64-linux-cc/misc.o"
DEBUG: ==> LINKING "OBJ/x86_64-linux-cc/btcflash"
DEBUG: make[1]: Leaving directory `/builddir/build/BUILD/cdrtools-3.01/btcflash'
DEBUG: ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/cdda2wav"
DEBUG: make[1]: Entering directory `/builddir/build/BUILD/cdrtools-3.01/cdda2wav'
DEBUG: ../RULES/local.cnf:43: OBJ/x86_64-linux-cc/Inull: No such file or directory
DEBUG: ../RULES/local.cnf:44: OBJ/x86_64-linux-cc/local.cnf: No such file or directory
DEBUG: ==> MAKING DIRECTORY "OBJ/x86_64-linux-cc"
DEBUG: ==> MAKING SYMLINKS in .
DEBUG: ==> MAKING SYMLINKS in .
DEBUG: ==> MAKING SYMLINKS in .
DEBUG: ==> MAKING SYMLINKS in .
DEBUG: ln: failed to create symbolic link `xxzzy.345': File exists
DEBUG: ln: ln: failed to creat...

Read more...

I have no idea where the "DEBUG:" messages are from, but it looks like you are using a buggy "make" program, or you did modify the source tree in an inapropriate way?

gmake has several well known bugs that even have been accepted by it's maintainer in 1998 already, but these bugs are still not fixed. It was always a problem to support make programs like gmake that do not behave as documented, but if you ignore the incorrect warnings from gmake and if you are OK with the fact that gmake may not stop it's work when an error is encountered, you still should be able to use gmake if you are on Linux (there are many other OS where gmake compiles fine but does not work at all).

I recommend to use "smake" as smake is known for not having problems and as smake works on more platforms than gmake.

The easiest way to start is to download the complete set of "schily" sources from:

ftp://ftp.berlios.de/pub/schily/

If you call "gmake" on that source tree, it will first build a bootstrap "smake" (using shell scripts) and then use that bootstrap smake to compile the rest.

If your problems stay with the official compile method, we need to have a closer look at what you are doing. cdrtools-3.01a06 as well as schily-2011-08-29 are known to compile without problems on a sane Linux installation.

Hint: if you like to remove possible official compile results, call "./.clean".

(In reply to comment #55)
> RedHat lost it's credability with the way it deals with cdrtools. It would be
> nice to see this changed and it would be nice if we could start a fact based
> discussion. Are you ready for a fact based discussion?

I believe you that a fact based discussion can solve the problem. Nevertheless, I'm not the right person who to discuss with and this is not the right place to
discuss, since bugzilla is a bug tracking tool. If you really need to start a
new discussion, fedora legal list seems to be a better place to begin.

I have successfully rebuild a f14 x86_64 packages using simosimo's f15 ones (cdrtools-3.01-a05.1.fc15.src.rpm) and update tarballs from schilly site (3.01-a06...)

Honza: That list is run by an unfriendly person who is unwilling to a fact based discussion and who blocked me from that list.

As the person in question did not yet send any legally valid claim, it may be better to get a direct contact with a redhat lawyer.

Giandomenico: do these rpms contain the build scripts, so I could see where problems may be caused?

Thanks, it worked. I changed the spec file from:

export CFLAGS="$RPM_OPT_FLAGS"
make GMAKE_NOWARN=true INS_BASE=/usr INS_RBASE=/ MANDIR=man %{?_smp_mflags} \
        COPTX=-g LDOPTX=-g RUNPATH=

to:

./.clean
export CFLAGS="$RPM_OPT_FLAGS"
make GMAKE_NOWARN=true INS_BASE=/usr INS_RBASE=/ MANDIR=man %{?_smp_mflags} \
        COPTX=-g LDOPTX=-g RUNPATH=

and that indeed fixed the problem, I built succesfully a06. It seems there's
some leftover into the original tarball.

I tested RHEL6 i386/x86_64 and Fedora 15/16 i386/x86_64, in RHEL6 I don't get the problem, it seems to be related to Fedora 15+.

The "DEBUG" prefix can be ignored, is just the verbose output of mock, the
Fedora/Redhat tool that is used to create a clean & complete chroot environment
for building packages.

The address space at kosgroup.com/* will be deleted soon, I no longer work for that company.

Giandomenico; are you able to host the packages? I have new spec files with added fixes from new versions of rpmlint.

Regards,
--Simone

There is no leftover in the original tarball, it seems that you added some files that do not belong there.

If you like, you can also host the data on berlios.

I've not added anything, I just changed the %define from "a05" to "a06" at the top of the spec file.

To force cdrecord, readcd and mkisofs higher priority in Brasero in respect to
other plugins run the following as your user:

dconf write /apps/brasero/plugins/cdrecord/priority 1
dconf write /apps/brasero/plugins/mkisofs/priority 1
dconf write /apps/brasero/plugins/readcd/priority 1

I guess that at least in my case the reason for failed dvd writing is libburnia.

dvd+rw-tools by command line works fine as cdrecord with all the {DL-}DVDs I
throw to it and wodim/genisoimage are replaced by my packages so the culprit is probably there.

I'll check if I still get errors with Brasero.

The tarball does not contain incorrect or superfluous files and it compiles out of the box on Linux.

If you did have problems with compiling, some of your actions must have created the files in question.

BTW: some of the bug-reports I received let me asume that gmake under some conditions ignores existing rules. Ignoring rules may cause problems later on.

Well, the "./.clean" has nothing to do with the fix, I incurred in the error of a06 again while building for other archs.

The solution for fixing the build on my systems was removing "%{?_smp_mflags}", the multiple jobs to make.

Regards,
--Simone

Mail referred to https://www.redhat.com/archives/fedora-legal-list/2009-July/msg00000.html is the Fedora legal position on cdrkit. If you have any further considerations, bring it to the legal mailing list. Bugzilla isn't the right place for such discussions.

Bart Verwilst (verwilst) wrote :

Clement, have you been able to get in touch with the Debian guys?

jaymzw (jaymzw) wrote :

This issue has affected me for a long time, I'd be very happy to see it resolved. The cdrkit fork is unmaintained garbage and has produced many coasters. It's a pain to have to reinstall cdrtools manually with every release.

Can the dependencies on cdrkit be removed while the licensing issues are being sorted out so that cdrkit can be properly uninstalled without removing all the CD burning tools?

cesare (wtoro00) on 2012-01-16
Changed in cdrtools (Ubuntu):
assignee: nobody → cesare (wtoro00)
Mantas Kriaučiūnas (mantas) wrote :

Hi Jörg Schilling,

I'd be very happy to see your original cdrtools software in Debian, Ubuntu, OpenSUSE and other free operating systems.
It seems this can be achieved very easily - you can simply add the thirty-nine words text in sources of some libraries from cdrtools package:
"You are permitted to link or otherwise combine this library with the program mkisofs, which is licensed under the GNU General
Public License (GPL). If You do, you may distribute the combined work under the terms of the GPL."

It's very easy to do and cost nothing :)

Jörg, please, give the permission as the relevant copyright holder on the CDDL's libraries for combination with mkisofs and distribution of the binary and source under the terms of GPL, without any additional restrictions.

Please, add this text even if you are 100% sure, that you don't *need* to grant the permission - all users of your original cdrtools software will be very happy if you add this text, because then your package will be included into OpenSUSE, Ubuntu and other Linux-based free OS, according to
https://features.opensuse.org/311186 and http://lists.opensuse.org/opensuse-factory/2011-02/msg00089.html

Jörg, please don't waste your time and don't argue with them even if they are not telling the truth - I've read yours answer (http://lists.opensuse.org/opensuse-factory/2011-02/msg00093.html ) and I agree with you, but you could show your generosity and simply give the permission as the relevant copyright holder on the CDDL's libraries.
Thank you very much for all your work and efforts.

I'm pasting some text from email above:
[..]
After speaking to Jörg we began our review of the complete source of
cdrtools, and soon verified that GPL compliance on mkisofs was broken.
We told Jörg that as far as we could see he was the only copyright
holder on the CDDL'd libraries, which he confirmed. In that case, I
pointed out, he could give all the permission necessary to solve the
problem, without any license changes: he simply needed to give
permission as the relevant copyright holder on the CDDL's libraries
for combination with mkisofs and distribution of the binary and source
under the terms of GPL, without any additional restrictions. We
drafted for him the thirty-nine words needed: "You are permitted to
link or otherwise combine this library with the program mkisofs, which
is licensed under the GNU General Public License (GPL). If You do,
you may distribute the combined work under the terms of the GPL."
[...]
Though Jörg continued to argue that he didn't *need* to grant the
permission, he never explained why, in the face of opposing legal
analysis on behalf of the copyright holders of mkisofs he didn't
*want* to grant a harmless permission that would allow his work to be
included in Canonical's Ubuntu distributions. After weeks of
discussion and many hours of my time and the time of my associate
Aaron Williamson, Mark Shuttleworth decided there was no point in
further fruitless negotiation and I agreed.

Schily (schilling-fokus) wrote :

Your request creates the impression that the original cdrtools are not valid OSS.

I am sorrry to see that you are wrong.

I've received a very clear statement from Eben Moglen on that the GPL of course
permits to link GPLd software against any library of any license as this is the
requirement for being able to permit to publish binaries from GPLd programs (such
as gtar) for platforms that do not come with a GPLd or LGPLd libc.

As you should know, the statement you are requesting does not exist from the gtar
Copyright holders in order "to permit to ship gtar binaries for Solaris, AIX or HP-UX",
just because it is commonly agreed that such statement is not needed.

So please do not ask me to do things that you won't ask from other projects.

Matteo Italia (matteo-mitalia) wrote :

Schily, what's wrong with adding those words, even if they are redundant?
If your interpretation of the matter is correct (and I believe it is, although IANAL) you are just making extra-explicit what is already permitted by of your license and the GPL, so you aren't granting any extra permission over what can be done with your code - from your point of view nothing changes.
On the other hand, people who think that the situation is currently into a "grey zone" will be relieved by the explicit permission, and we'll put to an end to the whole cdrkit nonsense. Everybody wins.

Schily (schilling-fokus) wrote :

Well, I'll tell you what's wrong:

The claim "...If You do, you may distribute the combined work under the terms of the GPL."

does never apply for typical OSS projects (unless someone makes _all_ parts
available under the GPL in their repspective source), so Mantas asked me to
grant something I do not need to grant, that I will not grant and that has not
been granted to the vast majority of OSS.

If you e.g. publish a gtar binary for HP-UX (which is a closed source platform),
only the parts from gtar that have been compiled from the gtar sources are
under GPL and nobody sees a problem with that fact.

This is because the GPL only requires the following:

- the parts that are from GPLd source need to be published under the terms
  and conditions of the GPL.

- the parts that are not compiled from GPLd source need to be made available
  to allow recompilation and re-linking.

If you don't believe me, you should read the GPL book from Harald Welte's lawyer.

Cdrtools are fully compatible with the requirements of the GPL and I see no
reason to grant more than the GPL request to be granted.

Sorry for this OT but am I the only one who has the feeling that this all is redicoulus? It really seems that this is something personal. What is the problem in adding a bit of text? I really have the strong feeling that you, schily, are not really interested in solving the problem. If I'm wrong, I make a formal apology. But I really havn't read any suggestion from you about how this could be solved.

And the users are the ones that suffer from this feud. Really sad.

Schily (schilling-fokus) wrote :

Well, it seems that recently some people came up with proposals that are not
realizable. Let me give some explanations on the background:

The whole problem has been initiated by an unfriendly Debian packetizer in
May 2004. At that time this person was a newcomer and the previous
Debian packetizer was a very friendly and honorable person. The "reason"
for initiatig this dispute was that the unfriendly newcomer wanted to
force me to include a defective patch in mkisofs.

After aprox. 15 months, this Debian packetizer came up with the new
and unsourced claim that there is a so called "license problem" in
cdrecord. If you closely look at his claims published that since then,
you will see that the interpretation of the GPL for his claim differs from
the interpretation for all other OSS projects.

Other prople who recently tried to really change things came up with the
proposal not to talk about licensing in this context.

Now Mantas came up with a proposal that is based on trying to force
me to accept worse conditions for cdrtools than other OSS projects
are given. Please understand that this is not acceptable.

The current cdrtools source already contains some explanations on
the GPL. If you believe that this is not sufficient, I may add more text
as long as this text is based on equal treatment on all OSS projects.
Did you read the file COPYING?

Thorsten: I encourage you to read http://www.osscc.net/de/gplger.html

If you believe I should add some statements that better explain
that/why the GPL definitely does not require other "works" to be under
GPL, try to make a proposal for a wording.

If you however belive that the GPL requires "other works" to be under
GPL just because we are talking about cdrtools even though the rest
of the OSS ecosystem works under different aasumption, you need to
rethink your position.

If you like to help, manage to include cdrtools packages in ubuntu.

Schily (schilling-fokus) wrote :

Just a note.... in case this helps:

Yesterday, I reworded the file "COPYING" a bit in order to avoid confusion
and to make things more obvious.

Check: ftp://ftp.berlios.de/pub/cdrecord/alpha/COPYING

in special the new top parts that explain work-limits and the enhanced
GPL notes at the end that now explain that the GPL under no
circumstances requires other works to be put under GPL.

Mantas Kriaučiūnas (mantas) wrote :

Thank you very much Schily, hope your work now will be included into free GNU/Linux distributions.
Maybe someone could inform about improved "COPYING" file Debian, OpenSUSE, Fedora and other distros developers?

On Mon, Feb 27, 2012 at 12:04:15PM -0000, Schily wrote:
> Just a note.... in case this helps:
> Yesterday, I reworded the file "COPYING" a bit in order to avoid confusion
> and to make things more obvious.
>
> Check: ftp://ftp.berlios.de/pub/cdrecord/alpha/COPYING
>
> in special the new top parts that explain work-limits and the enhanced
> GPL notes at the end that now explain that the GPL under no
> circumstances requires other works to be put under GPL.
>
> --
> Please include original cdrecord (cdrtools) package in Ubuntu

--
Labanaktis/Good luck,
Mantas Kriaučiūnas Jabber ID: <email address hidden> GPG ID: 43535BD5
Public organization "Open Source for Lithuania" - www.akl.lt
Geriausios biuro programos verslui ir namams - http://openoffice.lt
Prekyba naujais ir atnaujintais kompiuteriais su Linux OS - http://tinklas.eu
Naudok Baltix GNU/Linux sistemą savo kompiuteryje - http://baltix.lt

It is amazing that this problem of Wodim is so persistent, while it clearly compromises the quality of Ubuntu and Linux. Canonical please seek to find a solution!

Changed in cdrtools (Ubuntu):
assignee: cesare (wtoro00) → nobody

> Please, add this text even if you are 100% sure, that you don't *need* to grant the permission

> Schily, what's wrong with adding those words, even if they are redundant?

What's wrong with acting irrationally even if you're not? It appears you are applying pressing to the wrong party here.

> I had a conversation with Schily. As far as the political/social aspects go,
> I'm satisfied with his explanations and I strongly feel he needs our support.

Amen.

> So please do not ask me to do things that you won't ask from other projects.

Reasonable men will not.

> Now Mantas came up with a proposal that is based on trying to force
> me to accept worse conditions for cdrtools than other OSS projects
> are given.

That is neither reasonable nor acceptable. Remain steadfast.

> Thank you very much Schily, hope your work now will be included into free GNU/Linux distributions.

Hope? Will you not also apply pressure to the other parties in this issue? Such that the public sphere may observe?

To that end what progress has since been accompished?

Marcos Mora (marcosjosemora) wrote :

Hello.

It is no clear to me if this problem has been addresed at all since I reported a dupplicated bug in https://bugs.launchpad.net/ubuntu/+source/cdrkit/+bug/1106855 ( Bug #213215)

clic to get more info on the matter.

Schily (schilling-fokus) wrote :

I am not sure how I should interpret the text in comment #44. To me it
looks as if it has been written by a very unfriendly person but I am open
for a different explanation if possible...

Let me recapitulate:

In May 2004 a new and unfriendly Debian packetizer started to attack
the cdrtools project because his broken patch for mkisofs was not accepted.

As this packetizer also was extremely lazy, he did not upgrade cdrtools since
he started his new "job" and as a result many problems that have been a result
of incompatible linux kernel interface changes become obvious and users
complaint a lot.

In summer 2005, this person started a red herring by claiming that cdrtools
have a license problem.

In late September 2006, Debian "upgraded" to a cdrtools version from
Septemer 2004 and added many new bugs. In December, Debian removed
important Copyright notices for the original author from the code.

In May 2007, the last substancial change has been introduced into the Debian
"fork". Since then, only typo corrections have been applied.

Well, the lawyers from Sun, the lawyers from Oracle and the lawyers from Suse
confirmed that there is no license problem with the original code. Even Eben
Moglen confirmed this in a private mail to me.

So what is the reason for Ubuntu to prevent people from being able to use
working legal original software and why does Ubuntu still distribute "cdrkit"?

testing123 (garf-schroedinger) wrote :

@Schilly

If the-unfriendly-who-was-not-named made a bogus claim about licensing but then (as you pointed out) went to the dark side of the law by actually breaking your copyright, isn't it simpler to just SUE his @$$ and then get Debian fixed ?
(For the downstream distros that are still reluctant, such as Ubuntu, you could just point them to the result of the lawsuit or even to the preliminary paperwork and also the the ppa repositories so they can switch even before Debian does.)

I know it sounds harsh, it is, but any person making people burn a lot of coasters and a lot of time just for a lousy patch (and possibly sent some users back to windoze) can go to hеll in my book and .... burn all he wants with all the patches he wants.
And since the closest thing to hell is the justice systsem, there's the suggestion above.

And I also realise that you already worked a LOT on this (and I'm hoping you continue to do so for newer optical drives like BD-R etc if you haven't already done so), but you're the only one who can sue the-unfriendly-who-was-not-named. If you don't have time, see if any association could do it pro bono on your behalf (and with your proper authorization, of course).

Marcos Mora (marcosjosemora) wrote :

Has this bug been worked around some how?

@Marcos:

No, the situation is not going to change even if Joerg Schilling is going to change the license. He has shown several times that he has a hostile attitude towards others in the open source community and therefore most people who know him refuse to work with Joerg anymore.

Matteo Italia (matteo-mitalia) wrote :

Woa, now the ridicolousness of this debate is getting critical, I've seen five-year-old children way more reasonable than the two opposing parties involved in this debate.
If this wasn't keeping millions of systems with broken software it would be at least mildly entertaining; seeing how this is going, probably our best hope is that optical media just phase out.

@Matteo:

Debian is moving to libburnia-project.org and cdrkit is going to be removed soon. And, no, it's not a kindergarten, it has some serious background which I do not like to disclose here though as it might have legal ramifications.

Just believe me that this cannot be resolved the way you want it to be resolved.

Schily (schilling-fokus) wrote :

Mr. Glaubitz is well known to spread hostile personal attacks at various places.
just search for "glaubitz" or "cbmuser".

Matteo, your assessment was right. People with a real objection would be able to
verify their claims.

As you can read in comment #46, the problem was initiated by two people at Debian
that do not act in a social way and started personal attacks and attacks against
the cdrtools project in May 2004. This ended in an unverified claim of suposed legal
problems in cdrtools.

In Summer 2008, Mark Shuttleworth proposed a plan to work around the Debian
initated problem but later in 2008, he made it obvious that he will never honour his
promise.

What may help is the fact that currently three companies made a full legal review for
cdrtools and all as a result decided to include the original cdrtools in their distro. The
last company that made a full legal review was SuSe (in Autumn 2013). As a result,
SuSe now includes cdrtools again even though there have been several anonymous
threats from Debian people (those people could be de-anonymized) in the bug tracking
system from SuSe.

The Linux distros that still do not ship cdrtools are distros that did never ask a specialized
lawywer.

BTW: libburnia is still not supporting all features that cdrtools supported 10 years ago.

Peter Funk (pf-artcom-gmbh) wrote :

I tried to burn a bluray BD-R on my Kubuntu 14.04 LTS laptop using k3b.
This did not work. (files from the resulting disc can not be read).

After some research I got here.

Since I could not find the cdrtools source mentioned in the messages above using the URLs
on berlios I tried to find cdrtools using $earch-engine and ended up here:

http://fossies.org/linux/misc/cdrtools-3.01a24.tar.gz

Is this the right place?
Is fetching and compiling this software the only way to solve this problem in Ubuntu?
In 2014?

It would be helpful if someone with more knowledge about this topic could explain
what users should do if they simply want to burn bluray discs for backup
purposes. Even a pointer to a tutorial is welcome.

Roger Lawhorn (rll-m) wrote :

For Peter Funk -
A chapter out of my ebook (should work for ubuntu 14.04):

Media - Burning - CDR-Tools vs CDRKit

There are two packages that can be used for burning.
They are cdr-tools and cdrkit. cdrkit is the default for Linux Mint.

Here is an article describing why some did not like cdr-tools and replaced it.
http://www.enterprisenetworkingplanet.com/netos/article.php/3715646/Tips-and-Tricks-for-Linux-Admins-Volatile-Debian.htm

I personally go back to cdr-tools because it works. cdrkit, when first introduced, broke everything. It was a nightmare.

For those who remember cdr-tools and prefer it there is a way to switch back and forth at will.

PPA Website: https://launchpad.net/~brandonsnider/+archive/ubuntu/cdrtools

Switch to using cdr-tools...

Open up a terminal, and paste the following commands:
>sudo add-apt-repository ppa:brandonsnider/cdrtools
>sudo apt-get update
>sudo apt-get install cdrecord mkisofs

You will see an error telling you Brasero depends on wodim (cdrkit) to run. You can safely ignore this. Brasero will run with cdr-tools.

Optional - Install K3B Burning Software:
>sudo apt-get install phonon-backend-gstreamer
>sudo apt-get install k3b

Go back to cdrkit...
Open up a terminal, and paste the following command:
>sudo apt-get install wodim genisoimage

Schily (schilling-fokus) wrote :

This article on "enterprise...." is wrong - sorry.

What really happened is this:

In 2004, Debian decided to attack the cdrtools project, created a buggy fork (illegally under the original name) and stopped distributing the original software in May 2004.

After 2 years of attempts to solve this problem failed, and the FSF did not help against the attacks against the still 100% GPLd cdrtools, the cdrtools project was relicensed to CDDL on May 15 2006. At the same time, Debian was told to stop distributing their fork under the original name.

As a result, Debian renamed their fork to "cdrkit", keeping all the > 100 bugs they introduced since May 2004. So the timeline verifes that Debian is lying.

The article you are referring is also technically wrong: All CD-ROM drives ever made are SCSI drives and cdrtools honor this fact.

As a site note, it seems to be of interest that aprox. 50 of the Debian specific bugs in cdrkit are related to missunderstanding the SCSI / IDE story. The original software never had these bugs.

The only problem was that Linux-2.6 introduced an incompatible SCSI kernel interface that needs a different method to get the needed permissions that previous Linux releases. While cdrkit did never introduce support for this kernel incompatibility problem, the original cdrtools include a workaround.

BTW: since Mark Shuttleworth decided to include ZFS in UBUNTU, he admitted that there is no license problem (as spread by the deffamation from Debian) because ZFS is under CDDL and ZFS + the Linux kernel create a so called "collective work" that is permitted by the GPL.

mkisofs works the same way and links a GPLd program against a CDDL library which is accepted by the FSF, as otherwise GNU tar would be illegal on OpenSolaris.

All other software from the cdrtools is 100% CDDL, so UBUNTU should finally kick off the buggy and unmaintained cdrkit and re-introduce the maintained cdrtools.

Ben M. (bmhm) wrote :

ZFS also came to my mind. Why should ZFS be allowed to be compiled INTO the kernel on one hand, and cdrtools not being shipped as a optional software on the other hand?

Also, Debian ships ZFS using DKMS. On that matter, Ubuntu could also provide packages like those (and/or flashplugin-installer) which don't include the software directly, but download them from the original cdrtools site and compile them locally if they really insist on the licence problem. I don't know if there is any, I'm not a judge. Just saying that there is more than only one solution. Maybe this could be considered as well.

Schily (schilling-fokus) wrote :

Given that the GPL does not contain the term "linking" at all, there is no difference between static and dynamic linking.

But it may be of interest that Simon Phipps (Director at OpenSource.org) at CeBIT (March) 2009 made the following agreement with Debian:

Debian starts shipping the original cdrtools again within no more than 2 months, using a dynamically libschily and libscg.

Unfortunately, Debian did never intend to honor this promise...

Peter Funk (pf-artcom-gmbh) wrote :

@Roger: As you might have guessed from my post in 2014 I was able to solve my personal
problem. In fact I've been able to use the software written by Joerg Schilling by
compiling it myself.

And ... more important I am also very happy that I was permitted to use
it over many years in the past without ever paying a dime to Joerg Schilling!

I support the point made in your ebook that cdrkit made everything worse.

For the average user of GNU-Debian Linux or Ubuntu Linux the option to
find and include brandons PPA is certainly unnecessary tedious. The anyone with
the power to influence Ubuntu or even better Debian upstream to full fill this
long standing promise from 2009 should speak up.

Best regards, Peter Funk

Changed in cdrtools (Fedora):
importance: Unknown → Medium
status: Unknown → Invalid
Schily (schilling-fokus) wrote :

Hi, is this an intentional status change _here_ or just an imported status change from fedora?

Given that Ubuntu "recently" started to ship ZFS, it seems that Mark Shuttleworth finally follows the license strategy I offered him in 2008.

This should make it obvious to include the original cdrtools instead of the broken fork from Debian that is even dead since May 2007.

BTW: Fedora did never ask any lawyer and did never present a verifiable theory for their anti-social claims on the cdrtools project, so any claim from Fedora is no more than libel. Fedora with it's current behavior is in conflict with the law.

SuSe sent their lawyer to Berlin years ago and after half an hour of discussion, SuSe decided to include the original cdrtools and to fade out the broken cdrkit.

So when will Ubuntu stop to blindly follow the anti social behavior from Debian?

Edward (edwardtisdale-2004) wrote :

having issue burning DVDs, in processx now of ordering some brand new TDK CD-RWs no, which have worked in the past, but for some reason burning even with k3b hasn't worked for me for a while, is this all being phased out i lieu of flash drives or something? I do hope not ;)

here's the output of my k3b from 1/7/2018

-----------------------------------

Burned media
-----------------------
DVD+R

Devices
-----------------------
TSSTcorp CDDVDW TS-H663B UO00 (/dev/sr0, CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD-R DL, DVD+R, DVD+RW, DVD+R DL) [DVD-ROM, DVD-R Sequential, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RAM, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW] [SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Restricted Overwrite, Layer Jump] [%7]

System
-----------------------
K3b Version: 2.0.3
KDE Version: 4.14.16
QT Version: 4.8.7
Kernel: 4.10.0-38-generic

Used versions
-----------------------
growisofs: 7.1

growisofs
-----------------------
Executing 'builtin_dd if=/dev/fd/0 of=/dev/sr0 obs=32k seek=0'
/dev/sr0: "Current Write Speed" is 18.4x1352KBps.
          0/2868903936 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
=== last message repeated 2 times. ===
     360448/2868903936 ( 0.0%) @0.1x, remaining 1459:01 RBU 100.0% UBU 76.7%
    4128768/2868903936 ( 0.1%) @0.8x, remaining 161:54 RBU 99.9% UBU 99.9%
:-[ WRITE@LBA=2950h failed with SK=5h/ASC=21h/ACQ=04h]: Invalid argument
:-( write failed: Invalid argument
/dev/sr0: flushing cache
/dev/sr0: closing track
/dev/sr0: closing disc
:-[ CLOSE DISC failed with SK=5h/CANNOT FORMAT MEDIUM - INCOMPATIBLE MEDIUM]: Wrong medium type

growisofs command:
-----------------------
/usr/bin/growisofs -Z /dev/sr0=/dev/fd/0 -use-the-force-luke=notray -use-the-force-luke=tty -use-the-force-luke=4gms -use-the-force-luke=tracksize:1400832 -use-the-force-luke=dao:1400832 -dvd-compat -speed=18 -use-the-force-luke=bufsize:32m

Edward (edwardtisdale-2004) wrote :
Download full text (4.9 KiB)

Here's from a session from Brasero:
Checking session consistency (brasero_burn_check_session_consistency brasero-burn.c:1739)
BraseroBurnURI called brasero_job_get_action
BraseroBurnURI called brasero_job_get_action
BraseroBurnURI called brasero_job_set_output_size_for_current_track
BraseroBurnURI stopping
BraseroBurnURI called brasero_job_get_action
BraseroBurnURI called brasero_job_get_session_output_size
BraseroBurnURI output set (IMAGE) image = /tmp/brasero_tmp_6THECZ.bin toc = none
BraseroBurnURI called brasero_job_get_session_output_size
BraseroBurnURI called brasero_job_get_action
BraseroBurnURI called brasero_job_get_current_track
BraseroBurnURI no burn:// URI found
BraseroBurnURI stopping
BraseroLocalTrack called brasero_job_get_action
BraseroLocalTrack called brasero_job_get_action
BraseroLocalTrack called brasero_job_set_output_size_for_current_track
BraseroLocalTrack stopping
BraseroLocalTrack called brasero_job_get_action
BraseroLocalTrack called brasero_job_get_session_output_size
BraseroLocalTrack output set (IMAGE) image = /tmp/brasero_tmp_OHSECZ.bin toc = none
BraseroLocalTrack called brasero_job_get_session_output_size
BraseroLocalTrack called brasero_job_get_action
BraseroLocalTrack called brasero_job_get_current_track
BraseroLocalTrack no remote URIs
BraseroLocalTrack stopping
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_flags
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_fd_in
BraseroChecksumImage called brasero_job_set_output_size_for_current_track
BraseroChecksumImage stopping
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_flags
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_session_output_size
BraseroChecksumImage output set (IMAGE) image = /tmp/brasero_tmp_2ZRECZ.bin toc = none
BraseroChecksumImage called brasero_job_get_session_output_size
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_action
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage called brasero_job_get_input_type
BraseroChecksumImage called brasero_job_set_current_action
BraseroChecksumImage called brasero_job_get_fd_in
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage Starting checksuming file /home/edward/Downloads/ubuntustudio-17.10-dvd-amd64.iso (size = 2868903936)
BraseroChecksumImage called brasero_job_get_fd_out
BraseroChecksumImage called brasero_job_get_current_track
BraseroChecksumImage Setting new checksum (type = 2) cad497d4a880c6486a0f3e74c5314c55 ((null) before)
BraseroChecksumImage Finished track successfully
BraseroChecksumImage stopping
BraseroGrowisofs called brasero_job_get_action
BraseroGrowisofs getting varg
BraseroGrowisofs called brasero_job_get_action
BraseroGrowisofs called brasero_job_get_current_track
BraseroGrow...

Read more...

Edward (edwardtisdale-2004) wrote :

..and when I tried a 4.7GB non-DL disc it said there wasn't enough space!

Edward (edwardtisdale-2004) wrote :

now I thought I fixed it, because it at least looked like it burned the whole disc, by doing..

sudo apt-get install libdvdcss dvd+rw-tools libbrasero-media3-dev brasero
put swap on with gparted and don't close gparted until dvd is burned
use my usb burner instead of internal
choose explicitly to open the iso as an iso, don't use autdetect or the image will say it is too big for a 4.7gb disc

went all the way, then did a checksum then ejected the disc but when I reclosed the dvd there is no drive detected.

Edward (edwardtisdale-2004) wrote :

doing an integrity check in Brasero aftwer putting the dvd back in it says there is no md5 to be found on the disc, but I saw it go through the process of making the md5 hash.

Edward (edwardtisdale-2004) wrote :

yayy k3b finally came through with certain configuration settings. I did have to reclose the ejected disc for 15-30 seconds for it to finalize.

Schily (schilling-fokus) wrote :

Please note that your nore #128 mentions "growisofs" but this is a bug that asks for re-intrgrating the original cdrtools software.

Do you like to have the original software back again?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.