Re: Question about license compatibility

2005-07-22 Thread Sean Kellogg
On Thursday 21 July 2005 04:49 pm, Gerasimos Melissaratos wrote:
 X-Hellenic Ministry of Foreign Affairs-MailScanner: Found to be clean
 X-MailScanner-From: [EMAIL PROTECTED]

 I'd like to create a package for ng-spice, which seems to be governed by
 two licenses, which I include herein. In first reading I cannot see any
 real discrepancies, but of course IANAL. Pls tell me if any of them is
 compatible with DFSG.

I'm surprised no one has responded to this yet...  so I guess I'll get the 
ball rolling.  Its my opinion that both licenses are non-free, for reasonably 
well established and non-controversial reasons.

License 1 contains a limitation on use (educational, research and non-profit 
purposes, without fee) which is a violation of DFSG #6.  License 2 is less 
obvious, but I personally believe that a provision that forbids charging a 
fee for distribution is non-free, or at least bad policy.  Certainly having a 
package that prohibits charging for distribution would prevent it from being 
on a Debian CD sold by one of the vendors.  Based on the DFSG I'd have to 
point to #1 and #6...  but both are kind of stretches.

Anyone else have thoughts?

-- 
Sean Kellogg
3rd Year - University of Washington School of Law
Graduate  Professional Student Senate Treasurer
UW Service  Activities Committee Interim Chair 
w: http://probonogeek.blogspot.com

So, let go
 ...Jump in
  ...Oh well, what you waiting for?
   ...it's all right
    ...'Cause there's beauty in the breakdown



Re: Password disclosure?

2005-07-22 Thread Free Ekanayaka
|--== Francesco Poli writes:

  FP On Wed, 20 Jul 2005 10:17:29 +0100 Free Ekanayaka wrote:
  FP [...]
  FP |   zynaddsubfx is also a must
  FP [...] 
  FP | The licence is a bit strange, I know, but  it is still the
  FP | softsynth with the best sounds that come out of the box.
  
  FP Well, what's strange with the GNU GPL v2?
  FP 
http://packages.debian.org/changelogs/pool/main/z/zynaddsubfx/zynaddsubfx_2.2.1-2/zynaddsubfx.copyright
  
  From http://zynaddsubfx.sourceforge.net/:
  
  Please don't use this program to  make music that  is against God and
  Jesus Christ. Realize that  the  only way to   the Salvation is  Jesus
  Christ. Please  don't lose this chance and  don't  make others to lose
  it!

  FP Well, that's a Please don't do this: it's a kind *request*, not a
  FP legally binding *requirement*.
  FP Upstream authors seem to be Christian fundamentalists or something like
  FP that.
  FP At least, that's what appears from the notice you quoted...
  FP They probably would *not* be pleased, if, say, Marilyn Manson used
  FP zynaddsubfx in his artistical production; but they (seem to) want their
  FP software to be free, so they do not discriminate against any field of
  FP endeavor: they just advice against uses they feel as unethical.

  FP I fail to see anything non-free or troublesome in all this.

Yes, I  think you're right.   I just  reported what I  thought was the
issue here...  I don't know what Paul  Naska (author) would do in case
his program   were used by Marilyn Manson   (he could even  change the
license), but that's to the case now.

Cheers,

Free


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



Re: Password disclosure?

2005-07-22 Thread Glenn Maynard
On Fri, Jul 22, 2005 at 08:02:11AM +0100, Free Ekanayaka wrote:
 |--== Francesco Poli writes:
   FP I fail to see anything non-free or troublesome in all this.
 
 Yes, I  think you're right.   I just  reported what I  thought was the
 issue here...  I don't know what Paul  Naska (author) would do in case
 his program   were used by Marilyn Manson   (he could even  change the
 license), but that's to the case now.

Personally, I think if God cares, he'd be pleased to see Manson exercising
his freedom by making music disparaging Him.  (And I agree with Francesco.)

-- 
Glenn Maynard


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



Website Feedback

2005-07-22 Thread Rob Collyer
Dear Sirs, 

My name is Rob Collyer, and I'm the owner of webforumz.com.

I wanted to let you know that I am interested in exchanging links with 
you.

Webforumz.com has a Google Page rank (PR) of 6 and I am sure your site 
will benefit from exchanging links with us.

We have just added a new resource directory and we would place your 
link there.

Our link details:-

URL: http://www.webforumz.com
Link Title:- Free SEO, Design and development advice
Description:  Webforumz.com offers free SEO help, Web design and 
development advice and gives free website critiques to it's members.

Please drop me an email if you would like to swap links letting me know 
the link title and description of the link you require.

Best regards,

Rob Collyer
webforumz.com

http://www.webforumz.com/ - [EMAIL PROTECTED]

PS: It would be great if you linked to our site. Just drop me a line.


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



Re: Question about license compatibility

2005-07-22 Thread Matthew Garrett
Sean Kellogg [EMAIL PROTECTED] wrote:

 License 1 contains a limitation on use (educational, research and non-profit 
 purposes, without fee) which is a violation of DFSG #6.  License 2 is less 
 obvious, but I personally believe that a provision that forbids charging a 
 fee for distribution is non-free, or at least bad policy.  Certainly having a 
 package that prohibits charging for distribution would prevent it from being 
 on a Debian CD sold by one of the vendors.  Based on the DFSG I'd have to 
 point to #1 and #6...  but both are kind of stretches.

That aspect of license 2 isn't a problem - the DFSG don't require that
people be able to charge for an item of software, merely the aggregate
work.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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



Re: On the definition of source

2005-07-22 Thread Michael K. Edwards
On 7/21/05, Rich Walker [EMAIL PROTECTED] wrote:
 I think you mean:
 
   The story that is circulated now about the tweaking of the S-box is
   that it was to make DES more resistant to differential cryptanalysis,
   which was unknown at the time.

