DFSG#10 [was: Re: Draft Debian-legal summary of the LGPL]

[Francesco Poli]

On Wed, 12 May 2004 09:27:49 -0700 Josh Triplett wrote:

> For that matter, the same applies to the currently-posted summary of
> the GPL.  At the moment, the summary just states that the GPL passes
> the DFSG because it is explicitly listed in DFSG 10.  It would be
> highly preferable to compare the GPL against DFSG 1-9 as if 10 wasn't
> there, as a consistency check: we don't want 10 to act as an exception
> to the rest of the DFSG, only as an example of some licenses that pass
> the rest of the DFSG.

Agreed, fully.

I'm not quite happy with DFSG#10:

* it lists some examples of free licenses, but it doesn't specify which
versions/variants it's talking about (GPL v2 or another? n-clause BSD
with n=? Original or clarified Artistic?)

* it's subject to changes (some issue with one of those licenses might
come up in the future, who knows?)

* it could be misinterpreted as a rule, rather than a clarification by
examples (sort of)


I'd say that sort of information shouldn't belong in the DFSG: IMHO it
would fit much better in informative pages such as
http://www.debian.org/legal/licenses/

What do you think?


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgp5XbTDLE6we.pgp
Description: PGP signature

Re: Draft Debian-legal summary of the LGPL

[Francesco Poli]

On Tue, 11 May 2004 17:17:25 -0300 Humberto Massa wrote:

> >Debian-legal has concluded that the LGPL (Library Gnu Public License)
> >v2 and LGPL (Lesser Gnu Public License) v2.1 is a DFSG-free license.
> >  
> >
> s:is a DFSG-free license:are DFSG-free licenses:

Even better:

Debian-legal has concluded that the GNU LGPL (GNU Library General Public
License) version 2 and the GNU LGPL (GNU Lesser General Public License)
version 2.1 are DFSG-free licenses

:)

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpEPIFzwOfIY.pgp
Description: PGP signature

Re: DFSG#10 [was: Re: Draft Debian-legal summary of the LGPL]

[Francesco Poli]

On Wed, 19 May 2004 09:59:55 +0200 Andreas Barth wrote:

> * Francesco Poli ([EMAIL PROTECTED]) [040519 00:25]:
> > I'm not quite happy with DFSG#10:
[...]
> If it's not a bug, then don't fix it. We have enough problems with
> unnecessary changes to the SC, so please leave DFSG#10 alone.

But I feel that it could be seen as a bug.
I'm not quite comfortable with this `grandfathering' thing.
It could become a slippery slope: someone may come up with something
like:

"if the GPL is not-quite-free, but it's considered free anyway only
because it's grandfathered by DFSG#10, why cannot the
 be grandfathered as well?"


I'm not asking this, but if someone else asks?

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpUjPZYodWtX.pgp
Description: PGP signature

Re: DFSG#10 [was: Re: Draft Debian-legal summary of the LGPL]

[Francesco Poli]

On Fri, 21 May 2004 18:31:44 -0400 Glenn Maynard wrote:

> Of course, the "not comfortable" in the message you replied to was
> referring to grandfathering, not to the freeness of the GPL, so it
> didn't really make much sense as a reply.

Yes. Thank you for highlighting this (just in case it wasn't clear
enough).

To clarify once and for all:

I'm *not* against the GNU GPL.
Even if I see some of the issues that came up (like the one about clause
2c)...

I simply stated that I'm not quite happy if DFSG#10 is interpreted as
"these licenses are considered free, whatever they say".
As I said, I'm a bit uncomfortable with the `grandfathering' operation:
"we make exceptions" could become a slippery slope (hence my example of
a person who tries to persuade d-l to make an exception for his
favourite non-free license as well).

I'd be much more happy if the GNU GPL were ruled DFSG-free on the basis
of DFSG#1-9. That's it.


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpmfSkf0sa3G.pgp
Description: PGP signature

Re: A radical approach to rewriting the DFSG

[Francesco Poli]

On 30 May 2004 06:28:12 +0100 Henning Makholm wrote:

> I have been toying with the possibility of rewriting the DFSG such
> that it enumerates which things a free license *can* do, rather than
> just give examples of things it *cannot*.

It sounds interesting: it may work better...

> I think that such a revision
> could get the guidelines to be much closer to the *actual* practise of
> how we evaluate licenses than if we simply make local adjustments to
> the current DFSG. The downside is that the whole truth cannot be
> condensed into the "ten commandments" schema of the current DFSG.
> 
> My results so far are at
>
> 
> Comments will be appreciated - both about the general angle of attack,
> and about my specific draft. I have probably forgotten about a detail
> here and there.

First comments:

* the title: why `stuff'? I'm more comfortable with free _software_
guidelines, perhaps with a clear statement that we interpret the term
`software' as every piece of information that can be treated by a
computer system (that is programs, documentation, data...)[1]
Should these guidelines become the new DFSG, I think they will be named
Debian Free Software Guidelines version 2.0

* "Here, accompanied with the source must be understood to include the
situation where source is available for download from the same network
location and under the same conditions as the non-source form is
available under." I would generalize this:
s/available for download from the same network location/available from
the same place/

* typo: "respect to his to his own copyright" s/to his to his/to his/

* enhancement (maybe): "if the user knowingly copies the work in a way
not permitted by the license"
s/copies/copies or distributes/

* typo (I think): "license may require than" s/than/that/

* typo? "when a copy of the work are sold" s/are/is/ ???

* question: "Such a restriction is exactly as silly as it sounds.
However, some otherwise free programs come with licenses that specify
that the program must not be sold alone but only as part of an aggregate
software distribution."
Do you regard those programs as free? Is there any consensus on d-l
about this awkward restriction?

* Specific exception for 3-clause BSD licenses: "Debian strongly
encourages authors to use more appropriate tools than copyright licenses
if they feel they need more protection than the usual laws against
misleading advertising." which tools? Trademarks? Any other? I think you
should suggest at least one...

* Grandfather clause: mmmh! I already clarified MHO about
grandfathering, so I won't repeat myself...[2] Just a question: does
this mean that you also grandfather GPL#8?


Notes:

[1] of course the statement should be better phrased, but you know what
I mean and I'm in a hurry now... sorry  :p 

[2] read as: I would prefer if d-l revised the three famous licenses to
be sure they are acceptable on the basis of the other guidelines


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpo04G0LsydP.pgp
Description: PGP signature

Re: A radical approach to rewriting the DFSG

[Francesco Poli]

On Mon, 31 May 2004 01:07:02 -0400 Glenn Maynard wrote:

[...]
> Part 5 seems like it should be an appendix, and not part of the core
> guidelines.

I agree: much better to separate those /examples/ from the actual
guidelines.


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgphRAOjiWbvT.pgp
Description: PGP signature

Re: A radical approach to rewriting the DFSG

[Francesco Poli]

On Sun, 30 May 2004 09:06:18 -0700 Josh Triplett wrote:

> Francesco Poli wrote:
> > * question: "Such a restriction is exactly as silly as it sounds.
> > However, some otherwise free programs come with licenses that
> > specify that the program must not be sold alone but only as part of
> > an aggregate software distribution."
> > Do you regard those programs as free? Is there any consensus on d-l
> > about this awkward restriction?
> 
> I believe the general consensus is that since the requirement is so
> trivially satisfiable, it is considered free.

Ah, I see your argument. Well, you're right that a trivial workaround
exists for such a restriction. As a consequence, the restriction is
almost absent. Awkward, but almost absent... 

> As long as there is no
> restriction on how much additional software must be included, the
> requirement could be satisfied by either:
[...]
> * a one byte file containing "w", which would be a valid sh script to
> run the "w" command.

Wow! TSSSITHOCS!
(The shortest shell-script in the history of computer science)
  ;-)


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgp7EIZAdLjRY.pgp
Description: PGP signature

You can't get a copy unless you accept the GPL [was: Re: libkrb53 - odd license term]

[Francesco Poli]

On Tue, 1 Jun 2004 20:35:09 +1000 Matthew Palmer wrote:

> I guess, though, in a way
> it's another wording of the GPL's "you can't legally get a copy except
> by the permissions we've granted here, so we'll take it as read you
> accept this licence" clause.

Wait, wait!
I'm not sure I understand what you're saying here (maybe it's my
english-language-parser's fault... :p )

Do you mean I have to accept the GPL in order to *get* a copy of a GPL'd
work?

I suppose you're referring to the following GPL-2 clause:

]   5. You are not required to accept this License, since you have not
] signed it.  However, nothing else grants you permission to modify or
] distribute the Program or its derivative works.  These actions are
] prohibited by law if you do not accept this License.  Therefore, by
] modifying or distributing the Program (or any work based on the
] Program), you indicate your acceptance of this License to do so, and
] all its terms and conditions for copying, distributing or modifying
] the Program or works based on it.

I have always interpreted it as covering actions such as distributing,
modifying... but not getting copies!
Am I wrong?

That is: I'm not required to accept the GPL if I simply want to download
(and install and use) a GPL'd piece of software.
The person who distributes the work to me must have accepted the GPL,
but I'm not required to.

License acceptance is instead necessary when *I* want to modify or
distribute the work (or a modified version of the work).

Is that right?

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpxSf5UbHKg7.pgp
Description: PGP signature

Re: A radical approach to rewriting the DFSG

[Francesco Poli]

On Mon, 31 May 2004 01:04:36 -0400 Glenn Maynard wrote:

> 2. Source code
>   "The source for a work is a machine-readable form that is
>   appropriate for modifying the work or inspecting its structure and
>   inner workings."
> 
> Is there a benefit to using a different definition than the GPL?

Personally, I don't think there is... I would prefer the definition of
source code adopted by the GPL: it's less vague.

> 
> One case where this seems different is images.  For example, I have
> several PNGs, generated by Photoshop.  The PNG itself is appropriate
> for modifying the work, but it's not the preferred form for
> modification. Going by feel, it's not the source of the work at all.

I agree. The PNG format is not source, if it's generated from some other
format. It can be source, though, when editing is being performed
directly on it.
In other words, the most suitable definition of source code seems the
"preferred form for making modifications".

> 
> This also reveals a case that hasn't been resolved: do we expect
> source for PNGs, when such a form exists?

I think we should.

> In practice, we don't,

Strange!  :-|

> and I tend to classify it as "that would be nice, but it's not a
> worthwhile battle".

Why? What if someone wants to modify those images?

> Another major case of this (and one which is less
> ambiguous) is fonts. It would be nice to find a consensus on these,
> rather than having a new set of guidelines that still doesn't address
> the issue.

I thought that DFSG#2 was already addressing the issue ("The program
must include source code").

> 
> (I'll admit that "I don't want Debian to have to drop most of its
> high- quality fonts" is probably a major factor in my opinion on this,
> which sounds somewhat like "I don't want Debian to have to drop
> Netscape".)

Are there so many high-quality fonts with no actual source code in
Debian?
More important: are there so few high-quality fonts with source
available in Debian?


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpSF4aHr1OfI.pgp
Description: PGP signature

Re: A radical approach to rewriting the DFSG

[Francesco Poli]

On Sun, 30 May 2004 13:24:55 +0200 Francesco Poli wrote:

> > Comments will be appreciated - both about the general angle of
> > attack, and about my specific draft. I have probably forgotten about
> > a detail here and there.
> 
> First comments

Antoher couple of comments:

* "A derived work can be anything from a slightly modified versions of
the original work to a completely new work that includes parts of the
original work in a new contexts. The term also includes translation of
works into other languages, compilation of programs to machine code or
bytecode, and other transformations that prepare the work for being
used."
typo: s/versions/version/
typo: s/contexts/context/
proposed generalization: s/bytecode/pseudo-code/
   or maybe  s/bytecode/intermediate languages/

* "Rationale: A user in a remote location (say, any computer that is not
connected to the Internet) must have the freedom to contract with a
business to create a copy of the software and transport it to him. If
the licensing of the software prevents the business from getting a
profit out of this, the software is not truly free."
question: why such a complicated example?
Free software is not against business. It just aims to a different (and
better) kind of business (with respect to proprietary-software based
business).
In other words: if commercial distribution is prohibited by the license,
then it's clearly non-free software.
I cannot see the need for a strange example to explain this...

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgp9Eqt9DBVo8.pgp
Description: PGP signature

Re: You can't get a copy unless you accept the GPL [was: Re: libkrb53 - odd license term]

[Francesco Poli]

On 02 Jun 2004 12:52:37 +0100 Henning Makholm wrote:

> If you want to *download* the sofware, then you'd better do it by the
> GPL's terms. "Downloading" implies that you are instructing some
> computer to make create a copy of the Work on your hard drive.

Thus a downloaded package (e.g. from Debian mirror network) is legally
different from a package obtained on a CD (e.g. provided by a Debian CD
vendor).
Is that right? If this is the case, I see it as a bit surprising...

Or does the copy from CD to HD (that I must perform in order to install
the package) trigger copyright laws too?
In that case, I cannot install a package without accepting its license:
that sounds strange.
The user can use the software without accepting the license, but the
sysadmin must have accepted it, otherwise he could not install it...


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpVc9JBA9rma.pgp
Description: PGP signature

Re: You can't get a copy unless you accept the GPL [was: Re: libkrb53 - odd license term]

[Francesco Poli]

On Wed, 2 Jun 2004 16:27:28 +0100 Edmund GRIMLEY EVANS wrote:

> It seems to me that the person who puts something on line is usually
> regarded as the person doing the copying.

That is indeed what I have thought till a few days ago... And it's still
the most reasonable interpretation I can think of...

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgp7fLBvLRORP.pgp
Description: PGP signature

Re: A radical approach to rewriting the DFSG

[Francesco Poli]

On Wed, 02 Jun 2004 20:07:06 -0400 Nathanael Nerode wrote:

> The essence of what I would accept is this:
> 
> "If you claim, legally, that my work can't be
> distributed/used/modified freely by people in general, then *you*
> can't distribute/use/modify my work either".  A "if you think this
> should happen to everyone else, it should happen to you too" clause.
> 
> This prevents people from actually literally taking free software
> proprietary (not just derivative works, but the originals) -- this
> could otherwise be done using patents.

It seems a good approach: it may work.

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpDtvBC0Th3X.pgp
Description: PGP signature

Re: Bug#251983: libcwd: QPL license is non-free; package should not be in main

[Francesco Poli]

On Wed, 2 Jun 2004 23:33:14 +0200 martin f krafft wrote:

> i release all my work under the artistic licence, or the
> do-as-you-damned-well-please licence, or an attribution licence.
> afaict, all these allow closed derivation. yet, they are all
> dfsg-free.

If you are referring to the Creative Commons Attribution License 1.0
(CCPL-by), please note that it has been found to be DFSG-non-free...

See http://lists.debian.org/debian-legal/2004/04/msg00031.html for the
summary.

The discussion thread begins at
http://lists.debian.org/debian-legal/2004/03/msg00267.html

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpdYVveTPj39.pgp
Description: PGP signature

Re: You can't get a copy unless you accept the GPL [was: Re: libkrb53 - odd license term]

[Francesco Poli]

On Fri, 4 Jun 2004 11:46:51 +0200 Bernhard R. Link wrote:

