Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.misc > #3615 > unrolled thread

Why are mkisofs ISO's so large?

Started byTodd <Todd@invalid.invalid>
First post2012-01-07 20:15 -0800
Last post2013-03-21 14:06 +0000
Articles 20 on this page of 147 — 22 participants

Back to article view | Back to comp.os.linux.misc


Contents

  Why are mkisofs ISO's so large? Todd <Todd@invalid.invalid> - 2012-01-07 20:15 -0800
    Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-08 06:03 +0000
      Re: Why are mkisofs ISO's so large? Todd <Todd@invalid.invalid> - 2012-01-07 23:33 -0800
        Re: Why are mkisofs ISO's so large? Todd <Todd@invalid.invalid> - 2012-01-07 23:40 -0800
          Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-08 22:10 +0000
        Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-08 22:07 +0000
        Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-21 14:07 +0000
      Re: Why are mkisofs ISO's so large? Todd <Todd@invalid.invalid> - 2012-01-23 10:08 -0800
        Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-24 05:04 +0000
          Re: Why are mkisofs ISO's so large? Todd <Todd@invalid.invalid> - 2012-01-24 11:04 -0800
          Re: Why are mkisofs ISO's so large? Loki Harfagr <l0k1@thedarkdesign.free.fr.INVALID> - 2012-01-25 18:33 +0000
            Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-25 20:17 +0000
              Re: Why are mkisofs ISO's so large? Richard Kettlewell <rjk@greenend.org.uk> - 2012-01-25 21:37 +0000
                Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-25 22:32 +0000
                  Re: Why are mkisofs ISO's so large? Richard Kettlewell <rjk@greenend.org.uk> - 2012-01-26 01:33 +0000
                    Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-26 07:56 +0000
                      Re: Why are mkisofs ISO's so large? Baho Utot <baho-utot@invlaid.com> - 2012-01-26 09:26 -0500
                        Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-26 22:43 +0000
                          Re: Why are mkisofs ISO's so large? J G Miller <miller@yoyo.ORG> - 2012-01-27 00:43 +0000
                      Re: Why are mkisofs ISO's so large? Richard Kettlewell <rjk@greenend.org.uk> - 2012-01-26 20:08 +0000
                        Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-26 22:55 +0000
                          Re: Why are mkisofs ISO's so large? Baho Utot <baho-utot@invlaid.com> - 2012-01-26 18:15 -0500
                            Re: Why are mkisofs ISO's so large? The Natural Philosopher <tnp@invalid.invalid> - 2012-01-27 07:55 +0000
                              Re: Why are mkisofs ISO's so large? Baho Utot <baho-utot@invlaid.com> - 2012-01-27 07:51 -0500
                          Re: Why are mkisofs ISO's so large? Richard Kettlewell <rjk@greenend.org.uk> - 2012-01-27 09:29 +0000
                            Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-27 20:35 +0000
                              Re: Why are mkisofs ISO's so large? Peter Köhlmann <peter-koehlmann@t-online.de> - 2012-01-27 22:45 +0100
                        Re: Why are mkisofs ISO's so large? Baho Utot <baho-utot@invlaid.com> - 2012-01-26 18:58 -0500
                          Re: Why are mkisofs ISO's so large? John Hasler <jhasler@newsguy.com> - 2012-01-27 07:22 -0600
                            Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-21 14:47 +0000
                          Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-27 20:47 +0000
                            Re: Why are mkisofs ISO's so large? Peter Köhlmann <peter-koehlmann@t-online.de> - 2012-01-27 22:03 +0100
                              Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-27 21:38 +0000
                                Re: Why are mkisofs ISO's so large? The Natural Philosopher <tnp@invalid.invalid> - 2012-01-27 21:54 +0000
                                  Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-28 00:00 +0000
                                    Re: Why are mkisofs ISO's so large? The Natural Philosopher <tnp@invalid.invalid> - 2012-01-28 01:32 +0000
                                      Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-28 01:54 +0000
                                    Re: Why are mkisofs ISO's so large? Baho Utot <baho-utot@invlaid.com> - 2012-01-29 08:01 -0500
                                      Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-29 19:09 +0000
                                    Re: Why are mkisofs ISO's so large? Darren Salt <news@youmustbejoking.demon.cu.invalid> - 2012-01-31 17:57 +0000
                                      Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-31 21:12 +0000
                            Re: Why are mkisofs ISO's so large? Dan Espen <despen@verizon.net> - 2012-01-27 16:44 -0500
                            Re: Why are mkisofs ISO's so large? Baho Utot <baho-utot@invlaid.com> - 2012-01-27 16:39 -0500
                        Re: Why are mkisofs ISO's so large? lynxuser@mouse-potato.com - 2012-01-27 14:17 +0000
                          Re: Why are mkisofs ISO's so large? Baho Utot <baho-utot@invlaid.com> - 2012-01-27 09:44 -0500
                            Re: Why are mkisofs ISO's so large? Feranija <feranija@mouse-potato.com> - 2012-01-27 07:02 -0800
                              Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-27 20:53 +0000
                                Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-21 14:54 +0000
                        Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-21 14:43 +0000
                          Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2013-03-21 18:02 +0000
                            Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-21 17:30 -0400
                              Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2013-03-21 23:01 +0000
                                Re: Why are mkisofs ISO's so large? Robert Riches <spamtrap42@jacob21819.net> - 2013-03-22 04:10 +0000
                                  Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-22 07:19 -0400
                                    Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2013-03-22 17:48 +0000
                                      Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-22 17:51 -0400
                                  Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2013-03-22 17:46 +0000
                                    Re: Why are mkisofs ISO's so large? Robert Riches <spamtrap42@jacob21819.net> - 2013-03-23 04:45 +0000
                                      Re: Why are mkisofs ISO's so large? Robert Riches <spamtrap42@jacob21819.net> - 2013-03-23 04:47 +0000
                                      Re: Why are mkisofs ISO's so large? Balwinder S Dheeman <bsd.SANSPAM@anu.homelinux.net> - 2013-03-23 21:26 +0530
                                  Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-22 18:05 +0000
                                    Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-22 17:57 -0400
                                Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-22 07:17 -0400
                                  Re: Why are mkisofs ISO's so large? Roger Blake <rogblake@iname.invalid> - 2013-03-23 01:30 +0000
                                    Re: Why are mkisofs ISO's so large? Bit Twister <BitTwister@mouse-potato.com> - 2013-03-23 02:40 +0000
                                      Re: Why are mkisofs ISO's so large? Roger Blake <rogblake@iname.invalid> - 2013-03-23 13:33 +0000
                                        Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-23 10:41 -0400
                                          Re: Why are mkisofs ISO's so large? Roger Blake <rogblake@iname.invalid> - 2013-03-23 15:29 +0000
                                            Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-23 11:57 -0400
                                              Re: Why are mkisofs ISO's so large? J G Miller <miller@yoyo.ORG> - 2013-03-23 17:24 +0000
                                              Re: Why are mkisofs ISO's so large? Roger Blake <rogblake@iname.invalid> - 2013-03-23 19:02 +0000
                                                Re: Why are mkisofs ISO's so large? J G Miller <miller@yoyo.ORG> - 2013-03-23 20:00 +0000
                                                  Re: Why are mkisofs ISO's so large? Roger Blake <rogblake@iname.invalid> - 2013-03-23 23:22 +0000
                                                    Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-23 19:44 -0400
                                                      Re: Why are mkisofs ISO's so large? Roger Blake <rogblake@iname.invalid> - 2013-03-23 23:56 +0000
                                                        Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-23 20:36 -0400
                                                          Re: Why are mkisofs ISO's so large? Roger Blake <rogblake@iname.invalid> - 2013-03-24 00:54 +0000
                              Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-22 18:02 +0000
                                Re: Why are mkisofs ISO's so large? Dan Espen <despen@verizon.net> - 2013-03-22 14:34 -0400
                                  Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-23 11:48 +0000
                                    Re: Why are mkisofs ISO's so large? Roger Blake <rogblake@iname.invalid> - 2013-03-23 13:35 +0000
                                    Re: Why are mkisofs ISO's so large? Dan Espen <despen@verizon.net> - 2013-03-23 11:59 -0400
                                      Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-23 16:35 +0000
                                        Re: Why are mkisofs ISO's so large? Dan Espen <despen@verizon.net> - 2013-03-23 13:09 -0400
                                      Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2013-03-23 17:14 +0000
                                        Re: Why are mkisofs ISO's so large? Dan Espen <despen@verizon.net> - 2013-03-23 13:33 -0400
                                          Re: Why are mkisofs ISO's so large? Bit Twister <BitTwister@mouse-potato.com> - 2013-03-23 17:58 +0000
                                            Re: Why are mkisofs ISO's so large? Dan Espen <despen@verizon.net> - 2013-03-23 14:19 -0400
                                            Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-23 19:18 +0000
                                          Re: Why are mkisofs ISO's so large? Roger Blake <rogblake@iname.invalid> - 2013-03-23 19:18 +0000
                                            Re: Why are mkisofs ISO's so large? Dan Espen <despen@verizon.net> - 2013-03-23 17:25 -0400
                                            Re: Why are mkisofs ISO's so large? <nunojsilva@invalid.invalid> (Nuno Silva) - 2013-03-24 00:05 +0200
                                              Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2013-03-23 23:39 +0000
                                                Re: Why are mkisofs ISO's so large? <nunojsilva@invalid.invalid> (Nuno Silva) - 2013-03-24 09:00 +0200
                                                  Re: Why are mkisofs ISO's so large? J G Miller <miller@yoyo.ORG> - 2013-03-24 16:04 +0000
                                                    Re: Why are mkisofs ISO's so large? Dan Espen <despen@verizon.net> - 2013-03-24 13:46 -0400
                                                      Re: Why are mkisofs ISO's so large? J G Miller <miller@yoyo.ORG> - 2013-03-24 19:07 +0000
                                                        Re: Why are mkisofs ISO's so large? Dan Espen <despen@verizon.net> - 2013-03-24 17:06 -0400
                                                          Re: Why are mkisofs ISO's so large? "Nuno J. Silva (aka njsg)" <njsg@invalid.invalid> - 2013-03-24 21:20 +0000
                                                            Re: Why are mkisofs ISO's so large? Fedora bug tracking Dan Espen <despen@verizon.net> - 2013-03-24 20:08 -0400
                                                              Re: Why are mkisofs ISO's so large? Fedora bug tracking Joerg.Schilling@fokus.fraunhofer.de - 2013-03-25 09:59 +0000
                                                          Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-24 22:17 +0000
                                                            Re: Why are mkisofs ISO's so large? "Nuno J. Silva (aka njsg)" <njsg@invalid.invalid> - 2013-03-24 23:07 +0000
                                                              Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-25 09:57 +0000
                                                          Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-24 22:35 +0000
                                                            Re: Why are mkisofs ISO's so large? "Nuno J. Silva (aka njsg)" <njsg@invalid.invalid> - 2013-03-24 23:03 +0000
                                                        Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-24 21:42 +0000
                                                    Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-24 21:31 +0000
                                                Re: Why are mkisofs ISO's so large? <nunojsilva@invalid.invalid> (Nuno Silva) - 2013-03-24 09:00 +0200
                                                Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-24 11:29 +0000
                                          Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2013-03-23 23:34 +0000
                                            Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-23 19:58 -0400
                                              Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-24 11:31 +0000
                                                Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-24 08:56 -0400
                                                  Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-30 12:06 +0000
                                                    Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-30 13:24 -0400
                                              Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2013-03-24 17:46 +0000
                                                Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-24 15:53 -0400
                                                  Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-24 21:45 +0000
                                                    Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-24 21:51 -0400
                                                Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-24 20:53 +0000
                                                Re: Why are mkisofs ISO's so large? Richard Kettlewell <rjk@greenend.org.uk> - 2013-03-25 08:32 +0000
                                    Re: Why are mkisofs ISO's so large? Peter Köhlmann <peter-koehlmann@t-online.de> - 2013-03-23 17:22 +0100
                                    Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2013-03-23 17:13 +0000
                                      Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-23 18:44 +0000
                                    Re: Why are mkisofs ISO's so large? Robert Riches <spamtrap42@jacob21819.net> - 2013-03-24 04:15 +0000
                                      Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-24 11:34 +0000
                            Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-22 17:56 +0000
                              Re: Why are mkisofs ISO's so large? Richard Kettlewell <rjk@greenend.org.uk> - 2013-03-22 18:39 +0000
                              Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2013-03-22 22:14 +0000
                                Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-23 16:25 +0000
                                  Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-23 13:03 -0400
                                    Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-23 18:39 +0000
                                      Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-23 16:37 -0400
                          Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-21 17:23 -0400
                            Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-22 17:58 +0000
                              Re: Why are mkisofs ISO's so large? Octothorpe <Octothorpe@invalid.com> - 2013-03-22 17:53 -0400
                                Re: Why are mkisofs ISO's so large? The Natural Philosopher <tnp@invalid.invalid> - 2013-03-23 09:20 +0000
                      Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-21 14:35 +0000
              Re: Why are mkisofs ISO's so large? Peter Köhlmann <peter-koehlmann@t-online.de> - 2012-01-25 23:28 +0100
                Re: Why are mkisofs ISO's so large? unruh <unruh@invalid.ca> - 2012-01-26 07:41 +0000
              Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-21 14:31 +0000
            Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-21 14:23 +0000
          Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-21 14:21 +0000
        Re: Why are mkisofs ISO's so large? Todd <Todd@invalid.invalid> - 2012-01-26 10:38 -0800
    Re: Why are mkisofs ISO's so large? root <NoEMail@home.org> - 2012-01-08 15:50 +0000
    Re: Why are mkisofs ISO's so large? Joerg.Schilling@fokus.fraunhofer.de - 2013-03-21 14:06 +0000

Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8  Next page →


