Pledge of Allegiance. Please forward

[Ken Cutshall]

Title: Target E-mailing & Creative Services





  
 

  

  
 Targeted
  OPT-IN E-Mail Services
   Orlando,
  FL - Atlanta, GA
  
  
Looking for cost effective emailing? 
  Are you having difficulties with your emailiing?



  
407-539-0615
  - 404-806-6124
  
  Take us for
a test drive! 

  
  

  

  

   Targeted
Opt-In Mailings
& Campaign Hosting


  

  Tailored for your
individual needs. Highly targeted E-mail "Opt-In"
and Postal Mail campaigns.

Included in every campaign at no
extra cost: 
  Design
of your broadcast message including Graphics,

Conversion to HTML and Hosting.

Opt-In List Generation/Management: We can help
you generate your own opt-in lists or manage your current
lists for a fraction of what you would pay a broker.
 100% List "OWNERSHIP" !
  Web
Site Design: Let us design your private marketing site.

  News
Letter Promotions: Promote your company through monthly
newsletters. 
  RECEIVE
THE GREATEST RETURN ON YOUR MARKETING DOLLAR
  Targeted
Messages Delivered Base Price

500,000 Messages $1,750 
1 Million Messages $3,399 
2 Million Messages $4,499 
3 Million Messages $7,799 
5 Million Messages $12,299 
10 Million Messages $16,899 
  "Companies
who outsource their e-mail marketing operations actually
have a better conversion rate (6%) than companies that
do not (1.4%)."
  
  

  


  

  Fresh
Email Addresses


  

  The key to a good return on your email
campaign is NEW addresses. Our automated servers harvest
new addresses around the clock. We offer lists as a direct
purchase or as a monthly service.
  250,000 e-mails $100.00
500,000 e-mails $125.00
1,000,000 e-mails $200.00
5,000,000 e-mails $400.00

  Monthly
Service 150.00*
Includes: 
4,000,000 e-mails/month
'E-Mail-IT' Cloaking Software Updates
FTP Access
URL Cloaking Software 


  *Three
months required, lists and software download from our
FTP server.

  

  


  

  Email-IT
CSC Proxy Service


  

  Send your e-mails
directly through our servers. 
  Our in house 'Email-IT' True Stealth
System is based on Unix know-how sending technology,
providing real anonymous instant delivery. 

Forget problems with ISP 's your IP address will never
be shown in our e-mail headers. 
  You send directly into OUR servers which
then send your mail out to the world, FAST! 
  FAST! FAST! FAST!
Use your CABLE or DSL connection for mind blowing SPEEDS!

  'Email-IT' Pricing is based
on number of e-mails you can send monthly. You only pay
for what you send successfully!
  

Re: forwarded message from Jeff Licquia

[Nick Phillips]

On Thu, Jul 18, 2002 at 11:59:37AM +0200, Martin Schröder wrote:

> This is absolutely relevant. LaTeX is just a set of macros run
> through an interpreter. The interpreter happens to be some
> implementation of TeX. The security problems will be in the
> interpreter, not in the macros. And the parts of the
> implementation concerning these possible problems are under GPL.

Under the LPPL we are not allowed to fix the engine either; we have to wait
for D. E. Knuth to do it. Which I'm sure he would do, unless he happened
to have been run over by a bus that morning (unlikely, as he claims to be
sitting at home working on Volume 4 of The Art of Computer Programming
most of the time, but...). In which case we would have a nightmare time
trying to migrate all our LaTeX users from LaTeX to not-LaTeX, which would
be identical to LaTeX but for the fact that it used not-quite-TeX instead
of TeX...

If on the other hand the LaTeX license allowed us to do "whatever we like,
so long as anything that's called LaTeX produces identical output (documents)
to unmodified LaTeX for all valid input" then we could butcher LaTeX to use
a not-quite-TeX that had the bug fixed, and still produced identical output.

For example.


Cheers,


Nick
-- 
Nick Phillips -- [EMAIL PROTECTED]
Is this really happening?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LaTeX & DFSG

[Jeff Licquia]

On Thu, 2002-07-18 at 19:16, Mark Rafn wrote:
> On 18 Jul 2002, Jeff Licquia wrote:
> 
> > > Thanks, but no thanks. I do not want you to have this freedom. I do
> > > not want you to send me these "maybe altered" weights. I do not want
> > > you to be able to send them to anybody. I abhor the thought that my
> > > business associates, colleagues or anybody else might use your weights
> > > UNKNOWINGLY. You have the right to distribute any weights as long as
> > > you call them deb-kilograms or Pickwickian kilograms -- but please do
> > > not meddle with the standard weights.
> > 
> > This is a restriction the Debian Project can live with.
> 
> We can?  I guess this is the danger of analogies.  We can live with a
> restriction that an altered "kilogram" program may not have it's default
> invocation named "kilogram".  I hope we would not accept a package which
> specified that any derived work's output may not refer to 950g as a 
> kilogram.

No, but I think Boris is more concerned with your former example than
your latter one.

Think of it as fraud; a hacked LaTeX is calling itself "LaTeX"
fraudulently, as it were, just as a 950g "kilogram" is fraudulent. 
There's nothing wrong with making a 950g weight so long as it doesn't
pass itself off as a 1000g weight.  Similarly, it would seem that the
LaTeX Project doesn't really mind people hacking on LaTeX as long as
it's not called "latex".

> Here's another analogy:
> 
> Would you accept a mapping program that specified that Taiwan may not be
> shown in a color different from China?  Even if the authors only wanted to 
> ensure that all users got consistent output on different distributions?

I would think that this is a problem.  I'm not sure it relates to
Boris's objection, however.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LaTeX & DFSG

[Mark Rafn]

On 18 Jul 2002, Jeff Licquia wrote:

> > Thanks, but no thanks. I do not want you to have this freedom. I do
> > not want you to send me these "maybe altered" weights. I do not want
> > you to be able to send them to anybody. I abhor the thought that my
> > business associates, colleagues or anybody else might use your weights
> > UNKNOWINGLY. You have the right to distribute any weights as long as
> > you call them deb-kilograms or Pickwickian kilograms -- but please do
> > not meddle with the standard weights.
> 
> This is a restriction the Debian Project can live with.

We can?  I guess this is the danger of analogies.  We can live with a
restriction that an altered "kilogram" program may not have it's default
invocation named "kilogram".  I hope we would not accept a package which
specified that any derived work's output may not refer to 950g as a 
kilogram.

Here's another analogy:

Would you accept a mapping program that specified that Taiwan may not be
shown in a color different from China?  Even if the authors only wanted to 
ensure that all users got consistent output on different distributions?
--
Mark Rafn[EMAIL PROTECTED]  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LaTeX & DFSG

[Jeff Licquia]

On Thu, 2002-07-18 at 13:06, Boris Veytsman wrote:
> I think we finally got to understanding what is allowed and what is
> not in TeX and LaTeX licensing -- or at least in the licenses
> intentions. 
> 
> Right now I as an end user and developer have the following rights:
> 
> R1. Change the appearance of any document I got by adding the line
> inputting my set of macros to the document.
> 
> R2. Change the appearance of all documents by (1) using instead of the
> command "latex file" a command "modified-latex file" or (2)
> passing the corresponding options to tex or (3) using my own
> version of tex with different name.
> 
> R3. Distribute my macros, modified versions of latex, tex, fonts etc.,
> for profit or not, as long as I take care they will not be
> confused with the original tex, latex and fonts, and (in case of
> latex) impose the same "do not confuse users" restriction on the
> modified product (TeX is trademarked, so this restriction would be
> redundant for it).
> 
> Besides these right I have the following assurances:
> 
> A1. If I issue the command "latex file", the appearance of the
> resulting document will be exactly the same as intended by the
> author with discrepancy no more than tens of Angstroms.
> 
> A2. If I send my document to be latexed to my publisher, colleague,
> friend, the appearance of the document on their desks will be
> exactly same as on mine. This is true whether they use Debian
> Linux, FreeBSD, Windows, Macintosh or Palm Pilot.
> 
> A3. The propeties A1 and A2 are going to be there whether the document
> is processed today, tomorrow or in any foreseeable future.
> 
> Now what other rights are you talking about? This could not be my
> rights as a user a developer -- I have all that I need. Obviously it
> must be some other rights. Probably *your* rights. I take from the
> discussion that some people here want the right to modify parts of the
> TeX suite while still calling the thing TeX and LaTeX. In other words
> you want the right to change files on your server in such a way that
> "apt-get upgrade" will make my machine produce slightly different
> documents than my colleagues' machines. Worse than that, you want the
> right to dump these changes on other Debian machines -- while I can
> stop using your verson of LaTeX, I cannot presume my colleagues'
> admins are clueful enough to make this decision. 

No, not at all.  I think that your R3 right is the point of contention;
we do not believe that the draft of the LPPL we've seen confers that
right.

> Some people say they need this right to make (La)TeX more secure. This
> argument is purely hypothetical: there was no vulnerabilities reported
> during all the years of TeX and LaTeX existence, which is longer, than
> the existence of Linux or popularity of Unix and C. On the other case
> the dangers that LPPL tries to prevent are quite real: the story with
> "improved" CM fonts comes to my mind. Again, the people who improved
> CM fonts might think that they made a service to the community; they
> might consider the changes to be small. Nevertheless they are NOT
> small for me and I do not want this service. You break A1--A3 without
> meaningfully adding anything to R1--R3. 

Security is only one of many good reasons to change LaTeX, and it's
certainly a valid one, even for LaTeX.  The lack of security problems in
LaTeX is possible a happy accident of history rather than a real virtue
of its code.

Let's take an example that will likely resonate with typesetters a bit
more: the euro.  How did you arrange to add the euro symbol to TeX and
LaTeX?  What would have happened if I would have needed a euro symbol
before it was added?

> Thanks, but no thanks. I do not want you to have this freedom. I do
> not want you to send me these "maybe altered" weights. I do not want
> you to be able to send them to anybody. I abhor the thought that my
> business associates, colleagues or anybody else might use your weights
> UNKNOWINGLY. You have the right to distribute any weights as long as
> you call them deb-kilograms or Pickwickian kilograms -- but please do
> not meddle with the standard weights.

This is a restriction the Debian Project can live with.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LaTeX Public Project License, Version 1.3 (DRAFT)

[Jeff Licquia]

On Thu, 2002-07-18 at 10:54, Lars Hellström wrote:
> At 06.07 +0200 2002-07-17, Jeff Licquia wrote:
> >The problem is that *most of your good
> >points simply aren't in the license*, and the license is all I can rely
> >on when I try to figure out my rights.
> 
> Some of my points certainly refer more to what is the custom (for how the
> license is interpreted) than to what is necessarily in it. Frank has
> however made clear that the entire text of the license certainly is under
> the knife and hence that these points are not clear in the draft isn't,
> IMHO, a serious problem. What most (La)TeX users participating in this
> discussion are interested in isn't primarily that the text of the license
> is preserved, but that the *spirit* of it (as reflected in common practice)
> is.

I think we understand this now.  The problem is that a license is a very
poor "community standards" document, just as the law in general is a
very poor "community standards" document.  The understandings that you
have amongst yourselves aren't available to newcomers reading your
license for the first time.

