Let's consider a program, released under a MIT/X11 license and linked
with OpenSSL. Some GPL'ed plugins (which are dlopen'ed at run time) are
distributed with the program.
Is distribution of this package a GPL violation?
The plugins are actually a modified version of standalone applications,
so I'm
[EMAIL PROTECTED] wrote:
>Debian's committment to Free Software does not stop at the DFSG. The "G"
>in Debian Free Software Guidelines means "Guidelines".
Obviously, this is your personal view of the issue, not shared among all
developers.
--
ciao,
Marco
ot ignore it. The equipment
>> >won't work if we ignore the issue.
>
>On Mon, Nov 01, 2004 at 01:51:56AM +0100, Marco d'Itri wrote:
>> So you say that non-free software is OK with you as long as you can
>> pretend it's not there? Which part of the policy or
[EMAIL PROTECTED] wrote:
>> Yes, sure! If some stream of bits is considered software when stored in
>> RAM then I can't see why it should not be software anymore when stored
>> in some other media. I have not seen any convincing argument about why
>> software should lose its nature if stored in RO
[EMAIL PROTECTED] wrote:
>> >On Mon, Nov 01, 2004 at 01:51:56AM +0100, Marco d'Itri wrote:
>> >> So you say that non-free software is OK with you as long as you can
>> >> pretend it's not there? Which part of the policy or SC justifies this
>>
[EMAIL PROTECTED] wrote:
>On Thu, Nov 04, 2004 at 04:42:00PM +0100, Marco d'Itri wrote:
>> So you say that non-free software is OK with you as long as you can
>> ignore it's running on your system? Which part of the policy or SC
>> justifies this theory?
>
&
[EMAIL PROTECTED] wrote:
>From what I can tell, the overall consensus was that sarge should
>release with GFDLed and similar works in place, and that we should
>remove these works post-sarge.
You are confusing the result of a votation with a consensus.
These are pretty different things.
--
ciao,
[EMAIL PROTECTED] wrote:
>Of course, debian-legal declared this situation at best contrib for
debian-legal is just a mailing list and cannot declare anything. Many
people here like to declare things, but this does not mean that they
will be accepted by the project.
--
ciao,
Marco
On Dec 12, Bruce Perens <[EMAIL PROTECTED]> wrote:
> A lot of these BLOBs have been identified as ARM7 code, and generally
> "thumb" (the 8-bit ARM instructions).
I know of some devices (very cheap stuff, nothing fancy) which even uses
VxWorks. This explains why it is not even possible for some
m
On Dec 11, Glenn Maynard <[EMAIL PROTECTED]> wrote:
> If the driver has to be able to open the file and read the blob so it
> can send it to the device, there's a clear relationship and dependency
> between the driver and the blob: if you don't have a copy of the blob,
> the driver doesn't work.
On Dec 18, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> No. It's a driver for an ipw 2100; it has an ipw2100 and can't drive
> it. It's not functional -- it failed to power on the adapter. In the
No: it's reporting that the card did activate correctly, but it's not
the driver's fault. The
On Dec 18, Glenn Maynard <[EMAIL PROTECTED]> wrote:
> No, because (as has been said already) the existance of cases where you need
> non-free stuff isn't the issue; the issue is whether there exist cases where
> you don't. If nobody can use the software without needing non-free data, the
> softwa
On Dec 19, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> > No: it's reporting that the card did activate correctly, but it's not
> > the driver's fault. The driver is complete and does not lack anything
> > needed to operate the device.
> ...except the firmware?
No: the driver does not uses th
On Dec 19, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> >> > No: it's reporting that the card did activate correctly, but it's not
> >> > the driver's fault. The driver is complete and does not lack anything
> >> > needed to operate the device.
> >> ...except the firmware?
> > No: the driver
On Dec 20, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Marco d'Itri) writes:
> >> differently depending on the presence of additional software -- the
> >> kernel, for example, or the firmware.
> > I'm not doing this either.
>
On Dec 25, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> > Yet, CF is actually chips --- often the same chips as used to hold
> > firmware distributed with hardware. Thus, it's all hardware.
> Sure. It's on a medium for software exchange, thus it's software. If
> it were an integral componen
On Dec 28, Raul Miller <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 28, 2004 at 04:26:26PM +1100, Hamish Moffatt wrote:
> > Yet the ICQ client is not useful without a component which is not in
> > Debian and in fact is not freely available.
> Same thing applies to hardware drivers. And, for that matt
[EMAIL PROTECTED] wrote:
>The relevant distinction is whether whether or not we consider there to
>be an adequate abstraction barrier between the two pieces of code.
>Other distinctions don't really matter.
Then why you keep talking about where firmware is stored?
>Drivers for firmware, where the
On Jan 06, Josh Triplett <[EMAIL PROTECTED]> wrote:
> An ICQ client wouldn't Depends: icq-server; it might Suggests:
> icq-server, but that's OK. A driver might at most Suggests:
> burned-in-firmware-for-reflashing, but it would Depends: or at a minimum
> Recommends: firmware-loaded-by-driver.
I
On Jan 07, Josh Triplett <[EMAIL PROTECTED]> wrote:
> I'll assume for the moment you are only disagreeing with the
> driver->firmware dependencies, not the client->server dependencies,
> since the latter is standard Debian policy.
No. What I'm saying is that if you stretch the definition of
"requi
On Jan 08, Josh Triplett <[EMAIL PROTECTED]> wrote:
> atmel-firmware . Would you argue that at76c503a-source should neither
> Depends: nor Recommends: atmel-firmware ? If so, why? If you changed
Yes. Read the debian-legal@ archive if you care about the details.
--
ciao,
Marco
signature.asc
[EMAIL PROTECTED] wrote:
>i have read that graphviz is licensed under the Common Public License
>Version 1.0 [1]. The FSF consider this license as free and also in the
>debian-legal mailing-list archive i couldn't find a statement that debian
>have a different view.
>So why this package is in non-
[EMAIL PROTECTED] wrote:
>I think there's wide agreement here that forced click-wrap licenses
>are non-free, and very impractical. I've seen installers in Windows
Maybe impractical, but so far I can't see why they should be non-free.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTE
[EMAIL PROTECTED] wrote:
>In any case, I don't think denying our users access to files they have every
>legal right to use is an appropriate way to try to kill off the mp3 format.
>Even if it were, would you really have us do so by treating unsubstantiated
>patent claims about mp3 decoding as if t
On Nov 19, Oliver Kurth <[EMAIL PROTECTED]> wrote:
>The firmware is needed. Without it, the device is completely dumb.
>But there are some devices which can store the fw permanently. Also,
>the fw is distributed on their (windows) installation CDs.
Make an unofficial package which will contain
[EMAIL PROTECTED] wrote:
>I have just packaged a driver for wifi cards. The driver is licensed
>under GPL, but the cards needs a non-free firmware to be uploaded in
>order to work.
I will quote from policy 2.2.2:
Examples of packages which would be included in _contrib_ or
_non-US/co
[EMAIL PROTECTED] wrote:
>Probably the right question to ask is: is there any chance to use the
>driver without touching the non-free firmware (nor any other non-free
>stuff, for that matters)?
Can you quote which part of the policy describes this criteria?
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
>If the driver does not provide any significant functionality without the
>firmware, it belongs in contrib.
The driver provides all of its functionality without the firmware, the
firmware never becomes part of the driver. The hardware device may or
may not provide useful f
[EMAIL PROTECTED] wrote:
>I think it's a question of what "dependence" means for contrib. If the
>driver absolutely _depends_ on using the non-free firmware, it should be
>in contrib. If the non-free firmware is optional, it should go into
>main.
Again, please explain which part of the policy defi
[EMAIL PROTECTED] wrote:
>On the other side, if it is possible to distribute the firmware in the
>non-free section (I have to ask that to Texas Instrument), the package
>of the driver will have a Depends: or at least a Recommends: on the
>firmware package. In that case it seems that the driver
[EMAIL PROTECTED] wrote:
>This package should be removed from Debian before Debian gets sued for
>copyright infringement.
Can you cut this bullshit please? You know well that Debian is not going
to get sued.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
>>>Of course, there's shades of gray, here. If all the driver does is emit
>>>a message CAN'T FIND NON-FREE FIRMWARE, ABORTING without the firmware,
>>>it's hard to say that it doesn't depend on the firmware. But if the
>> This applies to almost every driver in the Linux k
[EMAIL PROTECTED] wrote:
>> Right, the package in main should not depend on an hypothetical package
>> from non-free.
>So rather than ship the driver in contrib and the firmware in
>non-free, you're suggesting that the driver go in main and the
>firmware not be shipped at all, even though that red
On Oct 11, Evan Prodromou <[EMAIL PROTECTED]> wrote:
> > I think it's a question of what "dependence" means for contrib. If the
> > >driver absolutely _depends_ on using the non-free firmware, it should be
> > >in contrib. If the non-free firmware is optional, it should go into
> > >main.
> > Agai
[EMAIL PROTECTED] wrote:
>It's a perfectly reasonable means to discriminate. One is *in the
>hardware*. If I buy a widget, I don't care whether it uses firmware
>in an eeprom or a well-trained gerbil. It's a box. Software on my
>CPU is different.
Firmwares do not run on your CPU. Your poing be
[EMAIL PROTECTED] wrote:
>> Why should debian adopt a different policy if the vendor provides this
>> firmware on a CD instead of on a flash EEPROM chip?
>Because of the reasonable expectation that the user already has the
>EEPROM chip, and it's part of the hardware. It's not something Debian
>co
[EMAIL PROTECTED] wrote:
>Anyways, here's the relevant quote:
>
>"Examples of packages which would be included in contrib or
>non-US/contrib are: [...] free packages which require contrib,
>non-free packages or packages which are not in our archive at
>all for comp
[EMAIL PROTECTED] wrote:
>If you want to argue that a package in contrib should be included on CDs
>or in the installer, feel free to argue that. Please do not conflate
>that issue with the entirely non-technical decision of whether a package
>goes in main or contrib; otherwise, you are doing a d
[EMAIL PROTECTED] wrote:
>Marco, it seems to me that there's a parallel case to non-free
>firmware: dongleware. Perhaps you could explain how this philosophy
>applies to that. If a piece of software is distributed under the GPL,
>can I add functionality by putting it into firmware on a dongle an
[EMAIL PROTECTED] wrote:
>I think that requiring a hardware upgrade to support behavior is
>irrelevant to free software. Firmware that's part of the hardware is
>part of the hardware. Firmware that looks like software is software.
>If Debian *could* ship it, it's software.
This distinction is no
[EMAIL PROTECTED] wrote:
>In both cases, the quantity of non-free software used has remained the
>same. The purpose of contrib is to discourage free software with
>non-free dependencies. Deciding whether software falls into it or not
>purely based on another vendor's choice of media seems mad. Eit
[EMAIL PROTECTED] wrote:
>I find the criteria extremely clear and consistent: if it depends on
>stuff that is either non-free, or that is too non-free to even ship, it
>goes to contrib. If a user can install and run it (and be able to
But, as I already explained, the driver does not depend on the
[EMAIL PROTECTED] wrote:
>That would probably depend on the license on the non-free drivers.
We are not discussing non-free drivers, but 100% free (usually GPL'ed)
drivers.
>One problem with "non-free drivers in downloaded firmware" is that they
>can be licensed such that not everyone who owns th
[EMAIL PROTECTED] wrote:
>Marco d'Itri wrote:
>> So you understand that we will remove from the kernel e.g. ide-cd and
>> the ACPI subsystem? This does not appears to be correct to me.
>Is it completely impossible to have an IDE CD drive or an ACPI hardware
>system
[EMAIL PROTECTED] wrote:
>>>If Debian *could* ship it, it's software.
>> This distinction is not clear at all to me. What if I take a dump of the
>> flash EPROM chip? Does this magically makes the firmware a software?
>There's no magic about it. If I build a simulator for some hardware,
>then my
[EMAIL PROTECTED] wrote:
>> Your driver can be compiled and successfully executed without the
>> firmware,
>But does it do anything useful when executed?...
I don't know how you define "useful". All its functionality is already
there, but probably the controlled device will only respond to a subse
In article <[EMAIL PROTECTED]> you wrote:
Loïc, I suggest you read the whole debian-legal thread named "non-free
firmware: driver in main or contrib?", because it answers many of the
points you raised.
I will summarize the points relevant to the eagle-usb-* packages:
- distribution of firmwares w
[EMAIL PROTECTED] wrote:
>Given that the entire purpose of the driver is to actually *drive a
>device*, and that it can't do that at all without the firmware, then the
No, apparently you do not understand how the driver, hardware and
firmware interact. The driver is fully functional as is: the fir
[EMAIL PROTECTED] wrote:
>Is there a dependency relationship between the package that provides
>the driver and the firmware itself?
I already explained some days ago why it's good and useful to not have a
strong dependency. Also, for some drivers there can be no package at all
providing the firmwa
[EMAIL PROTECTED] wrote:
>> Firmwares do not run on the host CPU (they are /data/ for the host
>> system)
>Ah. You seem to be labouring under the misconception that non-program
>data files aren't subject to the same rules for inclusion in main as
>executable programs. That's an incorrect assumptio
[EMAIL PROTECTED] wrote:
>> Drivers do not require firmwares, hardware devices require firmwares.
>Well, actually, there are cases where the communication between firmware
>and driver is tight and both need each other, i.e driver won't work with
>another firmware and vice versa.
This is applicable
[EMAIL PROTECTED] wrote:
>A broken law in Germany prohibiting the utterance of a pair of words
>does not make something non-free. If that line of logic held--"if
Agreed. This is so obvious that I can't see why this should be on topic
here.
The only problem I can see is that some mirror operators
[EMAIL PROTECTED] wrote:
>The point is, some drivers DO require firmwares. I'd rather say: Some
But, as I explained, this is not correct: hardware devices require
firmwares, not drivers.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
>Atari game, and he said its OK. Of course I tried to contact
>der Mouse, but without luck. And since "Mouse" is widely used
>in computing, Google didn't return something usefull.
You need to know what to look for... der Mouse is well known in some
circles. :-) mailto:[EMA
[EMAIL PROTECTED] wrote:
>Huh? If a driver requires a firmware blob be copied from a driver CD,
Please repeat after me: "drivers do not require firmwares, hardware
devices require firmwares".
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
>The total amount of non-free software on a user's system is different if the
>firmware comes pre-loaded on the device than if we have to load it from the
>OS, isn't it?
No.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
>>>Huh? If a driver requires a firmware blob be copied from a driver CD,
>> Please repeat after me: "drivers do not require firmwares, hardware
>> devices require firmwares".
>And the driver requires a functioning hardware device. Thus, the
This is not an use of the verb
[EMAIL PROTECTED] wrote:
>> On the other hand, if it's clearly software when it's on CD then it's
>> clearly software when it's on eeprom.
>False. That's why we call it firmware, not just "software living on a device".
Get real. Software does not change its nature depending on the media
it's stor
[EMAIL PROTECTED] wrote:
>Oh, wait, maybe you're suggesting that they had some OTHER reason for
>putting those bits in rom? If that's the case, your claim that it
>doesn't help our users is a bit specious.
It's not obvious that this would be an improvement which benefits users.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
>> >Huh? If a driver requires a firmware blob be copied from a driver CD,
>> Please repeat after me: "drivers do not require firmwares, hardware
>> devices require firmwares".
>Then, how do you explain the ipw2200 case where driver version 0.5 and
>less will only work wit
On Oct 25, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> "Marco d'Itri" <[EMAIL PROTECTED]> writes:
> > [EMAIL PROTECTED] wrote:
> >>>>Huh? If a driver requires a firmware blob be copied from a driver CD,
> >>> Please repeat afte
[EMAIL PROTECTED] wrote:
>be provided while keeping the packages in contrib), but I didn't see
>anything where you argued that a package in main that requires software
>not in our archive was not a violation of Policy and the Social Contract
>(other than many unsupported assertions that only the h
[EMAIL PROTECTED] wrote:
>So if you don't have the firmware installed (into
>/usr/lib/hotplug/firmware/something_or_other), the driver will only
>print an error message and return an error code. If that is your
>definition of "fully functional", then perhaps we should include all the
>programs in
[EMAIL PROTECTED] wrote:
>Heck, for all I know there's a device out there where the "firmware on
>disk" is verilog code, and it's compiled by the driver and loaded to
>an FPGA on the device.
>
>Surely that's software.
I'm not so sure that an FPGA design is software (for sane definitions of
softwar
[EMAIL PROTECTED] wrote:
>While this is true, it is incomplete: the driver Depends, in the
>policy sense, on the device, and the device Depends on the firmware.
I do not think policy can justify this.
>> Obviously any kind of device driver has limited practical use[1] if
>> you do not own the har
[EMAIL PROTECTED] wrote:
>On Mon, Oct 25, 2004 at 04:43:50PM +0200, Marco d'Itri wrote:
>> >> Please repeat after me: "drivers do not require firmwares, hardware
>> >> devices require firmwares".
>> >Then, how do you explain the ipw2200 case w
[EMAIL PROTECTED] wrote:
>On Mon, Oct 25, 2004 at 11:44:37AM +0200, Marco d'Itri wrote:
>> >Huh? If a driver requires a firmware blob be copied from a driver CD,
>> Please repeat after me: "drivers do not require firmwares, hardware
>> devices require firmware
[EMAIL PROTECTED] wrote:
>In cases where firmware is basically indistinguishable from hardware,
>we treat it as hardware, and not as software.
Really? Which part of policy states this?
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
>Perhaps then you can provide an example of what the driver can do in a
>world where all the Windows driver-CDs have vanished, and there is
>only a device plaintively calling out for a firmware download in my
>machine. Can the driver do anything?
Uploading or not uploadin
[EMAIL PROTECTED] wrote:
>Then there's no point continuing this conversation. An FPGA design,
>living as a file on disk and possibly even shipped by Debian is
>clearly software under Debian's definitions. Runtime-loaded firmware
I was not discussing Debian's definitions now.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
>> >In cases where firmware is basically indistinguishable from hardware,
>> >we treat it as hardware, and not as software.
>> Really? Which part of policy states this?
>Historical practice.
OK, thank you for confirming that this has no foundation in the policy.
--
ciao,
[EMAIL PROTECTED] wrote:
>> >I'm telling you some drivers *do depend* on a certain firmware. You're
>> >still repeating the opposite. Now explain me how in ipw2200 case the
>> >driver doesn't *depend* on the firmware, since you seem to know the
>> >truth.
>> You are using a different meaning of "d
[EMAIL PROTECTED] wrote:
>Yes, Marco. We all understand the model you propose, based around the
>idea "all firmware is essentially hardware, even if it's clearly a
>file that has to be there on disk for a driver to function". An
Now it's quite clear that you did not understand at all what I have
[EMAIL PROTECTED] wrote:
>> These two cases are well different: the first driver already contains
>> all code needed to manage the hardware device (even if it chooses to not
>> send some commends to the device until it will be ready to process them),
>> in the second case the program is not comple
[EMAIL PROTECTED] wrote:
>> No, this is again wrong: a program and the libraries it use are a single
>> entity (why do you think it's called linking?) while drivers and devices
>> are different entities.
>> They interact the same way IM clients and servers interact.
>From the point of view of user
[EMAIL PROTECTED] wrote:
>On Tue, Oct 26, 2004 at 12:27:09PM +0200, Marco d'Itri wrote:
>> >In cases where firmware is basically indistinguishable from hardware,
>> >we treat it as hardware, and not as software.
>> Really? Which part of policy states this?
&g
[EMAIL PROTECTED] wrote:
>Argh. Yes, but the firmware in these eeproms is something that we're
>entirely logically capable of shipping. Claiming that firmware is
>sometimes software (when it's on a compact flash card, say) and
>sometimes hardware (when it's on an eeprom, say) is the sort of argume
[EMAIL PROTECTED] wrote:
>On Wed, Oct 27, 2004 at 10:56:58AM +0200, Marco d'Itri wrote:
>> I explained my principles at the beginning of the discussion, and I do
>> not feel the need to state them again because they are not relevant here:
>
>How about something tha
[EMAIL PROTECTED] wrote:
>In the goal of seeking consistency, I think this requires mass bug
>filing against packages with unmet dependencies, including:
If dependencies really have to be followed outside the borders of
software manages by the OS then I agree that this is the only logical
conseque
[EMAIL PROTECTED] wrote:
>Does anyone know if it is possible to obtain an IDE disc drive that
>contains no non-free software,
I do not believe that this is possible.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
>On Thu, Oct 28, 2004 at 10:05:05PM -0400, Michael Poole wrote:
>> > BIOSes are in the EPROM case that I've described--part of the hardware,
>> > already present--and go in main.
>> How does this exception follow from either the SC, DFSG or Policy?
>Hardware is not part of
[EMAIL PROTECTED] wrote:
>On Thu, Oct 28, 2004 at 10:10:47PM -0400, Michael Poole wrote:
>> Conflict in what way? It says "contrib" and "non-free" are for works
>> that do not conform to the DFSG. Packages in "contrib" conform to the
>> DFSG but depend on software that does not. If I interpret
[EMAIL PROTECTED] wrote:
>> Then let's forget for a minute boot loaders. What about all drivers
>> which interact with non-free software stored in computers and their
>> peripherals?
>
>I think you're forgetting about more than boot loaders, since this has
>been explained more than once. However,
[EMAIL PROTECTED] wrote:
>On Fri, Oct 29, 2004 at 11:07:14AM +0200, Marco d'Itri wrote:
>> >Hardware is not part of Debian, and the fact that Debian depends on
>> >non-free pieces of hardware has never been considered to violate any of
>> >the above. (And, as
[EMAIL PROTECTED] wrote:
>On Fri, Oct 29, 2004 at 05:50:29PM +0200, Marco d'Itri wrote:
>> So, following from this why you think that the motherboard firmware
>> (the BIOS, which can be reflashed by users) or the CD reader firmware
>> (which can be reflashed as well, wit
On Jan 24, Russ Allbery <[EMAIL PROTECTED]> wrote:
>[mrouted]
>If anyone actually cares, I may be able to get this relicensed and am
>willing to at least try. I'm mildly surprised that anyone is still using
>this.
Two weeks ago I opened #227146 but the maintainer did not reply:
The OpenBSD
[EMAIL PROTECTED] wrote:
>this program use postscript program that is really short and
>copyrighted by adobe.
It's trivial enough that probably you do not need to worry about
copyright.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Cont
[EMAIL PROTECTED] wrote:
>> In an email on Aug 15 2005, Kevin wrote to Alex:
>> > I proceeded on the casual assumption that Noah Morgan
>> > and Don Kneller would have no issues with changes
>> > being made and posted. They posted to a public forum,
>> > and I seem to vaguely recall that their lic
[EMAIL PROTECTED] wrote:
>> Hope to have answered to your question. I am sorry but I did not succeed
>> in asking Berkeley's Regents for a license change.
>Didn't they issue a blanket license change for _all_ code owned by them
>under the old bsd license?
Yes.
But the original spice code was not
On Sep 08, Sven Luther <[EMAIL PROTECTED]> wrote:
> 2) Any argument i may have are only the lame repetition of the opinion of a
> single person here on debian-legal.
Indeed, the "choice of venue is a fee" argument is just that: an
opinion which has at best no clear roots in the DFSG, therefore
On Sep 08, Sven Luther <[EMAIL PROTECTED]> wrote:
> > Indeed, the "choice of venue is a fee" argument is just that: an
> > opinion which has at best no clear roots in the DFSG, therefore it
> > cannot make a license non-free.
> Yeah, but there is certainly more than a single person arguing that we
On Sep 09, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> > There is nothing wrong with this, and I'm not a fan of choice of venue
> > clauses either, but they should try to modify the DFSG then.
> Could you explain why DFSG#5 couldn't be invoked in this case?
It does not work this way. If you beli
On Sep 09, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> > It does not work this way. If you believe that a license is not free
> > it's up to you explaining why.
> Well, I'm explaining that it isn't free because of DFSG#5. However, it
> seems that you are refusing such arguments de facto.
I am re
On Sep 10, George Danchev <[EMAIL PROTECTED]> wrote:
> > Not "now". Debian (and I think every other distribution) has been
> > distributing software with this kind of licenses for years, without any
> > apparent ill effect on users.
> Not true. Many licenses that failed to comply with DFSG [0] has
[EMAIL PROTECTED] wrote:
>This might fail the Dissident test (and thus discriminate against
Which is not part of the DFSG, so it does not matter.
>[clause 3.3 goes on]
>> You may not
>> remove or alter any copyright, patent or trademark notices
>> contained within the Covered So
On Sep 09, George Danchev <[EMAIL PROTECTED]> wrote:
> Debian has always been full of software licensed that way ;-) Now you want
> (unintentially) to leave possible holes thru new 'a-la sco insane cases' to
> enter the scene... all over the world.
Not "now". Debian (and I think every other dis
On Sep 09, George Danchev <[EMAIL PROTECTED]> wrote:
> > It does not work this way. If you believe that a license is not free
> > it's up to you explaining why.
> here they are:
So finally we are up to the good old "every restriction is a
discrimination" argument. Even if in the last two years it
[EMAIL PROTECTED] wrote:
>This is, in my opinion, the natural and direct extension of the
>explicit language that a license cannot require "royalties or other
>fees" to be paid in exchange for the rights described in the
In my opinion, this is not natural nor direct.
Looks like we are down to opin
[EMAIL PROTECTED] wrote:
>>Which is not part of the DFSG, so it does not matter.
>The Dissident test is a test for DFSG #5, so it does matter. See:
No, it is not.
The "dissident test" is something which a few debian-legal@ contributors
invented, but which has no grounds in the DFSG.
--
ciao,
Mar
[EMAIL PROTECTED] wrote:
>DFSG#5 is very plain and very broad: it prohibits discrimination
>against *any* person or group. If you think it should be narrowed,
>propose an amendment to the SC.
Until the DFSG-revisionists came here, the meaning of the DFSG #5 was
to forbid licenses which provide th
1 - 100 of 312 matches
Mail list logo
