Re: Bug#248853: 3270: 5250 emulation code, all rights reserved

2004-08-09 Thread Nathanael Nerode

In case anyone was wondering, this is far from cleared up.  :-(


>Ahh, the horror continues.
>
>I would be happy to remove all of the Minolta-copyrighted code.
Perhaps the best choice.

Beat Rubischon has sent a nice message apparently granting permission to 
use his code under "any license" as long as his name is preserved 
(earlier in the bug trail) -- so for anything copyrighted by him, we're OK.


*UN*fortunately he apparently isn't the sole copyright holder of the 
5250 code.  Permission would be needed from Minolta, and I seriously 
doubt he has the right to speak for them, even though he's an employee. 
 I doubt he wants to go to the trouble of clearing this with Minolta's 
legal department.  :-(


>As for the "what this means" paragraph in the Lineage file, that was 
>written
>by an idiot, and should be removed (in fact, I thought I had removed 
it >already).

Well, that's simple then.  :-)

>As for the Georgia Tech copyrighted code, I've been through this issue 
>with
>them twice over the years, and the "public use" language was something 
>they
>suggested.  I don't know what it means, either.  Shall I give it 
>another go
>with them, to see if they will allow a different copyright notice?  If 
>so,

>what kinds of notices would be acceptable?

Ideally, the MIT/X11-like license already used by most of the code; that 
would look like this:

> Copyright © 1989 by Georgia Tech Research Corporation, Atlanta, GA 30332.
> Permission to use, copy, modify, and distribute this software and its 
>documentation for any purpose and without fee is hereby granted, 
>provided that the above copyright notice appear in all copies and that 
>both that copyright notice and this permission notice appear in 
>supporting documentation.


(It could also be consolidated with the other essentially identical 
notices.)


If they don't like that, perhaps change it to "hereby granted to all 
members of the public"?  That's probably (hopefully) what they mean by 
"public use".


Alternately, the Georgia Institute of Technology license appears to be 
an acceptable and DFSG-free license (-legal, please verify -- I'm not 
100% sure).  That, changed for Georgia Tech Research, would look like this:

> Copyright © 1989 by Georgia Tech Research Corporation, Atlanta, GA 30332.
>All rights reserved except for those rights explicitly mentioned below.
>Permission is granted to distribute freely or to modify and distribute 
>freely any materials and information contained herein as long as the 
>above copyright and all terms associated with it remain intact.


This appears to be a free, all-permissive license.  (Debian-legal should 
probably comment, of course; I am assuming that "freely" is not a no-fee 
restriction but simply intended to make the permission broad, and that 
"copy" is clearly implied by "distribute".  Ideally the copyright 
holders would clarify that my interpretation is the same as theirs.)  If 
Georgia Tech Research Corporation has some relationship with the Georgia 
Institute of Technology, it might be more amenable to using a "familiar" 
license statement.


If none of these options work for them, we really need to figure out 
what they *want*.  If we know *why* they don't like the standard license 
used for the rest of 3270, debian-legal can probably recommend a license 
tailored to suit their needs.




Conditions vs. (possibly inaccurate) notices (was Re: Please pass judgement on X-Oz licence: free or nay?

2004-08-09 Thread Nathanael Nerode

Matthew Garrett wrote:
>The wording of the clause is identical. Are you claiming that the
>differing location of it in the license alters the situations that it
>applies to?

Absolutely.

In the X11 license:

"Permission is hereby granted provided that... and that... appear in 
supporting documentation.

[Warranty Disclaimer]
[Problem Clause]
[Other Stuff]"

Note that only the conditions in the "Permission is granted" sentence 
are actually conditions on the permission grant.  The "Problem Clause" 
has a status equivalent to the warranty disclaimer; it's another statement.


In the X-Oz license:
"Permission is hereby granted... subject to the following conditions:
1. [Other Stuff]
2. [Other Stuff]
3. [Other Stuff]
4. [Problem Clause]
[Warranty Disclaimer]

Here, the Problem Clause is *clearly* a condition on the permission 
grant.  (The Warranty Disclaimer might be, but probably isn't.)


-
Now, the BSD no-advertising clause is a condition.
So if the Problem Clause ("Except as contained in this notice, the name 
of X-Oz Technologies shall not be used in advertising or otherwise to 
promote the sale, use or other dealings in this Software without prior 
written authorization from X-Oz Technologies.") is equivalent to the 
similar BSD clause ("Neither the name of the  nor the 
names of its contributors may be used to endorse or promote products 
derived from this software without specific prior written permission"),

then it is of course fine.

However, Branden believes that the X clause is stronger and more 
restrictive.  (Which doesn't really matter if it's not a condition of 
the permission grant, but does if it is.)  We asked X-Oz if they simply 
meant it to be equivalent to the BSD clause, but we got weird nonsense 
and no useful reply.  :-(



Side topic.

Warranty disclaimers often state false things.  For instance, the 
standard disclaimer in the BSD license says IN NO EVENT SHALL THE 
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY ...DAMAGES... ARISING 
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE"; many warranties simply 
cannot be disclaimed in many jurisdictions, the copyright owner could be 
offering a separate warranty on the software, and so forth.  The 
"Problem Clause" could state false things as well, but it's not actually 
a condition of the permission grant, so it's not a big deal.


I have mentioned before that making people agree to poorly drafted 
warranty disclaimers in order to use/modify/distribute software can open 
up a can of worms and may even make the software non-free.  In contrast, 
having the warranty disclaimer as a separate legal notice which must be 
preserved but is not a condition -- and this is the usual thing -- 
raises far fewer issues, if any.


The GPL does *much* better on the warranty front than most licenses 
because it includes key phrases like "TO THE EXTENT PERMITTED BY 
APPLICABLE LAW" and "EXCEPT WHEN OTHERWISE STATED IN WRITING".  So it's 
just fine that the GPL warranty disclaimer *is* a condition, because 
it's actually properly drafted.




Re: Free & open DRM software

2004-08-09 Thread Brian Thomas Sniffen
Brian M Hunt <[EMAIL PROTECTED]> writes:

> I was contemplating the conundrum of open source digital rights management, 
> and would like some feedback. If someone were to write digital rights 
> software, eg. for downloading from iTunes, could they license it under a free 
> software license like the GPL, with an added clause:
>
> "If the Program is designed to uphold digital rights management pursuant to 
> the distribution of copyrighted material, any modification to the Program to 
> undermine the terms of distribution for that copyright will violate this 
> license.   All rights to publish, redistribute, and use the modified Program 
> are revoked upon violation of this clause.   Derivative works may not modify 
> this license so as to remove this clause."

That isn't DFSG-free, no.  The last sentence also reflects a curious
understanding of how copyrights and licenses adhere to works.

Perhaps you would be satisfied with a notice that, in the US and the
EU and maybe elsewhere, it's often illegal to circumvent digital
rights management technologies -- and that while your copyright
doesn't stop them from doing so, the copyrights of others do.

Note that this *isn't* part of the license, just a note passed along
with the software.

-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]



Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Steve Langasek
On Mon, Aug 09, 2004 at 01:33:09PM +0100, Matthew Garrett wrote:
> Freek Dijkstra <[EMAIL PROTECTED]> wrote:

> > Personally I fear the upstream maintainers are not willing to change their
> > code for just this. After all, they already link with the technically
> > excellent OpenSSL library, which is indeed open source.

> If you're lucky, no code changes would be needed.

> > I take it that it is not possible to put a source-only (no-binary)
> > distribution) in the main section of Debian?

> Nope. The same argument actually applies - if netatalk is a derivative
> of openssl (and if it's been coded against it, then the FSF would
> probably claim that it is) then it's illegal to distribute it in any
> form under the current license.

Not exactly.  The issue with GPL applications linking against OpenSSL is
the GPL's broad definition of "source code", which for an application
includes any libraries it links against *except* for components that are
part of the OS and are not distributed with the application.

Debian always fails to be eligible for the so-called "OS exemption", on
account of this second requirement.

In any case, the issue is not linked at all to the FSF's much weaker
claim that applications constitute derivative works of libraries.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature


Re: Re: Please pass judgement on X-Oz licence: free or nay?

2004-08-09 Thread Nathanael Nerode
Joe Wreschnig wrote in 
http://lists.debian.org/debian-legal/2004/08/msg00200.html:


>I guess I'm also convinced that just because it's not numbered like it
>is in the BSD license, doesn't make it not a clause. That is, the X
>license says "Permission is hereby granted... subject to the following
>conditions:"
Actually, this is incorrect.  Which perhaps is the key difference.  From 
http://www.x.org/Downloads_terms.html:


>Permission is hereby granted, free of charge, to any person obtaining a
>copy of this software and associated documentation files (the
>"Software"), to deal in the Software without restriction, including
>without limitation the rights to use, copy, modify, merge, publish,
>distribute, and/or sell copies of the Software, and to permit persons
>to whom the Software is furnished to do so, provided that the above
>copyright notice(s) and this permission notice appear in all copies of
>the Software and that both the above copyright notice(s) and this
>permission notice appear in supporting documentation.

It simply does not say "subject to the following conditions".  It says:
>...provided that the above
>copyright notice(s) and this permission notice appear in all copies of
>the Software and that both the above copyright notice(s) and this
>permission notice appear in supporting documentation.

The conditions quite clearly end with the period at the end of the 
sentence.  That single sentence is, in fact, the entire permission 
grant.  Above it is the copyright notice (which ends with the words "All 
rights reserved.").  Below it are some other statements.


A more exhaustive analysis:  The permissions are granted "...provided 
that... (condition 1) and (condition 2)."  Condition 1 is "the above 
copyright notice(s) and this permission notice appear in all copies of 
the Software".  Condition 2 is "the above copyright notice(s) and this 
permission notice appear in all copies of the Software".  Then the 
sentence ends, ending the grant of permission and completing the list of 
conditions.


This is simply parsing of English.

> and then goes on to lay out the requirement that the
>copyright notice be preserved; then the warranty disclaimer; then the
>paragraph in question. At no point is it obvious to me that "the
>following conditions" is ending and being replaced by something else.

Pay more attention.  :-)

The warranty disclaimer is not a condition of the license; it's not a 
condition of any sort, simply an assertion that there is no warranty. 
Now if a license said "provided that you accept the following 
disclaimer", that would be a condition.


Similarly, the sentences following the warranty disclaimer are not 
conditions; they're wholly independent.


"Except as contained in this notice, the name of a copyright holder 
shall not be used in advertising or otherwise to promote the sale, use 
or other dealings in this Software without prior written authorization 
of the copyright holder."


"X Window System is a trademark of The Open Group."

"OSF/1, OSF/Motif and Motif are registered trademarks, and OSF, the OSF 
logo, LBX, X Window System, and Xinerama are trademarks of the Open 
Group. All other trademarks and registered trademarks mentioned herein 
are the property of their respective owners."


Any of these claims could be independently disputed.  They are 
independent sentences.




Re: New MySQL "Free/Libre and Open Source Software (FLOSS) Exception" licence.... (re #242449)

2004-08-09 Thread Mahesh T. Pai
Jonas Meurer said on Tue, Aug 10, 2004 at 03:00:21AM +0200,:

 > how exatly, is php itself not gpl compatible, or only the php scripts?

>From http://www.gnu.org/philosophy/license-list.html:-


This license is used by most of PHP4. It is a non-copyleft free
software license which is incompatible with the GNU GPL. 

We recommend that you not use this license for anything except PHP
add-ons. 
 

-- 
 Mahesh T. Pai<<>>   http://paivakil.port5.com
free -  (adj) able to  act at will;  not hampered;
   not  under  compulsion  or restraint;  free
   from  obligations or  duties; not  bound to
   servitude; at liberty.



Free & open DRM software

2004-08-09 Thread Brian M Hunt
I was contemplating the conundrum of open source digital rights management, 
and would like some feedback. If someone were to write digital rights 
software, eg. for downloading from iTunes, could they license it under a free 
software license like the GPL, with an added clause:

"If the Program is designed to uphold digital rights management pursuant to 
the distribution of copyrighted material, any modification to the Program to 
undermine the terms of distribution for that copyright will violate this 
license.   All rights to publish, redistribute, and use the modified Program 
are revoked upon violation of this clause.   Derivative works may not modify 
this license so as to remove this clause."

Similarly, would such a clause violate DFSG? If this cannot satisfy DFSG, what 
changes are required to make it so?

The hyperbole of this obviously leads to all sorts of non-free problems, where 
authors start contriving arbitrary restrictions. Is there a restriction that 
can be placed on open source software that prevents modifying digital rights 
management, and yet still satisfies DFSG?

Regards,
Brian Hunt



Re: nmap license

2004-08-09 Thread Glenn Maynard
On Mon, Aug 09, 2004 at 08:07:01PM -0400, MOB JUNKY wrote:
>  * Note that the GPL places important restrictions on "derived works",
> yet *
>  * it does not provide a detailed definition of that term.  To
> avoid   *
>  * misunderstandings, we consider an application to constitute
> a   *
>  * "derivative work" for the purpose of this license if it does any of
> the *

As I understand it, "derivative work" is a specific legal term, defined
by law, not individual licenses.

>  * o Integrates source code from
> Nmap  *

>  * o Links to a library or executes a program that does any of the
> above   *

"Executes a program"?  Is this claiming that bash and Linux are derivative
works of nmap?

>  * We don't consider these to be added restrictions on top of the GPL,
> but *
>  * just a clarification of how we interpret "derived works" as it
> applies  *
>  * to our GPL-licensed Nmap product.  This is similar to the way
> Linus *
>  * Torvalds has announced his interpretation of how "derived
> works"*
>  * applies to Linux kernel modules.  Our interpretation refers only

As far as I know, Linus has no real standing to make such "interpretations";
I really wish people wouldn't use him as an example of how to handle legal
issues, as he sets, as far as I can tell, a horribly bad example.

-- 
Glenn Maynard



Re: New MySQL "Free/Libre and Open Source Software (FLOSS) Exception" licence.... (re #242449)

2004-08-09 Thread Jonas Meurer
On 10/08/2004 Christian Hammers wrote:
> The MySQL and its libraries has been put under the GPL (not LGPL) a while ago
> and since then conflicts with PHP etc which is not GPL compatible but still
> DFSG compliant (or so I understood).

how exatly, is php itself not gpl compatible, or only the php scripts?

if php itself is gpl compatible (sorry, i simply don't know), the
problem is about php-scripts not being gpl compatible?

or is it the php package not being gpl compatible, but linked against
mysql?

what about python, do we have similar problems there?

bye
 jonas



mysql license and python-mysqldb

2004-08-09 Thread Jonas Meurer
hi,

as far as i understood the messages on debian-legal, the license of
some mysql libraries changed from lgpl to gpl.
this makes it impossible to link any non-gpl conform software with them.

anyway, i've no glue about what this has to do with pyhton-mysqldb, as
this is licensed under "GPL or the original license based on Python
1.5.2's license", where we always can choose GPL.

i don't know whether "python 1.5.2's license" is gpl compatible or not,
but maybe we can ask upstream to clarify the situation if it is that
way.

bye
 jonas



nmap license

2004-08-09 Thread MOB JUNKY
Download nmap 3.55 and look at the source code. Each file contains a
notice with the following text.  Is this dfsg-free?   I'm
not-subscribed, and I don't care about the results of this, so don't
bother to cc me.  I just want to stir the pot.

 * Note that the GPL places important restrictions on "derived works",
yet *
 * it does not provide a detailed definition of that term.  To
avoid   *
 * misunderstandings, we consider an application to constitute
a   *
 * "derivative work" for the purpose of this license if it does any of
the *
 *
following: 
*
 * o Integrates source code from
Nmap  *
 * o Reads or includes Nmap copyrighted data files, such
as*
 *   nmap-os-fingerprints or
nmap-service-probes.  *
 * o Executes
Nmap *
 * o Integrates/includes/aggregates Nmap into an executable
installer  *
 * o Links to a library or executes a program that does any of the
above   *

* *
 * The term "Nmap" should be taken to also include any portions or
derived *
 * works of Nmap.  This list is not exclusive, but is just meant
to*
 * clarify our interpretation of derived works with some common
examples.  *
 * These restrictions only apply when you actually redistribute Nmap. 
For *
 * example, nothing stops you from writing and selling a
proprietary   *
 * front-end to Nmap.  Just distribute it by itself, and point people
to   *
 * http://www.insecure.org/nmap/ to download
Nmap. *

* *
 * We don't consider these to be added restrictions on top of the GPL,
but *
 * just a clarification of how we interpret "derived works" as it
applies  *
 * to our GPL-licensed Nmap product.  This is similar to the way
Linus *
 * Torvalds has announced his interpretation of how "derived
works"*
 * applies to Linux kernel modules.  Our interpretation refers only
to *
 * Nmap - we don't speak for any other GPL
products.   *

* *
 * If you have any questions about the GPL licensing restrictions on
using *
 * Nmap in non-GPL works, we would be happy to help.  As mentioned
above,  *
 * we also offer alternative license to integrate Nmap into
proprietary*
 * applications and appliances.  These contracts have been sold to
many*
 * security vendors, and generally include a perpetual license as well
as  *
 * providing for priority support and updates as well as helping to
fund   *
 * the continued development of Nmap technology.  Please
email *
 * [EMAIL PROTECTED] for further
information. *






Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Glenn Maynard
On Tue, Aug 10, 2004 at 12:06:39AM +0200, Freek Dijkstra wrote:
> >> However, that being said, I claim it does not apply to this particular
> >> scenario! In this case, I suggested to distributed a binary of netatalk,
> >> including the UAMS linked with OpenSSL under GPL. To see if this is allowed
> >> you have to look at the *OpenSSL-licence*, NOT at the *GPL*.
> > 
> > This is incorrect.  It is the GPL which is being violated, not the OpenSSL
> > license.
> 
> Huh. Why?
> 
> I propose to built netatalk (with GPL licence) against OpenSSL (a non-GPL
> licence) and distribute the whole with the GPL licence. How does that
> violate the GPL?

You can't distribute the whole under the GPL.  You must adhere to the OpenSSL
license *and* the GPL, since the binary you're distributing combines both.

In order to distribute a binary under the GPL, you must grant a license
to the entire work under the terms of the GPL (see GPL section 6).  That
includes all code being used, regardless of what technology is being used
to bind that stuff together (static linking, dynamic linking).  However,
you can't do that; you don't have permission to grant me a license to
OpenSSL under those terms.  Therefore, you can't comply with GPL#6, and
so you can't distribute the binary.

> PS: I took this off-list, since I have the impression people get bored by
> this topic. Feel free to respond on-list though!

I'd prefer to keep things on the list.  Although this is a repeat topic, it's
more productive to repeat it where others can read it, so if, for example, we
happen to come up with any nice, succinct explanations, they can be referred
to the next time the topic comes up.

Also, it's possible that I may not personally be able to explain everything;
it's fairly common to not be able to figure out exactly where misunderstandings
are.  If we keep the discussion public, it's possible that somebody else
will figure it out.

Don't worry too much about people getting bored with a topic; if people
really don't want to bother with it, they'll stop reading it.  I'll be
upfront, though: this is a very well-understood topic and you're not raising
any new arguments, so I don't see any possibility that this discussion will
change conclusions or policies.  However, I do believe that one of the
secondary uses of this list is to help people better understand free software
licensing issues--insofar as us phony non-lawyers can possibly hope to, at
least--and so I think this type of discussion is useful (within reason).

(Obviously, IANAL, TINLA, etc.)

-- 
Glenn Maynard



Re: Bug#248853: 3270: 5250 emulation code, all rights reserved

2004-08-09 Thread Richard A Nelson

The upstream reply is below...  I think I have a copy of some of the
earlier go 'rounds on this - when Carey worked with Paul.

Be careful folks, while Paul is willing to help - I don't think we can
come back on this issue at a later time, we better get it right this
time !

---
Ahh, the horror continues.

I would be happy to remove all of the Minolta-copyrighted code.

As for the "what this means" paragraph in the Lineage file, that was written
by an idiot, and should be removed (in fact, I thought I had removed it 
already).

As for the Georgia Tech copyrighted code, I've been through this issue with
them twice over the years, and the "public use" language was something they
suggested.  I don't know what it means, either.  Shall I give it another go
with them, to see if they will allow a different copyright notice?  If so,
what kinds of notices would be acceptable?
--
-- 
Rick Nelson
Where do you think you're going today?



New MySQL "Free/Libre and Open Source Software (FLOSS) Exception" licence.... (re #242449)

2004-08-09 Thread Christian Hammers
Hello

The MySQL and its libraries has been put under the GPL (not LGPL) a while ago
and since then conflicts with PHP etc which is not GPL compatible but still
DFSG compliant (or so I understood).

MySQL addressed this issue now by making yet another version of their FLOSS
Exception license public which should resolve all problems.

It does no longer contain a section that was found conflicting last time I
asked but just to be sure someone should take a look at it.
(E.g. I wasn't sure if a Debian CD-Set where source and binaries are not on
the same CD is still considered as same "Medium" etc...) and what exactly they
were trying to say in point "3."...

thanks,

-christian-

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=242449
http://dev.mysql.com/doc/mysql/en/Copyright.html
http://dev.mysql.com/doc/mysql/en/MySQL_licenses.html
http://www.mysql.com/products/licensing/foss-exception.html


pgpQ6LHh0QzxP.pgp
Description: PGP signature


Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Don Armstrong
On Mon, 09 Aug 2004, Freek Dijkstra wrote:
> Personally I fear the upstream maintainers are not willing to change
> their code for just this. After all, they already link with the
> technically excellent OpenSSL library, which is indeed open source.

This may be the case, but that shouldn't prevent you from making the
modification in the netatalk packages incorporated in Debian, ideally
in a method that allows the code to link with either gnutls or
OpenSSL. [Just because upstream won't (or can't) cooperate, doesn't
mean that Debian packages should languish...]


Don Armstrong

-- 
The beauty of the DRUNKENNESS subprogram was that you could move your
intoxication level up and down at will, instead of being caught on a
relentless down escalator to bargain basement philosophy and the
parking garage.
 -- Rudy von Bitter _Software_ p124

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



Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Glenn Maynard
On Mon, Aug 09, 2004 at 09:50:30PM +0200, Freek Dijkstra wrote:
> I understand the low risk thing. However, in this case, I'd say it's worth
> the lawsuit. Though I have supported FSF, in the particular case I'd hope
> they lose :-) (I'm sure Richard Stallman doesn't agree with me).

If they lose that lawsuit, then the virality of the GPL would be completely
undermined.  I'm not the GPL's biggest fan, but I don't want to see that
happen.

In any event, I agree with it in principle: if something is legitimately
restricted when statically linking, the idea that you can "get around" the
requirement simply by putting part of the code in another binary file and
linking it at runtime seems silly.

> However, that being said, I claim it does not apply to this particular
> scenario! In this case, I suggested to distributed a binary of netatalk,
> including the UAMS linked with OpenSSL under GPL. To see if this is allowed
> you have to look at the *OpenSSL-licence*, NOT at the *GPL*.

This is incorrect.  It is the GPL which is being violated, not the OpenSSL
license.  The OpenSSL license says "advertising materials are required to
contain this and that acknowledgement"[1].  The GPL says "you may not add
any requirements in derived works".  These requirements are mutually exclusive:
requiring the former is in violation of the latter.

> (You could for
> that matter have looked at the LGPL as well, which explicitly would have
> allowed dynamic linking).

The GPL and the LGPL have very different requirements; the LGPL was explicitly
intended to allow this case, where the GPL was explicitly intended to forbid
it.

[1] among other GPL-incompatible things

-- 
Glenn Maynard



Re: summaries bugs, was: Please pass judgement on X-Oz licence: free or nay?

2004-08-09 Thread MJ Ray

On 2004-08-09 18:26:19 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote:


[MJR] summary
guidelines suggest a link back to the DFSG for all problems in clauses
3-4. The list of reasons in Jeremy Hankin's guidelines need not 
connect

to the DFSG at all.


Either:
a. I was trying to con debian-legal into thinking that aspect was a 
purely editorial wording change; OR
b. I didn't think that was controversial at all or even remarkable any 
more.


;-)

--
MJR/slefMy Opinion Only and not of any group I know
http://www.ttllp.co.uk/ for creative copyleft computing
Please email about: BT alternative for line rental+DSL;
Education on SMEs+EU FP6; office filing that works fast



Re: Please pass judgement on X-Oz licence: free or nay?

2004-08-09 Thread MJ Ray

On 2004-08-09 18:07:24 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote:


I guess I'm also convinced that just because it's not numbered like it
is in the BSD license, doesn't make it not a clause.
[...] At no point is it obvious to me that "the
following conditions" is ending and being replaced by something else.


Oh well, there's our difference.

--
MJR/slefMy Opinion Only and not of any group I know



Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Andrew Suffield
On Mon, Aug 09, 2004 at 06:29:21PM +0200, Freek Dijkstra wrote:
> On 09-08-2004 17:14, "MJ Ray" <[EMAIL PROTECTED]> wrote:
> 
> >> Netatalk is absolutely NO derivate of openssl.
> > 
> >  From a quick inspection, I don't think that will be true for all of a
> > netatalk binary compiled with openssl-related parts enabled. I think
> > you realised this in your later message.
> 
> No. This is untrue. I just realised that Netatalk, just like most binary
> distributions are *dynamically* compiled. Not statically.

Yeah, old argument, short answer: it's wrong.

Your binary does not need to contain a copy of their binary in order
to be a derivative of it. Your binary is based upon their binary. That
is enough.

"Derivative work" here is a legal term. Your entirely arbitrary
definition is not what it means.

In colloquial English:

If you use their code, you have created a derivative work of their
code. All code used in a GPLed project must be available under the
terms of the GPL. That is the whole point of the GPL.

We can't say that in legal discussions because 'use' means something
else there (specifically, the act of running the code) - and damnit,
it's too imprecise.

Please don't jump up and down upon the greasy smear on the pavement
where this horse once stood. We've done this one *so* *many* *times*.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature


Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Freek Dijkstra
On 9-8-2004 18:58, "Matthew Garrett" <[EMAIL PROTECTED]>
wrote:

> Freek Dijkstra <[EMAIL PROTECTED]> wrote:
> 
>> So if indeed netatalk contains executable code from openssl, then according
>> to #2, the redistributed binary must have the openssl-licence, and that is
>> not allowed. However, just thinking about how dynamic libraries work, I
>> belief there is no executable code of the library being called involved,
>> even though the header files are used (since they only contain definitions,
>> but don't lead to executable code).
>> 
>> Could someone confirm or deny this?
> 
> The FSF disagree - their claim is that even with dynamic linking the
> libraries must be GPL compatible. Nobody has so far been willing to have
> a lawsuit over this, so it's not possible to confirm or deny this.
> Believing the FSF is safer than not doing so, so we take the low-risk
> approach.

I understand the low risk thing. However, in this case, I'd say it's worth
the lawsuit. Though I have supported FSF, in the particular case I'd hope
they lose :-) (I'm sure Richard Stallman doesn't agree with me).

For those interested, there was an discussion on this topic on
gnu-misc-discuss last month. Read this mail for interesting pointers:
http://lists.gnu.org/archive/html/gnu-misc-discuss/2004-07/msg00070.html
For example, the first pointer, page 16 of it on how Richard Stallman and
Eben Moglen (general counsel of FSF) disagree on what is "derivate works".


However, that being said, I claim it does not apply to this particular
scenario! In this case, I suggested to distributed a binary of netatalk,
including the UAMS linked with OpenSSL under GPL. To see if this is allowed
you have to look at the *OpenSSL-licence*, NOT at the *GPL*. (You could for
that matter have looked at the LGPL as well, which explicitly would have
allowed dynamic linking).

Well *I* do not see anything in the OpenSSL licence which specifically
forbid dynamic linking against it. So I think it is allowed. (If you like, I
am more then willing to contact the OpenSSL on this matter).

Would you agree that if the OpenSSL licence doesn't forbid this, then it is
OK for netatalk to link against OpenSSL?

Or do I still miss something?

Regards,
Freek Dijkstra




Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Matthew Garrett
Freek Dijkstra <[EMAIL PROTECTED]> wrote:

> So if indeed netatalk contains executable code from openssl, then according
> to #2, the redistributed binary must have the openssl-licence, and that is
> not allowed. However, just thinking about how dynamic libraries work, I
> belief there is no executable code of the library being called involved,
> even though the header files are used (since they only contain definitions,
> but don't lead to executable code).
> 
> Could someone confirm or deny this?

The FSF disagree - their claim is that even with dynamic linking the
libraries must be GPL compatible. Nobody has so far been willing to have
a lawsuit over this, so it's not possible to confirm or deny this.
Believing the FSF is safer than not doing so, so we take the low-risk
approach.

-- 
Matthew Garrett | [EMAIL PROTECTED]



Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Matthew Garrett
Freek Dijkstra <[EMAIL PROTECTED]> wrote:

> Netatalk CAN be linked against openssl, to provide password encryption.
> The current package in sarge (testing) is not linked against OpenSSL, so all
> passwords are sent in clear text over the line.

Right. Which, arguably, makes a small part of netatalk a derivative work
of openssl. And since netatalk is a derivative work of other people's
GPLed code, this results in license issues.

Of course, nobody is actually going to sue over this.

> Does this, in any way, according to you, change if netatalk, linked against
> OpenSSL is allowed to be distributed?
> I am aware of the statment made at
> http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
> stating, that, in some cases, you can just distribute the packages without
> making an exception to the GPL (which the provider is willing, but unable to
> make).

Yes. That only applies if the component does not accompany the
executable. Debian's position is that everything inside Debian
accompanies everything else, so the exemption in the GPL is not
applicable to anything we distribute.

> However, I do not entirally understand what is being said there. I (and the
> current package maintainer) completely really on that "someone on
> debian-legel" says that "GPL software linked against OpenSSL is not allowed
> in the main archive without either a license exemption from the upstream
> author of the GPL package"
> source: http://lists.debian.org/debian-legal/2002/10/msg00173.html

GPLed software linked against OpenSSL is not legal to distribute, in
main or elsewhere. There is an argument that it would be illegal to
distribute the source as well. I find this line of argument unlikely,
but the FSF occasionally appear to use it. 

-- 
Matthew Garrett | [EMAIL PROTECTED]



Re: summaries bugs, was: Please pass judgement on X-Oz licence: free or nay?

2004-08-09 Thread Joe Wreschnig
On Mon, 2004-08-09 at 03:45, MJ Ray wrote:
> On 2004-08-09 06:17:17 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote:
> 
> > Since February, -legal has had an "official" (as official as they get)
> > document claiming that even without further annoyances from X-Oz that
> > clause is non-free. Simon Law, who wrote that summary, has since
> > realized it was a huge mistake. That means something is wrong in the 
> > way
> > we approach license analysis and summary writing.
> 
> I agree that something is wrong. Most recently, I mentioned and made 
> suggestions about this in 
> http://lists.debian.org/debian-legal/2004/07/thrd3.html#00334
> http://lists.debian.org/debian-legal/2004/07/msg00334.html and part of 
> another subthread around 
> http://lists.debian.org/debian-legal/2004/07/msg00219.html
> 
> Sadly, I commit the same sin of poor referencing that I percieve as a 
> problem with the summaries. I think the "unpleasantness" was mostly 
> about the handling of the MPL threads that month and the month before.
> 
> My suggestion wasn't clearly liked, but I feel there wasn't much 
> participation. It seems that I don't have time to get discussion on 
> this. You seem to care about fixing summaries too: please can you take 
> it forwards?

I have been going over that thread and thinking about it, but will
probably need a few more days before I can come to any conclusions
worthy of posting.

One thing I find interesting, that you didn't mention in your changes
(but you changed) and no one commented on is that your summary
guidelines suggest a link back to the DFSG for all problems in clauses
3-4. The list of reasons in Jeremy Hankin's guidelines need not connect
to the DFSG at all.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part


Re: Please pass judgement on X-Oz licence: free or nay?

2004-08-09 Thread Joe Wreschnig
On Mon, 2004-08-09 at 11:02, Brian Thomas Sniffen wrote:
> Joe Wreschnig <[EMAIL PROTECTED]> writes:
> 
> > On Mon, 2004-08-09 at 03:31, MJ Ray wrote:
> >> On 2004-08-09 05:35:10 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote:
> >> 
> >> > Clause 4 -- which you declared non-free in that thread *before* public
> >> > conversations with X-Oz, and Brian declared non-free at the start of
> 
> > The 3rd clause of the 3 clause BSD license. I made a case elsewhere that
> > the X wording is actually less restrictive because it only affects the
> > original software, where the BSD clause affects all derived software.
> 
> In that case, do you think the issue can be made to go away by making
> a trivial change to the software?

I don't yet admit that the paragraph in question is an "issue".
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part


Re: Please pass judgement on X-Oz licence: free or nay?

2004-08-09 Thread Joe Wreschnig
On Mon, 2004-08-09 at 04:59, MJ Ray wrote:
> On 2004-08-09 10:38:45 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote:
> 
> > I don't see the difference. I mean, I see the difference that one can 
> > be
> > read as an "assertion" and the other can be read as a "clause". But I
> > don't see how that affects any practical or legal conclusions. In 
> > other
> > words, if I write a license like the BSD one, but append "You will 
> > wear
> > a hat on Fridays." I think it will be clear to everyone, including a
> > judge, that I intend that to be a requirement to use the freedoms set
> > forth in the license, even though it's just an "assertion" rather 
> > than a
> > "clause".
> 
> That's not the impression I have, especially given the "clarification" 
> posts from X-Oz. Does someone know the legal reasoning of this? Would 
> the same hold if you appended "You may not wear a hat on Fridays" 
> which I think is closer to the BSD wording?

The entire X license is written in an assertoric rather than imperative
manner. All conditions are phrased with "X shall Y" or "X is Y" rather
than "You shall do X".

A study of differing legal interpretations between assertoric statements
and imperative clauses in licenses may be interesting. I also think it's
enough hair-splitting that we shouldn't bother with it.

I guess I'm also convinced that just because it's not numbered like it
is in the BSD license, doesn't make it not a clause. That is, the X
license says "Permission is hereby granted... subject to the following
conditions:" and then goes on to lay out the requirement that the
copyright notice be preserved; then the warranty disclaimer; then the
paragraph in question. At no point is it obvious to me that "the
following conditions" is ending and being replaced by something else.

> MJ Ray wrote:
> >> No-one found a licence with a similar *condition* in it.
> > The 3rd clause of the 3 clause BSD license.
> 
> That says "may not be used to endorse or promote products derived from 
> this software" while the X-Oz one says "shall not be used in 
> advertising or otherwise to promote the sale, use or other dealings in 
> this Software". There's the difference in verb, which I think is 
> substantial, and I think X-Oz has added sufficient lawyerbombs to make 
> me a lot more uncomfortable with it than the 3 clause BSD one.
> 
> I suspect we also have more postitive clarifications about the BSD 
> one. It is possible we will get a bizarre interpretation from a 
> particular licensor, but we'll deal with that when it happens.

Since I don't buy that it's not actually a clause, the whole of XFree86
licensing stands up as positive clarification of a free interpretation
of this.

> > I made a case elsewhere that
> > the X wording is actually less restrictive because it only affects the
> > original software, where the BSD clause affects all derived software.
> 
> Do both affect derived software, because we need copyright permission 
> for the original in order to use the derived, which would otherwise 
> infringe copyright of the original?

They both affect derived software in the sense that they place some
conditions you, which you must meet to derive from the software.
However, those conditions only apply to The Software in the X license;
they only apply to derived software in the BSD license.

Personally I think this is extreme hair splitting; I was using it as an
example of why I think it's silly to claim the BSD license is free and
this one isn't.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part


Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Freek Dijkstra
On 09-08-2004 18:25, "Brian Thomas Sniffen" <[EMAIL PROTECTED]> wrote:

>> It is sad that despite all copyright holders are more then willing to
>> co-operate, there still is something holding them back.
> 
> Yes -- the rest of the copyright holders.  Bug the Samba/libiconv
> folks if you like, but I suggest you blame Eric Young.  He could make
> this issue go away by behaving in a less unmutual manner.

OK, agreed. I was too quick in drawing conclussions on that one.

It is an issue with licences though. In time you just don't know anymore
who wrote what piece, and you can't fix issues in licencing. I know have
to congratulate the GPL folks who encourage the "or any later version"
practice. But let's not discuss that here.

Freek




Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Freek Dijkstra
On 09-08-2004 17:14, "MJ Ray" <[EMAIL PROTECTED]> wrote:

>> Netatalk is absolutely NO derivate of openssl.
> 
>  From a quick inspection, I don't think that will be true for all of a
> netatalk binary compiled with openssl-related parts enabled. I think
> you realised this in your later message.

No. This is untrue. I just realised that Netatalk, just like most binary
distributions are *dynamically* compiled. Not statically.

For example, all the password encryption-related parts (which link against
openssl) do end up in so-called UAMS (authentication modules). For example,
the one I talked about it /usr/lib/netatalk/uams_dhx_pam.so

I did compile it manually and found:
netatalk-2.0-beta1# ldd /usr/local/lib/netatalk/uams_dhx_passwd.so
libcrypto.so.0.9.6 => /usr/lib/i686/cmov/libcrypto.so.0.9.6
(0x4000f000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x400d)
libnsl.so.1 => /lib/libnsl.so.1 (0x400fe000)
libdl.so.2 => /lib/libdl.so.2 (0x40113000)
libc.so.6 => /lib/libc.so.6 (0x40116000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)

As you can see it indeed is DYNAMICALLY linked. Which means that no part of
the openssl binary code is included. I did try to verify that.

# cd source/netatalk-2.0-beta1
# grep -rsi libssl *
Only matches a few readme files
# grep -rsi libcrypto *
Matches config and some binary files.

I have the impression that no binary output file includes code which is
either (1) compiled from openssl sources or (2) include libssl.a or
libcrypto.a

I will verify this this evening.

If it is not the case, then the only thing that is included are the *header*
files in /usr/include/openssl.

However, header files result in no code (that's why they're header files)
and are neither included in the distribution.


Clearly uams_dhx_pam.so & co do include executable code which is compiled
from GPL-covered source code.

Technically, the issue boils down to this part of the OpenSSL licence:

( http://www.openssl.org/source/license.html )
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. All advertising materials mentioning features or use of this
 *software must display the following acknowledgment:
 *"This product includes software developed by the OpenSSL Project
 *for use in the OpenSSL Toolkit. (http://www.openssl.org/)"

The third point, the inclusion of the line, is incompatible with the GPL.
As such, just including the line is no incompability. That's fine. The
issue is that according to #1 or #2, redistributions must contain this
licence as well, and thus place restriction #3 on further derivate works.
This is not allowed, since it also places an added restriction on
GPL-derivate code.


So if indeed netatalk contains executable code from openssl, then according
to #2, the redistributed binary must have the openssl-licence, and that is
not allowed. However, just thinking about how dynamic libraries work, I
belief there is no executable code of the library being called involved,
even though the header files are used (since they only contain definitions,
but don't lead to executable code).

Could someone confirm or deny this?

In the mean time, I'll check this assertion by examining the header files,
compiling them, and by forcefully removeing libssl.a and libcrypto.a from
/usr/lib before compiling netatalk.

Kind regards,
Freek Dijkstra




Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Brian Thomas Sniffen
Freek Dijkstra <[EMAIL PROTECTED]> writes:

> OpenSSL does give that permission:
> http://www.openssl.org/support/faq.html#LEGAL2 (last paragraph of
> answer)

The OpenSSL license requires an ad for Eric Young on all software
using it.  The GPL conflicts with that requirement.

> Netatalk is willing to give it, but can not:
> It is practically unrealistic to ask every possible contributor (including
> samba and libiconv contributors) to make this exception to the GPL licence.
> http://sourceforge.net/tracker/index.php?func=detail&aid=890674&group_id=864
> 2&atid=358642

Well, then what you're really saying is that the Samba and Libiconv
folks have offered their software under the GPL, and won't give
permission for the OpenSSL exception.  So this isn't just a failing of
licenses; it's a legitimate disagreement between some copyright holders.

> It is sad that despite all copyright holders are more then willing to
> co-operate, there still is something holding them back.

Yes -- the rest of the copyright holders.  Bug the Samba/libiconv
folks if you like, but I suggest you blame Eric Young.  He could make
this issue go away by behaving in a less unmutual manner.

-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]



Re: Web application licenses

2004-08-09 Thread Brian Thomas Sniffen
Josh Triplett <[EMAIL PROTECTED]> writes:


> And obtaining GNU Emacs does not entitle you to run it on a gnu.org
> machine.  Why should this be any different?  You have control over your
> own boxes and what runs on them.  I have the same control over mine.  If
> you make software available, I can run it on my boxes, but not on yours
> unless you permit it.  This would still give me Freedom over the
> software I'm using; what you suggest would infringe _your_ Freedom to
> decide what software you run on your own hardware.

Some software, like Emacs or gcc, is mostly local.  Some software,
like traffic-signal control software, or homeland-security massive
database software, is useful only where it is; it is inherently
remote.  I have no interest in running my own Giant Database
Aggregator of Doom.  I just want to make sure *theirs* works right,
and doesn't compromise the privacy of citizens.



>>>* Allowing a user to log into your box and run the software.
>> 
>> So if I want to have a dialup server, it must include the source for
>> all its 
>
> This sentence seems incomplete.

Yes.  It should say something about all the dialup's software, or
maybe just software I've modified.

> Yes, you would have to provide source for the programs users may run on
> your server, if those programs are covered by this license, or are based
> on such software.  However, that can probably be handled for 99% of the
> software on that server by saying "Get it from *.debian.org".

No, I routinely modify all software I install and give those
modifications to others.  Those are both freedoms Debian wants to
guarantee, so a license can't be free if it restricts me from doing
them in any quantity.

For example, look at the response to the stoplight provision here:

> You really _should_ be able to get the source to everything you interact
> with that is under this license.  On the other hand, that is a good
> example of how the requirement might be difficult to meet.  Then again,
> the DoT can always choose not to derive their software from software
> under this license.

You're suggesting that some people might want to avoid modifying free
software and using it, because they don't want to bear the burden that
this would have.  That just doesn't sound like free software to me.

>> No, but if I don't have those things then I can't use the software
>> anyway.  
>
> My point is, you are asking for too much control over how the other
> party uses their hardware.  You should certainly have the right to use
> it on your own hardware; that would be more freedom than you have now,
> and certainly enough to consider it Free Software.  I'm sure that there
> is plenty of software in Debian main that neither of us could take
> advantage of for whatever reason.  That does not make the software any
> less Free.

True, but your argument for why they should have to give me copies of
their software is that to do so enhances my freedom.  I don't
understand why that argument applies to software and not hardware.  If
I implement an Emacs Machine, which provides Emacs but only in
hard-wired circuits, but in such a way that it's a derivative of a
work under this license, is it free to require me to give you one?  To
give you the plans?

Why is the answer different for software?

-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]



Re: Please pass judgement on X-Oz licence: free or nay?

2004-08-09 Thread Brian Thomas Sniffen
Joe Wreschnig <[EMAIL PROTECTED]> writes:

> On Mon, 2004-08-09 at 03:31, MJ Ray wrote:
>> On 2004-08-09 05:35:10 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote:
>> 
>> > Clause 4 -- which you declared non-free in that thread *before* public
>> > conversations with X-Oz, and Brian declared non-free at the start of

> The 3rd clause of the 3 clause BSD license. I made a case elsewhere that
> the X wording is actually less restrictive because it only affects the
> original software, where the BSD clause affects all derived software.

In that case, do you think the issue can be made to go away by making
a trivial change to the software?

-Brian

-- 
Brian Sniffen   [EMAIL PROTECTED]



Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Freek Dijkstra
On 09-08-2004 14:33, "Matthew Garrett" <[EMAIL PROTECTED]>
wrote:

> Nope. The same argument actually applies - if netatalk is a derivative
> of openssl (and if it's been coded against it, then the FSF would
> probably claim that it is) then it's illegal to distribute it in any
> form under the current license.

Netatalk is absolutely NO derivate of openssl.

It is a standalone package which (mainly) provides Apple Filesharing
Protocol (AFP) support. It is very simular in functionality to Samba, if
you're familiar with that.

Netatalk CAN be linked against openssl, to provide password encryption.
The current package in sarge (testing) is not linked against OpenSSL, so all
passwords are sent in clear text over the line.

Does this, in any way, according to you, change if netatalk, linked against
OpenSSL is allowed to be distributed?
I am aware of the statment made at
http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
stating, that, in some cases, you can just distribute the packages without
making an exception to the GPL (which the provider is willing, but unable to
make).

However, I do not entirally understand what is being said there. I (and the
current package maintainer) completely really on that "someone on
debian-legel" says that "GPL software linked against OpenSSL is not allowed
in the main archive without either a license exemption from the upstream
author of the GPL package"
source: http://lists.debian.org/debian-legal/2002/10/msg00173.html

If this statement is incorrect, given the statement in the GPL-FAQ, please
let me know immediately!

Kind regards,
Freek Dijkstra

-- 
Never ask a man what kind of computer he owns. If it's a Mac, he'll tell
you. If not, why embarrass him?




Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Matthew Garrett
Freek Dijkstra <[EMAIL PROTECTED]> wrote:

> Personally I fear the upstream maintainers are not willing to change their
> code for just this. After all, they already link with the technically
> excellent OpenSSL library, which is indeed open source.

If you're lucky, no code changes would be needed.

> I take it that it is not possible to put a source-only (no-binary)
> distribution) in the main section of Debian?

Nope. The same argument actually applies - if netatalk is a derivative
of openssl (and if it's been coded against it, then the FSF would
probably claim that it is) then it's illegal to distribute it in any
form under the current license.

The whole argument over whether linking against a library makes a
derived work has never (as far as I'm aware) been tested in court. It's
probably the weakest part of the GPL.

-- 
Matthew Garrett | [EMAIL PROTECTED]



Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Matthew Garrett
Freek Dijkstra <[EMAIL PROTECTED]> wrote:

> 1. Has anything changed in the statement made to debian-legal in 2002?

It's still the case that the openssl license is considered incompatible
with the GPL.

> 2. Is the netatalk upstream author correct that he cannot reasonably make
>the exception (without asking all possible contributors)

Yup. You can't change the license something is under without the
permission of the copyright holder, and adding an exception for openssl
is changing the license.

> 3. Is there any way of getting netatalk with encrypted passwords in sarge?
>I can think of source-only distributions, or asking to move it out of
>main. However, I do not fully understand the implications of this. So:
>what would be a possible next move? Maybe just put it in Sarge, and ask
>FSF to sue you to create legal precedent? :-)

GnuTLS has a openssl compatibility module. It's not complete, but it's
sufficient for some openssl code. GnuTLS is under the GPL, so there's no
problem with linking GPLed stuff against it. It's possible that you
could just link netatalk with that. Alternatively, the SSL code in
netatalk could be rewritten to use GnuTLS directly.

-- 
Matthew Garrett | [EMAIL PROTECTED]



Re: periodic summaries, was: RPSL and DFSG ...

2004-08-09 Thread David Nusinow
On Mon, Aug 09, 2004 at 04:36:31AM +0100, MJ Ray wrote:
> On 2004-08-09 03:10:06 +0100 Walter Landry <[EMAIL PROTECTED]> wrote:
> 
> >I'm not so sure that it should go to d-d-a.  For one time deals, where
> >a legal analysis affects a lot of packages, sure.  But not for a
> >weekly synopsis.  That is more like a mailing list of its own (like
> >kernel-traffic).
> 
> Then, unless the world shouts you down, for now I'll put it to d-l and 
> then my free software news blog (also on planet.debian.net) and rely 
> on subject line consistency to help people find them. If it seems to 
> work, I'll look for a better home next month.

Both of those are great choices. Thank you very much for doing this.

 - David Nusinow



Re: Suggestions of David Nusinow, was: RPSL and DFSG-compliance - choice of venue

2004-08-09 Thread David Nusinow
On Sun, Aug 08, 2004 at 07:07:11PM -0500, Branden Robinson wrote:
> Apart from Raul Miller's[1], I have yet to read a rebutal to Manoj's draft
> position statement on the GNU FDL[2].
> 
> If you would direct me to one which represents "the will of the project as
> a whole", I'd appreciate it.
> 
> Given that Raul himself, after a thread that went several directions, said
> "I'm not trying to convince people that the GFDL as it currently stands
> should be considered DFSG free.  I'm ambivalent about that."[3], we seem to
> be rather short on comprehensive and well-reasoned defenses of the
> DFSG-freeness of the GNU FDL.  Maybe you can help.

Actually, I agree with the GNU FDL position, and I even submitted a draft
version of a small portion of it to Manoj while he was in the writing phase of
it. :-)

 - David Nusinow



Re: Netatalk and OpenSSL licencing

2004-08-09 Thread MJ Ray
On 2004-08-09 13:55:01 +0100 Freek Dijkstra 
<[EMAIL PROTECTED]> wrote:



Netatalk is absolutely NO derivate of openssl.


From a quick inspection, I don't think that will be true for all of a 
netatalk binary compiled with openssl-related parts enabled. I think 
you realised this in your later message.



http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs [...]
However, I do not entirally understand what is being said there.


I don't think OpenSSL is *normally* distributed with the major 
components of the debian operating system, so that doesn't apply. It 
is only a standard priority package in the utils section, not a 
required or even important priority. Sorry.


A couple of bits from the other subthread:

http://www.openssl.org/support/faq.html#LEGAL2 OpenSSL doesn't give 
that permission - they just claim it's not needed for any major 
distribution. I assume we're not major in their eyes then. :-/



It is sad that despite all copyright holders are more then willing to
co-operate, there still is something holding them back.

Please attribute the fault to whoever you like, but not the copyright
holders.


You wrote that it's impractical to contact all copyright holders, so 
how can you make this conclusion safely about all of them? You seem to 
be exaggerating, so I think I'm right to doubt your "NO derivative 
work" conclusion: is that a similar exaggeration?


I don't think there's much point in attributing "fault" for this 
situation anyway. It still won't get the permission.


--
MJR/slefMy Opinion Only and not of any group I know
http://www.ttllp.co.uk/ for creative copyleft computing
Please email about: BT alternative for line rental+DSL;
Education on SMEs+EU FP6; office filing that works fast



Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Freek Dijkstra
> On 2004-08-09 13:35:30 +0100 Freek Dijkstra wrote:
> 
>> As an end-user, it's far easier to just compile it all myself
>> [...] then to change the code of netatalk to have it link to
>> gnutls.
> 
> Fine. If you choose not to help others, that's your choice. I don't
> like it.

I could have just compiled all myself, and stopped there. That solved my
problem. I instead choose to spent some time and change it for those who
only use packages and do not have the time to find the problem and compile
software on their own.

My apologies if I sound blunt because I did not commit myself to making
changes I do not see the need for. I may do it after all, now that Matthew
suggested that it doesn't require much changes, but I personally belief
OpenSSL is just fine.


To keep on-topic:
Netatalk is no derivate work. However, it is not clear if the compiled
program, which is linked with but the compiled program is.

Technically, for DHX (password encryption support), netatalk does compile
against openssl by linking against the header files found in
/usr/include/openssl (it adds -I/usr/include/openssl to CFLAGS)

Aparently, in simular cases (with Courier in the 2002 thread), this was
taken as incompatible with this note on the GNU FAQ:

  However, as a special exception, the source code distributed need not
  include anything that is normally distributed (in either source or
  binary form) with the major components (compiler, kernel, and so on)
  of the operating system on which the executable runs, unless that
  component itself accompanies the executable.

I was, and still am surprised (and yes, also disappointed) by this.


> We want copyright permission from the copyright holders for this act
> not covered by their licences in combination. Either openssl or
> netatalk could give an exception. They haven't give it, for whatever
> reasons. Regardless of what we think of their reasons, we don't have
> permission...

OpenSSL does give that permission:
http://www.openssl.org/support/faq.html#LEGAL2 (last paragraph of answer)

Netatalk is willing to give it, but can not:
It is practically unrealistic to ask every possible contributor (including
samba and libiconv contributors) to make this exception to the GPL licence.
http://sourceforge.net/tracker/index.php?func=detail&aid=890674&group_id=864
2&atid=358642

It is sad that despite all copyright holders are more then willing to
co-operate, there still is something holding them back.

Please attribute the fault to whoever you like, but not the copyright
holders.


> If you want to argue that copyleft is wrong for software,
> this is not the list for that and I'm not sure what is. Maybe ox-en or
> gnu-misc, but maybe not.

As for suggestion that GPL is wrong. Well, that it too harsh, but you are
right. I should take this part of the discussion to gnu-misc. For the
record, I don't think copyleft is wrong. On the contrary.

However, I DO argue that licences which limit people in using (other) open
source software are not optimal. If that is indeed what GPL does, I dislike
it, and prefer other (better?) licences, like maybe BSD or Apache (APSL).

Sorry if I sound too pessimistic here.

Regards,
Freek Dijkstra




Re: Netatalk and OpenSSL licencing

2004-08-09 Thread MJ Ray
On 2004-08-09 13:35:30 +0100 Freek Dijkstra 
<[EMAIL PROTECTED]> wrote:


As an end-user, it's far easier to just compile it all myself (which 
is of
course perfectly fine, and allowed according to both the GPL and the 
openssl
licence) then to change the code of netatalk to have it link to 
gnutls.


Fine. If you choose not to help others, that's your choice. I don't 
like it.


PS: to play the devils advocate on this list: is this [EMAIL PROTECTED]&$(%$ 
really

necessary for me as an end-user to get open-source software to work?

Sadly, yes, someone has to do this, until laws change. [...]

I don't think laws have anything to do with it.


Copyright law means we need permission for acts which would otherwise 
infringe copyright. If there was no legal support for copyright, you 
could distribute compiled GPL'd OpenSSL-using works without legal 
trouble.



The issue at case (im my naive opinion) is that GPL is so strict [...]


GPL is a copyleft, which means that it somehow requires derived works 
to be under the same licence, which is stronger than DFSG 3. OpenSSL's 
licence contains something that prevents derived works being covered 
by the GPL. If you want to argue that copyleft is wrong for software, 
this is not the list for that and I'm not sure what is. Maybe ox-en or 
gnu-misc, but maybe not.


If this is not the issue, please have someone explain me what does 
prevent

netatalk from linking with openssl and distributing it in Debian.


We want copyright permission from the copyright holders for this act 
not covered by their licences in combination. Either openssl or 
netatalk could give an exception. They haven't give it, for whatever 
reasons. Regardless of what we think of their reasons, we don't have 
permission...


--
MJR/slefMy Opinion Only and not of any group I know
http://www.ttllp.co.uk/ for creative copyleft computing
Please email about: BT alternative for line rental+DSL;
Education on SMEs+EU FP6; office filing that works fast



Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Freek Dijkstra
On 09-08-2004 14:33, "Matthew Garrett" <[EMAIL PROTECTED]>
wrote:

> Nope. The same argument actually applies - if netatalk is a derivative
> of openssl (and if it's been coded against it, then the FSF would
> probably claim that it is) then it's illegal to distribute it in any
> form under the current license.

Netatalk is absolutely NO derivate of openssl.

It is a standalone package which (mainly) provides Apple Filesharing
Protocol (AFP) support. It is very simular in functionality to Samba, if
you're familiar with that.

Netatalk CAN be linked against openssl, to provide password encryption.
The current package in sarge (testing) is not linked against OpenSSL, so all
passwords are sent in clear text over the line.

Does this, in any way, according to you, change if netatalk, linked against
OpenSSL is allowed to be distributed?
I am aware of the statment made at
http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
stating, that, in some cases, you can just distribute the packages without
making an exception to the GPL (which the provider is willing, but unable to
make).

However, I do not entirally understand what is being said there. I (and the
current package maintainer) completely really on that "someone on
debian-legel" says that "GPL software linked against OpenSSL is not allowed
in the main archive without either a license exemption from the upstream
author of the GPL package"
source: http://lists.debian.org/debian-legal/2002/10/msg00173.html

If this statement is incorrect, given the statement in the GPL-FAQ, please
let me know immediately!

Kind regards,
Freek Dijkstra




Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Freek Dijkstra
On 09-08-2004 14:18, "MJ Ray" <[EMAIL PROTECTED]> wrote:

> I don't know. I would probably look at porting to gnutls if no-one has
> tried that yet.

Yes, I've seen the suggestion before. It seems like a non-option to me.
As an end-user, it's far easier to just compile it all myself (which is of
course perfectly fine, and allowed according to both the GPL and the openssl
licence) then to change the code of netatalk to have it link to gnutls.

>> PS: to play the devils advocate on this list: is this [EMAIL PROTECTED]&$(%$ 
>> really
>> necessary for me as an end-user to get open-source software to work?
> 
> Sadly, yes, someone has to do this, until laws change. [...]

I don't think laws have anything to do with it.

The issue at case (im my naive opinion) is that GPL is so strict that I am
not allowed to distribute a program which is *partily* GPL, partialy other
open source software. Even not if I *do* distribute the source code with it.

If this is not the issue, please have someone explain me what does prevent
netatalk from linking with openssl and distributing it in Debian.

>> All lawyers on this list: please find an other job. ;-)
> 
> That would actually be unhelpful, assuming we have more helpful
> lawyers than evil spy lawyers on this list. I'm glad you labelled that
> as a rant.

LOL. Next time, I'll change my rant to "all lawyer, not on this list, find
another job" :-)

Regards, and thanks for the prompt feedback!
Freek





Re: Netatalk and OpenSSL licencing

2004-08-09 Thread MJ Ray
On 2004-08-09 12:36:46 +0100 Freek Dijkstra 
<[EMAIL PROTECTED]> wrote:


2. Is the netatalk upstream author correct that he cannot reasonably 
make

   the exception (without asking all possible contributors)


I think so.

3. Is there any way of getting netatalk with encrypted passwords in 
sarge?


I don't know. I would probably look at porting to gnutls if no-one has 
tried that yet.


   I can think of source-only distributions, or asking to move it out 
of

   main. However, I do not fully understand the implications of this.


IIRC, this licence conflict makes it non-distributable, so "move it 
out of main" wouldn't allow you to compile against OpenSSL.



PS: to play the devils advocate on this list: is this [EMAIL PROTECTED]&$(%$ 
really
necessary for me as an end-user to get open-source software to work? 
I'd


Sadly, yes, someone has to do this, until laws change. If the 
developers haven't done it and it's important to you, you need to 
cause some development on this...


Copyright won't necessarily ignore you (or us) just because you ignore 
copyright. That is the fault of your lawmakers, at least partly. 
Debian aims to be universal, so can't really rely on the few blanket 
copyright permissions for certain kinds of use.


rather had spend all this time doing something *useful*. All lawyers 
on this

list: please find an other job. ;-)


That would actually be unhelpful, assuming we have more helpful 
lawyers than evil spy lawyers on this list. I'm glad you labelled that 
as a rant.


--
MJR/slefMy Opinion Only and not of any group I know
http://www.ttllp.co.uk/ for creative copyleft computing
Please email about: BT alternative for line rental+DSL;
Education on SMEs+EU FP6; office filing that works fast



Re: Suggestions of David Nusinow, was: RPSL and DFSG-compliance - choice of venue

2004-08-09 Thread Nico Golde
Hello Brian,

* Brian Nelson <[EMAIL PROTECTED]> [2004-08-09 12:58]:
> It can be really tough to test NM's who are not native English speakers
> about licensing issues.  Legal text is very different from colloquial
> English, and non-native speakers are often completely overwhelmed.
> Hell, even native speakers have difficulty understanding licenses like
> the graphviz license.

oh thats what i like to say too. read my emails :)
regards nico
-- 
Nico Golde - [EMAIL PROTECTED]
[EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de
GPG: FF46 E565 5CC1 E2E5 3F69  C739 1D87 E549 7364 7CFF
Is there life after /sbin/halt -p?


signature.asc
Description: Digital signature


Re: Netatalk and OpenSSL licencing

2004-08-09 Thread Freek Dijkstra
On 09-08-2004 13:49, "Matthew Garrett" <[EMAIL PROTECTED]>
wrote:

> GnuTLS has a openssl compatibility module.

Thanks!

Personally I fear the upstream maintainers are not willing to change their
code for just this. After all, they already link with the technically
excellent OpenSSL library, which is indeed open source.

I take it that it is not possible to put a source-only (no-binary)
distribution) in the main section of Debian?

Regards,
Freek Dijkstra

[Who is trying very hard to refrain myself from make *very* saracastic
remarks about lawyers who make incompatible "open source" licences,
forcing people to write two functionally completely equal software
libraries. What was it again about "open source" and "duplicating efforts"
again? One more think, and I'll be back to good old proprietory software...]




Netatalk and OpenSSL licencing

2004-08-09 Thread Freek Dijkstra
Hi,

I'm asking for advice.

The best explanation can be found at this feature request on SourceForge:
http://sourceforge.net/tracker/index.php?func=detail&aid=890674&;
group_id=8642&atid=358642

  This is licence related. I'm using Debian, and prefer to grab
  netatalk using the appropriate package [1]. However, this
  package is not allowed to link to OpenSSL (and thus DHX
  passwords are disabled) [2]. The reason comes from debian-
  legal (don't ask *me*, I'm an ignorant user): "GPL software
  linked against OpenSSL is not allowed in the main archive
  without either a license exemption from the upstream author
  of the GPL package, a change in the license of OpenSSL
  itself, or a clear legal precedent sustaining the OpenSSL
  FAQ's opinion on this point." [3]

  In short, the OpenSSL and GPL are incompatible (as was
  noted on this list in 2001), so you may link it yourself, but
  may not distribute it because the GPL forbids it, despite that
  both licences are considered "free". (Well, at least that's
  what people on debian-legal claim).

  Thankfully, both the OpenSSL FAQ [4] and the GPL FAQ [5]
  give a solution: Add an exception to the licence, stating that
  it really is OK with you to compile the whole bunch, link with
  OpenSSL and put it in a package.

  So, my question. Could you pretty please add the following
  statement in one of your legal-blahblah files for both the 1.6
  and 2.0 version? I just copied it from gnu.org [5]:

  "In addition, as a special exception, the netatalk developers
  give permission to link the code of this program with the
  OpenSSL library (or with modified versions of OpenSSL that
  use the same license as OpenSSL), and distribute linked
  combinations including the two. You must obey the GNU
  General Public License in all respects for all of the code used
  other than OpenSSL. If you modify this file, you may extend
  this exception to your version of the file, but you are not
  obligated to do so. If you do not wish to do so, delete this
  exception statement from your version."

  [1] http://packages.debian.org/netatalk
  [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=191790
  [3] http://lists.debian.org/debian-legal/2002/debian-legal
  -200210/msg00173.html
  [4] http://www.openssl.org/support/faq.html#LEGAL2 (last
  paragraph of answer)
  [5] http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

  Thanks a LOT!
  And sorry to have distracted you from serious coding with
  this silly feature!

I have since bother the maintainer of netatalk debina package and the
upstream maintainers. The latter are perfectly happy to make the exception
to the licence, but can not:

  We have discussed this internally, and I fear it is not
  possible to make that change.

  Netatalk (at least 2.0) includes some GPL'ed code from other
  projects, mostly libiconv and Samba. Distributing Netatalk
  under a different license than the original GPL is AFAIKT
  (IANAL) therefore impossible without getting the permissions
  from the original authors and possibly all other contributors.

So: my questions:

1. Has anything changed in the statement made to debian-legal in 2002?
2. Is the netatalk upstream author correct that he cannot reasonably make
   the exception (without asking all possible contributors)
3. Is there any way of getting netatalk with encrypted passwords in sarge?
   I can think of source-only distributions, or asking to move it out of
   main. However, I do not fully understand the implications of this. So:
   what would be a possible next move? Maybe just put it in Sarge, and ask
   FSF to sue you to create legal precedent? :-)

Kind regards,
Freek Dijkstra

[rant mode on]
PS: to play the devils advocate on this list: is this [EMAIL PROTECTED]&$(%$ 
really
necessary for me as an end-user to get open-source software to work? I'd
rather had spend all this time doing something *useful*. All lawyers on this
list: please find an other job. ;-)
[rant mode off]




Re: Please pass judgement on X-Oz licence: free or nay?

2004-08-09 Thread MJ Ray

On 2004-08-09 10:38:45 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote:

I don't see the difference. I mean, I see the difference that one can 
be

read as an "assertion" and the other can be read as a "clause". But I
don't see how that affects any practical or legal conclusions. In 
other
words, if I write a license like the BSD one, but append "You will 
wear

a hat on Fridays." I think it will be clear to everyone, including a
judge, that I intend that to be a requirement to use the freedoms set
forth in the license, even though it's just an "assertion" rather 
than a

"clause".


That's not the impression I have, especially given the "clarification" 
posts from X-Oz. Does someone know the legal reasoning of this? Would 
the same hold if you appended "You may not wear a hat on Fridays" 
which I think is closer to the BSD wording?


MJ Ray wrote:

No-one found a licence with a similar *condition* in it.

The 3rd clause of the 3 clause BSD license.


That says "may not be used to endorse or promote products derived from 
this software" while the X-Oz one says "shall not be used in 
advertising or otherwise to promote the sale, use or other dealings in 
this Software". There's the difference in verb, which I think is 
substantial, and I think X-Oz has added sufficient lawyerbombs to make 
me a lot more uncomfortable with it than the 3 clause BSD one.


I suspect we also have more postitive clarifications about the BSD 
one. It is possible we will get a bizarre interpretation from a 
particular licensor, but we'll deal with that when it happens.



I made a case elsewhere that
the X wording is actually less restrictive because it only affects the
original software, where the BSD clause affects all derived software.


Do both affect derived software, because we need copyright permission 
for the original in order to use the derived, which would otherwise 
infringe copyright of the original?


--
MJR/slefMy Opinion Only and not of any group I know
http://www.ttllp.co.uk/ for creative copyleft computing
Please email about: BT alternative for line rental+DSL;
Education on SMEs+EU FP6; office filing that works fast



Re: Please pass judgement on X-Oz licence: free or nay?

2004-08-09 Thread Joe Wreschnig
On Mon, 2004-08-09 at 03:31, MJ Ray wrote:
> On 2004-08-09 05:35:10 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote:
> 
> > Clause 4 -- which you declared non-free in that thread *before* public
> > conversations with X-Oz, and Brian declared non-free at the start of
> > this thread -- is identical to that used in the existing X license.
> 
> It can be read as a simple assertion in the X licence 
> http://www.x.org/Downloads_terms.html (which seems to be how most 
> copyright holders have treated it), while the copyright permissions of 
> the X-Oz licence 
> http://lists.debian.org/debian-legal/2004/02/msg00154.html clearly 
> depend on it. I don't think it's identical.

I don't see the difference. I mean, I see the difference that one can be
read as an "assertion" and the other can be read as a "clause". But I
don't see how that affects any practical or legal conclusions. In other
words, if I write a license like the BSD one, but append "You will wear
a hat on Fridays." I think it will be clear to everyone, including a
judge, that I intend that to be a requirement to use the freedoms set
forth in the license, even though it's just an "assertion" rather than a
"clause".

> I think I explained this to selussos <[EMAIL PROTECTED]> in 
> http://lists.debian.org/debian-legal/2004/03/msg00048.html but I got a 
> reply of a Mark Twain quote and an assertion that US law is global and 
> the subthread digressed without resolution. No-one found a licence 
> with a similar *condition* in it.

The 3rd clause of the 3 clause BSD license. I made a case elsewhere that
the X wording is actually less restrictive because it only affects the
original software, where the BSD clause affects all derived software.

> The summary http://lists.debian.org/debian-legal/2004/02/msg00229.html
> may have bugs and need updating, but I doubt the ultimate outcome will 
> be different: software under the X-Oz licence does not clearly follow 
> DFSG.

I agree with you on this; but I think it derives entirely from clause 3.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part


Bits from debian-legal between 2004-08-02 and 2004-08-08

2004-08-09 Thread MJ Ray
This summary covers 2 August to 8 August 2004. 
http://lists.debian.org/debian-legal/2004/08/maillist.html#00052


Active threads with over 4 posts:

Please pass judgement on X-Oz licences: free or nay?, over 40 posts, 
last post 8 Aug
http://lists.debian.org/debian-legal/2004/08/threads.html#00014

RPSL and DFSG-compliance - choice of venue, over 10 posts, last post 8 
Aug
http://lists.debian.org/debian-legal/2004/08/threads.html#00051

RPSL and DFSG-compliance, under 10 posts, last post 8 Aug
http://lists.debian.org/debian-legal/2004/08/threads.html#00032

Periodic summaries, under 10 posts, started 7 Aug, last post 8 Aug
http://lists.debian.org/debian-legal/2004/08/threads.html#00143

Web application licenses, under 10 posts, last post 5 Aug
http://lists.debian.org/debian-legal/2004/08/threads.html#00011

Acceptable copyright, under 10 posts, started 3 Aug, last post 8 Aug
http://lists.debian.org/debian-legal/2004/08/threads.html#00104

Free non-software stuff, around 10 posts, last post 3 Aug
http://lists.debian.org/debian-legal/2004/08/threads.html#6


Bits author picks:

evan offers to summarise W3 software license
http://lists.debian.org/debian-legal/2004/08/msg00174.html

Tail of a htdig licensing thread
http://lists.debian.org/debian-legal/2004/08/msg00035.html

Mozilla relicensing progress
http://lists.debian.org/debian-legal/2004/08/msg00144.html



Notes about I think this should be done:

The header should be obvious, I hope. The first section should be 
rigid forms of "subject, rough number, started date if in range, last 
post date, newline, link to thread index". The cutoff number should be 
set to get a maximum of the top 7. The second section is "author's 
description, newline, link to message". I counted posts helped by: 
wget -O- http://lists.debian.org/debian-legal/2004/08/maillist.html | 
sed -n -e '/Aug 02/,/Aug 09/{;s/^.*]*>//;s/Re: 
//g;s/<\/a.*$//;p;}' | sort | uniq
-c | sort -n # pardon linewrap

Please inform me of errors or improvements.

-- 
MJR/slefMy Opinion Only and not of any group I know
http://www.ttllp.co.uk/ for creative copyleft computing
Please email about: BT alternative for line rental+DSL;
Education on SMEs+EU FP6; office filing that works fast

RFC3156 defines security multipart formats for MIME with OpenPGP.

pgphmDeYwGZAH.pgp
Description: PGP signature


summaries bugs, was: Please pass judgement on X-Oz licence: free or nay?

2004-08-09 Thread MJ Ray

On 2004-08-09 06:17:17 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote:


Since February, -legal has had an "official" (as official as they get)
document claiming that even without further annoyances from X-Oz that
clause is non-free. Simon Law, who wrote that summary, has since
realized it was a huge mistake. That means something is wrong in the 
way

we approach license analysis and summary writing.


I agree that something is wrong. Most recently, I mentioned and made 
suggestions about this in 
http://lists.debian.org/debian-legal/2004/07/thrd3.html#00334 
http://lists.debian.org/debian-legal/2004/07/msg00334.html and part of 
another subthread around 
http://lists.debian.org/debian-legal/2004/07/msg00219.html


Sadly, I commit the same sin of poor referencing that I percieve as a 
problem with the summaries. I think the "unpleasantness" was mostly 
about the handling of the MPL threads that month and the month before.


My suggestion wasn't clearly liked, but I feel there wasn't much 
participation. It seems that I don't have time to get discussion on 
this. You seem to care about fixing summaries too: please can you take 
it forwards?


--
MJR/slefMy Opinion Only and not of any group I know
http://www.ttllp.co.uk/ for creative copyleft computing
Please email about: BT alternative for line rental+DSL;
Education on SMEs+EU FP6; office filing that works fast



Re: Suggestions of David Nusinow, was: RPSL and DFSG-compliance - choice of venue

2004-08-09 Thread Brian Nelson
On Sun, Aug 08, 2004 at 06:57:03PM -0500, Branden Robinson wrote:
> [I am not subscribed to -newmaint.]
> 
> On Fri, Jul 30, 2004 at 08:37:40PM +1000, Matthew Palmer wrote:
> > For that matter, I'm not quite sure we should necessarily be subjecting
> > applicants to the joys of rigorous licence analysis.  We have d-legal for
> > this purpose just so maintainers don't have to be licence experts.  The
> > question about Pine licencing is a pretty good test of basic DFSG analytical
> > ability.
> 
> The trouble is, some of the same people who are excused from doing rigorous
> license analysis during P&P proceed to style themselves as licensing
> experts and spitefully ridicule the people who *do* do the hard work on
> debian-legal.  We've seen great many examples of this over the past few
> months.
> 
> Count me in favor of increasing the amount of licensing-oriented material
> in P&P.  In my opinion, we want new developers to more easily grasp the
> facts that:
> 
> 1) sometimes subtle issues are involved when trying to understand a license;
> 2) even licenses like the BSD and GPL represent compromises with "pure 
> freedom"
> 3) phenomena like "moral rights" (droit d'auteur), software patents, and
>regulations on cryptography can cause a given work under a given license
>to be de facto licensed differently in different jurisdictions that
>Debian cares about

It can be really tough to test NM's who are not native English speakers
about licensing issues.  Legal text is very different from colloquial
English, and non-native speakers are often completely overwhelmed.
Hell, even native speakers have difficulty understanding licenses like
the graphviz license.

Making sure an NM grasps the gist of the DFSG is reasonable, but
actually getting them to understand the subtleties involved is
frustrating at best.

-- 
You win again, gravity!



Re: Please pass judgement on X-Oz licence: free or nay?

2004-08-09 Thread MJ Ray

On 2004-08-09 05:35:10 +0100 Joe Wreschnig <[EMAIL PROTECTED]> wrote:


Clause 4 -- which you declared non-free in that thread *before* public
conversations with X-Oz, and Brian declared non-free at the start of
this thread -- is identical to that used in the existing X license.


It can be read as a simple assertion in the X licence 
http://www.x.org/Downloads_terms.html (which seems to be how most 
copyright holders have treated it), while the copyright permissions of 
the X-Oz licence 
http://lists.debian.org/debian-legal/2004/02/msg00154.html clearly 
depend on it. I don't think it's identical.


I think I explained this to selussos <[EMAIL PROTECTED]> in 
http://lists.debian.org/debian-legal/2004/03/msg00048.html but I got a 
reply of a Mark Twain quote and an assertion that US law is global and 
the subthread digressed without resolution. No-one found a licence 
with a similar *condition* in it.


The summary http://lists.debian.org/debian-legal/2004/02/msg00229.html 
may have bugs and need updating, but I doubt the ultimate outcome will 
be different: software under the X-Oz licence does not clearly follow 
DFSG.


--
MJR/slefMy Opinion Only and not of any group I know
http://www.ttllp.co.uk/ for creative copyleft computing
Please email about: BT alternative for line rental+DSL;
Education on SMEs+EU FP6; office filing that works fast



Re: W3 software license

2004-08-09 Thread evan
On Sun, Aug 08, 2004 at 05:36:29PM -0700, Josh Triplett wrote:

> >>>The license looks OK to me, with the possible exception that it says
> >>>"obtaining, using and/or copying this work" implies acceptance of the
> >>>license.

> > I think it sets a bad precedent to wave such language into a
> > list of licenses we accept as DFSG-free without at least asking the
> > upstream authors to remove this wording.

Why don't we do this: I'll write up a summary of the license, and note that we
think that works released under the license would, barring complications, be
free.