> > - no, a "file" is not "something covered by the LPPL".
> 
> My point was that the LPPL by itself has no built-in relevance for a file.
> There must also be a legal notice (created by the copyright holder for that
> file) stating that the terms of the LPPL applies for this file. In the case
> of LaTeX (the work), this legal notice is in the file legal.txt, and it
> defines LaTeX (the work) to be the contents of a set of files, which are
> listed by name (in the file manifest.txt). In the case of the `pig' package
> that is used as an example in the LPPL, we find
> 
>   % This program consists of the files pig.dtx and pig.ins
>   % and the derived file pig.sty.
> 
> so that there is again a definition of which are the files of The Program.

Yes, but people are not generally distributing two files that generate a
third; they are distributing a tarball.  The tarball is a derivative
work of the individual files contained within it, and as such has its
own copyright and licensing questions.

The license is clear that it applies to each of the files in the Program
separately, regardless of their status as part of an archive file.  The
problem is that the archive file itself appears to be in a legal limbo. 
By default, the archive file is assumed to be covered under the same
license as the files within it; however, the Project thinks of it in a
different way.

Where this becomes important is when a user asserts a right under the
LPPL that you didn't think you had granted.

> > - no, since you aren't allowed to distribute the Program in modified
> >form, non-free "additional restrictions" cannot be removed.
> 
> I have not claimed the contrary. A program with additional non-free
> restrictions is not free, but that doesn't say the LPPL by itself is a
> non-free license, just that works that from a _modification_ viewpoint are
> non-free can be _distributed_ under the terms of the LPPL. What we ask is
> that (some version of) the LPPL without additional conditions is approved
> by Debian, not that all possible extensions of the LPPL are approved.

The problem is that our approval of the LPPL by itself tells us very
little.  The presence of a single non-free file makes our evaluation of
the LPPL moot, since we cannot (in fact) distribute the combined work
under the LPPL with such a file.

This is one of the things we like about the GPL.  When a work is
licensed under it, you know what your rights are with the whole of the
work, with each piece, and with any combinations.

> >> Noone would license foo-1.0.tar.gz under the LPPL. What is licensed under
> >> the LPPL are files archived in foo-1.0.tar.gz.
> >
> >Then the file foo-1.0.tar.gz itself has no license, and cannot be
> >distributed at all.
> 
> The matter of whether a file has a license has absolutely no relevance for
> whether it is techincally possible to distribute a file. Is it legally
> relevant? A license certainly grants various rights and so on, but I doubt
> it would be required by any existing legal system. Is it necessary for
> Debian to distribute it? That's mainly a matter of policy.

Actually, pretty much every existing legal system I know of requires a
license to copy any copyrighted file.  If you don't have a license, you
can't make verbatim copies and distribute them, period.

> The point of view that I believe to be relevant here is that creating a
> tarball is equivalent to copying the contents to a new file system.

This is an interesting point of view.  Unfortunately, it is not
expressly written out in the license as presented.  This means that it
has no value as a tool of enforcement; if I choose to interpret the
legal status of the tarball differently, then it becomes a matter for
the courts to decide who's right.  And if I can show that my
interpretation is reasonable, then mine could be held to trump yours.

What the court would say to you if you protes

Re: Distributing GPL Software as binary ISO

[Simon Law]

On Thu, Jul 18, 2002 at 01:34:34PM -0500, Steve Langasek wrote:
> On Thu, Jul 18, 2002 at 08:04:03PM +0200, Martin Schulze wrote:
> > I'm asking what A and B should do to bring themselves into
> > compliance.  I don't want to sue or attack entities.  I would like to
> > document the required behaviour somewhere, though, so entities know
> > what their obligation is if they are repackaging and redistributing
> > the Debian system.
> 
> Once A or B has distributed GPLed binaries in this manner without the
> source, the offense is there, and they are vulnerable to a lawsuit
> because of the license violation.  C.f. the widely-publicized MySQL
> court case.  Assuming all parties are acting in good faith, which has
> tended to be the case in the Free Software community, it is probably
> sufficient if A and B take steps to ensure that all further distribution
> of binaries complies with the GPL.  If A or B knows how to reach some or
> all of those they distributed binaries to commercially, as an additional
> show of good faith they might send a copy of the sources to these
> recipients as the GPL originally required them to do.

Also remember that once someone has violated the GPL, they are
no longer licensed and do _not_ have the freedoms granted by the GPL.
Thus, many companies like to settle in a mutually acceptable agreement.

Simon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LaTeX & DFSG

[Mark Rafn]

On Thu, 18 Jul 2002, Boris Veytsman wrote:

> Right now I as an end user and developer have the following rights:
> 
> R1. Change the appearance of any document I got by adding the line
> inputting my set of macros to the document.

This was never in contention, and is irrelevant to the freedom of the 
processing software.

> R2. Change the appearance of all documents by (1) using instead of the
> command "latex file" a command "modified-latex file" or (2)
> passing the corresponding options to tex or (3) using my own
> version of tex with different name.

This seems untrue.  The current proposal is that in addition to naming the 
main invocation command something other than latex, there are a bunch of 
files that cannot be changed without renaming.  I have no clue how onerous 
this is in practice, but it definitely makes modification more difficult 
than you state.  Perhaps difficult enough that it qualifies as non-free.

> R3. Distribute my macros, modified versions of latex, tex, fonts etc.,
> for profit or not, as long as I take care they will not be
> confused with the original tex, latex and fonts, and (in case of
> latex) impose the same "do not confuse users" restriction on the
> modified product (TeX is trademarked, so this restriction would be
> redundant for it).

This is true for some modifications.  The issue under discussion is the 
judgement call of whether the "do not confuse users" restriction is 
implemented so intrusively that R2 is infringed.

> A1. If I issue the command "latex file", the appearance of the
> resulting document will be exactly the same as intended by the
> author with discrepancy no more than tens of Angstroms.

Sure if "latex" even exists.  The modified version latex-local may be all 
you have.  In that case, you'll need to get the original sources and build 
it yourself.  Which you could do anyway without the license restriction.

> A2. If I send my document to be latexed to my publisher, colleague,
> friend, the appearance of the document on their desks will be
> exactly same as on mine. This is true whether they use Debian
> Linux, FreeBSD, Windows, Macintosh or Palm Pilot.

Sure, unless they use latex-local for all their processing.

> A3. The propeties A1 and A2 are going to be there whether the document
> is processed today, tomorrow or in any foreseeable future.

With enough caveats that it's not much of an assurance.

> Now what other rights are you talking about? This could not be my
> rights as a user a developer -- I have all that I need.

"All the rights you need" is a scary concept, but I'll let it go.  The 
rights you list are sufficient to go into Debian, IFF recipients of the 
software really have them as you state.  

>From the discussion so far, R2 is much more restricted than you state.  
Since the assurances you list aren't really assured, why not drop the 
restrictions on the rights?

> must be some other rights. Probably *your* rights. I take from the
> discussion that some people here want the right to modify parts of the
> TeX suite while still calling the thing TeX and LaTeX.

Nope.  Nobody objects to calling the project or invocation file something
other than latex.  We object to the necessity of managing implementation
details like filenames inside our derived work.

If the license clearly states that we're allowed to have modified versions 
of any file in the package as long as we don't call the package latex, the 
discussion is done.  It's free software.  

> In other words
> you want the right to change files on your server in such a way that
> "apt-get upgrade" will make my machine produce slightly different
> documents than my colleagues' machines. Worse than that, you want the
> right to dump these changes on other Debian machines -- while I can
> stop using your verson of LaTeX, I cannot presume my colleagues'
> admins are clueful enough to make this decision. 

According to R2, that right already exists.  latex-deb could change
radically.  Latex is guaranteed to be pristine, though it's not guaranteed
to work (or exist) at all.

> Note that it is not a right to try to make a better LaTeX than LaTeX:

Why not?  R2 as you state it allows this, as long as it's named ltx++ or
something that isn't latex.

> Some people say they need this right to make (La)TeX more secure.

They're off on a tangent.  The right we need is for our users to be able 
to change software we distribute however they want.  

> the dangers that LPPL tries to prevent are quite real: the story with
> "improved" CM fonts comes to my mind. Again, the people who improved
> CM fonts might think that they made a service to the community; they
> might consider the changes to be small.

Small or large, the freedom to change the behavior is the key.

> Nevertheless they are NOT small for me and I do not want this service.

Nobody forces you to accept this service.  Get the original package, or 
use a distribution tha

Re: User's thoughts about LPPL

[Jeff Licquia]

On Thu, 2002-07-18 at 13:22, Mark Rafn wrote:
> On Thu, 18 Jul 2002, David Carlisle wrote:
> 
> > Changing the font metrics isn't like changing a picture file
> > it's like changing your png renderer so that the same file produces a
> > different image. ie the result document changes with no apparent change
> > to that source document.
> 
> I agree with David - changing font metrics is similar to changing the 
> engine.  If I can't change the engine (even if the result is incompatible 
> with the original), I don't have free software.
> 
> A license that prevents me from making such a change to a png renderer and 
> distributing the result is not free either.

OK, let me clarify here.

I am trying to avoid rehashing an old argument that isn't getting
resolved now, and is really orthogonal to the question of whether LaTeX
is DFSG-free or not.

The question of "data freedom" or "font freedom" or whatever affects
many more packages than TeX, and doesn't affect TeX in any way that it
doesn't affect these other packages.  In addition, we have concerns
about real executable code here that no one disputes is functional, so
it's not like the fonts are the only problem here.

Again, if you're interested, read the thread I posted links to earlier. 
In the meantime, please, let's keep focus.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LaTeX & DFSG

[Bernhard R. Link]

* Boris Veytsman <[EMAIL PROTECTED]> [020718 20:07]:
> Let me tell yuo this way. I am FOR the freedom of speech. However, I
> am against the freedom of my grocer to call a 950g weight "a
> kilogram". 

And I am for the right to call a 1000g a kilogram, whatever somebody
else say it is.

Though there may be restrictions. If some authorative entity defines
an kilogram as 1010g, is may be valid to be fobidden to use kilogram
as 1000g in advertisements or to confuse people. But I still want the 
right to use the word kilogram as 1000g for my own thing and with 
friends and others that think like me.

> Thanks, but no thanks. I do not want you to have this freedom. I do
> not want you to send me these "maybe altered" weights. I do not want
> you to be able to send them to anybody. I abhor the thought that my
> business associates, colleagues or anybody else might use your weights
> UNKNOWINGLY. You have the right to distribute any weights as long as
> you call them deb-kilograms or Pickwickian kilograms -- but please do
> not meddle with the standard weights.

I think noone will find restrictions non-free, that depend prominent
notifications and messages when distributing changed things. (Or
restrictions about advertising this as LaTeX and so on, though this
would be abuse of copyright, as there are other laws for trademarks)

An restriction for a binary-name may within acceptable restrictions,
though it might cause most people to have to unmodified program called
an other way (like apache->httpd) just to ensure that needed changes
can be made easily.

Perhaps the requirement for single files might be the same, as
I know of no way to forbid something simular to a 
´mv article.cls xyz123.gaga ; echo "\input xyz123.gaga" > article.cls´,
but this is an other point.

As said in my other mail, noone hopes it might be necessary to make
changes in my eyes. But how can we make an exception for LaTeX and
still reasonable reject those we do not trust that much? 

Hochachtungsvoll,
  Bernhard R. Link


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: User's thoughts about LPPL

[Sam Hartman]

> "Javier" == Javier Bezos <[EMAIL PROTECTED]> writes:

Javier> Thanks for saying "apparently" :-). We are repeating and
Javier> repeating again than you can rewrite latex in full, if you
Javier> want.

MMM, someone on the Debian side here should write up an instructive
rant on what source code means focusing on the preferred form for
editing definition.  I disagree that the source code (as we think of
it) is available to all documents.  The source to LaTeX isn't even on
my system.  The source goes through a bunch of transformations from
the .dtx files to produce the .cls and other files.

The LaTeX community's point remains--you can change any aspect of the
behavior of LaTeX from within a document.  But you do not get the
editable form of LaTeX source from within a document.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Distributing GPL Software as binary ISO

[Steve Langasek]

On Thu, Jul 18, 2002 at 08:04:03PM +0200, Martin Schulze wrote:
> Steve Langasek wrote:
> > >  4. What would be the proper way to solve this problem if a) or b) are
> > > not in complience with the license terms?

> > Are you asking what A and B should do if they wish to bring themselves
> > into compliance, or are you asking what can be done to legally force
> > them to?

> I'm asking what A and B should do to bring themselves into
> compliance.  I don't want to sue or attack entities.  I would like to
> document the required behaviour somewhere, though, so entities know
> what their obligation is if they are repackaging and redistributing
> the Debian system.

Once A or B has distributed GPLed binaries in this manner without the
source, the offense is there, and they are vulnerable to a lawsuit
because of the license violation.  C.f. the widely-publicized MySQL
court case.  Assuming all parties are acting in good faith, which has
tended to be the case in the Free Software community, it is probably
sufficient if A and B take steps to ensure that all further distribution
of binaries complies with the GPL.  If A or B knows how to reach some or
all of those they distributed binaries to commercially, as an additional
show of good faith they might send a copy of the sources to these
recipients as the GPL originally required them to do.

The best remedy, however, is still to avoid violating the GPL in the
first place; while I believe that most authors of Free Software are
willing to forgive innocent mistakes, neither Debian nor anyone else can
protect A and B from a lawsuit if this turns out to not be the case.

Steve Langasek
postmodern programmer


pgpODlvldtc8q.pgp
Description: PGP signature

Re: User's thoughts about LPPL

[Mark Rafn]

On Thu, 18 Jul 2002, David Carlisle wrote:

> Changing the font metrics isn't like changing a picture file
> it's like changing your png renderer so that the same file produces a
> different image. ie the result document changes with no apparent change
> to that source document.

I agree with David - changing font metrics is similar to changing the 
engine.  If I can't change the engine (even if the result is incompatible 
with the original), I don't have free software.

A license that prevents me from making such a change to a png renderer and 
distributing the result is not free either.
--
Mark Rafn[EMAIL PROTECTED]  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: forwarded message from Jeff Licquia

[Bernhard R. Link]

* Timothy Murphy <[EMAIL PROTECTED]> [020717 23:00]:
> (1) The intersection of those interested in LaTeX
> and those seriously interested in Debian is almost empty, I imagine.
> I would have said it was empty, 
> except that Frank Mittelbach seems to belong to both sets.

It may be nearly empty for the developers, but the userbase has an large
intersection in my eyes. People judging effiency more than WYSWYG and
inital ease of use tend to use Debian and LaTeX.

> (2) You (or someone else on the Debian "side")
> asked for the "LaTeX community" to comment on the discussion.
> I'm an ordinary LaTeX user,
> but I'm pretty sure that I speak for 95% (if not 100%) of LaTeX users
> when I say that satisfying the Debian licence
> comes very low indeed in my order of priorities.

Those persons I know, that use LaTeX for more then their diploma-
thesises and the like, do also note freedom of their software very high.

> (3) Debian does not have a monopoly of the word "free".
> I suggest that if you do not want to be offensive
> you should say "Debian-free" or "free in the Debian sense".

Sorry. But any word has a context. Microsoft Word is "free", too.
You can get it without paying when buying computers in some shops.
And Linux is "non-free", as you do not have the right to reduce the
freedom. This in mind the term "Free Software" nowadays has
in large areas a meaning that fit very well with the meaning in Debian.

> (4) There is no need for Debian or anyone else to modify the LaTeX kernel,
> since you can make any changes you want in a package (.sty file).
> So the whole discussion seems to me entirely theological.

This discussion is theological, because the sibject is.

I think noone wants to change the (La)TeX-Kernel, noone want do make
.tex-file iterchange impossible. We all want the LaTeX to be the
usefull crossplattform tool that it is.

But though we do not want to do it, we want to have the right to
choose this ourselves. We do not want to depend on anyone to be
able to bring our computers in workable state.

It's about principles. We all judge it very unlikely that the LaTeX-
developers will go nuts or a has-to-be-fixed-fast security update
has to be done. (As I think it is very unlikely that police would
suspect me for anything, but am against allowing them to tortue
suspects)
And it is this principle to demand software to be free is one
of the foundations of Debian and it is an important point for
many of the people I know. (Though I doubt any would stop using
LaTeX)

As I have not looked into the licenses, I do not yet have made
up an opinion for myself wheater they are non-free, as I can
not think of any licence that would effectfuly allow what
you want to be allowed and forbid what you want to forbid.
Escpeccially preventing local changes (that are not distributed)
by copyright law seems to be quite hard for me. (It might
be a little bit difficult to make such changes legally, if 
the rights of the users are inadequatly restricted, but not 
impossible, as extreme examples like patches for games have 
shown)

Hochachtungsvoll,
  Bernhard R. Link

-- 
 sagen wir mal...ich hab alle sourcen in /lost+found/waimea
 gEistiO: [...] Warum lost+found?
 wo haette ich es denn sonst hingeben solln?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: User's thoughts about LPPL

[Glenn Maynard]

On Thu, Jul 18, 2002 at 12:55:43PM +0200, Javier Bezos wrote:
> >> but the documents created using that distribution. If I get a
> >> document by "John Smith" (somehow), how can I see if _his_
> >> system had a modified latex?

Others (eg Boris) seem to be saying that the Latex developers don't
mind if you rename Latex to something else and modify it such that
\usepackage{article} in a document does something different than it
does in the real latex.  You're contradicting this, so I'll discontinue
this thread unless Frank or David speaks up to clarify this.

-- 
Glenn Maynard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Distributing GPL Software as binary ISO

[Martin Schulze]

Steve Langasek wrote:
> >  4. What would be the proper way to solve this problem if a) or b) are
> > not in complience with the license terms?
> 
> Are you asking what A and B should do if they wish to bring themselves
> into compliance, or are you asking what can be done to legally force
> them to?

I'm asking what A and B should do to bring themselves into
compliance.  I don't want to sue or attack entities.  I would like to
document the required behaviour somewhere, though, so entities know
what their obligation is if they are repackaging and redistributing
the Debian system.

Regards,

Joey

-- 
There are lies, statistics and benchmarks.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

LaTeX & DFSG

[Boris Veytsman]

> Date: Thu, 18 Jul 2002 09:43:15 -0400
> From: Peter S Galbraith <[EMAIL PROTECTED]>
> 
> I have always appreciated the fact that you could run latex on 10
> year-old sources and get the same output, but I have also come to
> appreciate the rights granted by DFSG-compliant software.  
> 

I think we finally got to understanding what is allowed and what is
not in TeX and LaTeX licensing -- or at least in the licenses
intentions. 

Right now I as an end user and developer have the following rights:

R1. Change the appearance of any document I got by adding the line
inputting my set of macros to the document.

R2. Change the appearance of all documents by (1) using instead of the
command "latex file" a command "modified-latex file" or (2)
passing the corresponding options to tex or (3) using my own
version of tex with different name.

R3. Distribute my macros, modified versions of latex, tex, fonts etc.,
for profit or not, as long as I take care they will not be
confused with the original tex, latex and fonts, and (in case of
latex) impose the same "do not confuse users" restriction on the
modified product (TeX is trademarked, so this restriction would be
redundant for it).

Besides these right I have the following assurances:

A1. If I issue the command "latex file", the appearance of the
resulting document will be exactly the same as intended by the
author with discrepancy no more than tens of Angstroms.

A2. If I send my document to be latexed to my publisher, colleague,
friend, the appearance of the document on their desks will be
exactly same as on mine. This is true whether they use Debian
Linux, FreeBSD, Windows, Macintosh or Palm Pilot.

A3. The propeties A1 and A2 are going to be there whether the document
is processed today, tomorrow or in any foreseeable future.

Now what other rights are you talking about? This could not be my
rights as a user a developer -- I have all that I need. Obviously it
must be some other rights. Probably *your* rights. I take from the
discussion that some people here want the right to modify parts of the
TeX suite while still calling the thing TeX and LaTeX. In other words
you want the right to change files on your server in such a way that
"apt-get upgrade" will make my machine produce slightly different
documents than my colleagues' machines. Worse than that, you want the
right to dump these changes on other Debian machines -- while I can
stop using your verson of LaTeX, I cannot presume my colleagues'
admins are clueful enough to make this decision. 

Note that it is not a right to try to make a better LaTeX than LaTeX:
this right is already there and was excersized by, say, ConTeXt
team. This is exactly the right to break the existing standard.

Some people say they need this right to make (La)TeX more secure. This
argument is purely hypothetical: there was no vulnerabilities reported
during all the years of TeX and LaTeX existence, which is longer, than
the existence of Linux or popularity of Unix and C. On the other case
the dangers that LPPL tries to prevent are quite real: the story with
"improved" CM fonts comes to my mind. Again, the people who improved
CM fonts might think that they made a service to the community; they
might consider the changes to be small. Nevertheless they are NOT
small for me and I do not want this service. You break A1--A3 without
meaningfully adding anything to R1--R3. 

Let me tell yuo this way. I am FOR the freedom of speech. However, I
am against the freedom of my grocer to call a 950g weight "a
kilogram". 

To extend this analogy, I might say to an imaginary Debian maintainer:
you make beautiful toolsets and distribute them for free. Thanks. I
got used to your tools and really prefer them. However, it came to
your attention that your toolset includes a carefully crafted set of
standard weights. You now say that you need a freedom to make 950 g
weights and call them kilograms. You say that these weights might be
better or more secure.  You even assure me that you might never need
to excersize this right or that your weights might be 999 g. However,
you consider the right to distribute altered kilograms very
important. 

Thanks, but no thanks. I do not want you to have this freedom. I do
not want you to send me these "maybe altered" weights. I do not want
you to be able to send them to anybody. I abhor the thought that my
business associates, colleagues or anybody else might use your weights
UNKNOWINGLY. You have the right to distribute any weights as long as
you call them deb-kilograms or Pickwickian kilograms -- but please do
not meddle with the standard weights.

-- 
Good luck

-Boris

Dear Emily:
Today I posted an article and forgot to include my signature.
What should I do?
-- Forgetful

Dear Forgetful:
Rush to your terminal right away and post an article that says,
"Oops, I forgot to post my signature with that last article.  Here
it is."

Re: forwarded message from Jeff Licquia

[Scott Dier]

On Thu, 2002-07-18 at 04:59, Martin Schröder wrote:
> The same applies to PostScript: One fixes security holes in the
> interpreter (e.g. GhostScript) and doesn't worry about the
> PostScript files.

Actually, afair, postscript is 'feature complete' on some platforms and
has the ability to muck with filesystems.  Having a postscript file nuke
your homedirectory would suck, wouldn't it?  I think ghostscript uses a
'safe' mode by default, however.

In any case, lets say one of the scripts decided to use /tmp in a stupid
way...  I don't know whats possible in TeX, however.

In any case, I agree with others in this group.  Non-free is non-free.

-- 
Scott Dier <[EMAIL PROTECTED]> http://www.ringworld.org/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: forwarded message from Jeff Licquia

[Jeff Licquia]

On Thu, 2002-07-18 at 04:59, Martin Schröder wrote:
> On 2002-07-17 14:24:15 -0500, Jeff Licquia wrote:
> > On Wed, 2002-07-17 at 12:23, Javier Bezos wrote:
> > > Let's put it in other words. TeX leaves to the distribution
> > > the decision about how files are read/written. tetex
> > > decides how files are read/written and it's under GPL. Thus, you
> > > can change it if you want. Nothing to do with LaTeX ot LPPL.
> > > After that, explaining the problem of holes in our dangerous
> > > time can be interesting but it's certainly irrelevant.
> > 
> > This is irrelevant to my position as stated:
> 
> This is absolutely relevant. LaTeX is just a set of macros run
> through an interpreter.

So interpreted languages cannot be insecure?

-
#!/usr/bin/python

import os
os.unlink("/etc/passwd")
-

I take it that you would think the proper solution to this problem is to
remove the os.unlink() function from Python?

> The same applies to PostScript: One fixes security holes in the
> interpreter (e.g. GhostScript) and doesn't worry about the
> PostScript files.

This is not true.  There are lots of things that you can do in
PostScript by design that can delete files, consume available memory,
etc.  That is not the fault of PostScript, but the particular PostScript
files you run.

You seem to be confusing bugs in the interpreter with bugs in
interpreted programs.  It is possible for an interpreter to be bug-free,
but programs written in that interpreted language to have bugs.

You also seem to have a lot of faith in sandboxing.  Sandboxes work *if
the sandbox model is correct* and the implementation has no bugs.  Ask
the Java people about how sandbox models can be incorrect.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: User's thoughts about LPPL

[David Carlisle]

> Well, yes.  OTOH, substituting pictures can also change layout, and
> pictures are clearly non-functional data.

document formatting systems have fonts they use in all documents.
They don't usually have pictures they use in all documents.

Changing the font metrics isn't like changing a picture file
it's like changing your png renderer so that the same file produces a
different image. ie the result document changes with no apparent change
to that source document.

> I hope not.
well that was just an initial reaction. I suspect having got this far we
will do a LPPL 1.3 version:-)


David

_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: forwarded message from Jeff Licquia

[Jeff Licquia]

On Thu, 2002-07-18 at 03:59, David Carlisle wrote:
> > I did not see any statement to this effect in the LPPL draft that was
> > posted here:
> > 
> > http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg7.html
> > 
> > I would love to hear that I had completely missed it, or that you've
> > changed the draft to include such a statement.
> 
> My understanding is that no such statement is necessary (but there is
> one anyway:-)

That's good to hear.  At some point, it might be fruitful to post the
latest draft, so we don't argue over things that are already resolved. 
I don't know what the status of the draft is, though, or whether there
are some more changes needed, so I'll leave that to you to decide.

In licensing, you have to assume that nothing is allowed unless
permission is explicitly granted.  Explanatory text that lays out how
you're able to exercise freedoms granted to the licensee (such as being
able to create "mylatex" and how to override the default classes and
such) is also good to avoid problems.

> (Also it's difficult for latex to talk of command names, even more than
> files, latex is used on systems with no command line, so you have to
> interpret "command name" as "menu option or icony thing or anything else
> that can be reasonably construed as starting the program from a user
> action", which propbably isn't legally watertight...)

Right.  Definitions are key; something like this might be closer:

"For the purposes of this license, a 'command name' constitutes any
method of starting the Program, including but not limited to commands
typed at command shells and clickable icons in a graphical environment."

You could then reference that definition in your restrictions.

Of course, IANAL; if you have access to one, they might be able to write
you a better definition.

> pslatex does not modify any of the latex source or run time files
> so is clearly not in breach of the LPPL. It does have a pile of extra
> tex macros that redefine chunks of latex, but LPPL explictly does not
> forbid redefintions it just says such redefinitions should not be in a
> file of the same name as the original.
> 
> Then wrapping it all up it has a new shell script which called "pslatex"
> which calls standard latex on the user's document while inserting the
> redefinitions in a suitably cunning way. This shell script again is not
> a modification of any part of latex and doesn't share any name with any
> part of latex so clearly is not in breach of LPPL.

I see.  So the process of modifying LaTeX involves a "runtime patch
system" of sorts, where a LaTeX document's calling of the "article"
class gets redirected to the file "article-hacked".  The original
"article" must remain, then, but never gets used in the LaTeX-alike
system, although it will continue to be used in standard LaTeX when that
is called.

That's the part that has been confusing me the most, I think.  No, I
don't see that as unreasonable, or non-free.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: User's thoughts about LPPL

[Jeff Licquia]

On Thu, 2002-07-18 at 03:28, David Carlisle wrote:
> 
> > Additionally, there is the question
> > of defining "non-functional" data; some kinds of data, such as fonts,
> > have functional impact
> 
> for a system like latex the fonts (or at least their metrics) have as
> much impact as the rest of the system. Modifying the font metrics is
> even more likely to change the final document layout than changing the
> latex macros (most of which are not used in any given document run).

Well, yes.  OTOH, substituting pictures can also change layout, and
pictures are clearly non-functional data.

You may be right; fonts may be too "functional" to waive the DFSG for
them.  But that's a bridge we'll have to come to at some point, and it
affects far more things than just TeX.

> >  if the time comes to act, CM fonts can be moved to non-free then.
> 
> In that case probably it's best if we just all come back then.
> It will be a lot of work finalising the details of a rewrite of LPPL
> and if the only benefit of that is that you declare LaTeX suitable for
> the free part of Debian, that effort will be completely wasted if TeX
> and the fonts are not in the free part.

I hope not.  Hopefully, the license you craft with our input will be a
stronger license, and will more clearly reflect your priorities.  I
think there have been several cases where we've identified
characteristics of your license that do not reflect your stated goals.

> I'd like to see LaTeX classed as Free by Debian (because it is Free)
> but distributing LaTeX separately from TeX would be non sensical
> and lead to massive user confusion. So if TeX and the CM fonts were in
> non-free I'd suggest you distribute latex from there as well, even if
> latex had a licence that you would be happy to classify as free.

Yes.  We cover this problem with a section called "contrib", which
contains DFSG-free software that depends on non-free software.  A lot of
Java software falls into this section, for example.

So if the LPPL ends up being DFSG-free but TeX is not, we won't take
that away from you.

> So I don't think we can do anything about the latex licence until 
> then. (This is a personal response to your comments, Frank may have
> different ideas, especially as he's spent a lot of time redrafting
> LPPL this last month and is (I thought) almost there as regards
> addressing any concerns raised by Debian with the old version.)

I haven't seen his response yet, and am looking forward to it.  I urge
him (and you) to stay engaged if you would, as I think our discussion
has been profitable in many ways.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: spokesman (was Re: User's thoughts about LPPL)

[Sam Hartman]

> "Boris" == Boris Veytsman <[EMAIL PROTECTED]> writes:
Boris> This is exactly the same with LaTeX. If you create a new
Boris> format newlatex.fmt and symlink /usr/bin/tex to
Boris> /usr/bin/newlatex (this is the UNIX TeX way to use
Boris> formats), then you have a complete freedom to load
Boris> newarticle.cls whenever your document calls article.cls.

Hmm. An interesting point.  From a purely pragmatic standpoint I
suspect Debian would simply choose to keep its current LaTeX packages
rather than write infrastructure for this sort of support.  It would
certainly be enough to convince me to stop using LaTeX.

It would be ironic if Debian ended up forking LaTeX because of a
license designed to promote standardization.


But you're right, if the LaTeX license allows this  it may be DFSG free.

There's another issue though.  When I discussed TeX, I carefully
avoided discussing whether the TeX license allows us to have a
modified version of TeX (which does not pass trip) invoked by
/usr/bin/tex.  We cannot call that program TeX.  However it is not
clear to me that having an executable called TeX to preserve makefiles
that depend on being able to shell out to /usr/bin/tex counts as
calling a program TeX.

The Debian community may decide that restricting API constants like
filenames or command names violates DFSG 3, by precluding large
classes of derived works where as restricting what a program can be
called in some vague sense referring more to documentation, claimed
feature set, and program output is OK.

We had a bit of a discussion of this issue on IRC and some people
pointed out to me that even if requiring renaming of files is OK, LPPL
may still violate DFSG 3 on some technicalities.  IF we resolve all
the big issues we can come back to this point.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: forwarded message from Jeff Licquia

[Edmund GRIMLEY EVANS]

Henning Makholm <[EMAIL PROTECTED]>:

> > > telnetd is a set of machine-language instructions. It doesn't actually
> > > have any capabilities to do anything.
> 
> > This misses the point entirely so I'll try stating it another way.
> > latex essentially runs in a virtual machine provided by tex the program.
> 
> My point is that there is no meaningful difference between "virtual"
> and "non-virtual" machines in this respect.

However, there is a relevant difference between a virtual machine such
as TeX or a browser's JVM that is intended to be secure, and a
(virtual or non-virtual) machine such as IA32 or the Linux ABI that is
not intended to be secure and supposed to be able to run a shell,
trash things, etc (at least if you have supervisor status or root,
respectively).

Edmund


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LaTeX Public Project License, Version 1.3 (DRAFT)

[Lars Hellström]

At 06.07 +0200 2002-07-17, Jeff Licquia wrote:
>You made some good points.

Thank you.

>The problem is that *most of your good
>points simply aren't in the license*, and the license is all I can rely
>on when I try to figure out my rights.

Some of my points certainly refer more to what is the custom (for how the
license is interpreted) than to what is necessarily in it. Frank has
however made clear that the entire text of the license certainly is under
the knife and hence that these points are not clear in the draft isn't,
IMHO, a serious problem. What most (La)TeX users participating in this
discussion are interested in isn't primarily that the text of the license
is preserved, but that the *spirit* of it (as reflected in common practice)
is.

>So:
>
> - no, a "file" is not "something covered by the LPPL".

My point was that the LPPL by itself has no built-in relevance for a file.
There must also be a legal notice (created by the copyright holder for that
file) stating that the terms of the LPPL applies for this file. In the case
of LaTeX (the work), this legal notice is in the file legal.txt, and it
defines LaTeX (the work) to be the contents of a set of files, which are
listed by name (in the file manifest.txt). In the case of the `pig' package
that is used as an example in the LPPL, we find

  % This program consists of the files pig.dtx and pig.ins
  % and the derived file pig.sty.

