4:28 p.m.
On 2009-01-20 at 4:30:26 -0500, Stefan Grosse <singularitaet(a)gmx.net> wrote:
Hi,
are there any plans for updating texlive to 2008 in Leonidas?
I'd have to say the chances of this are extremely unlikely. I'm much
more inclined to propose that we drop texlive altogether. It is a
licensing nightmare, a tangled bundle of millions of files with little
apparent organizational structure, and no overarching licensing
analysis. I started trying to do a license audit on texlive 2008, but it
would probably take me at least a month of doing nothing except auditing
texlive to finish it.
To be fair, the existing texlive has the same problems, I just was
unaware of the scope of things until recently.
~spot
5:51 p.m.
Tom "spot" Callaway wrote:
I'd have to say the chances of this are extremely unlikely.
I'm much
more inclined to propose that we drop texlive altogether.
No TeX? That would make Fedora pretty much useless for Mathematics and
anything related!
If concrete licensing issues are found by somebody, of course those need to
be addressed, but dropping all of TeX on the ground that it's too hard to
audit is a horribly bad idea.
Kevin Kofler
1:08 a.m.
Le jeudi 29 janvier 2009 à 00:51 +0100, Kevin Kofler a écrit :
Tom "spot" Callaway wrote:
> I'd have to say the chances of this are extremely unlikely. I'm much
> more inclined to propose that we drop texlive altogether.
No TeX? That would make Fedora pretty much useless for Mathematics and
anything related!
If concrete licensing issues are found by somebody, of course those need to
be addressed, but dropping all of TeX on the ground that it's too hard to
audit is a horribly bad idea.
People who want TEX kept should create a task force and feed TEXlive
2008 in rawhide bit by bit, checking for each bit the licensing is ok.
That's about the only way the burden of checking TEX can be distributed
enough it won't depend on a couple packagers, when the amount of work is
too much to be humanly doable by a few people alone in a realistic
timeframe.
Our curent TEX packaging would be similar to try to package 80% of CPAN
in a single source package. Of course people crap out when they try to
check licensing correctly (and TEX stuff has more licensing variability
than Perl)
--
Nicolas Mailhot
6:06 a.m.
2009/1/29 Nicolas Mailhot <nicolas.mailhot(a)laposte.net>:
Le jeudi 29 janvier 2009 à 00:51 +0100, Kevin Kofler a écrit :
> Tom "spot" Callaway wrote:
> > I'd have to say the chances of this are extremely unlikely. I'm much
> > more inclined to propose that we drop texlive altogether.
>
> No TeX? That would make Fedora pretty much useless for Mathematics and
> anything related!
>
> If concrete licensing issues are found by somebody, of course those need to
> be addressed, but dropping all of TeX on the ground that it's too hard to
> audit is a horribly bad idea.
People who want TEX kept should create a task force and feed TEXlive
2008 in rawhide bit by bit, checking for each bit the licensing is ok.
That's about the only way the burden of checking TEX can be distributed
enough it won't depend on a couple packagers, when the amount of work is
too much to be humanly doable by a few people alone in a realistic
timeframe.
Our curent TEX packaging would be similar to try to package 80% of CPAN
in a single source package. Of course people crap out when they try to
check licensing correctly (and TEX stuff has more licensing variability
than Perl)
I have actually been spending a chunk of time looking carefully at the
way in which TeXlive is put together from the various upstreams to see
if we can't do better than taking the monolthic tarball dumps of
texlive as we have in the past. To say that the way the bits and
pieces of TeX are put together is a horrific mess is an
understatement. However, there is some hope. Forefront in my mind is
that we do want to capitalise on the integration work that is done by
texlive, as we don't have the manpower to reproduce that effort. On
the other hand we want something much better integrated and modular
than texlive presently provides for distribution packaging. At the
moment though, I only have time to work on this at weekends, so
progress so far has been slow, and has been entirely learning.
J.
6:11 a.m.
On Thu, Jan 29, 2009 at 12:06:27PM +0000, Jonathan Underwood wrote:
I have actually been spending a chunk of time looking carefully at the
way in which TeXlive is put together from the various upstreams to see
if we can't do better than taking the monolthic tarball dumps of
texlive as we have in the past. To say that the way the bits and
pieces of TeX are put together is a horrific mess is an
understatement. However, there is some hope. Forefront in my mind is
that we do want to capitalise on the integration work that is done by
texlive, as we don't have the manpower to reproduce that effort. On
the other hand we want something much better integrated and modular
than texlive presently provides for distribution packaging. At the
moment though, I only have time to work on this at weekends, so
progress so far has been slow, and has been entirely learning.
Jindrich has done some work on extracting dependency information from
individual texlive packages. I don't know where this stands now.
--
Pat
6:15 a.m.
2009/1/29 Patrice Dumas <pertusus(a)free.fr>:
On Thu, Jan 29, 2009 at 12:06:27PM +0000, Jonathan Underwood wrote:
>
> I have actually been spending a chunk of time looking carefully at the
> way in which TeXlive is put together from the various upstreams to see
> if we can't do better than taking the monolthic tarball dumps of
> texlive as we have in the past. To say that the way the bits and
> pieces of TeX are put together is a horrific mess is an
> understatement. However, there is some hope. Forefront in my mind is
> that we do want to capitalise on the integration work that is done by
> texlive, as we don't have the manpower to reproduce that effort. On
> the other hand we want something much better integrated and modular
> than texlive presently provides for distribution packaging. At the
> moment though, I only have time to work on this at weekends, so
> progress so far has been slow, and has been entirely learning.
Jindrich has done some work on extracting dependency information from
individual texlive packages. I don't know where this stands now.
Yes, have looked at that... very useful. However, I am wondering if we
should really be working from the texlive tree.
12:31 p.m.
Nicolas Mailhot wrote:
People who want TEX kept should create a task force and feed TEXlive
2008 in rawhide bit by bit, checking for each bit the licensing is ok.
That's about the only way the burden of checking TEX can be distributed
enough it won't depend on a couple packagers, when the amount of work is
too much to be humanly doable by a few people alone in a realistic
timeframe.
I don't think that makes sense:
* Modular packaging is a lot more work than monolithic packaging.
* If we import TeXlive 2008 piecemeal, we'll have a Rawhide with a broken
mix of a monolithic 2007 package and incomplete split 2008 packages.
We have to upgrade 2007 to 2008 and this should not be blocking on a license
review. No other packages get a license audit on each upgrade, I don't see
why TeXlive should be any different.
We should just upgrade TeXlive and then deal with any licensing issues if
they are found and reported. Redoing an audit at every new version is not
going to scale and nothing in our policies requires it.
Kevin Kofler
12:37 p.m.
On Thu, 2009-01-29 at 19:31 +0100, Kevin Kofler wrote:
We have to upgrade 2007 to 2008 and this should not be blocking on a
license
review. No other packages get a license audit on each upgrade, I don't see
why TeXlive should be any different.
We should just upgrade TeXlive and then deal with any licensing issues if
they are found and reported. Redoing an audit at every new version is not
going to scale and nothing in our policies requires it.
When we suspect, and have already found, improper licenses in a set of
software, we certainly can and should block it from coming in until a
audit is done to clear ourselves of any wrong doing. Doing otherwise
would be willful infringement.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:56 p.m.
Jesse Keating wrote:
When we suspect, and have already found, improper licenses in a set
of
software, we certainly can and should block it from coming in until a
audit is done to clear ourselves of any wrong doing. Doing otherwise
would be willful infringement.
So where are the improper licenses in TeXlive 2008 (which have not already
been filtered out in Fedora since the 2007 version)?
Kevin Kofler
1:14 p.m.
On Thu, 2009-01-29 at 19:56 +0100, Kevin Kofler wrote:
Jesse Keating wrote:
> When we suspect, and have already found, improper licenses in a set of
> software, we certainly can and should block it from coming in until a
> audit is done to clear ourselves of any wrong doing. Doing otherwise
> would be willful infringement.
So where are the improper licenses in TeXlive 2008 (which have not already
been filtered out in Fedora since the 2007 version)?
Kevin Kofler
That's a spot question.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:51 p.m.
Le jeudi 29 janvier 2009 à 19:31 +0100, Kevin Kofler a écrit :
Nicolas Mailhot wrote:
> People who want TEX kept should create a task force and feed TEXlive
> 2008 in rawhide bit by bit, checking for each bit the licensing is ok.
> That's about the only way the burden of checking TEX can be distributed
> enough it won't depend on a couple packagers, when the amount of work is
> too much to be humanly doable by a few people alone in a realistic
> timeframe.
I don't think that makes sense:
* Modular packaging is a lot more work than monolithic packaging.
* If we import TeXlive 2008 piecemeal, we'll have a Rawhide with a broken
mix of a monolithic 2007 package and incomplete split 2008 packages.
We have to upgrade 2007 to 2008 and this should not be blocking on a license
review. No other packages get a license audit on each upgrade, I don't see
why TeXlive should be any different.
One of the changes in TeXlive 2008 is it's supposed to be modular
upstream now. Bundling a modular upstream in a single fedora package is
generally a bad idea
--
Nicolas Mailhot
8:55 a.m.
Kevin Kofler wrote:
Tom "spot" Callaway wrote:
> I'd have to say the chances of this are extremely unlikely. I'm much
> more inclined to propose that we drop texlive altogether.
No TeX?
If concrete licensing issues are found by somebody, of course those
need to be addressed
+1
Why is a license audit is blocking an update? Can't these tasks be done in
parallel?
-- Rex
9:09 a.m.
Le Jeu 29 janvier 2009 15:55, Rex Dieter a écrit :
Kevin Kofler wrote:
> Tom "spot" Callaway wrote:
>> I'd have to say the chances of this are extremely unlikely. I'm
>> much
>> more inclined to propose that we drop texlive altogether.
>
> No TeX?
> If concrete licensing issues are found by somebody, of course those
> need to be addressed
+1
Why is a license audit is blocking an update?
I don't think it's blocking, IIRC texlive 2008 also demands different
packaging, and there is a lack of people to do both the technical
*and* the legal work.
Of course new modular packaging of TEX would take care of both issues,
if enough packagers could be found to submit packages for each part of
TEX, checking its licensing at the same time.
--
Nicolas Mailhot
11:47 a.m.
Nicolas Mailhot wrote:
Le Jeu 29 janvier 2009 15:55, Rex Dieter a écrit :
> Why is a license audit is blocking an update?
I don't think it's blocking, IIRC texlive 2008 also demands different
packaging, and there is a lack of people to do both the technical
*and* the legal work.
fair nuf. Where's our TeX SIG? :)
-- Rex
11:58 a.m.
>>>> "RD" == Rex Dieter
<rdieter(a)math.unl.edu> writes:
RD> fair nuf. Where's our TeX SIG? :)
https://fedoraproject.org/wiki/SIGs/TeX
(well, in theory, at least).
I would be willing to devote a little time to TeX, seeing as how I
kind of have to support it. However, I don't actually use it (such is
the life of a sysadmin) so I'm not much help for some of the more
bizarre aspects.
I'd just hate to see the whole thing go down in a pile of legal
confusion. At the very least we'd have to go with the stuff that we
know is legally OK and add more as it is cleared. Going completely
without TeX is not an option for a large number of folks.
- J<
12:20 p.m.
2009/1/29 Jason L Tibbitts III <tibbs(a)math.uh.edu>:
>>>>> "RD" == Rex Dieter
<rdieter(a)math.unl.edu> writes:
RD> fair nuf. Where's our TeX SIG? :)
https://fedoraproject.org/wiki/SIGs/TeX
(well, in theory, at least).
I would be willing to devote a little time to TeX, seeing as how I
kind of have to support it. However, I don't actually use it (such is
the life of a sysadmin) so I'm not much help for some of the more
bizarre aspects.
I'd just hate to see the whole thing go down in a pile of legal
confusion. At the very least we'd have to go with the stuff that we
know is legally OK and add more as it is cleared. Going completely
without TeX is not an option for a large number of folks.
Count me in, obviously.
I hope to find a bit of time to write up my notes and thoughts on
tl2008 on a wiki page at the weekend, novovirus permitting.
1 p.m.
Jason L Tibbitts III <tibbs(a)math.uh.edu> writes:
I would be willing to devote a little time to TeX, seeing as how I
kind of have to support it. However, I don't actually use it (such is
the life of a sysadmin) so I'm not much help for some of the more
bizarre aspects.
Same for me.
--
Arnaud
12:32 p.m.
Nicolas Mailhot wrote:
Of course new modular packaging of TEX would take care of both
issues,
if enough packagers could be found to submit packages for each part of
TEX, checking its licensing at the same time.
Modular packaging means several orders of magnitude more work. If we don't
even have the manpower for monolithic packaging, we definitely don't have
it for modular packaging.
Kevin Kofler
1:02 p.m.
2009/1/29 Kevin Kofler <kevin.kofler(a)chello.at>:
Nicolas Mailhot wrote:
> Of course new modular packaging of TEX would take care of both issues,
> if enough packagers could be found to submit packages for each part of
> TEX, checking its licensing at the same time.
Modular packaging means several orders of magnitude more work. If we don't
even have the manpower for monolithic packaging, we definitely don't have
it for modular packaging.
Not necessarily in this case. From a thousand miles up, the process of
creating texlive upstream basically involves taking packages from ctan
and assembling them into the texlive tree using various scripts
(notably ctan2tl and ctan2tds and others) which is then used to create
the texlive distribution. I've been wondering if it would be possible
to adapt these scripts to be used during RPM build time to package
upstream ctan tarballs. More work needed though. An approach like this
is worth considering though I think. Of course, this applies to
packages and fonts mainly, not the tex binaries.
J.
1:52 p.m.
Jonathan Underwood wrote:
Not necessarily in this case. From a thousand miles up, the process
of
creating texlive upstream basically involves taking packages from ctan
and assembling them into the texlive tree using various scripts
(notably ctan2tl and ctan2tds and others) which is then used to create
the texlive distribution. I've been wondering if it would be possible
to adapt these scripts to be used during RPM build time to package
upstream ctan tarballs. More work needed though. An approach like this
is worth considering though I think. Of course, this applies to
packages and fonts mainly, not the tex binaries.
And who handles the dozens of review requests? Our review queue is already
flooded!
Kevin Kofler
1:59 p.m.
Le jeudi 29 janvier 2009 à 20:52 +0100, Kevin Kofler a écrit :
Jonathan Underwood wrote:
> Not necessarily in this case. From a thousand miles up, the process of
> creating texlive upstream basically involves taking packages from ctan
> and assembling them into the texlive tree using various scripts
> (notably ctan2tl and ctan2tds and others) which is then used to create
> the texlive distribution. I've been wondering if it would be possible
> to adapt these scripts to be used during RPM build time to package
> upstream ctan tarballs. More work needed though. An approach like this
> is worth considering though I think. Of course, this applies to
> packages and fonts mainly, not the tex binaries.
And who handles the dozens of review requests? Our review queue is already
flooded!
Not having a human check the license of each file is what got us into
legal problems in the first place.
--
Nicolas Mailhot
2:06 p.m.
2009/1/29 Kevin Kofler <kevin.kofler(a)chello.at>:
Jonathan Underwood wrote:
> Not necessarily in this case. From a thousand miles up, the process of
> creating texlive upstream basically involves taking packages from ctan
> and assembling them into the texlive tree using various scripts
> (notably ctan2tl and ctan2tds and others) which is then used to create
> the texlive distribution. I've been wondering if it would be possible
> to adapt these scripts to be used during RPM build time to package
> upstream ctan tarballs. More work needed though. An approach like this
> is worth considering though I think. Of course, this applies to
> packages and fonts mainly, not the tex binaries.
And who handles the dozens of review requests? Our review queue is already
flooded!
Well, whatever happens, a review is going to be needed for the
collection RPMs. I wasn't imagining one RPM per ctan package :).
12:57 p.m.
On Thu, Jan 29, 2009 at 04:09:16PM +0100, Nicolas Mailhot wrote:
Of course new modular packaging of TEX would take care of both issues,
if enough packagers could be found to submit packages for each part of
TEX, checking its licensing at the same time.
Something more modular may be nice, going to the granularity of CTAN is
certainly a bad idea. Upstream advocated packaging bundles that are quite
large.
--
Pat
6:38 p.m.
On Wed, 2009-01-28 at 17:28 -0500, Tom "spot" Callaway wrote:
On 2009-01-20 at 4:30:26 -0500, Stefan Grosse
<singularitaet(a)gmx.net> wrote:
> Hi,
>
> are there any plans for updating texlive to 2008 in Leonidas?
I'd have to say the chances of this are extremely unlikely. I'm much
more inclined to propose that we drop texlive altogether. It is a
licensing nightmare, a tangled bundle of millions of files with little
apparent organizational structure, and no overarching licensing
analysis. I started trying to do a license audit on texlive 2008, but it
would probably take me at least a month of doing nothing except auditing
texlive to finish it.
To be fair, the existing texlive has the same problems, I just was
unaware of the scope of things until recently.
Right, who needs those oldfashioned TeX users anyway... ?!
4:57 p.m.
On Wed, 2009-01-28 at 19:38 -0500, Matthias Clasen wrote:
On Wed, 2009-01-28 at 17:28 -0500, Tom "spot" Callaway
wrote:
> On 2009-01-20 at 4:30:26 -0500, Stefan Grosse <singularitaet(a)gmx.net> wrote:
> > Hi,
> >
> > are there any plans for updating texlive to 2008 in Leonidas?
>
> I'd have to say the chances of this are extremely unlikely. I'm much
> more inclined to propose that we drop texlive altogether. It is a
> licensing nightmare, a tangled bundle of millions of files with little
> apparent organizational structure, and no overarching licensing
> analysis. I started trying to do a license audit on texlive 2008, but it
> would probably take me at least a month of doing nothing except auditing
> texlive to finish it.
>
> To be fair, the existing texlive has the same problems, I just was
> unaware of the scope of things until recently.
>
Right, who needs those oldfashioned TeX users anyway... ?!
Er... you are not serious here, are you... There isn't any other
solution to type math formulae both fast and neat. I use TeX (csplain)
on daily basis... There's nothing oldfashioned about TeX, especially
around Physicists and Mathematicians.
But back to the main topic... TeTeX didn't have licensing issues? I'd
guess it had, seeing how cs fonts (which I use) seem to be licensed
under nonfree license (or so I understand what spot said somewhere in
this thread)... How other distributions (especially RHEL, SUSE and
Debian) handle these issues? I wouldn't want Fedora to be the only
distribution in the world without TeX just because its licensing is a
catastrophic mess...
Martin
5:14 p.m.
On Thu, 2009-01-29 at 23:57 +0100, Martin Sourada wrote:
On Wed, 2009-01-28 at 19:38 -0500, Matthias Clasen wrote:
> On Wed, 2009-01-28 at 17:28 -0500, Tom "spot" Callaway wrote:
> > On 2009-01-20 at 4:30:26 -0500, Stefan Grosse <singularitaet(a)gmx.net>
wrote:
> > > Hi,
> > >
> > > are there any plans for updating texlive to 2008 in Leonidas?
> >
> > I'd have to say the chances of this are extremely unlikely. I'm much
> > more inclined to propose that we drop texlive altogether. It is a
> > licensing nightmare, a tangled bundle of millions of files with little
> > apparent organizational structure, and no overarching licensing
> > analysis. I started trying to do a license audit on texlive 2008, but it
> > would probably take me at least a month of doing nothing except auditing
> > texlive to finish it.
> >
> > To be fair, the existing texlive has the same problems, I just was
> > unaware of the scope of things until recently.
> >
>
> Right, who needs those oldfashioned TeX users anyway... ?!
>
Er... you are not serious here, are you... There isn't any other
solution to type math formulae both fast and neat. I use TeX (csplain)
on daily basis... There's nothing oldfashioned about TeX, especially
around Physicists and Mathematicians.
Yeah, I omitted the sarcasm tag. I'm an old TeX user myself. You can
probably find a few of my contributions on ctan if you look hard
enough...
I totally agree that Fedora without TeX would feel very incomplete.
8:32 p.m.
Tom "spot" Callaway wrote:
On 2009-01-20 at 4:30:26 -0500, Stefan Grosse
<singularitaet(a)gmx.net>
wrote:
> Hi,
>
> are there any plans for updating texlive to 2008 in Leonidas?
I'd have to say the chances of this are extremely unlikely. I'm much
more inclined to propose that we drop texlive altogether. It is a
licensing nightmare, a tangled bundle of millions of files with little
apparent organizational structure, and no overarching licensing
analysis. I started trying to do a license audit on texlive 2008, but it
would probably take me at least a month of doing nothing except auditing
texlive to finish it.
To be fair, the existing texlive has the same problems, I just was
unaware of the scope of things until recently.
~spot
Really? I've been reading the texlive list. I noticed they have been
dropping many packages due to license issues.
12:35 p.m.
Neal Becker wrote:
Really? I've been reading the texlive list. I noticed they have
been
dropping many packages due to license issues.
That proves that TeXlive upstream cares about the licensing being Free
Software, why can't we just trust them instead of redoing an audit at every
single upgrade? We already did an audit when importing the 2007 version,
for all other packages that's sufficient (in fact in most cases we trust
the reviewer and don't even go through FE-Legal!), why not here?
Kevin Kofler
12:44 p.m.
On Thu, 2009-01-29 at 19:35 +0100, Kevin Kofler wrote:
Neal Becker wrote:
> Really? I've been reading the texlive list. I noticed they have been
> dropping many packages due to license issues.
That proves that TeXlive upstream cares about the licensing being Free
Software, why can't we just trust them instead of redoing an audit at every
single upgrade? We already did an audit when importing the 2007 version,
for all other packages that's sufficient (in fact in most cases we trust
the reviewer and don't even go through FE-Legal!), why not here?
It's like cancer. You don't worry about it until you get diagnosed once
as having it. Then you get the checks every year.
We know TexLive has had some issues, so we have to keep checking and
assuming it will have more issues.
-sv
1:32 p.m.
On 2009-01-29 at 13:35:50 -0500, Kevin Kofler <kevin.kofler(a)chello.at>
wrote:
Neal Becker wrote:
> Really? I've been reading the texlive list. I noticed they have been
> dropping many packages due to license issues.
That proves that TeXlive upstream cares about the licensing being Free
Software, why can't we just trust them instead of redoing an audit at every
single upgrade? We already did an audit when importing the 2007 version,
for all other packages that's sufficient (in fact in most cases we trust
the reviewer and don't even go through FE-Legal!), why not here?
Because we know it is bad.
Let me start putting facts on the table:
In texlive-texmf-20080822, there are three main directories:
texmf/
texmf-dist/
texmf-doc/
Assuming that texmf-doc/ is all documentation, I focused my initial
audit on texmf/ and texmf-dist/.
texmf/ has 1269 files in it.
texmf-dist/ has 58326 files in it.
I finished auditing texmf/. Of the files in there, I could not determine
any licensing information for 615 (48.5%) contain no licensing
information whatsoever. One file claims to be "BSD-style", but the
license text is missing.
I've barely scratched the surface of texmf-dist, but I have already found:
- texmf-dist/fonts/type1/public/cs/* is under the BaKoMa-CM.Fonts license
(http://www.netlib.org/bibnet/BaKoMa-CM.Fonts) which is non-free.
- texmf-dist/fonts/truetype/public/xepersian/IranNastaliq.ttf is non-free
- texmf-dist/fonts/truetype/public/xepersian/koodak.ttf is non-free, due
to modification restrictions
- texmf-dist/fonts/truetype/public/xepersian/LateefRegOT.ttf is non-free
- texmf-dist/fonts/truetype/public/xepersian/royab.ttf is non-free, due
to modification restrictions
- texmf-dist/fonts/truetype/public/xepersian/ScheherazadeRegOT.ttf is
non-free
- texmf-dist/fonts/truetype/public/xepersian/terafikb.ttf is non-free,
due to modification restrictions
- texmf-dist/fonts/truetype/public/xepersian/terafik.ttf is non-free,
due to modification restrictions
I cannot find licensing for:
- texmf-dist/fonts/type1/arphic/*
- texmf-dist/fonts/type1/bluesky/*
Also, given that the licensing information is almost never included in
the texlive fonts themselves, nor is the documentation packaged next to
the files, I have to try to unravel what file belongs to what
documentation and make guesses about the licensing.
I have tens of thousands of files still to audit, just in this tarball,
not even getting to the main texlive package.
~spot
2:26 p.m.
On Thu, Jan 29, 2009 at 12:32 PM, Tom spot Callaway <tcallawa(a)redhat.com>wrote:
I cannot find licensing for:
- texmf-dist/fonts/type1/arphic/*
- texmf-dist/fonts/type1/bluesky/*
FWIW, information on the Blue Sky fonts can be found here:
http://www.ams.org/tex/type1-fonts.html
For the arphic fonts, see this:
http://www.arphic.com/usa/news/news.htm
--
Jerry James
http://loganjerry.googlepages.com/
2:55 p.m.
On 2009-01-29 at 15:26:24 -0500, Jerry James <loganjerry(a)gmail.com> wrote:
On Thu, Jan 29, 2009 at 12:32 PM, Tom spot Callaway
<tcallawa(a)redhat.com>wrote:
> I cannot find licensing for:
> - texmf-dist/fonts/type1/arphic/*
> - texmf-dist/fonts/type1/bluesky/*
>
FWIW, information on the Blue Sky fonts can be found here:
http://www.ams.org/tex/type1-fonts.html
Would be nice if that was in texlive somewhere (heck, it might be!).
For the arphic fonts, see this:
http://www.arphic.com/usa/news/news.htm
That's not a license. Its a mangled translation at best. However, it did
stir my memory:
http://ftp.gnu.org/gnu/non-gnu/chinese-fonts-truetype/LICENSE
So, at least those two items are taken care of, thanks. Want some more
to try to hunt down? :)
~spot
3:07 p.m.
If texlive is such a can of worms, why not "downgrade" to tetex? That's
still the RHEL tex solution. As a latex user, I noticed no functional
difference between the two other than that I have to go re-setup local
configuration stuff when fedora changed from tetex to texlive.
Alec
--
Alec Habig, University of Minnesota Duluth Physics Dept.
habig(a)neutrino.d.umn.edu
http://neutrino.d.umn.edu/~habig/
3:16 p.m.
>>>> "ATH" == Alec T Habig
<habig(a)neutrino.d.umn.edu> writes:
ATH> If texlive is such a can of worms, why not "downgrade" to tetex?
Is there some reason to believe that tetex was any better in this
regard?
ATH> That's still the RHEL tex solution. As a latex user, I noticed
ATH> no functional difference between the two other than that I have
ATH> to go re-setup local configuration stuff when fedora changed from
ATH> tetex to texlive.
I have had various users here (the math department at a large
university) who have issues with either bugs or missing packages in
tetex that are solved by texlive. The TeX mindset is that you must
always have every package in existence installed because you must
always be able to compile every document you might ever come across,
so random missing packages actually do cause problems for some users.
- J<
3:27 p.m.
Jason L Tibbitts III writes:
Is there some reason to believe that tetex was any better in this
regard?
Only that I assume RH's lawyers are more rabid about licenses than
Fedora's, having a giant market capitalization to protect.
Of course, if spot's actually the point man for both, then all bets are
off :)
I have had various users here (the math department at a large
university) who have issues with either bugs or missing packages in
tetex that are solved by texlive.
I'm sure that the actively maintained version is better than the
orphaned one overall. But, if licensing issues crept into the new that
weren't in the old one (which did pass muster at some point, anyway),
having some version of tex available is infinitely better than no
version.
Of course, if removed from Fedora the rpms will fork over to a
third-party repository somewhere anyhow, but that's sub-optimal for an
application that's been a core part of unix since long before linux
wandered on to the scene.
After all, without tex how would we compile the nethack manual? :)
--
Alec Habig, University of Minnesota Duluth Physics Dept.
habig(a)neutrino.d.umn.edu
http://neutrino.d.umn.edu/~habig/
3:30 p.m.
On Thu, 2009-01-29 at 15:27 -0600, Alec T. Habig wrote:
Jason L Tibbitts III writes:
>
> Is there some reason to believe that tetex was any better in this
> regard?
Only that I assume RH's lawyers are more rabid about licenses than
Fedora's, having a giant market capitalization to protect.
They're the same lawyers.
-sv
5:13 p.m.
2009/1/29 Alec T. Habig <habig(a)neutrino.d.umn.edu>:
If texlive is such a can of worms, why not "downgrade" to
tetex? That's
still the RHEL tex solution. As a latex user, I noticed no functional
difference between the two other than that I have to go re-setup local
configuration stuff when fedora changed from tetex to texlive.
For reference: Roughly speaking, when Jindrich put the texlive 2007
packages together, he looked at what packages were in tetex and
packaged those up - i.e. the Fedora texlive packages are a subset of
the full texlive 2007 distribution comprisiing more or less an updated
tetex.
Jonathan (Hoping Jindrich will correct me if I am wrong).
3:14 p.m.
On Thu, Jan 29, 2009 at 1:55 PM, Tom spot Callaway <tcallawa(a)redhat.com> wrote:
So, at least those two items are taken care of, thanks. Want some
more
to try to hunt down? :)
The name "Blue Sky" just happened to stir my memory, and I attempted
to be a good citizen by hunting down the arphic fonts at the same
time, which triggered your memory. If you have a list of unknowns
handy, I think posting it here could be very valuable, as it may
trigger yet more memories.
--
Jerry James
http://loganjerry.googlepages.com/
4:46 p.m.
On 2009-01-29 at 16:14:46 -0500, Jerry James <loganjerry(a)gmail.com> wrote:
On Thu, Jan 29, 2009 at 1:55 PM, Tom spot Callaway
<tcallawa(a)redhat.com> wrote:
> So, at least those two items are taken care of, thanks. Want some more
> to try to hunt down? :)
The name "Blue Sky" just happened to stir my memory, and I attempted
to be a good citizen by hunting down the arphic fonts at the same
time, which triggered your memory. If you have a list of unknowns
handy, I think posting it here could be very valuable, as it may
trigger yet more memories.
--
Jerry James
http://loganjerry.googlepages.com/
Okay, here are more files I can't find licensing for (all from
texlive-texmf-20080822):
(These are all the unlicensed files in the "texmf/" directory):
texmf/dvipdfm/*
texmf/dvipdfmx/*
texmf/dvips/base/*
texmf/dvips/config/*
texmf/fmtutil/*
texmf/fonts/enc/dvips/afm2pl/*
texmf/fonts/enc/ttf2pk/base/*
texmf/fonts/lig/afm2pl/*
texmf/fonts/map/*
texmf/fonts/sfd/*
texmf/hbf2gf/*
texmf/scripts/*
texmf/scripts/epstopdf/epstopdf.pl
texmf/tex/*
texmf/texconfig/*
texmf/texdoc/*
texmf/texdoctk/*
texmf/ttf2pk/*
texmf/web2c/*
texmf/xdvi/*
texmf/xindy/*
(These are just some of the unlicensed files in the "texmf-dist/"
directory, there are lots more I haven't had a chance to look at yet)
texmf-dist/fonts/type1/arabi/farsiweb/homa.pfb
texmf-dist/fonts/type1/arabi/farsiweb/nazlib.pfb
texmf-dist/fonts/type1/arabi/farsiweb/nazli.pfb
texmf-dist/fonts/type1/arabi/farsiweb/titr.pfb
texmf-dist/fonts/truetype/public/belleek/blex.ttf
texmf-dist/fonts/truetype/public/belleek/blsy.ttf
texmf-dist/fonts/truetype/public/belleek/rblmi.ttf
texmf-dist/fonts/truetype/public/itrans/itxbeng.ttf
texmf-dist/fonts/truetype/public/itrans/itxguj.ttf
texmf-dist/fonts/truetype/public/itrans/ncpi____.ttf
texmf-dist/fonts/truetype/public/itrans/ncpr____.ttf
texmf-dist/fonts/truetype/public/itrans/xdvng.ttf
texmf-dist/fonts/type1/groff/freeeuro.pfa
texmf-dist/fonts/type1/hoekwater/context/*
texmf-dist/fonts/type1/hoekwater/manfnt/manfnt.pfb
texmf-dist/fonts/type1/hoekwater/mflogo/*
texmf-dist/fonts/type1/hoekwater/stmaryrd/*
texmf-dist/fonts/type1/jmn/hans/*
texmf-dist/fonts/type1/public/arabtex/*
texmf-dist/fonts/type1/public/augie/augie___.pfb
texmf-dist/fonts/type1/public/aurical/*
texmf-dist/fonts/type1/public/burmese/burm.pfb
texmf-dist/fonts/type1/public/esint-type1/esint10.pfb
texmf-dist/fonts/type1/public/esvect/*
texmf-dist/fonts/type1/public/gothic/*
texmf-dist/fonts/type1/public/itrans/*
texmf-dist/fonts/type1/public/montex/*
texmf-dist/fonts/type1/public/ocherokee/*
texmf-dist/fonts/type1/public/oinuit/*
texmf-dist/fonts/type1/public/omega/*
texmf-dist/fonts/type1/public/pl/*
texmf-dist/fonts/type1/public/yhmath/yhcmex.pfb
texmf-dist/fonts/type1/uhc/umj/*
5:12 p.m.
Hm well I never thought about licensing issues regarding LaTeX...
When I look at:
http://tug.org/texlive/copying.html
They state:
"To the best of our knowledge, all the software in TeX Live meets the
requirements of the Free Software Foundation's definition of free
software, and the Debian Free Software Guidelines. Where the two
conflict, we generally follow the FSF."
So maybe you dont want to rely on such a statement. But that makes
quite an effort.
Some of the mentioned packages also where in tetex which was part in
fedora before and no one complained about license issues.
On Thu, 29 Jan 2009 17:46:06 -0500 "Tom \"spot\" Callaway"
<tcallawa(a)redhat.com> wrote:
TC> texmf/dvipdfmx/*
dvipdfmx at least is GPL see readme:
http://www.ctan.org/tex-archive/dviware/dvipdfmx/
It would be really sad removing texlive for those license oddities. It
would be quite some competitive disadvantage.
Stefan
9:23 a.m.
On 2009-01-29 at 18:12:56 -0500, Stefan Grosse <singularitaet(a)gmx.net>
wrote:
"To the best of our knowledge, all the software in TeX Live
meets the
requirements of the Free Software Foundation's definition of free
software, and the Debian Free Software Guidelines. Where the two
conflict, we generally follow the FSF."
So maybe you dont want to rely on such a statement. But that makes
quite an effort.
Especially given that we've found 10+ non-free files inside of it.
Some of the mentioned packages also where in tetex which was part in
fedora before and no one complained about license issues.
Tetex was never license audited, because we inherited it from Red Hat
Linux, and when I got to it, we were in the process of moving to
texlive. I did a cursory audit of the original texlive import and we
caught some things, but I was nowhere near as thorough when I did that
original audit. I've learned a LOT since then. :)
On Thu, 29 Jan 2009 17:46:06 -0500 "Tom \"spot\"
Callaway"
wrote:
TC> texmf/dvipdfmx/*
dvipdfmx at least is GPL see readme:
http://www.ctan.org/tex-archive/dviware/dvipdfmx/
Okay, so the trick is that I need to match up those files in texlive
with the ones from CTAN. I can't assume random files in a directory with
the same name as something sanely licensed are the same. This is a big
reason why you should always always always always always put licensing
attribution in each file included in tarball. Always always always.
It would be really sad removing texlive for those license oddities.
It
would be quite some competitive disadvantage.
Yes, but at the same time, we know that the texlive in Fedora now has
license issues. I've only scratched the surface of auditing texlive
2008. I'd rather be able to finish the audit and bring texlive 2008 into
Fedora, but there are only so many hours in the day.
~spot
5:54 p.m.
On Thu, Jan 29, 2009 at 5:46 PM, Tom spot Callaway wrote:
On 2009-01-29 at 16:14:46 -0500, Jerry James wrote:
> On Thu, Jan 29, 2009 at 1:55 PM, Tom spot Callaway wrote:
>> So, at least those two items are taken care of, thanks. Want some more
>> to try to hunt down? :)
>
> The name "Blue Sky" just happened to stir my memory, and I attempted
> to be a good citizen by hunting down the arphic fonts at the same
> time, which triggered your memory. If you have a list of unknowns
> handy, I think posting it here could be very valuable, as it may
> trigger yet more memories.
> --
> Jerry James
> http://loganjerry.googlepages.com/
>
Okay, here are more files I can't find licensing for (all from
texlive-texmf-20080822):
(These are all the unlicensed files in the "texmf/" directory):
texmf/dvipdfm/*
texmf/dvipdfmx/*
texmf/dvips/base/*
texmf/dvips/config/*
texmf/fmtutil/*
texmf/fonts/enc/dvips/afm2pl/*
texmf/fonts/enc/ttf2pk/base/*
texmf/fonts/lig/afm2pl/*
texmf/fonts/map/*
texmf/fonts/sfd/*
texmf/hbf2gf/*
texmf/scripts/*
texmf/scripts/epstopdf/epstopdf.pl
texmf/tex/*
texmf/texconfig/*
texmf/texdoc/*
texmf/texdoctk/*
texmf/ttf2pk/*
texmf/web2c/*
texmf/xdvi/*
texmf/xindy/*
(These are just some of the unlicensed files in the "texmf-dist/"
directory, there are lots more I haven't had a chance to look at yet)
texmf-dist/fonts/type1/arabi/farsiweb/homa.pfb
texmf-dist/fonts/type1/arabi/farsiweb/nazlib.pfb
texmf-dist/fonts/type1/arabi/farsiweb/nazli.pfb
texmf-dist/fonts/type1/arabi/farsiweb/titr.pfb
texmf-dist/fonts/truetype/public/belleek/blex.ttf
texmf-dist/fonts/truetype/public/belleek/blsy.ttf
texmf-dist/fonts/truetype/public/belleek/rblmi.ttf
texmf-dist/fonts/truetype/public/itrans/itxbeng.ttf
texmf-dist/fonts/truetype/public/itrans/itxguj.ttf
texmf-dist/fonts/truetype/public/itrans/ncpi____.ttf
texmf-dist/fonts/truetype/public/itrans/ncpr____.ttf
texmf-dist/fonts/truetype/public/itrans/xdvng.ttf
texmf-dist/fonts/type1/groff/freeeuro.pfa
texmf-dist/fonts/type1/hoekwater/context/*
texmf-dist/fonts/type1/hoekwater/manfnt/manfnt.pfb
texmf-dist/fonts/type1/hoekwater/mflogo/*
texmf-dist/fonts/type1/hoekwater/stmaryrd/*
texmf-dist/fonts/type1/jmn/hans/*
texmf-dist/fonts/type1/public/arabtex/*
texmf-dist/fonts/type1/public/augie/augie___.pfb
texmf-dist/fonts/type1/public/aurical/*
texmf-dist/fonts/type1/public/burmese/burm.pfb
texmf-dist/fonts/type1/public/esint-type1/esint10.pfb
texmf-dist/fonts/type1/public/esvect/*
texmf-dist/fonts/type1/public/gothic/*
texmf-dist/fonts/type1/public/itrans/*
texmf-dist/fonts/type1/public/montex/*
texmf-dist/fonts/type1/public/ocherokee/*
texmf-dist/fonts/type1/public/oinuit/*
texmf-dist/fonts/type1/public/omega/*
texmf-dist/fonts/type1/public/pl/*
texmf-dist/fonts/type1/public/yhmath/yhcmex.pfb
texmf-dist/fonts/type1/uhc/umj/*
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
You can find information on many of these TeX packages by going to:
http://tug.ctan.org/cgi-bin/ctanPackageInformation.py?id=XXX
Replace XXX with dvipdfm, web3c, arabtex etc.
Wow... Thinking about removing TeX from Fedora? I can't imagine how
many people will leave Fedora in the first minute with no hesitation.
Orcan
5:59 p.m.
2009/1/29 Orcan Ogetbil <oget.fedora(a)gmail.com>:
Wow... Thinking about removing TeX from Fedora? I can't imagine
how
many people will leave Fedora in the first minute with no hesitation.
Noone's suggested that (in any seriousness)... this is about moving
beyond texlive 2007 which is presently in Fedora.
J.
12:52 a.m.
Le jeudi 29 janvier 2009 à 23:59 +0000, Jonathan Underwood a écrit :
2009/1/29 Orcan Ogetbil <oget.fedora(a)gmail.com>:
> Wow... Thinking about removing TeX from Fedora? I can't imagine how
> many people will leave Fedora in the first minute with no hesitation.
Noone's suggested that (in any seriousness)... this is about moving
beyond texlive 2007 which is presently in Fedora.
Though eventually it will come to that if there is no resolution of TEX
problems. We can't carry for years in multiple releases packages with
known problems just because they were not identified before and now
there is a lack of people working to solve them. TEX users need to worry
about keeping our TEX packaging into shape IMHO, they should not rely on
inertia forever.
--
Nicolas Mailhot
5:01 a.m.
On Fri, Jan 30, 2009 at 07:52:36AM +0100, Nicolas Mailhot wrote:
Though eventually it will come to that if there is no resolution of TEX
problems. We can't carry for years in multiple releases packages with
known problems just because they were not identified before and now
there is a lack of people working to solve them. TEX users need to worry
about keeping our TEX packaging into shape IMHO, they should not rely on
inertia forever.
You make it look like TeX packaging is bad. It's not the case. The TeX
packaging is consistent with FHS and with upstream organization. We
can do better at integrating, for the fonts for instance. But this
doesn't render the TeX packaging bad or not acceptable. I can't see
the 'known problems' of the current TeX packaging. If you refer
to TeX fonts not being available for other packages, sure this is a
shortcoming, but not a problem.
(License issues are another matter, but mostly independent of the
packaging issues, and upstream is quick at resolving those, quick
here meaning for the next release).
--
Pat
7:37 a.m.
Le Ven 30 janvier 2009 12:01, Patrice Dumas a écrit :
On Fri, Jan 30, 2009 at 07:52:36AM +0100, Nicolas Mailhot wrote:
>
> Though eventually it will come to that if there is no resolution of
> TEX
> problems. We can't carry for years in multiple releases packages
> with
> known problems just because they were not identified before and now
> there is a lack of people working to solve them. TEX users need to
> worry
> about keeping our TEX packaging into shape IMHO, they should not
> rely on
> inertia forever.
You make it look like TeX packaging is bad. It's not the case. The TeX
packaging is consistent with FHS and with upstream organization. We
can do better at integrating, for the fonts for instance. But this
doesn't render the TeX packaging bad or not acceptable. I can't see
the 'known problems' of the current TeX packaging. If you refer
to TeX fonts not being available for other packages, sure this is a
shortcoming, but not a problem.
Well, if you handwave packaging guidelines conformance away, and legal
checks away, sure there are no problems and all is fine.
This is still normal maintenance work that needs to be done by someone
and can not be postponed indefinitely.
--
Nicolas Mailhot
8:10 a.m.
On Fri, Jan 30, 2009 at 02:37:13PM +0100, Nicolas Mailhot wrote:
Well, if you handwave packaging guidelines conformance away,
It is not the point. Exceptions can be made when the cost is high and
the benefit is low. This is the case here. Now, people who are unhappy
can fill bugs (you already did it) and escalate to the list and
to FESCo for conflict resolution. Nobody stops you from putting
removal of texlive from Fedora on the FESCo agenda.
But I think that the priority is updating to texlive 2008, not strict
guideline policy conformance.
and legal checks away, sure there are no problems and all is fine.
Legal checks were done during review, and it is an independent issue.
This is still normal maintenance work that needs to be done by
someone
and can not be postponed indefinitely.
Sure. But removing texlive is not going to make that happen faster,
on the contrary, Fedora will certainly lose all the TeX users and
contributors, who are already very few.
--
Pat
9:14 a.m.
On Fri, Jan 30, 2009 at 04:09:18PM +0100, Benjamín Valero Espinosa wrote:
2009/1/30 Patrice Dumas
> Sure. But removing texlive is not going to make that happen faster,
> on the contrary, Fedora will certainly lose all the TeX users and
> contributors, who are already very few.
Few users or few contributors?
Few contributors.
--
Pat
1:21 p.m.
Patrice Dumas wrote:
On Fri, Jan 30, 2009 at 02:37:13PM +0100, Nicolas Mailhot wrote:
> Well, if you handwave packaging guidelines conformance away,
It is not the point. Exceptions can be made when the cost is high and
the benefit is low.
I think making exceptions is a good thing. Our Guidelines should be
flexible enough to make exceptions when necessary. But setting up the
analysis of when to make exceptions as "cost is high and benefit is low"
is doomed to failure. There's a cost with any changes we make to how a
package wants to install when it comes fresh from upstream. And the
benefit to that *individual* package is low. But Fedora Linux, or any
Linux distribution, is more than the sum of its packages. We're giving
our users a unified experience that is different than merely having them
download the package source, compile and install it themselves. We're
giving them a unified, coherent set of programs which conform to certain
standards that it is possible for the end user to learn and apply to any
package that comes from us.
So rather than "cost is high, benefit is low", we need to understand
that exceptions are made when it doesn't make sense for the package to
follow the Guideline. Conforming violates the spirit of the upstream
package. It causes something to stop working with no way to fix it. By
its very nature, the package is supposed to violate the Guideline. And
when those are the case, we should be able to boil the Exception down to
some rule, know that that rule trumps the reasons for our current
Guideline, and write the Exception to cover that and future cases.
-Toshio
7:51 p.m.
On Fri, Jan 30, 2009 at 11:21:39AM -0800, Toshio Kuratomi wrote:
Patrice Dumas wrote:
> On Fri, Jan 30, 2009 at 02:37:13PM +0100, Nicolas Mailhot wrote:
>> Well, if you handwave packaging guidelines conformance away,
>
> It is not the point. Exceptions can be made when the cost is high and
> the benefit is low.
I think making exceptions is a good thing. Our Guidelines should be
flexible enough to make exceptions when necessary. But setting up the
analysis of when to make exceptions as "cost is high and benefit is low"
is doomed to failure. There's a cost with any changes we make to how a
I am not saying that this should always be a good reason, I think that,
in this precise case, it is.
I am against violation of the guidelines, I am for a packaging quality
as high as possible. But sometimes compromises has to be done. Or somebody
has to step up to do the work.
--
Pat
5:18 a.m.
2009/1/30 Nicolas Mailhot <nicolas.mailhot(a)laposte.net>:
Le jeudi 29 janvier 2009 à 23:59 +0000, Jonathan Underwood a écrit :
> 2009/1/29 Orcan Ogetbil <oget.fedora(a)gmail.com>:
> > Wow... Thinking about removing TeX from Fedora? I can't imagine how
> > many people will leave Fedora in the first minute with no hesitation.
>
> Noone's suggested that (in any seriousness)... this is about moving
> beyond texlive 2007 which is presently in Fedora.
Though eventually it will come to that if there is no resolution of TEX
problems. We can't carry for years in multiple releases packages with
known problems just because they were not identified before and now
there is a lack of people working to solve them. TEX users need to worry
about keeping our TEX packaging into shape IMHO, they should not rely on
inertia forever.
TeX, not TEX !
--
http://vnoss.org
5562
days inactive
5573
days old
54 comments
20 participants
participants (20)
-
Alec T. Habig -
Arnaud Gomes-do-Vale -
Benjamín Valero Espinosa -
Jason L Tibbitts III -
Jerry James -
Jesse Keating -
Jonathan Underwood -
Kevin Kofler -
Martin Sourada -
Matthias Clasen -
Neal Becker -
Nicolas Mailhot -
Orcan Ogetbil -
Patrice Dumas -
Rex Dieter -
Seth Vidal -
Stefan Grosse -
Tom Callaway -
Toshio Kuratomi -
Vnpenguin