#3907

Fromunruh <unruh@invalid.ca>
Date2012-01-26 22:55 +0000
Message-ID<XRkUq.741$Ep3.371@newsfe08.iad>
In reply to#3905
On 2012-01-26, Richard Kettlewell <rjk@greenend.org.uk> wrote:
> unruh <unruh@invalid.ca> writes:
>> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>
>>> The idea that the kernel's licence *would* cover user programs is
>>> bizarre, but in this case, there's no need to entertain that idea,
>>> since the owners have explicitly ruled it out.  End of.
>>
>> How is it bizarre?
>
> For instance: if running a program under Linux makes it a derivative
> work of the Linux kernel, then a Windows program run for the first time
> using WINE, or a CIL program run using Mono, or a shell script written
> in 1885 and run today under Bash, would suddenly become a derivative
> work of Linux.

That may be something you do not want, but it is hardly bizarre. 
In your case, the derivative program would be the program which was
linked with Linux kernel-- it is the whole thing which would then be
derivative, not the original program itself. "derivative work" is a
statement about the work, not about anything the work depends on. 

>
>> Derivative works are precisely that, works which rely in some ill
>> defined way on other works. Would a court regard a user program which
>> uses kernel calls as derivative works?
>
> The usual interpretation (for instance, the one adopted in US law) is
> that a derivative work is one based on another.  User programs are not
> (in general) based on the kernel.

Well, that is the question. Is the work reliant on the other work? For
example it is almost certainly the case that a linux distribution is a
derivative work of the kernel, since clearly the distribution would not
work at all without the kernel. 
"Based on" can be incredibly vague. Thus  a movie "based on" a book, but
totally different from the book can still be a derivative work with
respect to the book. Totally different medium, different story...