so that there is again a definition of which are the files of The Program.

> - yes, a tarball is a file by the normal definition of "file".
>
> - no, since you aren't allowed to distribute the Program in modified
>form, non-free "additional restrictions" cannot be removed.

I have not claimed the contrary. A program with additional non-free
restrictions is not free, but that doesn't say the LPPL by itself is a
non-free license, just that works that from a _modification_ viewpoint are
non-free can be _distributed_ under the terms of the LPPL. What we ask is
that (some version of) the LPPL without additional conditions is approved
by Debian, not that all possible extensions of the LPPL are approved.

>If you don't agree, then point out the sections of the license that
>explicitly disagree with this assessment.
>
>On Mon, 2002-07-15 at 17:56, Lars Hellström wrote:
>> At 11 Jul 2002 16:05:14 -0500, Jeff Licquia <[EMAIL PROTECTED]> wrote:
>> >Consider Program "foo", distributed as "foo-1.0.tar.gz" under the LPPL.
>>
>> Noone would license foo-1.0.tar.gz under the LPPL. What is licensed under
>> the LPPL are files archived in foo-1.0.tar.gz.
>
>Then the file foo-1.0.tar.gz itself has no license, and cannot be
>distributed at all.

The matter of whether a file has a license has absolutely no relevance for
whether it is techincally possible to distribute a file. Is it legally
relevant? A license certainly grants various rights and so on, but I doubt
it would be required by any existing legal system. Is it necessary for
Debian to distribute it? That's mainly a matter of policy.

The point of view that I believe to be relevant here is that creating a
tarball is equivalent to copying the contents to a new file system. The
owner of the "medium" (a file in another file system) in which this file
system resides certainly has some rights to it, but licenses guarding files
in this file system can restrict those rights. The situation is not unlike
that which the publisher of an anthology is faced with: he has the right
(largly acquired through various agreements) to print (and so on) the
anthology, but the rights to the works contained in the anthology remain
with the authors (or other copyright holders) of these works.

>> "Unpacking" may be a suboptimal term in this case. What is primarily meant
>> is the generation of .sty, .cls, etc. files from (mainly) .dtx files, as
>> controlled by commands in .ins files. The process is more like the
>> compilation of some sort of binary from the actual program sources than
>> unpacking of compressed data. The reason the LPPL uses this term is
>> probably that there has traditionally been two kinds of LaTeX
>> distributions: "packed" (not including any generated files) and "unpacked"
>> (including generated files, as well as their sources).
>
>I would agree.  How to solve this is tricky, though, since technically
>these generated files are "the output of the program" in one sense.
>Obviously, you don't want to limit people's ability to process LaTeX
>documents into camera-ready output.
>
>You could, perhaps, define "results of building the Program" and "output
>from using the Program", and limit them differently.

The view taken in the LPPL is, although it may certainly need clarification
in the license text, that the generated files are principally part of The
Program, even though they need not actually be present in a copy of The
Program for that to be complete. The idea that a program may have such
virtual components could be seen as suspicious, but a compiled binary is in
a similar sense virt

