(Please Cc me on replies.)
On Feb 16, Paul Wise wrote:
> > And they are arguing that people cannot download this file from
> > a well-known location without first agreeing to some conditions.
> Do you have any info on the conditions?
Here they are:
https://www.arin.net/resources/rpki/tal.html
ARIN believes that they have a right to limit distribution of this RSA
public key (used for verification of routing security):
https://www.arin.net/resources/rpki/arin-rfc7730.tal
(This is basically an X.509 subjectPublicKeyInfo, which can be parsed
with openssl asn1parse.)
And they are
On Jun 07, Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote:
- We do have the source code for generating it (preferred form of
modification).
- We can build it, but it requires lot of work... and avoid FTBFSs while
bootstrapping ;)
So, could we accept pre-generated
On Dec 30, Sven Hoexter s...@timegate.de wrote:
due to demand by a coworker I've taken #625611 and started to prepare
a package for the exFAT fuse driver and the utils package.
Debian, as policy, ignores patents which are not being actively and
widely enforced.
So feel free to upload.
--
fab...@greffrath.com wrote:
If I could find a way to recreate the disk image from the precompiled
FreeDOS binaries and would ship them and their corresponding sources in
the Debian source package (although they are not used to recompile the
binaries at build time), would you think this package
mdpo...@troilus.org wrote:
The usual argument is that choice of venue violates DFSG #5 by
discriminating against people who live outside the venue. Is there some
The usual argument of the DFSG revisionists is that everything is a
restriction or a discrimination, so it's not really helpful.
--
nicolas.alva...@gmail.com wrote:
How about we try this? Let's assume for a moment that choice-of-venue is
both acceptable and allowed by the DFSG. Then look at the *rest* of the
cal.h license terms instead of continuing the argument about this one.
As explained, the license does not really
On Aug 26, Giacomo A. Catenazzi c...@debian.org wrote:
5) We create a new free database.
I don't think is too difficult, and I think we would have support
Sure, a database which can associate an IP address with a country 90% of
the time will be easy to create and if widely used in a few years
tmanc...@debian.org wrote:
We've requested that the upstream author release a new upstream version
with the updated license, and are waiting for his reply. But I wanted
to ask the list if that is strictly necessary, given that we know the
contents of the files, save for the license, haven't
On Apr 10, brian m. carlson sand...@crustytoothpaste.ath.cx wrote:
I don't know about you, but I'd much prefer to modify any sort of
program, firmware or not, using C or assembly rather than editing the
binary directly. I suspect that this is the case for any reasonable
programmer. Thus, we
f...@firenze.linux.it wrote:
Nobody seemed to disagree with this conclusion.
Please do not mistake lack of interest in your ramblings with consensus.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
t...@thomas-harding.name wrote:
Anyway, as the content have slightly changed, you'll find the thread in
debian-legal:
You should not trust everything you read on debian-legal.
* To upload a background source package, is it mandatory to use
an uncompressed format, such as tiff, for
[EMAIL PROTECTED] wrote:
- the release manager (and probably the security team as well) must be
comfortable with the result
And the package should state *which* tool is required to rebuild the
package. 8-/
This is why I mentioned the last condition, the build process should be
fully automatic
[EMAIL PROTECTED] wrote:
Must packages in main derive the contents of binary packages from the
sources shipped in the source package, or can they simply copy
pre-generated, not directly editable files which have been derived
using some other process (not available in the package sources)?
I
[EMAIL PROTECTED] wrote:
Not all restrictions are bad and unfree (except for the morons who argue
here from time to time that the GPL may not actually be DFSG-free).
There's no need to be rude or to insult [1] anyone just because they
don't share your point of view. It doesn't help to support
[EMAIL PROTECTED] wrote:
In the case of point #3 that you're making here, are you saying that
the AGPLv3 fails the dissident test?
Yes, I'm saying that it might be failing it. If you use a program
Not that this matters, since this test is not part of the DFSG.
--
ciao,
Marco
--
To
[EMAIL PROTECTED] wrote:
Miriam Ruiz writes (Is AGPLv3 DFSG-free?):
Do you think AGPLv3 is DFSG-free?
Yes. The source-transmission requirement is hardly onerous, and there
is an important class of sitations where that extra restriction is
very important to stop someone making the code
[EMAIL PROTECTED] wrote:
In the case of point #3 that you're making here, are you saying that
the AGPLv3 fails the dissident test?
Yes, I'm saying that it might be failing it. If you use a program
Not that this matters, since this test is not part of the DFSG.
It's an old discussion. It may
[EMAIL PROTECTED] wrote:
Some packages (notably compilers) avoid cyclic build dependencies by
shipping some sort of pre-compiled blob in the source package. This
blob is then used to compile the package.
Does this fullfil the requirement that packages in main must be built
from source
[EMAIL PROTECTED] wrote:
As far as I know, currently there is no easy way to edit those game
data. So beneath-a-steel-sky, flight-of-the-amazon-queen, and
lure-of-the-temptress should be in non-free segment.
Another great victory for free software.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to
[EMAIL PROTECTED] wrote:
On Tue, Feb 26, 2008 at 02:29:05PM -0800, Eitan Isaacson wrote:
3. The translation tables that are read at run-time are considered
part of this code and are under the terms of the GPL. Any changes to
these tables and any additional tables that are created for use by
[EMAIL PROTECTED] wrote:
I've contacted the upstream author (CCed), and he said [1] that he would have
put it under GPL (which is, indeed, DFSG-free) and that this was stated on the
project's homepage [2]. Is that sufficient? Or should he make a new release
with that header changed accordingly?
[EMAIL PROTECTED] wrote:
Is the somewhat unconventional copyright notice in TinyMCE's source a
problem at all? I think Moxiecode's intent to release this as free
software is clear, although their lawyers seem to have muddled things
a little. :-)
While a clarification would not hurt, the intent is
[EMAIL PROTECTED] wrote:
Perhaps I haven't been subscribed long enough or something, but I've
found the exact opposite. Certainly the feedback that I've got has
been tough and debatory. But it's also been prompt. It's been polite.
It's been terse and informative, and all emails I've received so
[EMAIL PROTECTED] wrote:
You are missing the point: some printers may or may not work, but the
program itself still has the same capabilities and is not influenced by
what getweb does.
that's why it is ok for most of the program to be in main. its just getweb
that depends on non-free data.
[EMAIL PROTECTED] wrote:
No, it's a very different case since here we have a large free
self-contained free software program which works without any non-free
dependencies, whose package also contains an additional little script
which downloads and copies to an external device some file.
[EMAIL PROTECTED] wrote:
Paragraph 2.2.2 probably resolves any ambiguity here:
No, it's about a different situation.
Examples of packages which would be included in contrib are [...]
free packages which require contrib, non-free packages or *packages
which are not in our archive at all* for
On Nov 10, Michael Gilbert [EMAIL PROTECTED] wrote:
the maintainer does not believe this to be an issue [1] because the
firmware fetching stuff is a small part of the total package. i
The maintainer is correct.
suggested that he could split out the firmware fetching stuff into a
contrib
[EMAIL PROTECTED] wrote:
Is this intentionally left out? If yes, why?
Patent issues were not very important when the DFSG was written.
Is there a consensus in the debian community about how to deal with
Software Patents and the inclusion of software into the debian
archive? If yes, is this
[EMAIL PROTECTED] wrote:
You may not impose any effective technological measures on the Work
that restrict the ability of a recipient of the Work from You to
exercise the rights granted to that recipient under the terms of the
License.
There seem to be consensus that as long as there is no
[EMAIL PROTECTED] wrote:
Yes, but if there is only one existing database in this format, I don't
think that changes much. It would be pretty much like a program
requiring a GPL library to work properly, but that would dlopen() it at
startup.
The criteria is still the derived work one. Not are
[EMAIL PROTECTED] wrote:
This is a very common situation. Most people crating works of
authorship find copyright to be a huge hassle to even think about
(because it is). Those who do think about it will usually take
whatever appears to be the path of least resistance -- such as tossing
in a
[EMAIL PROTECTED] wrote:
If the program cannot work without the database, that makes it a derived
work.
Not true:
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
[EMAIL PROTECTED] wrote:
Well this is not too helpful. I would wish that licenses that are
acceptable are all officially listed somewhere (here?
With very good approximation, you can be sure that packages in main have
acceptable licenses, and work from this knowledge.
So this means, MPL, CPL ==
[EMAIL PROTECTED] wrote:
I disagree that this can be a good approximation, since assuming it is
would imply that DFSG-compliance bugs (almost) never happen.
Indeed, they do not.
One example is all the GFDL-ed stuff that got approved before realizing
that it does not comply with the DFSG.
No,
[EMAIL PROTECTED] wrote:
Is my view correct? I can use the CC-BY-ed database for my GPL-ed
program, right?
Apparently yes. Anyway, the correct criteria is not linking but being
a derived work. This case looks like mere aggregation.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL
On Sep 02, Shriramana Sharma [EMAIL PROTECTED] wrote:
It's not mere aggregation. Mere aggregation is when GPL licensed Qt and
Boost-licensed Boost are put on a single distribution medium. Qt does
nothing to Boost and Boost does nothing to Qt. Here the program actually
*uses* the database.
On Sep 02, Shriramana Sharma [EMAIL PROTECTED] wrote:
Maybe you should explain better what the program is and how it works.
It's a program related to astronomy that requires latitude, longitude and
elevation of places to calculate sunrise, sunset etc. For that I found the
database from
[EMAIL PROTECTED] wrote:
the recent discussion about 'Firebird being in main' caused even more
confusion on my side, as the sites [1], [2] (which I consider the
debian-official statement wrt. which license is DFSG compliant) do not
list the MPL as a DFSG conform license but as DFSG-incompatible
[EMAIL PROTECTED] wrote:
Could someone explain to me why firebird is in main?
Because the ftpmasters reviewed it and accepted it.
It is my opinion that the MPL license fails to meet the DFSG.
It is my opinion that the MPL license meets the DFSG. So what?
This opinion seems to be shared by other
[EMAIL PROTECTED] wrote:
to OpenSSL, and I believe the QPL is widely considered non-free.
Your belief is not correct.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
(Incidentally, what part of the DFSG is the Dissident test supposed to
help test against?)
The imaginary clause.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Jun 02, Michael Poole [EMAIL PROTECTED] wrote:
A blatant appeal to authority in place of facts or analysis isn't
particularly useful information, and is even less so when arguments
for the contrary position have been made but not answered.
s/arguments/opinions/
--
ciao,
Marco
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
[EMAIL PROTECTED] wrote:
I remember reading that the GFDL is not DFSG-free (due to some clauses
regarding invariant sections or something) so I would like to know what
As long as you do not use these optional clauses it is free like any
other DFSG license.
OTOH, you should ask yourself what is
[EMAIL PROTECTED] wrote:
The troublesome clause in the copyright licence is probably
3) You may not charge a fee for the game itself. This includes reselling the
game as an individual item.
Does this get into debian because the above is a trivially-avoidable
restriction with a Hello World, or
On May 24, Don Armstrong [EMAIL PROTECTED] wrote:
This is not the case, unfortunatly, and it really would be wise in the
future to consult with people who are familiar with the arguments
surrounding such licenses before expressing Debian's opinion to the
FSF.
Do you mean the ftpmasters, don't
On May 24, Don Armstrong [EMAIL PROTECTED] wrote:
The DFSG is a set of guidelines; there are many things that licenses
can do which would be anathema to Free Software but are not
specifically excluded by the DFSG.
But still, the first two sentences of the SC read:
We provide the guidelines
[EMAIL PROTECTED] wrote:
I've read up and found the Creative Commons and GFDL licenses are
specifically disallowed by Debian (well GFDL with non-invariant
Actually I understand that the ftpmasters have approved content licensed
under CC 3.0, which is widely considered to be free (one of the
[EMAIL PROTECTED] wrote:
See http://lists.debian.org/debian-legal/2006/12/msg00161.html and the
reduction in mdgrams until now, for example.
Or maybe the fact that in that period I changed my job, home and city.
I apologize if I have not been able to spend more time answering your
mails here (it
[EMAIL PROTECTED] wrote:
That says little itself: far more
obviously DFSG-busting licences have snuck into debian in the past!
Yes and at times some debian-legal contributors have been wrong or their
analysis voted against.
AFAIK the ftpmaster team still decides what goes in or not.
Correct.
[EMAIL PROTECTED] wrote:
In summary, can we conclude that works solely released under the terms
of SIL OPEN FONT LICENSE Version 1.1-review2, are DFSG-free, *if* their
Reserved Font Names are only names used in previous versions of the
work?
You two obviously do, but I keep disagreeing from this
[EMAIL PROTECTED] wrote:
I didn't write that, fraudster.
Thank you for showing my point.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Come on. This everything is a cost meme is becoming silly.
The DFSG was not written with this meaning.
Come on! Stop beating your straw men! Nor were they written with the
intention to prevent only money demands that hit everyone every time!
Really? Can you show some
[EMAIL PROTECTED] wrote:
I watched Sun's Simon Phipps' talk at debconf 2006 few weeks ago.
It was mentioned that the choice of venue was useless and would be
removed from CDDL, thus making CDDL DSFG-compliant.
There is no consensus that choice of venue clauses are not
DSFG-compliant, anyway.
--
[EMAIL PROTECTED] wrote:
No, it does not. As usual, you are just inventing new requirements which
are not specified by the DFSG.
Perhaps. But how can software be considered 'free' if no
useful source code is available?
By following the DFSG.
Obviously there's no single definition for all
[EMAIL PROTECTED] wrote:
That's why they offered me to send me an official e-mail which summarize the
authorization they gave us.
Is it enough for ftp-masters ?
I am not a ftpmaster, but this has been routinely accepted in the past.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL
[EMAIL PROTECTED] wrote:
Various programs in main behave markedly different in the absence of
certain proprietary network server software -- IM client programs come
to mind. Do those bits need to be removed from main?
I remember that this was settled on debian-policy@ long ago
(debian-legal@ did
[EMAIL PROTECTED] wrote:
is the same program != functionality does not change
If the code being executed is exactly the same then I cannot see how it
could provide different functions. This sounds too much like magic to me.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
[EMAIL PROTECTED] wrote:
As far as I can tell, [1] is the only thread that predates -legal and
touches on this issue. As far as it comes to a conclusion, it is that
This was not the thread.
bits that depend on non-main packages must go into contrib or
non-free. This is consistent with the much
[EMAIL PROTECTED] wrote:
Are you saying that this is roughly equivlent to something like a firmwae
uploading utility for a proprietory PDA? (That sounds like something that
could go in main).
I am saying that the driver does not depend on the firmware because
its functionality does not change if
[EMAIL PROTECTED] wrote:
Please clarify for me, in which section should go a GPL-licensed package,
which is quite unusable without (but technically not Depends on), er,
obscure blobs of data, usually gathered by a way of sniffing data flow
between a proprietary application and a hardware
In linux.debian.legal Sven Luther [EMAIL PROTECTED] wrote:
Since i am seen as not trusthy to analyze such problems, i think to deblock
this situation, it would be best to have a statement from debian-legal to back
those claims (or to claim i am wrong in the above).
In the context of the kernel I
[EMAIL PROTECTED] wrote:
I am confused as to whether the licensor will allow anonymous changes.
On the one hand, he says
At the same time I think anonymous changes to code or docs should
indeed be disallowed.
but on the other, he says
The solution is to use a fantasy name for the author.
[EMAIL PROTECTED] wrote:
What should be done, in your opinion?
Nothing. The ftpmasters decide what is free or not, not you, not I, not
debian-legal as a whole (?).
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
while in RFS-phase of the package tstat has come out that file
``erf.c'' has licence near to BSD, and that its 4th clause is on the
edge to accepted in Debian (see this thread
This is bullshit, a four clauses BSD-like license is totally free and
even raised as an example
[EMAIL PROTECTED] wrote:
even raised as an example of free licenses in the DFSG.
This is wrong. This http://www.debian.org/misc/bsd.license
is not 4-clause BSD license, since the obnoxious 3rd clause is removed:
This is not relevant, since the advertising clause was removed well
after the DFSG
[EMAIL PROTECTED] wrote:
How has it 'been placed in the public domain'? I am not aware of any
way to do that in Oxford besides copyright expiring, or the work somehow
not qualifying for automatic copyright protection anyway. It may be
possible to disclaim all copyright interest in a work, but
On Aug 31, Nathanael Nerode [EMAIL PROTECTED] wrote:
Marco trolled again. FYI, no serious person disagrees with this
interpretation.
Except every other distribution, which usually retain real lawyers
to advise them about potential problems like this instead of relying
on mailing lists posts.
On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote:
Debian must decide whether it wants to ship BLOBs with licensing which
technically does not permit redistribution. At least 53 blobs have this
problem. Many of them are licensed under the GPL, but without source code
provided. Since the
[EMAIL PROTECTED] wrote:
When I think about it: Since there is no object code in the
libmail-domainkeys-perl or libmail-dkim-perl binary packages, there shouldn't
be any problems with GPL as far as *these* packages are concerned.
Did you notice my answer? I already explained the issue.
--
[EMAIL PROTECTED] wrote:
Since DFSG apparently (according to the recent discussion) only deals with
copyright and restrictions imposed by the copyright owner, I assume that
uploading the independently developed Perl packages, libmail-domainkeys-perl
and libmail-dkim-perl, should be possible.
[EMAIL PROTECTED] wrote:
In case anyone is new here. This is Maco d'Itri and he only speaks about
his own interpretion of the DFSG,
Like everybody else on this mailing list.
which is totally different to
how almost everyone else reads it.
This is a lie large enough that qualifies your answer.
[EMAIL PROTECTED] wrote:
Well, it prohibits an entire class of derivative works: the ones that
(accurately) credit the author of the original work!
As I said elsewhere: I can release an annotate version of a CC-licensed
novel, but I could be forbidden to accurately acknowledge the authorship
of
On Aug 21, Carlos Z.F. Liu [EMAIL PROTECTED] wrote:
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
[EMAIL PROTECTED] wrote:
Still, the DFSG does not addrss patents. This means that there is no
point in arguing that patent restrictions violate thit.
The DFSG doesn't talk about any particular branch of law. It talks
about the rights attached to the program and other such phrases. To
the extent
[EMAIL PROTECTED] wrote:
This is untrue. The DGSF does not address patents. It's also the
opposite of current practice.
I think it's against the DFSG1 Free Redistribution and the DFSG3
Derived Works.
Still, the DFSG does not addrss patents. This means that there is no
point in arguing that
[EMAIL PROTECTED] wrote:
What puzzles me are the words WITHIN THAT CONSTRAINT. Is that phrase
sufficient to cause US export restrictions to be incorporated into the
license? My understanding is that if so, it would not be DFSG-free, and
No. It merely remarks that the license does not give you
[EMAIL PROTECTED] wrote:
The main question I want to ask debian-legal is this:
Does the anti-DRM requirement in the CCPL 3.0 draft, without a
parallel distribution proviso, make it incompatible with the
DFSG?
I see no reason to believe that the DFSG forbids such a clause.
[EMAIL PROTECTED] wrote:
I think the Tigris licence is incompatible with the GPL and there's a
.h file under the Tigris licence. I expect that .h file is compiled
in somehow. That could be a problem.
Not for any sane person, since it's just a few #defines for version
strings and trivial macros.
[EMAIL PROTECTED] wrote:
Andreas Fester [EMAIL PROTECTED] writes:
There needs to be a statement in each copyrighted file stating the
license granted to the recipient. If that statement refers to license
There is no such need, unless the licensing status of some files is
ambiguous.
--
ciao,
[EMAIL PROTECTED] wrote:
,
| Amusingly, it's only the
| filename and you can probably make an symlink or some other
| alias while complying with this, so it's more comedy than a bug.
`
So here the lesson seems to be that also filename change requirements
are acceptable as long as they do
[EMAIL PROTECTED] wrote:
http://wiki.debian.org/DFSGLicenses lists several such licenses --
compare to http://www.opensource.org/licenses/. Notable examples are
the APL, MPL, OSL and RPSL; there may be others derived from MPL that
also fail DFSG, and I would argue that QPL has been settled as
[EMAIL PROTECTED] wrote:
They do, but those clauses have been pointed out as being problematic
multiple times. Copyright licenses should not need to invoke copyright
law to secure protections which trademark law grants to trademarks.
And still, nobody has been able to convincingly explain why
[EMAIL PROTECTED] wrote:
I mean: may I be an anonymous Contributor?
Being forced to disclose my own real identity is a significant
restriction: it would render software under the CPL non-free (because
it's a fee, see DFSG#1).
This is in no way a fee.
--
ciao,
Marco
--
To UNSUBSCRIBE, email
[EMAIL PROTECTED] wrote:
Regardless, a requirement to disclose one's real identity does fail
the Dissident test and is thus non-free.
This dissident test is not part of the DFSG, so it cannot make
something non-free.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
In linux.debian.legal Andrew Donnellan [EMAIL PROTECTED] wrote:
Yes. As it seems here, the DDs, including one DPL, are trolling and
making completely offtopic posts.
Or maybe, but just maybe, you are in the wrong place and should spend
your time in an environment where everybody is not so much
[EMAIL PROTECTED] wrote:
It seems to me that this is insufficient and that the developers need to
clarify their license somewhere before PyGaim can be uploaded to Debian.
Am I correct in making this assumption?
No. As long as you believe that the notice on the project web site is
truthfully
[EMAIL PROTECTED] wrote:
Please note that Walter does not speak for the Debian project, and is not
a developer, maintainer, or new-maintainer applicant, just a participant
on this mailing list.
Do you really need to be so contemptuous against users who make mailing
lists live?
For the records,
[EMAIL PROTECTED] wrote:
1. The C header files containing the address assignments in the tarball
are not source code in the GPL sense, ie. 'the preferred form of the
work for making modifications'. This means that we're technically
violating the GPL distributing the ipv6calc package in
[EMAIL PROTECTED] wrote:
sufficient legal existence to sign such an agreement. My intuition is
that, unless we have fairly firm knowledge that this patent is invalid
(and I haven't seen any sign of that), this means that OpenSAML is not
distributable by Debian (even in non-free).
No. The policy
[EMAIL PROTECTED] wrote:
It's sad that many people go on refusing to listen to freeness concerns
and happily release works in non-free manners... :-(
Why should anybody care about what some people in Debian thinks about CC
licenses?
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL
[EMAIL PROTECTED] wrote:
This is not the only issue with the MPL -- as Mike Hommey recently
Other people disagree. Reality is, the tests are not part of the DSFG
and people like you so far have not managed to persuade the ftpmasters
that choice of venue clauses violate the DFSG.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
I'm not sure if it makes sense to revert that decision at this
stage.
It is never too late to fix bugs.
You first need to show that there are bugs and that the precedent
decisions are wrong. So far nobody actually managed to do this.
--
ciao,
Marco
--
To
[EMAIL PROTECTED] wrote:
Whats debian-legals position about the MPL?
debian-legal is just a mailing list, so it cannot have a position about
anything.
My position is that the MPL does not violate the DFSG, but it's not
obvious if Debian can satisfy the requirement of distributing
non-current
[EMAIL PROTECTED] wrote:
I wouldn't take this any farther than what the GR explicitly said- GFDL
w/o invariant sections are free. Otherwise, 'normal' (ie: prior to the
GR) rules apply. If people want to change the DFSG then they'll need to
actually do that, this GR didn't, just added an
On Mar 13, Stephen Frost [EMAIL PROTECTED] wrote:
I wouldn't take this any farther than what the GR explicitly said- GFDL
w/o invariant sections are free. Otherwise, 'normal' (ie: prior to the
GR) rules apply. If people want to change the DFSG then they'll need to
actually do that, this
On Mar 13, Stephen Frost [EMAIL PROTECTED] wrote:
No, I do not. It's obviously not an exception (or it would have said so)
but a way to officially state what the DFSG means when applied to this
license, since there has been a wide disagreement in the project about
this.
It's obviously an
[EMAIL PROTECTED] wrote:
My humble opinion is that it is almost DFSG-free. The only problem
section is 3.1 (requires changes to be sent to upstream).
Right, it fails the so-called desert island test.
No part of the DFSG justifies this test, so it's not enough to make
the license non-free.
--
[EMAIL PROTECTED] wrote:
I can't see anything in the DFSG which would forbid it, so it looks
free to me. With the note that the source files may need to be modified
to allow being processed with the free fonts present in Debian, but this
would not be a freeness issue.
I think that the
1 - 100 of 288 matches
Mail list logo