Remember that the "work" in this case is the whole thing, the program as
linked with the kernel routines. The program itself may not be
derivative, but the thing actually run, the program linked with the
kernel, could be. (Part of the problem is exactly that "derivative work"
is so badly defined by the act that what is and is not a derivative work
is extremely unclear. This means that the courts would have to decide
it. And because it is so unclear the precidents are all over the
place,and may well contridict each other. 


>
>> I hope not, but it could well do so. At the same time the Debian
>> people claim that cdrtools is incompatible with the GPL and thus
>> cannot be included in the distribution? Under what legal theory? The
>> only one is that of "derivtive work". Ie, it is Debian which it seems
>> to me is expanding the definition of derivative work way beyond where
>> I would want it to apply ( and where Jorg thinks it applies).
>
> I don't in any way speak for Debian but their position as I understand
> it is that distributing the executable would require complying with both
> the GPL and CDDL simultaneously.  That's not possible.
>

The same is true of GPL3 and GPL2, and most other licenses with respect
to each other, if the licenses are read strictly enough. Schilling would
claim that one can in fact comply with both because those features of
the GPL which would be problematic are in fact beyond the right of the
license to control. For example, if a software license said that the
licensee had to sacrifice his firstborn to use the program, and the CDDL
said that the firstborn had to be the one to run the program, this might
seem in conflict, but would not be, because those terms in the licenses
were illegal and thus of no force. The licenses would not in legal fact
be in conflict as licenses. 

[toc] | [prev] | [next] | [standalone]


#3908

FromBaho Utot <baho-utot@invlaid.com>
Date2012-01-26 18:15 -0500
Message-ID<5e39v8-n7f.ln1@crazy-horse.bildanet.com>
In reply to#3907
unruh wrote:

> On 2012-01-26, Richard Kettlewell <rjk@greenend.org.uk> wrote:
>> unruh <unruh@invalid.ca> writes:
>>> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>>
>>>> The idea that the kernel's licence *would* cover user programs is
>>>> bizarre, but in this case, there's no need to entertain that idea,
>>>> since the owners have explicitly ruled it out.  End of.
>>>
>>> How is it bizarre?
>>
>> For instance: if running a program under Linux makes it a derivative
>> work of the Linux kernel, then a Windows program run for the first time
>> using WINE, or a CIL program run using Mono, or a shell script written
>> in 1885 and run today under Bash, would suddenly become a derivative
>> work of Linux.
> 
> That may be something you do not want, but it is hardly bizarre.
> In your case, the derivative program would be the program which was
> linked with Linux kernel-- it is the whole thing which would then be
> derivative, not the original program itself. "derivative work" is a
> statement about the work, not about anything the work depends on.
> 

I don't know of too many apps that link with the kernel except glibc.
What apps are you talking about?


>>
>>> Derivative works are precisely that, works which rely in some ill
>>> defined way on other works. Would a court regard a user program which
>>> uses kernel calls as derivative works?
>>
>> The usual interpretation (for instance, the one adopted in US law) is
>> that a derivative work is one based on another.  User programs are not
>> (in general) based on the kernel.
> 
> Well, that is the question. Is the work reliant on the other work? For
> example it is almost certainly the case that a linux distribution is a
> derivative work of the kernel, since clearly the distribution would not
> work at all without the kernel.
> "Based on" can be incredibly vague. Thus  a movie "based on" a book, but
> totally different from the book can still be a derivative work with
> respect to the book. Totally different medium, different story...
> 
> Remember that the "work" in this case is the whole thing, the program as
> linked with the kernel routines. The program itself may not be
> derivative, but the thing actually run, the program linked with the
> kernel, could be. (Part of the problem is exactly that "derivative work"
> is so badly defined by the act that what is and is not a derivative work
> is extremely unclear. This means that the courts would have to decide
> it. And because it is so unclear the precidents are all over the
> place,and may well contridict each other.
> 
> 

Isn't most libraries under LGPL?


>>
>>> I hope not, but it could well do so. At the same time the Debian
>>> people claim that cdrtools is incompatible with the GPL and thus
>>> cannot be included in the distribution? Under what legal theory? The
>>> only one is that of "derivtive work". Ie, it is Debian which it seems
>>> to me is expanding the definition of derivative work way beyond where
>>> I would want it to apply ( and where Jorg thinks it applies).
>>
>> I don't in any way speak for Debian but their position as I understand
>> it is that distributing the executable would require complying with both
>> the GPL and CDDL simultaneously.  That's not possible.
>>
> 
> The same is true of GPL3 and GPL2, and most other licenses with respect
> to each other, if the licenses are read strictly enough. Schilling would
> claim that one can in fact comply with both because those features of
> the GPL which would be problematic are in fact beyond the right of the
> license to control. For example, if a software license said that the
> licensee had to sacrifice his firstborn to use the program, and the CDDL
> said that the firstborn had to be the one to run the program, this might
> seem in conflict, but would not be, because those terms in the licenses
> were illegal and thus of no force. The licenses would not in legal fact
> be in conflict as licenses.

I simply don't see the problem.

[toc] | [prev] | [next] | [standalone]


#3911

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2012-01-27 07:55 +0000
Message-ID<jftl9s$a0j$3@news.albasani.net>
In reply to#3908
Baho Utot wrote:
> unruh wrote:
> 
>> On 2012-01-26, Richard Kettlewell <rjk@greenend.org.uk> wrote:
>>> unruh <unruh@invalid.ca> writes:
>>>> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>>>>> The idea that the kernel's licence *would* cover user programs is
>>>>> bizarre, but in this case, there's no need to entertain that idea,
>>>>> since the owners have explicitly ruled it out.  End of.
>>>> How is it bizarre?
>>> For instance: if running a program under Linux makes it a derivative
>>> work of the Linux kernel, then a Windows program run for the first time
>>> using WINE, or a CIL program run using Mono, or a shell script written
>>> in 1885 and run today under Bash, would suddenly become a derivative
>>> work of Linux.
>> That may be something you do not want, but it is hardly bizarre.
>> In your case, the derivative program would be the program which was
>> linked with Linux kernel-- it is the whole thing which would then be
>> derivative, not the original program itself. "derivative work" is a
>> statement about the work, not about anything the work depends on.
>>
> 
> I don't know of too many apps that link with the kernel except glibc.
> What apps are you talking about?

I have never heard glibc called an app.

I think at this point I will discontinue reading this post.

[toc] | [prev] | [next] | [standalone]


#3914

FromBaho Utot <baho-utot@invlaid.com>
Date2012-01-27 07:51 -0500
Message-ID<a7jav8-l6g.ln1@crazy-horse.bildanet.com>
In reply to#3911
The Natural Philosopher wrote:

> Baho Utot wrote:
>> unruh wrote:
>> 
>>> On 2012-01-26, Richard Kettlewell <rjk@greenend.org.uk> wrote:
>>>> unruh <unruh@invalid.ca> writes:
>>>>> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>>>>>> The idea that the kernel's licence *would* cover user programs is
>>>>>> bizarre, but in this case, there's no need to entertain that idea,
>>>>>> since the owners have explicitly ruled it out.  End of.
>>>>> How is it bizarre?
>>>> For instance: if running a program under Linux makes it a derivative
>>>> work of the Linux kernel, then a Windows program run for the first time
>>>> using WINE, or a CIL program run using Mono, or a shell script written
>>>> in 1885 and run today under Bash, would suddenly become a derivative
>>>> work of Linux.
>>> That may be something you do not want, but it is hardly bizarre.
>>> In your case, the derivative program would be the program which was
>>> linked with Linux kernel-- it is the whole thing which would then be
>>> derivative, not the original program itself. "derivative work" is a
>>> statement about the work, not about anything the work depends on.
>>>
>> 
>> I don't know of too many apps that link with the kernel except glibc.
>> What apps are you talking about?
> 
> I have never heard glibc called an app.
> 
> I think at this point I will discontinue reading this post.

Well maybe an app plus libraries is more correct, but that is not what I
meant.

usr/bin/getent
usr/bin/rpcgen
usr/bin/localedef
usr/bin/sprof
usr/bin/mtrace
usr/bin/catchsegv
usr/bin/pcprofiledump
usr/bin/getconf
usr/bin/xtrace
usr/bin/sotruss
usr/bin/tzselect
usr/bin/ldd
usr/bin/gencat
usr/bin/locale
usr/bin/lddlibc4
usr/bin/iconv

sbin/sln
sbin/ldconfig
usr/
usr/sbin/
usr/sbin/zic
usr/sbin/iconvconfig
usr/sbin/nscd
usr/sbin/zdump

[toc] | [prev] | [next] | [standalone]


#3912

FromRichard Kettlewell <rjk@greenend.org.uk>
Date2012-01-27 09:29 +0000
Message-ID<87fwf1o5n2.fsf@araminta.anjou.terraraq.org.uk>
In reply to#3907
unruh <unruh@invalid.ca> writes:
> Richard Kettlewell <rjk@greenend.org.uk> wrote:

>> I don't in any way speak for Debian but their position as I understand
>> it is that distributing the executable would require complying with both
>> the GPL and CDDL simultaneously.  That's not possible.
>
> The same is true of GPL3 and GPL2, and most other licenses with respect
> to each other, if the licenses are read strictly enough.

Indeed, you may not combine GPL-2-only and GPL-3-only code.

> Schilling would claim that one can in fact comply with both because
> those features of the GPL which would be problematic are in fact
> beyond the right of the license to control.

He can claim anything he likes, but he and his sycophants are doing a
terrible job of convincing distributors (case in point: bizarre claims
about kernel copyright extending to user programs).  In the end that's
all that matters.

> For example, if a software license said that the licensee had to
> sacrifice his firstborn to use the program, and the CDDL said that the
> firstborn had to be the one to run the program, this might seem in
> conflict, but would not be, because those terms in the licenses were
> illegal and thus of no force. The licenses would not in legal fact be
> in conflict as licenses.

I'd regard software covered by a hypothetical sacrifice-firstborn
licence as impossible to copy (etc) at all.  The copyright holder has
the exclusive right to control copying, the terms they state are
impossible for me to meet, ergo it may not be copied.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]


#3930

Fromunruh <unruh@invalid.ca>
Date2012-01-27 20:35 +0000
Message-ID<IUDUq.92$Cs3.38@newsfe22.iad>
In reply to#3912
On 2012-01-27, Richard Kettlewell <rjk@greenend.org.uk> wrote:
> unruh <unruh@invalid.ca> writes:
>> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>
>>> I don't in any way speak for Debian but their position as I understand
>>> it is that distributing the executable would require complying with both
>>> the GPL and CDDL simultaneously.  That's not possible.
>>
>> The same is true of GPL3 and GPL2, and most other licenses with respect
>> to each other, if the licenses are read strictly enough.
>
> Indeed, you may not combine GPL-2-only and GPL-3-only code.
>
>> Schilling would claim that one can in fact comply with both because
>> those features of the GPL which would be problematic are in fact
>> beyond the right of the license to control.
>
> He can claim anything he likes, but he and his sycophants are doing a
> terrible job of convincing distributors (case in point: bizarre claims
> about kernel copyright extending to user programs).  In the end that's
> all that matters.

Sorry, it is Debian that makes such claims. Schilling claims that there
is no problem with his licensing parts of cdrtools as CDDL. There is no
incompatibility in distributing CDDL.

You mean just like it is hard for the US to convince Iran to stop its
nuclear program. Ie, the reason for one person having difficulty
convincing someone else can be many and manifold, and need have nothing
to do with the logic of the arguments. 


>
>> For example, if a software license said that the licensee had to
>> sacrifice his firstborn to use the program, and the CDDL said that the
>> firstborn had to be the one to run the program, this might seem in
>> conflict, but would not be, because those terms in the licenses were
>> illegal and thus of no force. The licenses would not in legal fact be
>> in conflict as licenses.
>
> I'd regard software covered by a hypothetical sacrifice-firstborn
> licence as impossible to copy (etc) at all.  The copyright holder has
> the exclusive right to control copying, the terms they state are
> impossible for me to meet, ergo it may not be copied.

But the law would simply regard the license as it exists with that
clause removed, since that clause is illegal. Now you might decide not
to copy it anyway, since that would be your right, but if you met the
other conditions of the license ( assuming they were legally fine) the
writer would not be able to enforce this section of the copyright on you.

As I understand it, that is Schilling's attitude towards the parts of the GPL that are
claimed to be in conflict with the CDDA. And he has at least some legal
opinion on his side. 
This does not mean that GPL is invalid in its entirety. Just that some
of its claims are invalid. 

[toc] | [prev] | [next] | [standalone]


#3941

FromPeter Köhlmann <peter-koehlmann@t-online.de>
Date2012-01-27 22:45 +0100
Message-ID<jfv5td$1ql$1@dont-email.me>
In reply to#3930
unruh wrote:

> On 2012-01-27, Richard Kettlewell <rjk@greenend.org.uk> wrote:
>> unruh <unruh@invalid.ca> writes:
>>> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>>
>>>> I don't in any way speak for Debian but their position as I understand
>>>> it is that distributing the executable would require complying with
>>>> both
>>>> the GPL and CDDL simultaneously.  That's not possible.
>>>
>>> The same is true of GPL3 and GPL2, and most other licenses with respect
>>> to each other, if the licenses are read strictly enough.
>>
>> Indeed, you may not combine GPL-2-only and GPL-3-only code.
>>
>>> Schilling would claim that one can in fact comply with both because
>>> those features of the GPL which would be problematic are in fact
>>> beyond the right of the license to control.
>>
>> He can claim anything he likes, but he and his sycophants are doing a
>> terrible job of convincing distributors (case in point: bizarre claims
>> about kernel copyright extending to user programs).  In the end that's
>> all that matters.
> 
> Sorry, it is Debian that makes such claims. Schilling claims that there
> is no problem with his licensing parts of cdrtools as CDDL. There is no
> incompatibility in distributing CDDL.

That is Jörgs claim.
He could just as well claim that the sun is made from swiss cheese.

Why should anyone with half a brain believe the claims of a whacko?

[toc] | [prev] | [next] | [standalone]


#3909

FromBaho Utot <baho-utot@invlaid.com>
Date2012-01-26 18:58 -0500
Message-ID<2u59v8-l9f.ln1@crazy-horse.bildanet.com>
In reply to#3905
unruh wrote:

> On 2012-01-26, Baho Utot <baho-utot@invlaid.com> wrote:
>> unruh wrote:
>>
>> [putolin]
>>
>>> 
>>> How is it bizarre? Derivative works are precisely that, works which
>>> rely  in some ill defined way on other works. Would a court regard a
>>> user program which uses kernel calls as derivative works? I hope not,
>>> but it could well do so. At the same time the Debian people claim that
>>> cdrtools is incompatible with the GPL and thus cannot be included in the
>>> distribution? Under what legal theory? The only one is that of
>>> "derivtive work". Ie, it is Debian which it seems to me is expanding the
>>> definition of derivative work way beyond where I would want it to apply
>>> ( and where Jorg thinks it applies).
>>> Note that Jorg has explicitly ruled out any conflict between cdrtools
>>> and the GPL. End of? Why for the kernel but not for Jorg?
>>
>> His opinion.  There may be and most likely other issues as well.  His
>> point is from a single software package, debian must consider all
>> packages not just his.
> 
> Yes, it is his opinion. And his statement about what he will do. That
> statement would make it extremely difficult for him to sue.
>>
>> Any way why does'nt he license with GPL as well as CDDL?
> 
> He feels that the GPL is too weak and cannot protect his software from
> being used in someone else's proprietary software without his
> permission. Ie, although the GPL claims to disallow it, he feels that it
> is on too shakey a stance to be enforcable in court. He claims that this
> has been backed up by someone who tried to enforce the GPL in German
> courts and could not do so. The courts found that the language of the
> GPL overstepped what it was legally allowed to restrict.

Yes this was one of his claims but he did not provide any evidence to Arch
linux developers for his claims.  Lip service was all he provided and that
is why his proposal to switch from cdrkit to cdrtools was rejected.

I was also hassled by him as well when I posted that I have not had any
issues using cdrkit.  He claimed that I really didn't burn the dvds that I
did. He claimed it did not work when in fact it did.  I have them in hand.

Any way cdrkit and cdrtools is not the only game in town

http://www.linuxfromscratch.org/blfs/view/svn/multimedia/xorriso.html

> 
>> Dual license is permissable.  He could do so and solve all this problems
>> just by doing that, but he won't.
> 
> It is. It means that the weakest featues of each licence applies. Ie,
> he would not be able to prevent the use of the software in closed source
> commercial ventures. Ie, the solution would come with unacceptable side
> effects.
> 
>>
>> I still don't know why he had to pick an ugly fight with arch linux last
>> year.
> 
> I have no idea what the fight was. Can you point me to references?

He showed up on the arch mail lists and somewhat demanded that they use
cdrtools insteed of cdrkit. An ensuing cat fight then commenced.

Google.com is your friend

This is from the thread you can get the whole thread from there if you like.

http://mailman.archlinux.org/pipermail/arch-general/2010-January/010466.html

From the thread...
Qoute
"However, I am still with Allan here. All this situation was initially
caused by Jörg himself and talking about a proof but not actually providing
it does not help.

PS: I wonder if this discussion will come to a conclusion before optical
discs are obsolete."

[toc] | [prev] | [next] | [standalone]


#3915

FromJohn Hasler <jhasler@newsguy.com>
Date2012-01-27 07:22 -0600
Message-ID<871uqlnuuo.fsf@thumper.dhh.gt.org>
In reply to#3909
Baho Utot writes:
> He showed up on the arch mail lists and somewhat demanded that they
> use cdrtools insteed of cdrkit. An ensuing cat fight then commenced.

Sounds similar to what happened with Debian.  He also has threatened to
sue Debian developers.  Why would anyone want to get involved with
software the author of which has threatened to sue them over it?

> Any way cdrkit and cdrtools is not the only game in town

> http://www.linuxfromscratch.org/blfs/view/svn/multimedia/xorriso.html

And it is included in Debian, as is cdrskin.  See
<http://libburnia-project.org> .  Cdrkit might not be in the next Debian
release.
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]