> * Henning Makholm <[EMAIL PROTECTED]> [040602 16:42]:
> > If you want to *download* the sofware, then you'd better do it by
> > the GPL's terms.[...]
>
> If you log on some computer and make a copy there and transmit it to
> you (like ssh'ing into a solaris box and copying /bin/true), this may
> be true.
> 
> But normally someone set up a computer do make a copy and sent it to
> me, if I request it. As when someone makes copies of a CD and sends
> them to me, when I send him a postcard.

I agree.


Henning, consider how, say, the HTTP protocol works: an HTTP server
serves some content upon my *request*. I send a

  GET /path/lbreakout2_2.2.2-1woody1_i386.deb

to the web server, it processes my request (this choice of word is not a
coincidence!), determines if I have permission to get that resource and
serves a response to me.
The response may contain a

  403 forbidden

error code, or a copy of

  $DOCUMENTROOT/path/lbreakout2_2.2.2-1woody1_i386.deb


Is that any different (from a legal point of view) from visiting one
friend of mine, seeing that she has a great game installed on her Debian
Woody machine, *asking* her "May I have a copy of the deb package?" and
going back home with a floppy disk containing
lbreakout2_2.2.2-1woody1_i386.deb?

My friend is the one who is making the copy.
In the HTTP example, the copy is being made by server, that is (from a
legal standpoint) by the person who put online the file.


In the HTTP example, you can also consider the case in which the
response contains dynamically-generated content: that content may be a
derived work of something (a template, perhaps...).
Do you claim that *I* am the person who generated that content?
I don't even necessarily have access to the template!

I think that derivation is made by the server: after all, they are
called *server-side* scripting languages...


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgprcWqdBekmw.pgp
Description: PGP signature

Re: You can't get a copy unless you accept the GPL [was: Re: libkrb53 - odd license term]

[Francesco Poli]

On Fri, 4 Jun 2004 23:25:18 -0700 Adam McKenna wrote:

> the reason you can copy a file
> which has been released under the GPL without accepting the GPL is
> because you are explicitly granted that right by the GPL.

I don't think so: you are not granted any right by a license, unless you
accept the license itself.
Hence, I don't see how could the GPL grant any right to make copies to
someone who is not willing to accept the GPL itself.


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgp3AM4y2lpZZ.pgp
Description: PGP signature

Re: You can't get a copy unless you accept the GPL [was: Re: libkrb53 - odd license term]

[Francesco Poli]

On Sun, 6 Jun 2004 10:45:59 -0700 Adam McKenna wrote:

> On Sun, Jun 06, 2004 at 11:08:50AM +0200, Francesco Poli wrote:
> > On Fri, 4 Jun 2004 23:25:18 -0700 Adam McKenna wrote:
> > 
> > > the reason you can copy a file
> > > which has been released under the GPL without accepting the GPL is
> > > because you are explicitly granted that right by the GPL.
> > 
> > I don't think so: you are not granted any right by a license, unless
> > you accept the license itself.
> > Hence, I don't see how could the GPL grant any right to make copies
> > to someone who is not willing to accept the GPL itself.
> 
> Please read the GPL, specifically sections 5 and 6.  You only have to
> accept the license if you wish to modify or distribute the work.

Ooops. I apologize for not having recalled this.

> 
> I'm not going to participate in any more semantic arguments or legal
> 101 on what the definitions of the words 'distribute' or 'copy' are.

Could you please provide a good reference to some clear definition?
I hope I know the difference, but I'd better check anyway... :p

> If you are confused about copyrights in general, please go to 
> http://www.loc.gov/copyright and read the text entitled "copyright
> basics".

Well, *now* I'm a bit confused. At
http://www.copyright.gov/circs/circ1.html
I read the following:

é[ Section 106 of the 1976 Copyright Act generally gives the owner of
[ copyright the exclusive right to do and to authorize others to do the
[ following:
[
[* To reproduce the work in copies or phonorecords;
...

AFAIK the reasoning behind GPL#5 is that only the license gives me some
rights, hence I must have implicitly accepted it, if I exercise those
rights.
U.S. Copyright law (and many other copyright laws, I suppose) lists the
right to make copies as one of the copyright owner's exclusive rights.

That would bring me to the conclusion that I must accept the GPL in
order to make a copy of a GPL'd work.

See for example GPL#4:

[   4. You may not copy, modify, sublicense, or distribute the Program
[ except as expressly provided under this License.


On the other hand GPL#5 itself says I'm required to accept the GPL only
in order to distribute or modify...

Could you explain how's that possible?


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpIU94hxpjZ4.pgp
Description: PGP signature

Re: license change for POSIX manpages

[Francesco Poli]

On Fri, 11 Jun 2004 08:51:39 -0400 Nathanael Nerode wrote:

> >> One other issue: does "and the nroff source is included" mean that
> >if I> want to hand someone a printed copy of a manual page, I have to
> >either> print the nroff source or supply it on an attached disk? 
> >This seems> onerous for physical distribution.
> 
> Well, if you use the usual intepretation, you only have to *offer*
> someone the attached disk; if they decline it, you don't have to force
> it on them.

Well, but *can* we use the usual interpretation?
Our standard practice is to assume the most pessimistic interpretation,
isn't it?

And it says "included" with no other alternative options...
How can I assume they intended that an offer would be just as fine?


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0



pgpmPxch7yylR.pgp
Description: PGP signature

Re: license change for POSIX manpages

[Francesco Poli]

On Wed, 09 Jun 2004 09:53:18 -0700 Josh Triplett wrote:

> >>One other issue: does "and the nroff source is included" mean that
> >>if I want to hand someone a printed copy of a manual page, I have to
> >>either print the nroff source or supply it on an attached disk? 
> >>This seems onerous for physical distribution.
> > 
> > This is what happens if you apply the GPL to documentation, and it
> > seems to be considered acceptable.
> 
> The GPL has an option for just providing an offer to provide source on
> request.

Moreover, the GPL requires that *source code* be accompanied or offered.
This POSIX license requires that *nroff source* be included.

What if I created a derivative work by
step 0) converting it from nroff to some other typesetting language
(e.g. DocBook XML, LaTeX, XHTML, ...)
step 1) then applying lots of modifications to it
?

In that case, I'd say the new source code is in the other language (say,
DocBook): with the GPL I'd have to accompany or offer the new source
code in order to distribute my derivative work.

But what should I do in order to distribute my derivative work *and* to
comply with the POSIX license?
No nroff source would exist for my derivative work...
Such a derivative work would be undistributable, correct me if I'm
wrong.

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpgICxy8Cbgs.pgp
Description: PGP signature

Re: How aggressively should non-distributability bugs be dealt with?

[Francesco Poli]

On Tue, 15 Jun 2004 14:21:08 -0400 Nathanael Nerode wrote:

> I ask because of #242895.  In the Linux kernel,
> drivers/usb/misc/emi26_fw.h has a specific proprietary rights
> statement which does not give permission to distribute.

I will not enter in the discussion about the nature of those firmwares
as part of the Linux kernel (is the kernel a derivative work of these
firmwares and of the rest? a compilation or collective work?) as I don't
understand exactly how those firmwares *can* technically be part of the
kernel[1].

Anyway, IIUC, this one is undistributable even as a separate work.
I mean: not (only?) because of license incompatibility, but by the very
nature of the license itself (it does not give permission to
distribute).

This is serious, correct me if I'm wrong: Debian is distributing some
copyrighted thing without any permission to do so.
Even www.kernel.org is doing so, isn't it?
This is copyright law violation and it would be so even if Linux were
under the 2-clause BSD license.

I think that this situation should fixed ASAP.

IMHO the best solution would be to contact the firmware copyright holder
and persuade her to rilicense it under a GPL-compatible license (so that
every doubt would go away immediately).

A suboptimal solution is to remove the offending parts of the kernel (or
possibly replace them with GPL-compatible substitutes...) and suggest
upstream (kernel maintainers) to do the same thing with the official
Linux kernel.

[...]
> Personally, I would think that anything which exposes Debian to
> lawsuits for wilful copyright infrignement should be removed as soon
> as humanly possible.

I agree.
This situation should be dealt with quickly.




[1] I thought that firmware was a `microprogram' resident in the
hardware in order to implement some non-elementary operations by
exploiting elementary ones (that are performed directly by the hardware)
[I apologize for this gross definition]: so I don't quite understand how
a firmware can be shipped with an operating system kernel; I thought it
was shipped in the hardware (CPU, board, ...).
Perhaps someone knowledgeable will explain me (in private e-mail)...

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpMoPdYeNjei.pgp
Description: PGP signature

Re: How aggressively should non-distributability bugs be dealt with?

[Francesco Poli]

On Wed, 16 Jun 2004 16:22:06 -0700 Josh Triplett wrote:

> Francesco Poli wrote:
> > IMHO the best solution would be to contact the firmware copyright
> > holder and persuade her to rilicense it under a GPL-compatible
> > license (so that every doubt would go away immediately).
> 
> This would not solve the problem, unless they also released the source
> of the firmware.  Without that source, the firmware would either be
> non-distributable (if under a license like the GPL that requires
> source) or non-free (if the license does not require source).

Of course, releasing the source is an essential step of making something
free.
When I wrote "to r[e]license it under a GPL-compatible license" (and put
a typo in it...  :p ) I meant implicitly that source code should be
provided also...


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpBoGpRaPDXy.pgp
Description: PGP signature

Re: How long is it acceptable to leave *undistributable* files in the kernel package?

[Francesco Poli]

On Thu, 17 Jun 2004 09:37:09 -0400 [EMAIL PROTECTED] wrote:

> > I suspect that few people think a GPL'd installer of Microsoft Word
> > would be compliant with the GPL.  That's a reasonable analogy,
> > right? A hardcoded string, copied to some device which runs it, and
> > maybe with some additional setup.
> 
> The installer can be GPLed, sure.  Why shouldn't it be?  You will
> likely run into other copyright issues because you do not have
> permission to redistribute Microsoft Word like that, but it is
> irrelevant to the GPLness of the installer.

Well, if MS Word is installed by unpacking a separate package, then it's
merely data from the installer point of view. In this case, yes, the
installer can be GPL'd.
Just as dpkg(8) which is GPL'd, but, of course, using it to install a
non-free deb package is not a dpkg copyright violation.

It seems to me that the conclusion would be different if MS Word binary
files were hardcoded as strings defined in the installer source code.
In that case I would say the GPL'd installer is a derivative work of MS
Word and thus undistributable.
Anyway, I see that there are some people who claim that hardcoding a
work as a string included in the source code of a program creates
aggregation/anthology rather than a derivative work... So I expect that
those people disagree with me on this latter case...

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpvfSVZ16PF7.pgp
Description: PGP signature

Re: How aggressively should non-distributability bugs be dealt with?

[Francesco Poli]

On Thu, 17 Jun 2004 15:58:37 -0700 Josh Triplett wrote:

> > Of course, releasing the source is an essential step of making
> > something free.
> > When I wrote "to r[e]license it under a GPL-compatible license" (and
> > put a typo in it...  :p ) I meant implicitly that source code should
> > be provided also...
> 
> No problem.  The only reason I mentioned it is that one of the many
> facets of this issue involves firmware images supposedly licensed
> under the GPL, but with no source provided.  In these cases, even
> though the license is Free, the firmware is non-distributable.

Sure, 'cause we don't have what we need to distribute in compliance with
the license. Hence the copyight holder is the Only One who can
distribute such `free-wannabe' software...  :-(

I agree with you: such clarification was useful.

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpge1rjJd0P9.pgp
Description: PGP signature

Re: How long is it acceptable to leave *undistributable* files in

[Francesco Poli]

On Fri, 18 Jun 2004 03:27:28 +0200 Thiemo Seufer wrote:

> > It would (if correct) make a lot of current copyright infringement
> > (or as it is sometimes called "software piracy") legitimate. Since
> > I'm not distributing the source code (which is the original work of
> > authorship), just a mechanical transformation of it (ergo
> > non-copyrightable), giving MSOffice.exe to all my friends is not a
> > copyright violation?
> 
> Why do you think so? The result still falls under the same copyright
> protection as the original has. It's just a different representation.

Yes: it's not a derivative work, it's the *same* work under a different
representation.
The act of compiling source code into binary does not *add* creative
elements to the original work, hence the law says that this act cannot
*add* copyright holders to the work.

It seems reasonable to me (anyway IANAL).

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpNfPbyzO9Ec.pgp
Description: PGP signature

Re: How long is it acceptable to leave *undistributable* files in

[Francesco Poli]

On Sun, 20 Jun 2004 10:16:53 -0400 Raul Miller wrote:

> Consider, for example, building emacs against a third party supplied
> proprietary libc.

That would possibly require modifying Emacs source code and that's the
creative act (it would create a derivative work, no doubt about that).
OTOH, when you issue the classical

$ ./configure
$ make

commands, you are not performing any creative act.
Do you agree?

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpgat1nAAoQP.pgp
Description: PGP signature

Re: How long is it acceptable to leave *undistributable* files in the kernel package?

[Francesco Poli]

On Fri, 18 Jun 2004 14:26:05 -0500 Joe Wreschnig wrote:

[...]
> I agree with Michael Poole insofar as this message.

I agree too.

> Here's an attempt
> at an unbiased summary:
> 
> There are four classes of firmware:
> 
> 1. Firmware which no one has any permission to distribute. These have
> to go right away, or be relicensed. Thankfully, there are few of
> these, and the kernel team seems to be willing to help pursue the
> relicensing.

Good to know...

> 
> 2. Firmware which is released under GPL-compatible terms, with source.
> Everyone loves these, they can stay (e.g. the Adaptec drivers), and we
> encourage other manufacturers to do the same.

Yes and I would say that a sort of list of "manufacturers that did the
Right(TM) thing" could potentially encourage other ones to do the same,
perhaps.
Maybe some credit to those manufacturers (and to other hardware
manufacturers that behave in a free-software-friendly way, not
necessarily in a Linux-kernel-specific manner) could be put in a
dedicated section of the Debian web site.
What do you think?

> 
> 3. Firmware which is released under GPL-compatible terms but with no
> source available.
> 
> 4. Firmware which is released under GPL-incompatible terms with no
> source available.
> 
> (There is potentially a fifth class, firmware released under
> GPL-incompatible terms with source available. I don't believe anyone
> has found such a beast yet.)
> 
> The debate is over 3) and 4). Specifically,
> 
> 3a) What is firmware "source"?

The "preferred form for modification", as defined in the GPL.
And I think that *very* few programmers would prefer dealing with those
string encodings rather than some assembly language form (or whatever is
more human-readable)...

> 3b) If the firmware has source, does the DFSG apply to it (i.e. do we
> need it)? Unequivocally yes with the new DFSG, but some of the GRs
> (not voted on yet) may revert sarge to the "old" DFSG, and the RM's
> interpretation of that lets us release such firmware.

Why? 'Cause firmware is not software?

> 3c) If the firmware has source but the source is not available to us,
> is it a GPL violation for us to distribute it?

I think it is.
A violation of the GPL license *applied* to the firmware itself.

> 
> 4a) All the problems above, and,
> 4b) Is there some relationship between firmware and the rest of the
> kernel that makes this amount to a GPL violation? This is related to,
> but not the same as, the answer to 3c).

I think that a kernel that incorporates a firmware is a derivative work
of the firmware. So, yes, I think that distributing a Linux kernel that
embeds a GPL-incompatible firmware is a violation of the GPL license
applied to other parts of the kernel itself.



-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgp1lBxTlnZC3.pgp
Description: PGP signature

Re: How long is it acceptable to leave *undistributable* files in the kernel package?

[Francesco Poli]

On Fri, 18 Jun 2004 13:06:37 -0700 Josh Triplett wrote:

> I would argue that while the new Social Contract makes it
> unambiguously clear that the DFSG applies to non-programs (such as
> documentation, etc), both the old and new Social Contracts clearly
> apply to "software".
>  While it has been disputed that non-programs such as documentation
>  are
> software, firmware seems to be a program and therefore software, which
> is covered under both Socal Contracts.

The traditional distinction that I'm aware of is between hardware,
software and firmware: so someone will say that firmware is not
software.