Re: forwarded message from Jeff Licquia

[Martin Schröder]

On 2002-07-18 17:54:31 +0200, Henning Makholm wrote:
> My point is that there is no meaningful difference between "virtual"
> and "non-virtual" machines in this respect.

There is: You can not change the "real" machine (the cpu in your
example) while it's possible and legal to change the "virtual"
machine (tex in our case).

Best regards
Martin
-- 
   Martin Schröder, [EMAIL PROTECTED]
  ArtCom GmbH, Grazer Straße 8, D-28359 Bremen
  Voice +49 421 20419-44 / Fax +49 421 20419-10


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: forwarded message from Jeff Licquia

[David Carlisle]

> My point is that ..

I give up. I don't think your point makes any sense, and as you only
assert it without giving any reasons I don't see what else there is to
say on the issue. 

There is in any case no point continuing the thread as this is really a
general discussion about the merits of LPPL. The particular case of
latex's execution strategy might be relevant in a specific decision
about latex, but LPPL is drafted to be able to be applied to any
program if the author of the program chooses that licence.

Clearly it could be the case that an LPPL'ed program was found to have a
security problem, and it is reasonable for the Debian maintainers to
consider what they could do if they found themseleves distributing such
a thing.

I am sure that LPPL as drafted or with minor changes that anyone cares
to suggest gives enough freedom to the debian maintainers to stop
distributing the dangerous code and instead distribute a fixed code. The
only thing LPPL does is makes sure that the end user notices that a fix
has been applied. Which is probably a good thing as otherwise code may
move by accident from Debian (where it runs safely) to some other system
(where it does not).

David




_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: forwarded message from Jeff Licquia

[Henning Makholm]

Scripsit David Carlisle <[EMAIL PROTECTED]>

> > telnetd is a set of machine-language instructions. It doesn't actually
> > have any capabilities to do anything.

> This misses the point entirely so I'll try stating it another way.
> latex essentially runs in a virtual machine provided by tex the program.

My point is that there is no meaningful difference between "virtual"
and "non-virtual" machines in this respect.

-- 
Henning Makholm"It's kind of scary. Win a revolution and
a bunch of lawyers pop out of the woodwork."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: forwarded message from Jeff Licquia

[Martin Schröder]

On 2002-07-18 17:18:23 +0200, Henning Makholm wrote:
> Scripsit David Carlisle <[EMAIL PROTECTED]>
> > LaTeX is a set of macros. It doesn't actually have any capabilities to
> > do anything.
> 
> telnetd is a set of machine-language instructions. It doesn't actually
> have any capabilities to do anything.

http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00199.html
http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00140.html

Sorry, but are you trying to start a flame war?

Best regards
Martin
-- 
   Martin Schröder, [EMAIL PROTECTED]
  ArtCom GmbH, Grazer Straße 8, D-28359 Bremen
  Voice +49 421 20419-44 / Fax +49 421 20419-10


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: forwarded message from Jeff Licquia

[David Carlisle]

> telnetd is a set of machine-language instructions. It doesn't actually
> have any capabilities to do anything.

This misses the point entirely so I'll try stating it another way.
latex essentially runs in a virtual machine provided by tex the program.

If you set the security options for tex-the-program correctly then
the access of any tex document to read and/or write to your filesystem
or to run external programs can be controlled suitably (and turned off
by default in the case of running external programs.)

Assuming TeX is bug free and correctly installed, then there
is _nothing_ you can do in latex that gets round that.
If you manage to find some latex construct that does get round it it is
a bug in TeX. so it needs to be fixed there. In that case the fix will
not be in LPPL code (most likely it is in GPL'ed code, as all TeX's file
and system call handling is GPL in the version of TeX on Debian).


telnetd is not at all similar as those machine instructions are running
in an environment that does have access to secure information, so it is
the responsibility of the program not to do the wrong thing.

More similar would be a java program running in the secure environment
in a browser. If you find an applet that manages to escape from the
browser and trash your filesystem, then fixing the applet isn't really
the right thing to do, you should fix the security lapse in the browser's
JVM.

David

_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: forwarded message from Jeff Licquia

[Henning Makholm]

Scripsit David Carlisle <[EMAIL PROTECTED]>

> LaTeX is a set of macros. It doesn't actually have any capabilities to
> do anything.

telnetd is a set of machine-language instructions. It doesn't actually
have any capabilities to do anything.

> Any effect of running latex on a document is a result of the macro
> expansion engine or the execution of the primitive commands 
> into which latex constructs expand.

Any effect of running telnetd on a server is a result of a processor's
data path, or the execution of system calls embedded in telnetd.

> So any security issues in latex are not in latex itself (or LPPL'ed
> code) but must be due to issues in the underlying tex engine.

So any security issues in telnetd are not in telnetd itself, but must
be due to issues in the underlying machine language.

> As a compiled program with write access to the filesystem, that is
> of course  subject to the usual raft of issues, but it isn't under
> LPPL, most of it is under a "don't change it if you are not Don
> Knuth" licence,

As a piece of silicon with an interface to the harddisk, that is of
cource subject to the usual raft of issues, but it is not under a free
license, most of it is under a "don't change this unless you are
Intel" licence.

Does this mean we should not be concerned about the ability to
distribute security fixes for telnetd if a security issue was
discovered?

-- 
Henning Makholm   "Hele toget raslede imens Sjælland fór forbi."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: spokesman (was Re: User's thoughts about LPPL)

[Boris Veytsman]

> From: Sam Hartman <[EMAIL PROTECTED]>
> Date: Thu, 18 Jul 2002 06:20:32 -0400

> 
> The TeX license is OK because it mandates what we call the program,
> but does not say anything about the API.  Even if the binary is called
> uglytex, it's still easy for me to run it over .tex files.  If those
> files use macros defined in plain.tex, those macrso can (at our
> option) continue to work in uglytex.
> 

This is exactly the same with LaTeX. If you create a new format
newlatex.fmt and symlink /usr/bin/tex to /usr/bin/newlatex (this is
the UNIX TeX way to use formats), then you have a complete freedom to
load newarticle.cls whenever your document calls article.cls.

In macro languages you can redefine everything -- this is the beauty
of macro languages.

-- 
Good luck

-Boris

Thank goodness modern convenience is a thing of the remote future.
-- Pogo, by Walt Kelly


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: User's thoughts about LPPL

[Steve Langasek]

On Thu, Jul 18, 2002 at 09:28:58AM +0100, David Carlisle wrote:

> In that case probably it's best if we just all come back then.
> It will be a lot of work finalising the details of a rewrite of LPPL
> and if the only benefit of that is that you declare LaTeX suitable for
> the free part of Debian, that effort will be completely wasted if TeX
> and the fonts are not in the free part.

> I'd like to see LaTeX classed as Free by Debian (because it is Free)
> but distributing LaTeX separately from TeX would be non sensical
> and lead to massive user confusion. So if TeX and the CM fonts were in
> non-free I'd suggest you distribute latex from there as well, even if
> latex had a licence that you would be happy to classify as free.

FWIW, you wouldn't even need to ask. :)  Debian policy requires our
'main' archive to be self-contained; even if a piece of software meets
the DFSG, if it depends on other software that does not, it's placed in
a separate archive section called 'contrib'.

And I definitely think moving LaTeX to contrib would be a loss for all
Debian users.

Cheers,
Steve Langasek
postmodern programmer


pgpfzcxDKsaiu.pgp
Description: PGP signature

Re: Distributing GPL Software as binary ISO

[Steve Langasek]

On Thu, Jul 18, 2002 at 10:33:15AM +0200, Martin Schulze wrote:

> The current status quo:

>a) Company A collects .deb files from Debian and builds an ISO file
>   that runs the system (life system).  This ISO only contains
>   binary packages, no source.  This CD is sold and distributed
>   freely through the internet.

>   When asked about the source of the binary CD, company A points
>   to ftp.debian.org.

>b) An entity B (could be a company, or a single person, or a
>   project) lects .deb files from Debian and builds an ISO file
>   that runs the system (life system).  This ISO only contains
>   binary packages, no source.  This ISO image is distributed
>   freely through the internet and is sold on CD at an exhibition.

>   When asked about the source of the binary CD, B points to
>   ftp.debian.org.

> Questions:

>  1. Is either a) or b) in complience with the GPL (assuming all
> software is licensed using the GNU GPL.

Section 3c) of the GPL:

  3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:

c) Accompany it with the information you received as to the offer
to distribute corresponding source code.  (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)

This is the only clause of the GPL that permits someone to distribute
binaries without also making source available on their own dime, and it
only applies to noncommercial distribution.  A sale constitutes
commercial distribution.  Therefore, in both a) and b), pointing to
ftp.debian.org does not satisfy the distributor's obligations under the
GPL.

If company A or entity B is actually AFFILIATED with ftp.debian.org, note
that this might be construed as a written offer under GPL section 3b).
However, the fact that you did not call entity B 'Debian' suggests this
is not the real-world case you're interested in.

>  2. Is a) or b) in complience with the DFSG aka OSD?

Mu.  DFSG and OSD apply only to software licenses, not to behaviors.

>  3. Is it a problem if ftp.debian.org removes the source of the same
> version of a package that is used on the cd and installs a newer
> version?  (i.e. source of a package is available, but not exactly
> the proper source).

It is a problem if anyone is using ftp.debian.org to comply with section
3b) of the GPL.  Debian complies with the GPL under section 3a), so it's
only an issue for others trying to reference our archive in this manner. 
Actually, since we're using 3a) for our archive rather than 3b), I guess
no one else can cite 3c) by pointing to our archive anyway, so they're
in violation whether or not we remove some of the referenced source.

>  4. What would be the proper way to solve this problem if a) or b) are
> not in complience with the license terms?

Are you asking what A and B should do if they wish to bring themselves
into compliance, or are you asking what can be done to legally force
them to?

Steve Langasek
postmodern programmer


pgpX6Et58cgtW.pgp
Description: PGP signature

Re: User's thoughts about LPPL

[Boris Veytsman]

> Date: Thu, 18 Jul 2002 04:15:20 -0400
> From: Glenn Maynard <[EMAIL PROTECTED]>

> 
> If the core can be changed in any way without changing it directly,
> then you can break output exactly as well by this mechanism as you
> could by editing it directly.
> 

No, because to change the core you need to make an explicit decision,
like using a command

newlatex file.tex

instead of

latex file.tex

LaTeX team does not mind you using or distributing a changed
LaTeX. It does not want you to use it AND call it LaTeX.

