Talk:Cdrtools/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

The true story

Most of what is currently in sections "Licensing issues" and "The invariant section" is only noise and serves the purpose of harming cdrtools.

Consider Novell openSUSE and Oracle Solaris. Both ship cdrtools. Do you think they would do so if there was any problem with cdrtools?

Let's take each point, one by one.

• Jörg's alledged attacks against the Linux kernel were just kind recommendations for users who had cdrecord 2.01 when an incompatible interface change took place in Linux.
• Jörg's warning to openSUSE users were just an attempt to obtain help from them in his difficult task (at that time, because the issue is now solved) of convincing openSUSE to avoid adding their patches. Jörg was not attacking anyone but helping openSUSE users to avoid using an unsafe (because incorrectly modified) software (one patch had introduced a security vulnerability).
• The cdrkit fork did not begin in 2006 but in 2003 (or even before, I still need to check). In 2003 there already were patches from Debian that broke cdrecord. Between 2004 and 2006 Jörg tried to have Debian either remove their patches or choose a name for their fork. The only way he found (in my understanding) was to switch the licence to CDDL. Otherwise Debian would have continued distributing modified (and buggy) versions of cdrtools without even informing their users that it was not the original software. Jörg just wants his software to be distributed without unapproved patches when it is packaged with its original name. Does Debian refuse to distribute Iceweasel because Mozilla does not allow the distribution of Firefox under that name? Jörg is being even more friendly than Mozilla, as he allows the distribution of unmodified cdrtools with the original name (just like Ubuntu ships unmodified builds of Firefox with Mozilla's agreement).
• The invariant section issue: that piece of code (and comments around it) was introduced in 2002, 4 years before the cdrkit fork was (officialy) created. So telling that the fork was done because of this invariant section is not honest.
• The CDDL versus GPL licence issue: this is just more noise to hide the true story. There are several CDDL-licenced software in Debian (e.g. Glassfish).
• The buildchain issue: Debian claims cdrtools cannot be distributed because it requires smake to build cdrtools. But this is not true. gmake is also able to build cdrtools. smake is only required on platforms where gmake is not available.

If you google a little bit, you'll find that many Linux users are saying they use Nero and have no problems with it. That's true. But with cdrtools you have a free and open source software.

You might say I'm not proving all I wrote. But I can (and will do it). It's just that it takes a lot of time to gather the right links.

The rest of the story is not glorious at all for some people, so I'd rather not give any details. If you know what I'm talking about and/or are in a position where you can help Debian understand what happened 10 years ago, please do so. Debian users should not pay for the errors a few people did and have been hiding all this time. Thanks.

Kind regards, Ekkt0r (talk) 07:09, 4 March 2014 (UTC)

Let me add some information for the Linux kernel problem:

Linus Torvalds introduced an incompatible interface change to the Linux kernel in September 2004, at the same time when the new stable release for cdrtools-2.01 was just ready. This (in the first step) could be seen as the result of "This happens if someone without any clue is given the permission to change the Linux kernel sources". But the problem has been discussed on the Linux kernel mailinglist and a vast majority voted to go back to the old and documented Linux kernel interface. So as Linus Torvalds ignored these votes and did not revert his mistake, this really is a hostile act from Linus Torvalds against cdrtools. Informing people about the reason for possible problems was of course needed. Schily (talk) 12:29, 4 March 2014 (UTC)

So, where are all the references that prove this true story? Surely there must be public records that all this happened? All this information is useless to the article without the references. Diego (talk) 17:47, 6 March 2014 (UTC)

Once you understand that most of the false claims from Debian and it's sockpuppets are based on attempts to reverse the timeline (in order to confuse cause and reaction) it is easy to look for hints that prove claims from Debian as false. You also need to know that there is absolutely no evidence for the claims from Debian. Repeating a false claim thousands of times does not make it correct, but Debian just uses copies of their false claims to "proove" their claims. So what remains? The only provable facts are that Debian started to attack cdrtools in spring 2004 and that Debian at the same time stopped distributing the original cdrtools in favor of their own defective fork from spring 2004 that was later reamed (on my instructions) in autumn 2006. No license problem was ever proven. Many Linux distros ship cdrtools. The larger distros even asked their lawyers for an OK that of course was given. Schily (talk) 10:22, 7 March 2014 (UTC)

Censorship - suppression of facts Schily does not like

This revert is a good example of how User:Schily suppresses facts that he does not want people to read.

His edit is described as "Revert the usual false claims from Chire. The package from Brandon Snider if course works on Mint". This is a lie. His edit is censorship.

However, he takes the chance to revert everything else, too, without actually reviewing them properly.

1. The first change acutally fixes an incorrectly spelled name, as well as an incorrectly titled reference. But as it adds the fact that Joerg Schilling never delivered the "evidence" for his claims (the "As of" part), this is of course not desired by Schily.

2. The following changesets remove incorrect "third party" repositories. With my changes, the Ubuntu repository is only used for Ubuntu. The RPMFind link - which only finds cdrtools 3.0 for OpenSUSE Factory, but not for other distributions - is also removed.

3. For completeness, I also added some more Linux distributions to the table, all of which are on Wikipedia already. This is also reverted, as none of them included cdrtools, which again is information that Schily doesn't want other to see.

As you can see, his edits are not at all good faith, but censorship.

--Chire (talk) 11:52, 7 April 2014 (UTC)

Finally stop your edit wars and your crusade! If there is censorship, then it is done by you as you removed correct information. Let me make it clear: if you again add a false claim to the article, I am no longer willing to check each single claim for correctness but I will revert all. You did wast too much time already! Schily (talk) 12:44, 7 April 2014 (UTC)

Edits by Chire

Chire, as I wrote in the summary of my last edit of the cdrtools article, the only part that needs to be re-written is the section about the licensing issues. There is absolutely no reason for putting a Cleanup-rewrite tag outside of that section. Regarding your WP:NOTMANUAL accusations, there are many other articles with similar content. All your edits serve the purpose of fighting and harming a CDDL-licensed project just because you don't aprove that license. Why don't you just ignore cdrtools and its licenses? Ekkt0r (talk) 20:02, 31 March 2014 (UTC)

Our problem is that we really have a problem with the licensing section and only with the licensing section. It turns out that most of the problems in that licensing section have been introduced by Chire and now exactly this user is complaining about the quality of the article. Chire, I recommend you to stop your vandalism. Try to find a job where you can do something that is worthwhile. You have no clue on licensing and on the social deficits of the persons from Debian that started to attack cdrtools in May 2004 and (most important), you are not willing to inform yourself about what happened. So you are not suitable for this article. Do yourself and others a favor and stop your crusade. Schily (talk) 21:22, 31 March 2014 (UTC)

No, the problem is that the article has become an unreadable mess, because you want to use this article for advertising your program, and to serve as a replacement homepage and documentation for cdrtools.

Contrary to your claims, I do not care about CDDL or not CDDL. CDDL is an accepted open source licence. It's not used a lot, as the prime example of CDDL - NetBeans and GlassFish - are even dual licensed with GPL. I was about to include OpenJDK in this list, but apparently it is only GPL, not dual CDDL licensed. Either way, I don't care about CDDL. I do, however, care for Wikipedia:READABLE, and I do care about Wikipedia:Conflict of interest and Wikipedia:Neutral point of view, amongst other Wikipedia principles; and this article has been notorious for COI edit wars long before I got involved.

But you don't understand what kind of information Wikipedia users care for. They don't care about MiNT, Haiku and Magnussoft ZETA, for example. In my opinion the version at the end of 2012 or end of 2007 had a much more appropriate article size. At that time, the article got to the point quickly, and actually encouraged the reader to get more information when interested.

But go ahead. Continue to further destroy your article to the point where you make any reader (or potential user of your software) flee in terror. Keep on adding a complete manual and version history of cdrtools, that nobody will ever read, and that should go to a cdrtools homepage instead. --Chire (talk) 09:41, 7 April 2014 (UTC)

Chire, may I ask you what you think people would think about you if they knew what you have been doing since 2006 (outside Wikipedia) to harm cdrtools?

By the way, there can't be any conflict of interest regarding cdrtools because this is free and open source software.

If you don't stop your attacks against this article I'll have to seek help from Wikipedia admins.

Ekkt0r (talk) 10:40, 7 April 2014 (UTC)

Good luck in finding any proof of what I did "since 2006 outside Wikipedia" against cdrtools (Wikipedia:No personal attacks!). Because there can't be any, as I didn't do anything. Why would I? As Schily would put it, this is slander, and you should be careful with this. I have not at all been involved in these COI edit wars I documented above. If I recall correctly, I got slowly involved in patrolling these articles in 2011... It's fairly easy to see that there is a number of distinct users that tried to keep the article in shape, only that one after the other gave up because of such personal attacks.

There is a certain paranoia involved in cdrtools. But let me assure you, that I'm not affiliated with any CD writing software. I'm not involved in the development of cdrkit or libburnia. In fact, my current laptop doesn't even have a CD drive anymore. I do fight promotional editing though.

Also, you can have a WP:COI, even when you are not a company. COI is not restricted to selling products. You could also do it for reputation, for example. In above examples, Schily more than once tried to remove links to cdrkit, which is pretty much the definition of a WP:COI edit; I am not making these things up: I have proof.

Instead of properly handling these issues, the two of you start personal attacks. This is bad style. Before you've been attacking User:Diego Moya in above paragraph, now you are attacking me personally, and threatening me with off-wiki attacks (Wikipedia:No personal attacks!). The two of you (?) attacked earlier editors attempting to keep the article in shape before. There is still proof of this happening to many editors that tried to keep the article neutral before: EagleOne, User_talk:Niten, Chealer, Fudoreaper, Saxifrage and probably many more.

Are you sure it is me that is having issues here? Or did you lose track of all your "enemies"? This sure is a long list, and these aren't sock puppets like the IPs that Schily used to attack them. --Chire (talk) 11:39, 7 April 2014 (UTC)

Chire, my previous message was not an attack. Your reply looks much more like an attack. But don't worry, I won't disclose any potential proof because I know it would be against the rules. Ekkt0r (talk) 13:17, 7 April 2014 (UTC)

Conflict of interest

There's an ANI discussion here regarding Schily conflict of interest in editing the contents of this article. Diego (talk) 22:32, 7 April 2014 (UTC)

Jörg may be in a conflict of interest, but he has been careful with own edits on Wikipedia. Chire definitely is more than in such a conflict. Chire is related to the people that started to attack cdrtools in May 2004 and he is on a very heavy crusade against Jörg and cdrtools since aprox. 2010. Chire is not only interested to harm cdrtools on Wikipedia, he also attacks cdrtools on the Bugtracking systems of Linux distros and he created hate a website against cdrtools and Jörg. Be careful with edits from Chire. — Preceding unsigned comment added by 2001:638:806:69:222:19FF:FE2F:1622 (talk) 13:23, 8 April 2014 (UTC)

Ekkt0r has asked me what I think about moving the Licensing issues to the talk page and work here toward making it neutral. I wouldn't mind removing from the article everything without a direct reference supporting it; but the bits that have direct support from an external source should remain as they are now, until we can agree on a new wording for them. Simply removing them would excise the only parts that make the article notable IMO. Diego (talk) 13:03, 9 April 2014 (UTC)

I believe we should at least remove all personal remarks in footnotes, such as "This claim is unimportant as the "work" mkisofs is 100% under GPL." (which clearly is the personal opinion of Schily), and instead move to an encyclopedic style that focuses on documented positions, i.e. essentially stating that "Debian, Ubuntu, Fedora, Redhat do not accept the license. Jörg Schilling disagrees with their interpretation of the license." With appropriate pointers to WP:Reliable sources that document each position. We should completely avoid to make claims who is more right than the other, but only prove that there is a disagreement. --Chire (talk) 08:50, 10 April 2014 (UTC)

All footnotes have been added to correct false claims in the article. If the related false claims are removed, the footnotes are no longer needed too. Schily (talk) 10:14, 10 April 2014 (UTC)

cdrecord packages for RHEL-based distributions

THe article cites rpmfind search of cdrecord as the packages of cdrecord for RHEL-clones (RHEL, Schentific Linux, Centos, anything else?). Those do include cdrecord packages. Up to RHEL4. Search results also come up with some OpenSUSE packages. Can anybody positivly confirm dcrecord supported in one of those distributions? If not, I'll remove them from the list. Tzafrir (talk) 23:39, 7 April 2014 (UTC)

Fedora, RHEL, Scientific Linux, CentOS, and Oracle Linux do not distribute nor support cdrtools. The packages available on rpmfind come from unofficial/3rd-party builds, and the table on the article makes this clear as the links are on the "3rd-party" column.

This means anyone willing to use cdrtools on these operating systems should grab the SRPM (i.e. the source-RPM) and build cdrtools with the cdrtools.spec file that comes in the source-RPM.

If you prefer to use source-RPMs from a distro that supports cdrtools (like openSUSE), you can get them from [1].

Please do not remove the links/footnotes about rpmfind, as this proves that unofficial/3rd-party packages for cdrtools exist for these distros. Thank you. Ekkt0r (talk) 00:34, 8 April 2014 (UTC)

I note the fact that Oracle's Linux distribution does not support cdrecord. Indeed I forgot that one.

IMHO, third-party support for those distributions would be a package in a yum repository that would be safe to add to the distribution and would work well with it. I would also preffer a popular and well-used one and not just a litttle PPA, as in the case for Ubuntu, but that's just me. Support in a distribution also means providing updates.

Likewise the install instructions on the Ubuntu PPA will not work for Debian. Claiming that it is an "unofficial support for Debian" is a bit of a stretch. Tzafrir (talk) 11:19, 8 April 2014 (UTC)

If you have to run "dpkg-source" or build an SRPM yourself, they are not available precompiled, as a matter of fact. From a user point of view, the PPA web page only gives Ubuntu precompiled packages, and the rpmfind only finds the official OpenSUSE packages. Please, approach this from a Wikipedia reader point of view, not from an advertisement point of view. A reader cannot find a obviously working download for Mint on the given web page etc. Eventual compatibility (choosing the right Ubuntu version to match your Mint version) is WP:OR, and the reference should be removed, too. --Chire (talk) 11:56, 8 April 2014 (UTC)

Thanks. If there's no reasonable counter argument I'll remove Mint and Debian as "third party". As COI was raised, I'll just note that I'm a Debian user and developer (I don't think it matters, and I try to stick to the facts, but just in case someone thinks it does). Tzafrir (talk) 13:53, 8 April 2014 (UTC)

Tzafrir (talk) as a side note... You recently removed pointers to binary packages for some distros. Please be collaborative and when you see incorrect pointers, do not remove them but replace them by correct pointers. This are of course precompiled binary install pacakges for cdrtools related to most distros. For Redhat/centos, there is e.g. [2]. Schily (talk) 12:01, 10 April 2014 (UTC)

Hi Schily. Thanks for providing useful information in the talk page. As you can see in the history, the information I removed was a link to rpmfind. However the link you provide is a link to what looks like a decent yum repository. I'll add it as a third-party repo for RHELs and Fedora unless someone beats me to it. I hope you don't mind if I move your other comments to a different section to keep this section to the point. Tzafrir (talk) 16:13, 10 April 2014 (UTC)

False SCSI related claims in the licensing section

Moving Schily's comment from the section above to a new section with a new and arbitrary title and adjusting depth. Context: in the comment below "you" is me (Tzafrir). Tzafrir (talk) 16:24, 10 April 2014 (UTC)

One of your contributions ([3]) is definitely extremely unbalanced und not tolerable, so there is a COI. Without this note, I would believe that this was intentional, but with your note, it seems that you are just missinformed by anti-OSS people like redacted... Let me explain in detail:

• The text in the mentioned diff does not belong into the licensing section at all. It may be a candidate for the critisizm section on the Debian article (to explain problematic behavior of Debian against cdrtools, firefox, ...) after it has been corrected to reflect the truth.
• The named text tries to belittle cdrtools with false claims, so let me give the correct background information:

1. All CD/DVD/BD drives ever made are SCSI devices.
2. ATAPI is just one of many SCSI transport mechanisms and while ATAPI is fully integrated into the SCSI stack on Solaris x86 since 1993, this was not the case on Linux in 2004. This is a design problem on Linux.
3. Cdrtools is highly portable to ~ 30 different platforms (not counting different CPUs separately) and the man page mentions that it grants equivalent behavior on all supported platforms
4. The vast majority of all platforms do either not have device nodes at all or do not have a 1:1 relation between a specific device node and a specific SCSI device. Win-DOS and Mac OS X both do not have device nodes for SCSI devices, so 99% of all computers in the world cannot use device node based SCSI addressing.
5. 3) and 4) make it obvious that you cannot use device nodes in a portable implementation and that only the official SCSI addressing scheme is portable across platforms.
6. In September 2004 Linus Torvalds introduced a fatal Linux kernel SCSI interface incompatibility while claiming to fix a security bug. This incompatibility was introduced exactly when a new stable cdrtools relase was puiblished after a long time of bug fixing and code freeze in cdrtools.
7. The patches from Debian (redacted) that you seem to reference and that have been published in 2004 are full of bugs. In Spring 2005, there have been aprox. 150 unique bug reports against cdrtools in the bug tracking systems of various Linux distros. Nearly 100 of these bugs have been a result of the patches from redacted. The other 50 bugs have been fixed in the original code between September 2004 and August 2006 after Debian stopped updating their source. BTW: As there is no development activities on cdrkit since May 2007, the vast majority of these 150 bugs is still present in the defective and dead fork from Debian. In special, there is no code in the Debian fork that works around the SCSI interface incompatibility mentioned in 6).
8. cdrtools is a really openminded project. Any patch that was send and that follows the quality requirements in the CONTRIBUTING rules has been accepted. The patches from redacted did not follow the quality rules. The cdrtools project does not accept patches that harm the code - sorry, but this is needed if you like to give long term support for a program. Note that the first libscg code was written in August 1986 (28 years ago) and that I have other OSS (e.g. star) that is maintained since 32 years.