Instead, I think that `firmware' *is* software and should be treated as
such, especially as long as it can be embedded in a software source
code.
That is, firmware is a particular kind of software:

 (a) hardware
 (b) software
 (b.0) firmware
 (b.1) system programs
 (b.2) application programs
 (b.3) documentation
 (b.4) data
 (b.?) ...

> 
> > Current policy is that firmware types 1, 3, and 4 have to go. We
> > cannot change our policy such that 1 can stay; that is illegal. If
> > 3) and 4) are not copyright infringement (I and others believe they
> > are, Michael and others believe they are not, that is what this
> > debate is about), we*could* potentially suspend the SC/DFSG and
> > release with them. I think this is also a bad idea, but it's
> > feasible. If 3) and 4) are copyright infringement, then we must
> > remove them as well.
> 
> Agreed.  For what it's worth, I also believe that cases 3 and 4 are
> copyright infringement.

I agree too.


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgp0ysVkRzwyg.pgp
Description: PGP signature

Re: Visualboy Advance question.

[Francesco Poli]

On Sat, 19 Jun 2004 18:47:53 -0400 Evan Prodromou wrote:

> > Perhaps my choice of words was poor, but I think that emulators fall
> > into their own class of software because they rely on what is
> > generally commercial, non-free (and honestly, quite probably
> > illegal) software in order to run, which is why they fall into
> > contrib.
> 
> I guess I'm just not sure I buy that an emulator is materially
> different from a script interpreter, DFSG-wise.

I agree: they are not conceptually different from interpreters or JVMs
or image viewers or audio/video players, and so on.

They don't depend on ROM images: it's quite the opposite instead!
ROM images depend on an appropriate emulator to be executed.

$ python
Python 2.1.3 (#1, Sep  7 2002, 15:29:56) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> {Ctrl-D}
$

This interpreter runs perfectly fine, even without any script to
execute...
>From an interpreter point of view, a script is just data to process.

Similarly Kaffe would be in main even if there were no DFSG-free Java
programs available (correct me if I'm wrong).
A Java program cannot go in main if it cannot be executed by a DFSG-free
JVM, because it depends on a JVM (or on a JIT compiler or on a
java-to-native-code-compiler such as GJC).


I think that DFSG-free emulators should be in main as long as they don't
*depend* on non-free packages.
Usefulness is, IMHO, a completely different matter.

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpuwUt7LlSYZ.pgp
Description: PGP signature

Re: How long is it acceptable to leave *undistributable* files in

[Francesco Poli]

On Sun, 20 Jun 2004 13:00:14 -0400 Raul Miller wrote:

> What makes this particular point in time significant?

I'm not sure I understand your question...  :(
It's not time that's significant, it's the operation you are performing.

What I'm saying (well, trying to say...) is that you are not adding
creative elements by just running the build scripts and/or using
makefiles.
Perhaps you are substituting some copyiright holders with others in the
resulting binary if you link against a different libc implementation (in
the "linking creates derivative" assumption): the ones who hold
copyright for the replaced libc. But the mere build process is not a
creative act, as long as it goes straightforward with no need to modify
anything.

If you are porting Emacs in order to link it against some strange libc
implementation that was not in the mind of Emacs authors, then you
possibily have to modify something in the makefiles and/or in the C
source files. Then you are performing two operations: modifying
(creative act: you add your name among the copyright holders) and
building (non-creative).
 
-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgplVme5EFl39.pgp
Description: PGP signature

Re: Visualboy Advance question.

[Francesco Poli]

On Mon, 21 Jun 2004 09:50:35 +1000 Matthew Palmer wrote:

> On Sun, Jun 20, 2004 at 06:36:42PM +0200, Francesco Poli wrote:
> > I think that DFSG-free emulators should be in main as long as they
> > don't*depend* on non-free packages.
> > Usefulness is, IMHO, a completely different matter.
> 
> Because, of course, more useless software in main is exactly what we
> want. I don't think that's an argument you want to be pushing too
> hard.  

Well, I thought that useless software is maybe not worth to distribute
at all. You seem to imply that a free, but useless package must be
placed in contrib rather than in main...

> 
> Let me ask you this: if there was an image viewer, which only viewed
> one format of images, and there were no images out there in that
> format, would you want to see that in Debian?  What if there were
> images in that format, but in order to get them you'd have to break
> copyright law?

Cannot someone create some free image in that format in the near future?
Why should Debian wait for one such image to *be packaged* before moving
the viewer from contrib to main?

> 
> That second case is pretty much where we stand with a *lot* of game
> console emulators out there -- the only way to get data to use with
> them is to break the law.  Wonderful.

A real example: prboom is in contrib (at least in Woody). It's free
(under the GNU GPL license). It doesn't depend on non-free packages. It
can be installed without pulling in non-free packages and can execute
the FreeDoom IWADs that are free[1] (under a 3-clause BSD license), but
not packaged for Debian. But that doesn't stop me from downloading the
IWADs into my home directory and typing:

$ prboom -iwad ~/doom/freedoom-0.2/doom2.wad

That still seems to me very similar to

$ eeyes ~/images/myart/drawmadewithgimp.png


Neither FreeDoom, nor the hypothetical (but possible)
drawmadewithgimp.png are packaged for Debian.
Both are free (let's say the image I could create would be released
under the... mmmh... X11 license).


Why Electric Eyes is in main, while PrBoom is in contrib?


[1] http://freedoom.sourceforge.net/

> 
> This is very, very different to the case with your average image
> viewer or script interpreter -- you can create some images yourself,
> or write a script to be run.  There's likely to be thousands of the
> damn things out there already, for you to use.  Therefore, we can make
> a reasoned guess that users will be able to use this software freely. 
> No such reasoned guess can be made for console emulators for which no
> free ROM images exist.

Wait, Mutella is in main: someone could argue that we cannot make a
reasoned guess that users will be able to use a P2P network client
without breaking the law.
I know that P2P is not illegal per se. And I know that legal uses of P2P
networks are *possible*. But someone could argue that the *principal*
use would be in violation of copyright laws...
So what should we do? Move it to contrib?

> 
> So, if a program is free itself, but cannot be used in a free manner,
> where does it go?  Contrib.  Where are the console emulators in
> question? Contrib.  Hmm...
> 
> Or, to take it another way entirely: Policy has the following to say
> (in part) about the use of dependencies:
> 
> The Depends field should be used if the depended-on package is
> required for the depending package to provide a significant amount of
> functionality.
> 
> The litmus test here is "a significant amount of functionality", not
> "will refuse to work at all without it", although that's a fairly good
> description of a console without a ROM.  But I would *certainly* say
> that doing anything other than sitting around asking for a ROM image
> would count as "a significant amount of functionality".
> 
> Your attempted analogy to a python interpreter is flawed, too.  I can
> type things in at the >>> prompt and get python to do something.  Can
> I reasonably be expected to type things in to a console emulator's
> dead prompt and expect to be able to use the emulator for the purpose
> for which it was intended?  I would imagine not.

I could begin to write free software for the emulated hardware.
It would be perhaps much more difficult than writing a Python script,
but that's a difference in quantity, not in quality.

> 
> Console emulators are in contrib for good reason -- because they have
> no use that we can see without a dependence on non-free material. 
> SC#1 says "We
> will never make the system require the use of a non-free component". 
> If you can't practically use a console emulator without resorting to a
> non-free image, then we're violating the social contract if it's in
> main.

I've always interprete

Re: How long is it acceptable to leave *undistributable* files in

[Francesco Poli]

On Mon, 21 Jun 2004 20:09:52 -0400 Raul Miller wrote:

> I will agree that you are not creating creative elements.
> 
> I see no reason to agree that you are not adding creative elements.
> You might very well be adding someone else's creative elements
> (depending on how your system is configured).

Ah, OK.
I meant that you are not adding creative elements *that are your own*.
But, you're right in saying that I didn't stated explicitly...

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgptrSRurEX7X.pgp
Description: PGP signature

Re: Visualboy Advance question.

[Francesco Poli]

On Tue, 22 Jun 2004 09:55:25 +1000 Matthew Palmer wrote:

> > Well, I thought that useless software is maybe not worth to
> > distribute at all. You seem to imply that a free, but useless
> > package must be placed in contrib rather than in main...
> 
> I implied nothing of the sort.

I'm sorry if I misunderstood you.

Just to avoid that this happen again in the future: where should a free
emulator with no free data to process (and thus useless in a
free-software only environment) go? I thought you said contrib...

> 
> > > Let me ask you this: if there was an image viewer, which only
> > > viewed one format of images, and there were no images out there in
> > > that format, would you want to see that in Debian?  What if there
> > > were images in that format, but in order to get them you'd have to
> > > break copyright law?
> > 
> > Cannot someone create some free image in that format in the near
> > future? Why should Debian wait for one such image to *be packaged*
> > before moving the viewer from contrib to main?
> 
> Please quote back to me the part where I said that such content needed
> to be packaged in order for us to consider it.  *Nowhere* did I make
> that claim. I'm only talking about whether such content exists *at*
> *all*.

Ah.
The thread started from a question by Dan Korostelev who asked why
visualboyadvance is in contrib.
The first answer was by Benjamin Cutler who said:

| The same reason fceu was in contrib until 'efp' was packaged, because 
| the requires at least one piece of software that's not in Debian in 
| order to be useful. Find a good free rom, package it, and VBA can move
| into main just like fceu did. zsnes remains in contrib for the same
| reason.

Note the "package it" part.

Since you didn't stated that, in your opinion, the packaging requirement
was to be dropped, I thought that you agreed with Benjamin and were just
taking extreme examples when you were talking about cases with *no* free
data at all.
I now realize that I was wrong in this assumption: I stand corrected.

> For most of these emulators, the only source of 'data' for
> them is ripping lock-in games from their cartridges.  Whilst that
> isn't necessarily breaking the law, it is DFSG-non-free, and if the
> emulator is significantly impaired without one of them, I believe it
> falls under SC#1.

Well, now I think I see what you mean (also in light of the below
clarification about what the Policy says about the Depends meaning...).

[...]
> > I've always interpreted the "require" as "depend on", in the sense
> > of the "Depends" field.
> > And I've always saw the dependences as not related to usefulness (a
> > program cannot depend on its input data).
> > 
> > Of course, I may be wrong...
> 
> I think you are.  To re-quote policy, "The Depends field should be
> used if the depended-on package is required for the depending package
> to provide a significant amount of functionality."  Usefulness is a
> function of functionality.  No functionality, no utility (usefulness).
>  For an emulator,
> no ROM, no functionality, no utility.  If there's no free ROM, then we
> go through the chain again, ending at "not in main".

So be it...

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpzIjzUITeov.pgp
Description: PGP signature

Re: Draft Summary: MPL is not DFSG free

[Francesco Poli]

On Wed, 23 Jun 2004 17:16:51 -0400  Lex Spoon wrote:

> First, the GPL states explicitly that you must "accept" the terms or
> that you do not get permission to do anything with the code.  Should
> we argue with a statement that the text says itself?

Wait, quoting from GPL#0:

| Activities other than copying, distribution and modification are not
| covered by this License; they are outside its scope.  The act of
| running the Program is not restricted

and from GPL#5:

|   5. You are not required to accept this License, since you have not
| signed it.  However, nothing else grants you permission to modify or
| distribute the Program or its derivative works.  These actions are
| prohibited by law if you do not accept this License.  Therefore, by
| modifying or distributing the Program (or any work based on the
| Program), you indicate your acceptance of this License to do so, and
| all its terms and conditions for copying, distributing or modifying
| the Program or works based on it.

Only modification or distribution requires license acceptance: you can
run the Program without accepting the GPL.

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgppk9GRjxpif.pgp
Description: PGP signature

Re: Summaries in general, was: Summary Update: MPL ...

[Francesco Poli]

On Wed, 23 Jun 2004 22:44:42 +0100 MJ Ray wrote:

> I see. Were you absent from the discussion earlier this year about 
> whether these summaries would be useful? Now that we've seen them in 
> action a few times, I feel that they are doing more harm than good 
> because they always seem to include "this is a free licence" or "this 
> is a non-free licence". Too much is being focused on these binary 
> distinctions and the interesting part is whether the ITP'd or P'd 
> software is free or non-free, really.

Well, it's true that the final judgement is on the freeness of software
/packages/ (that's the primary activity of debian-legal, isn't it?).

Anyway, IMHO, summaries of /license/ analyses are still useful.
Those summaries, when collected together, form a sort of vademecum for

a) someone willing to perform a first quick & rough freeness check on a
newly discovered piece of software (a more accurate review could be
needed, when someone actually willing to create a package is in doubt)

b) someone willing to choose a free license avoiding the ones which are
clearly non-free (those people would go and pick some OSI-approved or
FSF-approved license, if no such Debian list of licenses existed... and
realize that our criteria are different only when it's late)

c) the author(s) of a reviewed license willing to fix the issues that
debian-legal has with the license itself (without a list of license
summaries, they could never find out that their license has something to
be fixed)

d) someone willing to know the conclusions of debian-legal discussions
without having to actually follow *all* the long threads (debian-legal
is often quite verbose, and many people are not interested *that much*
in legal discussions, while they still need to know what has been
concluded)


Moreover the summaries are good references that avoid us to explain
again and again why license L is clearly non-free.



-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgp6h4PZvxzd2.pgp
Description: PGP signature

Re: Summaries in general, was: Summary Update: MPL ...

[Francesco Poli]

On Thu, 24 Jun 2004 14:01:36 +0100 MJ Ray wrote:

> On 2004-06-24 10:40:01 +0100 Francesco Poli <[EMAIL PROTECTED]> 
> wrote:
> 
> > Anyway, IMHO, summaries of /license/ analyses are still useful.
> 
> Oh, I agree, but I think we need to make a few changes to how they're 
> being done, now we've seen them in action for a while.
> 
> There seem to be two types of licence summary needed:
> 
> 1. for licence authors, which was the original suggestion.
[...]
> 2. for developers, which seems to be the aim of the /legal/licences/ 
> page.
[...]

So, IIUC, you propose that summaries should be split into two
`variants': in your opinion, every license should be summarized by one
document intended for the license authors (who may be willing to
improve their license) /and/ by another document intended for developers
(people who choose licenses for their software) and users (people who
choose software taking into account licensing issues).

Don't you feel that this would be too much effort to be done effectively
for a significant number of debian-legal discussions?
I mean: very few `monotype' summaries have been done so far and you
suggest to double the number of summaries per discussion...  :o

Wouldn't it be better if one single summary variant could be tuned to be
well-suited for both uses (improving licenses /and/ choosing a license
or checking if a piece of software is _probably_ free)?

> > Moreover the summaries are good references that avoid us to explain
> > again and again why license L is clearly non-free.
> 
>  warning - semi-rant follows. Skip down to conclusion if you are 
> new here.
> 
> Yes, I think you've found the exact reason. These "developer 
> summaries" should aim to be a sort of FAQ, not a checklist of 
> free/non-free judgements. debian-legal is ill-suited to be FSF++ or 
> OSI mark 2 and should not be turned into that. I have realised that 
> this list's members have a role to play, helping to make debian a 
> distributable free software operating system, so let's stick to that 
> role.[...]

The FAQ use is certainly /one/ use of the license list, but not the only
one, IMHO.

It's not about becoming FSF++ or OSI mark 2.
But, hey!, what can you do when you realize you don't quite agree with
FSF's or OSI's criteria and you feel that Debian's criteria are the ones
you agree best with?
It's unfortunate that these three organizations don't agree exactly on
freedom criteria, but it's a fact. Well, OSI doesn't even speak about
freedom, but that's another matter...
Given that the Debian project judges freedom with (slightly?) different
criteria, I would like that a sort of database of conclusions (based on
these criteria) is set up.
So that anyone who wants to know how a package licensed under a
particular license would *probably* be judged by debian-legal, can find
out without spending at least one day digging in the archives and
reading all the (often long and verbose) discussions.

Note that this `anyone' could be the license author, a developer who
consider choosing the license for his own software, a user who considers
to choose a piece of software released under the license, ...

>  skip to here
> 
> In conclusion: if some debian-legal contributors want to try to make 
> another org to approve and reject licences, please go do it somewhere 
> else. Let's improve the summaries so that they better serve our job. 
> I'm interested to know whether anyone agrees with the "two types" 
> idea.

Well, Debian should not approve and reject licenses, I agree.

But it should publish some sort of vademecum, even though it must be
stated clearly that there is *no warranty* that a package under a `good'
license will go in main for sure.
I mean: a package under a `good' license could be very well judged as
non-free and viceversa, but anyway it's still useful to provide a
guide... otherwise people could begin to think that having a package
included in Debian (main) is a sort of lottery.
I know that the DFSG are there just to explain Debian criteria and are
themselves /guidelines/.
But many people don't understand them very well or are not interested in
reading them carefully.
A database of their practical consequences would be helpful, IMHO.
Of course, again, with *no warranty*...


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpfOcJ97rsfu.pgp
Description: PGP signature

Re: Apple's APSL 2.0 " Debian Free Software Guidelines"-compliant?

[Francesco Poli]

On Fri, 25 Jun 2004 04:32:01 -0500 Ryan Rasmussen wrote:

> Is the following compliant with Debian's Free Software Guidelines?
> 
> ---
> APPLE PUBLIC SOURCE LICENSE
> Version 2.0 - August 6, 2003
> 
> Please read this License carefully before downloading this software.
> By downloading or using this software, you are agreeing to be bound by
> the terms of this License. If you do not or cannot agree to the terms
> of this License, please do not download or use the software.

That's not a good start: you need to agree with the license in order to
download and use the software.

> 
> 1. General; Definitions.
[snip some definitions]
> 1.4 "Externally Deploy" means: (a) to sublicense, distribute or
> otherwise make Covered Code available, directly or indirectly, to
> anyone other than You; and/or (b) to use Covered Code, alone or as
> part of a Larger Work, in any way to provide a service, including but
> not limited to delivery of content, through electronic communication
> with a client other than You.

Remember this for later...

[snip other definitions]
> 2. Permitted Uses; Conditions & Restrictions. Subject to the terms
> and conditions of this License, Apple hereby grants You, effective on
> the date You accept this License and download the Original Code, a
> world-wide, royalty-free, non-exclusive license, to the extent of
> Apple's Applicable Patent Rights and copyrights covering the Original
> Code, to do the following:
> 
> 2.1 Unmodified Code. You may use, reproduce, display, perform,
> internally distribute within Your organization, and Externally Deploy
> verbatim, unmodified copies of the Original Code, for commercial or
> non-commercial purposes, provided that in each instance:
> 
> (a) You must retain and reproduce in all copies of Original Code the
> copyright and other proprietary notices

"Proprietary notices"? What's a "proprietary notice"?

> and disclaimers of Apple as
> they appear in the Original Code, and keep intact all notices in the
> Original Code that refer to this License; and
> 
> (b) You must include a copy of this License with every copy of Source
> Code of Covered Code and documentation You distribute or Externally
> Deploy, and You may not offer or impose any terms on such Source Code
> that alter or restrict this License or the recipients' rights
> hereunder, except as permitted under Section 6.

Since "Externally Deploy" can also mean "to use the Covered Code, alone
or as part of a Larger Work, in any way to provide a service" (see above
definition), this clause could also mean I have to "include a copy of
this License" when I use the software to provide a service.
What is not clear to me is: where have I to include it?

> 
> 2.2 Modified Code. You may modify Covered Code and use, reproduce,
> display, perform, internally distribute within Your organization, and
> Externally Deploy Your Modifications and Covered Code, for commercial
> or non-commercial purposes, provided that in each instance You also
> meet all of these conditions:
> 
> (a) You must satisfy all the conditions of Section 2.1 with respect to
> the Source Code of the Covered Code;
> 
> (b) You must duplicate, to the extent it does not already exist, the
> notice in Exhibit A in each file of the Source Code of all Your
> Modifications, and cause the modified files to carry prominent notices
> stating that You changed the files and the date of any change; and
> 
> (c) If You Externally Deploy Your Modifications, You must make
> Source Code of all Your Externally Deployed Modifications either
> available to those to whom You have Externally Deployed Your
> Modifications, or publicly available.

Here it is... Forced distribution: if you use your modified version to
provide a service (see above definition of "Externally Deploy") you are
forced to distribute the source code of your modified version.
That seems much like one of the issues with OSL (Open Software License)
v2.0: this is a use restriction.
Quoting Jeremy Hankins:
 
: While the DFSG does not explicitly prohibit this, the consensus on
: debian-legal is that this is non-free.


