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

Re: texlive restrictive licence in main prevents derived works?



On Fri, 08 May 2009 22:27:52 +0200
Frank Küster <frank@debian.org> wrote:

> >> 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.
> 
> Renaming won't work, because it's not about filenames, it's about
> "identification to the interpreter". In other words, if the license of
> foo.sty requires it be distributed together with foo.pdf, you are
> allowed to rename the whole thing to bar, but then bar.sty (or still
> call it foo.sty if you prefer) must identify itself as "Package bar
> [$date]", and you'll get "foo was requested, bar was loaded" fatal
> errors. 

It looks like packages that build-depend on tex* will simply not build
on Emdebian Grip - for (of all things) legal reasons - without pulling
the unchanged Debian packages. It means bringing in the massive
Packages.gz file from Debian but then, the texlive dependencies aren't
exactly small.

Probably the easiest way to do that is simply remove tex* packages from
Emdebian Grip unconditionally. (Grip is filtered, we can easily prevent
Debian packages being included into Grip.)

Are there other packages anyone knows about that prevent the removal
of /usr/share/doc/foo by some automated process for legal reasons?

> > 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.
> 
> I hope there's a different way to go: Identify which TeX/LaTeX styles
> are really needed by docbook-utils, and then let's create a package
> just for that. If it's still not small enough, including the docs,
> then let's start thinking again. What about
> 
> if $this_is_embedian rm $docfiles
> 
> in postinst?

That means downloading the docfiles in the first place which is what we
avoid by using Emdebian Grip. If the unchanged package needs to be
downloaded, it's not that much of a gain over having the package from
Debian unchanged, which is what it sounds like we would have to do.
 
> > It wouldn't be so bad if texlive-base didn't depend (not recommend)
> > texlive-doc-base.
> 
> What's the problem with that package?

Emdebian Grip drops Recommends so the problem goes away entirely - at
least it would if the resulting package was legal and would work as a
build dependency.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/

Attachment: pgpwhHhxp5gtP.pgp
Description: PGP signature


Reply to: