Hi,Someone here said that the licensing issues have been resolved. I cannot see how: nothing has changed.Schily will of course claim they *never existed*. But as long as there is *some doubt*, I consider shipping compiled cdrecord a certain legal *risk*. It doesn't need to be a proven copyright violation to be a risk; so Joergs claims are not sufficient for me. Apparently, RedHat, Debian etc. also still see this issue persist. Be careful with anything Joerg claims. He likes citing himself (e.g. his own "OSSCC" - yes, that is him, too!) and as you have seen at the same time claims that Eben Moglen backs his view and calls him a liar. To him, anything supporting his claims is sound and anything else thus must be a lie. And of course, calling someone a liar then is a fact, not an insult, to him?!? But actually none of his claims have been supported by a court so far either. The risk thus persists! As far as I can tell, the key point is what you consider to be a "derivative work" and what not.Schily says that linking a library and using header files only makes a "collective work", and thus he licence combinations are valid. There is little doubt that a "collective work" (such as SuSE as a whole) can contain both CDDL and GPL code. However, most people consider linking GPL code to form a "derivative work" (after all, this is why the LGPL was created - with Joergs interpretation, LGPL and GPL would be the same!). As far as I can tell, Joerg would concur that building a "derivative work" with GPL and CDDL breaks the licensing. His "workaround" is denying that it it a "derivative work" at all, but that it is a "collective work". Neither interpretation was so far tested in a court as far as I can tell. And of course I did not measure the term "most" in the previous sentence, nor am I a lawyer. But basically when you aren't 100% sure that cdrtools entirely qualifies as "collective work", you cannot distribute *compiled* versions. (The derived vs. collective work part is a compile time issue; distributing the uncompiled source code should be okay). We need to be *really careful* here, and it seems best to go the safe way and NOT ship cdrecord. Sooner or later, he will have a go at us then, call us liars, claims that we broke his software, slandered his name as author, introduced bugs and so on. Like he has done to everyone else so far! You already have him seen attack just about everyone on this list the last weeks; are you sure you want to have him as upstream author? I'd not be willing to take care of a cdrecord package given an upstream this hostile. And since there is no other upstream author, there is noone else to talk to. Schily has also shown very unwilling to adopt cdrecord to the users; instead the users are expected to adopt to cdrecord. For example, he has always told people to use the SCSI emulation and SCSI-like device ids instead of accepting that some users prefer referencing devices by their unix path name such as /dev/hda in particular for non-SCSI devices. From a user perspective this makes a lot of sense to use the same device name for both mounting and writing CDs. If I understood the early fights correctly, such patches have in fact been one of the things that Schily hated about Debian and wodim. Wodim has worked correctly for me every single time. (I don't use blueray though)And the future solution should be libburnia, which is actively developed and seems to have a sane upstream instead of a madm^W^W Schily. So I see no need at all to go the risky way of "shipping" cdrecord. Wodim is okay as an interim solution, and libburnia is the way to go on the long run!There is a cdrecord-like wrapper in libburnia called "cdrskin" that is meant to serve as drop-in replacement for the "cdrecord" command. Regards,Ray -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org