> Source Code of Your Externally
> Deployed Modifications must be released under the terms set forth in
> this License, including the license grants set forth in Section 3
> below, for as long as you Externally Deploy the Covered Code or twelve
> (12) months from the date of initial External Deployment, whichever is
> longer. You should preferably distribute the Source Code of Your
> Externally Deployed Modifications electronically (e.g. download from a
> web site).
> 
> 2.3 Distribution of Executable Versions. In addition, if You
> Externally Deploy Covered Code (Original Code and/or Modifications) in
> object code, executable form only, You must include a prominent
> notice, in the code itself as well as in related documentation,
> stating that Source Code of the Covered Code is available under the
> terms of this L

Re: Apple's APSL 2.0 " Debian Free Software Guidelines"-compliant?

[Francesco Poli]

On Sat, 26 Jun 2004 22:23:55 +0100 Andrew Suffield wrote:

> > Choice of law clause. This is regarded as fine, IIRC.
> 
> Under the proviso that the law chosen is not in itself an issue.

Of course.
Anyway I agree with you that it's better to state it explicitly...


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpTzTEh1chwI.pgp
Description: PGP signature

Re: Apple's APSL 2.0 " Debian Free Software Guidelines"-compliant?

[Francesco Poli]

On Sun, 27 Jun 2004 07:08:11 +0100 Lewis Jardine wrote:

> 1a: Does applying a 'choice of language' clause to everyone make a 
> license non-free (or is it acceptable the same way a 'choice of law' 
> clause is)?

Perhaps it does not make a license non-free.

> 1b: Is a 'choice of language' clause a NOOP? (is the choice of
> language clause implicit in the fact that the contract is only
> available in one language?)

Well, the license is only available in one language, but the clause in
the APSL v2.0 talks about the License *and all related documents*.
I considered strange that this clause only applies to Quebec people.
If this choice of language is implicit, I would think there's no
need to include an explicit clause. Or, on the other end, it would be
fine to include an explicit clause that applies to everybody.

I mean: do I have, as an Italian-speaking italian person, some right
(granted to me by the APSL v2.0) that French-speaking Quebec people
don't have?
Which are these `related documents'? Could I request that they be
drafted in Italian? Do Quebec people surrender this right by accepting
the License?

> 2: Does applying a NOOP to a subset of people discriminate against
> them?

No, it doesn't discriminate, it's just a bit stupid.
But it has to be a real NOOP: a NOOP under any reasonable jurisdiction
one can think of.

> 3: Does applying a Free term to a subset of people discriminate
> against them?

I'm undecided about this.

My first feeling is that it would still be a discrimination.
Why do some people get more rights just by belonging to a group, or by
living in a particular place?

Imagine the following:

"You can redistribute this work and/or modify it under the terms of the
GNU General Public License, version 2, as published by the Free Software
Foundation.
As en exception, if you are a king, you can redistribute and/or modify
it under the terms of the X11 license."

This seems unfair.

But, OTOH, the copyright holder could distribute the work under the GPL
to one person and then distribute the same work under the X11 license to
a different person (and even distribute the same work under a
proprietary license to a third person).
This is perfectly fine (the copyright holder has the right to relicense
as she likes) and it wouldn't undermine the freeness of the
free-licensed versions.

So, I don't know...

What do you think?

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpoNeikoyO0t.pgp
Description: PGP signature

Re: Apple's APSL 2.0 " Debian Free Software Guidelines"-compliant?

[Francesco Poli]

On Sun, 27 Jun 2004 14:09:25 -0700 Josh Triplett wrote:

> See also section 12e of the DFSG FAQ at
> http://people.debian.org/~bap/dfsg-faq.html

Ah, I forgot that answer in the DFSG-FAQ...
So my interpretation of DFSG#5 was too extremist: I apologize for the
confusion.

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpyX1H9dqUTw.pgp
Description: PGP signature

Re: Summaries in general, was: Summary Update: MPL ...

[Francesco Poli]

On Tue, 29 Jun 2004 00:23:40 +0100 MJ Ray wrote:

> Interesting reply,

TNX

> but it seems to have missed my main point.

Ouch, I apologize for this... ;p

> 
> On 2004-06-26 18:30:40 +0100 Francesco Poli <[EMAIL PROTECTED]> 
> wrote:
> 
> > So, IIUC, you propose that summaries should be split into two
> > `variants'
> 
> This part is correct.
> 
> > in your opinion, every license should be summarized by one
> > document intended for the license authors (who may be willing to
> > improve their license) /and/ by another document intended for 
> > developers
> > (people who choose licenses for their software) and users (people
> > who choose software taking into account licensing issues).
> 
> No, I feel that if a licence author/user asks the list, the summariser
> writes a reply explaining any notable features of the licence in 
> question; while if a packager asks the list, the summariser writes a 
> reply explaining why a particular consensus was reached about the 
> package and that can be added to the web page, listing the licence 
> used and the consensus.

Ah, that is what you meant!
The summariser must implement a comand-line switch (--license or
--package) and generate a different type of output depending on how
he/she was invoked.   ;-)
HHOJ!  :)