I tend to give Bruce Schneier a certain amount of credence, although I
recognize that he is not a historian.  It is well documented that the
NSA and at least some of the IBM researchers who contributed to the
DES design were cognizant of the technique now known as differential
cryptanalysis prior to the finalization of the DES S-boxes, and that
the S-boxes are locally (and very nearly globally) optimal with
respect to d-c attack.

 Once you allow systems to exist with poor disclosure of the construction
 process of their internals, you have opened up a back door wide enough
 to drive a thousand exploits through.

I don't pretend to do a security (or even maintainability) audit of
all the code that passes through my hands.  I frequently rely on the
good faith (and continued existence) of upstream when choosing
software products on and with which to build my own work.

Yes, I do some due diligence; where it seems worthwhile, I spot-check
the code quality, the documentation completeness, and the history of
the individuals and organizations; and where it really matters, I make
some attempt to evaluate the test coverage and the computational
complexity of core algorithms.  Very, very few open source projects
(and even fewer of the closed-source projects whose internals I've
seen) impress me on all of the above scores; but you've got to have
some tools to work with if you expect to build big things on a small
budget.

 If you are aware that the providers of the system have an agenda, then
 it actually makes sense to work *harder* on the full disclosure of all
 components necessary to reconstruct angle than you would otherwise.

Everybody's got an agenda.  If you're confident that you understand
what that agenda is, then you can hedge intelligently against it. 
Openness is good, but sometimes it reveals not-so-pretty things, and
you need to think about whether a shortcut somebody admits to have
taken is repugnant or merely regrettable.

 (Yes, I *am* in the business of producing stuff that you can only
 reproduce part of from the design data.)

Who isn't?  :-)

Cheers,
- Michael



EUPL draft

2005-07-22 Thread Ales Cepek
Greetings,

I searched archive of the debian-legal list and it seems that the
proposed European Union Public License (EUPL) has not been discussed
here yet.

As this is clearly an important subject (and I am sure that it is
closely related to the software patents agenda), I would like to ask,
if anybody here can say that the EUPL draft would be compatible with
the Debian Social Contract.

Ales Cepek
FFII.cz



Re: Question about license compatibility

2005-07-22 Thread Sean Kellogg
On Friday 22 July 2005 03:28 am, Matthew Garrett wrote:
 Sean Kellogg [EMAIL PROTECTED] wrote:
  License 1 contains a limitation on use (educational, research and
  non-profit purposes, without fee) which is a violation of DFSG #6. 
  License 2 is less obvious, but I personally believe that a provision that
  forbids charging a fee for distribution is non-free, or at least bad
  policy.  Certainly having a package that prohibits charging for
  distribution would prevent it from being on a Debian CD sold by one of
  the vendors.  Based on the DFSG I'd have to point to #1 and #6...  but
  both are kind of stretches.

 That aspect of license 2 isn't a problem - the DFSG don't require that
 people be able to charge for an item of software, merely the aggregate
 work.

Why is that the case?  The license says:

The licensee agrees not to charge for the University of California code
itself. The licensee may, however, charge for additions, extensions, or 
support.

If the license said You cannot charge for this code, nor can you charge for 
it in agregate with other applications outside of this license I might 
suggest the second part is simply unenforcable.  But even if it were 
enforcable, how does selling code in agregate with other code not fall within 
the bar against charging for the code itself?  The CD has value because of 
the code, I am charging for the CD, part of why customers are willing to pay 
for the CD is the value of the code...  strikes me as I am, agregate or not, 
charging for the code.

Additionally, how is this not a discrimination on use prohibited under DFSG 
#6?  One of the uses of software is to package, modify, and resell.  If I 
cannot do that because of the license, isn't that a use descrimination?

-Sean

-- 
Sean Kellogg
3rd Year - University of Washington School of Law
Graduate  Professional Student Senate Treasurer
UW Service  Activities Committee Interim Chair 
w: http://probonogeek.blogspot.com

So, let go
 ...Jump in
  ...Oh well, what you waiting for?
   ...it's all right
    ...'Cause there's beauty in the breakdown



Re: EUPL draft

2005-07-22 Thread Sam Morris

Ales Cepek wrote:

I searched archive of the debian-legal list and it seems that the
proposed European Union Public License (EUPL) has not been discussed
here yet.

As this is clearly an important subject (and I am sure that it is
closely related to the software patents agenda), I would like to ask,
if anybody here can say that the EUPL draft would be compatible with
the Debian Social Contract.

Ales Cepek
FFII.cz


There's a PDFs are available at 
http://europa.eu.int/idabc/en/document/2623/5585#eupl. Unfortunately, 
DRM in the file prevents ps2ascii from working its magic:


  This file requires a password for access.
  Error: /invalidfileaccess in pdf_process_Encrypt

An encouraging start. ;)

--
Sam Morris
http://robots.org.uk/

PGP key id 5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078


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



Re: EUPL draft

2005-07-22 Thread Ivo Danihelka
On Fri, 2005-07-22 at 18:35 +0200, Ales Cepek wrote:
 I would like to ask,
 if anybody here can say that the EUPL draft would be compatible with
 the Debian Social Contract.

Good question. The EUPL draft is available at
http://europa.eu.int/idabc/en/document/2623/5585#eupl

Now is time to propose changes.
-- 
Ivo Danihelka


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



Re: EUPL draft

2005-07-22 Thread Rich Walker
Ivo Danihelka [EMAIL PROTECTED] writes:

 On Fri, 2005-07-22 at 18:35 +0200, Ales Cepek wrote:
 I would like to ask,
 if anybody here can say that the EUPL draft would be compatible with
 the Debian Social Contract.

 Good question. The EUPL draft is available at
 http://europa.eu.int/idabc/en/document/2623/5585#eupl

 Now is time to propose changes.

Here is the text of the license.

I have run it through pdftotext, and then formatted for email reading.

Page breaks have been retained.

EUPL v.01-EN