This list of explanations can be found in the internet if you use a search engine...I did write it many times in similar wording in the past after people came up with similar false claims. Please also note that the fork from Debian was started in May 2004 - 10 years ago. When Debian claimed to start their cdrkit fork in late 2006, they did just change the name on my request. So this cdrkit includes all bugs that have been introduced by Debian since early 2004. Cdrkit did never publish a release that has no known bugs at the time of being published, so cdrkit did never raise above alpha-release quality. As your request looks collaborative, I am sure that you understand that you have been fooled by unfriendly people and fully remove the paragraph in question. Schily (talk) 10:09, 10 April 2014 (UTC)

Schily, by now it is exceedingly clear that you don't understand Wikipedia policy, have no idea of how Wikipedia articles are written, and behave in a way unconcerned to the utmost severity of your conflict of interest. In particular, whether a particular assertion is true or false is of no relevance for including it; what matters is that it has been made by a reliable source, and that it's relevant to the topic. So please do us all a favor, open the WP:Verifiability page, and study it until you understand it from the bottom of your heart; the other content core policies should follow this one.

From now on I expect on you that you don't touch the article's content with a 10 foot pole, and that you limit to propose changes at this talk page. Every change thus proposed must have a link to the exact URL (neither a search engine query, nor writing directly some "background information" to the article or Talk) of a page that includes the exact same words, adjusted for grammar, that you want to include; other editors here will debate whether the source is reliable, and whether it's relevant to the article; in which case we will decide the words with which to include the reference. Every time you make a revert, add or remove a single character from the article I will notify you to the COI noticeboard (which will likely get you blocked again), as maybe I should have done long ago.

