GNUStep: An Apology for Announcing Donation of Proprietary Software to the Project
Laurent Julliard
http://linuxtoday.com/news_story.php3?ltsn=2001-12-21-005-20-OP-CY
----------------------
GNUStep: An Apology for Announcing Donation of Proprietary Software to
the Project
Dec 21, 2001, 07 :07 UTC (1 Talkback[s]) (933 reads)
By Adam Fedor, Chief Maintainer of the GNUstep Project
The GNUstep project would like to apologize for announcing that we had
been given, as a donation, a license for a proprietary program. We made
a mistake in announcing this, but the first mistake was in asking for a
donation of that kind. The GNU Project gladly accepts donations of
computers, money, and other services, and gladly thanks the donors for
them. But we can't accept a copy of a proprietary program, because we
criticize proprietary software on ethical grounds and we have to live by
our ethical principles. And we can't advertise a proprietary program no
matter how grateful we feel towards its developer.
How did we make the mistake of asking for a donation of that kind? We
were so absorbed in looking for ways to improve GNUstep that we forgot
the larger goal and principles of the GNU Project. We forgot that
"donating a license" for a non-free program is just making a special
exception to a general policy of restricting all the users. We're
supposed to be working on changing this restrictive situation for
everyone, not obtaining a special exception for ourselves. We're
supposed to be taking the proprietary software off our machines, not
putting more of it on.
Announcing this problematical donation was a further mistake, because it
had the effect of advertising the proprietary program. Our principles
say we should only help publicize a software package if it's the sort of
package that we're trying to encourage--that is, a free software package.
This just goes to show how people working on a technical project need to
recall the larger context--the long-term goals and ethical
principles--and not get lost in the details of the specific technical
problems to be solved today.
We hope you can learn from this mistake. Please consider the benefits of
free software that respects your freedom. And if you find a non-free
program that you really would like to use, don't try to get a copy.
Write a free replacement for it instead!
Related Stories:
GNUstep Receives Help from VMware(Dec 11, 2001)
--
Laurent JULLIARD - Xerox R&T/XAC/XPA - Open Source team
>> Host your Xerox Software project on CodeX: http://codex.xerox.com
>> Linux@Xerox community: http://xww.linux.world.xerox.com
H.-R. Oberhage
: FYI.
Thanks for that pointer, ...
: http://linuxtoday.com/news_story.php3?ltsn=2001-12-21-005-20-OP-CY
:
: ----------------------
:
: GNUStep: An Apology for Announcing Donation of Proprietary Software to
: the Project
: Dec 21, 2001, 07 :07 UTC (1 Talkback[s]) (933 reads)
:
: By Adam Fedor, Chief Maintainer of the GNUstep Project
:
: The GNUstep project would like to apologize for announcing that we had
: been given, as a donation, a license for a proprietary program. [...]
... I do think it goes too far, though. Although I can identify with
the argumentation nearly completely, it is in my view not objectionable
to accept 'proprietary whatevers' and report and welcome it, as long
as such a whatever "just helps" getting a product done, and doesn't impair
the product or is necessary(!) for anyone to 'build' or 'use' it.
Thus as long as said donation just helps in 'testing' or 'getting things
over' (conversion, porting), I see nothing wrong in either using it or
making this known - even in asking for it, although this has another
flavour with it.
I do agree, that a 'free' product or tool is even better and more
of a target to aim for; but as long as it isn't there or at a point
it can achieve this ...
In that sense I do feel the cited apology being an (over-)exaggeration
and not necessary and could imagine VMware, just trying to be friendly
for whatever motive, being alienated unnecessarily, now.
The workstations, PCs or whatever we're using are also proprietary or
contain proprietary elements; for some systems (most notably those which
first run NEXTSTEP, and others Apple has control over) even their
programming isn't laid open or in the public domain, yet they are used
in the project.
It's quite another thing when strings are attached to usage, products
developed (from that) and so on.
Thus - speaking for me and this case - I'm still gratefull to VMware for
the donation and support (and still wish for an even better support of
OPENSTEP for many different reasons). I hope that a lot of good comes out
of it for the GNUstep project.
I hope (and do think) that not too much damage has been caused by all of
this (announcement as well as withdrawal), but think that arguments should
be weighted more before either such action.
[I've no problem with Fedor speaking for GNUstep the way he does, in this
matter, just with the apology/withdrawal, which sounds too much like coming
from RS for my taste.]
Thanks and greetings,
Ruediger Oberhage
--
H.-R. Oberhage
Mail: Univ. Essen E-Mail: ober...@Uni-Essen.DE
Fachbereich 7 (Physik) rued...@Theo-Phys.Uni-Essen.DE
S05 V07 E88
Universitaetsstrasse 5 Phone: (+49) 201 / 183-2493
45141 Essen, Germany FAX: (+49) 201 / 183-4578
Jeremy Bettis
Other reasons:
GNUstep could use other publicaly avaliable code (like darwin or other apple
changes to gcc/gdb) without a copyright assignment.
-Wno-import could be the default
Wouldn't it be nice to do what's best for the project and not what is best
for the GNU manafesto?
> GNUStep: An Apology for Announcing Donation of Proprietary Software to
> the Project
> Dec 21, 2001, 07 :07 UTC (1 Talkback[s]) (933 reads)
--
Jeremy Bettis -*- PGP public key available,send mail with subj "Send pgp key"
Home: jer...@bettises.com Work: jer...@hksys.com
MIME/PGP accepted
"Peron, Stéphane"
Yes ..and why not $$Step ? :-)
According to you, what is the best for the project ?
What it the real aim of GNUstep ?
Stef
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep
Nicola Pero
> This is just one more reason that GNUStep should not be a GNU project.
Some of our most dedicated developers (certainly myself) wouldn't be
working on GNUstep at all if GNUstep wasn't a GNU project. Don't forget
that and mind your words on this topic, 'cause you'll get flamed
otherwise.
> Other reasons:
> GNUstep could use other publicaly avaliable code (like darwin or other apple
> changes to gcc/gdb) without a copyright assignment.
?
I don't get your point - who cares ? what do we need that code for ?
first, we are trying to build a free software environment. well, we're
not trying - we've done it. the dream of many - a free nextstep-like
environment ... it's here - we miss gui details, we miss applications, but
we have to code those anyway - it's just a matter of time. so - what
would be the point at this stage to mix apple obscure-licensed code with
our clean free GNU (L)GPL code ? just to spoil the whole point of the
project at this stage ? if you don't care about the fact it's free, and
if you want apple proprietary software, go use apple software.
btw, apple is already merging their gcc changes into the mainstream GNU
GCC. They seem to be much less afraid of GNU than their users, and much
of the software on darwin is GNU anyway.
> -Wno-import could be the default
This has nothing to do with GNUstep being part of the GNU project - it's a
purely technical decision, while GNUstep being part of the GNU project is
an ethical/philosophical/licensing question.
#import is deprecated - on technical grounds - by any gcc compiler hacker
we had the chance of talking to, both GNU and Apple folks - they have
strong views on that point and they keep the warning turned on in the
compiler by default.
I personally think we don't have much to argue with them - they are right.
Anyway, if you don't want that warning, you should be discussing the
technical bits with them, not blaiming the fact the GNUstep is part of the
GNU project - that's meaningless.
gnustep-make already allows you to change the flags very simply - by just
adding
ADDITIONAL_OBJC_FLAGS += -Wno-import
to your GNUmakefile. If you have any suggestion for how to make it
simpler, let me know - I'll implement a simpler way if you can suggest a
reasonable one. But the fact we're part of the GNU project has nothing to
do with these technical details.
Just to put things in context, I personally would like -Wall to be the
default in gnustep-make, but I don't blaim the GNU project if it isn't.
Everyone of us has its own preferred flags for compiling, the GNU project
has nothing to do with it - we can discuss how to make it simpler for
people to choose their preferite flags, but what has this to do with
GNUstep begin part of the GNU project at all ?
> Wouldn't it be nice to do what's best for the project and not what is best
> for the GNU manafesto?
I don't get it - what exactly is your problem with GNUstep being part of
GNU ? You have all the software free on the internet, you can download
everything you want, you can see the sources, modify them, recompile them,
use them, package them, even sell them, what do you want more ?
If what you want more is being able to turn them into proprietary software
(or to mix them with proprietary software in such a way that you can't use
them without having proprietary software), then I'm very happy you can't
do it - our code is meant to be free for everyone, and forever.
Richard Frith-Macdonald
Nicola wrote.
While I'm no GNU fanatic, I think that the gains from being part of
GNU are more important than any inconveniences.
However, I think the main drive of what Nicola is saying is that most
of the points complained about are nothing to do with it being a GNU
project anyway.
For me, the most important thing about GNUstep being a GNU project sis
to do with the licensing ...
Using the LGPL has nothing to do directly with being a GNU project,
but being a GNU project means that the FSF is there as a copyright
holder to enforce the license! This means that I have some assurance
that my work won't be appropriated by people who won't share
fixes/improvements.
Chris B. Vetter
Nicola Pero <nic...@brainstorm.co.uk> wrote:
[...]
> we miss gui details, we miss applications, but we have to code those
> anyway - it's just a matter of time. so - what
I hope that's not flame-bait ...
The other day, I came across source of some older (April 2000, IIRC)
frameworks used by Omni Group. Some of the make- and config-files
use GNUstep #ifdef's others don't ... According to the license files,
you cannot release any changes, only send patches back to Omni.
Has anyone ever tried to port those to GNUstep?
I don't know if Omni would give permission to do so and let us add
them to GNUstep, but those frameworks just might spark the interest
of other developers, especially those with OS-X background ...
(eg. OmniWeb is based on those)
--
Chris
Richard Frith-Macdonald
I remember that someone ported some Omni stuff ... but I don't remember
who.
You could try looking at the archives for this list.
I suspect that Omni would want to keep control ... but they may well
accept
patches to keep their source in sync with GNUstep if you want to give
them
to them.
Chris B. Vetter
Richard Frith-Macdonald <ric...@brainstorm.co.uk> wrote:
> I remember that someone ported some Omni stuff ... but I don't
> remember who. You could try looking at the archives for this list.
> I suspect that Omni would want to keep control ... but they may well
> accept patches to keep their source in sync with GNUstep if you want
> to give them to them.
I'ld love to, but since I don't have a Mac at hand, I cannot convert
all those NIB files... :-P ... I would LOVE to see GNUstep running
OmniWeb ... *sigh*
Maybe we should all sign a petition and send it to Omni (c8
--
Chris
Jay McCarthy
if you not on the license it says you may distribute patches provided
you say certain things (like where the original is and that it's
modified etc.)
my work in progress patch is at:
www.brunswickrecords.org/~jay/
although i have a farther along one that i havent put up yet.
the patch located at that address compiles on CVS GNUstep/Linux with gcc
3.0.2 (however, one particular source file needs a fix that's in gcc cvs
to compile because of a gcc bug that hasnt been in a release yet)
below i quote Brian Convey (an Omni Support person) in response to my
email asking about a port of OmniWeb to GNUstep-
> Jay-
> I just talked briefly with Wil about this, and his response was that
the lion's share of the app was available in the frameworks we make
available, and if those were ported to GNUstep, we'd be willing to take
a look at porting the rest of the app and/or revisit the issue.
>
> I'll be happy to collect the answer to any other questions you may
have...
>
> Brian Covey
> Support Engineer
> Omni Group
last week i sent him information about my patch and the address but i
havent heard back from them. i'm still working on the patch and in
particular i need to locate ( or write ) some code to test the
frameworks with.
i dont have as much time as i used to to work on it though... so..
-Jay
--
Jay McCarthy <j...@kenyamountain.com>
David Golden
> #import is deprecated - on technical grounds - by any gcc compiler hacker
> we had the chance of talking to, both GNU and Apple folks - they have
> strong views on that point and they keep the warning turned on in the
> compiler by default.
>
As a complete ObjC newbie -
*why* is it deprecated? Does #import work anything like the Java import,
which automagically takes care of namespace merging and stuff that in C
results in that stupid, annoying, kludgy system of #include+#ifdef XXX_YYY_H ?
If ObjC #import works like Java import, surely it's a massive and stupid
step backwards to use #include +#ifdefs instead of #import ?
OTOH if it's just a synonym for #include, then fair enough...
Chris B. Vetter
Ah, cool ... sounds promising ...
--
Chris
Adam Fedor
for posting this I believe it was my fault for not realizing the problem
this would create. I fully approved of the press release and now I feel
like a dolt for saying that it should be sent out.
--
Adam Fedor, Digital Optics | I'm glad I hate spinach, because
http://www.doc.com | if I didn't, I'd eat it, and you
http://www.gnustep.org | know how I hate the stuff.
Nicola Pero
> > #import is deprecated - on technical grounds - by any gcc compiler hacker
> > we had the chance of talking to, both GNU and Apple folks - they have
> > strong views on that point and they keep the warning turned on in the
> > compiler by default.
> >
>
> As a complete ObjC newbie -
> *why* is it deprecated? Does #import work anything like the Java import,
I'm not much inside this, but I think it's because the languages are very
different -
in Java it's very easy to implement import. import imports a *class*.
when the compiler reaches an import, it checks if it has already imported
that class or not. That's it.
in C/ObjC, #import instead imports a file - which makes it not really
clearly defined because different physical files on disk might contain the
same code - but you don't want the same code to be loaded more than once
(that's the whole purpose of #import) so the compiler has to guess ... it
could check that the files are the same ? but what if they are different
versions of the same header ... they are different physically on the disk,
but should never be included twice ... all this which looks silly but then
might turn into very complex stuff for the compiler writer and might
actually cause some real mess with complicated system libraries when you
have multiple versions installed and a serious risk on including different
versions twice. I'm sure I read somewhere on the net a very definite
tricky example of a real-world case which was fooling gcc's #import into
loading the same file (with different versions perhaps) twice and crashing
compilation. Unfortunately I can't seem to find it any longer.
Anyway my explanation is probably incomplete and confused, but should give
you an idea of why the problem arises.
Defining a preprocessor tag inside the header file itself seems to be the
only real way of fixing this problem in C. The only thing I can think of
to make this prettier but still reliable would be to extend C (or ObjC)
adding a
#declare GNUSTEP_H_APPKIT
directive (or whatever the name), which would only be allowed as the first
command in a file, and would cause the compiler to behave as if
#ifndef GNUSTEP_H_APPKIT
#define GNUSTEP_H_APPKIT
where at the beginning and #endif at the end of file. The #declare would
declare a programmer-level tag marking the file, with the convention that
no two files with the same tag should be loaded ever.
Then, you could use #include in the same way as you use #import. You
would only have to add #declare GNUSTEP_H_APPKIT at the beginning of each
header file. This might make pascal happy I suppose :-) as a single
#declare per file is pretty high-levelish IMO and the compiler people as
well, because it would be well defined, reliable and efficient.
Anyway, in general #ifdef/#define looks like a minor annoyance after all.
It's a C thing, difficult to loose.
Scott Francis
i'm curious about something (yes, genuinely curious) - i am a fan of
opensource, and free software. but i've also been working in the
corporate world for quite a few years, so i'm a little out of touch.
my questions:
1. is it the position of GNU that all "paid-for" software is bad?
2. is it ok to pay for the "service" that someone supplies (ie, hours
of time and toil), rather than the finished product? can someone be
"paid" to write "opensource" or gnu software? i mean, rather, is that
considered "legit"?
3. the logical extension of this thing seems difficult to understand to
me... the position that you should not buy software seems interesting to
me... ie - don't buy the operating system, use the free one. or help
write the free one. so far so good. but how about the hardware? do we
all need to use only free hardware? how do we acquire such free
hardware? how about the firmware that runs much of the hardware? does
that need to be opensource as well?
adam, i understand why you are declining accepting the gift from vmware,
and that it doesn't fit with the gnu paradigm, but i don't think it
makes you a "dolt" :) there are people who are wanting to contribute to
gnustep who are not quite as committed to GNU in general - ie, they use
windows (god forbid) and other paid-for software, but are also
contributing to free software projects. i don't see anything wrong with
that, personally, but that seems like an individual choice. getting the
free licenses was a way to encourage those people to contribute and to
test their code on multiple platforms without having to buy multiple
machines, or dual boot them. however, advertising the provider of those
licenses doesn't fit with the free software motif.
i've used a trial version of vmware, and it is a very professionally
written product, i've enjoyed using it. i'm not willing to shell out
$300 for it though :) no matter how well advertised :) if they drop to
$50 though, then i'm in! hey, i pay for games, so why not for some
other random piece of cool software :) its entertainment value as
well... i pay for dvd's and movies and lots of other stuff...
let me close by saying: my apologies if any of this post is offensive,
i just haven't participated in many discussions on free software
philosophy, so i'm missing the FSF/GNU points of how should software
developers support themselves, when (if ever) is it okay to ask for
compensation for software written (finished product), and when (if ever)
is it okay to pay for software, hardware, services, or goods in general
(not just software).
please, feel free to take this offline and just reply to me if you want
to educate me without spamming the list :))
cheers,
scott
-----Original Message-----
From: discuss-gn...@gnu.org
[mailto:discuss-gn...@gnu.org] On Behalf Of Laurent Julliard
Sent: Friday, December 21, 2001 3:45 AM
To: discuss...@gnu.org
Subject: GNUStep: An Apology for Announcing Donation of Proprietary
Software to the Project
FYI.
http://linuxtoday.com/news_story.php3?ltsn=2001-12-21-005-20-OP-CY
----------------------
GNUStep: An Apology for Announcing Donation of Proprietary Software to
the Project
Dec 21, 2001, 07 :07 UTC (1 Talkback[s]) (933 reads)
By Adam Fedor, Chief Maintainer of the GNUstep Project
The GNUstep project would like to apologize for announcing that we had
Chris B. Vetter
"Scott Francis" <scott....@stanfordalumni.org> wrote:
[...]
> 3. the logical extension of this thing seems difficult to
> understand to me... the position that you should not buy
> software seems interesting to me... ie - don't buy the operating
> system, use the free one. or help write the free one. so far
> so good. but how about the hardware? do we all need to use only
> free hardware? how do we acquire such free hardware? how about
> the firmware that runs much of the hardware? does that need to
> be opensource as well?
You could always use OpenBIOS
(http://freshmeat.net/projects/openbios/)
> adam, i understand why you are declining accepting the gift from
> vmware,and that it doesn't fit with the gnu paradigm, but i don't
> think it makes you a "dolt" :) there are people who are wanting
> to contribute to gnustep who are not quite as committed to GNU in
> general - ie, they use windows (god forbid) and other paid-for
> software, but are also contributing to free software projects.
[...]
There are probably a couple of people, who prefer a BSD-style
license, amongst GNUstep users/developers ... nevertheless, a
quarrel over which license GNUstep should be put under won't
help "the cause" ...
--
Chris
JW
>i'm curious about something (yes, genuinely curious) - i am a fan of
>opensource, and free software. but i've also been working in the
>corporate world for quite a few years, so i'm a little out of touch.
The conflict lies in the fact that VMware's code is not open source, therefore VMWare cannot be Free Software.
I pay for every copy of SuSE I install, but I don't _have_ to - I can download the source code for it for free -- legally free.
That a simplistic answer but that's the heart of the matter.
As a comparison, it would not be against GNU ideals to pay for a CD with bochs or Plex86 on it, because bochs and Plex86 source code is Free.
>my questions:
>1. is it the position of GNU that all "paid-for" software is bad?
No, see above.
>2. is it ok to pay for the "service" that someone supplies (ie, hours
>of time and toil), rather than the finished product?
"You have our Official Blessing and Permission to pay for service"
(sorry, I just thought a funny question deserved a funny answer :-) )
> can someone be
>"paid" to write "opensource" or gnu software? i mean, rather, is that
>considered "legit"?
Well let's see. Alan Cox is paid by RedHat to work on kernel development... ...SuSE pays the salaries of several XFree86 and KDE developers.. Ximian pays Gnome people... the list could go on.
>3. the logical extension of this thing seems difficult to understand to
>me... the position that you should not buy software seems interesting to
>me...
But there is no such position.
> ie - don't buy the operating system, use the free one.
Don't confuse Free (e.g. Freedom) with free ( $$$ )
>or help
>write the free one. so far so good. but how about the hardware?
From here down is mostly pointless per above answers.
>do we
>all need to use only free hardware? how do we acquire such free
>hardware? how about the firmware that runs much of the hardware? does
>that need to be opensource as well?
>
>adam, i understand why you are declining accepting the gift from vmware,
>and that it doesn't fit with the gnu paradigm, but i don't think it
>makes you a "dolt" :)
Me neither.
> there are people who are wanting to contribute to
>gnustep who are not quite as committed to GNU in general - ie, they use
>windows (god forbid) and other paid-for software, but are also
>contributing to free software projects.
Like me.
>i don't see anything wrong with
>that, personally, but that seems like an individual choice.
It is, as it most everything in this world.
> getting the
>free licenses was a way to encourage those people to contribute and to
>test their code on multiple platforms without having to buy multiple
>machines, or dual boot them. however, advertising the provider of those
>licenses doesn't fit with the free software motif.
Bingo. I wish is had not been announced to begin with, but I"m afraid the retraction may have added more coals to the fire. I wonder how VMware feels about it all.
>i've used a trial version of vmware, and it is a very professionally
>written product, i've enjoyed using it. i'm not willing to shell out
>$300 for it though :) no matter how well advertised :) if they drop to
>$50 though, then i'm in! hey, i pay for games, so why not for some
>other random piece of cool software :) its entertainment value as
>well... i pay for dvd's and movies and lots of other stuff...
>
>let me close by saying: my apologies if any of this post is offensive,
>i just haven't participated in many discussions on free software
>philosophy, so i'm missing the FSF/GNU points of how should software
>developers support themselves, when (if ever) is it okay to ask for
>compensation for software written (finished product), and when (if ever)
>is it okay to pay for software, hardware, services, or goods in general
>(not just software).
try www.gnu.org and read some stuff. Educate yourself.
>please, feel free to take this offline and just reply to me if you want
>to educate me without spamming the list :))
>
>cheers,
>scott
----------------------------------------------------
Jonathan Wilson
System Administrator
Cedar Creek Software http://www.cedarcreeksoftware.com
Central Texas IT http://www.centraltexasit.com
Stan Shebs
>
> The #import CPP directive is defined as including a given file once
> ever in a compilation run, and that's enough to be an improvement to
> #include.
You're casually assuming that "a given file" is a well-defined
concept. In the presence of symlinks, relative paths, and multiple
-I directives on the command line, that's just not true. In fact,
correct implementation of #import requires looking at inodes to
verify identity, which is not portable because inodes are a Unix
thing. (I have a patch in Apple's GCC that does this for some
pathological cases that occur in OS X code, needs to be cleaned
up for FSF submission still.)
I think what happened with #import is that it was originally intended
to be a genuine interface-loading construct, but somewhere along the
way it got turned into an intelligent #include. #import <classname>
wouldn't have the file identity issue of #import <filename>, because
there is only one global space of classes, and behind the scenes you
could have a database of classes for the compiler to look in. Alas,
although everybody pays lip service to the idea that each #imported
h corresponds exactly to a single class interface, in practice lots
of non-class bits get slipped in, and so we're back to being just a
dialect of C, with #import being like #include, but flakier.
Stan
Nicola Pero
Ok - I think my answer was nor very precise, but I've done my homeworks
now.
> It does not matter. This kind of problem is not handled by any
> compiler/language. What if you defined two classes with the same name
> in different files with different path? Whatever the language, you can
> confuse the compiler with links to the same file. Programming
> languages/compilers don't impose any mapping between objects described
> in the language and files (that would link the language to a given
> file system!). That's why it's usefull to have higher level
> constructs in the language such as packages, modules, classes,
> whatever.
#import in C/ObjC is *not* such a higher level construct.
#import in C/ObjC *is* defined in terms of files, so in term of the
filesystem.
how do you determine if you've loaded the same file already is the problem
- I think it's not easy to implement this efficiently in a portable way
for different filesystems.
said that, I was trying to remember why the compiler people are so angry
with #import, I'm personally pretty uninterested in the #import vs
#include warfare, and if the compiler people recommend to use #include
rather than #import, I'm happy with that - if you want to use #import
instead, I'm happy with that as well.
The only thing is - yes I wouldn't mind some #preprocessor command which
would replace the #ifndef/#define/#endif trinity and declare more cleanly
a `module name' for the file, and the compiler would never load two files
with the same module name, that would be simpler and cleaner than the
#ifndef/#define/#endif trinity (though equivalent).
Jonathan B. Leffert
> On the other hand, I never had any problem using #import, working with
> projects up to ~500 classes and 4 developers. Who did?
Nor I.
> Aren't those problems just theorical?
Mostly, but there are some pathological real-world cases in which using
#import will fail. The GCC developers, I believe, feel that GCC ought to
make sure it compiles everything properly rather than adding a feature that
makes the somewhat common case easy yet completely breaks certain legacy
pieces of software. Can't say I disagree with them.
Jonathan
--
Jonathan B. Leffert <jona...@leffert.net> | "So now, less than five
years later, you can go up on a steep hill in Las Vegas and look West, and
with the right kind of eyes you can almost see the high-water mark, that
place where the wave finally broke and rolled back." -- Hunter S. Thompson
Fred Kiefer
that I can't agree more to what Nicola wrote. I would not be working on
GNUstep if this project wasn't under LGPL and this is more important
than what ever I think of the original announcement or the apology or
even of paid software as a general issue. And of course Adam is no
"dolt" (A term I had to look up in my copy of Webster's. Isn't free
software great, we learn so many new things every day...).
Fred
Scott Francis
$$ instead of free == opensource/free source... doh. must be the
holiday celebrations addling my wits :)
sorry for the bandwidth, but i do appreciate the responses!
happy holidays,
scott
-----Original Message-----
From: discuss-gn...@gnu.org
[mailto:discuss-gn...@gnu.org] On Behalf Of Fred Kiefer
Sent: Friday, December 21, 2001 7:33 PM
To: Nicola Pero
Cc: Jeremy Bettis; discuss...@gnu.org
Subject: Re: GNUStep: An Apology for Announcing Donation of
ProprietarySoftware to the Project
Pedro Ivo Andrade Tavares
>I hope that's not flame-bait ...
>
>The other day, I came across source of some older (April 2000, IIRC)
>frameworks used by Omni Group. Some of the make- and config-files
>use GNUstep #ifdef's others don't ... According to the license files,
>you cannot release any changes, only send patches back to Omni.
>
>Has anyone ever tried to port those to GNUstep?
>I don't know if Omni would give permission to do so and let us add
>them to GNUstep, but those frameworks just might spark the interest
>of other developers, especially those with OS-X background ...
>(eg. OmniWeb is based on those)
I did, around that timeframe... I sent my patches to them, and it would
seem some of my changes were integrated on their main sources... Search the
list archives, and you'll find some comments I made at the time.
After my (admittedly naïve) port, Karl Kraft had another go at it, and he
also sent them his patches.
The license is something I can live with. It's similar to qmail's, but not
so restrictive.
Pedro Ivo
Philippe C.D. Robert
doomed to fail - like all other 'extreme' ways of dealing with realities. This
is a very poor move. I am deeply disappointed.
I am seriously considering to release the next gen 3DKit under a BSD style license and remove the 'GNU' from its name.
-Phil
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep
>
--
Philippe C.D. Robert
Software Engineer
Silicon Graphics, Inc.
Philippe C.D. Robert
Fred Kiefer <FredK...@gmx.de> wrote:
> I don't want to add more mails to this discussion, I just want to state
> that I can't agree more to what Nicola wrote. I would not be working on
> GNUstep if this project wasn't under LGPL and this is more important
LGPL and GNU is not the same thing. The point which disappoints me is
that GNU seems to be so 'extreme' in its position. If this donation can help
the GNUstep project and if the company made their donation exactly because of
that, then I just fail to see why such a donation should be 'bad per se'. This
is why I am disappointed, it is not LGPL or GPL or the annoying 'free vs closed
software discussion'. It is the fact the Adam has to write an email to apologize
for accepting a donation which was intended to help all of us, in the end!
Based on the fact that most of the GNU developers use closed sources all day
anyway, ie. the bios, the micro code in their CPUs and so on, this looks very
cynical (and wrong) to me.
-Phil
David Golden
> This is exactly one of the reasons IMHO why GNU will never succeed, why it
> is doomed to fail - like all other 'extreme' ways of dealing with
> realities. This is a very poor move. I am deeply disappointed.
>
I'd have to say the poor move was accepting the donation in the first place
(even poorer if the donation was sought after) - particularly given the
existence of plex86. I don't regard the GNU project position as
particularly "extreme" in software licensing - the extreme ones are the
proprietary software corporations who are fighting to make things like
restrictive EULAs (which are not simply based on copyright laws, unlike the
GPL) fully enforceable worldwide. The GPL doesn't require new laws, their
position does.
I certainly don't think GNU is doomed to fail. After all, it's shown
slow-and-steady growth for years, unlike the flash-in-the-pan fly-by-nights
in the bulk of the proprietary world.
And anyway, it's a common trick in debating and law to take a _really_
extreme position to soften the blow of a slightly less extreme one - things
like the SSSCA are softening people up so they may even be happy about letting
a slightly less draconian, but still really bad, thing through - So, if
anything, given the new pulls on the pendulum from the "opposing side"* to
the FSF, we should expect the formation of a much more extreme organisation
than the FSF, but pulling the pendulum on the "same side", perhaps one
calling for mandated "Total Freedom of Information", calling for new laws in
which is is a civil offense to withhold any pattern of information from
anyone, using a similar line of reasoning about software to the one David
Brin uses about personal informations in "The Transparent Society - Will
Technology Force use to choose between Privacy and Freedom" (no, this is NOT
the same as the Big Brother scenario - see
http://www.kirthrup.com/brin/tschp1.html)
This of course, leads to an escalation of sillyness, but hey, that's life...
* I've put these in quotation marks becasue the software licensing issue
isn't really a 1-D spectrum.
David Golden
> http://www.kirthrup.com/brin/tschp1.html)
>
URL should be http://www.kithrup.com/brin/tschp1.html
Jeff Teunissen
>
> I don't want to add more mails to this discussion, I just want to state
> that I can't agree more to what Nicola wrote. I would not be working on
> GNUstep if this project wasn't under LGPL and this is more important
> than what ever I think of the original announcement or the apology or
> even of paid software as a general issue. And of course Adam is no
> "dolt" (A term I had to look up in my copy of Webster's. Isn't free
> software great, we learn so many new things every day...).
[snip]
Actually, I don't think this discussion, as it was started, had ANYTHING to do
with the licenses involved. It's not about LGPL vs. GPL vs. BSD vs. anything
else -- it's about GNU, and the differences between Stallman-style Free
Software and Debian-style Free Software, also known as Open Source. Both
styles accept the same licenses, but Stallman's version is basically that no
one should have the right to create proprietary software, while Debian's
version is that we don't have to use it and don't have to support it, but
we're just fine with it existing.
--
| Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net
| GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project http://www.quakeforge.net/
| Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Jeff Teunissen
>
> Ok - I think my answer was nor very precise, but I've done my homeworks
> now.
>
> > It does not matter. This kind of problem is not handled by any
> > compiler/language. What if you defined two classes with the same name
> > in different files with different path? Whatever the language, you can
> > confuse the compiler with links to the same file. Programming
> > languages/compilers don't impose any mapping between objects described
> > in the language and files (that would link the language to a given
> > file system!). That's why it's usefull to have higher level
> > constructs in the language such as packages, modules, classes,
> > whatever.
>
> #import in C/ObjC is *not* such a higher level construct.
>
> #import in C/ObjC *is* defined in terms of files, so in term of the
> filesystem.
How so? #include isn't, so how is #import?
[snip]
JW
>On Sat, 22 Dec 2001 02:33:29 +0100
>Fred Kiefer <FredK...@gmx.de> wrote:
>> that I can't agree more to what Nicola wrote. I would not be working on
>> GNUstep if this project wasn't under LGPL and this is more important
>
>that GNU seems to be so 'extreme' in its position. If this donation can help
>the GNUstep project and if the company made their donation exactly because of
>that, then I just fail to see why such a donation should be 'bad per se'.
The donation is not 'bad per se'. The unnecessary proclamation of a GNU project utilizing non-Free software is what was 'bad per se'.
>This
>is why I am disappointed, it is not LGPL or GPL or the annoying 'free vs closed
>software discussion'. It is the fact the Adam has to write an email to apologize
>for accepting a donation which was intended to help all of us, in the end!
Adam did not _have_ to apologize. IMHO sending out an "official" retraction looked worse then the original message did, though in a certain sense I understand that Adam felt a need to "correct" his original mistake.
>Based on the fact that most of the GNU developers use closed sources all day
>anyway, ie. the bios, the micro code in their CPUs and so on, this looks very
>cynical (and wrong) to me.
>
>-Phil
>--
>Philippe C.D. Robert
>Software Engineer
>Silicon Graphics, Inc.
----------------------------------------------------
Paul Seelig
> Announcing this problematical donation was a further mistake, because
> it had the effect of advertising the proprietary program.
>
Just too bad that such a IMHO silly public apology will even further
contribute to such an advertising, isn't it? An above all it'll
publically ridicule the GNUstep project. What a pity!
(shakes head) P. *8^/
PS: People get real: The software in question is a fantastic
commercial project and is worth every penny of it - albeit expensive
for the average user not interested in only running MS-only OS's.
--
------------ Paul Seelig <pse...@mail.uni-mainz.de> -------------
African Music Archive - Institute for Ethnology and Africa Studies
Johannes Gutenberg-University - Forum 6 - 55099 Mainz/Germany
------------------- http://ntama.uni-mainz.de --------------------
Chris B. Vetter
Pedro Ivo Andrade Tavares <ptav...@iname.com> wrote:
> I did, around that timeframe... I sent my patches to them, and it
> would seem some of my changes were integrated on their main sources..
> time.
> After my (admittedly naïve) port, Karl Kraft had another go at it,
> and he also sent them his patches.
That would explain all the #ifdef GNUSTEP ...
> The license is something I can live with. It's similar to qmail's,
> but not so restrictive.
So can I, but - (I admit, I'm not savvy when it comes to the GNU
license) if we could get Omni to allow us to use their framework
(that is, the source, ported to GNUstep, with their approval)
"as is" - we might get more developers interested in GNUstep.
--
Chris
Pedro Ivo Andrade Tavares
>On Sat, 22 Dec 2001 03:15:51 -0200
>Pedro Ivo Andrade Tavares <ptav...@iname.com> wrote:
> > would seem some of my changes were integrated on their main sources..
> > time.
> > After my (admittedly naïve) port, Karl Kraft had another go at it,
> > and he also sent them his patches.
>
Well, I haven't looked at these frameworks in a long time, so I can't tell
you which parts are mine and which are Karl's. I can tell you the Omni guys
were very open to our contact, though.
> > The license is something I can live with. It's similar to qmail's,
> > but not so restrictive.
>
>So can I, but - (I admit, I'm not savvy when it comes to the GNU
>license) if we could get Omni to allow us to use their framework
>(that is, the source, ported to GNUstep, with their approval)
>"as is" - we might get more developers interested in GNUstep.
Indeed we would. I like OmniFoundation a lot, and OmniNetworking, in my
opinion, should be the defacto standard for network programming in ObjC.
The OmniGroup developers seem interested in supporting GNUstep. However,
they are a very small team, and haven't got the resources to track the
differences in implementation. It's up to us to show them it can be done
cleanly and easily (which I do hope is truer now than two years ago).
If the frameworks compiled cleanly on GNUstep, they would certainly
consider a OmniWeb port. I'd love to see that!
Pedro Ivo Tavares
Leandro Guimarães Faria Corsetti Dutra
> This is just one more reason that GNUStep should not be a GNU project.
You are entitled to not see the benefits of freedom. But then perhaps
you do not deserve it.
> Other reasons:
> GNUstep could use other publicaly avaliable code (like darwin or other apple
> changes to gcc/gdb) without a copyright assignment.
That would make it much harder to enforce the GNU GPL to get software
hoarders such as Apple in line.
> Wouldn't it be nice to do what's best for the project and not what is best
> for the GNU manafesto?
Depends on the project's goals -- being part of the GNU Project the
most important one is freedom.
Robert Hartley
This got me thinking about the ability to upgrade the microcode on Intel
Pentium chips, which they can (and do?)provide updates for. (I won't get
into a discussion on the Pentium chips being a mere VMware 'clone' encased
in plastic, ergo we all have to go to another platform if Intel refuses to
publish their micro code.)
Has anyone explored these new open sourced microcode CPUs?
Details?
thanks,
Robert
Laurent Julliard wrote:
> FYI.
>
> http://linuxtoday.com/news_story.php3?ltsn=2001-12-21-005-20-OP-CY
>
> ----------------------
>
> GNUStep: An Apology for Announcing Donation of Proprietary Software to the
> Project
> Dec 21, 2001, 07 :07 UTC (1 Talkback[s]) (933 reads)
>
> By Adam Fedor, Chief Maintainer of the GNUstep Project
<snip>