Hi!
13-Фев-2004 14:06 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
BO> How is this different from a .rar file? Very much so. The GPL does not
BO> care about what the stub exactly does. The fact that matters is that it is
BO> a) linked in and b) impossible to run the executable wit
On Thu, 12 Feb 2004, Kenneth J. Davis wrote:
> The 'major components' do not have to be provided _with_ the
> OS, they must be _of_ the OS. Thus one can use any compiler,
> linker, or whatever is deemed a major component of the OS.
true.
> So the even funnier part is about statically linked run
On Fri, 13 Feb 2004, tom ehlert wrote:
> as the EMM*.zip archives are selfcontradicting (because they claim to
> be GPL, but aren't) they might crash any GPL-aware OS internal logic.
> please remove them from all open source OS disks before you see a
> kernel panic() ;)
> Exactly my thinking.
> bu
>> Here comes the fun part:
SK> Well, even more fun:
SK> If HIMEM(64) is under GPL, you may not do it either.
SK> You must release the executable under a different license; which, however,
SK> can be shipped in the same archive.
it's like
' this sentence is false '
as the EMM*.zip archives are
On Fri, 13 Feb 2004, tom ehlert wrote:
> Here comes the fun part:
Well, even more fun:
If HIMEM(64) is under GPL, you may not do it either.
You must release the executable under a different license; which, however,
can be shipped in the same archive.
Anyway, how about this:
There is already me
At Fri, 13 Feb 2004 1:16pm +0200, Luchezar Georgiev wrote:
> On Fri, 13 Feb 2004 11:13:20 +0100, Aitor SantamarÃa Merino wrote:
>
> > Otherwise it wouldn't be legal either that you provide an ISO file of
> > a CD-ROM that contains GPL and non-GPL software: both are different
> > types of sotware
Hi!
13-Фев-2004 10:02 [EMAIL PROTECTED] (Steffen Kaiser) wrote
to "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
>> 2. Again: exepackers are non-essential part of program, which adds stub for
>>_existing and working_ code, so they can't be counted as "modules, which
>>program contains". This is
On Fri, 13 Feb 2004 11:13:20 +0100, Aitor SantamarÃa Merino wrote:
If this be so, then RAR and PKZIP can no longer be chosen as file packers for exactly the same reason.
What an absurd, indeed!
However, the stub is nothing else than uncompressing software, that even if it is inside the same "oper
Hi,
Well, at least I seem to be convinced by Steffen's argument (and if I
weren't, I guess I can still be using InfoZIP's ZIP/UNZIP and UPX-UCL as
compressor software.
tom ehlert escribió:
I argued that coexistence of data, stub and and header is "mere
aggregation", just like combining files i
>> I argued that coexistence of data, stub and and header is "mere
>> aggregation", just like combining files in a ZIP file or in a diskette.
SK> No, because you "modify" the GPL'ed Program prior distribution and not
SK> by-pack it.
SK> That's why I assume that an un-aPack'er would solve the prob
On Fri, 13 Feb 2004 09:53:06 +0100 (CET), Steffen Kaiser wrote:
I argued that coexistence of data, stub and and header is "mere
aggregation", just like combining files in a ZIP file or in a diskette.
No, because you "modify" the GPL'ed Program prior distribution and not
by-pack it.
ZIP also modifi
On Thu, 12 Feb 2004, Arkady V.Belousov wrote:
> 1. Strictly speaking BC/OW/MSC are not "components" of MS-DOS/Windows. I
Yup. See tom's reply, too.
>
> 2. Again: exepackers are non-essential part of program, which adds stub for
>_existing and working_ code, so they can't be counted as "modul
On Thu, 12 Feb 2004, Luchezar Georgiev wrote:
> I argued that coexistence of data, stub and and header is "mere
> aggregation", just like combining files in a ZIP file or in a diskette.
No, because you "modify" the GPL'ed Program prior distribution and not
by-pack it.
That's why I assume that an
>From: tom ehlert <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Subject: Re: [Freedos-devel] Executable compression
>
>SK> special exception, the source code distributed need not include
>SK> anything that is normally distributed (in either source or binary
&
My personal opion is that packing the executables as part of the
official distribution is a bad idea. If somebody needs to squeeze the
last bit of space for some reason, they should be the one to do the EXE
compression.
As I see it EXE packing just adds one additional layer of possible
incompatib
On Thu, 2004-02-12 at 08:16, Bart Oldeman wrote:
> But please note that the GPL only affects distribution, not usage.
>
> This is also why I think restricting military usage is pointless: the
> really bad guys will ignore such usage restrictions anyway.
Yes, and the other little fact that Copyrig
SK> special exception, the source code distributed need not include
SK> anything that is normally distributed (in either source or binary
SK> form) with the major components (compiler, kernel, and so on) of the
SK> operating system on which the executable runs, unless that component
SK> itself
On Thu, 12 Feb 2004, Luchezar Georgiev wrote:
> On Thu, 12 Feb 2004 15:14:40 + (GMT), Bart Oldeman wrote:
>
> > there is a completely GPLed packer, called upx-ucl (the one that you get
> > when you compile UPX and UCL from source). It packs slightly weaker than
> > the precompiled upx (upx-nrv
On Thu, 12 Feb 2004 15:14:40 + (GMT), Bart Oldeman wrote:
there is a completely GPLed packer, called upx-ucl (the one that you get
when you compile UPX and UCL from source). It packs slightly weaker than
the precompiled upx (upx-nrv).
In Tom's comparison, for FreeCOM (~93000 bytes uncompressed
On Thu, 12 Feb 2004 14:16:39 + (GMT), Bart Oldeman wrote:
no it's not absurd, to the contrary, it's the whole point of the GPL!
Otherwise a BSD or MIT/X11 style license should be used. There are lots
of things the developers cannot do, for instance distributing a
closed-source program that der
On Thu, 12 Feb 2004, Aitor Santamaría Merino wrote:
> By the way, I assume from this all that there's no GPL-ed packer. So I
> suppose that according to the FSF agenda this means that, as there is no
> GPL-ed packer, then I have to give up the ussage of packers, better than
> using a closed source
Hi!
12-Фев-2004 14:43 [EMAIL PROTECTED] (Steffen Kaiser) wrote
to "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
SK> X-Spam-Report: Spam Filtering performed by sourceforge.net.
SK> 0.0 TO_ADDRESS_EQ_REAL To: repeats address as real name
SK> "The source code for a work means the preferred form o
Bart Oldeman escribió:
So I'm not convinced yet that using aPack would
be illegal EVEN THOUGH I register my own copy
No. *Using* apack is not restricted at all.
You may apack all your FreeDOS executables. It's the *distribution* that
is (likely) restricted by the GPL.
You may even (subject to
On Thu, 12 Feb 2004 14:43:57 +0100 (CET), Steffen Kaiser wrote:
OK - _I_ personally understand an EXEPACKER as a "kind of delivery",
like InstallShield, ZIP, and the like. [...] you
must ship all modules, tools, etc,pp, to re-built Program!!
[...] So, if you distribute the sources to built the Pro
On Thu, 12 Feb 2004, Luchezar Georgiev wrote:
> On Thu, 12 Feb 2004 09:10:33 +0100, Roberto Mariottini wrote:
>
> > I understand you Lucho, but Bart is right: if it's not possible, then just it
> > isn't.
>
> So, we are (OK, I am) in the trap of our own license! The GPL, instead
> of giving us fr
Hi!
12-Фев-2004 15:26 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
>> FreeDOS command.com aPack -1 63,766 byte
LG> you tested UPX-NRV, didn't you?). Method -1 (one) usually gives best
LG> compression for larger executables like FreeCOM.
Don't rely on such assumption,
> FreeDOS command.com UPX 66.426 byte
> FreeDOS command.com aPack63,818 byte
> FreeDOS command.com aPack -1 63,766 byte
> FreeDOS command.com aPack -2 63,791 byte
> FreeDOS command.com aPack -3 63,799 byte
>
> tom
For someone like me struggling to pack as many
as pos
On Thu, 12 Feb 2004, Arkady V.Belousov wrote:
Hello,
> Don't know which differences you see between "combining" and
> "aggregation", but I already explain 3-4 times why I think, that GPL not
> obstruct exepacking by closed source exepacker (aslo as it not prevents
> using closed source compi
On Thu, 12 Feb 2004 11:16:36 -0200, Alain wrote:
I just want to add something to the GPL issue: There is nothing to prevent a GPL'd program to be distributed "combined" with proprietary code. Only the other way around is restricted.
Good point, Alain!
So if someone is willing to pay for aPack so
On Thu, 12 Feb 2004 12:47:22 +0100, tom ehlert wrote:
FreeDOS command.com UPX 66,426 byte
FreeDOS command.com aPack 63,818 byte
FreeDOS command.com aPack -1 63,766 byte
FreeDOS command.com aPack -2 63,791 byte
FreeDOS command.com aPack -3 63,799 byte
Yes, the difference is simila
I just want to add something to the GPL issue: There is nothing to
prevent a GPL'd program to be distributed "combined" with proprietary
code. Only the other way around is restricted.
So if someone is willing to pay for aPack so that we can use his
personal distribution, I will thank him very m
FreeDOS command.com UPX 66.426 byte
FreeDOS command.com aPack63,818 byte
FreeDOS command.com aPack -1 63,766 byte
FreeDOS command.com aPack -2 63,791 byte
FreeDOS command.com aPack -3 63,799 byte
tom
---
SF.Net is
I suggest, that you wrongly understand GPL.
Of course! I've never understood legal language, and I, you, and many others we have problems with "normal" English too. And you're right that Mr. Turner probably doesn't understand the technical problem too. So, a big misunderstanding occurs, because we
Hi!
12-Фев-2004 13:24 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
>> then you have rights to distribute anything inside this archive (until this
>> "anything" allows own distribution).
LG> Of course, but lawyers (or "GNU compilance experts") like Mr. David Turner
LG> of FSF
Hi!
12-Фев-2004 10:55 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
>> I understand you Lucho, but Bart is right: if it's not possible, then just it isn't.
LG> So, we are (OK, I am) in the trap of our own license! The GPL, instead of
LG> giving us freedom, takes it away from *
On Thu, 12 Feb 2004 13:47:11 +0300 (MSK), Arkady V.Belousov wrote:
How this differs from exepackers? You may say: exepacker stub doesn't
unpacks executable to disk. But in case of ZipMagic or Stacker you also get
"on the fly" unpacking into memory. So, because exepacker isn't essential
part o
Hi!
11-Фев-2004 21:26 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
>> BO> c) APACK stub. Conflicts
>> BO>a. do i want to prevent linkage with closed or non-GPL
>> I think, using exepacker and or archiver _on_ (or joining unpacker _with_) program
>> is not linkage _into_
On Thu, 12 Feb 2004 09:10:33 +0100, Roberto Mariottini wrote:
I understand you Lucho, but Bart is right: if it's not possible, then just it isn't.
So, we are (OK, I am) in the trap of our own license! The GPL, instead of giving us freedom, takes it away from *us*, the *developers*! Isn't that absu
Hi,
comments embedded.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Luchezar Georgiev
> Sent: Wednesday, February 11, 2004 5:50 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Freedos-devel] Executable compression
>
>
>
On Wed, 11 Feb 2004 21:55:14 +0300 (MSK), Arkady V.Belousov wrote:
BO> c) APACK stub. Conflicts
[...]
BO>a. do i want to prevent linkage with closed or non-GPL
I think, using exepacker and or archiver _on_ (or joining unpacker _with_) program is not linkage _into_ program.
Yes, I think so, and
Hi!
11-Фев-2004 17:04 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
LG> There is a very good and easy interactive license selector at
LG> http://pgl.yoyo.org/lqr/ but I'd still prefer if we compose one of our own.
LG> More opinions, please!
I against this. GPL is a good
Hi!
11-Фев-2004 12:59 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
BO> /EXEPACK can be argued to be normally distributed with the compiler and is
BO> therefore part of the "special exception". Using APACK instead of EXEPACK
BO> is like using a third party RTL instead of the one sh
Hi!
11-Фев-2004 12:42 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
LG> WITHOUT the GPL virus effect),
What bad in this "effect"?
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps &
On Wed, 11 Feb 2004 15:43:55 + (GMT), Bart Oldeman wrote:
The FreeDOS kernel is released under the GPL and will remain so. Getting
the agreement of all copyright holders (Pat Villani, John Price, ror4,
James Tabor, Tom, Lucho, Martin, many others) to change it is an
impossible task.
OK, I see.
Hi!
11-Фев-2004 07:47 [EMAIL PROTECTED] (Steve Nickolas) wrote to
[EMAIL PROTECTED]:
SN> I'll admit I don't really care for the GPL much myself. I use it because
SN> it's well-known and gets more support than using an alternative. Me, I
SN> would just take the BSD license and add a clause requi
Hi!
11-Фев-2004 13:16 [EMAIL PROTECTED] (tom ehlert) wrote to Luchezar Georgiev
<[EMAIL PROTECTED]>:
LG>> virus effect), so this "FreeDOS License" becomes yet another item
LG>> in the following rather long list of GPL-compatible licenses?
te> If this license fits on a single page - maybe. If not,
On Wed, 11 Feb 2004, Luchezar Georgiev wrote:
> There is a very good and easy interactive license selector at
> http://pgl.yoyo.org/lqr/ but I'd still prefer if we compose one of our
> own. More opinions, please!
The FreeDOS kernel is released under the GPL and will remain so. Getting
the agreeme
An executable compressor is no different than a compiler/linker.
The exe compressor is a major component of the OS (at least
for the purposes of FreeDOS) just like a compiler/linker.
The major comonents do not have to provide source (it is the
only source exemption in the GPL). Thus the source to
There is a very good and easy interactive license selector at http://pgl.yoyo.org/lqr/ but I'd still prefer if we compose one of our own. More opinions, please!
Lucho
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy
Hi,
It is not easy to define the words 'free' and 'open'.
How free? How open? To what extent?
I don't know if my program developed in a propriatory
OS be defined as 'impure', but all softwares finally
make use of the BIOS that is also not 'free' to my
understanding.
IMHO, without propriatory soft
On Wed, 11 Feb 2004 12:59:27 + (GMT), Bart Oldeman wrote:
it does not allow you to modify the stub. That's the main point.
If this wasn't required by the GPL, why would one want to do that? That stub is very short (between 133 and 340 bytes long) and is so heavily optimised that hardly anyone
Hi,
comments embedded.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Luchezar Georgiev
> Sent: Wednesday, February 11, 2004 1:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Freedos-devel] Executable compression
>
[...]
&g
On Tue, 10 Feb 2004, tom ehlert wrote:
> DT> I heard that you were considering a proprietary executable compression
> DT> scheme for FreeDOS.
> could you explain 'proprietary' ?
>
> is everything non-GPL 'proprietary' ?
proprietary is everything that is (in the eyes of the FSF) not Free
Software.
At Wed, 11 Feb 2004 2:31pm +0200, Luchezar Georgiev wrote:
> On Wed, 11 Feb 2004 12:48:57 +0100, Aitor Santamari'a Merino wrote:
>
> > I am for that, because this way we can get rid of at all of these
> > issues about linking, stubbing to non GPL or composing software using
> > tools that are not
On Wed, 11 Feb 2004 12:48:57 +0100, Aitor Santamari'a Merino wrote:
However, what if we compose a special FreeDOS License, best suited to our needs (saying everything about executable packers, library code, inline compiler code, embedded systems use, and so on - all issues that are NOT satisfactor
LG> Sad to see that, Tom! But you're right - there is no logic in
LG> lawyer's thinking.
I'm only a programmer - with a programmer's brain.
Why use licensing terms I can't understand myself?
LG> However, what if we compose a special FreeDOS
LG> License, best suited to our needs (saying everything
Luchezar Georgiev escribio':
On Wed, 11 Feb 2004 10:03:11 +0100, tom ehlert wrote:
conclusion of this exepack discussion:
However, what if we compose a special FreeDOS License, best suited to
our needs (saying everything about executable packers, library code,
inline compiler code, embedded sys
On Wed, 11 Feb 2004 10:03:11 +0100, tom ehlert wrote:
conclusion of this exepack discussion:
1) Freedos EMM386 and HIMEM are not GPL (and have never been),
because they are distributed in a compressed format, and the
compressor/decomptressor is PROPRIETARY and not available to the
public.
so lice
conclusion of this exepack discussion:
1) Freedos EMM386 and HIMEM are not GPL (and have never been),
because they are distributed in a compressed format, and the
compressor/decomptressor is PROPRIETARY and not available to the
public.
so licensing will change.
2) same for MKEYB, as I reserve th
DT> I heard that you were considering a proprietary executable compression
DT> scheme for FreeDOS.
could you explain 'proprietary' ?
is everything non-GPL 'proprietary' ?
the compressor is available to everyone, but simply does not allow
free distribution of compressed executables, if used comerc
Hi!
10-Фев-2004 12:48 [EMAIL PROTECTED] (David Turner) wrote to
[EMAIL PROTECTED]:
DT> I heard that you were considering a proprietary executable compression
DT> scheme for FreeDOS. I'm just writing to let you know the licensing and
DT> freedom implications of this.
DT> The compressor rewrites a
On Tue, 10 Feb 2004, David Turner wrote:
> I heard that you were considering a proprietary executable compression
> scheme for FreeDOS. I'm just writing to let you know the licensing and
> freedom implications of this.
Now that you're here anyway ;) I have some questions too:
first of all many F
At Tue, 10 Feb 2004 12:48pm -0500, David Turner wrote:
> I heard that you were considering a proprietary executable compression
> scheme for FreeDOS. I'm just writing to let you know the licensing and
> freedom implications of this.
>
> The compressor rewrites an executable (in the FreeDOS case,
On Tue, 10 Feb 2004 12:48:43 -0500, David Turner wrote:
I heard that you were considering a proprietary executable compression
scheme for FreeDOS. I'm just writing to let you know the licensing and
freedom implications of this.
The compressor rewrites an executable (in the FreeDOS case, one unde
I heard that you were considering a proprietary executable compression
scheme for FreeDOS. I'm just writing to let you know the licensing and
freedom implications of this.
The compressor rewrites an executable (in the FreeDOS case, one under
the GPL), inserting decompression code. This creates a
65 matches
Mail list logo
