[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: texlive restrictive licence in main prevents derived works?



On Fri, 8 May 2009 13:10:02 +0200
Norbert Preining <preining@logic.at> wrote:

> > How did that get into main?
> 
> Long discussion, please see debian-legal quite some time ago. The point
> is that modifications are allowed but the modifyied work needs to be
> renamed (like with tex the program) as long as the status of the
> packages is "Maintained" plus prominent notices etc.
> http://lists.debian.org/debian-legal/2004/07/msg00079.html
> and many other links.

OK, it's just a naming thing. Not sure how we can handle that in
Emdebian - renaming isn't automated, at least not currently. "Gripping"
texlive-doc-base results in only three files:

./usr/share/doc/texlive-doc-base/copyright.gz
./usr/share/bug/texlive-doc-base/script
./usr/share/bug/texlive-doc-base/control

http://www.emdebian.org/grip/

743K 2009-05-08 12:16 texlive-doc-base_2007.dfsg.2-2_all.deb
 18K 2009-05-08 12:22 texlive-doc-base_2007.dfsg.2-2em1_all.deb

Hence why I'd like to understand the problem and work out how Emdebian
can have useful packages like docbook-utils without getting into
problems with tex.

Am I going to have to blacklist packages in main that don't allow
modifications without renaming? There's no easy way of identifying such
packages either.
 
> In fact it was always like that that we installed the doc files
> unconditionally, only on user demand and after recommends were installed
> by default we allowed ourselves after discussion with some upstream
> authors to split the doc files out.
> 
> In fact, there are upstream authors (not texlive upstream, but of the
> tex packages itself) that *force* us also in TeX Live (upstream) to
> include the documentation *in*any*case* (currently only one such case).
> Well, force, we could remove the packages, but that wouldn't be a good
> idea since it is one very important.
> 
> So we are left with the current situation. It is not that bad because
> auto-builders do not install recommends, the rest is up to the sysadmin.

It wouldn't be so bad if texlive-base didn't depend (not recommend)
texlive-doc-base.

This element still remains:

"The bug in that dependency chain is in
texlive-base which has "Depends: texlive-doc-base" - in the context of
'apt-get install docbook-utils', that is entirely unwarranted."

Shouldn't that be a Recommends?

I still want to *not* have to install texlive-doc-base on systems that
only want to use docbook-utils and have Install-Recommends turned off. I
don't see why texlive makes that impossible.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgpZ1Q5qUJK33.pgp
Description: PGP signature


Reply to: