unsuscribe

[Alejandro Lucas Baldres]

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

Re: Final text of GPL v3

[Iain Nicol]

(First: apologies. This message probably won't thread properly. This is
because I reading this list via Usenet, but because the Usenet gateway
is, I presume, one-way gateway, I have to reply via the list email
address. The trouble is my email client has no message to reply to,
because it's not my NNTP client.)

Concerning section 5d of the final text of the GPL 3:
>   5. Conveying Modified Source Versions.
[...]
> d) If the work has interactive user interfaces, each must display
> Appropriate Legal Notices; however, if the Program has interactive
> interfaces that do not display Appropriate Legal Notices, your
> work need not make them do so.

Francesco Poli worries:
> It mandates a feature that I *must* implement in *any* interactive
> interface of my modified work. [...] it seems that when a
> non-interactive work is modified so that it becomes an interactive
> work, the modifier is *compelled* to implement these features in *any*
> newly created interactive interface.
Could this requirement be interpreted more liberally? I'm concentrating
on the bit from "however". Suppose: I receive a program under the GPL 3.
I create a new interface for the program, without the legal notices.

The license says that, when distributing my modified version, I "need
not make" interfaces of "the Program" that don't display a legal notice
display a legal notice. I think, then, to be exempt from the requirement
to make user interfaces display legal notices, my modified version of
the Program would have to count as just "the Program".

Consider that "The Program" is defined as:
>  "The Program" refers to any copyrightable work licensed under this
> License. 
When I convey a modified source version, 5c) requires the entire
modified work be licensed under the GPL. This then means that when you
convey a modified "the Program", the new bits are licensed, and so the
whole modified program becomes just "the Program". I do not need to add
legal notices to interfaces of "the Program" that lack then.

I'm curious how far fetched people think this is.

If this interpretation were true, then the only burden of this section
would be to keep the legal notices in the user interfaces that you keep,
but you would *not* be required to add any notices to any user
interface, regardless of whether you wrote the interface or not.


-- 
Iain Nicol


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

Re: Final text of GPL v3

[Francesco Poli]

On Sat, 30 Jun 2007 00:47:59 +0200 Francesco Poli wrote:

[...]
> The full final text of the GNU GPL v3 is quoted below for reference.

My comments follow.

The usual disclaimers: IANAL, IANADD.


[...]
>   3. Protecting Users' Legal Rights From Anti-Circumvention Law.
[...]
>   When you convey a covered work, you waive any legal power to forbid
> circumvention of technological measures to the extent such
> circumvention is effected by exercising rights under this License with
> respect to the covered work,

This clause is troublesome, as it seems to be overreaching.  For
instance, it could be interpreted as covering legal powers to forbid
"computer crimes" such as unauthorized intrusion into computer systems.

E.g.: suppose that the covered work is a vulnerability scanner, or
password cracker, or anyway a tool that could be used (among other
things) to break into other people's computers.  Using that tool in this
manner is exercising a right "under this License" and is a circumvention
of appropriate technological measures set to protect a computer system
or network from unauthorized access.  Gaining unauthorized access to a
protected computer system or network is forbidden by law in several
jurisdictions; do I waive such a legal protection, when I convey the
covered work?

Waiving legal rights can be seen as a fee: this clause could fail
DFSG#1.
Hence, this is possibly a Freeness issue.


[...]
>   5. Conveying Modified Source Versions.
[...]
> d) If the work has interactive user interfaces, each must display
> Appropriate Legal Notices; however, if the Program has interactive
> interfaces that do not display Appropriate Legal Notices, your
> work need not make them do so.

Clause 5d is definitely worse than the corresponding clause 2c in GPLv2.

It's an inconvenience and border-line with respect to Freeness. 
Actually this clause restricts how I can modify what an interactive
program does when run.  It mandates a feature that I *must* implement in
*any* interactive interface of my modified work.  It's very close to
place an unacceptable restriction on modification.  What is more awkward
is that it seems that when a non-interactive work is modified so that it
becomes an interactive work, the modifier is *compelled* to implement
these features in *any* newly created interactive interface.