> 
> Of course, if I distribute my broken copy of Latex and call it Latex, it
> might cause some grief, since people who think they're getting Latex are
> getting something else.  That's why some people use licenses that say
> that if you distribute changed versions, you need to call the program
> something else.  No matter how much (or how subtly) I break Latex, and
> no matter how many people I distribute it to, it's not going to cause
> preventable problems if I call it something else.
> 


That is exactly the intention of LPPL as far as I understand it.

-- 
Good luck

-Boris

Kime's Law for the Reward of Meekness:
Turning the other cheek merely ensures two bruised cheeks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: forwarded message from Jeff Licquia

[Peter S Galbraith]

A short two cents from a user...

Boris Veytsman <[EMAIL PROTECTED]> wrote:

> Timothy Murphy <[EMAIL PROTECTED]> wrote:
> 
> > (1) The intersection of those interested in LaTeX and those
> > seriously interested in Debian is almost empty, I imagine.

I'm a LaTeX user and Debian developer.
 
> > (2) You (or someone else on the Debian "side") asked for the "LaTeX
> > community" to comment on the discussion.  I'm an ordinary LaTeX
> > user, but I'm pretty sure that I speak for 95% (if not 100%) of
> > LaTeX users when I say that satisfying the Debian licence comes very
> > low indeed in my order of priorities.
  
> I completely disagree with these points. 
> 
> 1. I know many LaTeX users. Debian is a distribution of choice for
>many of them. 
> 
> 2. The state of TeX/LaTeX in Debian is high on the priority list for
>many LaTeX users I know, and very high for many system admins that
>support LaTeX on their machines.

Right.  As a LaTeX user, I'd be sad to see it go from Debian.
 
> Having said this, I need to note that the integrity of my (La)TeX
> distribution on the production systems is higher in my priority list
> than ease of maintaining. If Debian starts to change the standard, I
> will probably migrate to TeXLive again -- with all the problems this
> migration would cause.

I think you can have both.  I don't think a DFSG-compliant license will
mean a fork of LaTeX by the Debian maintainer of that package.

I have always appreciated the fact that you could run latex on 10
year-old sources and get the same output, but I have also come to
appreciate the rights granted by DFSG-compliant software.  

Peter


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: User's thoughts about LPPL

[David Carlisle]

> Would a statement in the license that *either* of the following must
> happen be acceptable to the LaTeX project?
> 
> * The modified copy of the Program is distributed under a name which
>   clearly distinguishes it from Standard LaTeX, the unmodified copy.
> 
> * Any files which share names between the unmodified copy and the
>   modified copy must be identical in content.  You may modify files
>   only if you change their names.

such a statement appears already in the modguide.tex file (which is
referenced from the licence) as I posted this morning.
there is the additional requirement that you have to make sure your
modified files are not picked up by latex (if you also distribute that).

that is 
you can have (if you want, although no one does) 
debianlatex
that has its own article.cls that does whatever you want.

But you can't do that if that modified file is on latex's default path 
so that
latex 
uses the same file.


point 2 in modguide.tex which I post again:


\begin{enumerate}
\item
  Give your system a distinguished name, such as \nstex, which clearly
  distinguishes it from \LaTeX{}.

\item
  Ensure that it contains no file with a name the same as that of
  a file in the standard distribution but with different contents.
  (If this is not possible then you must: 
  \begin{itemize}
  \item
ensure that files from the non-\LaTeX{} system cannot be
accidentally accessed whilst using a standard \LaTeX{};
  \item ensure that each file from the non-\LaTeX{} system clearly
identifies itself as a non-\LaTeX{} file on the terminal and in the
log file.)
  \end{itemize}

\item
  Ensure that the method used to run your system is clearly
\label{mcon:command}
  distinct from that used to run Standard \LaTeX; e.g.~by using a
  command name or menu entry that is clearly not \texttt{latex}
  (or \texttt{LaTeX} etc).

\item
  Ensure that, when a file is being processed by your system, the
  use of non-standard \LaTeX{} is clearly proclaimed to the user by
  whatever means is appropriate.

\item Ensure that what is written at the beginning of the log file
  clearly shows that your system has been used, and that it is 
  not Standard \LaTeX{}.
  See the file \texttt{cfgguide.tex} for how to achieve this.

\item
 Clearly explain to users that bug reports concerning your 
 system should not be sent to the maintainers of Standard
 \LaTeX{}. 
\end{enumerate}

_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: User's thoughts about LPPL

[Brian Sniffen]

> In article <[EMAIL PROTECTED]>, David Carlisle <[EMAIL PROTECTED]> writes:

> If you want more and want to change the kernel itself rather than
> redefining it on the fly (perhaps just for optimisation reasons) you can
> do that as well as long as you don't call it latex, see the quote from
> modguide.tex I posted a few minutes ago.

But that isn't all: if the restriction were just that I couldn't
distribute my changed (perhaps just very heavily commented) LaTeX
kernel under the name LaTeX, that part of the license would be
unambiguously DFSG-free.  It's the requirement that I change every
file name as well, coupled with TeX's heavy dependence on file names,
that is the problem here

> What more do you want?

Would a statement in the license that *either* of the following must
happen be acceptable to the LaTeX project?

* The modified copy of the Program is distributed under a name which
  clearly distinguishes it from Standard LaTeX, the unmodified copy.

* Any files which share names between the unmodified copy and the
  modified copy must be identical in content.  You may modify files
  only if you change their names.

-Brian


pgpLCIgDcb82z.pgp
Description: PGP signature

Re: forwarded message from Jeff Licquia

[Colin Watson]

On Wed, Jul 17, 2002 at 09:52:05PM -0400, Boris Veytsman wrote:
> This is because libc on Linux is LGPL'ed. Now suppose that you work on
> a system where you cannot rename libc -- either because of license or
> because you are not a superuser. Still you can say something like
> 
> export LD_PRELOAD=my.cool.libc-substitute.so
> 
> and all your dynamically linked programs will use your substitute.

I think this is a bad example in the context of this discussion. We
would not consider it acceptable if we couldn't modify the libc and the
libc copyright holders said "LD_PRELOAD is available, so use that
instead".

-- 
Colin Watson  [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: User's thoughts about LPPL

[Javier Bezos]

Glenn Maynard said:

> If the core can be changed in any way without changing it directly,
> then you can break output exactly as well by this mechanism as you
> could by editing it directly.

So what...?
 
> If so, then there's no point in forcing people to use it; they can break
> stuff anyway.

Yes of course. If someone uses \usepackage{nonsense} in the
document where nonsense is a package breaking latex, the document
won't work (never). I don't see your point.

> If not, then there are apparently things you can't do with this mechanism.

Thanks for saying "apparently" :-). We are repeating and repeating
again than you can rewrite latex in full, if you want.

>> Definitely right, and as you can see LaTeX already provides
>> a mechanism for that (which could explain why LaTeX is still
>> alive after 20 years). The lppl ensures that this mechanism is
> 
> I can modify gcc, remove short-circuit evaluation, and distribute it,
> breaking almost every C program in use.

And you can write a package doing that. Except for the fact
that you cannot change the behaviour of "your" C compiler
from within a C "document" (ie, a C program), while you may
fix the wrong behavior of LaTeX with your own package or
even from within the latex document.

> Yet, C has been around for 30 years, without any of these restrictions,
> without falling apart.

So what...? Did I say a single word saying that LPPL is
good for C and, say, GPL is wrong? What I'm saying is that LaTeX
is not C and therefore the licence could have some differences.
If C and LaTeX are so long-lived depends on lots of factors,
but the right license (or standardization) might be one of them.
(BTW, except for TeX itself, the tetex code is distributed under
GPL and i think that's fine.)

> You're saying that if I edit the core directly instead of using the
> mechanisms you mention, free distribution of documents is no longer
> possible, and Latex will suddenly have severe restrictions?

Nope. The _distribution_ of LaTeX documents and the LaTeX
documents, _not_ LaTeX itself.

> Of course, if I distribute my broken copy of Latex and call it Latex, it
> might cause some grief, since people who think they're getting Latex are
> getting something else.

I repeat what I said a few messages ago -- the problem is not
redistributing LaTeX but distributing documents created using a
modified latex. I'm going to remember it:

>> but the documents created using that distribution. If I get a
>> document by "John Smith" (somehow), how can I see if _his_
>> system had a modified latex?

Packages and lppl provide freedom for both modifying latex and
distributing documents that work from the USA to India or
Iran or Australia or Russia or... Otherwise, documents will be
condemned to personal use only.

Regards
Javier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Distributing GPL Software as binary ISO

[Martin Schulze]

Chris Lawrence wrote:
> In other words: you have opened a massive can of worms. :-)

*looking innocent*  It wasn't me... :-) But I'd like the issue solved
so there's a clear statement for people, companies and entities to get
pointed to in order to preserve them from license infringement.

Regards,

Joey

