Reindl Harald h.reindl@thelounge.net wrote:
Please do not write false claims!
says the one on his fight against Linux and GNU since years
Do you like to prove that you cannot stay with the truth?
You also wrote a false claim.
Jörg
Am 20.08.2013 10:47, schrieb Joerg Schilling:
Reindl Harald h.reindl@thelounge.net wrote:
Please do not write false claims!
says the one on his fight against Linux and GNU since years
Do you like to prove that you cannot stay with the truth?
You also wrote a false claim.
Jörg
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 ad+lists@uni-x.org wrote:
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.
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örg
On 8/20/2013 1:47 AM, Joerg Schilling wrote:
Reindl Haraldh.reindl@thelounge.net wrote:
Please do not write false claims!
says the one on his fight against Linux and GNU since years
Do you like to prove that you cannot stay with the truth?
Is your code and its dependencies entirely GPL licensed? The allegation was that some of it is CDDL, which is problematic.
John R Pierce pierce@hogranch.com wrote:
On 8/20/2013 1:47 AM, Joerg Schilling wrote:
Reindl Haraldh.reindl@thelounge.net wrote:
Please do not write false claims!
says the one on his fight against Linux and GNU since years
Do you like to prove that you cannot stay with the truth?
Is your code and its dependencies entirely GPL licensed?
Is your favorite Linux distro entirely GPL licensed?
The allegation was that some of it is CDDL, which is problematic.
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örg
On Wed, 21 Aug 2013 13:25:23 +0200 Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de wrote:
John R Pierce pierce@hogranch.com wrote:
The allegation was that some of it is CDDL, which is problematic.
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.
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 vvmarko@gmail.com wrote:
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.
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.
software as you see fit, they equally have the right to not like your license and to boycott your software because of it.
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örg
Hello Joerg,
On Wed, 21 Aug 2013 18:09:10 +0200 Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de wrote:
Marko Vojinovic vvmarko@gmail.com wrote:
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.
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.
software as you see fit, they equally have the right to not like your license and to boycott your software because of it.
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.
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örg.
Regards,
wwp subscript@free.fr 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.
software as you see fit, they equally have the right to not like your license and to boycott your software because of it.
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.
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örg.
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örg
On Wed, Aug 21, 2013 at 11:09 AM, Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de wrote:
Marko Vojinovic vvmarko@gmail.com wrote:
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.
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.
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 lesmikesell@gmail.com 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.
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.
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örg
On Wed, Aug 21, 2013 at 11:42 AM, Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de 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.
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.
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.
Umm, have they dropped perl?
The GPL is discouraged by Debian...
You should think aboiut why you did not help to defend the GPL in 2005.
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.
Les Mikesell lesmikesell@gmail.com 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.
Umm, have they dropped perl?
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.
The GPL is discouraged by Debian...
You should think aboiut why you did not help to defend the GPL in 2005.
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 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.
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.
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örg
On Thu, Aug 22, 2013 at 3:53 AM, Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de wrote:
Umm, have they dropped perl?
It seems that Larry was in a different position.
Same problem, just starting from the other side of the picture.
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.
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.
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 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.
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,
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, 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.
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.
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.
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.
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.
On Wed, 21 Aug 2013 18:09:10 +0200 Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de wrote:
Marko Vojinovic vvmarko@gmail.com wrote:
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.
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.
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.
software as you see fit, they equally have the right to not like your license and to boycott your software because of it.
Democracy is that the doers and this are software authors decide about the license.
Sure, no argument there. :-)
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.
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
Marko Vojinovic vvmarko@gmail.com wrote:
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.
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örg
-
Alexander Dalloz -
Joerg Schilling -
John R Pierce -
Les Mikesell -
Marko Vojinovic -
wwp