I hope that you keep collaborating with us to enhance the article by behaving in a collaborative way, and avoid becoming a source of conflict by agreeing to these terms, which are no other than the communal consensus of how any editor in your situation should behave. Diego (talk) 11:32, 10 April 2014 (UTC)

If you believe that it does not matter whether some text in WP is correct or wrong, you seem to totally miss the way an encyclopedia is created. Important are verifyable facts and the current main text (disregarding footnotes) in the article in the licensing section is verifyable wrong and in addition offensive against cdrtools. I hope that you help to correct this. Schily (talk) 11:56, 10 April 2014 (UTC)

Now please don't misinterpret my words: of course it matters whether Wikipedia content is correct or wrong; if you re-read my words, you'll find that I didn't state that it doesn't matter. What I mean is that it doesn't matter for including it, i.e. we don't remove content merely because it's wrong; and we don't do so, because whether something is "right" or "wrong", "true" or "false" is not something that can be decided in a clear-cut way, and will vary for different people or contexts; in this respect, Wikipedia approach to correctness is rather constructivist.

If you read Wikipedia:Verifiability, not truth essay, it will explain why this is the chosen criteria for what to include. The way this particular encyclopedia is created is by ensuring that everything, and I mean everything included in its articles must be traceable to an external reference that editors consider reliable. The people who spent years deciding how to write articles decided that "verifiably wrong" is still "verifiable" and therefore must be included at the relevant articles, no matter how offensive some people may find it; offending people is merely a secondary concern, that we only take into account as long as the topic is otherwise properly described.