-- 
There are lies, statistics and benchmarks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: spokesman (was Re: User's thoughts about LPPL)

[Sam Hartman]

> "Jeff" == Jeff Licquia <[EMAIL PROTECTED]> writes:

Jeff> On Wed, 2002-07-17 at 01:31, Frank Mittelbach wrote:
>> Branden Robinson writes: > Perhaps the LaTeX community should
>> appoint a spokesman to the Debian > Project so that we do not
>> get contradictory statements about what is > acceptable?
>> 
>> Branden, pardon me, but i think this is funny. seems that you
>> think the LaTeX community needs as spokesman which is the very
>> thing that I think debian needs.

Jeff> I'm curious.  From my perspective, the Debian people seem
Jeff> not to have been contradicting themselves so far; I

But we do seem to be contradicting our actions and unclear on the
implications of DFSG 4.

I think DFSG 4 means that you can require renaming or patch files of
the sources.  It also seems that you can  require renaming of the distributions.

What Debian finds unacceptable is the assertion that we must break the
TeX or LaTeX API (hey you said it was a language) in order to make
some changes.

I.E.  if we find a bug in article.cls, it's not OK to rename that file
because then \documentclass{article} will either fail or get the old
file rather than our changed version.  The argument is that in
practice we cannot follow DFSG 3 because we cannot change the software
and maintain API compatibility with existing documents if we fix bugs.

The TeX license is OK because it mandates what we call the program,
but does not say anything about the API.  Even if the binary is called
uglytex, it's still easy for me to run it over .tex files.  If those
files use macros defined in plain.tex, those macrso can (at our
option) continue to work in uglytex.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Distributing GPL Software as binary ISO

[Martin Schröder]

On 2002-07-18 10:33:15 +0200, Martin Schulze wrote:
> The current status quo:
> 
>a) Company A collects .deb files from Debian and builds an ISO file
>   that runs the system (life system).  This ISO only contains
>   binary packages, no source.  This CD is sold and distributed
>   freely through the internet.
> 
>   When asked about the source of the binary CD, company A points
>   to ftp.debian.org.
> 
>b) An entity B (could be a company, or a single person, or a
>   project) lects .deb files from Debian and builds an ISO file
>   that runs the system (life system).  This ISO only contains
>   binary packages, no source.  This ISO image is distributed
>   freely through the internet and is sold on CD at an exhibition.
> 
>   When asked about the source of the binary CD, B points to
>   ftp.debian.org.
> 
> Questions:
> 
>  1. Is either a) or b) in complience with the GPL (assuming all
> software is licensed using the GNU GPL.

No.

http://www.gnu.org/licenses/gpl-faq.html#DistributeWithSourceOnInternet";>
I want to distribute binaries without accompanying sources. Can I
provide source code by FTP instead of by mail order?

You're supposed to provide the source code by mail-order on a
physical medium, if someone orders it. You are welcome to offer
people a way to copy the corresponding source code by FTP, in
addition to the mail-order option, but FTP access to the source
is not sufficient to satisfy section 3 of the GPL.

When a user orders the source, you have to make sure to get
the source to that user. If a particular user can conveniently
get the source from you by anonymous FTP, fine--that does the
job. But not every user is on a network. The rest of the users
are just as entitled to get the source code from you, which means
you must be prepared to send it to them by post.

If the FTP access is convenient enough, perhaps no one will
choose to mail-order a copy. If so, you will never have to ship
one. But you cannot assume that.

Of course, it's easiest to just send the source with the
binary in the first place.


Best regards
Martin
-- 
   Martin Schröder, [EMAIL PROTECTED]
  ArtCom GmbH, Grazer Straße 8, D-28359 Bremen
  Voice +49 421 20419-44 / Fax +49 421 20419-10


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: file name rules in licenses

[Martin Schröder]

On 2002-07-17 10:37:16 -0700, Mark Rafn wrote:
> Fundamentally, no software can go into Debian without granting all users
> the right to make it behave however they want, and to distribute that
> result, however stupid. 

Then you have to throw out TeX and friends.

Best regards
Martin
-- 
   Martin Schröder, [EMAIL PROTECTED]
  ArtCom GmbH, Grazer Straße 8, D-28359 Bremen
  Voice +49 421 20419-44 / Fax +49 421 20419-10


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: forwarded message from Jeff Licquia

[Martin Schröder]

On 2002-07-17 14:24:15 -0500, Jeff Licquia wrote:
> On Wed, 2002-07-17 at 12:23, Javier Bezos wrote:
> > Let's put it in other words. TeX leaves to the distribution
> > the decision about how files are read/written. tetex
> > decides how files are read/written and it's under GPL. Thus, you
> > can change it if you want. Nothing to do with LaTeX ot LPPL.
> > After that, explaining the problem of holes in our dangerous
> > time can be interesting but it's certainly irrelevant.
> 
> This is irrelevant to my position as stated:

This is absolutely relevant. LaTeX is just a set of macros run
through an interpreter. The interpreter happens to be some
implementation of TeX. The security problems will be in the
interpreter, not in the macros. And the parts of the
implementation concerning these possible problems are under GPL.

The same applies to PostScript: One fixes security holes in the
interpreter (e.g. GhostScript) and doesn't worry about the
PostScript files.

Best regards
Martin
-- 
   Martin Schröder, [EMAIL PROTECTED]
  ArtCom GmbH, Grazer Straße 8, D-28359 Bremen
  Voice +49 421 20419-44 / Fax +49 421 20419-10


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: forwarded message from Jeff Licquia

[David Carlisle]

> If these were the only restrictions (change contact info and change
> the name of the *program*, not the individual files), then we wouldn't
> be having this argument.


The filenames are part of the syntax of the language.

\documentclass{article}


does not mean "whatever article means on your system" it means the latex
article class. Without the filename restriction there would be no
standardisation of latex at all.

However if the program isn't called latex (even if it is derived from
latex) the code can be redefined so that

\documentclass{article}

does not load article.cls but loads article.debian-improved-class
instead, and that can do anything you like.

But this is basically just an unhelpful side issue of the form "I
personally don't like file name restrictions" as you are not I take it
claiming that anything in DFSG makes this distinction.

David

_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: User's thoughts about LPPL

[David Carlisle]

> you missed the point, which is that the changes in the Latex kernel
> had to be made in order for Klingon (or whatever language) to work.
> Don't tell me that there will never be a need to change the internals
> in order to make something work.  You can't anticipate everything that
> will happen in technology for the 100 years.

If the user wants klingon they go

\usepackage{klingon}

klingon.sty can redefine _absolutely every single line of latex code in
the latex distribution_ and still be compliant.

What more do you want?

If you want more and want to change the kernel itself rather than
redefining it on the fly (perhaps just for optimisation reasons) you can
do that as well as long as you don't call it latex, see the quote from
modguide.tex I posted a few minutes ago.

David

_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Distributing GPL Software as binary ISO

[Chris Lawrence]

On Jul 18, Martin Schulze wrote:
> The current status quo:
> 
>a) Company A collects .deb files from Debian and builds an ISO file
>   that runs the system (life system).  This ISO only contains
>   binary packages, no source.  This CD is sold and distributed
>   freely through the internet.
> 
>   When asked about the source of the binary CD, company A points
>   to ftp.debian.org.
> 
>b) An entity B (could be a company, or a single person, or a
>   project) lects .deb files from Debian and builds an ISO file
>   that runs the system (life system).  This ISO only contains
>   binary packages, no source.  This ISO image is distributed
>   freely through the internet and is sold on CD at an exhibition.
> 
>   When asked about the source of the binary CD, B points to
>   ftp.debian.org.
> 
> Questions:
> 
>  1. Is either a) or b) in complience with the GPL (assuming all
> software is licensed using the GNU GPL.
> 
>  2. Is a) or b) in complience with the DFSG aka OSD?
> 
>  3. Is it a problem if ftp.debian.org removes the source of the same
> version of a package that is used on the cd and installs a newer
> version?  (i.e. source of a package is available, but not exactly
> the proper source).
> 
>  4. What would be the proper way to solve this problem if a) or b) are
> not in complience with the license terms?

In case (4), it would be up to the individual copyright holders of the
packages contained on the CDs.

My general thought on 1-3 is that they could be construed as
violations of the license if someone were to push the issue.  If that
were the case, the following policies would probably have to be
adopted by anyone offering CDs of Debian (including myself):

1. Refuse to sell binaries without source.  This makes Debian 100%
more expensive to produce, and possibly means that distributors will
only distribute a subset of Debian to reduce the logistical nightmare
of producing 12 CD-Rs, but the buyer is the one that bears the brunt
of that problem.  (i.e. if Bob wants Debian, he has to have the source
for everything, and I won't sell him anything without that source
included.  Bob Newbie is now paying for 6 to-him coasters in addition
to 6 binary CDs.)

2. Refuse to offer any ISO images on the Internet.  (That means ssh
relativity.phy.olemiss.edu rm -rf /var/www/debian-cd, in English)

This insulates the distributor from liability under the "I got binary
from you 2 years and 364 days ago, so I demand the source" clause of
the GPL, because there's no way the purchaser could get binaries
without source.  It also makes Debian a royal pain in the ass to
distribute at low cost, but that's the legalities of it.  (However,
this is only actionable if a buyer attempts to exercise his rights
under the GPL - unless and until that happens, the distributor is not
violating the license.  He only violates the license if and only if he
fails to meet the buyer's demand for the equivalent source at a
"reasonable" price.  Furthermore, this has never been tested in court
so it is unclear whether providing a later version of the source would
be sufficient, or what a "reasonable" price might be.  For example, if
A distributes Debian without source, and nobody complains that they
didn't get source, A is not violating the GPL per se.)

In other words: you have opened a massive can of worms. :-)


Chris
-- 
Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: file name rules in licenses

[David Carlisle]

> At some level, this type of requirement is unenforceable, isn't it?  One
> can always name it "lsf" and create a wrapper "ls" that execs it.  "lsf"
> satisfies the license by having a different name, and the wrapper is brand
> new code so not encumbered by someone else's copyright.
> 

LPPL does not (unlike some other licences:-) insist that any derived code
is licenced in the same way, but it does state that any derived works,
apart from having different names, should be licenced with a licence
that forbids renaming back to the original.

David

_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: forwarded message from Jeff Licquia

[David Carlisle]

> I did not see any statement to this effect in the LPPL draft that was
> posted here:
> 
> http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg7.html
> 
> I would love to hear that I had completely missed it, or that you've
> changed the draft to include such a statement.

My understanding is that no such statement is necessary (but there is
one anyway:-)

