cdrtools
Elimar Riesebieter
Hi all,
are there any activities on that project? There is no mailinglist
active at https://alioth.debian.org/projects/pkg-cdrtools/ and the
latest cvs-entry is about 3 months ago or so. Meanwhile we have
ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01.01a10.tar.gz
# apt-cache policy cdrecord gives:
cdrecord:
Installed: 4:2.01+01a03-5
Candidate: 4:2.01+01a03-5
Version table:
*** 4:2.01+01a03-5 0
500 ftp://ftp.de.debian.org testing/main Packages
990 ftp://ftp.de.debian.org unstable/main Packages
100 /var/lib/dpkg/status
which is full of bugs.
Will the package be orphande next time?
Elimar
--
Learned men are the cisterns of knowledge,
not the fountainheads ;-)
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Daniel Baumann
> are there any activities on that project?
The licensing of cdrtools is/was under investigation of the Technical
Comitee, a final decision/action is not yet found/published so far.
For the public part of the information, read on at
http://bugs.debian.org/350739
> There is no mailinglist
> active at https://alioth.debian.org/projects/pkg-cdrtools/
There is pkg-cdrto...@lists.alioth.debian.org which is a private
list, only available to a the package maintainers, upstream and a few
others.
> Meanwhile we have
> ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01.01a10.tar.gz
Please wait until the licensing issues mentioned above are resolved.
> Will the package be orphande next time?
No, depending on the outcome of the licensing issues, either the current
maintainers still continue to maintain the package, or it has to be
removed from Debian completely.
--
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel....@panthera-systems.net
Internet: http://people.panthera-systems.net/~daniel-baumann/
George Danchev
> Elimar Riesebieter wrote:
> > are there any activities on that project?
>
> The licensing of cdrtools is/was under investigation of the Technical
> Comitee, a final decision/action is not yet found/published so far.
>
> For the public part of the information, read on at
> http://bugs.debian.org/350739
Could be an installer-only package (cdrtools-src or similar, like qmail-src
is) be a solution anyway ?
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Sam Morris
> On Thursday 06 July 2006 13:00, Daniel Baumann wrote:
>> Elimar Riesebieter wrote:
>> > are there any activities on that project?
>>
>> The licensing of cdrtools is/was under investigation of the Technical
>> Comitee, a final decision/action is not yet found/published so far.
>>
>> For the public part of the information, read on at
>> http://bugs.debian.org/350739
>
> Could be an installer-only package (cdrtools-src or similar, like qmail-src
> is) be a solution anyway ?
Such a package would cause large parts of the archive to be demoted into
contrib.
--
Sam Morris
http://robots.org.uk/
PGP key id 5EA01078
3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078
Elimar Riesebieter
Daniel Baumann told:
> Elimar Riesebieter wrote:
> > are there any activities on that project?
>
> The licensing of cdrtools is/was under investigation of the Technical
> Comitee, a final decision/action is not yet found/published so far.
>
> For the public part of the information, read on at
> http://bugs.debian.org/350739
Ahh, I didn't noticed this bug. But it shows the way Joerg is
discussing with Linux guys everywhere.
[...]
> > Will the package be orphande next time?
>
> No, depending on the outcome of the licensing issues, either the current
> maintainers still continue to maintain the package, or it has to be
> removed from Debian completely.
IMHO we have to have a GPL'd package. But at the moment I haven't
any clue which alternative we have? Joerg is very sensible and for
me it is not easy to follow the discussion between Joerg and Blade,
but in summary no one gets sensible for the arguments of the
other one. Thats not a good assumption to clarify and satisfy both
parties.
BTW, the cdrtools are very good ones, to give users very easy
intuition to burn, create ISO's or grab ogg's ion both command line
and gui frontends :)
Elimar
--
Numeric stability is probably not all that
important when you're guessing;-)
Erast Benson
> > > Will the package be orphande next time?
> >
> > No, depending on the outcome of the licensing issues, either the current
> > maintainers still continue to maintain the package, or it has to be
> > removed from Debian completely.
>
> IMHO we have to have a GPL'd package.
Hopefully, this will never be a requirement. Many people just hate GPL
and gives their preferences to an existing OSI-approved alternatives.
Daniel Baumann
> Could be an installer-only package (cdrtools-src or similar, like qmail-src
> is) be a solution anyway ?
Yes, that was discussed too.
--
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel....@panthera-systems.net
Internet: http://people.panthera-systems.net/~daniel-baumann/
George Danchev
> On Thu, 2006-07-06 at 19:56 +0200, Elimar Riesebieter wrote:
> > > > Will the package be orphande next time?
> > >
> > > No, depending on the outcome of the licensing issues, either the
> > > current maintainers still continue to maintain the package, or it has
> > > to be removed from Debian completely.
> >
> > IMHO we have to have a GPL'd package.
>
> Hopefully, this will never be a requirement. Many people just hate GPL
> and gives their preferences to an existing OSI-approved alternatives.
The requirement for main is to have a DFSG-compliant package (the license
either could be GPL, 3-clause BSD, Apache, MIT, Artistic, ...). That is DFSG
compliance what counts here, not just OSI approval. Please read that very
carefully: http://lists.debian.org/debian-legal/2006/07/msg00027.html
FWIW, statements like 'who hates what' are far from being serious. Counter
examples exists (search for 'star+openbsd' acceptance), but noone is
interested in yet another license war </over>
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Erast Benson
> On Thursday 06 July 2006 21:26, Erast Benson wrote:
> > On Thu, 2006-07-06 at 19:56 +0200, Elimar Riesebieter wrote:
> > > > > Will the package be orphande next time?
> > > >
> > > > No, depending on the outcome of the licensing issues, either the
> > > > current maintainers still continue to maintain the package, or it has
> > > > to be removed from Debian completely.
> > >
> > > IMHO we have to have a GPL'd package.
> >
> > Hopefully, this will never be a requirement. Many people just hate GPL
> > and gives their preferences to an existing OSI-approved alternatives.
>
> The requirement for main is to have a DFSG-compliant package (the license
> either could be GPL, 3-clause BSD, Apache, MIT, Artistic, ...). That is DFSG
> compliance what counts here, not just OSI approval. Please read that very
> carefully: http://lists.debian.org/debian-legal/2006/07/msg00027.html
Thanks. I'm glad Debian respects other than GPL licenses.
Kevin Bube
> On Thursday 06 July 2006 13:00, Daniel Baumann wrote:
>> Elimar Riesebieter wrote:
>> The licensing of cdrtools is/was under investigation of the Technical
>> Comitee, a final decision/action is not yet found/published so far.
>>
>> For the public part of the information, read on at
>> http://bugs.debian.org/350739
>
> Could be an installer-only package (cdrtools-src or similar, like qmail-src
> is) be a solution anyway ?
What about switching to dvdrtools [1]? I think this project was started
to solve the frequently recurring arguments about the licensing and the
device adressing scheme cdrtools use.
I don't know how far it got with its efforts, though. Maybe someone can
comment.
Regards,
Kevin
[1] http://www.arklinux.org/projects/dvdrtools
--
publickey 2048R/0AFDFB19 available at:
http://pgpkeys.pca.dfn.de:11371/pks/lookup?op=get&search=0x1BF55C710AFDFB19
fingerprint: 542B 1378 04AA AF1F 572E 78BF 1BF5 5C71 0AFD FB19
Daniel Baumann
> What about switching to dvdrtools [1]? I think this project was started
> to solve the frequently recurring arguments about the licensing and the
> device adressing scheme cdrtools use.
This was also considered as an option[0]. However, this is not the place
and not the right people (no offence) to discuss this a second time
again. The people in charge (CTTE and the maintainers) are working on an
optimal solution. They will communicate it as soon as they are ready.
[0] dvdrtools are currently in non-free (so not part of Debian at all)
and therefore not a solution/replacement - but.. Eduard spoke with
Julien why he did put it there: JS' interpretation of the GPL when it
comes to derivates (read it's copyright file) may sound strange on the
first look, but it is ok and does not conflict with any clause of the
GPL; therefore, the consens was IIRC that it will go to main, sooner or
later.
--
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel....@panthera-systems.net
Internet: http://people.panthera-systems.net/~daniel-baumann/
Adam Borowski
> Kevin Bube wrote:
> > started to solve the frequently recurring arguments about the
> > licensing and the device adressing scheme cdrtools use.
>
> and therefore not a solution/replacement
I completely fail to see any logic here:
* cdrtools, obviously completely non-free, is in main
* dvdrtools, a fork of the last GPLed version, is in non-free
The only reason why dvdrtools would sit in non-free is a controversy
whether a "clarification" can be retroactive. If it can be, it is
quite a hit to the GPL in general.
Freeness of dvdrtools is >= freeness of cdrtools, at least.
> The people in charge (CTTE and the maintainers) are working on an
> optimal solution. They will communicate it as soon as they are
> ready.
And of course, this particular case is already in good hands. What I
am interested in is whether GPL can be withdrawn. Of course, the
copyright holder can relicense new versions to his heart's content,
but can he take away people's rights from older releases? The whole
point of the GPL is to prevent _anyone_ from imposing further
restrictions that could limit the freeness of covered software, so I
would say that this would be a bad precedent.
Cheers,
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
Eduard Bloch
* Adam Borowski [Fri, Jul 07 2006, 10:38:32AM]:
> * dvdrtools, a fork of the last GPLed version, is in non-free
Please look at dvdrtools' files, eg. cdrecord.c before claiming that.
> And of course, this particular case is already in good hands. What I
> am interested in is whether GPL can be withdrawn. Of course, the
> copyright holder can relicense new versions to his heart's content,
> but can he take away people's rights from older releases? The whole
Apparently not. The current cdrtools package in topic is relicensed with
"some other license I'm not discussing here" but the initially GPLed
contributions (mkisofs and its additional components) have been kept
under the GPL.
And that is what I am forking right now. If someone is volunteering as
alpha tester or codeveloper, let me know.
Regards,
Eduard.
Kevin Bube
> * Adam Borowski [Fri, Jul 07 2006, 10:38:32AM]:
>> * dvdrtools, a fork of the last GPLed version, is in non-free
>
> Please look at dvdrtools' files, eg. cdrecord.c before claiming that.
What is wrong with that? The blurb [1] seems quite okay (i.e. GPL) to
me.
Regards,
Kevin
[1] http://www.arklinux.org/projects/dvdrtools/browser/releases/0.3.1/dvdrecord/cdrecord.c
Lars Wirzenius
> On Fri, 2006-07-07 at 08:39 -0700, Don Armstrong wrote:
> > No. The primary issue is that the mixture of a GPL+CDDL work creates a
> > work that cannot be distributed by anyone else but the copyright
> > holder.
>
> It seems to be an offtopic here, but could you please elaborate a little
> bit further, which particular statement of which license prevents it?
There were extensive discussion about this in November on debian-devel,
in the thread called "Debian based GNU/Solaris: pilot program", in which
Erast Benson also participated a lot. One article that seems pretty good
to me: http://lists.debian.org/debian-devel/2005/11/msg00123.html
I suggest we not repeat this discussion. We're not breaking new ground
here, we're beating a dry, dark patch of ground where a long time ago
(or so the elders tell us) some people used to have a hobby of hitting a
horse carcass.
If you do insist on re-iterating this discussion *again*, please do it
elsewhere than debian-devel.
Thanks.
--
Policy is your friend. Trust the Policy. Love the Policy. Obey the
Policy.
Martin Wuertele
> On Fri, 2006-07-07 at 08:39 -0700, Don Armstrong wrote:
> > No. The primary issue is that the mixture of a GPL+CDDL work creates a
> > work that cannot be distributed by anyone else but the copyright
> > holder.
>
> It seems to be an offtopic here, but could you please elaborate a little
> bit further, which particular statement of which license prevents it?
I don't know if you have seen the videos of the CDDL talk at debconf6
but the guys from SUN (and one of their attorneys was there as well)
clearly pointed out that CDDL is on purpose a GPL incompatible license.
HTH Martin
--
<ma...@debian.org> ---- Debian GNU/Linux - The Universal Operating System
<alphascorpii> Können bitte alle doofen Menschen ein eigenes Land
bekommen, und da hin gehen? BITTE?
<weasel> alphascorpii: gibt doch
schon 2 <weasel> alphascorpii: Frankreich und USA.
Erast Benson
> pe, 2006-07-07 kello 08:52 -0700, Erast Benson kirjoitti:
> > On Fri, 2006-07-07 at 08:39 -0700, Don Armstrong wrote:
> > > No. The primary issue is that the mixture of a GPL+CDDL work creates a
> > > work that cannot be distributed by anyone else but the copyright
> > > holder.
> >
> > It seems to be an offtopic here, but could you please elaborate a little
> > bit further, which particular statement of which license prevents it?
>
> There were extensive discussion about this in November on debian-devel,
> in the thread called "Debian based GNU/Solaris: pilot program", in which
> Erast Benson also participated a lot. One article that seems pretty good
> to me: http://lists.debian.org/debian-devel/2005/11/msg00123.html
>
> I suggest we not repeat this discussion. We're not breaking new ground
> here, we're beating a dry, dark patch of ground where a long time ago
> (or so the elders tell us) some people used to have a hobby of hitting a
> horse carcass.
>
> If you do insist on re-iterating this discussion *again*, please do it
> elsewhere than debian-devel.
No, I don't want to re-iterate the discussion again.
Situation were clarified by FSF leaders by Eben Moglen during GPLv3
discussion and Alex Ross summarized it in April here:
http://lists.debian.org/debian-devel/2006/04/msg00085.html
but those are bit different issues as I can see them.
Erast
Don Armstrong
> On Fri, 2006-07-07 at 10:38 +0200, Adam Borowski wrote:
> > I completely fail to see any logic here:
> > * cdrtools, obviously completely non-free, is in main
>
> is nonsense.
No. The primary issue is that the mixture of a GPL+CDDL work creates a
work that cannot be distributed by anyone else but the copyright
holder.
We don't even have to get into the argument of whether or not the CDDL
is DFSG Free or not so long as this is the case. See #377109 et al.
> And, please, don't tell me that CDDL is less free than 3-clause BSD,
> etc.
Clearly it is, but that's not at issue here.
> I'd like to see current Debian leaders to comment on this
> *political* issue and stop minority discrimination right there.
The people involved in maintaining the cdrtools package have been
commenting on this issue. They're the ones whose opinion actually
matters first. [ftpmaster's opinion is next; unless you're calling for
a GR about CDDL.] In this case, the bug has been refered to the
tech-ctte, so when they make a ruling, you'll know about it.
> > * dvdrtools, a fork of the last GPLed version, is in non-free
>
> dvdrtools - totally useless effort. Besides, its known to be buggy
> and linux-only which is against Debian philosophy therefore should
> never be in main.
Something being linux-only has never precluded it from being
distributed in main, just like a program which only runs on a single
architecture. Even then, the only kernel we officially support right
now is the linux kernel.
Don Armstrong
--
Clothes make the man. Naked people have little or no influence on
society.
-- Mark Twain
Mike Hommey
> On Fri, 2006-07-07 at 10:38 +0200, Adam Borowski wrote:
> > > Kevin Bube wrote:
> > > > What about switching to dvdrtools? I think this project was
> > > > started to solve the frequently recurring arguments about the
> > > > licensing and the device adressing scheme cdrtools use.
> > >
> > > dvdrtools are currently in non-free (so not part of Debian at all)
> > > and therefore not a solution/replacement
> >
> > I completely fail to see any logic here:
> > * cdrtools, obviously completely non-free, is in main
>
> 3-clause BSD, etc. Its OSI approved, therefore it is *free* license.
APSL 1.2 too is OSI approved. That doesn't make it a *free* license.
Mike
George Danchev
--cut--
> > * dvdrtools, a fork of the last GPLed version, is in non-free
>
Could you please report issues you face with dvdrtools to the BTS, so that can
be resolved if found to be valid.
> linux-only which is against Debian philosophy therefore should never be
> in main.
Please check Debian Policy to get a notion of what could be in main.
Furtheremore dvdrtools is (currently) not in main... find out why (hint: take
a look at the copyright file).
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Eduard Bloch
* Kevin Bube [Fri, Jul 07 2006, 11:29:21AM]:
> Eduard Bloch <e...@gmx.de> writes:
> > * Adam Borowski [Fri, Jul 07 2006, 10:38:32AM]:
>
> >> * dvdrtools, a fork of the last GPLed version, is in non-free
> >
> > Please look at dvdrtools' files, eg. cdrecord.c before claiming that.
>
> What is wrong with that? The blurb [1] seems quite okay (i.e. GPL) to
> me.
Grep for "not.allowed" and decide yourself whether such remarks are
applicable to the GPL (as applicable in your country).
Erast Benson
> > Kevin Bube wrote:
> > > What about switching to dvdrtools? I think this project was
> > > started to solve the frequently recurring arguments about the
> > > licensing and the device adressing scheme cdrtools use.
> >
> > dvdrtools are currently in non-free (so not part of Debian at all)
> > and therefore not a solution/replacement
>
> I completely fail to see any logic here:
> * cdrtools, obviously completely non-free, is in main
what? you think if it is non-GPL than it should go to non-free? This is
nonsense. And, please, don't tell me that CDDL is less free than
3-clause BSD, etc. Its OSI approved, therefore it is *free* license. I'd
like to see current Debian leaders to comment on this *political* issue
and stop minority discrimination right there.
> * dvdrtools, a fork of the last GPLed version, is in non-free
dvdrtools - totally useless effort. Besides, its known to be buggy and
linux-only which is against Debian philosophy therefore should never be
in main.
Please, reconsider and instead consolidate your efforts with current
cdrtools project.
Erast Benson
> > On Fri, 2006-07-07 at 10:38 +0200, Adam Borowski wrote:
> > > I completely fail to see any logic here:
> > > * cdrtools, obviously completely non-free, is in main
> >
> > what? you think if it is non-GPL than it should go to non-free? This
> > is nonsense.
>
> No. The primary issue is that the mixture of a GPL+CDDL work creates a
> work that cannot be distributed by anyone else but the copyright
> holder.
It seems to be an offtopic here, but could you please elaborate a little
bit further, which particular statement of which license prevents it?
Erast
Don Armstrong
On Fri, 07 Jul 2006, Erast Benson wrote:
> On Fri, 2006-07-07 at 08:39 -0700, Don Armstrong wrote:
> > On Fri, 07 Jul 2006, Erast Benson wrote:
> > > what? you think if it is non-GPL than it should go to non-free?
> > > This is nonsense.
> >
> > No. The primary issue is that the mixture of a GPL+CDDL work
> > creates a work that cannot be distributed by anyone else but the
> > copyright holder.
>
> It seems to be an offtopic here, but could you please elaborate a
> little bit further, which particular statement of which license
> prevents it?
It's pretty obvious if you read the CDDL and the GNU GPL, but just to
make it abundantly clear for those who don't read licenses for fun:
CDDL 3.1 requires that Covered Works made available in Executable form
requires the Source Code form to be distributable only under the CDDL;
CDDL 3.4 disallows additional restrictions. CDDL 6.2 (patent
retaliation) is a restriction not present in the GPL.
GPL 2 requires all of the work when distributed together to apply to
the GPL. GPL 6 dissallows additional restrictions. GPL 2c is a
requirement not present in the CDDL.
As you can see, they're incompatible with eachother in either
direction. Indeed, I've been told by those involved in the CDDL
drafting that this was done by design. [See the video of the Solaris
discussion if you want to see someone talk about it; you can also see
me discussing this issue and others as well in the same video.]
Don Armstrong
--
Cheop's Law: Nothing ever gets built on schedule or within budget.
-- Robert Heinlein _Time Enough For Love_ p242
Erast Benson
Thanks for explanations. I knew that they are incompatible but I never
fully understood why. Its clear now.
George Danchev
Well, I have the following 'and' vs. 'or' type of licensing question. While it
is clear now that Debian can not distribute a product when some of its parts
are under GPL and the rest are under CDDL ('and'), is it fine to
double-license {GPL|CDDL} the whole product like Perl does with GPL |
Artistic, so either the whole thing is under GPL or the whole thing under
CDDL as accepted by the licensee. In short, could you double license under
two incompatible licenses ? Should be fine imho, since licensee accepts just
one of them, and does not the other one.
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Don Armstrong
to -legal; please respond there only.
On Sat, 08 Jul 2006, George Danchev wrote:
> Well, I have the following 'and' vs. 'or' type of licensing
> question. While it is clear now that Debian can not distribute a
> product when some of its parts are under GPL and the rest are under
> CDDL ('and'), is it fine to double-license {GPL|CDDL} the whole
> product like Perl does with GPL | Artistic, so either the whole
> thing is under GPL or the whole thing under CDDL as accepted by the
> licensee. In short, could you double license under two incompatible
> licenses ?
As far as I understand it (TINLA, IANAL, YHBW, etc.) so long as there
is a subset of licenses available which you can use to actually
distribute the work, you ignore the licenses which you don't
distribute under. It is a good practice to list the other licenses in
the copyright file as a service to our users, but strictly speaking
they are superfluous. [In the cases where they are not, you're not
actually dual licensing the work.]
Of course, you have to actually own the copyright on the parts that
you are (re)licensing but that's probably obvious. ;-)
Don Armstrong
--
THERE IS NO GRAVITY THE WORLD SUCKS
-- Vietnam War Penquin Lighter
http://gallery.donarmstrong.com/clippings/vietnam_there_is_no_gravity.jpg
http://www.donarmstrong.com http://rzlab.ucr.edu
Nathanael Nerode
>#include <hallo.h>
>* Kevin Bube [Fri, Jul 07 2006, 11:29:21AM]:
>> Eduard Bloch <e...@gmx.de> writes:
>> > * Adam Borowski [Fri, Jul 07 2006, 10:38:32AM]:
>>
>> >
>>
>> What is wrong with that? The blurb [1] seems quite okay (i.e. GPL) to
>> me.
>
>Grep for "not.allowed" and decide yourself whether such remarks are
>applicable to the GPL (as applicable in your country).
>
>Eduard.
OK. Here are the "not allowed" elements in dvdrtools:
First, cdrecord.c:
/*
* Warning: you are not allowed to modify or to remove
this
* version checking code!
*/
This is false and unacceptable. I believe this constitutes an error on the
part of the dvdrtools upstream maintainer, who thought he'd forked from
before this was introduced. I suggest reporting this upstream and seeing if
there's an earlier version which it can be forked from.
librscg/scsi-remote.c
libscg/scsi-*.c
These are all shim layers for interfacing with different kernels'
implementations of SCSI.
My suspicion is that the best move would be to replace this library entirely.
Doesn't the Linux kernel have a fairly clean and reasonable interface to
CD-ROMs these days?
Frank Küster
> [See the video of the Solaris
> discussion if you want to see someone talk about it; you can also see
> me discussing this issue and others as well in the same video.]
By the way, were can the videos be found? Last time I tried, google
wasn't helpful.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Aníbal Monsalve Salazar
>By the way, were can the videos be found? Last time I tried, google
>wasn't helpful.
http://meetings-archive.debian.net/pub/debian-meetings/
Best Regards,
Aníbal Monsalve Salazar
--
http://v7w.com/anibal
Frans Pop
> On Mon, Jul 10, 2006 at 09:20:19AM +0200, Frank Küster wrote:
> >By the way, were can the videos be found? Last time I tried, google
> >wasn't helpful.
>
> http://meetings-archive.debian.net/pub/debian-meetings/
But most are still missing there :-(
Holger Levsen
On Monday 10 July 2006 10:20, Frans Pop wrote:
> > http://meetings-archive.debian.net/pub/debian-meetings/
> But most are still missing there :-(
I am painfully aware of this. And I am doing and have been doing what I can
do, which is not much (*). There is some light on the horizon now, so expect
less crypted information soon.
Sorry & regards,
Holger
(*) technically I could have borrowed a camera and copied >50 tapes to
harddisc and cut them again. But as the cutted videos exists on harddrive
already I have refrained from doing so so far.
Erast Benson
After reading [1] and discussing the issue with Joerg, it is still
remains unclear to me why resulted CDDL + GPL licensed work can not be
legally redistributed in Debian. Joerg actually clarified quite a bit
and his clarifications seems more reasonable than yours, i.e.
"""It may be the main point that people fear that compiling cdrtools
creates unredistibutable binaries. I see no reason why binaries may
be unredistibutable as I don't see any contradictory requirements
from CDDL/GPL. Both licenses are source licenses and require to make the
source available in case a binary is distributed. This is no
contradiction but just the same requirement."""
[1] http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=350739
Don Armstrong
> On Fri, 2006-07-07 at 20:15 -0700, Don Armstrong wrote:
> > NB: Please follow Debian list policy and refrain from Cc:'ing me.
> > CDDL 3.1 requires that Covered Works made available in Executable
> > form requires the Source Code form to be distributable only under
> > the CDDL; CDDL 3.4 disallows additional restrictions. CDDL 6.2
> > (patent retaliation) is a restriction not present in the GPL.
> >
> > GPL 2 requires all of the work when distributed together to apply
> > to the GPL. GPL 6 dissallows additional restrictions. GPL 2c is a
> > requirement not present in the CDDL.
>
> remains unclear to me why resulted CDDL + GPL licensed work can not
> be legally redistributed in Debian. Joerg actually clarified quite a
> bit and his clarifications seems more reasonable than yours, i.e.
The clarifications unfortunatly basically ignore the crux of the
rather straightforward explanation above. Indeed, what you have quoted
below is typical of the oversimplification present throughout this
discussion about what the licenses actually say, and what they mean:
> [...] Both licenses are source licenses and require to make the
> source available in case a binary is distributed. This is no
> contradiction but just the same requirement.
Regardless, both Jörg and yourself are welcome to have your own
opinion on this matter and act accordingly. What I have explained is
my interpretation, and it leads to how I would act, and how I think
Debian should act as well.
I unfortunatly do not have any additional time to spend laboriously
explaining this issue, so unless there are very specific (and brief)
arguments as to why my interpretation is incorrect, I'll stop
repeating myself (and bothering -devel) by participating further in
this discussion of ossified assertions.
Don Armstrong
--
Certainly the game is rigged. Don't let that stop you. If you don't
bet, you can't win.
-- Robert Heinlein _Time Enough For Love_ p240
Erast Benson
I don't think you can that easily close this thread. And I doubt that
Joerg needs to provide any other additional arguments other then he
already provided.
Don't forget that Joerg were main developer of cdrtools for quite some
time and we should respect his point of view on how result of his work
for the last (what 10 years?) should be licensed. Debian is built on top
of contributions made by people like Joerg. Besides, Joerg made a good
point on why he thinks that his mix of CDDL and GPL code is OK. Please
provide real fact arguments aligned with general license interpretation
rules, if none provided, I suggest to close those bugs.
Matthew Garrett
> Don't forget that Joerg were main developer of cdrtools for quite some
> time and we should respect his point of view on how result of his work
> for the last (what 10 years?) should be licensed. Debian is built on top
> of contributions made by people like Joerg. Besides, Joerg made a good
> point on why he thinks that his mix of CDDL and GPL code is OK. Please
> provide real fact arguments aligned with general license interpretation
> rules, if none provided, I suggest to close those bugs.
1) The GPL requires that all scripts used to control compilation and
installation of the executable be released under terms compatible with
the GPL.
2) The Schily makefile system is licensed under the CDDL.
3) The Schily makefile system is used to control compilation and
installation of the executable
4) The CDDL is not compatible with the GPL
Now, this can quite easily be worked around by Joerg agreeing that all
of the software in the cdrecord tarball can be treated under the terms
of the CDDL (assuming that he has the right to do so, of course - any
significant patches that have been contributed by people under the terms
of the GPL would have to be rewritten or permission granted by the
authors). Then it just ends up being a "Is CDDLed material acceptable
for Debian?" argument, which is much more straightforward but not really
suited for the debian-devel mailing list.
(For what it's worth, I have no great objection to the CDDL. Most of the
aspects of it that people claim to be unhappy with are also in the MPL,
and we still ship Mozilla quite happily. Yes, I know that most of
Mozilla is also available under the GPL. I don't really see why that's
relevant...)
--
Matthew Garrett | mjg59-chiark.ma...@srcf.ucam.org
Eric Dorland
> (For what it's worth, I have no great objection to the CDDL. Most of the
> aspects of it that people claim to be unhappy with are also in the MPL,
> and we still ship Mozilla quite happily. Yes, I know that most of
> Mozilla is also available under the GPL. I don't really see why that's
> relevant...)
Just to point out that as of Firefox/Thunderbird 2 the entire codebase
is triple licensed under the MPL, GPL and LGPL and any objection to
the MPL as far as Mozilla is concerned is fairly academic at this
point.
--
Eric Dorland <er...@kuroneko.ca>
ICQ: #61138586, Jabber: ho...@jabber.com
1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6
Matthew Garrett
> Just to point out that as of Firefox/Thunderbird 2 the entire codebase
> is triple licensed under the MPL, GPL and LGPL and any objection to
> the MPL as far as Mozilla is concerned is fairly academic at this
> point.
Seriously? That's absolutely great. Is there any sort of announcement of
this anywhere?
Thanks,
Roberto C. Sanchez
> Eric Dorland <er...@debian.org> wrote:
>
>
>>Just to point out that as of Firefox/Thunderbird 2 the entire codebase
>>is triple licensed under the MPL, GPL and LGPL and any objection to
>>the MPL as far as Mozilla is concerned is fairly academic at this
>>point.
>
>
> Seriously? That's absolutely great. Is there any sort of announcement of
> this anywhere?
What about the far more important and pressing matter of a "Reply to
List" button in Thunderbird? Has that finally been resolved?
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~roberto
Eric Dorland
>
> > Just to point out that as of Firefox/Thunderbird 2 the entire codebase
> > is triple licensed under the MPL, GPL and LGPL and any objection to
> > the MPL as far as Mozilla is concerned is fairly academic at this
> > point.
>
> Seriously? That's absolutely great. Is there any sort of announcement of
> this anywhere?
Seriously:
http://weblogs.mozillazine.org/gerv/archives/2006/03/relicensing_complete.html.
I'm hoping to have Firefox 2.0 part of etch, but with the aggressive
release schedule it may not happen.
Mike Hommey
> * Matthew Garrett (mgar...@chiark.greenend.org.uk) wrote:
> > Eric Dorland <er...@debian.org> wrote:
> >
> > > Just to point out that as of Firefox/Thunderbird 2 the entire codebase
> > > is triple licensed under the MPL, GPL and LGPL and any objection to
> > > the MPL as far as Mozilla is concerned is fairly academic at this
> > > point.
> >
> > Seriously? That's absolutely great. Is there any sort of announcement of
> > this anywhere?
>
> Seriously:
> http://weblogs.mozillazine.org/gerv/archives/2006/03/relicensing_complete.html.
Actually, only the trunk has the relicensing complete, and the trunk is
Firefox 3. Firefox 2 will still be in the same state as previous
releases, but we know most of its code is available in upstream cvs in a
really triple licensed form.
> I'm hoping to have Firefox 2.0 part of etch, but with the aggressive
> release schedule it may not happen.
I'm hoping to have Firefox 2.0beta1 uploadable to experimental somewhat soon.
Firefox 2.0 final itself is supposed to be released in august (but more
likley in september)
It might not be impossible to have it in etch (and would be preferable,
since upstream will stop support of Firefox 2 6 months after release
of Firefox 3, which is itself due Q1 2007).
Mike
Mike Hommey
> It might not be impossible to have it in etch (and would be preferable,
> since upstream will stop support of Firefox 2 6 months after release
> of Firefox 3, which is itself due Q1 2007).
... and when Firefox 3 is released, support for Firefox 1.5 will be stopped
upstream. That would mean we'd only have few months support if etch is
released as planned, in december.
Eric Dorland
> On Wed, Jul 12, 2006 at 12:47:32AM -0400, Eric Dorland <er...@debian.org> wrote:
> > * Matthew Garrett (mgar...@chiark.greenend.org.uk) wrote:
> > > Eric Dorland <er...@debian.org> wrote:
> > >
> > > > Just to point out that as of Firefox/Thunderbird 2 the entire codebase
> > > > is triple licensed under the MPL, GPL and LGPL and any objection to
> > > > the MPL as far as Mozilla is concerned is fairly academic at this
> > > > point.
> > >
> > > Seriously? That's absolutely great. Is there any sort of announcement of
> > > this anywhere?
> >
> > Seriously:
> > http://weblogs.mozillazine.org/gerv/archives/2006/03/relicensing_complete.html.
>
> Actually, only the trunk has the relicensing complete, and the trunk is
> Firefox 3. Firefox 2 will still be in the same state as previous
> releases, but we know most of its code is available in upstream cvs in a
> really triple licensed form.
Really? Gerv's post is incorrect?
> > I'm hoping to have Firefox 2.0 part of etch, but with the aggressive
> > release schedule it may not happen.
>
> I'm hoping to have Firefox 2.0beta1 uploadable to experimental somewhat soon.
> Firefox 2.0 final itself is supposed to be released in august (but more
> likley in september)
I was thinking about doing that myself :)
> It might not be impossible to have it in etch (and would be preferable,
> since upstream will stop support of Firefox 2 6 months after release
> of Firefox 3, which is itself due Q1 2007).
Oh I certainly don't think it's impossible, but the timing is tight.
Mike Hommey
> * Mike Hommey (m...@glandium.org) wrote:
> > On Wed, Jul 12, 2006 at 12:47:32AM -0400, Eric Dorland <er...@debian.org> wrote:
> > > * Matthew Garrett (mgar...@chiark.greenend.org.uk) wrote:
> > > > Eric Dorland <er...@debian.org> wrote:
> > > >
> > > > > Just to point out that as of Firefox/Thunderbird 2 the entire codebase
> > > > > is triple licensed under the MPL, GPL and LGPL and any objection to
> > > > > the MPL as far as Mozilla is concerned is fairly academic at this
> > > > > point.
> > > >
> > > > Seriously? That's absolutely great. Is there any sort of announcement of
> > > > this anywhere?
> > >
> > > Seriously:
> > > http://weblogs.mozillazine.org/gerv/archives/2006/03/relicensing_complete.html.
> >
> > Actually, only the trunk has the relicensing complete, and the trunk is
> > Firefox 3. Firefox 2 will still be in the same state as previous
> > releases, but we know most of its code is available in upstream cvs in a
> > really triple licensed form.
>
> Really? Gerv's post is incorrect?
Last time I checked (and it was after Gerv's post), the relicensing changes
were still not applied to the MOZILLA_1_8_BRANCH. Things seem to have
changed, but that needs some checking. I took some random files to check
and found out files that are not tri-licensed in the trunk, so... *sigh*
Mike Hommey
> Last time I checked (and it was after Gerv's post), the relicensing changes
> were still not applied to the MOZILLA_1_8_BRANCH. Things seem to have
> changed, but that needs some checking. I took some random files to check
> and found out files that are not tri-licensed in the trunk, so... *sigh*
After a slightly closer look, it seems most of the code is actually
tri-licensed, even in the Firefox 2 branch. Strangely enough, while the
vast majority of the code is under MPL/GPL/LGPL, some of it is under
NPL/GPL/LGPL. That doesn't change much for us, but it's still strange.
Still a lot of files don't have a license text at all, including
examples and test source code.
Some examples and test files are licensed under Mozilla-sample-code.
The most problematic files are in xpcom/reflect/xptcall/src/md/unix.
This directory contains assembler code for xpcom on several platforms.
While a lot of these files are not of any use for us (irix, vms...) some
are indeed used:
xptcinvoke_asm_ppc_linux.s, xptcstubs_asm_ppc_linux.s and
xptcinvoke_asm_sparc_linux.s are NPL only ;
xptcinvoke_asm_mips.s is MPL.
I'm going to contact Gerv about that.
Erast Benson
> Erast Benson <er...@gnusolaris.org> wrote:
>
> > Don't forget that Joerg were main developer of cdrtools for quite some
> > time and we should respect his point of view on how result of his work
> > for the last (what 10 years?) should be licensed. Debian is built on top
> > of contributions made by people like Joerg. Besides, Joerg made a good
> > point on why he thinks that his mix of CDDL and GPL code is OK. Please
> > provide real fact arguments aligned with general license interpretation
> > rules, if none provided, I suggest to close those bugs.
>
> 1) The GPL requires that all scripts used to control compilation and
> installation of the executable be released under terms compatible with
> the GPL.
Joerg clearly stands that:
1) Makefiles != scripts or at least it is unclear whether Makefiles may
be called "scripts":
""" GPL §3 requires the "scripts for compilation" to be provided but
as a first note, it is unclear whether Makefiles may be called
"scripts".
Makefiles are programs written in a non-scripting language:
I call this language "make". It is a non-algorithmic language but
a rule based language (like e.g. CDL2)."""
but this is not the main point of his argument.
> 2) The Schily makefile system is licensed under the CDDL.
which is totally fine (read below)
> 3) The Schily makefile system is used to control compilation and
> installation of the executable
Makefile(s) are not exactly scripts... (read above)
> 4) The CDDL is not compatible with the GPL
But not in his case. He explains:
"""Next point is that GPL §2 requires that the whole code of a project
(if you carefully read GPL §2, this does only include things that do
end up in the binary) that is made from including other peoples GPL code
is to be made available under the GPL.
This means in other words: If I take other people's GPL code and create
a "derived work" from that code, I need to make the whole work available
under GPL. I do not need to make non-GPL code available at all, if GPL
code is derived on that code. I do not need to make the build system
available under GPL (GPL §3 requires me to make it available but does
not mention a license) and the build system is not code that is
"derived" from the GPLd project."""
later he explains:
"""This means in other words: If I take other people's GPL code and
create a "derived work" from that code, I need to make the whole work
available under GPL. I do not need to make non-GPL code available at
all, if GPL code is derived on that code. I do not need to make the
build system available under GPL (GPL §3 requires me to make it
available but does not mention a license) and the build system is not
code that is "derived" from the GPLd project."""
The key point is: GPL is pure source license. It does not explicitly
require you to use a specific license for the binary in case you make
the source available.
Erast
Eric Dorland
> > Last time I checked (and it was after Gerv's post), the relicensing changes
> > were still not applied to the MOZILLA_1_8_BRANCH. Things seem to have
> > changed, but that needs some checking. I took some random files to check
> > and found out files that are not tri-licensed in the trunk, so... *sigh*
>
> After a slightly closer look, it seems most of the code is actually
> tri-licensed, even in the Firefox 2 branch. Strangely enough, while the
> vast majority of the code is under MPL/GPL/LGPL, some of it is under
> NPL/GPL/LGPL. That doesn't change much for us, but it's still strange.
> Still a lot of files don't have a license text at all, including
> examples and test source code.
Well I'm glad it's mostly resolved. It's odd that there are still
things licensed under the NPL. http://www.mozilla.org/MPL/ says it's
not even used in any mozilla code anymore.
> Some examples and test files are licensed under Mozilla-sample-code.
Uh, is that actually a license?
> The most problematic files are in xpcom/reflect/xptcall/src/md/unix.
> This directory contains assembler code for xpcom on several platforms.
> While a lot of these files are not of any use for us (irix, vms...) some
> are indeed used:
> xptcinvoke_asm_ppc_linux.s, xptcstubs_asm_ppc_linux.s and
> xptcinvoke_asm_sparc_linux.s are NPL only ;
> xptcinvoke_asm_mips.s is MPL.
Even if we don't use the irix, vms, etc files, if they're problematic
license-wise, we'd need to strip them out or get the license fixed.
> I'm going to contact Gerv about that.
Fantastic.
Matthew Garrett
> On Wed, 2006-07-12 at 01:02 +0100, Matthew Garrett wrote:
>> 1) The GPL requires that all scripts used to control compilation and
>> installation of the executable be released under terms compatible with
>> the GPL.
>
> Joerg clearly stands that:
>
> 1) Makefiles != scripts or at least it is unclear whether Makefiles may
> be called "scripts":
At that point we start getting into semantic arguments that are
basically uninteresting to anyone other than a judge (and possibly not
even then). As copyright holder, if this is Joerg's opinion, he can add
an exception to the license that avoids the problem entirely.
> This means in other words: If I take other people's GPL code and create
> a "derived work" from that code, I need to make the whole work available
> under GPL. I do not need to make non-GPL code available at all, if GPL
> code is derived on that code. I do not need to make the build system
> available under GPL (GPL §3 requires me to make it available but does
> not mention a license) and the build system is not code that is
> "derived" from the GPLd project."""
It's an interesting arugment But, again, this is semantic bickering and
entirely unnecessary - if Joerg is copyright holder, he can ensure that
the license reflects his opinion.
> The key point is: GPL is pure source license. It does not explicitly
> require you to use a specific license for the binary in case you make
> the source available.
Can I suggest you read section 2(b)?
--
Matthew Garrett | mjg59-chiark.ma...@srcf.ucam.org
Mike Hommey
> > Some examples and test files are licensed under Mozilla-sample-code.
>
> Uh, is that actually a license?
Yes it is:
BEGIN LICENSE BLOCK
Version: Mozilla-sample-code 1.0
Copyright (c) 2002 Netscape Communications Corporation and
other contributors
Permission is hereby granted, free of charge, to any person obtaining a
copy of this Mozilla sample software and associated documentation files
(the "Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to permit
persons to whom the Software is furnished to do so, subject to the
following conditions:
The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
Contributor(s):
END LICENSE BLOCK
If you want a full licensing status on the mozilla code base, take a
look to
http://packages.debian.org/changelogs/pool/main/x/xulrunner/current/copyright
which I actually need to update, I saw that some files changed to
tri-license between 1.8.0.1 and 1.8.0.4...
> > The most problematic files are in xpcom/reflect/xptcall/src/md/unix.
> > This directory contains assembler code for xpcom on several platforms.
> > While a lot of these files are not of any use for us (irix, vms...) some
> > are indeed used:
> > xptcinvoke_asm_ppc_linux.s, xptcstubs_asm_ppc_linux.s and
> > xptcinvoke_asm_sparc_linux.s are NPL only ;
> > xptcinvoke_asm_mips.s is MPL.
>
> Even if we don't use the irix, vms, etc files, if they're problematic
> license-wise, we'd need to strip them out or get the license fixed.
The point was that in the worst case scenario, we can't remove the files
I listed without removing support for these architectures. The others
can be removed without harm.
Another thing that is a bit annoying is that the LICENSE file in the
upstream tarball is the MPL license text. It'd be better for everyone if
they'd make it clear that everything in the tarball, except external
libraries such as expat, libpng, etc. are tri-licensed.
Adam Borowski
> Joerg clearly stands that:
>
> 1) Makefiles != scripts or at least it is unclear whether Makefiles may
> be called "scripts":
>
> """ GPL §3 requires the "scripts for compilation" to be provided but
> as a first note, it is unclear whether Makefiles may be called
> "scripts".
Er, wait. This is complete nonsense: the very definition of a
makefile is "compilation script".
> Makefiles are programs written in a non-scripting language:
> I call this language "make". It is a non-algorithmic language but
> a rule based language (like e.g. CDL2)."""
The word "script" in computing came from theater, previously meaning
"screenplay", listing the things actors have to do, in a particular
order.
Makefile does exactly that, lists what compiler/linker/etc have to
do, in a given order.
Thus, a makefile is certainly more a script than for example a Perl
module, and if it's not a "compilation script", then I don't know
what is.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
Ian Jackson
> Joerg clearly stands that:
>
> 1) Makefiles != scripts or at least it is unclear whether Makefiles may
> be called "scripts":
>
> """ GPL §3 requires the "scripts for compilation" to be provided but
> as a first note, it is unclear whether Makefiles may be called
> "scripts".
This is an absurd interpretation. `The scripts used to control
compilation and installation of the executable' would be an empty set
for much GNU software if it didn't include the Makefiles. It is
obvious that that phrase was included in the GPL specifically to
ensure that the build system is covered.
If it's not obvious to someone then that person is either
(a) dishonest or (b) astonishingly out of touch with reality.
Ian.
Erast Benson
I don't want to insist on (1) too. But I must agree with Joerg that it
is unclear if Makefiles could be called as "scripts for compilation".
Makefiles are programs written in non-scripting language. To understand
what non-scripting language is, I googled this:
"""I'd define a scripting language as one which requires you to put $
or whatever in front of variable names, and makes quoting strings an
optional construct, and does string variable substitution inside string
constants unless you force it not to with odd escape characters.
A non-scripting language is one which has simple, clear-cut lexical
conventions and parsing syntax."""
Jim Crilly
> On Thu, 2006-07-13 at 12:59 +0100, Ian Jackson wrote:
> > Erast Benson writes ("Re: cdrtools"):
> > > Joerg clearly stands that:
> > >
> > > 1) Makefiles != scripts or at least it is unclear whether Makefiles may
> > > be called "scripts":
> > >
> > > """ GPL §3 requires the "scripts for compilation" to be provided but
> > > as a first note, it is unclear whether Makefiles may be called
> > > "scripts".
> >
> > This is an absurd interpretation. `The scripts used to control
> > compilation and installation of the executable' would be an empty set
> > for much GNU software if it didn't include the Makefiles. It is
> > obvious that that phrase was included in the GPL specifically to
> > ensure that the build system is covered.
> >
> > If it's not obvious to someone then that person is either
> > (a) dishonest or (b) astonishingly out of touch with reality.
>
> I don't want to insist on (1) too. But I must agree with Joerg that it
> is unclear if Makefiles could be called as "scripts for compilation".
Do you consider debian/rules in all of the Debian packages a makefile or a
script? The fact that I can put '#!/usr/bin/make -f' at the top of a file
and run it as I would any other script would definitely make it appear to
be a script.
> Makefiles are programs written in non-scripting language. To understand
> what non-scripting language is, I googled this:
>
> """I'd define a scripting language as one which requires you to put $
> or whatever in front of variable names, and makes quoting strings an
> optional construct, and does string variable substitution inside string
> constants unless you force it not to with odd escape characters.
> A non-scripting language is one which has simple, clear-cut lexical
> conventions and parsing syntax."""
Well I guess that means Python isn't a scripting language since it fails to
meet at least the 'variable usage requires sigils' criteria.
Jim.
David Pashley
>
> I don't want to insist on (1) too. But I must agree with Joerg that it
> is unclear if Makefiles could be called as "scripts for compilation".
>
> Makefiles are programs written in non-scripting language. To understand
> what non-scripting language is, I googled this:
>
> """I'd define a scripting language as one which requires you to put $
> or whatever in front of variable names, and makes quoting strings an
> optional construct, and does string variable substitution inside string
> constants unless you force it not to with odd escape characters.
> A non-scripting language is one which has simple, clear-cut lexical
> conventions and parsing syntax."""
>
executes it. The language is a mixture of declarative and iterative
programming. It clearly falls in the remit of scripts for compilation.
Your paragraph appears to make python a non-scripting language.
[0] make(1)
[1] Makefile
--
David Pashley
da...@davidpashley.com
Nihil curo de ista tua stulta superstitione.
Luis Rodrigo Gallardo Cruz
> On Thu, 2006-07-13 at 12:59 +0100, Ian Jackson wrote:
> > Erast Benson writes ("Re: cdrtools"):
> > > Joerg clearly stands that:
> > >
> > > 1) Makefiles != scripts or at least it is unclear whether Makefiles may
> > > be called "scripts":
>
> is unclear if Makefiles could be called as "scripts for compilation".
>
> Makefiles are programs written in non-scripting language. To understand
> what non-scripting language is, I googled this:
>
> """I'd define a scripting language as one which requires you to put $
> or whatever in front of variable names, and makes quoting strings an
> optional construct, and does string variable substitution inside string
> constants unless you force it not to with odd escape characters.
> A non-scripting language is one which has simple, clear-cut lexical
> conventions and parsing syntax."""
So, scripting language == pretty much just perl?
And, anyways, vars in Makefiles are $(var). And there's no quotes. And
it substitutes vars in strings.
--
Rodrigo Gallardo
GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28
Roger Leigh
> On Thu, 2006-07-13 at 12:59 +0100, Ian Jackson wrote:
>> Erast Benson writes ("Re: cdrtools"):
>> > Joerg clearly stands that:
>> >
>> > 1) Makefiles != scripts or at least it is unclear whether Makefiles may
>> > be called "scripts":
>> >
>> > """ GPL §3 requires the "scripts for compilation" to be provided but
>> > as a first note, it is unclear whether Makefiles may be called
>> > "scripts".
>>
>> This is an absurd interpretation. `The scripts used to control
>> compilation and installation of the executable' would be an empty set
>> for much GNU software if it didn't include the Makefiles. It is
>> obvious that that phrase was included in the GPL specifically to
>> ensure that the build system is covered.
>>
>> If it's not obvious to someone then that person is either
>> (a) dishonest or (b) astonishingly out of touch with reality.
>
> I don't want to insist on (1) too. But I must agree with Joerg that it
> is unclear if Makefiles could be called as "scripts for compilation".
This is a minority viewpoint, IMO. We could argue for months about
what a "script" is, but that wouldn't help much. Makefiles are often
referred to as "build scripts", and I don't think many folks would
argue that they are *not* scripts.
Look at the complete definition:
,----
| The source code for a work means the preferred form of the work for
| making modifications to it. For an executable work, complete source
| code means all the source code for all modules it contains, plus any
| associated interface definition files, plus the scripts used to
| control compilation and installation of the executable.
`----
> Makefiles are programs written in non-scripting language. To understand
> what non-scripting language is, I googled this:
>
> """I'd define a scripting language as one which requires you to put $
> or whatever in front of variable names, and makes quoting strings an
> optional construct, and does string variable substitution inside string
> constants unless you force it not to with odd escape characters.
> A non-scripting language is one which has simple, clear-cut lexical
> conventions and parsing syntax."""
You are going into nitpicking arguments about semantics and
definitions at this point, which is not particularly useful: you are
wasting everyone's time, including your own.
The intent of the GPL requirement is clear: the build system in a
distributed source tree licensed under the GPL must be GPL (or
compatible with the GPL). That is, the mechanism used to build GPL
code is an intrinsic part of a GPL licensed work, and so cannot be
licensed in an incompatible manner.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please sign and encrypt your mail.
Erast Benson
> Erast Benson <er...@gnusolaris.org> writes:
>
> > On Thu, 2006-07-13 at 12:59 +0100, Ian Jackson wrote:
> >> Erast Benson writes ("Re: cdrtools"):
> >> > Joerg clearly stands that:
> >> >
> >> > 1) Makefiles != scripts or at least it is unclear whether Makefiles may
> >> > be called "scripts":
> >> >
> >> > """ GPL §3 requires the "scripts for compilation" to be provided but
> >> > as a first note, it is unclear whether Makefiles may be called
> >> > "scripts".
> >>
> >> This is an absurd interpretation. `The scripts used to control
> >> compilation and installation of the executable' would be an empty set
> >> for much GNU software if it didn't include the Makefiles. It is
> >> obvious that that phrase was included in the GPL specifically to
> >> ensure that the build system is covered.
> >>
> >> If it's not obvious to someone then that person is either
> >> (a) dishonest or (b) astonishingly out of touch with reality.
> >
> > I don't want to insist on (1) too. But I must agree with Joerg that it
> > is unclear if Makefiles could be called as "scripts for compilation".
>
> This is a minority viewpoint, IMO. We could argue for months about
> what a "script" is, but that wouldn't help much. Makefiles are often
> referred to as "build scripts", and I don't think many folks would
> argue that they are *not* scripts.
sure. and many would argue that it is not. I personally don't care much.
Well, it is not really productive, and as I said, I don't want to insist
on (1). So, for me, this topic is closed.
George Danchev
I'd rather expect some alternatives to cdrtools to be discussed in -devel ML,
because it is pretty insane to rely on a single point of failure like that
one (competition always makes things work better), and license issues
discussion to be moved to -legal or appropriate buglogs into BTS.
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Wouter Verhelst
> If it's not obvious to someone then that person is either
> (a) dishonest or (b) astonishingly out of touch with reality.
That would seem to be an accurate description of some certain author of
some certain rather popular CD-writing tool...
<ducks>
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Wouter Verhelst
> > Erast Benson writes ("Re: cdrtools"):
> > > Joerg clearly stands that:
> > >
> > > 1) Makefiles != scripts or at least it is unclear whether Makefiles may
> > > be called "scripts":
> > >
> > > """ GPL §3 requires the "scripts for compilation" to be provided but
> > > as a first note, it is unclear whether Makefiles may be called
> > > "scripts".
> >
> > This is an absurd interpretation. `The scripts used to control
> > compilation and installation of the executable' would be an empty set
> > for much GNU software if it didn't include the Makefiles. It is
> > obvious that that phrase was included in the GPL specifically to
> > ensure that the build system is covered.
> >
> > If it's not obvious to someone then that person is either
> > (a) dishonest or (b) astonishingly out of touch with reality.
>
> I don't want to insist on (1) too. But I must agree with Joerg that it
> is unclear if Makefiles could be called as "scripts for compilation".
>
> Makefiles are programs written in non-scripting language. To understand
> what non-scripting language is, I googled this:
>
> """I'd define a scripting language as one which requires you to put $
> or whatever in front of variable names,
$(MAKE)
$(CC)
$<
are all valid make varialbes.
So, check.
> and makes quoting strings an optional construct,
Direct quote from the `make' info file:
objects = main.o foo.o bar.o utils.o
check.
> and does string variable substitution inside string constants unless
> you force it not to with odd escape characters.
I'll leave out the example to keep your and my sanity on par with some
standard we both may want to adhere to. Check, anyway.
> A non-scripting language is one which has simple, clear-cut lexical
> conventions and parsing syntax."""
Anyone claiming that make has 'simple, clear-cut lexical conventions'
needs to go see a doctor.
How's it that make isn't a scripting language?
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Mike Hommey
> On Wed, Jul 12, 2006 at 10:10:29AM +0200, Mike Hommey <m...@glandium.org> wrote:
> > Last time I checked (and it was after Gerv's post), the relicensing changes
> > were still not applied to the MOZILLA_1_8_BRANCH. Things seem to have
> > changed, but that needs some checking. I took some random files to check
> > and found out files that are not tri-licensed in the trunk, so... *sigh*
>
> After a slightly closer look, it seems most of the code is actually
> tri-licensed, even in the Firefox 2 branch. Strangely enough, while the
> vast majority of the code is under MPL/GPL/LGPL, some of it is under
> NPL/GPL/LGPL. That doesn't change much for us, but it's still strange.
> Still a lot of files don't have a license text at all, including
> examples and test source code.
> Some examples and test files are licensed under Mozilla-sample-code.
>
> The most problematic files are in xpcom/reflect/xptcall/src/md/unix.
> This directory contains assembler code for xpcom on several platforms.
> While a lot of these files are not of any use for us (irix, vms...) some
> are indeed used:
> xptcinvoke_asm_ppc_linux.s, xptcstubs_asm_ppc_linux.s and
> xptcinvoke_asm_sparc_linux.s are NPL only ;
> xptcinvoke_asm_mips.s is MPL.
>
> I'm going to contact Gerv about that.
I got a clarifying answer. The relicensing is indeed done, which means
they got permission from all the contributors involved to relicense the
relevant things. Some things may not be MPL/GPL/LGPL if they are under
compatible licensing terms (such as the Mozilla-sample-code license).
Some others, such as the assembler files I was talking about were just
missed by the license status checking scripts and can be considered
relicensed.
Eric Dorland
That's just the MIT license renamed it would appear.
> If you want a full licensing status on the mozilla code base, take a
> look to
> http://packages.debian.org/changelogs/pool/main/x/xulrunner/current/copyright
> which I actually need to update, I saw that some files changed to
> tri-license between 1.8.0.1 and 1.8.0.4...
Wow, I should really update the copyright file in firefox.
> > > The most problematic files are in xpcom/reflect/xptcall/src/md/unix.
> > > This directory contains assembler code for xpcom on several platforms.
> > > While a lot of these files are not of any use for us (irix, vms...) some
> > > are indeed used:
> > > xptcinvoke_asm_ppc_linux.s, xptcstubs_asm_ppc_linux.s and
> > > xptcinvoke_asm_sparc_linux.s are NPL only ;
> > > xptcinvoke_asm_mips.s is MPL.
> >
> > Even if we don't use the irix, vms, etc files, if they're problematic
> > license-wise, we'd need to strip them out or get the license fixed.
>
> The point was that in the worst case scenario, we can't remove the files
> I listed without removing support for these architectures. The others
> can be removed without harm.
Indeed.
> Another thing that is a bit annoying is that the LICENSE file in the
> upstream tarball is the MPL license text. It'd be better for everyone if
> they'd make it clear that everything in the tarball, except external
> libraries such as expat, libpng, etc. are tri-licensed.
Should we file a bug?
Mike Hommey
> > Another thing that is a bit annoying is that the LICENSE file in the
> > upstream tarball is the MPL license text. It'd be better for everyone if
> > they'd make it clear that everything in the tarball, except external
> > libraries such as expat, libpng, etc. are tri-licensed.
>
> Should we file a bug?
I'm in contact with Gerv about all these issues. Stay tuned.
Toni Mueller
Hello,
[ I'm leaning somewhat out of the window here w/o being a law expert ]
On Wed, 12.07.2006 at 12:46:51 -0700, Erast Benson <er...@gnusolaris.org> wrote:
> Joerg clearly stands that:
>
> 1) Makefiles != scripts or at least it is unclear whether Makefiles may
> be called "scripts":
> ...
> Makefiles are programs written in a non-scripting language:
> I call this language "make". It is a non-algorithmic language but
but he and you are dead wrong on that, imho. For me at least, a
"script" is anything that can be executed using shebang, and makefiles
_can_, as your famous debian/rules file demonstrates.
> This means in other words: If I take other people's GPL code and create
> a "derived work" from that code, I need to make the whole work available
> under GPL. I do not need to make non-GPL code available at all, if GPL
> code is derived on that code. I do not need to make the build system
> available under GPL (GPL §3 requires me to make it available but does
> not mention a license) and the build system is not code that is
> "derived" from the GPLd project."""
This is imho a very broken interpretation because the build system is
usually an intimate part of the whole, and often enough, source code
with no idea about how to tie everything together is not nearly half as
useful as a "full" source is. Think of KDE w/o a build system, or the
Linux kernel, for instance... which would almost certainly defeat the
purpose of enabling others to change and expand on "given" code, and
also open the door for all kinds of abuse.
Maybe we should solicit the legal opinion of the FSFE or so on this
matter. But in reality, this all belongs on legal@.
Best,
--Toni++
Josselin Mouette
> Now, this can quite easily be worked around by Joerg agreeing that all
> of the software in the cdrecord tarball can be treated under the terms
> of the CDDL (assuming that he has the right to do so, of course - any
> significant patches that have been contributed by people under the terms
> of the GPL would have to be rewritten or permission granted by the
> authors). Then it just ends up being a "Is CDDLed material acceptable
> for Debian?" argument, which is much more straightforward but not really
> suited for the debian-devel mailing list.
As long as he keeps the "you cannot change this part of the code" blurb,
the most problematic issue remains. The GFDL GR made it very clear that
we won't accept invariant sections, and this is even more true for code.
This is a fundamental disagreement between Joerg Schilling and the
project, and unless he removes that blurb there is no way recent
cdrecord versions can be packaged in main.
--
.''`. Josselin Mouette /\./\
: :' : josselin...@ens-lyon.org
`. `' jo...@debian.org
`- Debian GNU/Linux -- The power of freedom
Anthony DeRobertis
>
> I do not need to make the build system
> available under GPL (GPL §3 requires me to make it available but does
> not mention a license)
GPL 3(a) requires the "complete corresponding source code [be]
distributed under the terms of Sections 1 and 2 above....". GPL 3
defines the source code to include the "the scripts used to control
compilation and installation of the executable."
Section 2(b) requires third parties to publish derived works under the
GPL ("to be licensed as a whole at no charge to all third parties under
the terms of this License."). Section 2 also states "[T]he distribution
of the whole must be on the terms of this License, whose permissions for
other licensees extend to the entire whole, and thus to each and every
part regardless of who wrote it."
Joerg Schilling
>Erast Benson wrote:
>>
>> I do not need to make the build system
>> available under GPL (GPL §3 requires me to make it available but does
>> not mention a license)
>GPL 3(a) requires the "complete corresponding source code [be]
>distributed under the terms of Sections 1 and 2 above....". GPL 3
>defines the source code to include the "the scripts used to control
>compilation and installation of the executable."
Again a person who tries to bend the GPL to his wishes......
You should better _read_ the GPL and try to understand it.
GPL §2 defines what the "work" is and requres to publish the whole
work under the GPL in case that that work incorporates other
peoples work under GPL. (*)
The GPL allows to publish "the scripts used to control
compilation and installation of the executable." under _any_ license
as the scripts are not part of the "work".
Note it is unclear whether the makefiles could be called "scripts"
and that in case of cdrtools, the build system is even a _different_
"work" that has been published _before_ the first cdrecord came out.
*) It does not even require to publish the whole work under the GPL
in case that you add code to a GPL project! In this case the added
code may under _any_ license (even Closed source).
AGAIN: If you like to understant/interpret a contract like the GPL,
you need to read it carefully word by word and are not allowed to
add claims that are not written in the GPL.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Wouter Verhelst
> Anthony DeRobertis wrote:
> >Erast Benson wrote:
> >> I do not need to make the build system
> >> available under GPL (GPL §3 requires me to make it available but does
> >> not mention a license)
>
> >GPL 3(a) requires the "complete corresponding source code [be]
> >distributed under the terms of Sections 1 and 2 above....". GPL 3
> >defines the source code to include the "the scripts used to control
> >compilation and installation of the executable."
>
> Again a person who tries to bend the GPL to his wishes......
Gee, that sounds familiar somehow.
> You should better _read_ the GPL and try to understand it.
Good plan.
> GPL §2 defines what the "work" is and requres to publish the whole
> work under the GPL in case that that work incorporates other
> peoples work under GPL. (*)
>
> The GPL allows to publish "the scripts used to control
> compilation and installation of the executable." under _any_ license
> as the scripts are not part of the "work".
These scripts are referred to in GPL§3, not §2. So much for reading the
GPL.
GPL§3 clearly says what you may do when you distribute binary versions
of the Program, and gives you three options:
3a) accompany it with complete source code, to be distributed "under the
terms of Sections 1 and 2 above" (i.e., under the GPL);
3b) accompany it with a written offer to offer the source "under the
terms of Sections 1 and 2 above" (i.e., under the GPL);
3c) pass on an already existing written offer as defined in 3b), under
certain conditions
Additionally, it defines "source code" as follows:
===
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scrips used to
control compilation and installation of the executable.[...]
===
I fail to see how your claim holds, given the above, but I'm willing to
be educated.
> Note it is unclear whether the makefiles could be called "scripts"
Unproven assertion.
> and that in case of cdrtools, the build system is even a _different_
> "work" that has been published _before_ the first cdrecord came out.
If you're referring to smake here, then I cannot help but disagree with
you.
Surely automake, GNU make, bash, and so on, were written before most of
the projects that use them. However, that does not mean that the build
system is a totally different "work"; the particular version of
configure.ac, Makefile.am/Makefile.in/Makefile, and any .sh scripts that
are part of the source tarball are part of the build system, even if the
interpreters that are used to run them are not.
In the same way, smake is indeed a different work, but the makefiles
that are shipped with cdrecord are not.
Am I missing something?
> *) It does not even require to publish the whole work under the GPL
> in case that you add code to a GPL project! In this case the added
> code may under _any_ license (even Closed source).
Could you quote the part of the GPL on which you base this assertion? It
is not clear to me.
> AGAIN: If you like to understant/interpret a contract like the GPL,
The GPL is a license, not a contract.
> you need to read it carefully word by word and are not allowed to
> add claims that are not written in the GPL.
Exactly.
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Stephen Gran
> On Sun, Jul 30, 2006 at 11:25:00AM +0200, Joerg Schilling wrote:
> > Again a person who tries to bend the GPL to his wishes......
>
> Gee, that sounds familiar somehow.
Haven't we reached the point where we have noticed that all posts by JS
are understood as being based in a special fantasy land only inhabited
by him and a few fanboys?
Can we move on? I am slightly bored with having my various mailboxes
filled with fantastical interpretations of licenses, and would like to
move on to new and different flamewars, if we could.
Thanks all,
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sg...@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Matthew R. Dempsky
> On Sun, Jul 30, 2006 at 11:25:00AM +0200, Joerg Schilling wrote:
> > Note it is unclear whether the makefiles could be called "scripts"
>
> Unproven assertion.
How is something proven unclear?
Wouter Verhelst
> On Sun, Jul 30, 2006 at 10:03:14PM +0200, Wouter Verhelst wrote:
> > On Sun, Jul 30, 2006 at 11:25:00AM +0200, Joerg Schilling wrote:
> > > Note it is unclear whether the makefiles could be called "scripts"
> >
> > Unproven assertion.
>
> How is something proven unclear?
'unexplained', then. Whatever.
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Joerg Schilling
> > You should better _read_ the GPL and try to understand it.
>
> Good plan.
Did you have some time to make your plan reality meanwhile?
> > GPL §2 defines what the "work" is and requres to publish the whole
> > work under the GPL in case that that work incorporates other
> > peoples work under GPL. (*)
> >
> > The GPL allows to publish "the scripts used to control
> > compilation and installation of the executable." under _any_ license
> > as the scripts are not part of the "work".
>
> These scripts are referred to in GPL§3, not §2. So much for reading the
> GPL.
Wow, so it seems that you did read at least parts of the GPL...
> GPL§3 clearly says what you may do when you distribute binary versions
> of the Program, and gives you three options:
But this is unrelated to the problem Debian seems to construct.
You should read the GPL more carefully.
> Additionally, it defines "source code" as follows:
>
> ===
> The source code for a work means the preferred form of the work for
> making modifications to it. For an executable work, complete source
> code means all the source code for all modules it contains, plus any
> associated interface definition files, plus the scrips used to
> control compilation and installation of the executable.[...]
> ===
In case you did read the GPL carfully enough you should know that
GPL §2 and GPL §3 speak about differnt things.
GPL §3 speaks about "complete source", while GPL §2 speaks about "the work"
which from what GPL §3 sais is _less_ than the "complete source".
/*--------------------------------------------------------------------------*/
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
/*--------------------------------------------------------------------------*/
does not mean more than: "make 'the work' available under GPL (in case
'the work' is a 'derived work' and make the rest for the 'complete source'
available under any license you like".
> I fail to see how your claim holds, given the above, but I'm willing to
> be educated.
You ned to carefully read the GPL as long as you need in order to understand
it by your own.
Do not read GPL FAQs, as most of them (including the one from FSF) are not
100% correct.
> > Note it is unclear whether the makefiles could be called "scripts"
>
> Unproven assertion.
Unproven claim!
> > and that in case of cdrtools, the build system is even a _different_
> > "work" that has been published _before_ the first cdrecord came out.
>
> If you're referring to smake here, then I cannot help but disagree with
> you.
It would help a lot if you did educate yourself about the problem _before_
you try to comment it...
> Surely automake, GNU make, bash, and so on, were written before most of
> the projects that use them. However, that does not mean that the build
> system is a totally different "work"; the particular version of
> configure.ac, Makefile.am/Makefile.in/Makefile, and any .sh scripts that
> are part of the source tarball are part of the build system, even if the
> interpreters that are used to run them are not.
This is completely irelevent, why did you write it?
> In the same way, smake is indeed a different work, but the makefiles
> that are shipped with cdrecord are not.
>
> Am I missing something?
You did miss nearly everything of importance :-(
I encourage you to look at _cdrtools_ and not at any random other project.
While smake is of course older than GNU make, it is (currently) not needed
in order to compile cdrtools. This may change in future in case that I need
features that are not present with GNU make.
Note that smake could have died 10 years ago, but I needed to maintain
and enhance it in order to get a really portable make program.
GNU make is unmaintained since at least 7 years, it has many bugs that
make it extremely user-unfriendly when used together with "The Schily
Makefilesystem" and GNU make is far less prtable than smake. This is why
I recommend smake to compile my software.
It is obvious that it makes more sense to put effort in an own project than
wasting time with un-responsive GNU make maintainers.
smake is not part of cdrtools but another project I am working on:
"The Schily Makefilesystem"
is. This is definitely a project that is _separate_ from cdrtools but included
as a sub-project.
- This project ("The Schily Makefilesystem") contains > 300 kB of
_project-independent_ makefiles/rules.
- The "Makefile" that is e.g. part of the "mkisofs" project is
only 2477 bytes in size. Only 1243 Bytes in this file are specific
to mkisofs and not copied from a (project-independent) template.
- The "Makefile" that is e.g. part of the "mkisofs" project comes
with the _same_ license as "mkisofs" comes and _this_ file is of
course part of the sub-project "mkisofs". This _project-dependent_
file is much less than 1% of the project indepenent "The Schily
Makefilesystem".
> > *) It does not even require to publish the whole work under the GPL
> > in case that you add code to a GPL project! In this case the added
> > code may under _any_ license (even Closed source).
>
> Could you quote the part of the GPL on which you base this assertion? It
> is not clear to me.
I did this already many times: GPL §2 (first sentence) and GPL § 2b)
> > AGAIN: If you like to understant/interpret a contract like the GPL,
>
> The GPL is a license, not a contract.
You should try to ask a lawyer in order to get some basic legal knowledge
before writing nonsense.
The GPL could be either taken as a "contract" or the "terms of business
conditions" (depending on the view of a judge). A license is not a separate
legal form.
This is at least true for most parts of the world...
> > you need to read it carefully word by word and are not allowed to
> > add claims that are not written in the GPL.
>
> Exactly.
Well as long as it stays your intention only but is not turned into
reality, it does not help....
So before answering again: read the GPL and try to understand it.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Wouter Verhelst
> Wouter Verhelst <wou...@debian.org> wrote:
>
> > > You should better _read_ the GPL and try to understand it.
> >
> > Good plan.
>
> Did you have some time to make your plan reality meanwhile?
I can quote major parts of it by heart since a few years, does that
help?
[...]
> > GPL§3 clearly says what you may do when you distribute binary versions
> > of the Program, and gives you three options:
>
> But this is unrelated to the problem Debian seems to construct.
> You should read the GPL more carefully.
Actually, no. The main problem which Debian has with you and your
relation to the GPL is related to GPL§3.
> > Additionally, it defines "source code" as follows:
> >
> > ===
> > The source code for a work means the preferred form of the work for
> > making modifications to it. For an executable work, complete source
> > code means all the source code for all modules it contains, plus any
> > associated interface definition files, plus the scrips used to
> > control compilation and installation of the executable.[...]
> > ===
>
> In case you did read the GPL carfully enough you should know that
> GPL §2 and GPL §3 speak about differnt things.
>
> GPL §3 speaks about "complete source", while GPL §2 speaks about "the work"
> which from what GPL §3 sais is _less_ than the "complete source".
They both speak about "the Program", though, which is what really
matters. The license applies to "the Program", which is defined in §0.
It does not apply to "the work" or anything remotely similar. That term
is only used to define rules that you needt to follow /when modifying
the Program/. These rules are outlined in §2.
IOW, if you are creating an original work (as you are) instead of
modifying an already existing work, then §2 /does not even apply to
you/.
> /*--------------------------------------------------------------------------*/
> 3. You may copy and distribute the Program (or a work based on it,
> under Section 2) in object code or executable form under the terms of
> Sections 1 and 2 above provided that you also do one of the following:
>
> a) Accompany it with the complete corresponding machine-readable
> source code, which must be distributed under the terms of Sections
> 1 and 2 above on a medium customarily used for software interchange; or,
> /*--------------------------------------------------------------------------*/
>
> does not mean more than: "make 'the work' available under GPL (in case
> 'the work' is a 'derived work' and make the rest for the 'complete source'
> available under any license you like".
You seem to have a very strange sense of English.
You may copy and distribute the Program (or a work based on it (...) )
(...) provided that you also do one of the following:
a) Accompany it with the complete machine-readable source code (...)
It says "the Program", not "the work". It says "the *complete*
machine-readable source code" (emphasis mine), not "the source code of
just the part of which you're providing binaries".
> > I fail to see how your claim holds, given the above, but I'm willing to
> > be educated.
>
> You ned to carefully read the GPL as long as you need in order to understand
> it by your own.
My point exactly.
> > > Note it is unclear whether the makefiles could be called "scripts"
> >
> > Unproven assertion.
>
> Unproven claim!
The point was: can you give me any sane description of "script" that
does not hold for Makefiles?
[...]
> > Surely automake, GNU make, bash, and so on, were written before most of
> > the projects that use them. However, that does not mean that the build
> > system is a totally different "work"; the particular version of
> > configure.ac, Makefile.am/Makefile.in/Makefile, and any .sh scripts that
> > are part of the source tarball are part of the build system, even if the
> > interpreters that are used to run them are not.
>
> This is completely irelevent, why did you write it?
Because they are also build systems that were written before projects
that use them. It is not completely irrelevant; it works exactly the
same way as your claim.
[...]
> GNU make is unmaintained since at least 7 years,
GNU make has seen at least 227 updates since 2000 alone, some of which
are *very* significant. How does that count as "unmaintained", other
than "They do not incorporate Joerg Schilling's patches"? Would you
incorporate any random patch for cdrecord which I would send your way,
/even/ if it is not an evil patch that tries to circumvent whatever you
try to do with cdrecord?
You know, I knew about your reputation, but was willing to forget all
about it, just for the remote chance that you might see the light for
once.
I was being silly:
> it has many bugs that make it extremely user-unfriendly when used
> together with "The Schily Makefilesystem"
"Doctor, I have a headache when I drink coffee with the spoon still in
the cup"
"Don't do that, then".
I've been using GNU make for over six years now. I've never come into
contact with a feature of which I thought "gee, this is terribly
non-userfriendly".
[...]
> smake is not part of cdrtools but another project I am working on:
>
> "The Schily Makefilesystem"
>
> is. This is definitely a project that is _separate_ from cdrtools but included
> as a sub-project.
>
> - This project ("The Schily Makefilesystem") contains > 300 kB of
> _project-independent_ makefiles/rules.
>
> - The "Makefile" that is e.g. part of the "mkisofs" project is
> only 2477 bytes in size. Only 1243 Bytes in this file are specific
> to mkisofs and not copied from a (project-independent) template.
>
> - The "Makefile" that is e.g. part of the "mkisofs" project comes
> with the _same_ license as "mkisofs" comes and _this_ file is of
> course part of the sub-project "mkisofs". This _project-dependent_
> file is much less than 1% of the project indepenent "The Schily
> Makefilesystem".
Right, so it would seem that in order to avoid GPL issues, you have
three options then:
* Distribute the "Schily Makefilesystem" under the GPL, so that there
are no conflicts.
* Distribute the "Schily Makefilesystem" under a different license, but
in a separate package. This means it's not part of the cdrtools
package, so does not /need/ to be GPL. If it's still a DFSG-free
license, then cdrtools wouldn't even have to be moved to contrib
(provided it's still under the GPL and not something non-free; I heard
rumours to the contrary, but haven't checked the license myself)
* Make sure the Makefile in the mkisofs package can somehow work without
the "Schily Makefilesystem". Don't know whether this is feasible.
> > > *) It does not even require to publish the whole work under the GPL
> > > in case that you add code to a GPL project! In this case the added
> > > code may under _any_ license (even Closed source).
> >
> > Could you quote the part of the GPL on which you base this assertion? It
> > is not clear to me.
>
> I did this already many times: GPL §2 (first sentence) and GPL § 2b)
2b:
"You must cause any work that you distribute or publish, that in whole
or in part contains or is derived from the Program or any part thereof,
to be licensed as a whole at no charge to all third parties under the
terms of this License."
What part of "to be licensed as a whole (...) under the terms of this
License" do you not understand?
> > > AGAIN: If you like to understant/interpret a contract like the GPL,
> >
> > The GPL is a license, not a contract.
>
> You should try to ask a lawyer in order to get some basic legal knowledge
> before writing nonsense.
This is not nonsense. In Belgium, the very definition of a "contract"
involves two parties putting their signature on a piece of paper.
This is the same in many jurisdictions.
(Even if the law has modernised and now recognizes digital signatures as
legally binding, you /still/ need to sign in order to make it a legal
_contract_).
> The GPL could be either taken as a "contract" or the "terms of business
> conditions" (depending on the view of a judge). A license is not a separate
> legal form.
"Terms" and/or "conditions" would work. "Contract" would not.
> So before answering again: read the GPL and try to understand it.
I did. Now it's your turn.
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Joerg Schilling
> I can quote major parts of it by heart since a few years, does that
> help?
If you like to discuss the GPL with other people, it is irrelevent whether
you know it "by heart" in case you did not understand it yet...
> [...]
> > > GPL§3 clearly says what you may do when you distribute binary versions
> > > of the Program, and gives you three options:
> >
> > But this is unrelated to the problem Debian seems to construct.
> > You should read the GPL more carefully.
>
> Actually, no. The main problem which Debian has with you and your
> relation to the GPL is related to GPL§3.
If you believe that there is a problem with GPL §3, why don't you explain this
"problem"? Instead of writing such acusations, _you_ should try to find
a non-prejudiced relation to software licenses...
What I am subjected to by Debian is a real bad calumniation campaign :-(
People repeatedly claim that there are problems with my but are unable to
explain where the problems should be. If the Debian Pproject does not like
to lose credibility, people from Debian should finally explain their problems
or _correcty_ admit that there is no problem.
As you still seem not to understand the GPL, let me give you a final
explanation of the relevent statements from GPL §2 and GPL §3:
- The GPL §2 talks about a "work", but does not give a definition
for the term "work". So I am free to decide (within reasonable
limits) where the work ends.
The GPL §2 requires the "work" to be put under GPL in case that
the work has been created by including other peoples GPLd work
in a new or bigger project.
The GPL §2 does _not_ mention a restriction in case that a GPLd
work is based on a NON-GPL work or includes parts from a NON-GPL
work. As the GPL gives a general permission to use the GPLd code,
this is the point where the GPL opens a way to combine CDDL code
with GPL code. This is the way I am going with mkisofs.
- The GPL §3 uses a definition about the "complete source" which
differs from the term "work" which is used in GPL §2.
If you publish binaries from a project, then the GPL §3 requires
that the "complete source" needs to be published but does not
name a license for the parts of the "complete source"
that are not covered by "the work" (as mentioned in GPL §2).
The file "COPYING" in the root directory of the cdrtools project
explains which _sub_projects_ are published with the cdrtools
project and lists the location where the various sub-projects
could be found in the directory structure.
The "schily makefile system" is definitely not part of the
mkisofs project. The "schily makefile system" is project independent
and it is _also_ published separately from any other project.
The "schily makefile system" is more than 100x as big as the
project specific makefile mkisofs/Makefile and the project specific
Makefiles are published under the same license as the related
project.
As the GPL allows "mere agregation", this is what I do
with the "schily makefile system". The "schily makefile system"
is under CDDL and the file mkisofs/Makefile is under GPL.
If people from the Debian project believe that the GPL is to interpreted
otherwise, then the Debian project would need to immediately mark all
GPLd projects "non-free" as the GPL then seems to violate DSFG §9.
> > In case you did read the GPL carfully enough you should know that
> > GPL §2 and GPL §3 speak about differnt things.
> >
> > GPL §3 speaks about "complete source", while GPL §2 speaks about "the work"
> > which from what GPL §3 sais is _less_ than the "complete source".
>
> They both speak about "the Program", though, which is what really
> matters. The license applies to "the Program", which is defined in §0.
> It does not apply to "the work" or anything remotely similar. That term
> is only used to define rules that you needt to follow /when modifying
> the Program/. These rules are outlined in §2.
If you did not understand what a "program" is in terms of the GPL, you should
read GPL §0. In addition, I encourage you to read GPL §2 and GPL §3 again until
you manage to understand in which relation the term "program" is used there.
It is obvious that the term "program" applies to parts of the source that
end up in iditificable parts of the binary. The GPL §2 talks about the
limitations in case you put other peoples GPLd source or parts from it
into your peoject.
> IOW, if you are creating an original work (as you are) instead of
> modifying an already existing work, then §2 /does not even apply to
> you/.
See above, you seem to start understanding GPL §2.
... but it would take some time for you to understand enough of the GPL
in order to be able to discuss things related to the GPL with me.
> > does not mean more than: "make 'the work' available under GPL (in case
> > 'the work' is a 'derived work' and make the rest for the 'complete source'
> > available under any license you like".
>
> You seem to have a very strange sense of English.
Sorry, it's _you_ who sem to have a very strange sense of English.
What I am doing is to carefully read the GPL word by word, sentence by sentence.
What you to do is really strange as you seem to create _new_ (own) definitions
from words scattered to the whole text of the GPL.
> You may copy and distribute the Program (or a work based on it (...) )
> (...) provided that you also do one of the following:
>
> a) Accompany it with the complete machine-readable source code (...)
>
> It says "the Program", not "the work". It says "the *complete*
> machine-readable source code" (emphasis mine), not "the source code of
> just the part of which you're providing binaries".
Are you trying to do deliberate demagogy?
THIS is a quotation from GPL §3, not GPL §2!
GPL §3 does not require that "the complete machine-readable source code" is
to be put under GPL, it only requires that is has to be published.
> > You ned to carefully read the GPL as long as you need in order to understand
> > it by your own.
>
> My point exactly.
So why don't you try to understand the GPL?
> > Unproven claim!
>
> The point was: can you give me any sane description of "script" that
> does not hold for Makefiles?
A "scipt" is a _series_ of _instructions_ in _algorithmic_ form.
If you look at a script, it is "easy" to understand what it will do
if you run it.
A "Makfile" is a program written in the language "make" which is a
non-algorithmic (but rather rule based) language.
If you look at a "makfile" it is usually hard to predict what "make"
will do after reading the rules from "Makefile". Even I as an author of
an advanced "make" program am regularily fooled by the behavior of make
because I cannot predict the effects of all rules in a specific makefile.
But this definition is irrelevent as the "Schily makefilesystem" is a separate
and program independent project that cannot be treaten as integral part of any
project that uses the "Schily makefilesystem" for compilation.
> [...]
> > > Surely automake, GNU make, bash, and so on, were written before most of
> > > the projects that use them. However, that does not mean that the build
> > > system is a totally different "work"; the particular version of
> > > configure.ac, Makefile.am/Makefile.in/Makefile, and any .sh scripts that
> > > are part of the source tarball are part of the build system, even if the
> > > interpreters that are used to run them are not.
> >
> > This is completely irelevent, why did you write it?
>
> Because they are also build systems that were written before projects
> that use them. It is not completely irrelevant; it works exactly the
> same way as your claim.
OK, but why do you like to treat this build system differently from the
"Schily makefilesystem"?
> [...]
> > GNU make is unmaintained since at least 7 years,
>
> GNU make has seen at least 227 updates since 2000 alone, some of which
> are *very* significant. How does that count as "unmaintained", other
> than "They do not incorporate Joerg Schilling's patches"? Would you
> incorporate any random patch for cdrecord which I would send your way,
> /even/ if it is not an evil patch that tries to circumvent whatever you
> try to do with cdrecord?
If the "Maintainer" of GNU make admits that there is a seriuos problem
in GNU make regarding to treating "include" files and tells me that it will
take some time to rewrite GNU make in order to fix this serious bug...
If you take into account that I did point him to the correct implementation
used in smake and allowed him to use this algorithm...
If you check 7 years !!!! later and you see that nothing happened, what
would you call GNU make?
If you send abug report for a problem in GNU make that causes GNU make
to dump core in case that the environment has a specific content and
it is less than 5 lines of code to change to fix this problem....
If you check 18 months later (after a "new" source has been oublished)
and this GNU make bug is still present, how would you call the state of
GNU make?
> You know, I knew about your reputation, but was willing to forget all
> about it, just for the remote chance that you might see the light for
> once.
>
> I was being silly:
If you know about my reputation, why do you behave so silly?
I am the author of a lot of OSS and you seem to be rather unknown
in the OSS community.
> I've been using GNU make for over six years now. I've never come into
> contact with a feature of which I thought "gee, this is terribly
> non-userfriendly".
This is childish :-(
> Right, so it would seem that in order to avoid GPL issues, you have
> three options then:
>
> * Distribute the "Schily Makefilesystem" under the GPL, so that there
> are no conflicts.
> * Distribute the "Schily Makefilesystem" under a different license, but
> in a separate package. This means it's not part of the cdrtools
> package, so does not /need/ to be GPL. If it's still a DFSG-free
> license, then cdrtools wouldn't even have to be moved to contrib
> (provided it's still under the GPL and not something non-free; I heard
> rumours to the contrary, but haven't checked the license myself)
> * Make sure the Makefile in the mkisofs package can somehow work without
> the "Schily Makefilesystem". Don't know whether this is feasible.
Are you really so inflexible to not try to understand the GPL first,
but parrot simple boilerplates that do not apply to our case?
I do not like to comment the rest of your mail as it is wrong and not worth
any further discussion as long as you fail to understand the basic rules of the
GPL.
I encourage you to read and understand the GPL and if you still find problems
with cdrtools, send an explanation based on _real_ quotations (that are not
used out of context) from the GPL.
As long as you quote the GPL out of context or as long as you try to create
statements that cannot be found in the GPL, let us asume that people from Debian
are on an unsubstancial calumniation campaign against my software.
For this reason, I ask you to mark the related entries in the BTS
as "resolved and closed"
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Wouter Verhelst
> Wouter Verhelst <wou...@grep.be> wrote:
>
> > I can quote major parts of it by heart since a few years, does that
> > help?
>
> If you like to discuss the GPL with other people, it is irrelevent whether
> you know it "by heart" in case you did not understand it yet...
*sigh*
If everybody else interprets it significantly different from you, isn't
it more likely that *you* do not understand it?
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Michael Banck
On Mon, Aug 07, 2006 at 10:56:24AM +0200, Joerg Schilling wrote:
> I am still in hope that there are people at Debian who are able to
> understand license issues without bending things the way they like but
> by correctly following the words in the license text.
Joerg, this discussion is off-topic for the debian-devel mailing list,
which is concerned with development issues, not licensing trivia.
Please (preferably) stop this discussion, or take it to debian-curiosa
or debian-legal.
Thanks,
Michael
--
"No other topic of discussion in our circles has matched even a fraction
of the gravity and profundity of this observation. I appreciate it
greatly."
-- Roland McGrath
Joerg Schilling
> On Sun, Aug 06, 2006 at 01:04:41PM +0200, Joerg Schilling wrote:
> > If you like to discuss the GPL with other people, it is irrelevent whether
> > you know it "by heart" in case you did not understand it yet...
> If everybody else interprets it significantly different from you, isn't
> it more likely that *you* do not understand it?
As you seem to be unable to prove _your_ claims by _correctly_ quoting
the GPL, it is obvious that _you_ did not understand the GPL or that
you prefer to bend the GPL to your wishes.
I am still in hope that there are people at Debian who are able to
understand license issues without bending things the way they like but
by correctly following the words in the license text.
My software is definitely free and has no license problems.
If people from Debian continue to publish untenable assertions on my software,
it is obvious that those people from Debian are only interested in a
calumniation campaign aganst me.
Note that this makes Debian incredible. If it is impossible to find
a reasonable person at Debian, I will need to inform other people about the
problems in the Debian project. The way _you_ and other people from Debian
currently act, makes Debian a definitely non-free project :-(
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Josselin Mouette
> My software is definitely free and has no license problems.
You may think so, but the Debian project doesn't. For example, a recent
GR stated that invariant sections aren't acceptable for the specific
GFDL case, and there is no reason why they would be acceptable for
cdrecord. Furthermore, there are issues with the CDDL and currently no
CDDL-licensed project has been accepted.
All of this, without even taking into account your brain-dead licensing
mix between CDDL and GPL - which are intentionally incompatible
licenses, according to Sun guys.
> If people from Debian continue to publish untenable assertions on my software,
> it is obvious that those people from Debian are only interested in a
> calumniation campaign aganst me.
People from Debian are interested in building a free distribution, not
in trolling with software authors crying out loud because they aren't
able to understand how licenses work. We decide what's acceptable for
our project, and you don't have a single word to say about that.
> Note that this makes Debian incredible. If it is impossible to find
> a reasonable person at Debian, I will need to inform other people about the
> problems in the Debian project. The way _you_ and other people from Debian
> currently act, makes Debian a definitely non-free project :-(
Indeed, you are not free to add whatever piece of crap to the Debian
archive regardless of the license. Call it a non-free project if you
want, but this would only look like a calumniation campaign against us.
Joerg Schilling
> Le lundi 07 août 2006 à 10:56 +0200, Joerg Schilling a écrit :
> > My software is definitely free and has no license problems.
>
> You may think so, but the Debian project doesn't. For example, a recent
As long as people from Debian are on calumiation campaigns aginst
OSS authors, Debian needs to be called non-free.
Debian must either be able to clean itself from people who use Debian
for such campaigns against OSS authors, or Debian needs to be called
a higly suspect and non-free project.
> GR stated that invariant sections aren't acceptable for the specific
> GFDL case, and there is no reason why they would be acceptable for
If Linux Distributions would not distribute bastardized versions of cdrecord,
there was no need to add the statements you might be talking about.
But note: you are again spreading lies!
You should better inform yourself on the Debian project and about the
GPL. The phrases that are inside cdrecord, have been clearly accepted by Debian
more than 4 years ago and they have been 100% GPL compatible as long as
cdrecord was published under GPL. Note that there are no invariant sections
in my sofware. As long as you do not create problems with my reputation (which
meand that you may need to call cdrecord e.g. "kindergarten", you may apply
any changes you like....).
> cdrecord. Furthermore, there are issues with the CDDL and currently no
> CDDL-licensed project has been accepted.
There are definitely NO issues with the CDDL. The CDDL gives at least
as much freedom as the GPL does and the CDDL is a first class OSS license.
It has been accepted by the OSI and this is sufficient for anybody.
> All of this, without even taking into account your brain-dead licensing
> mix between CDDL and GPL - which are intentionally incompatible
> licenses, according to Sun guys.
The more such lies you write, the more I get the impression that you are
a really bad troll.
Sun did definitely NOT create the CDDL to be incompatible to the GPL.
What you are doing here is FUD of the worst kind!
I am still in hope that this is a problem with people like you only
and not a general problem with Debian. Note that Debian has been a
respectable project in the past. If Debian does not dissociate from people
like you, Debian will soon become completely incredible.
> > If people from Debian continue to publish untenable assertions on my software,
> > it is obvious that those people from Debian are only interested in a
> > calumniation campaign aganst me.
>
> People from Debian are interested in building a free distribution, not
> in trolling with software authors crying out loud because they aren't
> able to understand how licenses work. We decide what's acceptable for
> our project, and you don't have a single word to say about that.
So why do they allow you to troll in the name of Debian?
Joerg Schilling
> Hi,
>
> On Mon, Aug 07, 2006 at 10:56:24AM +0200, Joerg Schilling wrote:
> > I am still in hope that there are people at Debian who are able to
> > understand license issues without bending things the way they like but
> > by correctly following the words in the license text.
>
> Joerg, this discussion is off-topic for the debian-devel mailing list,
> which is concerned with development issues, not licensing trivia.
People from Debian did start this discussion by starting a calumniation
capaign against me and the CDDL.
As long as this list is abused to spread lies on my software, I would
need to have right to correct the related incorrect claims. If you
don't like this discussion to be continued here, make sure that the people
who are spreading lies on me and my software are not allowed to do this
on this list anymore.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Norbert Preining
> Debian must either be able to clean itself from people who use Debian
> for such campaigns against OSS authors, or Debian needs to be called
> a higly suspect and non-free project.
>
You troll around on debian-devel, you troll around on lkml, you seem to
be more intelligent, wise, knowledgable, fluent in licenses, all-mighty
than *ALL* *OTHER*:
- linux kernel developers (quite a lot)
- debian developers (quite a lot)
Do you really believe this yourself?!?! If yes, go for a therapist, please, I
would even pay the first hour!
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <preining AT logic DOT at> Università di Siena
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
PIMPERNE (n.)
One of those rubber nodules found on the underneath side of a lavatory
seat.
--- Douglas Adams, The Meaning of Liff
Roger Leigh
> On Mon, 07 Aug 2006, Joerg Schilling wrote:
>> Debian must either be able to clean itself from people who use Debian
>> for such campaigns against OSS authors, or Debian needs to be called
>> a higly suspect and non-free project.
>
> You troll around on debian-devel, you troll around on lkml, you seem to
> be more intelligent, wise, knowledgable, fluent in licenses, all-mighty
> than *ALL* *OTHER*:
> - linux kernel developers (quite a lot)
> - debian developers (quite a lot)
>
> Do you really believe this yourself?!?! If yes, go for a therapist,
> please, I would even pay the first hour!
Please keep non-constructive messages and flaming off debian-devel
(and the same applies to you, Joerg Schilling). Take this off
debian-devel to private mail or to a more appropriate list.
Thanks,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please sign and encrypt your mail.
Joerg Schilling
> You troll around on debian-devel, you troll around on lkml, you seem to
> be more intelligent, wise, knowledgable, fluent in licenses, all-mighty
> than *ALL* *OTHER*:
> - linux kernel developers (quite a lot)
> - debian developers (quite a lot)
>
> Do you really believe this yourself?!?! If yes, go for a therapist, please, I
> would even pay the first hour!
You are a really bad troll!
Any sane person who did follow this mail thread knows that the trolls
from Debian did only send junk and obvious lies while I tried to
give technical based explanations.
I do not need to comment your insane scribbling, only people who are as insane
as you are will believe you.
And it is interesing to see that the same applies to the LKML trolls as
does apply to the Debian trolls:
When they run out of arguments, they either stop replying or start
with personal infringement. You are obviously from the second category.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Gunnar Wolf
> As long as people from Debian are on calumiation campaigns aginst
> OSS authors, Debian needs to be called non-free.
It's not like publishing software under an allegedly free license
makes you a saint, you know?
> > GR stated that invariant sections aren't acceptable for the specific
> > GFDL case, and there is no reason why they would be acceptable for
>
> If Linux Distributions would not distribute bastardized versions of cdrecord,
> there was no need to add the statements you might be talking about.
Any free license allows for forking, allows for us modifying and
redistributing your work. If we consider some parts of your code
unfit, and you say you write Free Software, you should not have a
problem accepting us to distribute those changes to your
sources. Why are you so bitter about it to call "bastardizing" what
should be called "distributing modified versions of"?
> You should better inform yourself on the Debian project and about the
> GPL. The phrases that are inside cdrecord, have been clearly accepted by Debian
> more than 4 years ago and they have been 100% GPL compatible as long as
> cdrecord was published under GPL. Note that there are no invariant sections
> in my sofware. As long as you do not create problems with my reputation (which
> meand that you may need to call cdrecord e.g. "kindergarten", you may apply
> any changes you like....).
Thing is that different programmers will look differently at the same
problem - And if most people looking at your approach feel it should
not be done that way, what's your big problem with them modifying your
logic? They are not "creating problems with your reputation". They
label the software as originally written by you, but maintained for
Debian by another Joerg, an Eduard and a Steve.
> There are definitely NO issues with the CDDL. The CDDL gives at least
> as much freedom as the GPL does and the CDDL is a first class OSS license.
> It has been accepted by the OSI and this is sufficient for anybody.
...By OSI. That's an important part, but not all of, the Free Software
camp.
Greetings,
--
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Josselin Mouette
> As long as people from Debian are on calumiation campaigns aginst
> OSS authors, Debian needs to be called non-free.
Why do you have to be so self-centered? This is not a calumniation
campaign, this is not about YOU. We just think your software isn't fit
to be distributed by us. If you really want that badly that we
distribute your software, you should just comply with our requirements,
that's all.
> Debian must either be able to clean itself from people who use Debian
> for such campaigns against OSS authors, or Debian needs to be called
> a higly suspect and non-free project.
On what grounds? Because you don't like us?
> > GR stated that invariant sections aren't acceptable for the specific
> > GFDL case, and there is no reason why they would be acceptable for
>
> If Linux Distributions would not distribute bastardized versions of cdrecord,
> there was no need to add the statements you might be talking about.
This is free software or this is not free software. If you don't like
when people distribute modified versions of your software, you should
not try share them with the free software community.
For example, I don't like when people distribute buggy modified versions
of my packages, like this happened with Knoppix or Ubuntu. However I
won't stop making my packages free for such a frivolous reason.
> But note: you are again spreading lies!
>
> You should better inform yourself on the Debian project and about the
> GPL.
I am obviously better informed than you about the Debian project and
about the GPL. You don't know the former at all and you haven't read the
latter enough to understand it.
> The phrases that are inside cdrecord, have been clearly accepted by Debian
> more than 4 years ago
But the result of the GFDL GR implies that we should reconsider this
acceptance under the light of what the project currently thinks of
invariant sections.
> and they have been 100% GPL compatible as long as
> cdrecord was published under GPL.
No. The GPL explicitly forbids to add any additional restriction.
> Note that there are no invariant sections
> in my sofware. As long as you do not create problems with my reputation (which
> meand that you may need to call cdrecord e.g. "kindergarten", you may apply
> any changes you like....).
That's not "any changes we like", sorry.
> > cdrecord. Furthermore, there are issues with the CDDL and currently no
> > CDDL-licensed project has been accepted.
>
> There are definitely NO issues with the CDDL. The CDDL gives at least
> as much freedom as the GPL does and the CDDL is a first class OSS license.
> It has been accepted by the OSI and this is sufficient for anybody.
Debian is not the OSI. Debian decides what is acceptable for Debian, not
the OSI. As the OSI has repeatedly accepted blatantly non-free licenses
in the past, we have no reason to trust them on this matter.
> > All of this, without even taking into account your brain-dead licensing
> > mix between CDDL and GPL - which are intentionally incompatible
> > licenses, according to Sun guys.
>
> The more such lies you write, the more I get the impression that you are
> a really bad troll.
>
> Sun did definitely NOT create the CDDL to be incompatible to the GPL.
> What you are doing here is FUD of the worst kind!
No, this is from first hand, real-life discussion with Sun people at
DebConf. A part of the staff wanted to use the GPL, but the developers,
who were old times BSD fans, didn't want a copyleft and they didn't want
a GPL-compatible license. The CDDL was the compromise they found, and it
was *intentionally* written to be incompatible with the GPL.
> I am still in hope that this is a problem with people like you only
> and not a general problem with Debian. Note that Debian has been a
> respectable project in the past. If Debian does not dissociate from people
> like you, Debian will soon become completely incredible.
There is an expulsion procedure documented there:
http://lists.debian.org/debian-devel-announce/2005/08/msg00005.html
If you can convince enough developers to start an expulsion procedure
against me, this should be fine.
> So why do they allow you to troll in the name of Debian?
I am not doing anything in the name of Debian. I am just trying to be
patient and taking some of my precious time to explain you how things
work, but given your reaction, it just looks like a waste of time.
Christian Perrier
> for such campaigns against OSS authors, or Debian needs to be called
> a higly suspect and non-free project.
As an outsider of the Debian project, you probably have little
knowledge of all the people you're debating with currently. What's
really funny is that several of these people are indeed people who
sometimes have radically different opinions about licensing, freeness
and all these things.
You see the Debian project as a monolithic project with only one
voice, which is everything but true.
But, here, what is even more funny is that most of these very often
incompatible people seem to agree that the licensing of your software
makes it unacceptable for the project. Even those people that are not
known to be "freeness zealots" think it (count me among those
people...several here will confirm this to you).
This would make anyone with a reasonable sense of debate at least
question his/her reasoning. Which you do not seem ready to do,
standing in your ivory tower (at least this is my understanding of
this thread, please forgive me if that's untrue and if your really
ready to discuss the parts that Debian considers questionable in you
licensing).
That's really infortunate, of course.....and the only option I see
here for Debian is to use some forks of your project that would use
some more reasonable licensing.....unless you seem ready to reconsider
it. If you're not, there's probably not much point wasting our
respective time.
Joerg Schilling
> > > GR stated that invariant sections aren't acceptable for the specific
> > > GFDL case, and there is no reason why they would be acceptable for
> >
> > If Linux Distributions would not distribute bastardized versions of cdrecord,
> > there was no need to add the statements you might be talking about.
>
> Any free license allows for forking, allows for us modifying and
> redistributing your work. If we consider some parts of your code
> unfit, and you say you write Free Software, you should not have a
> problem accepting us to distribute those changes to your
> sources. Why are you so bitter about it to call "bastardizing" what
> should be called "distributing modified versions of"?
If you don't know that you just need to use a clearly _different_ _name_
for such a fork, I can't help you. Read the preamble from the GPL
to understand your fault.
> > There are definitely NO issues with the CDDL. The CDDL gives at least
> > as much freedom as the GPL does and the CDDL is a first class OSS license.
> > It has been accepted by the OSI and this is sufficient for anybody.
>
> ...By OSI. That's an important part, but not all of, the Free Software
> camp.
????
In case you don't know, the CDDL is one of 9 preferred:
http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:11636:200607:nknhhdligldemhkfbhpd
The CDDL has no problem with any of the DFSG requirements, so in case some
people at Debian do not like to accept the CDDL, this needs to be called pure
evilness.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling
> Le lundi 07 août 2006 à 10:56 +0200, Joerg Schilling a écrit :
> > My software is definitely free and has no license problems.
>
> You may think so, but the Debian project doesn't. For example, a recent
> GR stated that invariant sections aren't acceptable for the specific
> GFDL case, and there is no reason why they would be acceptable for
> cdrecord. Furthermore, there are issues with the CDDL and currently no
> CDDL-licensed project has been accepted.
You are again trying to intentionally tell us untrue things about my software!
The Debian project accepted the clauses in cdrecord ~ 4 years ago.
The Debian people at that time _did_ know that the cdrecord source does not
contain invariant sections. You need of course chose a clearly different name
(e.g. kindergarten) instead of cdrecord in case you like to apply specific
changes....
And note: the CDDL is one of 9 preferred licenses:
It has no problem with any of the DFSG requirements.
If you claim different things, you are obviously speading FUD and not
a serious discussion partner - sorry.
> All of this, without even taking into account your brain-dead licensing
> mix between CDDL and GPL - which are intentionally incompatible
> licenses, according to Sun guys.
If you are so braindead not to understand that this license combination
is perfectly OK, I cannot help you. It seems that I did waste already too much
time with you. A discussion only makes sense in case that the "other side"
is able/willing to understand simple explanataions...
> People from Debian are interested in building a free distribution, not
> in trolling with software authors crying out loud because they aren't
> able to understand how licenses work. We decide what's acceptable for
> our project, and you don't have a single word to say about that.
If this was true, why don't you talk with me with in a serious way but troll
instead?
> Indeed, you are not free to add whatever piece of crap to the Debian
> archive regardless of the license. Call it a non-free project if you
> want, but this would only look like a calumniation campaign against us.
If you continue to spread this kind of personal insults, _you_ are a person
that I don't like to talk with anymore in future.
I am sorry, but I cannot waste my time with trolls like you.
I am however still in hope that the Debian project is not full of trolls
but that there are reasonable people in Debian....
Wouter Verhelst
> > Indeed, you are not free to add whatever piece of crap to the Debian
> > archive regardless of the license. Call it a non-free project if you
> > want, but this would only look like a calumniation campaign against us.
>
> If you continue to spread this kind of personal insults,
Err, ENOPARSE.
How is the above paragraph a "personal insult"?
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Josselin Mouette
> You are again trying to intentionally tell us untrue things about my software!
>
> The Debian project accepted the clauses in cdrecord ~ 4 years ago.
That doesn't mean the project still considers them acceptable *NOW*.
> And note: the CDDL is one of 9 preferred licenses:
>
> http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:11636:200607:nknhhdligldemhkfbhpd
One of the preferred licenses *by the OSI*. Debian has nothing to do
with the OSI and doesn't not rely on the OSI to be told what is free or
not. Can't you even understand something that simple?
> It has no problem with any of the DFSG requirements.
Many people have expressed complaints about the choice-of-venue clause
and think it is not acceptable for Debian. I am not one of them and I
believe the CDDL to be free, but I would surely not claim there is
consensus around that in the project. I repeat: currently no CDDL
project has been accepted yet.
> If you claim different things, you are obviously speading FUD and not
> a serious discussion partner - sorry.
Why is anyone disagreeing with you necessarily "spreading FUD", "lying",
"trying to hurt your reputation", or anything like this? Bear with it:
most people disagree with you. I do not know a SINGLE Debian developer
who believes your license combination to be distributable. Does that
make only hundreds of trolls who are just trying to spread FUD against
you?
Stop the paranoia. People disagree with you, and you have to accept
that. They are not disagreeing with you just to hurt you *personally*.
This is why you should listen to these criticisms instead of throwing
them away by calling them FUD. No one is going to listen to you if you
are still unable to listen to anyone.
> If you are so braindead not to understand that this license combination
> is perfectly OK, I cannot help you. It seems that I did waste already too much
> time with you. A discussion only makes sense in case that the "other side"
> is able/willing to understand simple explanataions...
Your "simple explanations" are wrong. I'm not going to re-explain what
Wouter explained better than I would. If you cannot understand that the
CDDL is incompatible with the GPL, you should stop talking about
licenses and only keep coding, a task for which you seem to have more
talent.
> > People from Debian are interested in building a free distribution, not
> > in trolling with software authors crying out loud because they aren't
> > able to understand how licenses work. We decide what's acceptable for
> > our project, and you don't have a single word to say about that.
>
> If this was true, why don't you talk with me with in a serious way but troll
> instead?
I have yet to be shown how it is possible to discuss with you in a
serious way.
> > Indeed, you are not free to add whatever piece of crap to the Debian
> > archive regardless of the license. Call it a non-free project if you
> > want, but this would only look like a calumniation campaign against us.
>
> If you continue to spread this kind of personal insults, _you_ are a person
> that I don't like to talk with anymore in future.
Where is there a personal insult in this paragraph?
> I am sorry, but I cannot waste my time with trolls like you.
You are the one bringing this discussion on the Debian development
mailing list. You are wasting the time of people reading this list.
> I am however still in hope that the Debian project is not full of trolls
> but that there are reasonable people in Debian....
If "reasonable" means "who agree with you", I have yet to see them.
Goswin von Brederlow
> Josselin Mouette <jo...@debian.org> wrote:
>> GR stated that invariant sections aren't acceptable for the specific
>> GFDL case, and there is no reason why they would be acceptable for
>
> If Linux Distributions would not distribute bastardized versions of cdrecord,
> there was no need to add the statements you might be talking about.
Sorry, but you say your software is free. That means Debian (or anyone
else) is free to bastardize cdrecord as much as they want. That is
called freedom.
You can require proper notice or even a name change of the software
when such "bastardization" is done but when you start forbiding such
changes then your software is no longer free.
Specifically in cdrecord you write:
* Begin restricted code for quality assurance.
*
* Warning: you are not allowed to modify or to remove the
* Copyright and version printing code below!
* See also GPL <A7> 2 subclause c)
GPL 2c:
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
'IF THE MODIFIED PROGRAM NORMALLY READS COMMANDS INTERACTIVELY WHEN RUN...'
Where does the original or any modified cdrecord run interactively?
This section just does not apply to cdrecrod. In accordance to that I
can just remove your copyright printing in cdrecord since it is not
interactive.
* If you modify cdrecord you need to include additional version
* printing code that:
*...
Too bad the printing code itself can be removed completly anyway
sparing the user the anoying text. You demand that I write additional
code here, that might be totaly unsuitable for my use, severly limits
my freedom to use the source. That is not covered by the GPL, not in
2c as you claim at all.
So even though your intentions are fine your wording is not.
MfG
Goswin
Goswin von Brederlow
> Gunnar Wolf <gw...@gwolf.org> wrote:
>
>> > > GR stated that invariant sections aren't acceptable for the specific
>> > > GFDL case, and there is no reason why they would be acceptable for
>> >
>> > If Linux Distributions would not distribute bastardized versions of cdrecord,
>> > there was no need to add the statements you might be talking about.
>>
>> Any free license allows for forking, allows for us modifying and
>> redistributing your work. If we consider some parts of your code
>> unfit, and you say you write Free Software, you should not have a
>> problem accepting us to distribute those changes to your
>> sources. Why are you so bitter about it to call "bastardizing" what
>> should be called "distributing modified versions of"?
>
> If you don't know that you just need to use a clearly _different_ _name_
> for such a fork, I can't help you. Read the preamble from the GPL
> to understand your fault.
So all we need to do to apeace you is to call is "debianrecord"?
If that is all that is needed for you not to complain that we include
unsupported dvd support and the like then that can easily be aranged.
But then please just say so. The GPL alone does not require such a
rename, only that "the modified files to carry prominent notices
stating that you changed the files and the date of any change".
You should just add a requirement for renaming the software instead of
your invariant section and extra printing code requirement.
...
> The CDDL has no problem with any of the DFSG requirements, so in case some
> people at Debian do not like to accept the CDDL, this needs to be called pure
> evilness.
You may call that evil but everybody (including Debian) has the right
to their own opinion.
> Jörg
MfG
Goswin
Michael Banck
On Wed, Aug 09, 2006 at 05:39:12PM +0200, Goswin von Brederlow wrote:
> Joerg Schilling <schi...@fokus.fraunhofer.de> writes:
> > Josselin Mouette <jo...@debian.org> wrote:
> >> GR stated that invariant sections aren't acceptable for the specific
> >> GFDL case, and there is no reason why they would be acceptable for
> >
> > If Linux Distributions would not distribute bastardized versions of cdrecord,
> > there was no need to add the statements you might be talking about.
>
> Sorry, but you say your software is free. That means Debian (or anyone
> else) is free to bastardize cdrecord as much as they want. That is
> called freedom.
This discussion has nothing to do with debian development, kindly stop
or continue on another list.
thanks,
Michael
Joerg Schilling
> On Wed, Aug 09, 2006 at 03:44:57PM +0200, Joerg Schilling wrote:
> > > Indeed, you are not free to add whatever piece of crap to the Debian
> > > archive regardless of the license. Call it a non-free project if you
> > > want, but this would only look like a calumniation campaign against us.
> >
> > If you continue to spread this kind of personal insults,
>
> Err, ENOPARSE.
>
> How is the above paragraph a "personal insult"?
We are talking about my software and you are talking about a "piece of
crap", I am sorry but this is insulting.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling
> Le mercredi 09 août 2006 à 15:44 +0200, Joerg Schilling a écrit :
> > You are again trying to intentionally tell us untrue things about my software!
> >
> > The Debian project accepted the clauses in cdrecord ~ 4 years ago.
>
> That doesn't mean the project still considers them acceptable *NOW*.
So you like to tell me that Debian is not trustworthy?
> > And note: the CDDL is one of 9 preferred licenses:
> >
> > http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:11636:200607:nknhhdligldemhkfbhpd
>
> One of the preferred licenses *by the OSI*. Debian has nothing to do
> with the OSI and doesn't not rely on the OSI to be told what is free or
> not. Can't you even understand something that simple?
I understand things but if Debian people have problems to understand that
the OSI is the only independend institution that deals with OSS Licenses, you
are obviously a bit out of order.
Note that the CDDL has been chosen because it is a first class license as it
allows to combine CDDL code with other code and that the GPL only is in this
list because the GPL is widely used but not because of the quality of the
license.
BTW: The GPL is definitely non-free if someone makes use of GPL § 8.
> > It has no problem with any of the DFSG requirements.
>
> Many people have expressed complaints about the choice-of-venue clause
> and think it is not acceptable for Debian. I am not one of them and I
> believe the CDDL to be free, but I would surely not claim there is
> consensus around that in the project. I repeat: currently no CDDL
> project has been accepted yet.
Well then help to explain these other people that only a malicious distributor
or licensee needs to be in fear of this clause and that the clause protects the
Author for malicious licensees. If the Authors will not be protected,
we will end up with no OSS in the future...
> > If you claim different things, you are obviously speading FUD and not
> > a serious discussion partner - sorry.
>
> Why is anyone disagreeing with you necessarily "spreading FUD", "lying",
> "trying to hurt your reputation", or anything like this? Bear with it:
> most people disagree with you. I do not know a SINGLE Debian developer
> who believes your license combination to be distributable. Does that
> make only hundreds of trolls who are just trying to spread FUD against
> you?
Well this is strange. I did not "invent" this idea by myself and I did ask
many people about their opinion. What I see is that only a few people
from Debian have a different opinion and they are even unable to prove their
claims by correctly quoting the parts pf the GPL that they believe prevents what
I am doing.....
> Stop the paranoia. People disagree with you, and you have to accept
> that. They are not disagreeing with you just to hurt you *personally*.
> This is why you should listen to these criticisms instead of throwing
> them away by calling them FUD. No one is going to listen to you if you
> are still unable to listen to anyone.
Sorrry, the people from Debian need to stop _their_ paranoia as they are a
minority with a strange opinion.
I listen to people but if I see that they spread FUD instead of offering
useful and traceable information I believe at some point that is does not
make sense to continue a "discussion".
The Debian people should just read their DFSG rules and try to understand
them.... DFSG §9 claims that a license is only free if it does not conaminate
other software on the same medium. The "medium" in case of cdrtools is the
"tarball". The cdrtools distribution is based on two cases to allow a
combination of different licenses:
1) Mere aggregation. This applies for "The Schily Makefilesystem" and other
software as well as with e.g. cdda2wav and cdrecord.
2) GPLd software uses CDDLd libraries. This is done in a way that does not
make the CDDLd software a "derived work" of the GPL software. This
is done for mkisofs an libschily/libscg.
If Debian sees a problem with 1) bedause of their interpretation of the GPL,
then they need to clearly call the GPL a non-free license. BTW: any GPL software
that makes use of GPL §8 clearly violates the DFSG, so I would not call the GPL
a generaily free license.
If Debian has a problem with 2) they would need to call things like Cygwin
a violation of the GPL and would be in contradiction to usual GPL interpretations.
> > If you are so braindead not to understand that this license combination
> > is perfectly OK, I cannot help you. It seems that I did waste already too much
> > time with you. A discussion only makes sense in case that the "other side"
> > is able/willing to understand simple explanataions...
>
> Your "simple explanations" are wrong. I'm not going to re-explain what
> Wouter explained better than I would. If you cannot understand that the
> CDDL is incompatible with the GPL, you should stop talking about
> licenses and only keep coding, a task for which you seem to have more
> talent.
You still did not read the GPL and you still claim things that cannot be found
in the GPL the way _you_ claim...
You shoul stop talking about licensing if you are unable or unwilling to
read the GPL and compare my claims with the GPL.
> > If this was true, why don't you talk with me with in a serious way but troll
> > instead?
>
> I have yet to be shown how it is possible to discuss with you in a
> serious way.
I am still waiting that you start using provable arguments when trying to
defend your claims.
Once you start using provable arguments based on correct quotings, it may be
possible to have a serious discussion with you, but for now, it's you who
is missing the base for a discussion. If you really like a serious discussion,
treat me in a serious way but do not try to surprise me with incorrectc
quotations from the GPL.
> > I am sorry, but I cannot waste my time with trolls like you.
>
> You are the one bringing this discussion on the Debian development
> mailing list. You are wasting the time of people reading this list.
It's not me who did use this word first...
> If "reasonable" means "who agree with you", I have yet to see them.
Reasonable means provable and you did not send any provable claim so far...
Joerg Schilling
> Joerg Schilling <schi...@fokus.fraunhofer.de> writes:
>
> > Josselin Mouette <jo...@debian.org> wrote:
> >> GR stated that invariant sections aren't acceptable for the specific
> >> GFDL case, and there is no reason why they would be acceptable for
> >
> > If Linux Distributions would not distribute bastardized versions of cdrecord,
> > there was no need to add the statements you might be talking about.
>
> Sorry, but you say your software is free. That means Debian (or anyone
> else) is free to bastardize cdrecord as much as they want. That is
> called freedom.
>
> You can require proper notice or even a name change of the software
> when such "bastardization" is done but when you start forbiding such
> changes then your software is no longer free.
I am sorry but it seems that you miss to read the Urheberrecht....
AND e.g. the GPL.
Both forbid to damage the reputation of the original author.
As I _did_ already receive coplaints against cdrecord that have been e.g. based
on the fact that Linux distributoions change the name for the file
/etc/default/cdrercord and the fact that the basterdized behavior is
incompatible with the (officially) documented behavior, these Linux
distributions cause harm....
Free software gives you the right to change software but free software
definitely does _not_ give you the right to use the originam _name_ of the
software in case you apply incompatible changes or in case that you introduce
bugs. The license is related to "urheberrecht", using the original name
of the software is related to trade mark right....
If people at Denbian are missing this kind of basic knowledge, how
would it be possible to discuss license issues in a serious way?
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Linas Žvirblis
>>> The Debian project accepted the clauses in cdrecord ~ 4 years ago.
>> That doesn't mean the project still considers them acceptable *NOW*.
> So you like to tell me that Debian is not trustworthy?
The requirements of the project changed. That is called progress.
Joerg Schilling
> > If you don't know that you just need to use a clearly _different_ _name_
> > for such a fork, I can't help you. Read the preamble from the GPL
> > to understand your fault.
>
> So all we need to do to apeace you is to call is "debianrecord"?
>
> If that is all that is needed for you not to complain that we include
> unsupported dvd support and the like then that can easily be aranged.
This is really funny......
The oficial cdrecord _does_ support DVD writing.
Why do you like to first hide this feature from your users and then
later add broken DVD "support"?
> But then please just say so. The GPL alone does not require such a
> rename, only that "the modified files to carry prominent notices
> stating that you changed the files and the date of any change".
The GPL does not allow you to use the original name......
This is related to different things (trade mark right).
> You should just add a requirement for renaming the software instead of
> your invariant section and extra printing code requirement.
Note that the name "dvdrecord" is illegal too as this name is "too close"
to the name cdrecord and many people use the name "dvdrecord" for the newer
versions of cdrecord that include DVD writing although I did never mentioned
this name for my software.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Jean Parpaillon
Le 09.08.2006 15:33, Joerg Schilling a écrit :
> If you don't know that you just need to use a clearly _different_ _name_
> for such a fork, I can't help you. Read the preamble from the GPL
> to understand your fault.
>
>
Beside the licensing issues, why do you care so much patched version of
your software to be distributed with big WARNINGS, a different name and
tutti quanti ?
AFAIK, each Linux distribution have a huge bag of patches it applies on
the Linux kernel and the reputation of the kernel devels is not
compromised. And it's quite the same about gcc and many pieces of free
softwares.
Aren't you afraid that your reputation is _far_ more about the issues to
ditribute your software than about the quality of your software ?
Regards,
Jean Parpaillon
--
_________________________________________
/ La science a fait de nous des dieux \
| avant même que nous méritions d'être |
| des hommes. -+- Jean Rostand |
\ (1894-1977) -+- /
-----------------------------------------
\ ^__^
\ (**)\_______
(__)\ )\/\
U ||----w |
Ralph Amissah
>> with the OSI and doesn't not rely on the OSI to be told what is free
>> or not. Can't you even understand something that simple?
>
>I understand things but if Debian people have problems to understand
>that the OSI is the only independend institution that deals with OSS
>Licenses, you are obviously a bit out of order.
"Debian" has no problem understanding that they will independently
determine what licenses are suitable to "Debian".
If you want your software in Debian, use a currently Debian approved
license.
On 10/08/06, Joerg Schilling <schi...@fokus.fraunhofer.de> wrote:
> Goswin von Brederlow <bred...@informatik.uni-tuebingen.de> wrote:
>
> Note that the name "dvdrecord" is illegal too as this name is "too
> close" to the name cdrecord and many people use the name "dvdrecord"
> for the newer versions of cdrecord that include DVD writing although I
> did never mentioned this name for my software.
>
>
Surely you jest... then again, perhaps you don't.
It is highly unlikely (that any jurisdiction would recognise) that there could
be any restriction on use of the name "dvdrecord" resulting from the
existence of another highly generic name cdrecord:
cdrecord and dvdrecord are generic names, describing what the
software does... granted you may have a claim to cdrecord having named
your software thus, but even this might be challenged by close similarly
generic cdrecordtype variants... it is questionable whether cdrecorder
or recordcd for example would be protected...
you cannot by virtue of using the generic type name cdrecord control
variants of the genric term let alone (yet) another name that is as generic
(and different): dvdrecord.