I'll also add a suggestion to drop the use language.

How does that sound?

~ESP



Re: Please pass judgement on X-Oz licence: free or nay?

2004-08-09 Thread Joe Wreschnig
On Sun, 2004-08-08 at 17:57, Branden Robinson wrote:
> On Tue, Aug 03, 2004 at 12:20:47PM -0500, Joe Wreschnig wrote:
> > On Tue, 2004-08-03 at 11:15, Matthew Garrett wrote:
> > > The summary claims that clause 4 makes the license non-free.
> 
> ...because we don't undestand what X-Oz means when they say it.

... which you didn't know until after the summary was published and even
then I don't find questions of interpretations of clause 4, but mostly
about clause 3. I'd prefer follow-ups on this topic to go to the other
subthread though.

> > > Since clause 4 is identical to what's contained in the X11 license, it
> > > makes it difficult to take the summary terribly seriously.
> > 
> > Oh, wow.
> > 
> > Shame on you, Branden, for placing Debian's X packaging scripts under a
> > non-free license! Or have you recanted from your position in
> > http://lists.debian.org/debian-legal/2004/02/msg00162.html?
> 
> Is this sort of remark intended to be productive, or are you just venting
> your spleen because you don't appear to have actually comprehended the
> message you cite?

Since February, -legal has had an "official" (as official as they get)
document claiming that even without further annoyances from X-Oz that
clause is non-free. Simon Law, who wrote that summary, has since
realized it was a huge mistake. That means something is wrong in the way
we approach license analysis and summary writing.

My hope is that in the future we will be more careful in our evaluation
of licenses; we will compare them to existing licenses more often; we
will try to keep our core criteria as the DFSG, and try, whenever
possible, to relate arguments back to the DFSG. I don't think they're
exhaustive or meant to be, but lately it seems that the proposed tests
are our "core" criteria and the DFSG are treated as a sort of footnote.
I realize this is because often the licenses we deal with here are on
the borderline. But just because the DFSG aren't a checklist doesn't
mean they're not useful.

We also need to engage the rest of the project more; a common criticism
of -legal is that we're too strict, and too closed to new ideas and
participants. A good way to stop being closed is to admit when we're
wrong. And that summary is wrong.
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part