(Also it's difficult for latex to talk of command names, even more than
files, latex is used on systems with no command line, so you have to
interpret "command name" as "menu option or icony thing or anything else
that can be reasonably construed as starting the program from a user
action", which propbably isn't legally watertight...)

To take that specific example.

pslatex does not modify any of the latex source or run time files
so is clearly not in breach of the LPPL. It does have a pile of extra
tex macros that redefine chunks of latex, but LPPL explictly does not
forbid redefintions it just says such redefinitions should not be in a
file of the same name as the original.

Then wrapping it all up it has a new shell script which called "pslatex"
which calls standard latex on the user's document while inserting the
redefinitions in a suitably cunning way. This shell script again is not
a modification of any part of latex and doesn't share any name with any
part of latex so clearly is not in breach of LPPL.


This is spelled out more fully in the latex modification guide
modguide.tex which is referenced in the preamble of the LPPL draft you
quoted.

modguide.tex is in the base latex distribution, or ready formatted here:

ftp://ftp.tex.ac.uk/tex-archive/macros/latex/doc/modguide.pdf

the relevant bit of modguide.tex source says


\section{Modification conditions}
\label{sec:modcon}

It is possible that you need to produce a document processing system
based on standard \LaTeX{} but with functionality that cannot be
implemented by using the approved configuration files and complying
with the restriction on the code that is allowed in them.  In other
words, you may need a system which is sufficiently distinct from
Standard \LaTeX{} that it is not feasible to do this simply by using
the configuration options we provide or by producing new classes and
packages.

If you do produce such a system then, for the reasons described
above, you should ensure that your system is clearly distinguished
from Standard \LaTeX{} in every possible way, including the following.


\begin{enumerate}
\item
  Give your system a distinguished name, such as \nstex, which clearly
  distinguishes it from \LaTeX{}.

\item
  Ensure that it contains no file with a name the same as that of
  a file in the standard distribution but with different contents.
  (If this is not possible then you must: 
  \begin{itemize}
  \item
ensure that files from the non-\LaTeX{} system cannot be
accidentally accessed whilst using a standard \LaTeX{};
  \item ensure that each file from the non-\LaTeX{} system clearly
identifies itself as a non-\LaTeX{} file on the terminal and in the
log file.)
  \end{itemize}

\item
  Ensure that the method used to run your system is clearly
\label{mcon:command}
  distinct from that used to run Standard \LaTeX; e.g.~by using a
  command name or menu entry that is clearly not \texttt{latex}
  (or \texttt{LaTeX} etc).

\item
  Ensure that, when a file is being processed by your system, the
  use of non-standard \LaTeX{} is clearly proclaimed to the user by
  whatever means is appropriate.

\item Ensure that what is written at the beginning of the log file
  clearly shows that your system has been used, and that it is 
  not Standard \LaTeX{}.
  See the file \texttt{cfgguide.tex} for how to achieve this.

\item
 Clearly explain to users that bug reports concerning your 
 system should not be sent to the maintainers of Standard
 \LaTeX{}. 
\end{enumerate}




_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RFC: Myricom GM message passing system packaging

[Francesco P. Lovergine]

Hi deb-folks and sorry for the long post.

After a quite long delay in packaging GM message passing system (see my
ITP #114992), I'm going to build up the beast. Some issues I see:

A. Sources include a modified old version of zlib - with the infamous security 
   bug. Myrinet developers think (?) the bug is not exploitable in GM code.
   Probably the best thing to do is to back-port the patch for zlib,
   but this could be a pain for future releases... Is there any pointer
   to zlib patches? Other suggestions? (Myrinet folks do not mind
   excessively security aspects IMHO)


B. Copyright is 




   **
   **
   * Myricom GM networking software and documentation   *
   **
   * Copyright (c) 1994-2001 by Myricom, Inc.   *
   * All rights reserved.   *
   **
   * Permission to use, copy, modify and distribute this software and its   *
   * documentation in source and binary forms for non-commercial purposes   *
   * and without fee is hereby granted, provided that the modified software *
   * is returned to Myricom, Inc. for redistribution. The above copyright   *
   * notice must appear in all copies.  Both the copyright notice and this  *
   * permission notice must appear in supporting documentation, and any *
   * documentation, advertising materials and other materials related to*
   * such distribution and use must acknowledge that the software was   *
   * developed by Myricom, Inc. The name of Myricom, Inc. may not be used   *
   * to endorse or promote products derived from this software without  *
   * specific prior written permission. *
   **
   * Myricom, Inc. makes no representations about the suitability of this   *
   * software for any purpose.  *
   **
   * THIS FILE IS PROVIDED "AS-IS" WITHOUT WARRANTY OF ANY KIND, WHETHER*
   * EXPRESSED OR IMPLIED, INCLUDING THE WARRANTY OF MERCHANTABILITY OR *
   * FITNESS FOR A PARTICULAR PURPOSE. MYRICOM, INC. SHALL HAVE NO  *
   * LIABILITY WITH RESPECT TO THE INFRINGEMENT OF COPYRIGHTS, TRADE*
   * SECRETS OR ANY PATENTS BY THIS FILE OR ANY PART THEREOF.   *
   **
   * In no event will Myricom, Inc. be liable for any lost revenue or   *
   * profits or other special, indirect and consequential damages, even if  *
   * Myricom has been advised of the possibility of such damages.   *
   **
   * Other copyrights might apply to parts of this software and are so  *
   * noted when applicable. *
   **
   * Myricom, Inc.  *
   * 325 N. Santa Anita Ave.*
   * Arcadia, CA 91006  *
   **
   **

The "zlib" source is copyright (C) 1995-1996 Jean-loup Gailly and Mark
Adler.  See the file "zlib/README" for the copyright notice.

The GM configure scripts were produced by the Gnu Autoconf package and
are redistributed as permitted by that software's documentation,
which states,

   There are no restrictions on how the configuration scripts that
Autoconf produces may be distributed or used.  [...]
 
   Of the other files that might be used with `configure',
`config.h.in' is under whatever copyright you use for your
`configure.in', since it is derived from that file and from the public
domain file `acconfig.h'.  `config.sub' and `config.guess' have an
exception to the GPL when they are used with an Autoconf-generated
`configure' script, which permits you to distribute them under the same
terms as the rest of your package.  `install-sh' is from the X
Consortium and is not copyrighted.



So this stuff could be released in non-free, by sending the .deb stuff to
them before. A strange aspect of the story is that their web site require 
a password to download all softwares (!). Anyway copyright is apparently
not too restrictive.
 
C. Building requires some kernel files: both kernel headers and some
post 'make d

Distributing GPL Software as binary ISO

[Martin Schulze]

Hi,

a discussion arose recently and I'd like to discuss the outcome and
the way to go.

The current status quo:

   a) Company A collects .deb files from Debian and builds an ISO file
  that runs the system (life system).  This ISO only contains
  binary packages, no source.  This CD is sold and distributed
  freely through the internet.

  When asked about the source of the binary CD, company A points
  to ftp.debian.org.

   b) An entity B (could be a company, or a single person, or a
  project) lects .deb files from Debian and builds an ISO file
  that runs the system (life system).  This ISO only contains
  binary packages, no source.  This ISO image is distributed
  freely through the internet and is sold on CD at an exhibition.

  When asked about the source of the binary CD, B points to
  ftp.debian.org.

Questions:

 1. Is either a) or b) in complience with the GPL (assuming all
software is licensed using the GNU GPL.

 2. Is a) or b) in complience with the DFSG aka OSD?

 3. Is it a problem if ftp.debian.org removes the source of the same
version of a package that is used on the cd and installs a newer
version?  (i.e. source of a package is available, but not exactly
the proper source).

 4. What would be the proper way to solve this problem if a) or b) are
not in complience with the license terms?

Regards,

Joey

-- 
There are lies, statistics and benchmarks.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: User's thoughts about LPPL

[David Carlisle]

> Additionally, there is the question
> of defining "non-functional" data; some kinds of data, such as fonts,
> have functional impact

for a system like latex the fonts (or at least their metrics) have as
much impact as the rest of the system. Modifying the font metrics is
even more likely to change the final document layout than changing the
latex macros (most of which are not used in any given document run).

>  if the time comes to act, CM fonts can be moved to non-free then.

In that case probably it's best if we just all come back then.
It will be a lot of work finalising the details of a rewrite of LPPL
and if the only benefit of that is that you declare LaTeX suitable for
the free part of Debian, that effort will be completely wasted if TeX
and the fonts are not in the free part.

I'd like to see LaTeX classed as Free by Debian (because it is Free)
but distributing LaTeX separately from TeX would be non sensical
and lead to massive user confusion. So if TeX and the CM fonts were in
non-free I'd suggest you distribute latex from there as well, even if
latex had a licence that you would be happy to classify as free.

So I don't think we can do anything about the latex licence until 
then. (This is a personal response to your comments, Frank may have
different ideas, especially as he's spent a lot of time redrafting
LPPL this last month and is (I thought) almost there as regards
addressing any concerns raised by Debian with the old version.)

David

_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: User's thoughts about LPPL

[Glenn Maynard]

On Thu, Jul 18, 2002 at 09:28:22AM +0200, Javier Bezos wrote:
> Of course, I won't tell you that. I repeat that the internals *can*
> be changed without touching a single file from the LaTeX kernel,
> and currenty there are several packages doing that. An example:
> the hyperref package patches some internals of the LateX kernel
> to provide hyperlinks and more in pdf documents, and no file
> from LaTeX has been modified.

If the core can be changed in any way without changing it directly,
then you can break output exactly as well by this mechanism as you
could by editing it directly.

If so, then there's no point in forcing people to use it; they can break
stuff anyway.

If not, then there are apparently things you can't do with this mechanism.

> Definitely right, and as you can see LaTeX already provides
> a mechanism for that (which could explain why LaTeX is still
> alive after 20 years). The lppl ensures that this mechanism is

I can modify gcc, remove short-circuit evaluation, and distribute it,
breaking almost every C program in use.

Yet, C has been around for 30 years, without any of these restrictions,
without falling apart.

> used, or otherwise the free distribution of LaTeX documents
> won't be possible and it will suffer severe restrictions.

You're saying that if I edit the core directly instead of using the
mechanisms you mention, free distribution of documents is no longer
possible, and Latex will suddenly have severe restrictions?

Huh?

Sorry, but there's no connection here.  If I edit the core directly and
break everything, I can still freely distribute my Latex documents and
Latex will not suffer any restrictions.

Of course, if I distribute my broken copy of Latex and call it Latex, it
might cause some grief, since people who think they're getting Latex are
getting something else.  That's why some people use licenses that say
that if you distribute changed versions, you need to call the program
something else.  No matter how much (or how subtly) I break Latex, and
no matter how many people I distribute it to, it's not going to cause
preventable problems if I call it something else.

Of course, that means there's another tex parser out in the wild that
may not be completely compatible with Latex, but that can't be stopped.

-- 
Glenn Maynard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

AW: forwarded message from Jeff Licquia [OT]

[Mittelbach, Frank]

True, that is why i said in b) LPPL-x (indicating a different version of
LPPL

okay?

cheers
frank   (out of the run until tonight probably)

-Ursprungliche Nachricht-
Von: Glenn Maynard [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 18. Juli 2002 09:37
An: debian-legal@lists.debian.org
Betreff: Re: forwarded message from Jeff Licquia [OT]


On Thu, Jul 18, 2002 at 09:03:11AM +0200, Frank Mittelbach wrote:
>   a) to improve LPPL (which has several deficiencies)
>   b) to come to a common understanding that LPPL-x is complient with DFSG
as
>   well as FSF etc
or failing b, b2) determine why the LPPL fails the DFSG, and what can be
done about it.

Don't assume a license is DFSG-free because you've read (or written) the
license, read the DFSG and ticked off each guideline.  Human judgment
and existing practice come into the equation.

-- 
Glenn Maynard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: forwarded message from Jeff Licquia [OT]

[Glenn Maynard]

On Thu, Jul 18, 2002 at 09:03:11AM +0200, Frank Mittelbach wrote:
>   a) to improve LPPL (which has several deficiencies)
>   b) to come to a common understanding that LPPL-x is complient with DFSG as
>   well as FSF etc
or failing b, b2) determine why the LPPL fails the DFSG, and what can be
done about it.

Don't assume a license is DFSG-free because you've read (or written) the
license, read the DFSG and ticked off each guideline.  Human judgment
and existing practice come into the equation.

-- 
Glenn Maynard


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: User's thoughts about LPPL

[Javier Bezos]

>> This is a really good argument *in favour* of LPPL! If someone
>> adds support for Klingon by modifying the LaTeX kernel, the
>> resulting documents will have a restricted distribution
>> because they won't compile correctly in other systems. This
>> is an _actual_ restriction. But if instead a package -- extending
>> and modifying latex as desired -- is created and called from
>> the document, it will complain about a required but missing
>> package and you will be able to locate and get the package,
>> and then typeset the document. Otherwise, you will be frustrated
>> because you could have a 'correct' document displaying nothing
>> without any explanation.
> 
> You missed the point, which is that the changes in the Latex kernel
> had to be made in order for Klingon (or whatever language) to work.

As I said, that's not exact.

> Don't tell me that there will never be a need to change the internals
> in order to make something work.

Of course, I won't tell you that. I repeat that the internals *can*
be changed without touching a single file from the LaTeX kernel,
and currenty there are several packages doing that. An example:
the hyperref package patches some internals of the LateX kernel
to provide hyperlinks and more in pdf documents, and no file
from LaTeX has been modified.

> You can't anticipate everything that
> will happen in technology for the 100 years.

Definitely right, and as you can see LaTeX already provides
a mechanism for that (which could explain why LaTeX is still
alive after 20 years). The lppl ensures that this mechanism is
used, or otherwise the free distribution of LaTeX documents
won't be possible and it will suffer severe restrictions.

Regards
Javier




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: forwarded message from Jeff Licquia [OT]

[Frank Mittelbach]

Glenn Maynard writes:
 > I don't see how any of this is related to the topic at hand, so I've
 > marked this OT.

if OT means others topic then I agree.

 > On Thu, Jul 18, 2002 at 02:15:31AM +0100, Timothy Murphy wrote:
 > > There you are -- you _do_ consider you have been granted
 > > the True Meaning of "freeness".
 > 
 > No, of course he doesn't.  We're all well-aware that there are other
 > definitions of freeness; please stop telling us we're not.

agreed. I think we all have made that point clear. There are various forms of
FREE and most (perhaps all?) people think that LaTex is "free" software of
some kind, but the question at hand is whether or not LPPL is within DFSG or
could be made to agree to DFSG (assuming it doesn't) without violating what we
consider to belong to FREE in the LaTeX sense. 

There is certainly an advantage to everybody in the free software community,
eg Debian, FSF, OSI, LaTeX-users, ..., if software like LaTeX is accepted
within each community to be free and not just in some because LaTeX plays a
not unimportant part in communication and exchange between users using FREE
software (of whatever flavour)

So i'm for my part see indeed a value for LaTeX users (not for me personally)
to try

  a) to improve LPPL (which has several deficiencies)
  b) to come to a common understanding that LPPL-x is complient with DFSG as
  well as FSF etc

I still think that both are possible, in fact given Mark Rafn's posts there
shouldn't be any problem whatsoever. but i think we should be able to do
better than declare LPPL DFSG complient by tricking it. 

I still have the hope that I might be able to even convince Mark (even though
he, if I understand his post correctly, has no respect left for the likes of
me, David or others responsible for something like LPPL) that LPPL stays
firmly within the freedoms outlined by Branden forming the basis of DFSG.

we'll see

frank


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]