European Union Public Licence
V.01
EUPL © the European Community 2005

This European Union Public Licence (the EUPL) applies to the Work or
Software (as defined below) which is provided under the terms of this
Licence. Any use of the Work, other than as authorised under this
Licence is prohibited (to the extent such use is covered by a right of
the copyright holder of the Work). The Original Work is provided under
the terms of this Licence when the Licensor (as defined below) has
placed the following notice immediately following the copyright notice
for the Original Work: Licensed under the EUPL v.01 or has expressed by
any other mean his willingness to license under the EUPL.

1. Definitions
In this Licence, the following terms have the following meaning: 

The Licence: this Licence. 

The Original Work or the Software: the software distributed and/or
communicated by the Licensor under this Licence, available as Source
Code and also as Executable Code as the case may be. 

Derivative Works: the works or software that could be created by the
Licensee, based upon the Original Work or modifications thereof. This
Licence does not define the extent of modification or dependence on the
Original Work required in order to classify a work as a Derivative Work;
this extent is determined by copyright law applicable in the country
mentioned in article 15. 

The Work: the Original Work and/or its Derivative Works. 

The Source Code: the human-readable form of the Work which is required
in order to make modifications to it. 

The Executable Code: any code which has generally been compiled and
which is meant to be interpreted by a computer as a program.

The Licensor: the physical or legal person that distributes and/or
communicates the Work under the Licence.

Contributor(s): any physical or legal person who modifies the Work under
the Licence, or otherwise contributes to the creation of a Derivative
Work. 

The Licensee or You: any physical or legal person who makes any usage
of the Software under the terms of the Licence.  

page 1 of 6

-

© European Community 2005


EUPL v.01-EN

-

Distribution and/or Communication: any act of selling, giving, lending,
renting, distributing, communicating, transmitting, or otherwise making
available, on-line or off-line, copies of the Work at the disposal of
any other physical or legal person.

2. Scope of the rights granted by the Licence
The Licensor hereby grants You a world-wide, royalty-free,
non-exclusive, sub-licensable licence to do the following, for the
duration of copyright vested in the Original Work: 

use the Work in any circumstance and for all usage, 

reproduce the Work, 

modify the Original Work, and make Derivative Works based upon the Work,

communicate to the public, including the right to make available or
display the Work or copies thereof to the public and perform publicly,
as the case may be, the Work,

distribute the Work or copies thereof,

lend and rent the Work or copies thereof, 

sub-license rights in the Work or copies thereof.

Those rights can be exercised on any media, supports and formats,
whether now known or later invented, as far as the applicable law
permits so. In the countries where moral rights apply, the Licensor
waives his right to exercise his moral right to the extent allowed by
law in order to make effective the licence of the economic rights here
above listed.

3. Communication of the Source Code
The Licensor may provide the Work either in its Source Code form, or as
Executable Code. If the Work is provided as Executable Code, the
Licensor provides in addition a machine-readable copy of the Source Code
of the Work along with each copy of the Work that the Licensor
distributes or indicates, in a notice following the copyright notice
attached to the Work, a repository where the Source Code is easily and
freely accessible for as long as the Licensor continues to distribute
and/or communicate the Work.

4. Limitations to copyright
Nothing in this Licence is intended to deprive the Licensee of the
benefits from any exception or limitation to the exclusive rights of the
rights owners in the Original Work or Software, of the exhaustion of
those rights or of other applicable limitations thereto.

© European Community 2005

page 2 of 6


EUPL v.01-EN

5. Obligations of the Licensee
The grant of the rights mentioned above is subject to some restrictions
and obligations imposed on the Licensee. Those obligations are the
following: 


Re: EUPL draft

2005-07-22 Thread Humberto Massa Guimarães
 Derivative Works: the works or software that could be created by
 the Licensee, based upon the Original Work or modifications
 thereof. This Licence does not define the extent of modification
 or dependence on the Original Work required in order to classify a
 work as a Derivative Work; this extent is determined by copyright
 law applicable in the country mentioned in article 15. 

This definition should be left to the copyright law.

 Distribution and/or Communication: any act of selling, giving,
 lending, renting, distributing, communicating, transmitting, or
 otherwise making available, on-line or off-line, copies of the
 Work at the disposal of any other physical or legal person.

This appears to include public performance (eg, using the software
to drive a website), which will cause problems and be non-free IMHO.

 5. Obligations of the Licensee The grant of the rights mentioned
 above is subject to some restrictions and obligations imposed on
 the Licensee. Those obligations are the following: 
 
...
 Provision of Source Code: When distributing and/or communicating
 copies of the Work, the Licensee will provide a machine-readable
 copy of the Source Code or indicates a website where this Source
 will be easily and freely available for as long as the Licensee
 continues to distribute and/or communicate the Work.

This is the if you drive a website using this, then you have to
distribute the source, when combined with #1. non-free IMHO.

 10. Acceptance of the Licence The provisions of this Licence can
 be accepted by clicking on an icon I agree placed under the
 bottom of a window displaying the text of this Licence or by
 affirming consent in any other similar way, in accordance with
 rules of applicable law. Clicking on that icon indicates your
 clear and irrevocable acceptance of this Licence and all of its
 terms and conditions. Similarly, the creation by You of a
 Derivative Work or the Distribution and/or Communication by You of
 the Work or copies thereof indicates your clear and irrevocable
 acceptance of this Licence and all of its terms and conditions.

This, together with the preamble's any use of this work, may be
non-free.

 11. Information to the public
 
 In case of any Distribution and/or Communication of the Work by
 You (for example, by offering to download the Work from a website)
 the distribution channel or media (for example, the website) must
 provide the following information to the public: 
 
 your name, as new Licensor providing the Work, 
 
 your geographic and electronic address, 