#7520

FromJoerg.Schilling@fokus.fraunhofer.de
Date2013-03-21 14:47 +0000
Message-ID<kif6hb$bn3$9@news.albasani.net>
In reply to#3915
In article <871uqlnuuo.fsf@thumper.dhh.gt.org>,
John Hasler  <jhasler@newsguy.com> wrote:
>Baho Utot writes:
>> He showed up on the arch mail lists and somewhat demanded that they
>> use cdrtools insteed of cdrkit. An ensuing cat fight then commenced.
>
>Sounds similar to what happened with Debian.  He also has threatened to
>sue Debian developers.  Why would anyone want to get involved with
>software the author of which has threatened to sue them over it?
>
>> Any way cdrkit and cdrtools is not the only game in town
>
>> http://www.linuxfromscratch.org/blfs/view/svn/multimedia/xorriso.html
>
>And it is included in Debian, as is cdrskin.  See
><http://libburnia-project.org> .  Cdrkit might not be in the next Debian
>release.

This software is not able to replace mkisofs at all.

There are too many missing features.

-- 
EMail:joerg@schily.net			(home) Jörg Schilling D-13353 Berlin
      js@cs.tu-berlin.de		(uni)  
      joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

[toc] | [prev] | [next] | [standalone]


#3931

Fromunruh <unruh@invalid.ca>
Date2012-01-27 20:47 +0000
Message-ID<y3EUq.170$9e4.146@newsfe21.iad>
In reply to#3909
On 2012-01-26, Baho Utot <baho-utot@invlaid.com> wrote:
> unruh wrote:
>
>> On 2012-01-26, Baho Utot <baho-utot@invlaid.com> wrote:
>>> unruh wrote:
>>>
>>> [putolin]
>>>
>>>> 
>>>> How is it bizarre? Derivative works are precisely that, works which
>>>> rely  in some ill defined way on other works. Would a court regard a
>>>> user program which uses kernel calls as derivative works? I hope not,
>>>> but it could well do so. At the same time the Debian people claim that
>>>> cdrtools is incompatible with the GPL and thus cannot be included in the
>>>> distribution? Under what legal theory? The only one is that of
>>>> "derivtive work". Ie, it is Debian which it seems to me is expanding the
>>>> definition of derivative work way beyond where I would want it to apply
>>>> ( and where Jorg thinks it applies).
>>>> Note that Jorg has explicitly ruled out any conflict between cdrtools
>>>> and the GPL. End of? Why for the kernel but not for Jorg?
>>>
>>> His opinion.  There may be and most likely other issues as well.  His
>>> point is from a single software package, debian must consider all
>>> packages not just his.
>> 
>> Yes, it is his opinion. And his statement about what he will do. That
>> statement would make it extremely difficult for him to sue.
>>>
>>> Any way why does'nt he license with GPL as well as CDDL?
>> 
>> He feels that the GPL is too weak and cannot protect his software from
>> being used in someone else's proprietary software without his
>> permission. Ie, although the GPL claims to disallow it, he feels that it
>> is on too shakey a stance to be enforcable in court. He claims that this
>> has been backed up by someone who tried to enforce the GPL in German
>> courts and could not do so. The courts found that the language of the
>> GPL overstepped what it was legally allowed to restrict.
>
> Yes this was one of his claims but he did not provide any evidence to Arch
> linux developers for his claims.  Lip service was all he provided and that
> is why his proposal to switch from cdrkit to cdrtools was rejected.