I see above that you recognize how the footnotes are not verifiable; I hope that you will now understand, in the light of the Verifiability policy that you and I are compelled to follow, why those notes must be removed until a reliable source is found for each one of them. Diego (talk) 12:49, 10 April 2014 (UTC)

Don't understand me wrong.... there is no problem with including the claims from Debian/redacted, etc. but they need to be marked as verifyably wrong. The principle of an encyclopedia is that it has to be balanced and if the mentioned claims stay uncorrected, this would cause an unbalanced article. Schily (talk) 13:50, 10 April 2014 (UTC)

You're right about the need for balance. But to mark claims as verifiably wrong, they need to be verifiably wrong - as in, "a reader can verify it by following the available references". As the notes are unreferenced, readers won't be able to verify them and thus should be removed. Diego (talk) 15:22, 10 April 2014 (UTC)

So we seem to agree basically. A claim that can be verified by a trustworthy pointer can be seen as true. A claim that can be verified as false can be seen as false and other claims are obviously in an undefined state. Each claim that makes it into the new licensing section should be marked that way.

What we need to agree on is what can be seen trustworthy. Unspecific statements like the ones on the FSF website that are e.g. neither explaining the exact constraints nor contain a reasoning cannot be seen as trustworthy sources. Sources from laymen such as Mr. Corbet represent no more than a personal opinion that does not belong into this article. On the other side, we need to take into account that a lawyer is not allowed to speak about any internal result from the discussions with his client. They may only tell you the final result or even nothing, but the fact that e.g. Sun legal, Oracle legal and SuSE legal did all give their OK for cdrtools verifies that there is no legal problem - in special as the companies this way express their opinion that there is no risk on a lawsuit.

Note that soneone who likes to express his doubt on the legallity on the other side needs to present a valid legal reasoning. If he is not able to present such a reasoning, his clains must be seen as no more than libel and slander. This may look unbalanced, but sorry - this are the legal rules from law. A laywer that discloses internals from a client will go into prison for 1-2 years, depending on whether the disclosure was made in order to harm his client or not. A company that asked their lawyers and ships cdrtools verifies that there is no risk. A company that does not ship cdrtools does not verify anything. Schily (talk) 16:54, 10 April 2014 (UTC)

See, this is another example of how your involvement makes you misunderstand the purpose of the article and how it should be written. Wikipedia can't and shouldn't try to offer legal advice, so the actual status of distributing cdrtools is not something that we can ascertain; again, The Truth is not relevant to how we write the article. If a lawyer makes a public stance about it, we can include it; if not, we can do without it.