Whoa... dissident test alert!

 where the Licensor is registered in a trade or similar public
 register,
 
 the trade register in which the Licensor is entered and his
 registration number, 
 
 the different technical steps to follow to conclude the Licence,
 prior to the Distribution and/or the Communication of the Work,

what is to conclude the License?

 where the Licence contract will be accessible, 
 
 the languages which can be used for the conclusion of the Licence.
 
 The Licence terms provided to the Licensee must be made available
 in a way that allows him to store and reproduce them.
 

 14. Jurisdiction Any litigation resulting from the interpretation
 of this license, arising between the European Commission, as a
 Licensor, and any Licensee, will be subject to the jurisdiction of
 the European Court of Justice, as laid down in article 238 of the
 Treaty establishing the European Community. Any litigation arising
 between parties other than the European Commission, and resulting
 from the interpretation of this license, will be subject to the
 exclusive jurisdiction of the competent court:

Whoa... discrimination: differentiates the EC amongst all licensors.

 
  · where the Licensor resides or conducts its primary business, if
  Licensor resides or conducts its primary business inside the
  European Union;
 
  · where the Licensee resides or conducts its primary business if
  Licensor resides or conducts its primary business outside the
  European Union; 
 
 · where the Licensor resides or conducts its primary business, if
 both the Licensor and the Licensee reside or conduct their primary
 business outside the European Union.

Discrimination: this is best left to each copyright law.

 
 15. Applicable Law This License shall be governed by the law of
 the European Union country where the Licensor resides or has his
 registered office. This License shall be governed by the Belgian
 Law if a litigation arises between the European Commission, as a
 Licensor, and any Licensee. This License shall also be governed by
 the Belgian Law if the Licensor has no residence or registered
 office inside a European Union country.

Ditto.

--
HTH,
Massa


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



Re: Question about license compatibility

2005-07-22 Thread Anthony W. Youngman
In message [EMAIL PROTECTED], Sean Kellogg 
[EMAIL PROTECTED] writes

On Friday 22 July 2005 03:28 am, Matthew Garrett wrote:

Sean Kellogg [EMAIL PROTECTED] wrote:
 License 1 contains a limitation on use (educational, research and
 non-profit purposes, without fee) which is a violation of DFSG #6.
 License 2 is less obvious, but I personally believe that a provision that
 forbids charging a fee for distribution is non-free, or at least bad
 policy.  Certainly having a package that prohibits charging for
 distribution would prevent it from being on a Debian CD sold by one of
 the vendors.  Based on the DFSG I'd have to point to #1 and #6...  but
 both are kind of stretches.

That aspect of license 2 isn't a problem - the DFSG don't require that
people be able to charge for an item of software, merely the aggregate
work.


Why is that the case?  The license says:

The licensee agrees not to charge for the University of California code
itself. The licensee may, however, charge for additions, extensions, or
support.


Actually, doesn't the GPL itself contain exactly the same restriction, 
just worded a bit differently?


The GPL forbids charging for the code itself. It DOES permit charging 
(as much as you can get away with) for the effort of packaging it. I'd 
class packaging as support, therefore it could be included on a Debian 
CD because you're not charging for the code.


Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999


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



Re: Public Domain and Packaging

2005-07-22 Thread Anthony W. Youngman
In message 
[EMAIL PROTECTED], Brian M. 
Carlson [EMAIL PROTECTED] writes

There is no such thing as software that isn't copyrighted.  All original
expression that is fixed in a tangible form is immediately copyrighted (at
least, that's the U.S. rule).  There is still lots of debate as to whether it
is possible to disclaim that copyright...  but there is no question that it
is, at the moment of creation, copyrighted.


False.  You, as a lawyer-to-be, should know better than to be imprecise.
U.S. Government software is not copyrighted, and cannot be so,
excepting, of course, the United States Postal Service, which is granted
an exception under 19 U.S.C.


I gather that's false too :-)

The rule, afaict (and I'm not an American), is that copyright *cannot* 
*be* *enforced*, which is not the same thing at all ...


Cheers,
Wol
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999


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



Re: Public Domain and Packaging

2005-07-22 Thread Adam McKenna
On Fri, Jul 22, 2005 at 10:05:09PM +0100, Anthony W. Youngman wrote:
 The rule, afaict (and I'm not an American), is that copyright *cannot* 
 *be* *enforced*, which is not the same thing at all ...

http://www.copyright.gov/circs/circ1.html#piu

--Adam


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



Re: Question about license compatibility

2005-07-22 Thread Florian Weimer
* Anthony W. Youngman:

 Actually, doesn't the GPL itself contain exactly the same restriction, 
 just worded a bit differently?

 The GPL forbids charging for the code itself.

Only for the source code which you must make available when you
distribute binaries, you may not charge for anything but your actual
costs to create and ship the copy.

You can charge what you want for plain source code, binaries, or a
combination of source code and binaries on the same distribution
medium.


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



Re: generated source files, GPL and DFSG

2005-07-22 Thread Florian Weimer
* Matthew Garrett:

 There's two main issues here.

 1) Does everything in main have to include the preferred form of
 modification?

 I don't believe so, 

We had a GR that is usually interpreted in a manner which disagrees
with you.

Certainly we require that the DFSG apply to documentation.  As I've
stated repeatedly, nothing in that GR grants us permission to exempt
fonts, artwork or cryptographic certificates from the source code
requirements.  The certificates part might be somewhat drastic, but I
think that it's highly desirable to have source code for all the
technical documentation we ship, under reasonably permissive licenses,
so that we can update it as needed.  This obviously includes technical
artwork.

Looking at the gsfonts bugs, there even is a completely *technical*
justification to have the source code equivalent for fonts.  Similar
things might happen with artwork whose vectorized (or non-flattened)
version we do not require.

 and it's trivial to demonstrate that this isn't the
 current situation (see the nv driver in the X.org source tree, for
 instance).

I think the last time the nv reference popped up, nobody could confirm
that the source code has been deliberately obfuscated.  It seems to be
the real thing, but there is not enough public documentation to make
any modifications which change the way the driver interacts with the
hardware.

 The DFSG require the availability of source code, and it
 seems reasonable to believe that anything that can be reasonably
 modified falls into that catagory. The graphics are available in a form
 that can be modified with free tools (the .xpm files).

Modifiying them is like patching object code.  It can be done, but we
have chosen not do it that way.  We can choose differenly for artwork,
of course, but I'm not sure if it's desirable to do so.  Some
practical limits obviously exist, though, but they don't apply to
ray-traced images.

 2) Does a GPLed work have to include the preferred form of modification?

 Probably, and this may include the source code for the graphics.
 However, this may also be affected by the copyright holder's
 interpretation of the preferred form of modification and whether the
 GPLed code is a derived work of the graphics or not. On the other hand,
 if we accept my opinion on point (1), even if we need to include the
 pov-ray models we are not required to build from them in order to
 satisfy the DFSG. 

I think it's not acceptable to yse pregenerated files to prevent
software from entering contrib.  (Look at all the Java programs, for
instance.)  If there's a povray dependency, the software cannot be
included in main.


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



Re: generated source files, GPL and DFSG

2005-07-22 Thread Andreas Barth
* Florian Weimer ([EMAIL PROTECTED]) [050722 23:47]:
 * Matthew Garrett:

  There's two main issues here.
 
  1) Does everything in main have to include the preferred form of
  modification?
 
  I don't believe so, 
 
 We had a GR that is usually interpreted in a manner which disagrees
 with you.