He has provided evidence in the past-- in the form of legal opinions on
the validity of some of the GPL claims. 

>
> I was also hassled by him as well when I posted that I have not had any
> issues using cdrkit.  He claimed that I really didn't burn the dvds that I
> did. He claimed it did not work when in fact it did.  I have them in hand.

This whole discussion was started by someone who DID have trouble with
cdrkit, which was solved by going to cdrtools. I can well believe that
you had no  trouble. Some (man?) people find cdrkit fine. It is afterall
cdrtools of 7 years ago, and Schilling writes good software. It just has
not kept up with changes in writing since then-- whether
hardware/software/bug fixes. 

>
> Any way cdrkit and cdrtools is not the only game in town
>
> http://www.linuxfromscratch.org/blfs/view/svn/multimedia/xorriso.html

Good. Competition is always good. Mind you, competition to cdrtools have
come up in the past, and the developers have lost interest and the
software has died. Schilling has been producing his software for about
20 years and has demonstrated that he is in it for the long run. That is
worth something. Maybe xorriso will be the same, and the developers will
have the same dedication without the aggrevation.


>
>> 
>>> Dual license is permissable.  He could do so and solve all this problems
>>> just by doing that, but he won't.
>> 
>> It is. It means that the weakest featues of each licence applies. Ie,
>> he would not be able to prevent the use of the software in closed source
>> commercial ventures. Ie, the solution would come with unacceptable side
>> effects.
>> 
>>>
>>> I still don't know why he had to pick an ugly fight with arch linux last
>>> year.
>> 
>> I have no idea what the fight was. Can you point me to references?
>
> He showed up on the arch mail lists and somewhat demanded that they use
> cdrtools insteed of cdrkit. An ensuing cat fight then commenced.
>
> Google.com is your friend
>
> This is from the thread you can get the whole thread from there if you like.
>
> http://mailman.archlinux.org/pipermail/arch-general/2010-January/010466.html

Thanks. As I have said often, Schilling can be hard to get along with.
He is stubborn and  he is opinionated. He also writes really good
software. cdrkit is HIS software. It is not someone elses. He is annoyed
that he has spent the last 6 years improving it and other then keep
using his ancient version, which is not surprizing. 

>
> From the thread...
> Qoute
> "However, I am still with Allan here. All this situation was initially
> caused by J??rg himself and talking about a proof but not actually providing
> it does not help.