Ok, seriously: I didn't understand what you actually propose.
Now, it's clear (even to me! ;-) and it sounds like a good proposal, if
summarisers can (and are willing to) get used to such a `double
system'...

[...]
> > It's not about becoming FSF++ or OSI mark 2.
> > But, hey!, what can you do when you realize you don't quite agree
> > with FSF's or OSI's criteria and you feel that Debian's criteria are
> > the ones
> > you agree best with?
> 
> Go set up your own licence court system using those criteria.

Well, those criteria are well known and understood by debian-legal
regulars.
I think that the only feasible way would be to exploit debian-legal
expertise.

Could you explain what do you feel would be wrong with a list of
licenses?
Do you think it would be misunderstood?

> 
> [...]
> > But it should publish some sort of vademecum, even though it must be
> 
> Vademecum is not a word dict or I know. It looks like a Roman place 
> name.

I'm sorry: I'm not a native English speaker.
I just took a Latin word that is used in Italian in the (apparently
wrong) belief that it was used in English, too...  :p

Actually, searching for that word in English dictionaries returns
nothing in most cases.
Though, *some* dictionaries do include it. An online example from:

http://wordreference.com/definition/vade+mecum.htm

vade mecum ['va:di'meikum]
noun  a handbook or other aid carried on the person for immediate use
when needed
[ETYMOLOGY: 17th Century: from Latin, literally: go with me]


What I meant was a sort of guide or reference that could help the reader
to find his/her way in the difficult world of licensing...

[...]
> Surely one could generate some lists of licences for the web site from
> existing packages, then reference debian-legal discussions?

This would probably do the job, at least partially.

> Or look at
> /usr/share/common-licenses on any Debian system for some obvious 
> candidates.

Well, these are the very minimum...  ;-)



-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpM4HsHmAWfL.pgp
Description: PGP signature

Re: Visualboy Advance question.

[Francesco Poli]

On Tue, 29 Jun 2004 23:22:12 +0100 Andrew Suffield wrote:

> Nintendo are the only ones I'm aware of that try to pretend console
> emulators aren't legal (sheer sophistry though; they claim outright
> "this thing is illegal because it can be used for illegal purposes").

This is what I call the "anti-screwdriver claim": following this line of
reasoning you could argue that a screwdriver is illegal, because it can
be used for illegal purposes (e.g. killing someone by thrusting the
screwdriver in his/her throat).

:-(

-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpEtth3FShpz.pgp
Description: PGP signature

Re: definitions of free

[Francesco Poli]

On Fri, 02 Jul 2004 17:57:57 -0400 Michael Poole wrote:

> The policy work involves the actual identification of freeness.
> DFSG-free is a (I believe strict) subset of OSI-free, and probably a
> superset of FSF-free.

I don't think that DFSG-free is a superset of FSF-free.
For non-programs there is no doubt, IMHO, (see GFDL, verbatim-copying,
...).
For programs, I don't know: I don't have the time now to scan the FSF
list of free program licenses and see if they include some that Debian
considers non-free.

[...]
> I see both the infrastructure and policy issues as being significant
> reasons to *not* identify packages as "FSF Free" or "OSI Free" or
> anything except "DFSG Free" (as in main vs non-free).

I agree: it would be too complicated.


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpHWy486qs0d.pgp
Description: PGP signature

Re: definitions of free

[Francesco Poli]

On Sat, 03 Jul 2004 23:55:23 +1000 Zenaan Harkness wrote:

> On Sat, 2004-07-03 at 10:42, Josh Triplett wrote:
> > Consider this sentence from the GNU Project's Free Software
> > Definition:
> > > It is also acceptable for the license to require that, if you have
> > > 
> > > distributed a modified version and a previous developer asks for a
> > > copy of it, you must send one.
> > 
> > Any software with such a requirement would be non-DFSG-free.
> 
> So that's not an appropriate restriction, at least according to the
> DFSG?

True: it's not an acceptable restriction, from the DFSG point of view.

> 
> What if it were just "must be emailed" - eg. if it were "must be
> posted" then the cost could be prohibitive for someone in the 3rd
> world right? But email, that should approach zero cost right?

I don't think it's a matter of cost, but rather a matter of being forced
to do something in case you previously performed a particular operation.
At least, it seems to me that the above requirement would fail the
desert island test[1].


[1] See  for details about
the desert island test.


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpNlqoxmBCEG.pgp
Description: PGP signature

Re: Visualboy Advance question.

[Francesco Poli]

On Wed, 7 Jul 2004 06:05:24 -0500 Branden Robinson wrote:

> On Sun, Jun 20, 2004 at 06:36:42PM +0200, Francesco Poli wrote:
> > I think that DFSG-free emulators should be in main as long as they
> > don't*depend* on non-free packages.  Usefulness is, IMHO, a
> > completely different matter.
> 
> I don't think we should be putting useless software in our archive,
> let alone in main.

Of course!

What I meant was: IMHO, usefulness should not be the parameter used to
decide if one package must end up in main or in contrib.

Uselessness can be a reason for completely dropping the package and
deciding to not distribute it. I would find it weird if uselessness were
a reason for moving the package from main to contrib...

That's all I meant.

-- 
 |  GnuPG Key ID = DD6DFCF4 | $ fortune
  Francesco  |Key fingerprint = | Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 |and commutes?
 | 31B5 78F4 279B DD6D FCF4 | A: A boolean grape.


pgpwYDR5vZzBp.pgp
Description: PGP signature

Re: Visualboy Advance question.

[Francesco Poli]

On Wed, 7 Jul 2004 14:00:47 -0400 Glenn Maynard wrote:

> I think there's a fairly significant difference between an emulator
> that will load and display an "insert ROM" image (eg. NES, SNES), and
> one that requires a specific non-free image in order to be able to do
> anything at all (eg. PSX BIOS images).
> 
> The first is analogous to requiring media; you see what the console
> displays if a cartridge isn't inserted.  The second is the same as
> requiring a non-free library for which there is no free replacement. 
> (I'm not aware of any free replacement PSX BIOSes.)

Agreed, fully.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpid1DbB2t4B.pgp
Description: PGP signature

Re: [Fwd: Licence for Icons]

[Francesco Poli]

On Wed, 07 Jul 2004 15:53:54 +0200 Stefan Völkel wrote:

> My understanding:
>   * All Data in a debian package (Source, Documentation, Art, ...)
> has to comply to the DFSG.

Correct: this will be more clearly stated by a new wording of the social
contract that has already been approved[1] and will come into effect
after the release of Sarge[2].

>   * Since the software is GPL the icon has to be packaged under a
> licence that is compatible with the GPL.

Correct, unless the packaging can be considered "mere aggregation" of
the icon and the rest of the package.

>   * FOOD's Licence is not GPL compatible

Correct. It doesn't look as a very clear license, but it seems to be
GPL-incompatible and *not* DFSG-free (it restricts use, it doesn't give
any permission to copy, distribute, or modify).

[1] http://www.debian.org/vote/2004/vote_003
[2] http://www.debian.org/vote/2004/vote_004

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpoNln7wyhoa.pgp
Description: PGP signature

Re: Apple's APSL 2.0 " Debian Free Software Guidelines"-compliant?

[Francesco Poli]

On Wed, 7 Jul 2004 07:09:09 -0500 Branden Robinson wrote:

> We should set a better example than those who overreach with their
> licenses and attempt to prohibit actions with no foundation for
> prohibition in copyright law.
> 
> We should not attempt to enforce that which we *can't* enforce.

Yes, now I'm convinced and I agree.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpTCEyyYX4tG.pgp
Description: PGP signature

Free Debian logos? [was: Re: GUADEC report]

[Francesco Poli]

On Wed, 07 Jul 2004 03:26:08 +0100 MJ Ray wrote:

> Maybe we 
> should show some examples of trademark terms we like? Maybe we could 
> even make the damn debian logo artwork into one?

I think that the Debian logo issue should really be worked out.
Having a Free OS with non-free logos is a sort of inconsistency: I'm not
comfortable with this situation.

IMHO, Debian logos should be DFSG-free. Their appropriate use should be
enforced via trademark laws, not copyright ones, if this is possible.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpSuyj7pCJqL.pgp
Description: PGP signature

Re: CeCILL license : Free Software License for french research

[Francesco Poli]

On Tue, 06 Jul 2004 16:19:57 -0700 Josh Triplett wrote:

> Lucas Nussbaum wrote:
[...]
> > Alex Hudson <[EMAIL PROTECTED]> was able to find the english
> > version of the license. It's here :
> > 
> > http://www.inria.fr/valorisation/logiciels/Licence.CeCILL-V1.US.pdf
> 
> For ease of quoting and commentary, here is a text version, converted
> using pdftotext along with some manual reformatting.

This is very much appreciated, TNX!

[...]
> FREE SOFTWARE LICENSING AGREEMENT CeCILL
> 
> Notice
[...]
> Version 1 of 06/21/2004
> 
> CeCILL License
> 
> PREAMBLE
[...]
> In this respect, the user's attention is drawn to the risks associated
> with loading, using, modifying and/or developing or reproducing the
> software by the user in light of its specific status of free software,
> that may mean that it is complicated to manipulate, and that also
> therefore means that it is reserved for developers and experienced
> professionals having in-depth IT knowledge.

I don't like this warning very much. It seems to strengthen the "free
software is for techies only" misconception: IMHO free software is for
anyone who is willing to appreciate it!
But anyway...

[...]
> This Agreement
> may be freely reproduced and published, provided it is not altered,
> and that no Articles are either added or removed herefrom.

So you cannot create derivative licenses based on this one.

[...]
> Version 1 of 06/21/2004
> 
> CeCILL License
> 
> Article 1 --­ DEFINITION
[...]
> Source Code: means all the Software's instructions and program lines
> to which access is required so as to modify the Software.

This looks like a weak definition of source code: what is *required* so
as to modify a program written in C?
Someone could argue that the C source files are not *required*, since
you can modify the program starting from the executable: you only have
to use a disassembler, a text editor and an assembler...
Therefore, someone could claim he/she is distributing "Source Code",
while he/she is actually passing on a binary only package...

[...]
> Article 3 --­ ACCEPTANCE
> 
> 3.1. The Licensee shall be deemed as having accepted the terms and
> conditions of this Agreement by the occurrence of the first of the
> following events:
> 
> - (i) loading the Software by any or all means, notably, by
> downloading from a remote server, or by loading from a physical
> medium;

So I accept the license as soon as I download the package.
Even if I haven't had *any* opportunity to read it in advance?   :-/

> 
> - (ii) the first time the Licensee exercises any of the rights granted
> hereunder.

This is pretty similar to the GPL, instead...

> 
> 3.2. One copy of the Agreement, containing a notice relating to the
> specific nature of the Software, to the limited warranty, and to the
> limitation to use by experienced users has been provided to the
> Licensee prior to its acceptance as set forth in Article 3.1
> hereinabove, and the Licensee hereby acknowledges that it is aware
> thereof.

This is not clear to me. Is it a requirement? "One copy of the Agreement
[...] has been provided to the Licensee [...]" seems a factual
statement, not a permission, nor a condition...
Does it mean that a distributor must make sure that recipients read the
license and acknowledge their awareness, *before* events (i) or (ii)
from Article 3.1 occur? 

> 4.2. TERM
>
> The Agreement shall remain in force during the whole legal term of
> protection of the economic rights over the Software.

Until copyright expires, right?

[...]
> Article 5 --­ SCOPE OF THE RIGHTS GRANTED
[...]
> Otherwise, the Licensor grants to the Licensee free of charge
> exploitation rights on the patents he holds on whole or part of the
> inventions implemented in the Software.

IIUC, this a copyright *and* patent license at the same time...

[...]
> 5.2. ENTITLEMENT TO MAKE CONTRIBUTIONS
> 
> The right to make Contributions includes the right to translate,
> adapt, arrange, or make any or all modification to the Software, and
> the right to reproduce the resulting Software.
> 
> The Licensee is authorized to make any or all Contribution to the
> Software provided that it explicitly mentions its name as the author
> of said Contribution and the date of the development thereof.

This seems similar to the GPL#2a, but it says explicitly that the
Contributor's name must be mentioned. Would a pseudonym suffice?
Does this pass the dissident test?

[...]
> 5.3.3. REDISTRIBUTION OF DYNAMIC MODULES
> 
> When the Licensee has developed a Dynamic Module, the terms and
> conditions hereof do not apply to said Dynamic Module, that may be
> distributed under a separate Licensing Agreement.

This seems somewhat similar to the LGPL (lack of) conditions for
linking.

> 
> 5.3.4. COMPATIBILITY WITH THE GPL LICENSE
> 
> In the event that the Modified or unmodified Software includes a code
> that is subject to the provisions of the GPL License, the Licensee is
> authorized to redistribute the whole under the GPL License.

Re: Visualboy Advance question.

[Francesco Poli]

On Mon, 12 Jul 2004 01:56:45 -0400 Nathanael Nerode wrote:

> > Why should Debian wait for one such image to *be packaged* before
> > moving the viewer from contrib to main?
> Oh, it doesn't need to be packaged.  If it is, however, it proves that
> such an image exists.

I'm glad to hear this: at least it is not necessary to have DFSG-free
data *packaged* in order to move a DFSG-free reader from contrib to
main. The mere existence of such data seems to be sufficient...

[...]
> > A real example: prboom is in contrib (at least in Woody). It's free
> > (under the GNU GPL license). It doesn't depend on non-free packages.
> > It can be installed without pulling in non-free packages and can
> > execute the FreeDoom IWADs that are free[1] (under a 3-clause BSD
> > license), but not packaged for Debian.
> 
> It seems like this belongs in main.  But why hasn't anyone packaged
> any of the free IWADs?

I really don't know.
Perhaps no DD has enough time to package two files that don't even need
any actual installation: you just have to download them and you are
ready to feed prboom. Very similar to downloading a DFSG-free mp3 audio
file and feeding mpg321: does a free-mp3-collection package exist? 


-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpChL5jhDqvV.pgp
Description: PGP signature

Re: Visualboy Advance question.

[Francesco Poli]

On Mon, 12 Jul 2004 01:46:08 -0400 Nathanael Nerode wrote:

> Debian main does contain MP3 recorders.  I think that is quite
> sufficient to render MP3 players useful with no non-free software; you
> can make your own MP3s.

Out of curiosity, is that different from the status of MPEG videos?
That is: are there MPEG or MPEG2 codecs in main that can generate an
MPEG animation starting from its frames in separate images?
I see that there are decoder libraries such as libmpeg...

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpZNXRjeiN9L.pgp
Description: PGP signature

Re: DRAFT: debian-legal summary of the QPL

[Francesco Poli]

On Sun, 11 Jul 2004 15:29:22 +0530 Mahesh T. Pai wrote:

> MJ Ray said on Sun, Jul 11, 2004 at 10:24:26AM +0100,:
[...]
>  > As you can read elsewhere, I am not convinced that debian-legal is 
>  > equipped or wise to try to analyse licences in abstract.
> 
> I'm afraid that  this list will have to do both  - analyse licenses in
> general,  and also scturinise  specific packages  when brought  to our
> notice.
> 
> In the specific case of  licenses which are outright non-free, we need
> to tell DDs / upstream that packages under a particular license cannot
> be in the archives.
> 
> Analysis  of specific packages  would be  necessary, when  issues like
> possible  patents, out  right license  violations,  dependency issues,
> license incompatibilities, etc. arise. 
> 
> To me,  this seems like  a two stage  process, we analyse  the license
> first, and the package later on.

I agree. Focussing on packages only would require too many analyses,
indeed.
We must also collect some sort of license database, so as we can say
"this package is solely under the L license, hence it cannot be
DFSG-free for sure".
Of course a number of packages have a less simple status (strange
license couplings, patents involved, additional requirements or
permissions, ...) and must be scrutinized on a case-by-case basis; but
many other packages would be a waste of time if we had to review the
same licenses again and again or to dig in the archives to recall if
some old package in a similar situation was judged free or not...

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpdR5iL1mica.pgp
Description: PGP signature

Re: Visualboy Advance question.

[Francesco Poli]

On Wed, 14 Jul 2004 04:24:14 -0500 Branden Robinson wrote:

> On Mon, Jul 12, 2004 at 10:34:56PM +0200, Francesco Poli wrote:
> > On Mon, 12 Jul 2004 01:56:45 -0400 Nathanael Nerode wrote:
> > > It seems like this belongs in main.  But why hasn't anyone
> > > packaged any of the free IWADs?
> > 
> > I really don't know.
> > Perhaps no DD has enough time to package two files that don't even
> > need any actual installation: [...]
>
> This can't be the case; witness the abuse of the people on this list
> when we *dared* to find the IETF's RFC license non-free[1].  Somehow,
> not shipping (some of) the RFCs in main made them inaccessible, and
> infeasible to access.

ROTFL!
Take into account that I am one who would like to have (almost)
everything packaged, as long as it's DFSG-free and useful.

But, oddly enough, I don't have the ability to *generate* DDs or to
*clone* existing ones...  ;-)
IANADD, either...  :p
If no DD is willing to package something, I cannot do anything more than
filing a RFP: I cannot force anyone, I'm not a dictator!  ;-)

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpmE32PtXhXR.pgp
Description: PGP signature

Re: DRAFT: debian-legal summary of the QPL

[Francesco Poli]

On Wed, 14 Jul 2004 01:37:46 +0100 MJ Ray wrote:

> > We must also collect some sort of license database, so as we can say
> > "this package is solely under the L license, hence it cannot be
> > DFSG-free for sure".
> 
> What does this do that a database of summaries indexed by licence 
> wouldn't?

Nothing more.
Actually a database of package review summaries indexed by license would
be perfectly fine, IMHO.

Anyway, sometimes we have a fairly large number of packages that include
L-licensed material: in that case it seems (at least to me) a bit weird
if we focused on *one* particular package, rather than on the license L
itself.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgp0cc6PhRmWi.pgp
Description: PGP signature

Re: DRAFT: debian-legal summary of the QPL

[Francesco Poli]

On Fri, 16 Jul 2004 16:07:11 -0400 Glenn Maynard wrote:

> A license that goes out of its way to
> make freedoms hard to assert (possibly with the goal of preventing
> them from actually being asserted) shouldn't be considered free.
> 
> Making freedom harder to assert is restricting freedom.

Indeed.
An example: modifying a binary executable through reverse engineering or
by disassembling/decompiling it is clearly possible, though difficult.
In order to exercise our freedom to modify free programs, we demand
access to source code.


-- 
 |  GnuPG Key ID = DD6DFCF4 | You're compiling a program
  Francesco  |Key fingerprint = | and, all of a sudden, boom!
 Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
 | 31B5 78F4 279B DD6D FCF4 | version 1.8.0


pgpD5JKTc9u84.pgp
Description: PGP signature

Re: DRAFT: debian-legal summary of the QPL

[Francesco Poli]

On Mon, 19 Jul 2004 19:53:37 +0200 Sven Luther wrote:

> Once you make a release, and you are afraid of loosing your changes,
> you send those changes upstream in prevention, and thus comply to the
> licence in advance.

That could be a good way to persuade upstream copyright holders to
switch to another license!   ;-)
Imagine the number of unsolicited (and possibily undesired) patches they
would receive for a popular software project...

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpDXTarNI3Uo.pgp
Description: PGP signature

Re: GPL-compatible, copyleft documentation license

[Francesco Poli]

On Mon, 19 Jul 2004 23:26:52 -0500 Branden Robinson wrote:

> > > If you're selling the hard copies then you can probably afford to
> > > include a CD.
> > 
> > I don't think there are affordable self-publishing deals that also
> > include CD production, but I could be wrong.
> 
> Keep in mind that it's not exactly challenging to represent (X)HTML
> and CSS on paper, given that they're plain text.

Wait, I would think that this cannot satisfy GPL#3a:

| 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;

Source code printed on paper would not be machine-readable (unless you
use an OCR, but that sounds like a weak argument...). Moreover paper
does not seem to be a "medium customarily used for software
interchange".

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.



pgp90UW5eeifh.pgp
Description: PGP signature

Re: DRAFT: debian-legal summary of the QPL

[Francesco Poli]

On Thu, 22 Jul 2004 01:06:25 -0700 Steve Langasek wrote:

> On Thu, Jul 22, 2004 at 12:56:50AM -0400, Walter Landry wrote:
> > Matthew Garrett <[EMAIL PROTECTED]> wrote:
> > > Walter Landry <[EMAIL PROTECTED]> wrote:
> > > >Matthew Garrett <[EMAIL PROTECTED]> wrote:
> > > >> Under the GPL, the government can just pass a law requiring
> > > >> that all distributed source code be provided to the government.
[...]
> > In that country, it would not be free.
> 
> I disagree.  This is not relevant to the freedom of the license,
> because it's an additional restriction imposed by a *third party* (in
> this case, a government), and not something that can be fixed by
> additional permission grants from the licensor.

Indeed. For a license to be free, it is necessary that the *license*
grants all the important rights and does not take away any right.
If another entity nukes one important right, it's not the license's
fault...

Consider a totalitarian regime in which anyone can be put in prison with
no reason: would free licenses become non-free in this country?
I don't think so.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpr6l7qPV8fD.pgp
Description: PGP signature

Re: GPL-compatible, copyleft documentation license

[Francesco Poli]

On Tue, 27 Jul 2004 07:32:52 -0400 Brian Thomas Sniffen wrote:

> Glenn Maynard <[EMAIL PROTECTED]> writes:
[...]
> > (Whether or not this is an issue with using the GPL for manuals, I
> > have no idea.)
> 
> It isn't a big deal: you can just stick a CD with the source of the
> manual in the back (or, if you're big enough, put a written offer in).
> Technical manuals do this increasingly often *anyway*.  And it's
> really the only way to give recipients of the manual freedom with
> respect to it.

Agreed. You cannot fully exercise fundamental freedoms with only source
code printed on paper.
And the GNU GPL *is* appliable to manuals and other non-programs.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.



pgpH9ni78FKfa.pgp
Description: PGP signature

Re: ocaml, QPL and the DFSG: New ocaml licence proposal.

[Francesco Poli]

On Thu, 29 Jul 2004 05:53:14 -0400 (EDT) Walter Landry wrote:

> Sven Luther <[EMAIL PROTECTED]> wrote:
> > So this solves most of the issues, and we need to go through the QPL
> > 3b again, but upstream feels it is a reasonable clause, and would
> > like to keep it.
> 
> I'm sure that anyone would love to have that kind of term in a
> license.  It still feels non-free to me.

Agreed: I'm another one who feels that QPL 3b is non-free.

It forces me to grant to the initial developer more rights to my code
than he/she granted me to his/her own code.

I feel that this does not satisfy DFSG 3, because I'm allowed to
distribute my modifications "under the same terms as the license of the
original software" to anyone I like *but* to the initial developer.
The initial developer automatically gets a more permissive license grant
for my modifications...

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpqJL2GOgX8g.pgp
Description: PGP signature

Re: ocaml, QPL and the DFSG: New ocaml licence proposal.

[Francesco Poli]

On Sun, 1 Aug 2004 09:03:31 +0200 Sven Luther wrote:

> > It forces me to grant to the initial developer more rights to my
> > code than he/she granted me to his/her own code.
> 
> Easy, you place your patch under the QPL, and then if upstream applies
> the patch, he clearly makes a modification of your work, and gives you
> the same right back with regard of the original software, so it is not
> non-free, but not really what upstream expected in the first place.

I don't read QPL 3b that way.

| 3. You may make modifications to the Software and distribute your
| modifications, in a form that is separate from the Software, such as
| patches. The following restrictions apply to modifications:
[...]
|   b. When modifications to the Software are released under this
|   license, a non-exclusive royalty-free right is granted to the
|   initial developer of the Software to distribute your
|   modification in future versions of the Software provided such
|   versions remain available under these terms in addition to any
|   other license(s) of the initial developer.

When I release my modification to the Software under the QPL, the
initial developer (of the Original Software) automatically gets more
rights than anybody else: he/she gets a right that goes beyond the ones
granted by the QPL to mere mortals. Actually the initial developer gets
the right to take my modification and relicense it under *any* other
license (as long as the modification is applied to the Original Software
and the result is also available under the QPL).

He/She does not need any other permission to do so: he/she is not
subject to the QPL license applied to my modification, because he/she
automatically gets a more permissive grant from me on the basis of the
QPL license applied to the Original Software.
And I cannot refuse to grant him/her this right (as long as I want to
release my modification under the QPL): if I refuse, I'm violating the
QPL license. In the meanwhile I have no such right with respect to the
Original Software.

Again: IMHO this does not satisfy DFSG 3.


-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpNiPM6Eu4B6.pgp
Description: PGP signature

Re: Free non-software stuff and what does it mean. [was Re: General Resolution: Force AMD64 into Sarge]

[Francesco Poli]

On Sat, 24 Jul 2004 05:31:18 -0400 Glenn Maynard wrote:

> The question, for me, is whether starting to require this source is
> useful for Debian, balanced against the cost of throwing out stuff
> that clearly fails it, and the added maintenance costs (maintainers
> having to track down sources).

Why not?
Suppose I want to modify a DFSG-free 2D game and I don't like the look
of a PNG (or JPEG) sprite.
I must have the preferred form for modification in order to fully
exercise my freedom to adapt the game to my needs...


P.S.: I apologize for not setting the Mail-Followup-To header correctly.
I didn't manage to find out how to do it (even manually) with Sylpheed:
if someone knows, I'd welcome suggestions (in private). TIA.
I'm a debian-legal subscriber, so no need to Cc: me, as long as
debian-legal itself is among the recipients.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.



pgp1DGbcqBvTv.pgp
Description: PGP signature

Re: ocaml, QPL and the DFSG: New ocaml licence proposal.

[Francesco Poli]

On Mon, 2 Aug 2004 09:23:11 +0200 Sven Luther wrote:

> Now, what would be your ground for the original author not respecting
> the QPL of the patch ?

I think that the initial developer does not have to comply with the QPL
of the patch, because he/she already has the rights he/she needs (the
right to integrate the patch in future versions of the Original Software
and the right to distribute them under any other license as long as they
remain available under the QPL too).

> He is allowed to apply its proprietary licence,
> as long as he also adds the patch to the QPLed version, thus allowing
> you the same rigths under the QPL back ?

Let's look at the QPL license under which my hypothetical patch is
distributed.
Who is the "initial developer" in this instance of the QPL license?
Is it me? I don't think so: I'm not the initial developer of the
Software, I'm just a contributor, because I created a derived work of
the Software.
Hence (if it's true that I'm *not* the initial developer, not even for
the QPL applied to the patch), I don't get any special right from
further modifiers that must comply with the QPL: the true initial
developer gets it!

If this is correct, I don't get any special right from the initial
developer, even if he/she must comply with the QPL of the patch...


[...]
> > Again: IMHO this does not satisfy DFSG 3.
> 
> The DFSG #3 says :
> 
>   The license must allow modifications and derived works, and must
>   allow them to be distributed under the same terms as the license of
>   the original software.
> 
> The point at hand is : "to be distributed under the same terms as the
> license of the original software.".
> 
> Since nothing is stopping you from releasing your patches under the
> QPL, i don't see what the problem is.

My reasoning is: I modify a QPL'd software and thus create a patch.
I want to distribute the patch under the QPL to the initial developer.
DFSG #3 says that I must be allowed to do this, otherwise the QPL'd
software is not DFSG-free.
But I'm not allowed to, because the QPL forces me to grant additional
permissions to the initial developer.

As a consequence, the QPL'd software is not DFSG-free.



P.S.: no need to Cc me as I'm a debian-legal subscriber...


-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.



pgpVMeQzcTseW.pgp
Description: PGP signature

Re: ocaml, QPL and the DFSG: New ocaml licence proposal.

[Francesco Poli]

On Tue, 3 Aug 2004 21:24:23 +1000 Matthew Palmer wrote:

> As to the loophole: 3b says "When modifications to the Software *are
> released under this license*, a non-exclusive royalty-free right is
> granted to the initial developer" (emphasis mine).  So if the changes
> are released under a different licence, upstream is screwed --
> especially if it's a QPL-incompatible licence (such as the GPL).  The
> only circumstance I can find where a change must be released under the
> QPL is when binary distribution takes place.  If I only distribute my
> patch, upstream has no special right to my code.

Yes, of course.
I think you are quite right.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpiAMZbGHnr2.pgp
Description: PGP signature

Re: Free non-software stuff and what does it mean. [was Re: General Resolution: Force AMD64 into Sarge]

[Francesco Poli]

On Mon, 2 Aug 2004 16:26:12 -0400 Glenn Maynard wrote:

> Sure, I understand the benefit. [...]
> There's a cost, too, though.  Source for images is often very big (eg.
> layered PSDs).  Source for sounds is often huge, [...]
> (That's a separate question from "does the SC currently mandate it?";
> I think that a strict reading of the post-2004-003, pre-004 SC may,
> but I'm not arguing SC interpretation here.)

Ah, I'm sorry, I thought you were arguing about freedom and its
requirements.

You were instead talking about practical (and rather reasonable)
concerns for archive capacity and the like.
Well, I would say: it's the price of freedom...  :p

> 
> > P.S.: I apologize for not setting the Mail-Followup-To header
> > correctly. I didn't manage to find out how to do it (even manually)
> > with Sylpheed: if someone knows, I'd welcome suggestions (in
> > private). TIA. I'm a debian-legal subscriber, so no need to Cc: me,
> > as long as debian-legal itself is among the recipients.
> 
> You don't need to set MFT if you don't want a CC on Debian lists; not
> doing so is list policy default.  You only need to worry about setting
> it if you do.

First of all, TNX for the explanation.
Actually, being a debian-legal subscriber I don't usually set any
Mail-Followup-To as I prefer when people reply to the list only (unless
they want to send me a private message: PGP/MIME encryption and digital
signature are welcome in that case!).
This time, however, I thought that I should keep the Mail-Followup-To:
debian-devel@lists.debian.org, debian-legal@lists.debian.org already set
in the thread...
Correct me if I'm wrong.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgptwZxjptNof.pgp
Description: PGP signature

Re: Free non-software stuff and what does it mean. [was Re: General Resolution: Force AMD64 into Sarge]

[Francesco Poli]

On Tue, 3 Aug 2004 19:48:38 -0400 Glenn Maynard wrote:

> On Tue, Aug 03, 2004 at 11:00:17PM +0200, Francesco Poli wrote:
> > This time, however, I thought that I should keep the
> > Mail-Followup-To: debian-devel@lists.debian.org,
> > debian-legal@lists.debian.org already set in the thread...
> > Correct me if I'm wrong.
> 
> I'm not sure exactly how it should be set in this case; because Mutt
> just does the right thing, I've never had to worry about it.

Well, I was trying (and now I succeeded, thanks to Andrew Saunders that
explained me, in private, how to do that!) to reproduce manually the
Right(TM) behaviour of Mutt, that is (IIUC): when replying to a message
that has a Mail-Followup-To header, put those addresses in the To header
*and* in the Mail-Followup-To header.

But now, we are going rather OT...
We'd better continue in private, if there's something else to add!

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpJPLy2QwaNo.pgp
Description: PGP signature

Re: acceptable copyright?

[Francesco Poli]

On Wed, 04 Aug 2004 14:16:47 +0200 Jörgen Hägg wrote:

> This is the copyright I found in a program I'd like to package.
> Is it acceptable for 'main' or should I ask for a better copyright?
[...]
> And in COPYING:
> 
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions
> are met:
> 
> 1. Redistributions of source code must retain the above copyright
>notice, this list of conditions and the following disclaimer.
> 2. Redistributions in binary form must reproduce the above copyright
>notice, this list of conditions and the following disclaimer in the
>documentation and/or other materials provided with the
>distribution.
> 
> THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
> IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
> INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
> (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
> SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
> STRICT LIABILITY, OR TORT(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
> IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.


It looks like a 2-clause BSD license.
It's perfectly fine and suitable for main. 


-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.



pgpQdRspg1kuI.pgp
Description: PGP signature

Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.

[Francesco Poli]

On Thu, 12 Aug 2004 10:35:03 -0700 Josh Triplett wrote:

> I strongly disagree that such clauses are non-free.

I still consider QPL 3b as non-free: I'm not allowed to redistribute
modifications under the same terms of the original software. At least
not to the initial developer. This, IMHO, violates DFSG 3.

See my previous message
Message-Id: <[EMAIL PROTECTED]>
(http://lists.debian.org/debian-legal/2004/07/msg01736.html)
and the subthread that followed.

Brian Thomas Sniffen is following the same line of reasoning now in this
thread.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpHssmo1fzle.pgp
Description: PGP signature

Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.

[Francesco Poli]

On Fri, 20 Aug 2004 04:51:36 -0400 Glenn Maynard wrote:

> Hence, they can't additionally release it under the GPL, because the
> software retains a restriction "must be additionally available under
> the terms of the QPL", and the GPL forbids that restriction.  They
> couldn't quite release it under the MIT license, because it would
> actually be under the MIT license with a rider that it must also be
> available under the QPL's terms (which would still render it GPL-
> incompatible).
>
> So, it doesn't actually allow the initial author to
> take the work proprietary, unless I'm reading QPL#3b incorrectly; if
> you think I am, I'd appreciate an explanation.

I don't think QPL#3b requires the other licenses to carry an attached
additional restriction such as "must be additionally available under the
terms of the QPL". The recipients of the differently licensed version
have the rights granted by that different license, nothing more, nothing
less.
IMHO, if the initial developer incorporates contributed patches and
releases the whole under the QPL and, separately, under the 2-clause BSD
to his/her best friend, then the latter receives a BSD-licensed software
(with no added restrictions) and can fork it as he/she likes.

The problem, as you pointed out, as many others have been pointing out
(including me...), is that the initial developer can relicense J. Random
Hacker's modifications without being compelled to comply with their QPL
license (because the initial developer has been granted a more
permissive license). In the meanwhile J. Random Hacker has no special
rights to the initial developer's code (no rights beyond the ones
granted by the QPL).
This means that J. Random Hacker cannot distribute his modifications
under the same terms as the license of the original software, at least
not to the initial developer. This fails DFSG#3.

> I believe this is non-free because it requires me to grant rights to
> my modifications that I did not receive for the original work, which I
> believe fails DFSG#3--I can't redistribute under the same terms as the
> license of the original software.

Indeed.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgp364nsbEzRB.pgp
Description: PGP signature

Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.

[Francesco Poli]

On Sat, 21 Aug 2004 18:58:20 -0400 Glenn Maynard wrote:

> On Sat, Aug 21, 2004 at 10:54:42PM +0200, Francesco Poli wrote:
> > I don't think QPL#3b requires the other licenses to carry an
> > attached additional restriction such as "must be additionally
> > available under the terms of the QPL". The recipients of the
> > differently licensed version have the rights granted by that
> > different license, nothing more, nothing less.
> 
> I don't see how "provided" could mean anything else, in "provided such
> versions remain available under these terms in addition to ...".
> 
> If you, the initial author, release the work under the BSD license in
> addition to the QPL, and I then take the code, modify it and place my
> modifications under the GPL, then the Software is no longer available
> under these [QPL] terms.  This "provided" has been violated.  I'm not
> allowed to do that, and you (the initial author) don't have permission
> to give me permission to do so--the above "provided" explicitly denies
> you that.
> 
> Where am I wrong?

Well, maybe you are not wrong... In that case, I'm the one who is wrong.
 ;)

My reasoning was like the following: who is bound by the clause
"provided..."? The initial developer. Not the recipient of the
differently licensed version.
In other words, I thought that QPL#3b requires the modifier to give
permission to the initial developer to incorporate his/her modification
to future versions of the software and relicense the results as he/she
likes, as long as the same is also available under the QPL. But this "as
he/she likes" means under *any* license, a proprietary one for instance,
but also a free one, even the GNU GPL, or the X11 license, with no
additional restrictions for further recipients.
It says "in addition to any other license(s) of the initial developer".

I felt that while the initial developer is bound to release the same
version under the QPL also, he/she is allowed to give to others
permission to modify the differently licensed version with no "must be
additionally available under the terms of the QPL" restriction.

Of course, I suspect TrollTech (and other copyright holders that use the
QPL license) didn't think about such a possibility. That's because the
usual choice for "any other license(s)" is one or more proprietary
license(s) that do(es) not allow modification or redistribution.

But I feel the language of the QPL is not clear enough to deny the
initial developer the possibility of giving to others the above
permission.

But of course I may be wrong.
IANAL.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpGeWTyachNU.pgp
Description: PGP signature

Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.

[Francesco Poli]

On Mon, 23 Aug 2004 09:34:00 +0200 Sven Luther wrote:

> Notice that in the ocaml case, it is well possible that the additional
> licences is more near the BSD, since it allows for third party to make
> modifications under a more permisive licence than the LGPL/QPL duo.
>
> So, would a wording where QPL 3b is modified to say that it may be
> relicenced under the QPL and under a more permisive licence be
> acceptable ?

IMHO, it would not improve the modified-QPL freeness.

It however would really improve the ocaml freeness, if ocaml itself were
dual-licensed under a 2-clause BSD license (or X11 or Expat or...)
besides the QPL. In that case Debian could choose to distribute
under the 2-clause BSD license (or X11 or...) and everyone could be
happy...

Anyway I think that a QPL/BSD dual license would be equivalent to a BSD
license.
So, if INRIA would like to go in this direction, I would suggest to drop
the QPL entirely and switch to a 2-clause BSD license...


P.S.: please do not reply to me directly, as I'm a list subscriber.
I would prefer you reply to the list only. Thanks.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgp3fNnubA4VF.pgp
Description: PGP signature

Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.

[Francesco Poli]

On Sun, 22 Aug 2004 16:37:56 -0400 Glenn Maynard wrote:

> He doesn't have that permission himself.  How can he possibly give it
> to others?  If he can't release just under the GPL, how can he allow
> me to?

Well, it says "any other license(s)", not "any other license(s) with the
additional clause that further recipients must keep further derivative
works available under the QPL also".

I agree with you that it's weird that the initial developer is legally
bound to do something, but is allowed to give others the permission to
do otherwise.

Anyway, the initial developer got the power to relicense a patch when
applied to future versions of the software in exchange of the promise to
keep this future versions available under the QPL also. Further
recipients of the differently licensed versions don't get any special
relicensing power: why should they have additional restrictions beyond
what their license says?
Because the different license says so, you claim.
But then how can it be "any other license" if it must absolutely include
one specified clause?


-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpDtAVhEN3mA.pgp
Description: PGP signature

Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.

[Francesco Poli]

On Mon, 23 Aug 2004 19:11:57 -0400 Glenn Maynard wrote:

> Anyway, we aren't going anywhere.  I don't think this has any real
> impact on my opinion of the QPL, anyway, though it may to others. 

Nor on mine...
I still think that QPL#3b is non-free.
Add the other issues that have larger consensus... and you get the
picture!

> It's clear this is a badly written clause, at least.

Indeed.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpibNtQgr9xf.pgp
Description: PGP signature

Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.

[Francesco Poli]

On Tue, 24 Aug 2004 10:07:21 -0400 Brian Thomas Sniffen wrote:

> Francesco, I think you're misinterpreting Sven's intent with the "more
> permissive" license.  The idea is not that you or I would ever see
> such a thing; rather, INRIA sells licenses to Ocaml.  You pay them
> $10k or so, and you get a permissive license.  If you don't pay, you
> get the QPL.

Yes, this would be possible in Sven's hypothesis, I know.
And I knew, when I replied.

Actually, my reply to Sven's hypothesis was my first sentence:

| IMHO, it would not improve the modified-QPL freeness.

The rest was simply *another* hypothesis, the dual-licensing one:

| It however would really improve the ocaml freeness, if ocaml itself
| were dual-licensed under a 2-clause BSD license [...]

Did I clarify?

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpwNas8eruND.pgp
Description: PGP signature

Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.

[Francesco Poli]

On Tue, 24 Aug 2004 11:07:36 -0400 Brian Thomas Sniffen wrote:

> > Why not ? It would say : upstream can redistribute under the QPL and
> > any other licence that is considered DFSG-Free, including the BSD
> > licence.
> >
> > What do you find non-free in this ? 
> 
> It compels me to grant upstream a right which upstream will not grant
> me.  If that were symmetric, I would not object to this under DFSG 3.

Indeed.
It would still fail DFSG 3 and that's exactly what I was thinking about.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpZUElUtISTu.pgp
Description: PGP signature

cdrecord: weird GPL interpretation

[Francesco Poli]

Hi all,
in cdrtools-2.01a38 I found the following weird GPL interpretation.
I wonder if this is considered acceptable for main (I would say that
this is non-free). I don't know whether cdrecord links with (or is
otherwise a derivative work of) other GPL'd software (whose copyright is
held by other people): in that case I would say that this is even
undistributable...  :(

What do you think about this?
There already is a Debian BTS bug report
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265546) about this
issue (it was filed when it was even worse, it seems...), but it says
it's resoved with version 2.01a38. I wonder if you agree...


NOTE: I am Cc:ing the the package maintainer (Joerg Jaspert) and the
bug-report filer (Andreas Metzler).
I don't know if they would like to be Mail-Followup:ed...


Issue description follows:

 -=-=-=-= cdrecord/LICENSE =-=-=-=-

This software is under GPL but you should read the following
clarifications:


-   You may not modify certain copyright messages in cdrecord.c

See cdrecord.c for further information.


-   You may (with a few exceptions) not modify the location of the
configuration file /etc/default/cdrecord.

See defaults.c for further information.

Please note that this is just the way I interpret the GPL and as this
is my software, users should follow my interpretation of the GPL and not
use their own different interpretations.


 -=-=-=-= cdrecord/cdrecord.c (sorry for linewrapping) =-=-=-=-

[...]
/*
 * 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 § 2 subclause c)
 *
 * If you modify cdrecord you need to include additional version
 * printing code that:
 *
 *  -   Clearly states that the current version is an
 *  inofficial (modified) version and thus may have bugs
 *  that are not present in the original.
 *
 *  -   Print your support e-mail address and tell people that
 *  you will do complete support for this version of
 *  cdrecord.
 *
 *  Or clearly state that there is absolutely no support
 *  for the modified version you did create.
 *
 *  -   Tell the users not to ask the original author for
 *  help.
 *
 * This limitation definitely also applies when you use any other
 * cdrecord release together with libscg-0.6 or later, or when you
 * use any amount of code from cdrecord-1.11a17 or later.
 * In fact, it applies to any version of cdrecord, see also
 * GPL Preamble, subsection 6.
 *
 * I am sorry for the inconvenience but I am forced to do this because
 * some people create inofficial branches. These branches create
 * problems but the initiators do not give support and thus cause the
 * development of the official cdrecord versions to slow down because
 * I am loaded with unneeded work.
 *
 * Please note that this is a memorandum on how I interpret the GPL.
 * If you use/modify/redistribute cdrecord, you need to accept it
 * this way.
 *
 *
 * The above statement is void if there has been neither a new version
 * of cdrecord nor a new version of star from the original author
 * within more then a year.
 */

/*
 * Ugly, but Linux incude files violate POSIX and #define printf
 * so we cannot include the #ifdef inside the printf() arg list.
 */
#   define  PRODVD_TITLE""
#ifdef  CLONE_WRITE
#   define  CLONE_TITLE "-Clone"
#else
#   define  CLONE_TITLE ""
#endif
if ((flags & F_MSINFO) == 0 || lverbose || flags & F_VERSION) {
printf("Cdrecord%s%s %s (%s-%s-%s) Copyright (C) 1995-2004 Jörg
Schilling\n",
PRODVD_TITLE,
CLONE_TITLE,
cdr_version,
HOST_CPU, 
HOST_VENDOR, HOST_OS);

#if defined(SOURCE_MODIFIED) || !defined(IS_SCHILY_XCONFIG)
#define INSERT_YOUR_EMAIL_ADDRESS_HERE
#define NO_SUPPORT  0
printf("NOTE: this version of cdrecord is an inofficial
(modified) release of cdrecord\n");
printf("  and thus may have bugs that are not present in the
original version.\n");
#if NO_SUPPORT
printf("  The author of the modifications decided not to
provide a support e-mail\n");
printf("  address so there is absolutely no support for t

Re: cdrecord: weird GPL interpretation

[Francesco Poli]

On Fri, 3 Sep 2004 09:40:49 + (UTC) Andreas Metzler wrote:

[...]
> Hello,
> This was about the recent change of license in a36 that was widely
> covered in the news, e.g. lwn or heise.de
> http://weblogs.mozillazine.org/gerv/archives/006193.html
> 
> We (cdrools Debian maintainers) were in indeed private contact with
> Joerg about this and successfully managed to resolve this, a38 undid
> the newly introduced non-freeness issue, the code in question
> (linuxcheck()) is not encumbered by a specific license anymore, it may
> be removed like anything else.
> 
> This is resolved and completely orthogonal to this thread, so please
> ignore it.

So, IIUC, debian bug #265546
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265546) is related to
linuxcheck() only.

I instead thought that it was related to the whole bunch of weird
restrictions that go well beyond the GPL license, and that it was filed
when the non-freeness was even worse and then marked resolved when one
of the issues went away.
So, since I noticed that many issues were still there, I wondered if the
bug should be reopened.

I apologize for the misunderstanding.


Well, if I *now* understand the situation correctly, we have version
2.01a38 with *another* set of non-freeness and non-distributability
issues to deal with...
So probably a different bug should be filed, at least if sid already
includes version 2.01a38...


-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpCNLDB19B2G.pgp
Description: PGP signature

Re: Free Art License

[Francesco Poli]

On Sat, 11 Sep 2004 01:02:40 +0200 Kai Blin wrote:

> I wanted a review of the license as we're considering switching the
> package sear-media and another media package that'll follow when our
> DD finishes the package to this license, the GPL being a bit unclear
> when used for artwork.

I would say "please, don't do that".
The Free Art License could even be judged DFSG-free (we don't know by
now, as there is not yet a clear consensus...), but it doesn't seem to
be a well worded license.
And it's clearly a GPL-incompatible license (being a copyleft license
that is not equivalent to the GNU GPL...).

Switching from the GPL to a GPL-incompatible license would probably
cause major problems to any other GPL-compatible work that would like to
reuse your work (in any way that creates a derivative work).
Creating barriers across the free software world is not a good practice
-- at least, not one I would recommend...


I would suggest sticking to the GNU GPL.
I cannot see what is not clear with the GPL applied to artwork...

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpNPD4Oh7KvB.pgp
Description: PGP signature

What if source is really big? [was: Re: Free Art License]

[Francesco Poli]

On Sun, 12 Sep 2004 14:53:35 +0200 Kai Blin wrote:

> > I would suggest sticking to the GNU GPL.
> > I cannot see what is not clear with the GPL applied to artwork...
> 
> Well, Section 3 of the GPL allows you to copy and distribute the work
> if you also distribute the source (or make it accesible, or the like).

Yes, briefly speaking...

> 
> The source is defined as "The source code for a work means the
> preferred form of the work for making modifications to it."

Definetely.

> 
> It's not always clear what the preferred form of modification would be
> for a piece of media.

I think the right question you should ask yourself is "which form would
I use, should I make some modifications to it?".

Of course I assume that the person who asks himself/herself this
question is reasonably skilled in the involved field (image manipulation
or digital movie editing or computer programming or ...): for instance
someone who doesn't understand C++ cannot claim that unobfuscated C++ is
not the preferred form for making modifications to a program written in
C++...

OTOH, there are cases in which the preferred form for modifications
changes over time: suppose the above program is manually translated from
C++ into Python and further modified. At that point, the source code is
in Python.

> For a picture composed of multiple layers, it's
> a version with all the layers intact and seperate, but often, in the
> process of working on a multi-layer image, the artist will combine a
> set of layers to save ram and speed up the processing. Is that image
> still a source?

If I ask that artist to make some modifications to the new image,
would he/she restart from the totally-separated-layer form or rather
from the partially-flattened form?
That is the test, IMHO.

> 
> Now, movies get even more tricky. A short movie clip often requires
> hours of raw material. Does everyone who wants to distribute the movie
> need to have gigabytes and gigabytes of raw movie scenes available?

That is indeed an issue.
Is source still source when it grows beyond the imaginable?
But that issue is not GPL-specific, IMHO.
Are you really providing the freedoms that we value, without providing
the preferred form for modification?

> 
> I'll gladly be convinced that I'm misinterpreting the GPL here. If
> this thread is off-topic for this channel, please reply to me
> personally.

There have already been some discussions about this issue on this list,
so I think that it's not OT.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpkVRpuXZlqh.pgp
Description: PGP signature

FIGlet: how to file an appropriate bug report?

[Francesco Poli]

Hi all!  :)

I found a package in main that does not seem to comply with the DFSG.
Moreover the copyright file seems inaccurate.

I'm seeking help, as I would like to file a bugreport in the Right
way(TM).
What should I say in the bugreport?



The package I'm talking about is figlet: a small program to make ASCII
banners and the like...

Looking at the contents of the orig.tar.gz, I found a file named
"Artistic-license.txt" that contains a license similar, but not
identical to /usr/share/common-licenses/Artistic
I didn't have the time to revise the DFSG-freeness of this license yet,
but the fact is that copyright notices in files seem to be inconsistent.

Actually file figlet.c states that the whole package is under this
`Artistic license':