This clause is very close to fail DFSG#3.
Hence, this is possibly a Freeness issue.


[...]
>   7. Additional Terms.
[...]
>   Notwithstanding any other provision of this License, for material
> you add to a covered work, you may (if authorized by the copyright
> holders of that material) supplement the terms of this License with
> terms:
[...]
> b) Requiring preservation of specified reasonable legal notices or
> author attributions in that material or in the Appropriate Legal
> Notices displayed by works containing it; or

I strongly *dislike* the entire concept of allowing a limited set of
additional requirements to be added.  It's *against* the spirit of the
GPLv2 (where the FSF promised that new versions would "be similar in
spirit to the present version", see GPLv2, section 9.) and greatly
weakens the copyleft.

Especially, clause 7b is a permission to add a possibly non-free
requirement.  Actually: what exactly is a "reasonable legal notice"? 
What exactly is an "author attribution"?  These terms are not defined
anywhere in the license.  I'm concerned that they could be interpreted
in a broad sense and allow people to take a GPLv3'd work and add some
sort of invariant long text that nobody will ever be able to remove or
modify...  This option could make a work include unmodifiable &
unremovable parts and thus fail to fully grant the freedom to modify.

This option could make the work fail DFSG#3, when exercised.
It's not a Freeness issue, per se, but a great loss, since
GPL-compatibility is no longer a DFSG-compliance guarantee...


[...]
>   11. Patents.
[...]
>   If you convey a covered work, knowingly relying on a patent license,
> and the Corresponding Source of the work is not available for anyone
> to copy, free of charge and under the terms of this License, through a
> publicly available network server or other readily accessible means,
> then you must either (1) cause the Corresponding Source to be so
> available,

I still fail to understand how (1) can be seen as a specific form of
shielding downstream recipients.  If I am a downstream recipient who
does not have a patent license, what protection (against patent
infringement lawsuits) would I get from the existence of a network
server which makes source available to the public?

I'm puzzled.

This clause could be not enough to protect recipients from patent
lawsuits, and thus make the work fail several DFSG, when there are
actively enforced patents infringed by the work.
It's not a Freeness issue, unless and until there are actively enforced
patents infringed by the work.


[...]
>   A patent license is "discriminatory" if it d

Final text of GPL v3

[Francesco Poli]

Hi all,
the final text of the GNU GPL v3 has been published on 29 June 2007 by
the FSF.
The plain text form can be downloaded from:
http://www.gnu.org/licenses/gpl-3.0.txt

The main substantial changes with respect to the "Last Call Draft"
(discussed in the thread
http://lists.debian.org/debian-legal/2007/06/msg00016.html) are in
sections 8 and 13.
As far as section 13 is concerned, now the compatibility with the yet
unreleased GNU AGPL v3 is complete (for both linking and combining),
even though not automatically extended to later versions of the GNU
AGPL.

The full final text of the GNU GPL v3 is quoted below for reference.




GNU GENERAL PUBLIC LICENSE
   Version 3, 29 June 2007

 Copyright (C) 2007 Free Software Foundation, Inc. 
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

Preamble

  The GNU General Public License is a free, copyleft license for
software and other kinds of works.

  The licenses for most software and other practical works are designed
to take away your freedom to share and change the works.  By contrast,
the GNU General Public License is intended to guarantee your freedom to
share and change all versions of a program--to make sure it remains free
software for all its users.  We, the Free Software Foundation, use the
GNU General Public License for most of our software; it applies also to
any other work released this way by its authors.  You can apply it to
your programs, too.

  When we speak of free software, we are referring to freedom, not
price.  Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
them if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it in new
free programs, and that you know you can do these things.

  To protect your rights, we need to prevent others from denying you
these rights or asking you to surrender the rights.  Therefore, you have
certain responsibilities if you distribute copies of the software, or if
you modify it: responsibilities to respect the freedom of others.

  For example, if you distribute copies of such a program, whether
gratis or for a fee, you must pass on to the recipients the same
freedoms that you received.  You must make sure that they, too, receive
or can get the source code.  And you must show them these terms so they
know their rights.

  Developers that use the GNU GPL protect your rights with two steps:
(1) assert copyright on the software, and (2) offer you this License
giving you legal permission to copy, distribute and/or modify it.

  For the developers' and authors' protection, the GPL clearly explains
that there is no warranty for this free software.  For both users' and
authors' sake, the GPL requires that modified versions be marked as
changed, so that their problems will not be attributed erroneously to
authors of previous versions.

  Some devices are designed to deny users access to install or run
modified versions of the software inside them, although the manufacturer
can do so.  This is fundamentally incompatible with the aim of
protecting users' freedom to change the software.  The systematic
pattern of such abuse occurs in the area of products for individuals to
use, which is precisely where it is most unacceptable.  Therefore, we
have designed this version of the GPL to prohibit the practice for those
products.  If such problems arise substantially in other domains, we
stand ready to extend this provision to those domains in future versions
of the GPL, as needed to protect the freedom of users.

  Finally, every program is threatened constantly by software patents.
States should not allow patents to restrict development and use of
software on general-purpose computers, but in those that do, we wish to
avoid the special danger that patents applied to a free program could
make it effectively proprietary.  To prevent this, the GPL assures that
patents cannot be used to render the program non-free.

  The precise terms and conditions for copying, distribution and
modification follow.

   TERMS AND CONDITIONS

  0. Definitions.

  "This License" refers to version 3 of the GNU General Public License.

  "Copyright" also means copyright-like laws that apply to other kinds of
works, such as semiconductor masks.
 
  "The Program" refers to any copyrightable work licensed under this
License.  Each licensee is addressed as "you".  "Licensees" and
"recipients" may be individuals or organizations.

  To "modify" a work means to copy from or adapt all or part of the work
in a fashion requiring copyright permission, other than the making of an
exact copy.  The resulting work is called a "modified version" of the
earlier work or a work "based on" the earlier work.

  A "covered work" means either t

Re: [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks

[Santiago Vila]

On Sat, 30 Jun 2007, Robert Millan wrote:

> On Sat, Jun 30, 2007 at 12:17:00AM +0200, Santiago Vila wrote:
> > + file.  Packages should not refer to GPL and LGPL symlinks in
> > + that directory since different, incompatible versions of these
> > + licenses have been published by the Free Software Foundation,
> > + hence using the symlinks could lead to ambiguity.
> > 
> > I disagree with this. It should be ok to point to the latest version
> > of the GPL if the program says "Version X or later". Many programs
> > do that, and we should not need to change them.
> > 
> > Instead, I think we should amend policy in this way:
> > 
> >   Packages under a fixed, definite version of the GPL should refer to
> >   the versioned GPL file in /usr/share/common-licenses.
> 
> Good idea.  Should we also specify that referring to the unversioned GPL
> is for programs that say "Version X or later" ?  I think this is not obvious.

Obvious or not, it is, IMHO, the logical thing to do. If it needs to
be written, so be it.

What we need is a policy which works when GPL is a symlink to the latest
available version and additionaly makes clear what people should do
in each case.


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

Re: [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks

[Robert Millan]

On Sat, Jun 30, 2007 at 12:17:00AM +0200, Santiago Vila wrote:
> + file.  Packages should not refer to GPL and LGPL symlinks in
> + that directory since different, incompatible versions of these
> + licenses have been published by the Free Software Foundation,
> + hence using the symlinks could lead to ambiguity.
> 
> I disagree with this. It should be ok to point to the latest version
> of the GPL if the program says "Version X or later". Many programs
> do that, and we should not need to change them.
> 
> Instead, I think we should amend policy in this way:
> 
>   Packages under a fixed, definite version of the GPL should refer to
>   the versioned GPL file in /usr/share/common-licenses.

Good idea.  Should we also specify that referring to the unversioned GPL
is for programs that say "Version X or later" ?  I think this is not obvious.

-- 
Robert Millan

My spam trap is [EMAIL PROTECTED]  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.


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

Re: [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks

[Santiago Vila]

+ file.  Packages should not refer to GPL and LGPL symlinks in
+ that directory since different, incompatible versions of these
+ licenses have been published by the Free Software Foundation,
+ hence using the symlinks could lead to ambiguity.

I disagree with this. It should be ok to point to the latest version
of the GPL if the program says "Version X or later". Many programs
do that, and we should not need to change them.

Instead, I think we should amend policy in this way:

  Packages under a fixed, definite version of the GPL should refer to
  the versioned GPL file in /usr/share/common-licenses.


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

Re: [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks

[Santiago Vila]

> This proposal does essentialy two things:
> 
>   - Disambiguate GPL/LGPL versioning requirement by extending it to any DFSG
>   compatible version the FSF may publish.
> 
>   - Deprecate use of symlinks, since they're a source of problems (as exposed
>   by GPLv3, see http://lists.debian.org/debian-legal/2007/06/msg00234.html)

Symlinks are not a problem. The real problem are hardcoded references
to "GPL" when they should have been references to GPL-2.

For programs which are under "GPL v2 or later" or "GPL v3 or later"
(most of them, if I'm not mistaken), the symlink is useful, so it
should be kept.


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

[PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL symlinks

[Robert Millan]

retitle 431109 [PROPOSAL] Disambiguate of Section 12.5, Deprecate GPL/LGPL 
symlinks
thanks

On Fri, Jun 29, 2007 at 10:04:02PM +0200, Santiago Vila wrote:
> 
> Following /usr/share/doc/base-files/FAQ, I'm reassigning this to 
> debian-policy.
> 
> Please read my email to debian-legal ad debian-policy from two days ago.

In my interpretation, Policy doesn't exclude any version of the GPL from this
requirement, but I admit that it is ambigous, specially considering the
examples.

This proposal does essentialy two things:

  - Disambiguate GPL/LGPL versioning requirement by extending it to any DFSG
  compatible version the FSF may publish.

  - Deprecate use of symlinks, since they're a source of problems (as exposed
  by GPLv3, see http://lists.debian.org/debian-legal/2007/06/msg00234.html)

-- 
Robert Millan

My spam trap is [EMAIL PROTECTED]  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.
diff -ur debian-policy-3.7.2.2.old/policy.sgml debian-policy-3.7.2.2/policy.sgml
--- debian-policy-3.7.2.2.old/policy.sgml	2006-10-03 00:36:50.0 +0200
+++ debian-policy-3.7.2.2/policy.sgml	2007-06-29 23:58:41.0 +0200
@@ -41,7 +41,7 @@
 
 	
 	  A copy of the GNU General Public License is available as
-	  /usr/share/common-licenses/GPL in the Debian GNU/Linux
+	  /usr/share/common-licenses/GPL-2 in the Debian GNU/Linux
 	  distribution or on the World Wide Web at
 	  http://www.gnu.org/copyleft/gpl.html";
 	   name="the GNU General Public Licence">. You can also
@@ -8625,24 +8625,26 @@
 
 	
 	  Packages distributed under the UCB BSD license, the Artistic
-	  license, the GNU GPL, and the GNU LGPL, should refer to the
-	  corresponding files under
+	  license, the GNU GPL or LGPL (any version as published by the Free
+	  Software Foundation that Debian considers free as per DFSG), should
+	  refer to the corresponding files under
 	  /usr/share/common-licenses,
 
   For example,
   /usr/share/common-licenses/Artistic,
   /usr/share/common-licenses/BSD,
-  /usr/share/common-licenses/GPL,
-  /usr/share/common-licenses/LGPL,
   /usr/share/common-licenses/GFDL,
-  /usr/share/common-licenses/GPL-2, and
-  /usr/share/common-licenses/LGPL-2.1, and so
+  /usr/share/common-licenses/GPL-3, and
+  /usr/share/common-licenses/LGPL-3, and so
   on. Note that the GFDL is new here, and the license file
   may not yet be in place in
   /usr/share/common-licenses/GFDL. 
 
rather than quoting them in the copyright
-	  file. 
+	  file.  Packages should not refer to GPL and LGPL symlinks in
+	  that directory since different, incompatible versions of these
+	  licenses have been published by the Free Software Foundation,
+	  hence using the symlinks could lead to ambiguity.
 	
 
 	


signature.asc
Description: Digital signature

Re: Copyright verification needed

[Francesco Poli]

On Fri, 29 Jun 2007 00:34:33 +0200 Josselin Mouette wrote:

> Le mardi 26 juin 2007 à 00:48 +0200, Francesco Poli a écrit :
> > On Tue, 26 Jun 2007 00:06:58 +0200 Josselin Mouette wrote:
> > > This is a bit more complicated. The QPL is DFSG-free, but only if
> > > you don't apply section #6
> > 
> > This is equivalent to saying that software solely released under the
> > QPL does *not* comply with the DFSG.
> 
> No. Section #6 only applies to components "that link with the original
> or modified versions of the Software". It doesn't apply to derived
> works.

I am afraid I am not following you.

Section 6c of the QPL v1.0 restricts your ability to privately
distribute components "that link with the original or modified versions
of the Software".

You cannot opt out from this restriction, unless you refrain from
developing such components.
The DFSG require that you are able to develop such components, and the
restriction is non-free.

I cannot see how you can say that "the QPL is DFSG-free [...] if you
don't apply section #6".
How can you escape from the restrictions set forth in section #6?

> 
> > When discussing whether a license meets the DFSG, "patched" versions
> > of the license cannot help the "unpatched" original license to meet
> > the DFSG...
> 
> I'm not talking about a hypothetical "patched" license, and you should
> consider reading what people write before replying on a mailing list.

I did read what you wrote, but I apparently misunderstood it.
Sorry about that: in the above, I'm asking you to clarify what you
meant...

> 
> > And anyway, you there's not only clause 6c: another issue that makes
> > the QPL fail to meet the DFSG is the choice of venue.
> 
> There is no choice of venue, only choice of law.

AFAICS, we are talking about the QPL v1.0 as adopted by Trolltech AS for
the Qt library.  Is that right?

If this is the case, the license states[1]:

| This license is governed by the Laws of Norway. Disputes shall be
| settled by Oslo City Court.

This is a choice of law *and* a choice of venue.

[1] 
http://packages.debian.org/changelogs/pool/main/q/qt-x11-free/current/copyright



P.S.: I think we should drop Bruno from the Cc: list, as he stated he's
not interested in the ITP anymore.  Bruno, if you are still interested
in this discussion, please speak up and ask to be Cc:ed in the next
messages...


-- 
 http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html
 Need to read a Debian testing installation walk-through?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpL6f1b1dRXi.pgp
Description: PGP signature

Re: Copyright verification needed

[Josselin Mouette]

Le vendredi 29 juin 2007 à 00:36 +0200, Josselin Mouette a écrit :
> Le jeudi 28 juin 2007 à 10:24 +0200, Bruno Costacurta a écrit :
> > > AFAICS you can use it legally if you port it to GNUTLS.
> 
> > - the actual code implemented a strong separation layer between OpenSSL and 
> > Qt 
> > (review of code can be made by independent party) thus licenses should not 
> > be 
> > mixed in their interpretations.
> 
> Regardless of the implementation, a resulting binary that requires both
> OpenSSL and Qt to work is considered a derived work from both, and is
> therefore not distributable.

Hmm, I forgot what I said earlier about the QPL when writing this. A
work that links with both OpenSSL and Qt *is* distributable, but in this
case section #6 of the QPL applies. I think this is not OK for main, but
it is acceptable for non-free.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: DPL's view of debian-legal (was: Debian Trademarks Summary)

[Francesco Poli]

On Fri, 29 Jun 2007 13:17:10 +0100 Anthony Towns wrote:

[...]
> In 2006, we had:
> 
>   - a resolution on the DFSG-free status of the GFDL

Where the winning option legislated without *any explanation* that the
DFSG issues of the GFDL (except for the invariant-like ones) do not
exist.
This resolution is doing more harm than good: it has been misinterpreted
by many people as "Debian states the GFDL is OK", it sent a signal to
FSF that there's no real need to fix those issues with the GFDL as they
are considered acceptable anyway, it poses serious logical problems when
one tries to reconcile its result with the DFSG, people has already
tried to use it as a precedent to allow other non-free restrictions into
main, ...

See the following thread:
http://lists.debian.org/debian-legal/2006/03/msg00098.html

>   - a resolution of the licensing problems preventing us from
> distributing Java at all, including, eventually, legal advice
> via SPI to that effect

Resolution?  Do you mean a GR, a vote?
Am I missing anything?  I don't recall any vote on this issue...

Moreover the DLJ license affair was, IMHO, handled quite badly: every
decision seemed to have been taken behind closed doors by very few
people and communicated publicly only when it was too late for providing
suggestions and advice.
I was really worried by all that accepting licenses with contradictory
FAQs and non-legally-binding clarifications.

See the following thread:
http://lists.debian.org/debian-legal/2006/05/msg00064.html

>   - DFSG-free updates to creative commons licenses

Which we *did not* have, because CC licenses still fail to meet the
DFSG, IMO.

See the following threads:
http://lists.debian.org/debian-legal/2007/03/msg00024.html
http://lists.debian.org/debian-legal/2007/03/msg00023.html
http://lists.debian.org/debian-legal/2007/02/msg00059.html

>   - new draft of the GFDL resolving Debian's other concerns

Which we *did not* have, since the first draft of the GFDL v2 does not
solve all the GFDL issues which are not related to invariantness.

See the following thread:
http://lists.debian.org/debian-legal/2006/12/msg00123.html

>   - a resolution on how we approach sourceless firmware

Which decided to ignore this issue for the release of etch (despite the
opposite promise made with GR-2004-004) and was not respected anyway.

See bug:
http://bugs.debian.org/412950

>   - Java licensed under the GPL

Which could be seen as a positive effect of the DLJ mess, but it's still
incomplete, AFAIUI.
At least sun-java6 source package is still in the non-free archive,
AFAICT.

See
http://packages.debian.org/unstable/source/sun-java6
http://packages.debian.org/changelogs/pool/non-free/s/sun-java6/sun-java6_6-00-2/copyright

>   - a recommendation to SPI on a free copyright license and
> more free trademark handling for our logos that's since been
> acted on, and is now just pending an announcement by the DPL

Which actually *is* a little progress on the issue we were discussing in
the present thread and is appreciated, as I said at the time. 
Unfortunately that move leaves the harder side of the issue (that is to
say, trademark licensing) in a black-or-white situation (no trademark
restrictions for one logo, non-free restrictions for the other logo),
which is suboptimal.

See the following thread:
http://lists.debian.org/debian-legal/2007/02/msg00012.html


-- 
 http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html
 Need to read a Debian testing installation walk-through?
. Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4


pgpUXOfPwoWLc.pgp
Description: PGP signature

Re: slepc license

[Ondrej Certik]

Permission to distribute binary packages at least.  While you're asking,
why not ask for it as free software?  Even one with an obnoxious ad
clause (so they get their attribution) would be an improvement.

Hope that helps,


That helps a lot. Thanks. I asked the upstream and they seem not to be
against using the old BSD license with the ad clause, so that maybe
the next version will be distributed with that license.

I realized, that 2.3.2 version that I am going to package at the
moment contains the license below, which is not free, but can go to
non-free. The problem above is only for the 2.3.3 version.

Ondrej

Copyright (c) 2002-2006, Universidad Politecnica de Valencia, Spain

This  software is provided 'as is', with absolutely no warranty, expressed  or
implied.  Any use is at your own risk. In no event shall the authors be liable
for  any direct or indirect damages arising in any way out of the use of  this
software.

The  user will acknowledge (using references [1] or [2]) the  contribution  of
SLEPc  in any publication of material dependent upon the use of  the  package.
The  user  will reasonably endeavour to notify the authors of the  package  of
this publication.

The  user can modify the code but, at no time shall the right or title to  all
or  any  part  of  this  package pass to the user. Contributions  are  welcome
relating  to any alteration or addition made to this package for the  purposes
of  extending the capabilities or enhancing its performance.  Credit  will  be
given in the documentation for contributed code.

This  package (or a modified version) may not be sold. It is freely  available
and  it can be redistributed provided that redistribution comprises all  files
including this copyright notice. No license is required for research use.  For
commercial use, written permission must be granted by the authors.


[1] V. Hernandez, J. E. Roman and V. Vidal (2005),
SLEPc: A Scalable and Flexible Toolkit for the Solution of
Eigenvalue Problems
ACM Trans. Math. Softw. 31(3), 351-362.

[2] V. Hernandez, J. E. Roman and V. Vidal (2002),
SLEPc Users Manual, Technical Report DSIC-II/24/02,
Universidad Politecnica de Valencia, Spain.


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

Re: DPL's view of debian-legal (was: Debian Trademarks Summary)

[Anthony Towns]

On Wed, Jun 27, 2007 at 05:38:20PM +0100, Anthony Towns wrote:
> On Wed, Jun 27, 2007 at 09:59:50AM +0100, MJ Ray wrote:
> > I think the Anthony Towns DPLship was not a fun time for those trying
> > to fix legal bugs and it should have been ended sooner.

You know, beyond the initial offensiveness, this is actually a pretty
remarkable statement.

In 2006, we had:

- a resolution on the DFSG-free status of the GFDL
- a resolution of the licensing problems preventing us from
  distributing Java at all, including, eventually, legal advice
  via SPI to that effect
- DFSG-free updates to creative commons licenses
- new draft of the GFDL resolving Debian's other concerns
- a resolution on how we approach sourceless firmware
- Java licensed under the GPL
- a recommendation to SPI on a free copyright license and
  more free trademark handling for our logos that's since been
  acted on, and is now just pending an announcement by the DPL

All of those have been causing problems for Debian users for years; if
you don't find getting actual solutions to those sorts of legal issues
"fun", maybe you're in the wrong business.

Cheers,
aj



signature.asc
Description: Digital signature

Re: slepc license

[MJ Ray]

Ondrej Certik <[EMAIL PROTECTED]> wrote:
> I would like to package SLEPc eigenvalue solvers[0] into non-free, the
> license is below. There is a line "A modified version of the software
> cannot be redistributed". The debian package can be built without
> modificating the upstream sources though, so my question is, can it go
> into non-free?

In the absence of any definition of what they mean by a modified
version, I think a binary package is a modified version of the source.

(This is not a new worry:
http://lists.debian.org/debian-devel/1997/08/msg00119.html
)

> And if not, the upstream authors asked me what words
> should be added to the license in order for the Debian to be able to
> distribute it in non-free?

Permission to distribute binary packages at least.  While you're asking,
why not ask for it as free software?  Even one with an obnoxious ad
clause (so they get their attribution) would be an improvement.

Hope that helps,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: Copyright verification needed

[Bruno Costacurta]

On Friday 29 June 2007 00:36:43 Josselin Mouette wrote:
> Le jeudi 28 juin 2007 à 10:24 +0200, Bruno Costacurta a écrit :
> > > AFAICS you can use it legally if you port it to GNUTLS.
> >
> > - the actual code implemented a strong separation layer between OpenSSL
> > and Qt (review of code can be made by independent party) thus licenses
> > should not be mixed in their interpretations.
>
> Regardless of the implementation, a resulting binary that requires both
> OpenSSL and Qt to work is considered a derived work from both, and is
> therefore not distributable.

Thanks to all for attention and follow up.
Unfortunately I come to the conclusion that this planned packaging will be 
complicated regarding its licenses duties (porting to GnuTLS...etc..) and so 
decide to abandon the creation of the ITP (Intend To Package).

Regards,
Bruno Costacurta

-- 
PGP key ID: 0x2e604d51
Key server: hkp://subkeys.pgp.net
Key fingerprint = 713F 7956 9441 7DEF 58ED  1951 7E07 569B 2E60 4D51
--


pgpQOiXhRjrZP.pgp
Description: PGP signature