What is relevant, as it affected the story of the project, is that many distros decided to drop cdrtools, claiming that it was as a result of the change in licensing and the problems they found in collaborating with you. We therefore document what happened, and the reasons they stated for their decision. Any source is reliable for claims about their own opinions, so the reasons why they changed to cdrkit are verifiable and can be included, irrespective of how they arrived to them or whether they correspond to copyright law.

As of the need to counter-balance those claims, that's true, but to a point; there's no need to insert a rebuttal for every claim as you did. Neutrality requires that, if there are conflicting views, each one is document giving them weight according to their prominence; and your position about what the new license implies is already included in the article. But your position is ultimately not that relevant in most cases for the distros that dropped the software, as they decided to follow their own criteria anyway. So we'll include just those high-profile cases were you or their lawyers managed to convince them, such as Suse, or those that were covered by independent third parties as proof of their relevance, as with Debian. Diego (talk) 18:45, 10 April 2014 (UTC)

And please, I insist that you review the WP:Verifiability policy again. You use the word with a totally different meaning that what the policy says. Diego (talk) 19:16, 10 April 2014 (UTC)

Earth is proven to be not flat, but Flat Earth is well acceptable for Wikipedia. Similarly, Wikipedia may state beliefs about cdrtools even if you disagree, and you believe they are proven false. Because a lot of people apparently disagree on your perception of truth, sorry. So far, the only proven thing is, that you disagree with some of these statements. I don't think we need to annotate every single one with your believes on their truthfulness. It is sufficient to state that there is position A, and there is position B, and neither is actually proven correct so far. There is plenty of evidence on the disagreement fact, though. --Chire (talk) 16:38, 10 April 2014 (UTC)

I added the paragraph to give some background. The "licensing" section should really be part of a "history" section. If its content weren't so sensitive, I'd remove it and rewrite it as a history section. Tzafrir (talk) 16:31, 10 April 2014 (UTC)

As the issue still persists, I don't think it is good to move it into history. Large parts could go there, but the fact that major Linux distributions do consider the licensing undistributable is not history. --Chire (talk) 16:38, 10 April 2014 (UTC)

I want to start from a decent history section. This would clear the licensing section from being also a history section. For starters, and objection for renaming it to plainly "History"? I like shorter section names. Tzafrir (talk) 16:46, 10 April 2014 (UTC)

Then this section should be emptied and filled up from scratch with every statement discussed before it goes into the article. Schily (talk) 17:01, 10 April 2014 (UTC)

Before doing that, I want to experiment with colaborative editing on the History section. If I see we get along well then sure - great. Tzafrir (talk) 17:09, 10 April 2014 (UTC)

More to the point: comment (1) from Schily was is completely correct. I fixed the text. The other comments seem to me irrelevant: the fact (verified by the external link I provided) that Linux distributions had to carry their own fixes to cdtools, of which the upstream author was not happy. I could go into the larger questions of portability, or distribution-upstream relations, but this is not the scope of the article. Any other relevant comments? Tzafrir (talk) 17:09, 10 April 2014 (UTC)

What you call fixes was introducing bugs and if you look on the bug tracking systems of the various Linux distros, it is easy to verify that these patches introduced the bugs as there are many reporters that also confirm that there is no such bug when using the unmodified original source. So please remove your false claims before we start other edits. Schily (talk) 18:04, 10 April 2014 (UTC)

A software that has users has bugs (Any software. Except Mutt). Thus the count of bugs is not a good indication. Linux distributions apply changes (patches) for various reasons. The article already states that you rejected those patches. Tzafrir (talk) 18:56, 10 April 2014 (UTC)

I am talking about the patches you mentioned in your recent edit and these patches have absolutely no benefit, so they only introduce plenty of well known and well documented bugs.