Actually, the DFSG says:
| 2. Source Code
|
| The program must include source code, and must allow distribution in
| source code as well as compiled form.

Obviously e.g. fonts are no programms, even if they are in main.


Cheers,
Andi


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



Re: generated source files, GPL and DFSG

2005-07-22 Thread Florian Weimer
* Andreas Barth:

 Actually, the DFSG says:
 | 2. Source Code
 |
 | The program must include source code, and must allow distribution in
 | source code as well as compiled form.

 Obviously e.g. fonts are no programms, even if they are in main.

It's clear from the context (and previous discussion) that this has to
be interpreted as software.

At least I hope so.  It would be rather ridiculous if documentation
under the GNU FDL (with invariant sections, just to be sure) is not
DFSG-compliant, but some BSD-licensed non-editable PDF file is. 8-(


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



Re: generated source files, GPL and DFSG

2005-07-22 Thread Glenn Maynard
On Fri, Jul 22, 2005 at 11:47:09PM +0200, Florian Weimer wrote:
  2) Does a GPLed work have to include the preferred form of modification?
 
  Probably, and this may include the source code for the graphics.
  However, this may also be affected by the copyright holder's
  interpretation of the preferred form of modification and whether the
  GPLed code is a derived work of the graphics or not. On the other hand,
  if we accept my opinion on point (1), even if we need to include the
  pov-ray models we are not required to build from them in order to
  satisfy the DFSG. 
 
 I think it's not acceptable to yse pregenerated files to prevent
 software from entering contrib.  (Look at all the Java programs, for
 instance.)  If there's a povray dependency, the software cannot be
 included in main.

