-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 20 May 2009 13:42:24 +0300
Source: libsoftware-license-perl
Binary: libsoftware-license-perl
Architecture: source all
Version: 0.011-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Mon, 27 Apr 2009 09:14:53 -0300
Source: libsoftware-license-perl
Binary: libsoftware-license-perl
Architecture: source all
Version: 0.010-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain
Hi there,
I am trying to understand some license issue I am having. Could
someone let me know if the following is compatible with a debian
package:
From the [For License Of Certain Hewlett-Packard Patents Relating To
Lossless and Near-Lossless Image Compression] page (*)
The following
On Fri, Apr 24, 2009 at 3:39 PM, Mathieu Malaterre
mathieu.malate...@gmail.com wrote:
What I do not understand is implementation such as CharLS, which declare:
...
Ref: http://charls.codeplex.com/
On an unrelated note, please do not package this until upstream fixes
the security issues that
Mathieu Malaterre mathieu.malate...@gmail.com (24/04/2009):
I am trying to understand some license issue I am having. Could
someone let me know if the following is compatible with a debian
package:
You usually want -legal@ for that.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Package: wnpp
Severity: wishlist
Owner: Peter Pentchev r...@ringlet.net
* Package name: libsoftware-license-perl
Version : 0.009
Upstream Author : Ricardo Signes r...@cpan.org
* URL : http://search.cpan.org/dist/Software-License/
* License : Perl
Programming
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Millan wrote:
On Thu, Apr 09, 2009 at 10:27:19PM -0500, Adam Majer wrote:
License and copyright are one and the same.
GPL license relies on copyright law, just like almost any other open
source license there is, be it BSD, Artistic or LGPL
On Wed, Apr 15, 2009 at 08:41:08AM +0200, Giacomo Catenazzi wrote:
Maybe taking derived code (e.g. including new code), one could write only
the license of aggregate work (thus one later license),
I think so. I agree it could be better to list them explicitly, but
upstream doesn't want
On Thu, Apr 09, 2009 at 10:27:19PM -0500, Adam Majer wrote:
License and copyright are one and the same.
GPL license relies on copyright law, just like almost any other open
source license there is, be it BSD, Artistic or LGPL. Without copyright,
the license is meaningless. Without license
will assume it is. I'm fine with extra clarification, for the sake of
correctness, it just means a bit more work. I'll speak with the gnote
author about it.
and a
clear violation of Tomboy's license.
Notice license and copyright statements are two separate issues. AFAIK
LGPL doesn't explicitly
=markup
This kind of rewrite is completely permitted under Tomboy's license -
changing the copyright without the author's permission is not.
If there's a problem, we'll get it sorted out, but I need more specific
info on your findings; the example you pasted shows a file with nor
copyright
/mainline/blobs/master/src/preferencesdialog.cpp
to
http://svn.gnome.org/viewvc/tomboy/trunk/Tomboy/PreferencesDialog.cs?revision=2349view=markup
This kind of rewrite is completely permitted under Tomboy's license -
changing the copyright without the author's permission
On Wed, Apr 08, 2009 at 08:30:30PM +0100, Jo Shields wrote:
If there's a problem, we'll get it sorted out, but I need more specific
info on your findings; the example you pasted shows a file with nor
copyright statement neither license information (from tomboy) and one
with both
*PRESS RELEASE
**
http://tinyurl.com/cloudleft
Major Vendors and FSF Announce Instigation of Cloud Alliance and New Open
Source License
*
CLOUD 9, THE CLOUD®, April 1 2009 (CCT): Today, major cloud vendors, in
conjunction with the Free Software Foundation (FSF), announced the imminent
creation
Le Tue, Oct 21, 2008 at 12:56:43PM -0500, Manoj Srivastava a écrit :
Where do I record the fact that any contribution I have made to the
web site or the wiki may be licensed under the GPL?
How about http://wiki.debian.org/ManojSrivastava ?
Have a nice day,
--
CharlesPlessy
--
To
/ManojSrivastava ?
Have a nice day,
Please, don't encourage people to put individual license on their
homepage, or any wiki page.
1. This make it impractical to merge pages.
2. This will cause multiple licenses to show up.
3. I don't think GPL is a good choice for documentation, especially
in stable suddenly became a wishlist bug. We don't want that!
Good point: severity is not versionned.
By the way (and not answering to the rest of your mail, sorry), I just
realised that some package have a more restrictive license for the
packaging than for the packaged content (typically GPL vs BSD
a proposal; common-licenses exists today.
(2) I didn't grasp from the proposal whether the fully license text
must appear in the copyright file (or in common-licenses). If we can
simply put License: GPL-1+ | Artistic for a perl module, then I'm
happy. If we have to put that PLUS the prose of the Perl
.
However:
(1) This is only a proposal; common-licenses exists today.
Yes, but it's not really a good labelling solution, IMO.
(2) I didn't grasp from the proposal whether the fully license text
must appear in the copyright file (or in common-licenses). If we can
simply put License: GPL-1
On Tue, July 3, 2007 4:06 pm, Paul Cager wrote:
On Tue, July 3, 2007 8:38 am, Andreas Barth wrote:
Explain it in debian/copyright, that's the proper place (the source
files don't actually need license statement, even though of course it
helps transparence and is therefore encouraged).
I
Paul Cager [EMAIL PROTECTED] writes:
But Ben Finney said:
No, there needs to be an explicit grant of license explaining what
terms apply, and exactly which files comprise the work being licensed.
I'm not sure I understand; would a COPYING file stating this project
is licensed under
* Russ Allbery [EMAIL PROTECTED] [070706 17:46]:
I'm not sure I understand; would a COPYING file stating this project
is licensed under... be acceptable?
In practice, there's so much software out there that just provides a
license in the README file and no separate notices in each file
* Paul Cager ([EMAIL PROTECTED]) [070702 23:04]:
I'm packaging a couple of Java libraries where the source files do not
have any license declarations. This is being fixed in upstream's svn
repository.
I still want to package upstream's latest *release* rather than the head
of svn, so
On Tue, July 3, 2007 8:38 am, Andreas Barth wrote:
Explain it in debian/copyright, that's the proper place (the source
files don't actually need license statement, even though of course it
helps transparence and is therefore encouraged).
I didn't realise that. I had assumed that each source
On Tue, 3 Jul 2007 16:06:11 +0100 (BST)
Paul Cager [EMAIL PROTECTED] wrote:
On Tue, July 3, 2007 8:38 am, Andreas Barth wrote:
Explain it in debian/copyright, that's the proper place (the source
files don't actually need license statement, even though of course it
helps transparence
On Tue, Jul 03, 2007 at 04:06:11PM +0100, Paul Cager wrote:
On Tue, July 3, 2007 8:38 am, Andreas Barth wrote:
Explain it in debian/copyright, that's the proper place (the source
files don't actually need license statement, even though of course it
helps transparence and is therefore
Paul Cager [EMAIL PROTECTED] writes:
On Tue, July 3, 2007 8:38 am, Andreas Barth wrote:
Explain it in debian/copyright, that's the proper place (the
source files don't actually need license statement, even though of
course it helps transparence and is therefore encouraged).
I didn't
I'm packaging a couple of Java libraries where the source files do not
have any license declarations. This is being fixed in upstream's svn
repository.
I still want to package upstream's latest *release* rather than the head
of svn, so is it OK just to explain the situation in
README.Debian
On Mon, Jul 02, 2007 at 09:23:38PM +0100, Paul Cager wrote:
I'm packaging a couple of Java libraries where the source files do not
have any license declarations. This is being fixed in upstream's svn
repository.
I still want to package upstream's latest *release* rather than the head
of svn
On Mon, Jun 04, 2007 at 11:08:39PM +0200, Frank K?ster wrote:
Anthony Towns [EMAIL PROTECTED] wrote:
See, given that as an ftpmaster I'm one of the folks who actually
implements the policy on what's accepted into main or not, it's not my
loss at all.
I think that Debian would very much
Anthony Towns [EMAIL PROTECTED] wrote:
On Mon, Jun 04, 2007 at 11:08:39PM +0200, Frank K?ster wrote:
I think that Debian would very much benefit if there was a place (call
it [EMAIL PROTECTED] or whatever) where our policy with regard to
individual software's licenes could be discussed with
Am Dienstag, 5. Juni 2007 09:08:31 schrieb Frank Küster:
Anthony Towns [EMAIL PROTECTED] wrote:
On Mon, Jun 04, 2007 at 11:08:39PM +0200, Frank K?ster wrote:
And a mail like
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350624;msg=142;att=0
is not only not-helpful-at-all, it's really
Thomas Weber [EMAIL PROTECTED] wrote:
Am Dienstag, 5. Juni 2007 09:08:31 schrieb Frank Küster:
Anthony Towns [EMAIL PROTECTED] wrote:
On Mon, Jun 04, 2007 at 11:08:39PM +0200, Frank K?ster wrote:
And a mail like
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350624;msg=142;att=0
is not
to with a conclusion of the
form this license is flawed in these novel ways, but none of them are
enough to make it non-free for Debian.
Cheers,
aj
signature.asc
Description: Digital signature
license, explicitly limit when
choice of venue comes into play)
* Different people and organisations may reasonably have different
views on the acceptability of various effects -- the FSF view
the Affero GPL and GFDL as free, OSI views the APSL as free
Am Dienstag, 5. Juni 2007 14:20:40 schrieb Anthony Towns:
On Tue, Jun 05, 2007 at 12:07:52PM +0200, Frank K?ster wrote:
You could ask Anthony whether you're allowed to publish his reasons on
-legal. That would do the project a great favor.
You could just ask me directly you know...
As my
Thomas Weber [EMAIL PROTECTED] wrote:
Am Dienstag, 5. Juni 2007 14:20:40 schrieb Anthony Towns:
On Tue, Jun 05, 2007 at 12:07:52PM +0200, Frank K?ster wrote:
You could ask Anthony whether you're allowed to publish his reasons on
-legal. That would do the project a great favor.
You could
On Tue, Jun 05, 2007 at 10:20:40PM +1000, Anthony Towns wrote:
] I thought choice-of-venue is non-free by default?
An example of a different MPL 1.1 derived choice-of-venue clause is
firebird2's:
This License shall be governed by California law provisions (except to
the extent
On Wed, Jun 6, 2007 at 06:07:46 +1000, Anthony Towns wrote:
Perhaps a more interesting example is xserver-xorg-core's inclusion of the
GLX Public License, which includes:
Any litigation relating to this License shall be subject to the
exclusive jurisdiction of the Federal Courts
Anthony Towns [EMAIL PROTECTED] wrote:
See, given that as an ftpmaster I'm one of the folks who actually
implements the policy on what's accepted into main or not, it's not my
loss at all.
I think that Debian would very much benefit if there was a place (call
it [EMAIL PROTECTED] or whatever)
Le lundi 04 juin 2007 à 23:08 +0200, Frank Küster a écrit :
I think that Debian would very much benefit if there was a place (call
it [EMAIL PROTECTED] or whatever) where our policy with regard to
individual software's licenes could be discussed with the input of those
who actually set this
license ( http://creativecommons.org/licenses/by/3.0/ ).
As I understand, CC-by 3.0 is DFSG-free. The only potentially DFSG-freeness
problem I can see is the DRM limitation, and then again GNU FDL also has it
and is perfectly DFSG according to the last GR about it.
Anyway, I prefer to ask about
On May 31, Miriam Ruiz [EMAIL PROTECTED] wrote:
Anyway, I prefer to ask about it first: Does anyone know if CC-by 3.0 is
DFSG-free or not for sure, shall I go ahead and put it in the repositories?
The ftpmasters do.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Thu, 31 May 2007 18:47:37 +0200 Miriam Ruiz wrote:
Hi,
I plan to file an ITP and package a cute small game
[...]
All the game code is licensed under the GPL 2.0.
Good.
All the game content,
sounds and graphics are licensed under Creative Commons 3.0
Attribution license ( http
[Simon Josefsson]
Do you have suggestions to improve the situation?
I would suspect manual inspection of each file, and only file bugs for
the files with real license problems. Using the file name to guess
about the existence of a serious bug is not acceptable.
How many bugs did you file
Petter Reinholdtsen [EMAIL PROTECTED] writes:
[Simon Josefsson]
Do you have suggestions to improve the situation?
I would suspect manual inspection of each file, and only file bugs for
the files with real license problems. Using the file name to guess
about the existence of a serious bug
positive, in the quagga (bug
#393411) package. It isn't clear if the file draft-zebra-00.txt is
from IETF or not, and has no standard copyright notice nor license.
It has the same boilerplate and look as an IETF draft, but the
reference to IETF have been removed. Most likely, this was a false
licenses that meet
our standard of Freedom, this is the time to act. Please, if you haven't
already, take a few minutes to send an email message to the Creative
Commons public review mailing list [6] letting CC know that you support
a Debian-compatible version of the license. I want a Debian
] letting CC know that you support
a Debian-compatible version of the license. I want a Debian-compatible
Creative Commons license, signed John Q. Hacker is probably plenty.
It seems too many have tried this. I just got this answer:
You are not allowed to post to this mailing list, and your
(images,
video, sounds, documentation, help text) can be part of the Debian
operating system. [4]
We reached some good conclusions, which resulted in the current Creative
Commons 3.0 license but unfortunately some of the people in the
Creative Commons community -- a diverse one, just like Debian's
[6] letting CC know that you support
a Debian-compatible version of the license. I want a Debian-compatible
Creative Commons license, signed John Q. Hacker is probably plenty.
I'd very much like to see this happen, but I feel kind of
uncomfortable sending an AOL to a list I'm not subscribed
On Mon, Oct 02, 2006 at 06:00:02PM -0400, Eric Dorland wrote:
Maybe some sort of signature collection would make more sense, then
send batches in a single email to the list. Seems more polite that
way.
Totally agreed, I was going to write exactly the same reply.
Evan: what about setting up a
, if you haven't
already, take a few minutes to send an email message to the Creative
Commons public review mailing list [6] letting CC know that you support
a Debian-compatible version of the license. I want a Debian-compatible
Creative Commons license, signed John Q. Hacker is probably plenty
On Mon, 2006-10-02 at 18:00 -0400, Eric Dorland wrote:
I'd very much like to see this happen, but I feel kind of
uncomfortable sending an AOL to a list I'm not subscribed to and a
discussion I haven't participated in. Maybe some sort of signature
collection would make more sense, then send
, modify and distribute without charge this
software,
Doesn't the 'without charge' bit violate DFSG #1?
It is confusing for sure. But the intent of the author was probably to
be a shorter funny version of MIT license.
If it is meant as it is written, yes. Often sentences like this can
also
Kevin B. McCarty [EMAIL PROTECTED] wrote:
Any chance you could also post the list of those with Build-Depends or
Build-Depends-Indep on these packages?
Of course, sorry for forgetting this in the first place. Here's the
list. And again the question: Is there a script to mass-mail to all
Summary:
We will probably have to remove files from teTeX due to license
problems: Please check whether your package is affected!
Hi,
in the past I have started to do a license auditing on teTeX. I found a
couple of files with non-free or unclear licensing, they are listed at
http
Frank Küster [EMAIL PROTECTED] wrote:
Summary:
We will probably have to remove files from teTeX due to license
problems: Please check whether your package is affected!
... and tell us.
Note that we have tried to contact as many upstream authors as possible,
and we will probably not need
Frank Küster wrote:
We will probably have to remove files from teTeX due to license
problems: Please check whether your package is affected!
[...]
Below is a list of all
packages that Depend on, Recommend, or Suggest either tetex-base,
tetex-bin or tetex-extra, sorted by maintainer.
Any
Hi,
I found this problem in vim's English manual when I tried[1] to package
the Chinese translation of vim documents. To know the problem, just
type :help manual-copyright in vim editor. It clearly states that the
Vim user manual and reference manual are using Open Publication License,
v1.0
[ quoted text reordered ]
On Mon, Aug 21, 2006 at 08:15:38PM +1200, Carlos Z.F. Liu wrote:
In my point of view, the OPL license make the vim manual non-free. It
shouldn't be put in main as part of vim-runtime package.
Some procedural comments. Please file a bug about that against
vim-runtime
the maintainers' mailing list (Cc-ed with this message).
thanks, done, http://bugs.debian.org/384019
They use OPL because some parts of the manual are come from the book
Vi IMproved - Vim by Steve Oualline. The Open Publication License
applies to this book.
Are you sure this is the reason why
manual are using Open Publication License,
v1.0 or later which is considered[2] as DFSG-incompatible. They use
I do not think that this is obvious. The objections reported in the
message you cited do not appear to be clearly justified by the DFSG
(when they are not totally bogus, as in the reference
precedent for such clauses in the Artistic license.
OpenContent License (OPL)
Version 1.0, July 14, 1998.
This document outlines the principles underlying the OpenContent (OC)
movement and may be redistributed provided it remains unaltered. For
legal purposes, this document
the Open Publication License (the same license
used by Steve Oualline for his Vim book) yet the URL is for the Open
Content License. Both license texts use the OPL acronym, which may be
the cause of the confusion.
There's an open bug against Vim (#384019). I'll bring up the
inconsistency with Bram
[EMAIL PROTECTED] (Karl Berry) wrote:
Sigh.
Oh, well. There are more intersting things in the world to care about.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Frank Küster [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Karl Berry) wrote:
Sigh.
Oh, well. There are more intersting things in the world to care about.
Sorry, this was a mistake, a funny effect of my mail setup.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein
Hello Jari,
AFAIK is this already done with debtags.
Greetings
Michelle Konzack
Systemadministrator
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack Apt. 917
Am 2006-02-21 02:45:12, schrieb Kevin Mark:
Hi,
would it provide any automation or easier processing for the NEW
queue(ftpmasters)? would it allow for reducing package size by removing
license text from all packages and having them installed in a seperate
essential package stored
[Kevin Mark]
would it provide any automation or easier processing for the NEW
queue(ftpmasters)?
I doubt it. They don't take the maintainer's word for stuff like that,
as I understand it - they double-check the copyright and license
declarations in the source code.
would it allow
and license
declarations in the source code.
You mean they check ever single time $RANDOM_PACKAGE enter NEW and don't
assume its correct until someone raises an objections? I'd at least
think you could create a sub-queue in NEW so that already tagged
standard licenses would get processed faster
that,
as I understand it - they double-check the copyright and license
declarations in the source code.
You mean they check ever single time $RANDOM_PACKAGE enter NEW and don't
assume its correct until someone raises an objections?
Yes. Legal compliance is /not/ tractable in the same way
On Tue, Feb 21, 2006 at 02:45:12AM -0500, Kevin Mark wrote:
On Mon, Feb 20, 2006 at 11:12:46PM -0800, Russ Allbery wrote:
[License field]
In other words, it seems like a lot of work, and it's not clear what
problem it would really solve.
Hi,
would it provide any automation or easier
Note that there was a discussion using debtags for license information
on debtags-devel/debian-legal.
http://lists.debian.org/debian-legal/2005/06/msg00016.html
is a good starting point.
Personally I believe, that if such an information should be available,
debtags is more suitable to express
On 10572 March 1977, Jari Aalto wrote:
To my understanding the only way to obtain the license information
for a package is to actually download it (or install it) and the
study the content of
/usr/share/doc/package/copyright
Yes.
Add new field to the debian/control (which would
On 10572 March 1977, Kevin Mark wrote:
would it provide any automation or easier processing for the NEW
queue(ftpmasters)?
Nope.
--
bye Joerg
Naturally; worms that don't know what they are doing end up as
fish bait, instead of getting invited into weird math experiments.
--
that it is neccessary.
If we wouldnt check the packages we would have stuff in debian that
contains statements like YOU ARE NOT ALLOWED TO GIVE THAT CODE TO
ANYONE, has license incompatibilities, talks about legal actions
against you if you modify code, etc. pp.
--
bye Joerg
HE liw: Ah, but now I'm old
be in a
location to allow for special license processing.
Well, de facto a package that only has a soname bump will likely not be
license-reexamined.
For truly new packages, though, there is no way to get around a thorough
examination by someone paying careful attention and the ftpmasters are
really doing
/copyright
files (more than for technical reasons) shows that it is neccessary.
If we wouldnt check the packages we would have stuff in debian that
contains statements like YOU ARE NOT ALLOWED TO GIVE THAT CODE TO
ANYONE, has license incompatibilities, talks about legal actions
against you
standard licenses would get processed faster and others would be in a
location to allow for special license processing.
Well, de facto a package that only has a soname bump will likely not be
license-reexamined.
For truly new packages, though, there is no way to get around a thorough
On 10572 March 1977, Kevin Mark wrote:
I understand the general idea of a DFSG-free license but, for example,
if Clint uploads yet another zsh package bugfix, I'm not expecting him to have
it under a different license then the last 99 uploads. And if there was
a license change, you could
think you could create a sub-queue in NEW so that already tagged
standard licenses would get processed faster and others would be in a
location to allow for special license processing.
Well, de facto a package that only has a soname bump will likely not be
license-reexamined.
For truly new
On Tue, Feb 21, 2006 at 11:01:07AM +0100, Joerg Jaspert wrote:
On 10572 March 1977, Kevin Mark wrote:
I understand the general idea of a DFSG-free license but, for example,
if Clint uploads yet another zsh package bugfix, I'm not expecting him to
have
it under a different license
which warrants such attention, but the upload for bug
fixes and new upstream. If someone uploads Bash, its a pretty safe bet
that the license is not going to change but if it did, all that would be
required is to change this 'tag' and then have an automated check
compare 'tag' with 'oldtag
am not refering to the initial upload of a
brand-new package which warrants such attention, but the upload for bug
fixes and new upstream. If someone uploads Bash, its a pretty safe bet
that the license is not going to change but if it did, all that would be
required is to change
On Tue, 2006-02-21 at 02:45 -0500, Kevin Mark wrote:
would it provide any automation or easier processing for the NEW
queue(ftpmasters)?
I'd assume part of the FTP masters checking is actually verifying the
license specified in debian/copyright is the license actually used by
the source
On Tue, Feb 21, 2006 at 08:34:22AM +, Ross Burton wrote:
On Tue, 2006-02-21 at 02:45 -0500, Kevin Mark wrote:
would it provide any automation or easier processing for the NEW
queue(ftpmasters)?
I'd assume part of the FTP masters checking is actually verifying the
license specified
cases). I understand the
initial upload needing attention but the subsequent uploads should not
need license checking unless this 'tag' value was changed.
Packages get in NEW when
- they are completly new for the archive,
- or they have a new binary package in them.
Not if they only have a new
To my understanding the only way to obtain the license information
for a package is to actually download it (or install it) and the
study the content of
/usr/share/doc/package/copyright
It would be better if user could use the packaging search commands,
like
grep-dctrl -F License
Jari Aalto [EMAIL PROTECTED] writes:
To my understanding the only way to obtain the license information for a
package is to actually download it (or install it) and the study the
content of
/usr/share/doc/package/copyright
It would be better if user could use the packaging search
* Jari Aalto [EMAIL PROTECTED] [2006-02-21 08:01]:
To my understanding the only way to obtain the license information
for a package is to actually download it (or install it) and the
study the content of
/usr/share/doc/package/copyright
That information can also be obtained from
On Mon, Feb 20, 2006 at 11:12:46PM -0800, Russ Allbery wrote:
Jari Aalto [EMAIL PROTECTED] writes:
To my understanding the only way to obtain the license information for a
package is to actually download it (or install it) and the study the
content of
/usr/share/doc/package
Daniel Ruoso [EMAIL PROTECTED] writes:
Em Sáb, 2006-02-11 às 13:46 -0500, Nathanael Nerode escreveu:
I have one single question... Does copyright law even applies to legal
agreements and license terms? I'm pretty sure noone can be sued for
using the terms someone used earlier, or even
Stuart Yeates [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
In the USA copyright can be enforced even on laws:
http://www.constructionweblinks.com/Resources/Industry_Reports__Newsletters/May_17_2004/supreme.html
I'm assuming that the legislation in question included the codes
Em Sáb, 2006-02-11 às 13:46 -0500, Nathanael Nerode escreveu:
The problem is quite specifically that we have unmodifiable license
texts, not unmodifiable license terms. These texts are in Debian,
making it technically untrue that Debian will remain 100% free.
I have one single question... Does
In message [EMAIL PROTECTED] Daniel Ruoso [EMAIL PROTECTED] writes:
Em Sáb, 2006-02-11 às 13:46 -0500, Nathanael Nerode escreveu:
The problem is quite specifically that we have unmodifiable license
texts, not unmodifiable license terms. These texts are in Debian,
making it technically
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Ruoso wrote:
Em Sáb, 2006-02-11 às 13:46 -0500, Nathanael Nerode escreveu:
I have one single question... Does copyright law even applies to legal
agreements and license terms? I'm pretty sure noone can be sued for
using the terms someone
also sprach José Carlos do Nascimento Medeiros [EMAIL PROTECTED]
[2006.02.06.1746 +0100]:
I have a package (php-netcheckip) that was MIT licensed.
Debian suports this license ?
Yes. http://wiki.debian.org/DFSGLicenses
--
Please do not send copies of list mail to me; I read the list
Hi,,
I have a package (php-netcheckip) that was MIT licensed.
Debian suports this license ?
-
The MIT License
Copyright (c) year copyright holders
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files
Instead I propose that all RC bugs in PHP Group software released with
the PHP License be closed.
For the record, all previous discussions of this matter on debian-legal
have suggested that the PHP License might be non-free for everything
(including PHP), but it has never been argueed that PHP
601 - 700 of 1064 matches
Mail list logo
