K3b -> Cddb Doesn’t Work

Home » CentOS » K3b -> Cddb Doesn’t Work
CentOS 53 Comments

Copying a CD with k3b is no problem, except I want to include on my copy the cbbd data (from freedb.org). I’ve configured k3b’s cddb section according to instructions at
and read every article google could find about “k3b cddb freedb.org config”, but still k3b can’t manage it. Grip handles getting the cddb data just fine. I’m beginning to think that k3b is simply broke as far as this functionality is concerned. But I thought I’d ask here if anyone has found a way to make this work.

tia for all helpful tips.

53 thoughts on - K3b -> Cddb Doesn’t Work

  • ken wrote:

    Doing this is no problem if you just use the cdrtools from the commandline.

    BTW: I recommend to use cdda2wav for audio extraction.

    J

  • n 08/17/2013 05:29 PM Joerg Schilling wrote:

    Jörg,

    Thanks for your reply. As late as November 2012 I always used the CLI
    for copying *data* CDs, using cdrecord and readcd. But though I read and studied manpages and scads of documentation, I never had any luck cloning a music CD using these commands. So I’d doubt I could figure out on my own, in addition to cloning a CD, adding in the song titles etc.

    I guess I wasn’t clear about ripping a CD. Grip, as I said handles this fine, including downloading the cddb data. So if I wanted to create wav
    (or ogg or other) files, I could use grip. But for some CDs, a series of wav files just doesn’t play back well; I’m talking about music in which one track blends into the following track with no break in between. These don’t play back well because audio players insert a break (perhaps because they need a second or so to load that second track) and, in addition, often this break isn’t in a good moment. So I’ve decided to just burn the entire CD to avoid hearing the breaks. So is it even possible to save the cddb data to a copied CD?

  • ken wrote:

    Are you using recent original software or are you using an outdated, dead and defective fork that is distributed by some non-OpenSource oriented Linux sources?

    If you are using this bad fork that is from September 2004 – 9 years ago, you suffer from many problems, like incomplete documentation and many bugs that cannot be found in the original software.

    Programs like grip and cdparanoia don’t care about the usability of the extracted files for later burning tasks and they are not able to extract so called “un-CDs”.

    cdda2wav knows about the writing process, feteches cddb data and includes a bug-fixed libparanoia.

    Recent man pages also contain several related examples. Did you read a recent manpage and follow the EXAMPLE section?

    J

  • cdrecord and readcd are both part of this package:

    $ rpm -qi cdrecord Name : cdrecord Relocations: (not relocatable)
    Version : 2.01 Vendor: CentOS
    Release : 10.7.el5 Build Date: Thu 26 Feb 2009
    06:30:50 PM EST
    Install Date: Mon 05 Sep 2011 03:03:56 PM EDT Build Host:
    chamkaur.karan.org Group : Applications/Archiving Source RPM:
    cdrtools-2.01-10.7.el5.src.rpm Size : 1383954 License: GPL
    Signature : DSA/SHA1, Sun 08 Mar 2009 09:45:19 PM EDT, Key ID
    a8a447dce8562897
    Packager : Karanbir Singh
    URL : http://cdrecord.berlios.de/old/private/cdrecord.html Summary : A command line CD/DVD recording program. Description :
    ….

    The “Description” states nothing about it being from a bad fork from
    2004. :) So how would anyone know?

    I don’t know what is meant here by “recent”. Which is the earliest version which contains the functionality required?

  • ken wrote:

    You will not get useful version information from calling “rpm”.

    There is nothing like: cdrtools-2.01-10.7.el5

    If you like to know what you are using, I recommend to call:

    cdrecord -version cdda2wav -version readcd -version mkisofs -version

    If you are using original software, you will see someting like:

    Cdrecord-ProDVD-ProBD-Clone 3.01a16 (i386-pc-solaris2.11) Copyright (C) 1995-2013 Joerg Schilling

    If one of the commends does not print a message like this, you should be careful.

    BTW: cdrtools-2.01 is from September 2004.

    The features in question are in since a longer time, but if you are on a Linux distro that does not deliver up-to-date software, you should expect that there are bugs in your version that never have been in the original software.

    Since 2004, the man pages have been completely rewritten for better readability, the features have been massively enhanced (they did more than double since September 2004) and many bugs have been fixed. In January 2010, cdda2wav e.g. added support for hidden tracks. Mkisofs added support for libfind in 2006
    and cdrecord added support for BluRay in 2007.

    Would you like to run a Linux kernel from 2004 today?

    J

  • [cdrtools-2.01-10.7.el5 ist einmalig???]

    You’re saying this is the preferred package, yes? and it will have the functionality needed? If yes and yes, where does one get that package?

    Note that my rpm command output above says:
    Source RPM: cdrtools-2.01-10.7.el5.src.rpm

    So there should be something definitive to say about these:

    $ cdrecord -version Cdrecord-Clone 2.01 (cpu-pc-linux-gnu) Copyright (C) 1995-2004 J�rg Schilling Note: This version is an unofficial (modified) version with DVD support Note: and therefore may have bugs that are not present in the original. Note: Please send bug reports or support requests to http://bugzilla.redhat.com/bugzilla Note: The author of cdrecord should not be bothered with problems in this version.
    $ cdda2wav -version cdda2wav version 2.01_linux_2.6.18-92.1.10.el5_x86_64_x86_64
    $ readcd -version readcd 2.01 (cpu-pc-linux-gnu) Copyright (C) 1987, 1995-2003 J�rg Schilling
    $ mkisofs -version mkisofs 2.01 (cpu-pc-linux-gnu)

    Well, I’m always careful (except that one time I backed my car into the garage door).

    Without knowing what is *essential* in the “-version” output, it’s hard to say anything definitive. Jörg, I’m not a lawyer, but I know it’s possible to get a tradename which then others could use only with your permission. So is you owned “Jörg’s unmessed with software” or “Jörg’s truly functional code”, you could put that in the “-version” output, but no one else could unless they had your permission… iow, they couldn’t muck with your code and then confuse people by saying it’s your code.
    (I’m assuming that this is what you mean by “original”.) This then would constitute a definitive determination.

    What’s an “un-CD”?

    What I hear is that you and Redhat/CentOS have different ideas as to what “up-to-date” means. My system is completely up-to-date as defined by the latter.

    For a person of considerable talents as you, it shouldn’t be a big deal to put together an RPM package for currently supported RH/cOS (v. 5.9
    and 6.x) with the needed utilities and which wouldn’t break dependent apps such as k3b, grip, gnome-cd, etc. Then these two disparate worlds would be united, at least as far as burning and ripping CDs and DVDs goes.

    No. But I wouldn’t either want to go back to the days before package management.

    CentOS mailing list CentOS@CentOS.org http://lists.CentOS.org/mailman/listinfo/CentOS

  • ken wrote:

    A version cdrtools-2.01-10.7.el5 does not exist.

    So this is a release where somebody did rip off the working original DVD
    support code and replaced it with half baken other code that is known not to work correctly.

    You still get a completely outdated software.

    Be careful, this mkisofs is full of bugs and creates ISO buggy images.

    If I have trouble with a piece of software, I call xxx -version and if that prints 2004 as the newest date, I know that something is wrong.

    There is no need to get a trademark as the name “cdrecord” is a trademark even wihtout registering it.

    Did you try google?

    Intentionally broken CD shaped media sold by the music industry.

    Someone who did not do his homework for 9 years could be called dead. It seems that your distro missed 97 updated versions from cdrtools.

    If FORD did stop creating newer models with Model T, this was still “up to date”, but would you like to use it today?

    You miss the point: I write software that compiles/runs nearly everywhere from source.

    It is the duty of the distros to create packages. I cannot create packages for
    > 100 OS/cpu combinations.

    I am sure that if you go to your favorite PC shop and this shop has no model from after 2004, you would ask the dealer to get newer items or chose another dealer.

    In other words, you either choose a distro that offers up to date packages or you need to compile yourself.

    J

  • Has the CD format changed since 2004?

    I’m sure you realize that no one on this list wants ‘up to date’
    software as shipped by developers – and why. Is there some compromise possible where a somewhat vetted, packaged release exists? Or RedHat gets appropriate bug reports so they fix the broken parts?

  • Les Mikesell wrote:

    This is why you are happy with buggy software from 2004 shipped by redhat when there is software with no known bugs?

    Redhat had more than 100 bugs filed against the “cdrtools” version they ship. All these bugs could be avoided by upgrading to a recent original version. Redhat closed these unfixed bugs instead of doing it’s homework that would result in updated versions.

    So it seems that redhat doesn’t care about bug reports.

    J

  • This isn’t aimed at you personally, but the reason people like RHEL/CentOS is that the ‘no known bugs’ status of a developer’s software release often turns pretty quickly into ‘bugs with no known fix’ when they hit a wider distribution. And developers like to change things in ways that break existing interfaces in what they think are improvements.

    You are in a better position to judge that than me, but the whole point of RHEL is to never break exiting, previously working interfaces
    (and thus their user’s programs…) within the life cycle of the distro. So if they would lose backwards compatibility anywhere by updating – and perhaps even if it isn’t clear that they wouldn’t, they they are correctly following the policy that the people on this list typically want. Othewise we’d be off reinstalling todays new and buggy version of some other disto instead of reading email while our servers keep working. But, maybe it’s not so great for desktop type activity that wasn’t feature-complete in 2004. And if you are talking about bug reports that were made long enough before the 6.0
    release to have gotten the update in, then I’d say you are right regardless of compatibility.

  • All I have to say about that is that I wish the GPL were not so restrictive that it prohibits many potential best-of-breed combinations of components. But that was it’s intent and it isn’t likely to ever change. I’m just glad that people like Larry Wall understood that early-on and used dual-licensing to make at least some software usable in more situations. .

  • None of this is helpful to the OP. You should either point him to your preferred location for acquiring your version of cdrtools, or provide a yum repository for RHEL/CentOS users to download rpms. You should warn him that either of these methods will “officially” break binary compatibility with upstream (which users need to decide for themselves if they wish to do that).

    –keith

  • Les Mikesell wrote:

    The Linux kernel and Linux distros are known for breaking things by e.g. changing interfaces.

    Cdrtools are known for stability and backwardscompatibility while at the same time enhancing functionality.

    I am talking about obvious bugs that apply to the redhat version but not to the original code. I am talking about closing unfixed bugs instead of upgrading to newer versions. I am talking abut redhat that is not doing it’s homeworks.

    People complain about problems and redhat is ignoring them even though the bug reports contain comments that make it obvious that the right way to deal with the bug is to upgrade to a more recent version. Nothing happens and after a few years the bugs are closed even thoug the bug still exists on redhat.

    J

  • Les Mikesell wrote:

    Mr. Corbet is not interested on the truth but likes to play games against OSS. He publishes unproven claims and does not give a place to correct his fault.

    Don’t believe the attacks against OSS from Debian, Mr. Corbet and similar.

    Sun legal, Oracle legal and even Eben Moglen confirmed that cdrtools is without legal problems.

    J

  • Keith Keller wrote:

    Please do not write false claims!

    If you know about problems, send evidence

    There are more then 100 bug reports in the redhat bugtracking system (just change your view to see all closed but unfixed bugs) that confirm problems with the binaries distributed by redhat and the users who reported the bugs confirmed that upgrading to recent original software fixed the problem.

    It is pretty obvious that redhat does not care about it’s users…

    J

  • Yes, that is true in general. RHEL (and thus CentOS) are known for
    _not_ changing interfaces within the supported life of each major release version. It is extremely rare for any previously working program to be broken by an OS update over that many-year span. And that is a good thing – and why they are popular.

    That stops a little short of saying they would be fully compatible with any previous invocation or library linkage.

    Part of the story must be missing here – why does a broken version exist in the first place and why would RedHat have picked it?

  • The problem seems to be that you would rather rant about distributions’
    licensing and packaging decisions than help the OP. It seems like he would be perfectly happy to use your version of cdrtools, yet you insist on not telling him how to get it!

    Still, none of this solves the OP’s problem! You do yourself and your software a disservice by being deliberately unhelpful to score political points. (Perhaps that is why distros are reluctant to include your software, preferring a buggy version to one with a difficult author.)

    –keith

  • Reindl Harald wrote:

    Do you like to prove that you cannot stay with the truth?

    You also wrote a false claim.

    J

  • Keith Keller wrote:

    ???

    I told him that if his distro does not do it’s homework, he needs to compile himself. The URL is in my signature and in contrary to many autoconf based sources, my software compiles out if the box by just calling “make”.

    As mentioned before: I deliver something that compiles and runs out of the box on aprox. 30 OS platforms (not counting the CPU and OS-version variants). It is not my duty to deliver binary packages for more than 100 OS/CPU variants.

    J

  • Am 20.08.2013 10:47, schrieb Joerg Schilling:

    Can we stop this please? It serves no value for anyone on this list.

    If there is a problem with a software package provided by CentOS (base /
    updates), then it can only be solved if a ticket and case is opened with the upstream dsitribution as CentOS just rebuilds what Red Hat offers in their RHEL package set.

    Else people may provide the software through a third party repository like repoforge extras.

    Thanks

    Alexander

  • Alexander Dalloz wrote:

    There have been more than 100 related bugs in the redhat bugtracking before the bugs have been close without fixing them.

    You could show that you are interested in those bugs by reopening all related bugs that have not been fixed yet. Note that a bug does not go away if you increment the distro version number without upgrading software.

    If you like to avoid that similar discussions will pop up from time to time, I recommend you to upgrade to recent original software. This is the best grant from preventing your users to ask related questions. You then could close the named bugs as “fixed”.

    J

  • Joerg,

    Wouldn’t doing this cause conflicts with existing libraries?

    Will the many apps which depend upon the existing code– e.g., grip, k3b, gnome-cd– still work after installing your software?

  • Why not just create one RPM package for i386…? This would/should run on a whole lot of linux boxes and if, as you claim, it overcomes a lot of bugs and adds so much more functionality and documentation, then the word will get out about it and people will clamor for it. This would speak much more loudly and convincingly than all your posts here.

  • Is your code and its dependencies entirely GPL licensed?
    The allegation was that some of it is CDDL, which is problematic.

  • You can install Joerg’s version to someplace separate, like /usr/local, then test those dependent apps against the /usr/local version. I do not use these programs, so I don’t know exactly how they work–if they are built against cdrecord libraries, this process might be challenging, but if they are just calling external helper programs it might be easy to configure e.g. k3b to use the /usr/local versions.

    I hope that’s helpful.

    –keith

  • ken wrote:

    Why do you believe this?
    Do you believe that CentOS delivers inconstsistent libraries?

    My software delivers nackwards compatible interfaces: it enhances but it does not break things.

    J

  • ken wrote:

    what problem do you have? You have been pointed to compile and install recent original software. Did you do that?

    J

  • John R Pierce wrote:

    Is your favorite Linux distro entirely GPL licensed?

    The CDDL was accepted as definitely OSS compliant by bopensource.org within 14 days and without to mention problems.

    The GPL did take a longer time to get approved because the GPL license text is in conflict with the OpenSource definition. The approval was given with a longer delay after the FSF explained that the GPL has to be interpreted in a way that makes it OSS compliant.

    So are you kidding?

    J

  • The issue is not compliance with opensource.org or otherwise. Each distro decides which licenses to prefer, which to tolerate and which to not tolerate. In the Linux communities, GPL is by far the most commonly used license, and it is accepted by virtually all Linux distros.

    So if you want your software to be used by the majority of Linux distros without license-related hiccups, you can always just re-license it to GPL and everyone will be happy.

    If, on the other hand, you have a reason to prefer CDDL over GPL
    for your software, then you should also acknowledge that each distro has an equal right to prefer GPL over CDDL, whatever the reasons.

    It’s democracy — as much as you have the right to license your software as you see fit, they equally have the right to not like your license and to boycott your software because of it.

    And there should be no hard feelings — everyone is responsible for the consequences of their choices. Live with it. :-)

    HTH, :-)
    Marko

  • Marko Vojinovic wrote:

    You seem to be missinformed: When cdrtools have been 100% GPL, it was attacked by Debian _because_ it was 100% GPL and because the GPL is a frequently missinterpreted license.

    …so I decided to choose a less problematic license than the GPL.

    Democracy is that the doers and this are software authors decide about the license. Distros are just users of the software and have to accept the license and as long as the license is doubtless OSS compliant, I see no reason why a distro should complain.

    J

  • Hello Joerg,

    Exactly! Agree or disagree, but act consequently (and obey to licenses/laws or..). Thanks a bunch for the software you brought to us sinces years, J

  • wwp wrote:

    You seem to miss that cdrtools _was_ under GPL and that I was forced to change the license because I was attacked by OSS enemies (Debian) and not a single Linux distro nor the FSF did help me against these attacks.

    If you _really_ prefer the GPL, why don’t you support it and why do you wait until authors are forced to change the license away from GPL?

    You had the chance to keep cdrtools under the GPL if you did help to defend cdrtools against OSS enemies such as Debian in 2005. I made the problem public and I asked for heelp.

    Please be no crybaby now that you see the consequences of not supporting the GPL when it was attacked.

    J

  • The GPL is designed to restrict distribution of combinations of things that are not all-GPL if any component is GPL. So any other license is equally problematic as long as GPL components might exist. The ‘less problematic’ solution is dual licensing like perl uses unless you want to apply restrictions one way or the other.

  • Les Mikesell wrote:

    I was attacked by Debian _for_ using the GPL and it seems that you did not help at that time. I will not use a license again after I was attacked _because_ I
    used this specific license.

    The GPL is discouraged by Debian…

    You should think aboiut why you did not help to defend the GPL in 2005.

    J

  • Umm, have they dropped perl?

    I’m not a fan of the GPL because of its viral and divisive nature, especially for anything that could be considered library code, and because it prevents the distribution of any number of potentially useful combinations of components (the current poster child being zfs on linux, but the issue has always been obvious). But, GPL-encoumbered code is not going away, nor are the companies that use it specifically because they don’t want better versions than what they ship to be allowed to exist.

    I’m just thankful that Larry Wall and others have realized that the way to side-step the problem is to dual-license so that the code can be distributed as GPL or a less restrictive license as the circumstances require without getting involved in someone else’s religious or political wars.

  • Reindl Harald wrote:

    But Debian attacked cdrtools for using the GPL when it has been 100% GPL.

    You should face reality.

    J

  • I find this an extremely odd assertation. I am not nor ever have been a Debian user, but I know Debian is based on the Linux Kernel, uses GCC, gnu libc, etc as its core, and these are ALL gpl. in what way were you ‘attacked’ by a ‘project’ (not an individual? we all know individuals can act loony) for using the same license as the bulk of the rest of the Debian distribution?

  • if you replace the stuff thats under RPM package management with code you self compile and simply copy, you break the package management system. an update might come along and not realize your code is in the place of the original RPM supplied files and replace them.

    btw, are /any/ CDDL components bundled with major linux distributions?
    I know Sun Java was never bundled due to CDDL entanglement, instead we have OpenJDK, which is GPL.

  • I’m pretty sure there was a point where Sun Java was in the Red Hat subscription update streams, but not in the publicly available src rpms. And debian included it. Not sure about the status now.

  • It is indeed true that I might be misinformed — I am writing from my
    (possibly faulty) memory here…

    But as far as my memory serves, the issue was not that cdrtools were GPL, but that the toolchain for building cdrtools source (was that called “schilly-tools”?) was non-GPL. And the dispute was about the interpretation of the GPL — does it require you to license the whole build-toolchain as GPL if cdrtools are GPL, or does it not require you to do so. And that was where things regarding GPL
    interpretations got complicated, and all that ugly story with Debian folks that followed.

    In essence, the conclusion was that there was no “fully-GPL”-kind of way (whatever that might mean) to distribute cdrtools such that the binaries could be built from source, if toolchain for the build is non-GPL. That was the reason why cdrtools were attacked “for being GPL”, as you said. So to avoid this problem, you re-licensed cdrtools to CDDL, which does not require any restrictions on the licence of the toolchain.

    And ever since then, various distros refuse to bundle cdrtools since the toolchain used for building the cdrtools binaries has a license that makes it unsuitable for them. Or something along those lines.

    That is how I remember the whole story, in short. Of course, my memory might be faulty, you certainly know all those details much better than I
    remember them.

    Nevertheless, my point was the following — assuming that the dispute was as I described it above, or something along those lines, the whole thing could be resolved if you just re-license *both* cdrtools and the schilly toolchain to be GPL. Or maybe dual-licence them, as Les suggested in another post.

    Not wanting to do that is of course your prerogative, but I believe it would solve all license-related problems for the cdrtools in one single and simple step. That way all distros could be allowed to bundle your software without any issues.

    Sure, no argument there. :-)

    Well, it is certainly more complicated than that. Different distros obey different internal and external rules which licenses to accept and which to refuse. There are many things in play there — legislation of the country of origin, eventual patent issues, internal distro policies about what constitutes as “freedom”, etc… Fedora is a typical example where one can find all sorts of complicated reasons why something was not included.

    So while every distro is of course required to accept the way you licensed your own software, other reasons might prevent them to bundle your software, despite your license being generally OSS compliant. This is of course unfortunate, but it is not simply the case of distro being
    “evil” or something — it may be a consequence of complicated interactions between several sets of rules, etc., leaving them with no choice in the matter.

    Best, :-)
    Marko

  • While Joerg certainly knows better… I think the issue was that cdrtools could be built only with the schilly-toolchain (or whatever the exact name), and that was *not* GPL. So according to some interpretations of the GPL, while cdrtools was claiming to be GPL-licensed, there was no GPL-compatible way to build the binaries from that source, which arguably made it violate GPL. That’s why Debian folks attacked, as far as I understood.

    The issue was resolved by Joerg re-licensing the cdrtools to CDDL, which does not impose restrictions on the toolchain used to build it. And that made it a no-go for mostly all distros since.

    All this with the usual caveat that my memory might not be very correct here… ;-)

    Best, :-)
    Marko

  • Les Mikesell wrote:

    It seems that Larry was in a different position.

    Larry prefers the Artistic license and given the fact that Larry was doing OpenSource long before RMS “invented” “Free Software”, I understand why he prefers the more liberal from the OpenSOurce Movement, I apreciate his decision.

    Like perl, cdrtools have become an important part of a typical OS installation and most distros even depend on mkisofs for booting the main OS or the install media.

    If you carefully read the Artistic License, you will notice that Larry seems to have been under similar challenges as I have been while trying to ensure that this basic software is freely and in a recent bug free version available to everyone who needs it.

    I have been a promoter of the GPL as long as it was a good choice, but this was around 1990 when I made my decision. I even made a proposal on how to modify the GPLv0 (the one, GCC was using in 1986) could be modified in order to turn the GPL from something that cannot be used as it would enforce you to break other license agreements into something that has become usable. For this reason, I of course know how the often missinterpreted parts of the GPL have been created and what their real purpose is.

    Now the GPL has become a big problem for the OSS people as it prevents collaboration with other OSS projects in a way that projects using different but Opensouce.org approved licenses could crosswise exchange code parts. For this reason, I now promote licenses that allow soch code exchange. I selected the CDDL as the best copyleft license in this area and the Apache
    2.0 license as the best academic license and I did select these licenses before opensource.org made similar publications.

    Dual licensing is always more a problem than a solution. Uncooperative entities will distribute enhancements (you like to be interested as author) with only one of the licenses, making it impossible for the original author to use it.

    J

  • John R Pierce wrote:

    You cannot break something that is broken already. A distro that ignores updates since nearly 10 year is definitely broken.

    Of course. The CDDL is one of the 8 major OSS licenses.

    J

  • Whee. Here we go again.

    There are properly built and packaged RPMs for Jorg’s (sorry, android keyboard I’m using doesn’t have the proper marking for the o there) cdrtools, for EL6. I’m using them on a few installs where wodim just simply does the wrong thing and cdrtools does the right thing.

    Those packages properly obsolete the wodim ones and install in the correct places with the correct dependencies; I want to say they’re from the city-fan.org repo. (I’m not on my EL6 laptop, but on my phone right now,so I can’t easily check).

    In my case, I rebuilt from the source RPM, and that worked well.

    Once I’m back where I can check I’ll verify the repo and provide a pointer (again; it is in the archives of this list…..).

  • http://www.city-fan.org/ftp/contrib/yum-repo/ is the city-fan.org repo master; you will likely want to us the University of Seville mirror at http://nervion.us.es/city-fan/yum-repo/ .

    Do note that installing these packages will replace what could be considered core portions of the system; you’re on your own as far as support is concerned, in other words.

    I did not check if the version of cdrtools there is the absolute latest; it wasn’t when I first found this repo, which is why I rebuilt from the source RPM (using the latest cdrtools upstream source and slightly modified city-fan spec file; city-fan updated not long afterwards, and this package has been recently updated, as recently as this month).

    k3b and other tools can use this package just fine; while there are some neat features that k3b and other GUI frontends don’t expose, that’s ok for most purposes. You can add your own command line parameters in the k3b setup.

    But the EL6 version of k3b is quite old at this point.

    YMMV, you break it you keep the pieces, etc.

  • Lamar Owen wrote:

    On Android, you just need to “press” the character for a longer time and a bubble with more selections pops up. The only bug I see with the “o” is that this bubble is sorted the wrong way and the “

  • Marko Vojinovic wrote:

    Correct, Eduard Bloch (a hostile packager) came first up with personal insults and later created a red herring and turned these insults into a so called license dispute.

    This was an attack based on the wrong interpretations of the GPL you repeated above.

    The GPL is very clear about the fact that the build system is not an integral part of the work and that it may be licensed under _any_ license – it just needs to be included.

    The false interpretation of the GPL in order to attack projects is partucularly problematic as one month before, a book on the GPL was published by Till Jaeger et al (most well known pro GPL lawyers) and that book of course explains the correct interpretation of the GPL. See:

    http://www.osscc.net/de/gplger.html#gpl-complete-source

    It is a pitty that after Debian turned into a hostile distro other Linux distros followed the false claims from Debian instead of asking specialized lawyers.

    J

  • Marko Vojinovic wrote:

    If such false claims are published on a license and the license steward does not correct them, the licence needs to be seen as a weak license and avoided because it causes a high risk of being sued for no reason.

    J

  • John R Pierce wrote:

    The origin of course was a single hostile and lazy person: Eduard Bloch.

    Every larger project may have black sheeps… but I expect a project to do what is needed to keep it’s credibility and thus to discipline people who destroy the credibility of a project. Debian was kindly asked to replace the hostile person in December 2004. Debian (as a project) decided to support the attacker instead of it’s own reputation. So a personal problem from May 2004 was was turned into a Debian problem in December 2004.

    Note that before, there was a very kind packager for cdrtools at Debian. He finished his studies in late 2003 and dod not have the needed time anymore. A new packager was set up and this person was so lazy that soon more than 50
    bugs in the Debian bug tracking were caused by the fact that he did not upgrade to a newer version.

    In May 2004, he send a patch that was claimed to implement UTF-8 support for mkisofs. This patch did only address aprox. 50% of the places in the code that need a change for supporting UTF-8 and the code that was changed was so buggy that it caused plenty of compiler warnings.

    I send im this information and explained that I cannot include the patch in the main code for quality reasons. At that time Bloch started to send repeated personal insults to me.

    J

  • Same problem, just starting from the other side of the picture.

    The existence of GPL and non-GPL components presents a problem for anyone who wants combine the best components and give away their work.
    Larry is a bright guy. He solved that problem – and made his software usable in many situations where it might not have been otherwise.

    The purpose has always clearly been to restrict the combination of components that can be distributed as a ‘work’. If you are old enough you’ll probably remember one of the early invocations was to block distribution of the GPL’d gpm library in something that used RSA
    encryption code even though the components were all available in source. Except for the case of someone selling software and not wanting better versions to compete, it seems very unattractive. Certainly from a user’s perspective, allowing all possible combinations of well-tested, reliable components to be combined sounds better. Imagine if the reference code for TCP/IP had not been available for all types of use – we’d probably all still be struggling to get things to interoperate,

    But, as others have pointed out, the problematic part wasn’t so much the GPL in this case as the mix of GPL/non-GPL in the required build tools, so it seems wrong to misrepresent the issue as just ‘GPL’ when that was all under your control. But it does point out the divisive and viral nature of the GPL when used out of the context of a dual license.

    First, I don’t see how _additional_ uses of a software component are a problem to anyone, but even if that somehow bothers you, a dual license of GPL or CDDL should work while still requiring the source of changes to be available to the author.

LEAVE A COMMENT