On Fri, Sep 08, 2000 at 12:28:54AM +0200, Gregor Hoffleit wrote:
Indeed. A dependency may also mean that the package is a binary extension
module for the Python interpreter which will be linked dynamically with the
interpreter (at some time, when the module is imported).
In this case, if
Gregor == Gregor Hoffleit [EMAIL PROTECTED] writes:
[...]
Gregor 1) Ignore Python 1.6 and up, as long as the license is not
compatible
Gregorwith the GPL. That's probably the easiest way to go, but is it
Gregorjustified ? Looks like a deliberate discrimination against a
On Thu, Sep 07, 2000 at 10:47:01AM -0700, Joey Hess wrote:
I don't see us making this kind of check for code written in perl, or
code wirtten in C, or any other language.
Perl is available under two licenses: GPL + Artistic. Not much room
for a reasonable person to introduce conflict there.
C
On Thu, Sep 07, 2000 at 10:47:01AM -0700, Joey Hess wrote:
Gregor Hoffleit wrote:
Still, if 1.6 were to replace 1.5.2, we had to check all packages that
depend on Python, if we think their license is still compatible with the
new Python license, and remove them if it's not. I'd opt
Someone wrote this:
I am disappointed that RMS is fighting over something as trivial as a
company asking that legal issues be settled in their home state
(country). This is common practice.
I am not fighting, I am pointing out the situation as it exists. I
don't believe the CNRI
On Wed, Sep 06, 2000 at 11:37:17AM -0700, Sean 'Shaleh' Perry wrote:
1) Ignore Python 1.6 and up, as long as the license is not compatible
with the GPL. That's probably the easiest way to go, but is it
justified ? Looks like a deliberate discrimination against a
DFSG-free license,
On Wed, Sep 06, 2000 at 11:37:17AM -0700, Sean 'Shaleh' Perry wrote:
I think that we are going to see more and more cases of GPL
incompatibilities
as time goes on.
Agreed; although market forces are driving many software development houses
towards Open Source, they're still trying to squirm
On Wed, Sep 06, 2000 at 10:49:20PM +0400, Alexey Vyskubov wrote:
Pyhton 2.0 is released already. And it doesn't seems that 2.0 solve the
license incompatibility...
It's not a stable release.
bye
Christian
--
Christian Surchi | [EMAIL PROTECTED] | [EMAIL PROTECTED]
FLUG:
On Wed, Sep 06, 2000 at 09:50:07PM -0500, Branden Robinson wrote:
On Wed, Sep 06, 2000 at 11:37:17AM -0700, Sean 'Shaleh' Perry wrote:
I am disappointed that RMS is fighting over something as trivial as a
company asking that legal issues be settled in their home state
(country). This is
Gregor Hoffleit wrote:
Still, if 1.6 were to replace 1.5.2, we had to check all packages that
depend on Python, if we think their license is still compatible with the
new Python license, and remove them if it's not. I'd opt against this.
Hm, I'm confused. Are you saying that you think that
Python 1.6 was released finally today (for an announcement, see
http://www.python.org/1.6/), and it was released under the discussed
CNRI license. This license was intended to be compatible with the GPL,
but RMS says he thinks it's not (cf. the announcement).
Moments later, Guido and BeOpen's
On Wed, Sep 06, 2000 at 11:43:21AM +0200, Gregor Hoffleit wrote:
Still, if 1.6 were to replace 1.5.2, we had to check all packages that
depend on Python, if we think their license is still compatible with the
new Python license, and remove them if it's not. I'd opt against this.
Yup, that
Gregor Hoffleit [EMAIL PROTECTED] writes:
Python 1.6 was released finally today (for an announcement, see
http://www.python.org/1.6/), and it was released under the
discussed CNRI license. This license was intended to be
compatible with the GPL, but RMS says he thinks it's not
1) Ignore Python 1.6 and up, as long as the license is not compatible
with the GPL. That's probably the easiest way to go, but is it
justified ? Looks like a deliberate discrimination against a
DFSG-free license, only because it's not GPL compatible.
2) Include both Python 1.5.2
Python 1.5 I wouldn't put two Python versions into Debian. Also Python
2.0 will probably be released before the next code freeze and solve
the license issues.
Pyhton 2.0 is released already. And it doesn't seems that 2.0 solve the
license incompatibility...
Am I wrong? I hope I am... :(
--
15 matches
Mail list logo