On Thu, 2023-06-01 at 15:54 +0200, Matthias Geiger wrote:
> I was working on packaging sepaxml [1] when I ran into an issue
> where I'd appreciate some legal guidance. The source contains .xsd
> SEPA files [2] distributed by the iso committee [3] under what I
> believe to be DFSG-compliant licens
On Fri, 2023-06-02 at 10:42 +0800, Paul Wise wrote:
> Although the material on this site is intended to be used and reproduced
> freely
> by all interested users under the ISO 20022 Intellectual Property Right
> Policy,
Here is a copy of that policy:
https://www.iso20022.org/intellectual
On Thu, 2023-06-01 at 15:54 +0200, Matthias Geiger wrote:
> I was working on packaging sepaxml [1] when I ran into an issue
> where I'd appreciate some legal guidance. The source contains .xsd
> SEPA files [2] distributed by the iso committee [3] under what I
> believe to be DFSG-compliant licens
DFSG ?
Regards,
---
Matthias Geiger (werdahias)
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033096[2]
https://github.com/raphaelm/python-sepaxml/blob/master/sepaxml/schemas
<https://github.com/raphaelm/python-sepaxml/blob/master/sepaxml/schemas/pain.001.001.03.xsd>
[3] https://www.i
Em 20-09-2017 10:56, Ian Jackson escreveu:
> Herbert Fortes writes ("Re: Bug#875876: RFS: python-dtcwt/0.12.0-1"):
>> [Ian Jackson:]
>>> So I think that the situation is perfectly clear. Algorithms are not
>>> covered by copyright (anywhere). The upstream a
Herbert Fortes writes ("Re: Bug#875876: RFS: python-dtcwt/0.12.0-1"):
> [Ian Jackson:]
> > So I think that the situation is perfectly clear. Algorithms are not
> > covered by copyright (anywhere). The upstream author is just being
> > over-cautious in leaving in th
My typo:
-over-cautions
+over-cautious
>
> So I think that the situation is perfectly clear. Algorithms are not
> covered by copyright (anywhere). The upstream author is just being
> over-cautious in leaving in that notice.
>
Why being "over-cautions" if the append is useless. That's the term I
should use at first. It is the ups
Ghislain Vaillant writes ("Re: Bug#875876: RFS: python-dtcwt/0.12.0-1"):
> FYI, here is the interpretation of the license by the upstream author. I
> asked about it back when I did the initial release, and no issue was
> raised by the FTP team.
>
> https://github.c
Em 17-09-2017 11:24, Ghislain Vaillant escreveu:
> FYI, here is the interpretation of the license by the upstream author. I
> asked about it back when I did the initial release, and no issue was raised
> by the FTP team.
>
> https://github.com/rjw57/dtcwt/issues/109
>
> It would be nice to have
have to justify my work on this package every time a different
sponsor comes in.
Cheers,
Ghis
On 16/09/17 12:32, Ghislain Vaillant wrote:
The copyright you quoted applies to the code from the original
implementation in MATLAB.
This code is a complete rewrite in Python, so the original copy
The copyright you quoted applies to the code from the original
implementation in MATLAB.
This code is a complete rewrite in Python, so the original copyright should
not apply. Not sure why this file is provided since the two code bases are
different.
Anyway I am open to hear from a second
Hi Ghislain Vaillant,
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "python-dtcwt"
>
> * Package name : python-dtcwt
> Version : 0.12.0-1
> Upstream Author : R
> On Thu, 30 Apr 2015, Richard Fontana wrote:
> It's clear that Dave did see the Baruch Even code, since he modified it.
> He also says "the credits in the source file are there to honor the
> inspiration for the source, not the actual implementation."
> None of this makes me inclined to see
s to
all his popular works.
--
\ “Why doesn't Python warn that it's not 100% perfect? Are people |
`\ just supposed to “know” this, magically?” —Mitya Sirenef, |
_o__) comp.lang.python, 2012-12-27 |
Ben Finney
--
To UNSUBSCRIBE, email to d
On Thu, Apr 30, 2015 at 06:56:13PM +0200, Andrew Shadura wrote:
> Hello,
>
> I've bumped into an interesting thing: python-jsmin claims to be a
> Python rewrite of jsmin, but it's not clear if it's infected by Douglas
> Crockford's "evilness" or
Andrew Shadura writes:
> python-jsmin claims to be a Python rewrite of jsmin, but it's not
> clear if it's infected by Douglas Crockford's "evilness" or not? It's
> in Debian currently, but look here:
>
> https://bugzilla.redhat.com/show_bug.cgi?i
Daniel Stender writes:
> I've asked about its copyright on Mentors before and the consensus was
> that by the trademark policy [2] it's considered to be freely
> distributable, but *might* violate the DFSG.
>
> I'm seeking now for an "official" statement before this is going to be
> put in the ne
Hello,
I'm working on a package which sources includes a version of the
official Python logo [1], which is used for examples and the tests.
I've asked about its copyright on Mentors before and the
consensus was that by the trademark policy [2] it's considered
to be freely dis
t;> should be equally valid as the formal exception, right?
>
> OK, not quite: Upstream explicitly states, that OpenSSL license
> is incompatible with GPL-3, but is seen by them as system library
> if it does provide functions via the Python standard library.
>
> https://github.c
Upstream explicitly states, that OpenSSL license
is incompatible with GPL-3, but is seen by them as system library
if it does provide functions via the Python standard library.
https://github.com/xray7224/PyPump/issues/101#issuecomment-70409244
https://github.com/xray7224/PyPump/issues/101#issuecomm
rating system, but
> that all users of the software can reasonably be expected to have. For
> example, it now also includes the standard libraries of common
> programming languages such as Python and Ruby.
Of course, in the actual license, there is no word about "Python".
--
questio
On 2015-01-18 12:16, W. Martin Borgert wrote:
> Upstream has been contacted. So far they seem to think, that
> this is a Debian internal issue and don't want to add anything
> to their license (GPL-3+). I'll try again.
Isn't the fact that upstream does not care sufficient evidence
that in this cas
On 2015-01-18 15:09, Riley Baird wrote:
> Then as is, the software can't go into Debian. Maybe you could try
> contacting upstream to ask them for an OpenSSL exception?
Upstream has been contacted. So far they seem to think, that
this is a Debian internal issue and don't want to add anything
to th
> My conclusion is that if you have a GPL program importing the "ssl"
> module, you can ignore the licensing issue on either the ground
> that nobody really cares or the fact that OpenSSL should be
> considered as a system library (and this is easier with GPLv3 than
> it was with GPLv2).
You mig
On 18/01/15 08:18, Vincent Bernat wrote:
> ❦ 17 janvier 2015 19:14 +0100, "W. Martin Borgert" :
>> Python program or library "X" is licensed under GPL3+ without
>> OpenSSL exception. "X" does use the python-requests library,
>> which on loa
❦ 17 janvier 2015 19:14 +0100, "W. Martin Borgert" :
> sorry, if this question has been discussed before.
> Python program or library "X" is licensed under GPL3+ without
> OpenSSL exception. "X" does use the python-requests library,
> which on load dyn
On 18/01/15 09:34, W. Martin Borgert wrote:
> On 2015-01-18 07:39, Riley Baird wrote:
>> If you could make a version of python-requests with the OpenSSL parts
>> removed, then yes. Otherwise, no.
>
> If one imports requests from Debian, OpenSSL is used.
> No idea how to p
On 2015-01-18 07:39, Riley Baird wrote:
> If you could make a version of python-requests with the OpenSSL parts
> removed, then yes. Otherwise, no.
If one imports requests from Debian, OpenSSL is used.
No idea how to prevent this.
> Also, if the writer of the module specifically st
On 18/01/15 05:14, W. Martin Borgert wrote:
> Hi,
>
> sorry, if this question has been discussed before.
> So far, I could not find a conclusive answer.
> Please Cc me.
>
> Python program or library "X" is licensed under GPL3+ without
> OpenSSL exception. "
Hi,
sorry, if this question has been discussed before.
So far, I could not find a conclusive answer.
Please Cc me.
Python program or library "X" is licensed under GPL3+ without
OpenSSL exception. "X" does use the python-requests library,
which on load dynamically links th
Hi Yaroslav,
Le Fri, Dec 12, 2014 at 12:07:41PM -0500, Yaroslav Halchenko a écrit :
>
> If we have a library X in Python, released under some GPL-compatible
> license (e.g. BSD-3 or Expat) and then using (optionally) some GPL code
> (at run time) provided by another library Y --
>
>> If we have a library X in Python, released under some GPL-compatible
>> license (e.g. BSD-3 or Expat) and then using (optionally) some GPL code
>> (at run time) provided by another library Y -- what are the implications?
>> Am I wrong on any of the following sta
Yaroslav Halchenko wrote:
Dear fellas who know much more about licensing than me.
I might have even asked before (since we are in a similar situation with
PyMVPA/shogun) but forgot what was the summary:
If we have a library X in Python, released under some GPL-compatible
license (e.g. BSD-3 or
Yaroslav Halchenko writes:
> If we have a library X in Python, released under some GPL-compatible
> license (e.g. BSD-3 or Expat) and then using (optionally) some GPL
> code (at run time) provided by another library Y -- what are the
> implications?
The implications depend on what “
Dear fellas who know much more about licensing than me.
I might have even asked before (since we are in a similar situation with
PyMVPA/shogun) but forgot what was the summary:
If we have a library X in Python, released under some GPL-compatible
license (e.g. BSD-3 or Expat) and then using
On 05/05/14 11:18, Simon Fondrie-Teitler wrote:
> Hi,
>
> I'm working on packaging pypump, which is licensed under the GPL-3. The
> package reviewer noticed it requires python-openssl to function. Does
> this mean that pypump needs an OpenSSL exception in order to be
Hi,
I'm working on packaging pypump, which is licensed under the GPL-3. The
package reviewer noticed it requires python-openssl to function. Does
this mean that pypump needs an OpenSSL exception in order to be included
in Debian?
Thanks,
Simon
pgpx0bKuAJyqC.pgp
Description: PGP signature
Dear All,
Full article:
http://pyfound.blogspot.co.uk/2013/02/python-trademark-at-risk-in-europe-we.html
There is a company in the UK that is trying to trademark the use of
the term "Python" for all software, services, servers... pretty much
anything having to do with a computer. Sp
"Scott Leggett" writes:
> I am considering packaging an application known as 'python-iview'[1]
> (existing RFP[2]) and I wanted to get some legal/policy advice before
> filing an ITP.
Thank you for taking care with the thorny freedom issues around such a
pro
Hi,
I am considering packaging an application known as 'python-iview'[1] (existing
RFP[2]) and I wanted to get some legal/policy advice before filing an ITP.
First, a description of what 'ABC[3] iview' is, from their FAQ[4]:
> ABC iview is a free internet broadcastin
2011/3/7 Ulrik Sverdrup :
> Can GPLv3+ applications written in Python exist in Debian main? The
> applications in question do not use an openssl exception.
>
> Python uses OpenSSL so the moment the application starts, it is linking
> against it too:
>
> $ objdump -p /usr
On Mon, Mar 7, 2011 at 7:48 PM, Ulrik Sverdrup wrote:
> Can GPLv3+ applications written in Python exist in Debian main? The
> applications in question do not use an openssl exception.
>
> Python uses OpenSSL so the moment the application starts, it is linking
> against it too:
&
Can GPLv3+ applications written in Python exist in Debian main? The
applications in question do not use an openssl exception.
Python uses OpenSSL so the moment the application starts, it is linking
against it too:
$ objdump -p /usr/bin/python2.6 | grep NEEDED
NEEDED libpthread.so
On 12/18/09, Ben Finney wrote:
> Andrew Donnellan writes:
>
>> On 12/18/09, Ben Finney wrote:
>> > I'm doubtful that it's correct to say “If it's copyright, it has an
>> > owner”. Copyright is *not* a property right; it's a different
>> > monopoly right. Monopolies are held; that doesn't make th
Andrew Donnellan writes:
> On 12/18/09, Ben Finney wrote:
> > I'm doubtful that it's correct to say “If it's copyright, it has an
> > owner”. Copyright is *not* a property right; it's a different
> > monopoly right. Monopolies are held; that doesn't make the holder of
> > a monopoly the “owner”
On 12/18/09, Ben Finney wrote:
> I'm doubtful that it's correct to say “If it's copyright, it has an
> owner”. Copyright is *not* a property right; it's a different monopoly
> right. Monopolies are held; that doesn't make the holder of a monopoly
> the “owner” in a property sense.
>
> IANAL, but i
Francesco Poli writes:
> On Thu, 17 Dec 2009 01:00:48 + Anthony W. Youngman wrote:
>
> > If it's copyright, it's proprietary.
> >
> > "proprietary" == "property". If it's copyright, it has an owner,
> > therefore it's property, therefore it's proprietary.
>
> Your reasoning does not seem in
On Thu, 17 Dec 2009 01:00:48 + Anthony W. Youngman wrote:
> In message <20091216233823.af491478@firenze.linux.it>, Francesco
> Poli writes
> >> The second question may seem strange, but why copyleft license is
> >> used?
> >
> >Hopefully in order to prevent the distribution of proprietar
On Dec 17, 2009, at 2:00 AM, Anthony W. Youngman wrote:
> CLOSED derivative works.
>
> If it's copyright, it's proprietary.
>
> "proprietary" == "property". If it's copyright, it has an owner, therefore
> it's property, therefore it's proprietary.
Although the GNU project disagrees again with y
In message <20091216233823.af491478@firenze.linux.it>, Francesco
Poli writes
The second question may seem strange, but why copyleft license is
used?
Hopefully in order to prevent the distribution of proprietary
derivative works...
CLOSED derivative works.
If it's copyright, it's proprie
On Tue, 15 Dec 2009 14:20:45 +0200 anatoly techtonik wrote:
> Hello,
Hello...
>
> Following recent Python policy updates I wonder if GPL is really the
> license of choice for software documentation in Debian?
IMHO, yes it is and it should be, really!
The GPL is the best choice
Hello,
Following recent Python policy updates I wonder if GPL is really the
license of choice for software documentation in Debian? There are many
other licenses available that are more clear to general public, such
as Creative Commons.
The second question may seem strange, but why copyleft
* Florian Weimer [090712 20:43]:
> * Anderson Lizardo:
>
> > I noticed that some files of the "re" module still have the (GPL
> > incompatible) 1.6 license notice. Is that on purpose or
> > unintentionally forgotten?
>
> It is generally assumed that the PSF license grant in the LICENSE file
> ov
* Anderson Lizardo:
> I noticed that some files of the "re" module still have the (GPL
> incompatible) 1.6 license notice. Is that on purpose or
> unintentionally forgotten?
It is generally assumed that the PSF license grant in the LICENSE file
overrides all the other licenses that apply to indiv
Hi,
I already sent this to the python-dev mailing list last week[1], but
there was not much interest on the issue. Here is the original
message:
###
I noticed that some files of the "re" module still have the (GPL
incompatible) 1.6 license notice. Is that on purpose or
unintentionally
В Sun, 05 Apr 2009 18:17:18 +0200, Cristian Greco написа:
> The python-libtorrent package contains bindings for
> libtorrent-rasterbar, which in turn gets linked against OpenSSL. So, is
> it right to ask upstream to add the exception?
FWIW, some time ago I asked licens...@fsf.org about
Hi,
with regards to the recent licensing problem in qBittorrent (which is going to
be fixed upstream), I'd like to hear some comments about deluge and all clients
using libtorrent-rasterbar's python bindings, just for the sake of completeness.
The python-libtorrent package contains bi
On Thu, 26 Feb 2009 09:21:48 +1100
Ben Finney wrote:
> Jonathan Bastien-Filiatrault writes:
>
> > Ben Finney wrote:
> > > Greg Harris writes:
> >
> > [snip]
> > >
> > > But that wording is *not* what has been used
Jonathan Bastien-Filiatrault writes:
> Ben Finney wrote:
> > Greg Harris writes:
>
> [snip]
> >
> > But that wording is *not* what has been used for ‘python-imaging’.
> > Instead, the wording is:
> >
> > Permission to [foo] for any purpose and w
On Wed, Feb 25, 2009 at 04:31:10PM -0500, Jonathan Bastien-Filiatrault wrote:
> Ben Finney wrote:
>> Greg Harris writes:
>> But that wording is *not* what has been used for ‘python-imaging’.
>> Instead, the wording is:
>> Permission to [foo] for any purpos
Ben Finney wrote:
Greg Harris writes:
[snip]
But that wording is *not* what has been used for ‘python-imaging’.
Instead, the wording is:
Permission to [foo] for any purpose and without fee is hereby
granted,
I find that wording rather ambiguous, in my mind it could mean any of
ut fee,
…
But that wording is *not* what has been used for ‘python-imaging’.
Instead, the wording is:
Permission to [foo] for any purpose and without fee is hereby
granted,
which is clearly applying *both* of “for any purpose and without fee”
to “[foo]”, that is, the actions per
On Wed, 25 Feb 2009 09:43:27 +1100
Ben Finney wrote:
> Carl Fürstenberg writes:
>
> > The Python Imaging Library is
> >
> > Copyright (c) 1997-2001 by Secret Labs AB
> > Copyright (c) 1995-2001 by Fredrik Lundh
> >
> > By obtaining, usin
Carl Fürstenberg writes:
> The Python Imaging Library is
>
> Copyright (c) 1997-2001 by Secret Labs AB
> Copyright (c) 1995-2001 by Fredrik Lundh
>
> By obtaining, using, and/or copying this software and/or its
> associated documentation, you agree that you have read, u
I would like some input on the license for the package python-imaging,
which I think isn't fully in line with DFSG
; The full copyright file is as follow:
-
This package was debianized by Simon Richter on
Mon, 21 May 2001 22:
g the problem by downgrading severity.
What I am not sure of is that mixing GPL licensed code and OpenSSL
derived code prevent Python to be distributed in this form or just
programs using both pieces of code to be distributed.
--
I AM NOT A LICENSED HAIRSTYLIST
I AM NOT A LICENSED
embre 2008, vers 00:53,
> Thomas Viehmann <[EMAIL PROTECTED]> disait=A0:
>
> > Hi Vincent,
> > thanks for looking into licensing issues in Debian.
>
> > How exactly is the python license GPL-incompatible?
>
> > If you scroll down a screen or two on th
"Anthony W. Youngman" <[EMAIL PROTECTED]> writes:
> If it's external non-GPL, you can't change its licence. So *YOU* *CAN*
> mix it with both GPL and your own software.
>
> But you CAN'T then DISTRIBUTE the result. The GPL says you must
> distribute the non-GPL code as if it were GPL
Not quite:
all code in our project is non-GPLed, including some code which
makes use of external GPL library through python bindings. So,
technically speaking we are not mixing the code, and we do not
redistribute GPL code within our project (that dependency on GPLed
library is optional). But if I get it
library through python bindings. So,
technically speaking we are not mixing the code, and we do not
redistribute GPL code within our project (that dependency on GPLed
library is optional). But if I get it right -- it doesn't really matter,
since GPL doesn't allow external non-GPLed softw
In message <[EMAIL PROTECTED]>, Yaroslav
Halchenko <[EMAIL PROTECTED]> writes
Hi Guys,
I am sorry that I am following up on this dead thread I started long
ago [1], and which Francesco was kind to follow up to.
Now I've got another project to package and got the same issue, and I am
not clear i
reopen 498857
reopen 498477
thanks
OoO En cette nuit nuageuse du vendredi 19 septembre 2008, vers 00:53,
Thomas Viehmann <[EMAIL PROTECTED]> disait :
> Hi Vincent,
> thanks for looking into licensing issues in Debian.
> How exactly is the python license GPL-incompatible?
A toolbox [1], which we currently
> distribute under MIT License. It is written in Python and is actually a
> framework either to create scripts for the analysis or just perform
> analysis interactively within python (ipython) shell environment.
> Recently we decided to make use of sh
amed "the Expat license", in order to avoid
ambiguities with other licenses that are called "MIT License" as well...
> It is written in Python and is actually a
> framework either to create scripts for the analysis or just perform
> analysis interactively within python (ipy
Dear Legal People,
I am one of the developers of PyMVPA toolbox [1], which we currently
distribute under MIT License. It is written in Python and is actually a
framework either to create scripts for the analysis or just perform
analysis interactively within python (ipython) shell environment
Le lundi 25 juin 2007 à 20:17 +0200, Carlos Galisteo a écrit :
> Upstream source is released under the CNRI Python License [2] but AFAIK,
> the DFSG compliant 'Python License' is the PSF [3] one.
>
> As you can read in the PSF license full text, there's a controve
On Tue, Mar 6, 2007 at 14:19:19 +, Floris Bruynooghe wrote:
> Hello
>
> I am looking at the python-sybase software
> (http://python-sybase.sourceforge.net) and it isn't packaged yet in
> Debian. So I had a look at the licence to see if it is possible to
> packag
Hello
I am looking at the python-sybase software
(http://python-sybase.sourceforge.net) and it isn't packaged yet in
Debian. So I had a look at the licence to see if it is possible to
package. I think it is, I am however no expert at this so am asking
some advice. The licence is fairly
of the trader by whom the action is
brought or (in a quia timet action) will probably do so." -- British
Telecommunications Plc & Ors v One In A Million Ltd & Ors [1998]
EWCA Civ 1272 (23 July 1998) URL:
http://www.bailii.org/ew/cases/EWCA/Civ/1998/1272.html
> > Ho
On 01/09/07 12:19, MJ Ray wrote:
>> That's not how things work in my experience. You are responsible for
>> everything on the CD. It has nothing to do with how you label it or if
>> you advertise it as included at all.
>
> Maybe you are responsible for it, but how can strings encoded in a
> recor
es?
If they can't, then how is the trademark infringed?
That's how trademarks work, as far as I can tell. The US line on hidden
labels seems to be currently under development:
http://blog.ericgoldman.org/archives/2007/01/keyword_ads_and.htm
> Anyway, it looks like they python guys might ha
the CD. It has nothing to do with how you label it or if
you advertise it as included at all.
> If there is no infringement, why does the distributor need permission?
That python wording is really clear.
Anyway, it looks like they python guys might have fixed/changed their
position so this shou
he outside of the CD.
If that's what someone was arguing then that's crazy.
This python license change is notable. Things like this are going to
happen more and more I suspect.
It might be nice to drop a nice email to the python guys asking them
what people that sell/distribute deb
Gervase Markham wrote:
> The Python Software Foundation trademark policy[0] says the following:
>
> "# Use of the word "Python" when redistributing the Python programming
> language as part of a freely distributed application -- Allowed. If the
> standard ver
In message <[EMAIL PROTECTED]>, Gervase Markham
<[EMAIL PROTECTED]> writes
MJ Ray wrote:
If I purchase Debian CDs and type "python", or I do "man python" and
read all about the interpreter which I can invoke by typing "python"
which interprets the
he outside of the CD.
Because developers in the free software world are hoping common sense
is what is followed. Debian and Python (and mozilla) are allies here.
Infighting only helps our enemies.
Happy hacking,
Jeff
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscr
MJ Ray wrote:
Passing off is a little different, so I don't want to confuse that
with trademarks.
That's not something I know much about; a reference on the difference
would be appreciated if you have one.
How is "Python" being used by the distributor to label th
Gervase Markham <[EMAIL PROTECTED]> wrote:
> Could you really not work out what I meant?
No. I had no idea how you think the trademark is being
infringed in your example.
> The CD I have been sold by the Debian distributor uses the Python
> trademarks to label their shipped
MJ Ray wrote:
If I purchase Debian CDs and type "python", or I do "man python" and
read all about the interpreter which I can invoke by typing "python"
which interprets the Python programming language, or I install
"python-doc" and read some more, isn&#
Gervase Markham <[EMAIL PROTECTED]> wrote:
> MJ Ray wrote:
> > Well, it applies to all commercial distribution which uses the
> > Python trademark.
>
> Right. And doesn't calling some software "Python" count as "using the
> Python trademark&q
MJ Ray wrote:
Gervase Markham <[EMAIL PROTECTED]> wrote:
[...] This is a complete, standalone,
unqualified sentence, and therefore applies to all commercial
distribution, including people selling Debian CDs.
Well, it applies to all commercial distribution which uses the
Python tra
Gervase Markham <[EMAIL PROTECTED]> wrote:
> [...] This is a complete, standalone,
> unqualified sentence, and therefore applies to all commercial
> distribution, including people selling Debian CDs.
Well, it applies to all commercial distribution which uses the
Python trademar
MJ Ray wrote:
> Gervase Markham <[EMAIL PROTECTED]> wrote:
>> As I understand it, Debian uses the name Python to refer to its Python
>> implementation and the name `python' for the executable. Does this mean
>> that all commercial distributors of Debian need to
Gervase Markham <[EMAIL PROTECTED]> wrote:
> As I understand it, Debian uses the name Python to refer to its Python
> implementation and the name `python' for the executable. Does this mean
> that all commercial distributors of Debian need to get permission from
> the P
The Python Software Foundation trademark policy[0] says the following:
"# Use of the word "Python" when redistributing the Python programming
language as part of a freely distributed application -- Allowed. If the
standard version of the Python programming language is modified,
On Thu, 2006-11-23 at 13:28 +1100, Andrew Donnellan wrote:
> On 11/20/06, Adam C Powell IV <[EMAIL PROTECTED]> wrote:
>
> > Second, I may need some advice on the license:
> >
> > Copyright (c) 2001-2003, ETH Zurich and Roman Geus
> > All rights reserved.
> >
> > Redistribution and use in source an
On 11/20/06, Adam C Powell IV <[EMAIL PROTECTED]> wrote:
Second, I may need some advice on the license:
Copyright (c) 2001-2003, ETH Zurich and Roman Geus
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the follo
Joe Wreschnig <[EMAIL PROTECTED]>
> The problem is, as I said, the terms of the Python license are very
> specific to Python. Not in the way that, say, the LPPL is specific to
> LaTeX, but that the terms of the license specifically identify the PSF,
> and Python. It's like
any
concrete criticisms, I would be interested in hearing them. My goal is
to have a document to point upstreams to when I email them about their
license.
> Isn't "under the
> same terms as Python" under all current and future PSF Python licences at
> the time of writing
1 - 100 of 137 matches
Mail list logo