One problem caused by these patches is e.g. that Linux in 2004 offered three competing driver implementations - each with different bugs - and an original cdrtools version (used as proposed in the man page) automatically selected the best driver interface available, while people who give a device node name force libscg to use a specific driver. As users used the /dev/* name they best know, they forced cdrecord to use the worst driver interface. Users that used the original code and followed the man page used the SCSI address triplet and this causes libscg to auto-select the best available driver interface.

But it seems that you are missinterpreting the rules for Wikipedia. I disproved the correctness of your claims, but this was a curtesy to you. I don't need to prove anything. You on the other side like to add new text and so it is your task to prove your claims. Please note that Wikipedia is not intended to give average people a platform to express a personal opinion. Your unproven (false) claims are however no more than the personal opinion of User:Tzafrir and this opinion has no relevance to the cdrtools wikipedia article.

To make thing simple....less is more why not removing all the mess and all false claims from the licensing section and using a simple text like this:

Cdrtools have originally been distributed under the GPL but the project members discussed a move to a more liberal license since year 2000.

On May 15 2006, most of the sub-projects in cdrtools have been relicensed to use the CDDL with permission of its authors. This was triggered by social attacks from Debian that started in May 2004 and that have been changed in 2005 into attacks using a false GPL interpretation that would (if this GPL interpretation was applied to Linux distros) make all Linux distros illegal. As there was no help from GPL people to defend against these attacks, the GPL was no longer a choice for the project.

Like a typical Linux distro, cdrtools is an aggregation of several separate works with different age that respectively are all completely under a single license that was selected separately for each specific project. No license merge appears within a single work. A fine grained list of the licenses can be found in the file COPYING in the top level directory of the project.

Using this text removes all the current mess and the text roposal from above is what the various legal departments (Sun, Oracle, SuSE, ...) wanted to have for their license review before they did give their OK for shipping cdrtools in their distros. Schily (talk) 10:34, 11 April 2014 (UTC)

Resources

An early resource: [4] Proof of fork in October 2001 with DVD writing support. --94.216.197.194 (talk) 20:24, 14 April 2014 (UTC)

Supported Platforms

The list of supported operating systems seems to include some operating systems that are quite dead. Are all of those tested to build the latest version? The wording hints so by the verification comments in the note don't claim so. Some of those platforms indeed have well-supported and maintained packages. Specifically: SunOS-4.x, Rhapsody, BSD/OS, Tru64 UNIX, NeXTSTEP, AmigaOS, magnussoft ZETA, MiNT. I don't follow any of them closely, so they they all may actually have a working and up-to-date package. But the sources in the article don't reflect that. Tzafrir (talk) 18:47, 10 April 2014 (UTC)

What's the problem with listing old or dead operating systems? Do you really think that for these old or dead OSes it is so important to know exactly which was the last relase of cdrtools that worked fine on them? It is very likely that newer releases of cdrtools still compile on all old or dead OSes. If you prefer, I can add a footnote to make it clear that for these old or dead OSes, the release of cdrtools at the time the OS died is the one that was verified to build and work. Reducing the list because an OS is old or because the references come from the official site looks to me like censorship. BTW, I've seen build logs of cdrtools on old or dead OSes on the internel, but I don't think adding them would improve the quality of the article. The list of supported platforms is not invented, and everyone knows it and knows it can be proven false if false. If you think the primary sources are not reliable, then there is a big problem with a lot of articles. Ekkt0r (talk) 04:20, 11 April 2014 (UTC)

The question is: is it of interest to the majority of Wikipedia readers of this article, or should it go into the software documentation on the homepage of cdrtools. The Wikipedia article must not attempt to be a manual. There is Software Wikia (Suggested by Wikipedia:WikiProject_Software#Announcement for information that is not notable enough for Wikipedia. Although IMHO, the cdrtools homepage is the better place to collect such information; we should try to keep the article in a reasonable size. For example, the Wikipedia:Notability_(software) guideline says, the articles should not have "Lists (release logs) of every released version". The same probably applies to "lists of every supported operating system". The Mozilla Firefox article is given as a good example. It also does not list every supported operating system. Now Firefox is obviously very notable, which makes the History of Firefox a worthy article on its own; I doubt we need a History of cdrtools, though. The short message is: Wikipedia doesn't need to be exhaustive. For complete information, readers should refer to the original sources instead. The best source for cdrtools history would be a well-kept homepage; and it certainly could be improved a lot. --Chire (talk) 08:13, 11 April 2014 (UTC)

There's also the issue of correctness. The section claims that those platforms build cdrtools of current version but the references it cites only support the fact that those platforms used to be supported at a certain point in the past (sometimes: over 15 years ago). Tzafrir (talk) 12:48, 11 April 2014 (UTC)

If you change code the way, redacted did, you of course loose portability immediately (cdrkit did not even compile on many Linux based systems after he startet his changes), but if you know how to code in a portable way and how to test on a regular base, such poroblems are unlikely to happen. Schily (talk) 13:03, 11 April 2014 (UTC)

Tzafrir, Wikipedia is not intended to please the majority. Moreover, you cannot know what readers want to see when they come to Wikipedia. So any attempt to limit an article to what one thinks is important is just censorship. There are many articles with much more information than this one. If you think the project's homepage is a better place for some of the information currently in this article, let me tell you that there is absolutely no consensus on this. BTW, the fact that there are very few editors really trying to improve this article does not mean that it is not interesting "enough". Thank you. Ekkt0r (talk) 21:31, 14 April 2014 (UTC)

Both of you did not answer to my point. I'll just point out that cdrtools' build system also cchanged in 2006 (switched to using smake, IIRC). Many of the platforms here don't have a reference for building it later than the switch of the cdrtools build system. Tzafrir (talk) 11:41, 16 April 2014 (UTC)

Where did you get this false claim from? The schily makefile system exists since February 1993 (when Solaris x86 has become available). It is based on prior work from Simon Ney that started around 1990. The schily makefile system supports all make implementations that support suffcient POSIX compliance plus some enhancements (include statement and pattern macro expansions). The schily makefile system is under constant develepment in order to keep it abreast of the times. The usabbility of different make programs of course is limited to the availability and usability of these make implementations on different platforms. Sun-PRO-make is e.g. only available for Solaris and Linux. Gmake is not usable on many platforms where it compiles.

Smake exists since ~ 1982-1984 and was written as a proof whether I understand how make works. I planned to let it die in the mid 1990s but in 1997, cdrtools have been ported to many non-UNIX platforms (e.g. OS/2) and it turned out that gmake has many bugs that prevent it from working correctly on various platforms. Since then, smake is the preferred make program, as it is known to be highly portable and not to have problems related to the schily makefile system. Due to the built-in automake features, smake allows the schily makefile system to work even on prior unknown platforms (this is something the GNU build system cannot deliver) in case the bootstrap version of smake is included in the sources (see the schily source bundle). As people who like to port cdrtools to a new platform, start with the schily source bundle, they start with smake. The schily makefile system (when used with smake) supports more target platforms than the GNU buildsystem.

2006 is no year with special changes in the schily makefile system and the published (external) versions of cdrecord/cdrtools use the schily buildsystem since a few weeks after Linux support was added besides Solaris (the schily makefie system was introduced in cdrecord with cdrecord-1.3 - May 1997) Schily (talk) 12:38, 16 April 2014 (UTC)

Distribution derivatives

The "binary packages" table lists many distributions. In many cases these distributions are derivatives from a other Linux distributions. If a distribution is derivative from another one and does not change anything in the maintenance of the cdrtools package: no point in listing it: all the RHEL clones share the same cdrtools binary packages. Pardus originally used the Gentoo package and now it is a Debian derivative and does not have a package, just like Debian. It seems that almost all the ArchLinux, Gentoo and Slackware derivatives listed here don't maintain their own packages but use the one of the parent distribution. However I'm not wwell familiar with those distributions, so I may be wrong here. What do you think? Tzafrir (talk) 13:29, 11 April 2014 (UTC)

Yes, the list should contain only those distribution that create their packages themselves, not those that merely repackage the compilation made by others. This would make it easier to find which distro is the source for each packaging. Diego (talk) 14:10, 11 April 2014 (UTC)

Come to think of it, I don't think a table is the best format to describe it. The information in the table is better written in a single paragraph (or a few). Here is a shot.

cdrtools is prepackaged in several Linux distributions (mainly OpenSUSE, Arch, Gentoo, Slackware and their derivatives). It is included in all the BSD distributions (FreeBSD, NetBSD, OpenBSD, etc.). Third-party repositories are available for some of the other Linux distributions (Ubuntu, RHEL, Fedora) as well as for Mac OS/X and for Windows.

Not well phrased, but you get the idea. What do you think? Tzafrir (talk) 15:08, 11 April 2014 (UTC)

As iterated a number of times, I believe this information should be kept on the cdrtools homepage. The cdrtools homepage should have a "download" page, that lists source code as well as packaged versions that are deemed "acceptable" by User:Schily. This also gives him control over which versions he includes. Because, eventually, there may be some "bastardized" cdrtools again! He can then easily remove such a variant from his own list. For Wikipedia, it should be enough to link to the download page! --Chire (talk) 17:20, 11 April 2014 (UTC)

The cdrtools homepage is a homepage for a highly portable sourcecode. It does not prefer specific platforms, so it does not list binaries for specific platforms. This is like POSIX is a standard that explains how portable (to certified platforms) sourcecode has to be written. For the same reason, POSIX does not mention path names except for /dev/null and /dev/tty.

Creating download pages for binaries is the duty of the various distros.

Bastardized variants are created by people that have more self-confidence than knowledge. I would not expect this skill on platforms other than Linux. There are currently only two examples for heavily bastardized variants:

• Number two on the ranking by damage: The SuSE programmer that discovered how to send file descriptory via sockets in 2001 and believed to be a security expert for this knowledge. He created a real security mess and a few other problems.
• Number one on the ranking by damage: The Debian packetizer redacted that discovered how to call make in 2004 and then believed to be a C and SCSI expert with more knowledge than the authors of cdrtools. He managed to add aprox. 100 own bugs within a year and wins a price for the best long term support in preserving bugs over 10 years.

Fortunately, there is a sufficient number of people that care about usability... Schily (talk) 19:00, 11 April 2014 (UTC)

Ekkt0r, would you be willing to set up a community web page for cdrtools (say, a Wiki or something like this; maybe on Sourceforge or Github or Wikia - something that people can easily edit; without logging in, or where they may already have an account anyway)? A web site where the cdrecord users community could collect e.g. links to binary download locations, instructions for compiling cdrtools, command line usage examples, etc.? IMHO such a site is needed anyway, and some of the contents from the article would be better of on that site than on Wikipedia in my opinion. There is enough content for multiple pages: version history, command line examples, download, build instructions, ... You do seem to have interest in building a collaborative cdrtools community. --Chire (talk) 08:01, 14 April 2014 (UTC)

Chire, what I wish is to be able to edit this article without having to fight against censorship. Removing rows from a table because an OS is not on DistroWatch or because it is not used by many people is what I call censorship. Here are some such edits by you and Tzafrir:

Date	Editor	Delta	Your edit summaries	My comments
2014-02-24	Chire	Δ1	Drop all non-wikipedia-relevant distributions, that only serve the purpose of inflating the unreadable table. Unfloat, because of layout problems (too little text for a float)	You removed several rows (KaOS, Kwheezy, magiclinux-plus, openmamba, Ramone Linux, roblinux and SlavankaOS), claiming they are not relevant for Wikipedia. After that, I added a section on the talk page explaining why part of your edit was censorship and then partially reverted your edit, providing (in my edit summary) a pointer to my explanation on the talk page.
2014-04-07	Chire	Δ2	Remove speculation that the Ubuntu PPA packages will work for Mint or Debian, as well as rpmfind (which only finds OpenSuSE Factory!) Add Grml, Mandriva/Mandrake, Skolelinux, Knoppix while at this table anyway.	On the very same table you had unsuccessfully tried to remove several rows (see Δ1), you added several other OSes (Grml, Knoppix, Mandrake, Mageia, Skolelinux) which do not ship cdrtools and are therefore not relevant for that table.
2014-04-07	Chire	Δ3	Restore edits that User:Schily reverted with a false edit message - he obviously is doing WP:COI edits, and promoting his software with false claims.	Same comment as for Δ2.
2014-04-08	Tzafrir	Δ4	removed roblinux - broken link. Not even on DistroWatch. Don't provide source (as required by license).	First, the link is not broken. Second, removing that row just because the distro is not in DistroWatch is what I call censorship.
2014-04-08	Tzafrir	Δ5	removing ramonelinux - likewise (Δ4)	Same comment as for Δ4 (with a different link).
2014-04-08	Tzafrir	Δ6	Removed Gentoo/FreeBSD - not an independent project	Gentoo (Linux) and Gentoo/FreeBSD are from the same project but have a different kernel, so both are relevant for the table.
2014-04-09	Tzafrir	Δ7	Pardus: now based on Debian (and not Gentoo) and thus does not include cdrtools	The fact that a distro is based on Debian does not imply that it does not ship cdrtools. Pardus distributes both source and binary packages of cdrtools. Update: Pardus did ship cdrtools (until 2011), but did not update the packaging after that distro became Debian-based. So the removal of Pardus from the table is OK.
2014-04-08	Tzafrir	Δ8	No summary (other than the section title)	This edit adds a pointless "note" (about the cdrtools package on Arch Linux) which states that the installation of K3b or Brasero pulls that of wodim by default. It tends to belittle cdrtools by suggesting that K3b and Brasero prefer cdrkit over cdrtools, which is false because the dependencies are part of the package, not of the source tarball. The note is also unbalanced because it does not say that cdrecord can be safely used by K3b and Brasero. If not removed, this note should be rewritten and moved inside a proper footnote.

There are many articles with much more similar information and I would really appreciate if you and Tzafrir could let me add the rows you have removed. Thanks. Ekkt0r (talk) 21:31, 14 April 2014 (UTC)

Maybe these articles should then also be trimmed to what is of encyclopedic relevance, too! Plenty of articles are not good. Let's take Mozilla Firefox as a reference, this is a reasonable quality article. Does Mozilla Firefox list every Linux distribution it is available on? (see Mozilla Firefox#Platform_availability - it doesn't) How about PHP, a "good" article? Nope, it just says "cross-platform". How about OpenBSD (which is a "featured article", i.e. highest quality) - what does it say about supported platforms? It lists about half of the supported CPU families and an "other" link pointing to the OpenBSD homepage. Then why should cdrecord? Wikipedia:Relevance of content applies to within-article content; support for obscure operating systems or linux distributions is not relevant. Because, again, Wikipedia is not a manual. Removing details that lack WP:Significance is not censorship (in particular, I would agree with a link to a download list!). It's keeping the article focused and to the point (and this article is really bad in this respect). If you want a cdrecord manual and reference, make a cdrecord homepage, but outside of Wikipedia. IMHO this would be a good thing (which is why I proposed it above - and I would welcome a link to such a page).

If you want to continue this discussion, how about asking Wikipedia:WikiProject_Software for a third opinion, whether they consider such fringe Linux distribution download locations relevant, or if this information should go to the cdrtools homepage! --Chire (talk) 11:48, 15 April 2014 (UTC)

Hi Tzafrir, may I revert deltas Δ6 (about Gentoo/FreeBSD) and Δ7 (about Pardus) listed on the table above? Thanks. Ekkt0r (talk) 05:57, 18 April 2014 (UTC)

• Gentoo/FreeBSD: it's just a port of Gentoo. Much like Debian/kFreeBSD. The whole point of the project is being able to use the rest of gentoo (namely: portage) with minimal changes. I can't find any fbsd-specific Gentoo ebuild.
• Pardus: the links you point to are to Gentoo-based packages (see the history in that article). The distribution has since been recreated as a Debian-based distribution. They got the cdrtools package "for free" from Gentoo, and they did not bother including it explicitly in the Debian-based distribution.

That said, I generally agree with Chire above, which is why I did not answer to specific arguments before: this long list does not belong here. Tzafrir (talk) 08:36, 18 April 2014 (UTC)

The old pardus package is also version 3.01 alpha4, which is around 2004? Have you verified it isn't actually cdrkit, or contains any of the bastardized patches? What good is it to list a 2004 package? If people want to download a precompiled binary, they want the latest, not a 10 years old version, that does *not* support DVD or BD as advertised in this article. --94.216.77.27 (talk) 08:40, 18 April 2014 (UTC)

With proper research, this mistake could have been avoided, or was it not just a mistake?

You are however correct with your claim that nobody likes to have a variant from 2004 that does not include support for DVD and BD. This is why Debian users are unhappy with the infantilizing that tries to prevent them from getting up to date software for optical media and delivers "cdrkit" instead. But three year old software is still much better than what you get with Debian. Schily (talk) 14:30, 18 April 2014 (UTC)

Actually, cdrkit works perfectly for me. I have yet to encounter a single bug. It worked literally 100% of the time I used it. I only install software from trusted sources, so your homepage is ruled out, as are any "rpmfind" resources, sorry. --94.216.78.182 (talk) 01:33, 21 April 2014 (UTC)

If you only use the programs with the option -version, your claim that "cdrkit works perfectly" is of course believable. If you look at the 150 unfixed bugs for cdrkit in the bugtracking systems of the various Linux distros, you see that the real world has a different reality than yours. Well, you may need a wayback machine today as the entries have been removed without fixing the bugs.

If you ask people that need a working toolset (like Klaus Knopper or Michael Prokop) they will tell you that they use the original cdrtools for their private tasks.

Back to your interpretation of wikipedia, should't we delete the "Debian" article from Wikipedia because Debian did not update cdrtools during the past 10 years? It seems that Debian is out of encyclopedic interest from a view of today. Schily (talk) 11:48, 21 April 2014 (UTC)

I never asked Klaus Knopper, but the packages in Knoppix 7.2 (currently the latest) include libburn and wodim (and dcrecord as a dummy package provided by wodim). The remastering HOWTO on the Knoppix wiki suggests using genisoimage. I didn't bother checking Michael Prokop, but Grml was listed in the table before as a distribution without cdrtools binaries. Now, could we please move this table to an external site? Tzafrir (talk) 23:05, 21 April 2014 (UTC)

Sorry Tzafrir, there is no valid reason for removing the table of the "Availability" section. Chire, 94.216.78.182 and you have already removed several lines. Removing the whole table would be just censorship. This list is perfectly relevant. Moreover, it is quite small. There is absolutely no consensus for the removal of the table. It should stay there. Ekkt0r (talk) 07:46, 22 April 2014 (UTC)

I also do not agree with this edit (by 94.216.78.182) which removed 2 popular distros (Debian and Linux Mint) just because there are no official binary packages (of cdrtools) for them. The table gives an overview of which majors distros ship (or do not ship) cdrtools, as well as a small list of less popular distros that ship cdrtools. Again, this is very valuable information for many readers. Ekkt0r (talk) 08:28, 22 April 2014 (UTC)

You disagree with everything anyway. Just above (Δ2), you complained that I added "several other OSes (Grml, Knoppix, Mandrake, Mageia, Skolelinux) which do not ship cdrtools and are therefore not relevant for that table", now you want some distributions that satisfy the same property to be included? Grml, Knoppix, Mandrake/Mageia are also very popular; definitely more popular than various of the obscure distributions you added to the table (Mageia is #4 on distrowatch! So it's not about popularity then, either?). I have the impression that you want the table to just say "everybody except Debian and Redhat is stupid"; but that is not an acceptable rule for Wikipedia, you know... To make the table actually useful, it should also include the version number. Because I'm pretty sure, half of the entries listed is outdated... but again: the whole table is not relevant for Wikipedia, it should go to the cdrecord homepage. --Chire (talk) 09:20, 22 April 2014 (UTC)