But from what I have seen, the situation was NOT caused by Jorg himself.
It was an unfortunate collision between him and others, in which all of
them acted very much like little children fighting in a sandbox-- yes,
including Jorg. 


>
> PS: I wonder if this discussion will come to a conclusion before optical
> discs are obsolete."
>

[toc] | [prev] | [next] | [standalone]


#3933

FromPeter Köhlmann <peter-koehlmann@t-online.de>
Date2012-01-27 22:03 +0100
Message-ID<jfv3ec$gd1$1@dont-email.me>
In reply to#3931
unruh wrote:

> On 2012-01-26, Baho Utot <baho-utot@invlaid.com> wrote:
>> unruh wrote:
>>
>>
>> Yes this was one of his claims but he did not provide any evidence to
>> Arch
>> linux developers for his claims.  Lip service was all he provided and
>> that is why his proposal to switch from cdrkit to cdrtools was rejected.
> 
> He has provided evidence in the past-- in the form of legal opinions on
> the validity of some of the GPL claims.

Which was simply a bullshit opinion.
And then his "lawyers", who he claimed to have asked.
They exist every bit as miuch as that infamous SCO koffer

I have never seen someone making as ass out of himself and lying constantly 
like Jörg

If I would maintain a distro, I would steadfastly refuse to even talk to 
someone like him, let alone use his version of the software

[toc] | [prev] | [next] | [standalone]


#3937

Fromunruh <unruh@invalid.ca>
Date2012-01-27 21:38 +0000
Message-ID<lPEUq.1016$%17.461@newsfe06.iad>
In reply to#3933
On 2012-01-27, Peter K??hlmann <peter-koehlmann@t-online.de> wrote:
> unruh wrote:
>
>> On 2012-01-26, Baho Utot <baho-utot@invlaid.com> wrote:
>>> unruh wrote:
>>>
>>>
>>> Yes this was one of his claims but he did not provide any evidence to
>>> Arch
>>> linux developers for his claims.  Lip service was all he provided and
>>> that is why his proposal to switch from cdrkit to cdrtools was rejected.
>> 
>> He has provided evidence in the past-- in the form of legal opinions on
>> the validity of some of the GPL claims.
>
> Which was simply a bullshit opinion.
> And then his "lawyers", who he claimed to have asked.
> They exist every bit as miuch as that infamous SCO koffer

It is clear that you have no interest in the issues, just in your
position. I have read some of the opinions he has referenced and they
make sense to me, as someone who is not a lawyer, but had spent some
time trying to understand how lawyers think. 

>
> I have never seen someone making as ass out of himself and lying constantly 
> like J??rg

Again an opinion with zero backing. 

>
> If I would maintain a distro, I would steadfastly refuse to even talk to 
> someone like him, let alone use his version of the software

Yes, and you would deprive your users. It is precisely this kind of mind
game where the feelings of the distributors take precidence over the users
that I object to. My attitude would be that if there is really good
piece of software which my users would find useful ( and for most of the
past 15 years, cdrecord was the only game in town for doing something
that users find EXTREMELY useful) I would bend over backwards to provide
it to them, and damn my own hurt feelings. But that is clearly not the
attitude of many of the distributions. They are as obnoxious and
stubborn as Jorg can be. 

>

[toc] | [prev] | [next] | [standalone]


#3943

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2012-01-27 21:54 +0000
Message-ID<jfv6fe$kag$1@news.albasani.net>
In reply to#3937
unruh wrote:
> On 2012-01-27, Peter K??hlmann <peter-koehlmann@t-online.de> wrote:
>> unruh wrote:
>>
>>> On 2012-01-26, Baho Utot <baho-utot@invlaid.com> wrote:
>>>> unruh wrote:
>>>>
>>>>
>>>> Yes this was one of his claims but he did not provide any evidence to
>>>> Arch
>>>> linux developers for his claims.  Lip service was all he provided and
>>>> that is why his proposal to switch from cdrkit to cdrtools was rejected.
>>> He has provided evidence in the past-- in the form of legal opinions on
>>> the validity of some of the GPL claims.
>> Which was simply a bullshit opinion.
>> And then his "lawyers", who he claimed to have asked.
>> They exist every bit as miuch as that infamous SCO koffer
> 
> It is clear that you have no interest in the issues, just in your
> position. I have read some of the opinions he has referenced and they
> make sense to me, as someone who is not a lawyer, but had spent some
> time trying to understand how lawyers think. 
> 
>> I have never seen someone making as ass out of himself and lying constantly 
>> like J??rg
> 
> Again an opinion with zero backing. 
> 
>> If I would maintain a distro, I would steadfastly refuse to even talk to 
>> someone like him, let alone use his version of the software
> 
> Yes, and you would deprive your users. It is precisely this kind of mind
> game where the feelings of the distributors take precidence over the users
> that I object to. My attitude would be that if there is really good
> piece of software which my users would find useful ( and for most of the
> past 15 years, cdrecord was the only game in town for doing something
> that users find EXTREMELY useful) I would bend over backwards to provide
> it to them, and damn my own hurt feelings. But that is clearly not the
> attitude of many of the distributions. They are as obnoxious and
> stubborn as Jorg can be. 
> 
I thionk you will find that its a bit more complex than that..Debian 
IIRC at least has a statement of its own about what it is and how it 
operates: That  was and possibly still is in conflict with Jorg.. now 
under those circumstances each side has a good point.



But in the end downloading and compiling is just the linux alternative 
to going shopping and buying and then trying to make XYZ app work.

at LEAST with linux, if it all just 'doesn't work' you haven't wasted 
any money.

[toc] | [prev] | [next] | [standalone]


#3947

Fromunruh <unruh@invalid.ca>
Date2012-01-28 00:00 +0000
Message-ID<LUGUq.2646$JN6.587@newsfe13.iad>
In reply to#3943
On 2012-01-27, The Natural Philosopher <tnp@invalid.invalid> wrote:
> unruh wrote:
>> On 2012-01-27, Peter K??hlmann <peter-koehlmann@t-online.de> wrote:
>>> unruh wrote:
>>>
>>>> On 2012-01-26, Baho Utot <baho-utot@invlaid.com> wrote:
>>>>> unruh wrote:
>>>>>
>>>>>
>>>>> Yes this was one of his claims but he did not provide any evidence to
>>>>> Arch
>>>>> linux developers for his claims.  Lip service was all he provided and
>>>>> that is why his proposal to switch from cdrkit to cdrtools was rejected.
>>>> He has provided evidence in the past-- in the form of legal opinions on
>>>> the validity of some of the GPL claims.
>>> Which was simply a bullshit opinion.
>>> And then his "lawyers", who he claimed to have asked.
>>> They exist every bit as miuch as that infamous SCO koffer
>> 
>> It is clear that you have no interest in the issues, just in your
>> position. I have read some of the opinions he has referenced and they
>> make sense to me, as someone who is not a lawyer, but had spent some
>> time trying to understand how lawyers think. 
>> 
>>> I have never seen someone making as ass out of himself and lying constantly 
>>> like J??rg
>> 
>> Again an opinion with zero backing. 
>> 
>>> If I would maintain a distro, I would steadfastly refuse to even talk to 
>>> someone like him, let alone use his version of the software
>> 
>> Yes, and you would deprive your users. It is precisely this kind of mind
>> game where the feelings of the distributors take precidence over the users
>> that I object to. My attitude would be that if there is really good
>> piece of software which my users would find useful ( and for most of the
>> past 15 years, cdrecord was the only game in town for doing something
>> that users find EXTREMELY useful) I would bend over backwards to provide
>> it to them, and damn my own hurt feelings. But that is clearly not the
>> attitude of many of the distributions. They are as obnoxious and
>> stubborn as Jorg can be. 
>> 
> I thionk you will find that its a bit more complex than that..Debian 
> IIRC at least has a statement of its own about what it is and how it 
> operates: That  was and possibly still is in conflict with Jorg.. now 
> under those circumstances each side has a good point.