/

  FIGlet Copyright 1991, 1993, 1994 Glenn Chappell and Ian Chai
  FIGlet Copyright 1996, 1997, 1998, 1999, 2000, 2001 John Cowan
  FIGlet Copyright 2002 Christiaan Keet
  Portions written by Paul Burton and Christiaan Keet
  Internet: <[EMAIL PROTECTED]>
  FIGlet, along with the various FIGlet fonts and documentation, is
copyrighted under the provisions of the Artistic License (as listed
in the file "Artistic-license.txt" which is included in this package.
/


At the same time other files seem to state different things...
See the following.


Makefile:
copyright notices with no permissions granted

# Makefile for figlet version 2.2.1 (13 July 2002) 
# adapted from Makefile for figlet version 2.2 (15 Oct 1996)
# Copyright 1993, 1994,1995 Glenn Chappell and Ian Chai
# Copyright 1996, 1997, 1998, 1999, 2000, 2001 John Cowan
# Copyright 2002 Christiaan Keet


chkfont.c, figlist, showfigfonts:
no copyright notice at all


crc.c, crc.h, inflate.c, inflate.h, zipio.c, zipio.h:
non-free license, I would say...

/*
 * Copyright (c) 1995, Edward B. Hamrick
 *
 * Permission to use, copy, modify, distribute, and sell this software and
 * its documentation for any purpose is hereby granted without fee, provided
 * that
 *
 * (i)  the above copyright notice and the text in this "C" comment block
 *  appear in all copies of the software and related documentation, and
 *
 * (ii) any modifications to this source file must be sent, via e-mail
 *  to the copyright owner (currently [EMAIL PROTECTED]) within 
 *  30 days of such modification.

This is compelled distribution. It does not permit private
modifications.
It fails the Dissident Test and the Desert Island Test.
Non-free.

 *
 * THE SOFTWARE IS PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND,
 * EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY
 * WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 *
 * IN NO EVENT SHALL EDWARD B. HAMRICK BE LIABLE FOR ANY SPECIAL, INCIDENTAL,
 * INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND, OR ANY DAMAGES WHATSOEVER
 * RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER OR NOT ADVISED OF
 * THE POSSIBILITY OF DAMAGE, AND ON ANY THEORY OF LIABILITY, ARISING OUT OF
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */


figfont.txt:
non-free license

| Draft 2.0 Copyright 1996, 1997
| by John Cowan and Paul Burton
| Portions Copyright 1991, 1993, 1994
| by Glenn Chappell and Ian Chai
| May be freely copied and distributed.

Where's the permission to modify?


figlet.6:
This file include another copyright notice that seems to cover the whole
package, but the permission grant seems non-free...

.\"  FIGlet
.\"  Copyright (C) 1991, 1993, 1994 Glenn Chappell and Ian Chai
.\"  Internet: <[EMAIL PROTECTED]>
.\"  Portions Copyright 1996, 1997, 1998, 1999, 2000, 2001 by John Cowan 
<[EMAIL PROTECTED]>
.\"  Portions Copyright 2002 by Christiaan Keet
.\"  FIGlet, along with the various FIGlet fonts and documentation, may
.\"  be freely copied and distributed.

It lacks permission to make modifications!

.\"  If you use FIGlet, please send an e-mail message to
.\"  <[EMAIL PROTECTED]>
.\"


getopt.c:
seems to be public domain

 * Here's something you've all been waiting for:  the AT&T public domain
 * source for getopt(3).  It is the code which was given out at the 1985
 * UNIFORUM conference in Dallas. I obtained it by electronic mail directly
 * from AT&T.  The people there assure me that it is indeed in the public
 * domain.


some font files (fonts/*.flf):
very limited permission grant, non-free

| Permission is hereby given to modify this font, as long as the
| modifier's name is placed on a comment line.

No permission to distribute...



OK, now the copyright file states:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This is the Debian Linux prepackaged version of Figlet, a program for doing
things
 _ _ _  _   _ _
| (_) | _  | |_| |__ (_)___
| | | |/ / _ \ | __| '_ \| / __|
| | |   

Re: FIGlet: how to file an appropriate bug report?

[Francesco Poli]

On Tue, 14 Sep 2004 16:46:52 -0700 Josh Triplett wrote:

> Could you please post the text of "Artistic-license.txt", along with a
> wdiff to /usr/share/common-licenses/Artistic ?  That would help
> greatly with ascertaining the Freeness of the license, and determining
> whether the modifications are significant.

Sorry for the delay.
This is the text included in the "Artistic-license.txt" file:

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://www.sunsite.unc.edu/pub/Linux/LICENSES/artistic.license

 The "Artistic License"

Preamble

The intent of this document is to state the conditions under which a
Package may be copied, such that the Copyright Holder maintains some
semblance of artistic control over the development of the package,
while giving the users of the package the right to use and distribute
the Package in a more-or-less customary fashion, plus the right to make
reasonable modifications.

Definitions:

"Package" refers to the collection of files distributed by the
Copyright Holder, and derivatives of that collection of files
created through textual modification.

"Standard Version" refers to such a Package if it has not been
modified, or has been modified in accordance with the wishes
of the Copyright Holder.

"Copyright Holder" is whoever is named in the copyright or
copyrights for the package.

"You" is you, if you're thinking about copying or distributing
this Package.

"Reasonable copying fee" is whatever you can justify on the
basis of media cost, duplication charges, time of people involved,
and so on.  (You will not be required to justify it to the
Copyright Holder, but only to the computing community at large
as a market that must bear the fee.)

"Freely Available" means that no fee is charged for the item
itself, though there may be fees involved in handling the item.
It also means that recipients of the item may redistribute it
under the same conditions they received it.

1. You may make and give away verbatim copies of the source form of the
Standard Version of this Package without restriction, provided that you
duplicate all of the original copyright notices and associated disclaimers.

2. You may apply bug fixes, portability fixes and other modifications
derived from the Public Domain or from the Copyright Holder.  A Package
modified in such a way shall still be considered the Standard Version.

3. You may otherwise modify your copy of this Package in any way, provided
that you insert a prominent notice in each changed file stating how and
when you changed that file, and provided that you do at least ONE of the
following:

a) place your modifications in the Public Domain or otherwise make them
Freely Available, such as by posting said modifications to Usenet or
an equivalent medium, or placing the modifications on a major archive
site such as ftp.uu.net, or by allowing the Copyright Holder to include
your modifications in the Standard Version of the Package.

b) use the modified Package only within your corporation or organization.

c) rename any non-standard executables so the names do not conflict
with standard executables, which must also be provided, and provide
a separate manual page for each non-standard executable that clearly
documents how it differs from the Standard Version.

d) make other distribution arrangements with the Copyright Holder.

4. You may distribute the programs of this Package in object code or
executable form, provided that you do at least ONE of the following:

a) distribute a Standard Version of the executables and library files,
together with instructions (in the manual page or equivalent) on where
to get the Standard Version.

b) accompany the distribution with the machine-readable source of
the Package with your modifications.

c) accompany any non-standard executables with their corresponding
Standard Version executables, giving the non-standard executables
non-standard names, and clearly documenting the differences in manual
pages (or equivalent), together with instructions on where to get
the Standard Version.

d) make other distribution arrangements with the Copyright Holder.

5. You may charge a reasonable copying fee for any distribution of this
Package.  You may charge any fee you choose for support of this Package.
You may not charge a fee for this Package itself.  However,
you may distribute this Package in aggregate with other (possibly
commercial) programs as part of a larger (possibly commercial) software
distribution provided that you do not advertise this Package as a
product of your own.

6. The scripts and library files supplied as input to or produced as
output from the programs of this Package do not automatically fa

libdvdcss legal status [was: Re: Bug#265352: grub: Debian splash images for Grub]

[Francesco Poli]

On Thu, 23 Sep 2004 15:06:34 -0700 Josh Triplett wrote:

> See also libdvdcss, a piece of software that is Free Software in all
> jurisdictions except the United States, in which its use is restricted
> by ridiculous laws.

If you are referring to DMCA, I'm afraid that EUCD is very much similar
in spirit and effect.
Hence libdvdcss will be considered illegal in the European Union, as
well.   :-(

Correct me, if I'm wrong, and I would really like to be wrong here...

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpcuKgkq0pQO.pgp
Description: PGP signature

Re: Bug#265352: grub: Debian splash images for Grub

[Francesco Poli]

On Fri, 24 Sep 2004 09:14:08 +0100 Edmund GRIMLEY EVANS wrote:

> Josh Triplett <[EMAIL PROTECTED]>:
> 
> > > Trademark problems only arise when the image is used in a
> > > particular way. I would think that Debian is not obliged to and
> > > cannot give permission for all possible uses of Debian software.
> > 
> > We most certainly can and should.
> 
> We can't give permission for people to use Apache to implement
> one-click shopping. That's a far greater and far more serious
> restriction, and one more direcly related to software, than the
> trademark restriction on the use of the Debian logo, and yet we don't
> argue that Apache is non-free because of it.

That's because it's not Apache's license that fails to permit this use
(or attempt to restric this use): it's the existence of an unrelated
software patent.
Apache Software Foundation gives this permission, it's the one-click
shopping patent holder that does not!


-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgp1f8EaWJArW.pgp
Description: PGP signature

Re: MTL license

[Francesco Poli]

On Tue, 21 Sep 2004 16:20:09 -0400 Nathanael Nerode wrote:

> And if you're going to make a new one, consult debian-legal, cause
> we're sufficiently paranoid.  ;-)

Indeed.  And, as you may already know,

  "Paranoy is a virtue."   -- Anonymous

:-)

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpQGKulgytgY.pgp
Description: PGP signature

Re: Clarifying non-free parts of the GNU FDL

[Francesco Poli]

On Wed, 22 Sep 2004 18:12:07 -0400 Nathanael Nerode wrote:

> > If these clarifications were to be made, would the licence be
> > considered DFSG-free?
> Um... I think so.  Were there any other problem clauses?

The possibility for further modifiers to *add* unmodifiable sections
(Invariant Sections, Front/Back-cover Texts, ...)?

With this permission in the license, a work is Free (as long as it
doesn't include unmodifiable sections in the first place), but can
easily generate derivatives that are non-free.
This could be undesired by a copyright holder who wants a copyleft Free
license...


Anyway, Roger, consider that, one exception or additional permission
after the other, we are approximately moving in the GPL-2 direction.
I really recommend to choose the GPL-2 itself, as it is really the most
studied and understood copyleft license. At least in dual license with
the GFDL, but GPL-2 alone is my recommendation...


-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpt2bcRkPJli.pgp
Description: PGP signature

Re: Bug#265352: grub: Debian splash images for Grub

[Francesco Poli]

On Sat, 25 Sep 2004 00:59:54 -0400 Brian Thomas Sniffen wrote:

> Well, yes, but if I offer you the MS Visual C++ source code to package
> for Debian, and I tell you I'll give it to you under the GPL, you'll
> turn me down.  Even though I give the relevant permissions, and it's
> the copyright holder that does not.

I'm not convinced that this is an equivalent situation...
I could be misleaded by my opinion that software patents are an abuse
and should not exist in the first place, but anyway I'll try and clarify
what my position is.


If you offer me the MS Visual C++ source code under the GNU GPL license,
*you* are doing something you cannot legally do. You are not the
copyright holder: the real copyright holder didn't give you permission
to distribute under the GNU GPL.

IIUC, you are arguing that, similarly, ASF cannot give me permission to
use Apache to implement one-click shopping, because ASF is not the
patent holder and the real patent holder didn't give ASF permission to
grant a patent license...

But Apache is not a program that implements one-click shopping, so it's
not covered by that software patent, per se.
Of course, it *can* be used as a component in a system that implements
one-click shopping. But that is entirely different.
In other words, that patent is unrelated to Apache.

The MS Visual C++ copyright is instead very much related to MS Visual
C++ (of course).

The Freeness of MS Visual C++ is indeed affected by the permissions
granted by its copyright holder and by any holder of patents that are
*involved* in VC++ itself.

The Freeness of Apache is affected by the permissions granted by its
copyright holder and by any holder of patents that are *involved* in
Apache itself (and one-click shopping is not, AFAIK).
Apache is Free, even if no one issued a free patent license for
one-click shopping.
It cannot be used to implement one-click shopping for external reasons.
It cannot even be used to murder people, again for external reasons:
that does not mean it isn't Free (actually this doesn't violate DFSG 6)


I hope I clarified what I meant.

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpo9zUKGaWo7.pgp
Description: PGP signature

Patents and Freeness [was: Re: Bug#265352: grub: Debian splash images for Grub]

[Francesco Poli]

On Sat, 25 Sep 2004 22:20:33 -0400 Brian Thomas Sniffen wrote:

> > I'm not convinced that this is an equivalent situation...
> > I could be misleaded by my opinion that software patents are an
> > abuse and should not exist in the first place, but anyway I'll try
> > and clarify what my position is.
> 
> But we're talking about trademarks, too.  Do you think trademarks
> which cover software are an abuse?  What about when those trademarks
> describe functional behavior, like the shape of a car or the sound of
> an engine?  How about the interface of a computer, like an iPod?

I didn't think about trademarks enough to conclude...
I haven't yet make up my mind about them.

> 
> > If you offer me the MS Visual C++ source code under the GNU GPL
> > license,*you* are doing something you cannot legally do. You are not
> > the copyright holder: the real copyright holder didn't give you
> > permission to distribute under the GNU GPL.
> 
> Perhaps I'm a reseller -- like CompUSA or Egghead.  I sell you a copy,
> and attach a note saying that I license all my copyrights to the
> included work under the GNU GPL.

Which copyrights?
(almost) none, I think... or do resellers add modifications to MS
programs?

[...]
> > The Freeness of MS Visual C++ is indeed affected by the permissions
> > granted by its copyright holder and by any holder of patents that
> > are*involved* in VC++ itself.
> 
> What's this "involved"?  I don't think that has a clear definition.

Well, I would think we cannot judge the Freeness of a program by looking
at software patents that its *possible* modifications or uses *could*
infringe.
If we did, GNU bash would not be Free, because you have the
possibility to write a bash script that infringes some
not-freely-licensed software patent...
If we did, I think that no program could be judged Free.

IMHO, we must look only at (actively enforced) software patents covering
algorithms that are *already* implemented in the program.
This is what I meant by "involved"...

> 
> > The Freeness of Apache is affected by the permissions granted by its
> > copyright holder and by any holder of patents that are *involved* in
> > Apache itself (and one-click shopping is not, AFAIK).
> 
> How come?  If it were restriction on building web sites, you'd say
> that was involved, I think.  If it were a restriction on frames, you'd
> say that was involved.  If it were a restriction on separate
> menu-bars, like on Debian's own site down the side, is that involved?
> Where's the line between that and a one-click shopping cart?

None of the above are implemented *in* Apache: it merely serves pages.
This restrictions would come into play when judging the Freeness of a
website or of a web authoring tool, but not of a web server...
Or at least, that's the way I would think it works: Apache has no "build
separate menu-bar" feature...

Or do you think that Linux is non-free because its TCP/IP implementation
*can* be used to vehiculate an HTTPS e-commerce transaction featuring
one-click shopping or an HTML page with frames and/or separate
menu-bars?
I don't think that the Freeness of the Linux kernel depends on such
software patents...

[...]
> But I don't lose my license to Apache for murdering people with it, or
> for implementing a one-click shopping license.  Not even if I'm sued
> for doing so.  I think *that's* the difference, that Apache doesn't
> run off and remove its license if I use it for these things. 
> 
> The Open Somethingorother license under discussion here recently did
> so, and trademark law does so too.

I'm sorry: I think I'm not understanding that last sentence.
Do trademark laws state that, when I violate a trademark, I lose a
license?
Which license? A copyright license? A trademark license?

Could you please clarify, as I'm not very knowledgeable about trademark
laws (IANAL)?

-- 
 |  GnuPG Key ID = DD6DFCF4 |  $ fortune
  Francesco  |Key fingerprint = |  Q: What is purple
 Poli| C979 F34B 27CE 5CD8 DC12 | and commutes?
 | 31B5 78F4 279B DD6D FCF4 |  A: A boolean grape.


pgpEuppj4YWpd.pgp
Description: PGP signature

Re: Fwd: figlet license change from Artistic to Clarified Artistic or Artistic 2.0?

[Francesco Poli]

On Tue, 2 Nov 2004 21:33:51 -0500 Glenn Maynard wrote:

> It seems that this license is actually doing two fundamentally
> distinct things: granting a license to people to do stuff, and making
> promises from the distributor/licensor.  I think this combination is
> what makes it so confusing:
[...]
> 
> I'm sure there's some way to make this stuff clearer for people used
> to more typical free licenses, but I'm not sure what it is.

Perhaps by

a) releasing the work under a real copyright license grant (such as the
Expat a.k.a. MIT license http://www.jclark.com/xml/copying.txt)

*and*

b) offering in parallel an optional `uni-lateral' contract in which the
copyright holder promises things to anyone that is willing to accept the
contract.


In that case Debian would (probably) not accept the contract and simply
distribute under the Expat license.
And everyone would be happy...


-- 
  Today is the tomorrow you worried about yesterday.
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpmlGLSj1rIK.pgp
Description: PGP signature

Re: Fwd: figlet license change from Artistic to Clarified Artistic or Artistic 2.0?

[Francesco Poli]

On Thu, 4 Nov 2004 11:49:12 -0500 John Cowan wrote:

> Francesco Poli scripsit:
> 
> > a) releasing the work under a real copyright license grant (such as
> > the Expat a.k.a. MIT license http://www.jclark.com/xml/copying.txt)
> 
> The AFL *is* a "real copyright license grant"; it already grants
> everything the MIT license does and more.

Well, the AFL is a copyright license grant *and* a contract.
By "real" copyright license grant, I meant something that is a copyright
license grant and nothing else.

[...]
> > In that case Debian would (probably) not accept the contract and
> > simply distribute under the Expat license.
> 
> Nothing requires Debian to become a licensor just because they are
> distributing AFLed code, though Debian would have that option.

But, if it's true (as you seem to say) that Debian can legally
distribute FIGlet under (say) the Expat license, with no mention to the
original license at all, why not making this much clearer by splitting
the AFL into an optional contract and a simple free non-copyleft license
(just like the Expat license). 

> (Is Debian a legal person?)

I don't think so.
And that is probably another issue with contract-ish licenses: who is
going to accept contracts? ftp-masters and all the mirror operators?
That sounds problematic...

-- 
  Today is the tomorrow you worried about yesterday.
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4



pgpSJTzUWATmN.pgp
Description: PGP signature

Re: Fwd: figlet license change from Artistic to Clarified Artistic or Artistic 2.0?

[Francesco Poli]

On Thu, 4 Nov 2004 22:54:55 -0500 John Cowan wrote:

> You are already distributing code under the MPL license, which is a
> contract, in debian-stable main.

IIRC, the Mozilla relicensing is underway (though a bit slowly). Debian
is therefore waiting for any NPL/MPL-related issues to be solved.


P.S.: please do not Cc: me, as I am a debian-legal subscriber. Just
reply to the mailing list (and any other addresses in the
Mail-Followup-To: header).  Thanks!   :)

-- 
  Today is the tomorrow you worried about yesterday.
......
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4



pgpiA0W7G2MLP.pgp
Description: PGP signature

APT-HOWTO is under the GFDL

[Francesco Poli]

Hi all!  :)

The Debian documentation policy[1] reads:

| All manuals of the Debian Documentation Project (DDP) will be released
| under DFSG-compliant licenses

On the other hand the APT HOWTO[2] is released under the GNU FDL.
Debian-legal consensus about the GFDL seems quite clear...

Should a bug be filed, in your opinion?


Among other things, the copyright notice[3] reads

| Copyright (C) 2001, 2002 Gustavo Noronha Silva
|
| This manual is licensed under the terms of the GNU FDL (Free
| Documentation License). It has been written in the hope that it will
| be useful to the community but it comes with no warranty; use it at
| your own risk.

As you can see, no explicit declaration about unmodifiable parts
(Invariant Sections, Front/Back-cover Texts, ...).
This looks like an incorrect application of the GFDL...
Is this undistributable?


References:

[1] http://www.debian.org/doc/docpolicy
[2] http://packages.debian.org/unstable/doc/apt-howto
[3] http://www.debian.org/doc/manuals/apt-howto/index.en.html

-- 
  Today is the tomorrow you worried about yesterday.
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp2nwJHK3eHQ.pgp
Description: PGP signature

Re: APT-HOWTO is under the GFDL

[Francesco Poli]

On Tue, 09 Nov 2004 11:01:28 -0200 Gustavo Noronha Silva wrote:

> > > Should a bug be filed, in your opinion?
> > 
> > Definitely.
> 
> Please do.

OK, I'll file a bug ASAP.

> 
> > No, I don't think leaving it unspecified is an incorrect
> > application, though it doesn't exactly follow the application
> > guidelines in the GFDL itself.  I would tend to say that any work
> > under the GFDL which doesn't explicitly specify invariant sections
> > or cover texts should be assumed to have none.
> 
> That's how I understand it myself.

I suspect that a strict interpretation of the GFDL could lead to the
opposite conclusion, but anyway...

> 
> > This still doesn't make it DFSG-free, of course, so a bug should
> > still be filed.  Thank you for raising this issue.  If the Debian
> > project is going to advocate against the GFDL, we should certainly
> > not have any works under that license ourselves.
> 
> Agreed. I didn't change it yet because I plan to do so for version 2,
> which is being written at the alioth's svn and because this was being
> ignored for sarge; I can do it for v1.x if it is a problem right now.

I'm very happy of hearing this!  :)
I really appreciate your good will to relicense.

> 
> Thanks,

Thanks to you, indeed!  :)

-- 
  Today is the tomorrow you worried about yesterday.
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpc0KOtm2abh.pgp
Description: PGP signature

Bug#280673: apt-howto: APT HOWTO is under a non-free license

[Francesco Poli]

Package: apt-howto
Version: 1.7.7-3
Severity: serious
Justification: Policy 2.2.1

The Debian documentation policy (http://www.debian.org/doc/docpolicy) reads:

| All manuals of the Debian Documentation Project (DDP) will be released
| under DFSG-compliant licenses

On the other hand the APT HOWTO is released under the GNU FDL.
Debian-legal consensus about the GFDL seems quite clear: it is *not*
a license suitable for releasing DFSG-free software.

The APT-HOWTO should be relicensed under a DFSG-compliant license.
Refer to http://lists.debian.org/debian-legal/2004/11/msg00062.html
and the thread that follows, for further details.


I found out this license issue in Woody, but note that it still applies
to current Sid package version (1.8.8.1).


-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux neverland 2.4.27 #1 Mon Aug 9 23:52:28 CEST 2004 i686
Locale: LANG=C, LC_CTYPE=

Versions of packages apt-howto depends on:
ii  apt-howto-en  1.7.7-3A Guide to APT (English)
ii  apt-howto-es  1.7.7-3A Guide to APT (Spanish)
ii  apt-howto-it  1.7.7-3A Guide to APT (Italian)
ii  apt-howto-ko  1.7.7-3A Guide to APT (Korean)
ii  apt-howto-pl  1.7.7-3A Guide to APT (Polish)
ii  apt-howto-pt-br   1.7.7-3A Guide to APT (Portuguese)
ii  apt-howto-ru  1.7.7-3A Guide to APT (Russian)

Re: turck-mmcache license violation?

[Francesco Poli]

On Thu, 11 Nov 2004 20:12:42 -0200 [EMAIL PROTECTED] wrote:

> One could claim that php4 is part of the operating system, just like
> they do with OpenSSL. That is nuts!

I agree with you that claiming PHP is part of the OS is a bit hard...

But anyway, Debian cannot ever use the OS exception, since Debian
distributes the "operating system" as well.
The GPL-2 (section 3.) reads:

| However, as a special exception, the source code distributed need not
| include anything that is normally distributed (in either source or
| binary form) with the major components (compiler, kernel, and so on)
| of the operating system on which the executable runs, unless that
| component itself accompanies the executable.  ^^^
  ^^^


-- 
  Today is the tomorrow you worried about yesterday.
......
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpmnxuWsYGne.pgp
Description: PGP signature

Common-licenses [was: Re: kissfft]

[Francesco Poli]

On Fri, 26 Nov 2004 14:22:56 -0800 Josh Triplett wrote:

> Agreed.  For the same reason, I wonder why one particular variant
> (3-clause, copyright "The Regents of the University of California") of
> the BSD license is included in /usr/share/common-licenses, while the
> standard MIT license is not.

You are quite right!
I would think that the following licenses belong in
/usr/share/common-licenses/  :

GPL-2  LGPL-2  LGPL-2.1
 --- as they are just now

2-clause-BSD
 --- as in  http://www.fsf.org/licenses/info/BSD_2Clause.html

3-clause-BSD
 --- as in  http://www.fsf.org/licenses/info/BSD_3Clause.html

Expat-MIT
 --- as in  http://www.jclark.com/xml/copying.txt

X11-MIT
 --- as in  http://www.x.org/Downloads_terms.html


Maybe a wishlist bug should be filed against the base-files package...
What do you think?

-- 
  Today is the tomorrow you worried about yesterday.
......
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpViwb8is7kR.pgp
Description: PGP signature

Bug#284340: base-files: Please remove reference to UC in BSD license and add other licenses

[Francesco Poli]

Package: base-files
Version: 3.0.2
Severity: wishlist


Please remove reference to a specific copyright holder (The Regents of 
the University of California) in /usr/share/common-licenses/BSD and 
rename it 3-clause-BSD. Including only one narrow variant of the
BSD license seems highly error-prone.

Moreover, please add 2 clause BSD license, Expat (a.k.a. MIT) license,
and X11 (a.k.a. MIT) license in /usr/share/common-licenses/

Refer to http://lists.debian.org/debian-legal/2004/11/msg00158.html and 
following few replies.



In other words, I would think that the following licenses belong in
/usr/share/common-licenses/  :


GPL-2  LGPL-2  LGPL-2.1  Artistic
 --- as they are just now


2-clause-BSD
 --- as in  http://www.fsf.org/licenses/info/BSD_2Clause.html

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

* Redistributions of source code must retain the above copyright
  notice, this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above
  copyright notice, this list of conditions and the following
  disclaimer in the documentation and/or other materials provided
  with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


3-clause-BSD
 --- as in  http://www.fsf.org/licenses/info/BSD_3Clause.html

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

* Redistributions of source code must retain the above copyright
  notice, this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above
  copyright notice, this list of conditions and the following
  disclaimer in the documentation and/or other materials provided
  with the distribution.

* Neither the name of [original copyright holder] nor the names of
  its contributors may be used to endorse or promote products
  derived from this software without specific prior written
  permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


Expat-MIT
 --- as in  http://www.jclark.com/xml/copying.txt  but with copyright 
holders pulled out

Permission is hereby granted, free of charge, to any person obtaining
a copy of this 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.


X11-MIT
 --- as in  http://www.x.org/Downloads_terms.html  but with copyright 
holders pulled out

Permission is hereby granted, free of charge, to any person obtaining a 
copy of this software and associated documentation files (the 
"Software"), to deal in the Software 

Re: Bug#284340: base-files: Please remove reference to UC in BSD license and add other licenses

[Francesco Poli]

On Sun, 5 Dec 2004 18:35:03 +0100 (CET) Santiago Vila wrote:

> reassign 284340 debian-policy
> thanks

Whooops...  :p

[...]
> > In other words, I would think that the following licenses belong in
> > /usr/share/common-licenses/  :
> > [...]
> 
> You probably have not read base-files FAQ.

You are quite right: I haven't...
I apologize for this.  

The reason is that no such FAQ exists in Woody and I didn't know that
such a file was included in Sarge/Sid...  :p

> Please read the answer to this question:
> 
> Q. Why isn't license "foo" included in common-licenses?

Mmmmh, I see. The answer is:

| A. I delegate such decisions to the policy group. If you want to
| propose a new license you should make a policy proposal to modify the
| paragraph in policy saying "Packages distributed under the UCB BSD
| license, Artistic license, GNU GPL and GNU LGPL should refer to the
| files in /usr/share/common-licenses". The way of doing this is
| explained in the debian-policy package. As usual, you should always
| take a look at already reported bugs against debian-policy before
| submitting a new one.

> IMHO, the licenses you propose to be added to
> /usr/share/common-licenses are short enough that no disk space is
> saved at all by having a "single" copy in base-files. For this reason
> I think we could even remove the current BSD license itself, since
> it's just 1499 bytes long.

Yes, they are fairly short.
But, IMVHO, having them in /usr/share/common-licenses would help to
clarify their differences and their canonical text and proper name.

Moreover the current BSD license includes (as I said) a particular
copyright holder's name: referring to it (or even copying & pasting it)
would often be a mistake.

I still think that my proposed common-licenses reordering would benefit
Debian...

-- 
  Today is the tomorrow you worried about yesterday.
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp7KQTL8OfBk.pgp
Description: PGP signature

Re: Copyright Question

[Francesco Poli]

On Fri, 10 Dec 2004 23:52:36 + Rich Walker wrote:

> Would it make sense to add a License: field to the status information
> available to dpkg?

IMHO, no.
Because the Freeness status of a package is far more complex than a
single license name.

Many times you have works under different licenses packaged together.
Then there are additional permissions (or restrictions!) that go beyond
standard licenses.
Awkward licenses that have no name at all.
Actively enforced software patents to cope with.



-- 
  Today is the tomorrow you worried about yesterday.
......
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpCQtrXdQyPR.pgp
Description: PGP signature

Re: GPL on rendered images

[Francesco Poli]

On Tue, 14 Dec 2004 16:11:19 -0500 Glenn Maynard wrote:

> Merely running p2c on the code doesn't make it the preferred form for
> modification.  I can't take your Pascal program, hack on it (in
> Pascal) for a while, compile and release it, and only offer converted
> C code, calling it "source".  It's not my preferred form for
> modification (and merely claiming it is doesn't make it so; that's
> just lying).
> 
> However, I can take your Pascal program, convert it to C, hack on it
> (in C) for a while, compile and release it, and only offer converted
> C code.  It really is source; it's my real, actual preferred form
> for modification.  The fact that I actually did my work in C indicates
> this.
> 
> The former is merely using p2c as an obfuscator, as an attempt to
> avoid releasing source; the GPL does not allow this.  The latter is a
> legitimate change in the source form of the work, which the GPL does
> allow.

I agree entirely.

This is the main strength of the "preferred form for modification"
definition of source. You cannot cheat: you must provide your actual
working form, not another person's one.

-- 
  Today is the tomorrow you worried about yesterday.
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgp6QLjxEadVM.pgp
Description: PGP signature

Re: d-fsl - German Free Software License

[Francesco Poli]

ing. It is 
> assumed that terminology used in the License has 
> the same meaning in both versions. Should, 
> however, differences arise, such meaning is 
> authoritative which best brings into line both 
> versions, taking into consideration the aim and 
> purpose of the License.

This seems good...

> 
> (2) The license board of the German Free Software 
> License may put into force binding new versions 
> of this License inasmuch as this is required and 
> reasonable. New versions of the License will be 
> published on the Internet site <http://www.d-
> fsl.org> with a unique version number. The new 
> version of the License becomes binding for you as 
> soon as you become aware of its publication. 
> Legal remedies against the modification of the 
> License are not restricted by the regulations 
> described above.

So I cannot license a program under a particular version of D-FSL and
not later ones.
An implicit "latest available version" is assumed...


-- 
  Today is the tomorrow you worried about yesterday.
..
  Francesco Poli GnuPG Key ID = DD6DFCF4
 Key fingerprint = C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpC1OcfHEav4.pgp
Description: PGP signature