If you mean images generated from povray are non-free because they can't
be built from source without a non-free component, I'd have to disagree
on the grounds that the conclusion is so patently absurd, the premises
must be flawed (whether or not I'm able to pinpoint that flaw).

Looking at it more closely, nothing in DFSG#2 requires that the source be
usable; only that it be source.  That is, if the source to a program is
written in an expensive, proprietary language, it's still source, and
satisfies DFSG#2.  That doesn't mean Debian has to accept it; meeting the
DFSG is a prerequisite, but not a guarantee of inclusion, and Debian is
free to refuse to include software for other reasons (such as we can't
build this source).  I just can't agree that a freely-licensed work, with
source (such as an image with povray source) can be accurately branded non-
free because the tools to build that source are non-free.

-- 
Glenn Maynard


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



Re: generated source files, GPL and DFSG

2005-07-22 Thread Steve Langasek
On Fri, Jul 22, 2005 at 11:56:01PM +0200, Florian Weimer wrote:
 * Andreas Barth:
 
  Actually, the DFSG says:
  | 2. Source Code
  |
  | The program must include source code, and must allow distribution in
  | source code as well as compiled form.
 
  Obviously e.g. fonts are no programms, even if they are in main.

 It's clear from the context (and previous discussion) that this has to
 be interpreted as software.

No, it isn't.  Considering we went through all the effort of a GR to amend
the DFSG and this still says program, not software, I don't see how you
can claim it *has* to be read as software.  (And there are fewer instances
of the word software in the DFSG after the revision than there were
before, anyway...)

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature


Re: generated source files, GPL and DFSG

2005-07-22 Thread Glenn Maynard
On Fri, Jul 22, 2005 at 11:56:01PM +0200, Florian Weimer wrote:
 * Andreas Barth:
 
  Actually, the DFSG says:
  | 2. Source Code
  |
  | The program must include source code, and must allow distribution in
  | source code as well as compiled form.
 
  Obviously e.g. fonts are no programms, even if they are in main.
 
 It's clear from the context (and previous discussion) that this has to
 be interpreted as software.

(To start, in case I'm unclear below, I agree.)

 At least I hope so.  It would be rather ridiculous if documentation
 under the GNU FDL (with invariant sections, just to be sure) is not
 DFSG-compliant, but some BSD-licensed non-editable PDF file is. 8-(

Collossal flamewars around the time of SC2004-003 revolved around the
definition of software, and SC2004-003, as I understand it, made Debian's
interpretation of the word very clear: everything in Debian is software.

It's depressing that, after we finally finish that massive debate, people
want to start all over again with the word program, which is just as
ambiguous a word.

So, let's not word-lawyer the DFSG, and instead focus on what's important:
what's good for Debian's users and Free Software.  Figure out if Debian
*should* require source for fonts and graphics.  Debian can easily and
consistently interpret program in the DFSG to mean either executable
stuff or all software, and arguments about which should be saying why
their choice is better, not merely saying I don't care if it's better,
we should do this one because it's my interpretation.

(And, as a final note, modern hinted fonts do, in fact, contain programs.
I only mention this because Andreas, saying obviously, seems to not know
that.)

-- 
Glenn Maynard


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



Re: generated source files, GPL and DFSG

2005-07-22 Thread Florian Weimer
* Steve Langasek:

 It's clear from the context (and previous discussion) that this has to
 be interpreted as software.

 No, it isn't.  Considering we went through all the effort of a GR to amend
 the DFSG and this still says program, not software, I don't see how you
 can claim it *has* to be read as software.

So you think that the DFSG clauses 2, 6, 7, 8 do not apply to
documentation, only to executables?

This is certainly an interesting position.  Whether it's a valid one
is indeed harder to decide than I thought.


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



Re: generated source files, GPL and DFSG

2005-07-22 Thread Matthew Garrett
Florian Weimer [EMAIL PROTECTED] wrote:
 * Matthew Garrett:
 
 There's two main issues here.

 1) Does everything in main have to include the preferred form of
 modification?

 I don't believe so, 
 
 We had a GR that is usually interpreted in a manner which disagrees
 with you.

We had a GR that stated that everything in main must include source
code. That's not the same thing in the slightest.

 I think the last time the nv reference popped up, nobody could confirm
 that the source code has been deliberately obfuscated.  It seems to be
 the real thing, but there is not enough public documentation to make
 any modifications which change the way the driver interacts with the
 hardware.

Fine. I'll attempt to obtain confirmation that the obscure hex
constants aren't the original and preferred form for modification.

 I think it's not acceptable to yse pregenerated files to prevent
 software from entering contrib.  (Look at all the Java programs, for
 instance.)  If there's a povray dependency, the software cannot be
 included in main.

Yes, but *WHY* do you think that? Christ. This isn't a difficult
conceptual issue. I think that source has to be the preferred form of
modification BECAUSE IT IS DAMNIT is not a convincing argument.

If there existed reasonable ways of modifying Java bytecode to create
new derivative works, then I'd have fewer qualms about shipping Java
bytecode without a compiler. But there aren't, so I do.
-- 
Matthew Garrett | [EMAIL PROTECTED]


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



Re: generated source files, GPL and DFSG

2005-07-22 Thread Florian Weimer
* Matthew Garrett:

 I think it's not acceptable to yse pregenerated files to prevent
 software from entering contrib.  (Look at all the Java programs, for
 instance.)  If there's a povray dependency, the software cannot be
 included in main.

 Yes, but *WHY* do you think that?

It makes it very hard to fix bugs in the pregenerated files.
Look at the gsfonts mess, it's pretty instructive.

 If there existed reasonable ways of modifying Java bytecode to create
 new derivative works, then I'd have fewer qualms about shipping Java
 bytecode without a compiler. But there aren't, so I do.

From a technical point of view, Java bytecode is as good as
uncommented source code.  The Java-to-bytecode compilers are not very
sophisticated.


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



A question about converting code to another programming language

2005-07-22 Thread svante
Dear Debian legal,

I have a few questions about software developement. One of them is whether
a program written in e.g. Fortran by me or somebody else (who owns the
copyright) is converted to C (not f2c). How is copyright changed and what
about patent issues (maybe not relevant).

Further questions will follow.

Thanks,
Svante


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



Re: generated source files, GPL and DFSG

2005-07-22 Thread Matthew Garrett
Florian Weimer [EMAIL PROTECTED] wrote:
 * Matthew Garrett:
 Yes, but *WHY* do you think that?
 
 It makes it very hard to fix bugs in the pregenerated files.
 Look at the gsfonts mess, it's pretty instructive.

Not all pregenerated files are difficult to modify.

 If there existed reasonable ways of modifying Java bytecode to create
 new derivative works, then I'd have fewer qualms about shipping Java
 bytecode without a compiler. But there aren't, so I do.
 
From a technical point of view, Java bytecode is as good as
 uncommented source code.  The Java-to-bytecode compilers are not very
 sophisticated.

We're happy to accept uncommented source code in main. If Java bytecode
is as good as that, it would imply that we're happy to accept it in main
as well.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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



Re: generated source files, GPL and DFSG

2005-07-22 Thread Michael K. Edwards
On 7/22/05, Florian Weimer [EMAIL PROTECTED] wrote:
 It makes it very hard to fix bugs in the pregenerated files.
 Look at the gsfonts mess, it's pretty instructive.

That's an argument from maintainability, not from freeness.  The two
are, in my view anyway, distinct though related judgments.

 From a technical point of view, Java bytecode is as good as
 uncommented source code.  The Java-to-bytecode compilers are not very
 sophisticated.

Ditto.  But observe that bytecode is not only uncomment_ed_, it is
effectively uncomment_able_, which makes it far less maintainable by
downstream contributors.  The freedom to modify is not reduced to a
technicality by relative impracticality -- a license to modify is a
pretty good defense against complaints about reverse engineering and
repurposing -- but it is certainly abridged.

Again I would argue that, if the GFingerPoken source tarball contained
only the XPM versions of the artwork and did not discuss how they had
been created, that would represent at most a minor barrier to ongoing
maintenance of the software.  The fact that upstream has gone the
extra mile and provided povray input is very nice; a future maintainer
who wants to render them into, say, Display PostScript for use on a
300 DPI LCD has something to work with.

Someday perhaps these will be the bad old days when people didn't
turn up their noses at any code or data without a perfect,
all-free-tools audit trail.  Given the pressure to cram abandonware
clones into main, it doesn't look to me like we're going in the
direction of higher standards; but maybe that's only a short term
trend.  I don't like the sort of message it would send to relegate
GFingerPoken to contrib while retaining the many (perhaps most) other
games in main made of crap-ass code and bitmap images; but as usual
IANADD and it's not my problem.  :-)

Cheers,
- Michael



Re: generated source files, GPL and DFSG

2005-07-22 Thread Glenn Maynard
On Sat, Jul 23, 2005 at 12:40:00AM +0100, Matthew Garrett wrote:
 Florian Weimer [EMAIL PROTECTED] wrote:
 From a technical point of view, Java bytecode is as good as
  uncommented source code.  The Java-to-bytecode compilers are not very
  sophisticated.
 
 We're happy to accept uncommented source code in main. If Java bytecode
 is as good as that, it would imply that we're happy to accept it in main
 as well.

Uncommented source is not the same as source with comments stripped to make
it harder to understand.

The former is merely potentially bad source code, but clearly source.  The
latter is obfuscation, and is not source at all.  Assuming what Florian
says is accurate, Java bytecode is not source any more than C code with
comments stripped, which would imply that Debian should not be accepting
it as source.

Of course, it can be difficult or impossible to tell the difference between
bad code and lightly obfuscated code, as with the nVidia driver.  Again,
that only means it's more difficult to determine if what you've been given
is really the source.

(And I also readily acknowledge that lightly obfuscated code is better than
none at all, but that's in the same vein as slightly non-free is better
than onerously non-free--better, but not good enough.)

-- 
Glenn Maynard


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



Re: generated source files, GPL and DFSG

2005-07-22 Thread Matthew Garrett
Glenn Maynard [EMAIL PROTECTED] wrote:

 Uncommented source is not the same as source with comments stripped to make
 it harder to understand.
 
 The former is merely potentially bad source code, but clearly source.  The
 latter is obfuscation, and is not source at all.  Assuming what Florian
 says is accurate, Java bytecode is not source any more than C code with
 comments stripped, which would imply that Debian should not be accepting
 it as source.

So if I write C with comments and then remove them that's not DFSG free,
but if I fail to add them in the first place then it's fine for main?

-- 
Matthew Garrett | [EMAIL PROTECTED]


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



Re: generated source files, GPL and DFSG

2005-07-22 Thread Don Armstrong
On Sat, 23 Jul 2005, Matthew Garrett wrote:
 So if I write C with comments and then remove them that's not DFSG
 free, but if I fail to add them in the first place then it's fine
 for main?

I've no idea if it's fine for main,[1] but it's clearly DFSG Free.

Whether a work is DFSG Free is a separate question from whether we
should actually distribute a work.


Don Armstrong

1: I'd question a maintainer's sanity if they said they were capable
of maintaining such a thing.
-- 
A people living under the perpetual menace of war and invasion is very
easy to govern. It demands no social reforms. It does not haggle over
expenditures on armaments and military equipment. It pays without
discussion, it ruins itself, and that is an excellent thing for the
syndicates of financiers and manufacturers for whom patriotic terrors
are an abundant source of gain.
 -- Anatole France

http://www.donarmstrong.com  http://rzlab.ucr.edu


signature.asc
Description: Digital signature


Re: generated source files, GPL and DFSG

2005-07-22 Thread Glenn Maynard
On Sat, Jul 23, 2005 at 01:32:37AM +0100, Matthew Garrett wrote:
 Glenn Maynard [EMAIL PROTECTED] wrote:
 
  Uncommented source is not the same as source with comments stripped to make
  it harder to understand.
  
  The former is merely potentially bad source code, but clearly source.  The
  latter is obfuscation, and is not source at all.  Assuming what Florian
  says is accurate, Java bytecode is not source any more than C code with
  comments stripped, which would imply that Debian should not be accepting
  it as source.
 
 So if I write C with comments and then remove them that's not DFSG free,
 but if I fail to add them in the first place then it's fine for main?

Yes; as noble a goal as is writing good, well-commented code, that's not
what the DFSG is about; it's about free software, including source code.
If you write a well-commented program, and remove the comments in the copy
you give me, you havn't given me the source at all.  Why should Debian
consider obfuscated code sufficient for DFSG#2?

-- 
Glenn Maynard


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



Re: generated source files, GPL and DFSG

2005-07-22 Thread Matthew Garrett
Glenn Maynard [EMAIL PROTECTED] wrote:
 On Sat, Jul 23, 2005 at 01:32:37AM +0100, Matthew Garrett wrote:
 So if I write C with comments and then remove them that's not DFSG free,
 but if I fail to add them in the first place then it's fine for main?
 
 Yes; as noble a goal as is writing good, well-commented code, that's not
 what the DFSG is about; it's about free software, including source code.
 If you write a well-commented program, and remove the comments in the copy
 you give me, you havn't given me the source at all.  Why should Debian
 consider obfuscated code sufficient for DFSG#2?

So say we have two drivers for a piece of hardware. One is written
without comments. One was originally commented, but the comments have
been removed. Both provide the same amount of information about how they
work. Both are released under the same license. Both provide exactly the
same freedoms to our users.

How is one of these free and the other non-free?
-- 
Matthew Garrett | [EMAIL PROTECTED]


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



Re: generated source files, GPL and DFSG

2005-07-22 Thread Jeff King
On Sat, Jul 23, 2005 at 02:35:01AM +0100, Matthew Garrett wrote:

 So say we have two drivers for a piece of hardware. One is written
 without comments. One was originally commented, but the comments have
 been removed. Both provide the same amount of information about how they
 work. Both are released under the same license. Both provide exactly the
 same freedoms to our users.
 
 How is one of these free and the other non-free?

Let's say I write a program in C code and compile it to assembly
language, which I distribute. Somebody else writes an equivalent program
directly in assembly language and distributes it. The distributed
products contain the same amount of information about how they work.

How is one of these free and the other non-free?

-Peff


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



Re: generated source files, GPL and DFSG

2005-07-22 Thread Glenn Maynard
On Sat, Jul 23, 2005 at 02:35:01AM +0100, Matthew Garrett wrote:
 So say we have two drivers for a piece of hardware. One is written
 without comments. One was originally commented, but the comments have
 been removed. Both provide the same amount of information about how they
 work. Both are released under the same license. Both provide exactly the
 same freedoms to our users.
 
 How is one of these free and the other non-free?

One provided source, the other did not, and Debian considers having source
fundamental to having a free program.

Take it a step further, and say we have two drivers: one written in heavily-
optimized, uncommented assembly, and one written in C, compiled with
optimizations and disassembled.  They look pretty much the same; as you say,
both provide the same freedoms to our users.  Is disassembly output of a
compiled program source to you?  Is one free and the other non-free?

(My answer is probably obvious: a disassembly dump of a program, no matter
how good the disassembler, no matter that it used debug information to
reconstruct function boundaries and resulted in assembly output practically
equivalent to hand-written assembly code, is not source and isn't acceptable
as such--even though a program that was actually written in assembly
and resulted in the same thing would be.)

-- 
Glenn Maynard


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



Re: failure notice @ [EMAIL PROTECTED]

2005-07-22 Thread Glenn Maynard
On Sat, Jul 23, 2005 at 02:07:09AM -, [EMAIL PROTECTED] wrote:
 Hi. This is the qmail-send program at peff.net.
 I'm afraid I wasn't able to deliver your message to the following addresses.
 This is a permanent error; I've given up. Sorry it didn't work out.
 
 [EMAIL PROTECTED]:
 You sent mail to a mailbox which is used only for receiving
 mailing list postings.
  
 If you did this because you are sending unsolicited bulk
 email, please don't. I don't want to read it.
  
 If you did this because you are CC'ing me on a list email,
 please don't.  I'll just end up with two copies of your
 response. 
  
 If you did this because you are responding privately to my
 list comments, please don't. The list is a public forum, and
 others may benefit from our discussion:
 http://www.eyrie.org/~eagle/faqs/questions.html
  
 If you really do want to get in touch with me via private
 email, please send mail to me directly at:
  
   [EMAIL PROTECTED]

Posting mail to public mailing lists with a deliberately invalid reply
address, and making people jump through hoops for the privilege of
mailing you, is a severe breach of basic etiquette.  Please don't do
this.

 --- Below this line is a copy of the message.
 
 Return-Path: [EMAIL PROTECTED]
 Received: (qmail 5475 invoked from network); 23 Jul 2005 02:07:09 -
 Received: from unknown (HELO c-65-96-98-23.hsd1.ma.comcast.net) (65.96.98.23)
   by 0 with SMTP; 23 Jul 2005 02:07:09 -
 Received: by c-65-96-98-23.hsd1.ma.comcast.net (Postfix, from userid 1000)
   id CF13D100AA9BC; Fri, 22 Jul 2005 22:07:08 -0400 (EDT)
 Date: Fri, 22 Jul 2005 22:07:08 -0400
 From: Glenn Maynard [EMAIL PROTECTED]
 To: Jeff King [EMAIL PROTECTED]
 Subject: Re: generated source files, GPL and DFSG
 Message-ID: [EMAIL PROTECTED]
 References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 
 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL 
 PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
 Mime-Version: 1.0
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 In-Reply-To: [EMAIL PROTECTED]
 Mail-Copies-To: nobody
 X-No-CC: Branden subscribes to this list; do not CC him on replies.
 User-Agent: Mutt/1.5.9i
 
 On Fri, Jul 22, 2005 at 10:05:49PM -0400, Jeff King wrote:
  On Sat, Jul 23, 2005 at 02:35:01AM +0100, Matthew Garrett wrote:
  
   So say we have two drivers for a piece of hardware. One is written
   without comments. One was originally commented, but the comments have
   been removed. Both provide the same amount of information about how they
   work. Both are released under the same license. Both provide exactly the
   same freedoms to our users.
   
   How is one of these free and the other non-free?
  
  Let's say I write a program in C code and compile it to assembly
  language, which I distribute. Somebody else writes an equivalent program
  directly in assembly language and distributes it. The distributed
  products contain the same amount of information about how they work.
  
  How is one of these free and the other non-free?
 
 Get out of my head!

-- 
Glenn Maynard


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



Re: generated source files, GPL and DFSG

2005-07-22 Thread Michael K. Edwards
On 7/22/05, Jeff King [EMAIL PROTECTED] wrote:
 Let's say I write a program in C code and compile it to assembly
 language, which I distribute. Somebody else writes an equivalent program
 directly in assembly language and distributes it. The distributed
 products contain the same amount of information about how they work.
 
 How is one of these free and the other non-free?

Nothing stops us from considering the evidence of the upstream
developer's intent when they release a program in a less than
perfectly maintainable condition.  It's natural that they know some
things about it we don't, but if it seems obfuscated beyond the limits
of good faith, somebody should blow a whistle.

We know perfectly well that the NVidia driver is in the condition it's
in partly because its development is funded by a profit-seeking entity
that has no wish to destabilize its market position, either by making
it easier for a competitor to produce a graphics chip to which the
driver could easily be ported, or by losing its privileged
relationship to Microsoft when an inspired Linux hacker reworks the
driver and related bits of the Linux graphics subsystem to get triple
the FPS of the Windows (or XBox) version.  (I think triple is probably
an exaggeration, but there's room for improvement.)  It's very clever
of NVidia to support both a fully proprietary Linux driver and a
driver we can call open source if we don't look too closely.  Do we
mind being manipulated this way?  A little, but we work with it.

That's an extreme case, but the fact is that upstreams do all sorts of
things to the code and documentation to pursue agendas at best
orthogonal to, and often in opposition to, their users' and especially
potential forkers' interests.  [I was going to add another rant about
the FSF here, but got bored with it.]

Cheers,
- Michael