I am not saying that the two sides do not have points. I am saying that
the pig headedness on both sides (sticking to a point way beyond what is
reasonable) is what I see here. 
I am not sure what the phrase "about what it is" refers to. 

Debian has made statements about the licensing. If one takes it
literally it would outlaw a huge number of programs which are not
outlawed from the distro. (I would point to for example any GPL3
program. Since the kenrel is GPL2 and GPL2 ONLY, the distro must be
released as GPL2, since GPL3 is incompatible. Since the distro is
clearly a derived work of the kernel, it must comply with the kernel
license (it is not a "mere aggregation" since the distro without the
kernel would be useless, and the provision of the kernel is one of the
key purposes of the distro), and that requires that it be released under
GPL2. Thus, any GPL3 only program is in conflict and cannot be
distributed. 
Now, this may or may not be a legally valid argument, but it is at least
as cogent as Debian's argument re cdrtools. But they refuse to accept
this, but they push the cdrtools one. Why? Because of animosity and pig
headedness as far as I can see. 


>
>
>
> But in the end downloading and compiling is just the linux alternative 
> to going shopping and buying and then trying to make XYZ app work.

AGreed. People can just download cdrecord and compile it. On some
distros people have even generated scripts to do that for the user. 
It would sure be nicer if the distro did it. 

>
> at LEAST with linux, if it all just 'doesn't work' you haven't wasted 
> any money.

Well, if time is money, then yes, you have probably wasted a huge amount
of money. (trying to figure out why something does not work can take
hours and days).

[toc] | [prev] | [next] | [standalone]


#3951

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2012-01-28 01:32 +0000
Message-ID<jfvj7u$4c5$1@news.albasani.net>
In reply to#3947
unruh wrote:
> On 2012-01-27, The Natural Philosopher <tnp@invalid.invalid> wrote:
>> unruh wrote:
>>> On 2012-01-27, Peter K??hlmann <peter-koehlmann@t-online.de> wrote:
>>>> unruh wrote:
>>>>
>>>>> On 2012-01-26, Baho Utot <baho-utot@invlaid.com> wrote:
>>>>>> unruh wrote:
>>>>>>
>>>>>>
>>>>>> Yes this was one of his claims but he did not provide any evidence to
>>>>>> Arch
>>>>>> linux developers for his claims.  Lip service was all he provided and
>>>>>> that is why his proposal to switch from cdrkit to cdrtools was rejected.
>>>>> He has provided evidence in the past-- in the form of legal opinions on
>>>>> the validity of some of the GPL claims.
>>>> Which was simply a bullshit opinion.
>>>> And then his "lawyers", who he claimed to have asked.
>>>> They exist every bit as miuch as that infamous SCO koffer
>>> It is clear that you have no interest in the issues, just in your
>>> position. I have read some of the opinions he has referenced and they
>>> make sense to me, as someone who is not a lawyer, but had spent some
>>> time trying to understand how lawyers think. 
>>>
>>>> I have never seen someone making as ass out of himself and lying constantly 
>>>> like J??rg
>>> Again an opinion with zero backing. 
>>>
>>>> If I would maintain a distro, I would steadfastly refuse to even talk to 
>>>> someone like him, let alone use his version of the software
>>> Yes, and you would deprive your users. It is precisely this kind of mind
>>> game where the feelings of the distributors take precidence over the users
>>> that I object to. My attitude would be that if there is really good
>>> piece of software which my users would find useful ( and for most of the
>>> past 15 years, cdrecord was the only game in town for doing something
>>> that users find EXTREMELY useful) I would bend over backwards to provide
>>> it to them, and damn my own hurt feelings. But that is clearly not the
>>> attitude of many of the distributions. They are as obnoxious and
>>> stubborn as Jorg can be. 
>>>
>> I thionk you will find that its a bit more complex than that..Debian 
>> IIRC at least has a statement of its own about what it is and how it 
>> operates: That  was and possibly still is in conflict with Jorg.. now 
>> under those circumstances each side has a good point.
> 
> I am not saying that the two sides do not have points. I am saying that
> the pig headedness on both sides (sticking to a point way beyond what is
> reasonable) is what I see here. 
> I am not sure what the phrase "about what it is" refers to. 
> 
> Debian has made statements about the licensing. If one takes it
> literally it would outlaw a huge number of programs which are not
> outlawed from the distro. (I would point to for example any GPL3
> program. Since the kenrel is GPL2 and GPL2 ONLY, the distro must be
> released as GPL2, since GPL3 is incompatible. Since the distro is
> clearly a derived work of the kernel, it must comply with the kernel
> license (it is not a "mere aggregation" since the distro without the
> kernel would be useless, and the provision of the kernel is one of the
> key purposes of the distro), and that requires that it be released under
> GPL2. Thus, any GPL3 only program is in conflict and cannot be
> distributed. 
> Now, this may or may not be a legally valid argument, but it is at least
> as cogent as Debian's argument re cdrtools. But they refuse to accept
> this, but they push the cdrtools one. Why? Because of animosity and pig
> headedness as far as I can see. 
> 
> 
>>
>>
>> But in the end downloading and compiling is just the linux alternative 
>> to going shopping and buying and then trying to make XYZ app work.
> 
> AGreed. People can just download cdrecord and compile it. On some
> distros people have even generated scripts to do that for the user. 
> It would sure be nicer if the distro did it. 
> 
>> at LEAST with linux, if it all just 'doesn't work' you haven't wasted 
>> any money.
> 
> Well, if time is money, then yes, you have probably wasted a huge amount
> of money. (trying to figure out why something does not work can take
> hours and days).

If I cant get 'it' to work in  less than a day, then as far as I am 
concerned its not worth pursuing.

I've had a few things like that - some came as part of the distro and 
simply did not work. Some I tried to compile, hit dependency hell and 
simply abandoned.

That's the problem with Debian stable - its usually up to 18 months 
behind the latest libraries and if your app of choice wont compile on it 
  because its libraries don't match what's on your system..well life is 
too short.

But at least when the new releases get to the debian stable repo it all 
does generally work. Whereas I have windows programs costing hundreds 
that always have and irrevocably always will seg fault and crash under 
certain circumstances and only spending more money on a yet more bloated 
windows and a yet more bloated upgrades will fix the problem, Or maybe 
it won't. I dunno.


Life is not perfect.

[toc] | [prev] | [next] | [standalone]


#3952

Fromunruh <unruh@invalid.ca>
Date2012-01-28 01:54 +0000
Message-ID<bzIUq.2336$wR2.2077@newsfe01.iad>
In reply to#3951
On 2012-01-28, The Natural Philosopher <tnp@invalid.invalid> wrote:
> unruh wrote:
>> On 2012-01-27, The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> unruh wrote:
>>>> On 2012-01-27, Peter K??hlmann <peter-koehlmann@t-online.de> wrote:
>>>>> unruh wrote:
>>>>>
>>>>>> On 2012-01-26, Baho Utot <baho-utot@invlaid.com> wrote:
>>>>>>> unruh wrote:
>>>>>>>
>>>>>>>
>>>>>>> Yes this was one of his claims but he did not provide any evidence to
>>>>>>> Arch
>>>>>>> linux developers for his claims.  Lip service was all he provided and
>>>>>>> that is why his proposal to switch from cdrkit to cdrtools was rejected.
>>>>>> He has provided evidence in the past-- in the form of legal opinions on
>>>>>> the validity of some of the GPL claims.
>>>>> Which was simply a bullshit opinion.
>>>>> And then his "lawyers", who he claimed to have asked.
>>>>> They exist every bit as miuch as that infamous SCO koffer
>>>> It is clear that you have no interest in the issues, just in your
>>>> position. I have read some of the opinions he has referenced and they
>>>> make sense to me, as someone who is not a lawyer, but had spent some
>>>> time trying to understand how lawyers think. 
>>>>
>>>>> I have never seen someone making as ass out of himself and lying constantly 
>>>>> like J??rg
>>>> Again an opinion with zero backing. 
>>>>
>>>>> If I would maintain a distro, I would steadfastly refuse to even talk to 
>>>>> someone like him, let alone use his version of the software
>>>> Yes, and you would deprive your users. It is precisely this kind of mind
>>>> game where the feelings of the distributors take precidence over the users
>>>> that I object to. My attitude would be that if there is really good
>>>> piece of software which my users would find useful ( and for most of the
>>>> past 15 years, cdrecord was the only game in town for doing something
>>>> that users find EXTREMELY useful) I would bend over backwards to provide
>>>> it to them, and damn my own hurt feelings. But that is clearly not the
>>>> attitude of many of the distributions. They are as obnoxious and
>>>> stubborn as Jorg can be. 
>>>>
>>> I thionk you will find that its a bit more complex than that..Debian 
>>> IIRC at least has a statement of its own about what it is and how it 
>>> operates: That  was and possibly still is in conflict with Jorg.. now 
>>> under those circumstances each side has a good point.
>> 
>> I am not saying that the two sides do not have points. I am saying that
>> the pig headedness on both sides (sticking to a point way beyond what is
>> reasonable) is what I see here. 
>> I am not sure what the phrase "about what it is" refers to. 
>> 
>> Debian has made statements about the licensing. If one takes it
>> literally it would outlaw a huge number of programs which are not
>> outlawed from the distro. (I would point to for example any GPL3
>> program. Since the kenrel is GPL2 and GPL2 ONLY, the distro must be
>> released as GPL2, since GPL3 is incompatible. Since the distro is
>> clearly a derived work of the kernel, it must comply with the kernel
>> license (it is not a "mere aggregation" since the distro without the
>> kernel would be useless, and the provision of the kernel is one of the
>> key purposes of the distro), and that requires that it be released under
>> GPL2. Thus, any GPL3 only program is in conflict and cannot be
>> distributed. 
>> Now, this may or may not be a legally valid argument, but it is at least
>> as cogent as Debian's argument re cdrtools. But they refuse to accept
>> this, but they push the cdrtools one. Why? Because of animosity and pig
>> headedness as far as I can see. 
>> 
>> 
>>>
>>>
>>> But in the end downloading and compiling is just the linux alternative 
>>> to going shopping and buying and then trying to make XYZ app work.
>> 
>> AGreed. People can just download cdrecord and compile it. On some
>> distros people have even generated scripts to do that for the user. 
>> It would sure be nicer if the distro did it. 
>> 
>>> at LEAST with linux, if it all just 'doesn't work' you haven't wasted 
>>> any money.
>> 
>> Well, if time is money, then yes, you have probably wasted a huge amount
>> of money. (trying to figure out why something does not work can take
>> hours and days).
>
> If I cant get 'it' to work in  less than a day, then as far as I am 
> concerned its not worth pursuing.

Well, we are talking about dvd burning here, and many people consider it
pretty important, and worth getting to work. Since most seem to get
theirs to work, it is really frustrating if yours does not-- only to
discover that you have say a burner which cdrecord has worked with it
for years, and cdrkit has not yet managed to get to work. Or as with teh
OP, cdrkit produces huge files which will not fit onto a dvd, while
cdrecord produces files which fit fine. 


>
> I've had a few things like that - some came as part of the distro and 
> simply did not work. Some I tried to compile, hit dependency hell and 
> simply abandoned.

It depends on how much you need it. If you are a financial planner and
for you the spreadsheet simply does not work, you might be willing to
spend more time on it, than say, some game. 

>
> That's the problem with Debian stable - its usually up to 18 months 
> behind the latest libraries and if your app of choice wont compile on it 
>   because its libraries don't match what's on your system..well life is 
> too short.
>
> But at least when the new releases get to the debian stable repo it all 
> does generally work. Whereas I have windows programs costing hundreds 
> that always have and irrevocably always will seg fault and crash under 
> certain circumstances and only spending more money on a yet more bloated 
> windows and a yet more bloated upgrades will fix the problem, Or maybe 
> it won't. I dunno.
>
>
> Life is not perfect.
>
>

[toc] | [prev] | [next] | [standalone]


#3994

FromBaho Utot <baho-utot@invlaid.com>
Date2012-01-29 08:01 -0500
Message-ID<shsfv8-nvj.ln1@crazy-horse.bildanet.com>
In reply to#3947
unruh wrote:

> Debian has made statements about the licensing. If one takes it
> literally it would outlaw a huge number of programs which are not
> outlawed from the distro. (I would point to for example any GPL3
> program. Since the kenrel is GPL2 and GPL2 ONLY, the distro must be
> released as GPL2, since GPL3 is incompatible. Since the distro is
> clearly a derived work of the kernel, it must comply with the kernel
> license (it is not a "mere aggregation" since the distro without the
> kernel would be useless, and the provision of the kernel is one of the
> key purposes of the distro), and that requires that it be released under
> GPL2. Thus, any GPL3 only program is in conflict and cannot be

Isn't a distro a collection of software packages?

If so then a distro is not a dirivative but a collection.

Or from FSF point of view GNU+linux so linux is then an addition?

[toc] | [prev] | [next] | [standalone]


#4002

Fromunruh <unruh@invalid.ca>
Date2012-01-29 19:09 +0000
Message-ID<QPgVq.4993$JN6.3304@newsfe13.iad>
In reply to#3994
On 2012-01-29, Baho Utot <baho-utot@invlaid.com> wrote:
> unruh wrote:
>
>> Debian has made statements about the licensing. If one takes it
>> literally it would outlaw a huge number of programs which are not
>> outlawed from the distro. (I would point to for example any GPL3
>> program. Since the kenrel is GPL2 and GPL2 ONLY, the distro must be
>> released as GPL2, since GPL3 is incompatible. Since the distro is
>> clearly a derived work of the kernel, it must comply with the kernel
>> license (it is not a "mere aggregation" since the distro without the
>> kernel would be useless, and the provision of the kernel is one of the
>> key purposes of the distro), and that requires that it be released under
>> GPL2. Thus, any GPL3 only program is in conflict and cannot be
>
> Isn't a distro a collection of software packages?
>
> If so then a distro is not a dirivative but a collection.

And a collection is copyright as a derivative of the items in that
collection plus the the extras that have been added to the collection. 
Note that a distribution is far more than just a collection, as anyone
who has ever used a distribution knows. It has a character all its own,
it alters the kernel, it alters many of the items in the collection. 

Note that a novel is just a collection of words, none of which can
themselves attract copyright, and yet the book as a whole, consisting of
simply that collection of words, does attract copyright. 



>
> Or from FSF point of view GNU+linux so linux is then an addition?

What is "an addition" in light of this conversation?

>

[toc] | [prev] | [next] | [standalone]


#4041

FromDarren Salt <news@youmustbejoking.demon.cu.invalid>
Date2012-01-31 17:57 +0000
Message-ID<525FB89E24%news@youmustbejoking.demon.cu.invalid>
In reply to#3947
I demand that unruh may or may not have written...

[snip]
> Debian has made statements about the licensing. If one takes it literally
> it would outlaw a huge number of programs which are not outlawed from the
> distro. (I would point to for example any GPL3 program. Since the kenrel is
> GPL2 and GPL2 ONLY,

“The kernel”... which kernel?

Linux or FreeBSD?

Debian has both. :-þ

[snip]
-- 
|  _  | Darren Salt, using Debian GNU/Linux (and Android)
| ( ) |
|  X  | ASCII Ribbon campaign against HTML e-mail
| / \ | http://www.asciiribbon.org/

"A-LERT! A-LERT! YOU ARE THE DOC-TOR!" "SEN-SORS SHOW THAT HE IS UN-ARMED!"

[toc] | [prev] | [next] | [standalone]


Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8  Next page →

Back to top | Article view | comp.os.linux.misc


csiph-web