Open Source Admin Tool Project
Thad Phetteplace
provide a system administration tool for Linux, FreeeBSD and other
platforms. I've heard about similar commercial ventures by IBM, Sun,
and others, but have not found an open source project that quite fits
the image I have in my head. I am imagining a system written in several
layers. From the bottom up they go like this:
1) An admin library. This supplies a standard set of function calls
that do things like add/modify/delete a user, configure printers,
tweak network settings in the rc scripts, etc. This library provides
the platform specific part. It should include functions for querying
about the operating systems capabilities and features (i.e. we shouldn't
display a DNS admin option if the box doesn't run a DNS).
2) A server. Your basic TCP daemon that talks to a client piece and
includes support for robust user authentication and encryption of
the data stream.
3) A standardized protocol for talking between the client and server. It
should be inherently extensible, allowing new features to be added to
client and server without redefining the protocol.
4) The client piece. I envision a Java app to start with, partially
because of the cross-platform development benefits, but mainly
because I want an excuse to program in Java. :-) There is no reason
that various client versions could not be written, so if you want a
admin tool that integrates with the KDE desktop or whatever, it should
be easy to do.
Directory services (X500 style, like NDS) should be kept in mind while
designing this beast. Any good open source directory service projects
or resources I should know about?
It should be easy to plug new feature sets into the system (like an
apache admin set for example). Any thoughts on the best way to
facilitate that?
Are there any *cross platform* projects like this already begun?
What about the client/server protocol? Any existing protocols I should
look at or build on top of?
My reference platforms will be Linux and FreeBSD, but the app should
port easily to other platforms. It has been inspired by a bunch of
ugly hacks I pieced together here at DIAS to make the admin of our
servers easier for the non-technical staff. I've been telling myself
for a while that I would throw the current mess out and do it *the
right way*. I plan on implementing a trimmed down version of all four
layers and then release it as open source for further development.
right now I am collecting info for the basic design. Any input will
be greatly appreciated.
--
Thad Phetteplace
President - DIAS, Inc.
tdph...@dias.net
Christopher B. Browne
posted:
>provide a system administration tool for Linux, FreeeBSD and other
>platforms. I've heard about similar commercial ventures by IBM, Sun,
>and others, but have not found an open source project that quite fits
>the image I have in my head.
I take it that neither COAS nor Linuxconf are suitable to your purposes?
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
cbbr...@hex.net - "What have you contributed to Linux today?..."
Dominic Mitchell
> Are there any *cross platform* projects like this already begun?
Had a look at GNU cfengine?
--
Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator
"Xerox studies suggest that most people print out electronic mail
that is longer than half a page; paper use rises by 40 percent in
offices that introduce E-mail." -- CCM
Jonathan Abbey
Thad Phetteplace <tdph...@ren.dias.net> wrote:
|
| I've been dabbling with the idea of starting an open source project to
| provide a system administration tool for Linux, FreeeBSD and other
| platforms. I've heard about similar commercial ventures by IBM, Sun,
| and others, but have not found an open source project that quite fits
| layers. From the bottom up they go like this:
|
| 1) An admin library. This supplies a standard set of function calls
| that do things like add/modify/delete a user, configure printers,
| tweak network settings in the rc scripts, etc. This library provides
| the platform specific part. It should include functions for querying
| about the operating systems capabilities and features (i.e. we shouldn't
| display a DNS admin option if the box doesn't run a DNS).
|
| 2) A server. Your basic TCP daemon that talks to a client piece and
| includes support for robust user authentication and encryption of
| the data stream.
|
| 3) A standardized protocol for talking between the client and server. It
| should be inherently extensible, allowing new features to be added to
| client and server without redefining the protocol.
|
| 4) The client piece. I envision a Java app to start with, partially
| because of the cross-platform development benefits, but mainly
| because I want an excuse to program in Java. :-) There is no reason
| that various client versions could not be written, so if you want a
| admin tool that integrates with the KDE desktop or whatever, it should
| be easy to do.
|
| Directory services (X500 style, like NDS) should be kept in mind while
| designing this beast. Any good open source directory service projects
| or resources I should know about?
Yes, as a matter of fact. We've been working for the last 3 years on just such
a beast. It's called Ganymede, and you can read about it at
http://www.arlut.utexas.edu/gash2
It's written in Java, is client/server, has a built in object database
and support for pluggable Java classes for object management. The
database schema is editable using a GUI editing tool. It is not X.500
or LDAP based, and it is only designed to handle on the order of
50,000 records, but it works well.
I'm going to be presenting the work at this year's LISA conference
next month up in Boston. You can read a preprint of our paper for
LISA at the bottom of the aforementioned web page.
Note that we are still working on getting approval for releasing the
project under the GNU General Public License. If you sign up for the
development mailing list, you'll get an informative message which
includes directions on downloading the system via ftp. Right now the
developer's pre-release does not include most of the system's source,
but it does include full javadocs and source code for all of the
customization classes.
The system is in late beta.. we'll probably put out Ganymede 1.0
within the next month or so, assuming approval for GPL licensing goes
through.
| --
| Thad Phetteplace
| President - DIAS, Inc.
| tdph...@dias.net
|
--
-------------------------------------------------------------------------------
Jonathan Abbey jona...@arlut.utexas.edu
Applied Research Laboratories The University of Texas at Austin
-------------------------------------------------------------------------------
Thad Phetteplace
>
> I take it that neither COAS nor Linuxconf are suitable to your purposes?
Thanks for the pointer to COAS. It comes closest to what I am shooting for.
It might be possible to build the client/server layer as an extension on top
of the COAS API. I will need to investigate it more to see what extent
I can build on top of or at least interoperate with COAS. Also, thank you
to everyone else who has posted or emailed responses. There have a great
many useful suggestions and pointers to related projects. I am drafting
a preliminary design doc that I will publish to a web page. Your feedback
is appreciated.
Thanks,
Thad
Michael Maxwell
>
> Note that we are still working on getting approval for releasing the
> project under the GNU General Public License. If you sign up for the
Please, for the sake of all programmers, PLEASE release it under the
BSD license...
--
drwho @ xnet.com, BOFH -- http://www.xnet.com/~drwho/
America: where you're free to do as you're told.
Jonathan Abbey
Michael Maxwell <dr...@No-Spam-see.sig> wrote:
| bro...@arlut.utexas.edu (Jonathan Abbey) writes:
|
| >
| > Note that we are still working on getting approval for releasing the
| > project under the GNU General Public License. If you sign up for the
|
| Please, for the sake of all programmers, PLEASE release it under the
| BSD license...
Wow, that's a pretty dramatic plea. What would be the benefit of
doing so?
| --
| drwho @ xnet.com, BOFH -- http://www.xnet.com/~drwho/
| America: where you're free to do as you're told.
--
Michael Maxwell
> | > Note that we are still working on getting approval for releasing the
> | > project under the GNU General Public License. If you sign up for the
> |
> | Please, for the sake of all programmers, PLEASE release it under the
> | BSD license...
>
> Wow, that's a pretty dramatic plea. What would be the benefit of
> doing so?
The benefit of doing so is that we, as programmers, are not restricted
by the GPL source "requirements", etc... And commercial developers
*also* will be less likely to be scared away by the open-source
"requirement" of the GPL.
Say I created a program based on this project. If it's GPL, I *have*
release my code as GPL (or parts that are derived from the original
code) whether I like it or not. So much for consistency. So much for
standards.
GPL is "restrictively unrestrictive".
--
drwho @ xnet.com BOFH -- http://www.xnet.com/~drwho/
Please don't email replies to Usenet postings.
Phil Brutsche
> bro...@arlut.utexas.edu (Jonathan Abbey) writes:
>
> > | > Note that we are still working on getting approval for releasing the
> > | > project under the GNU General Public License. If you sign up for the
> > |
> > | Please, for the sake of all programmers, PLEASE release it under the
> > | BSD license...
> >
> > Wow, that's a pretty dramatic plea. What would be the benefit of
> > doing so?
>
> The benefit of doing so is that we, as programmers, are not restricted
> by the GPL source "requirements", etc... And commercial developers
> *also* will be less likely to be scared away by the open-source
> "requirement" of the GPL.
>
This is all very true. But consider this from a certain Linus Torvalds
(paraphrased, of course):
"He who writes the code decides the license. Anyone else is just a
whiner."
If the author of the administration tool suite decides to release under
the GPL, more power to him.
----------------------------------------------------------------------
Phil Brutsche
"Be of stout heart, Number One. We've handled the Borg. We can
certainly handle Admiral Jellico." - Jean-Luc Picard
Help stop spam! Visit http://www.cauce.org
----------------------------------------------------------------------
je...@dementia.mishnet
>bro...@arlut.utexas.edu (Jonathan Abbey) writes:
>
>> | > Note that we are still working on getting approval for releasing the
>> | > project under the GNU General Public License. If you sign up for the
>> |
>> | Please, for the sake of all programmers, PLEASE release it under the
>> | BSD license...
>>
>> Wow, that's a pretty dramatic plea. What would be the benefit of
>> doing so?
>
>The benefit of doing so is that we, as programmers, are not restricted
>by the GPL source "requirements", etc... And commercial developers
>*also* will be less likely to be scared away by the open-source
>"requirement" of the GPL.
That doesn't slow down the industry in console gaming
one bit. While a pure GPL has it's problem, LGPL quite
adequately addresses them. Whining that the GPL needs
to be replaced with the BSD licence is deceptive at best.
>
>Say I created a program based on this project. If it's GPL, I *have*
>release my code as GPL (or parts that are derived from the original
>code) whether I like it or not. So much for consistency. So much for
>standards.
>
>GPL is "restrictively unrestrictive".
Then don't muck about with the sourcecode. It's typically
not good programming practice anyways.
--
Unix had startmenus and tasbars before Microsoft |||
even had a decent memory manager for DOS. / | \
In search of sane PPP docs? Try http://penguin.lvcm.com
Jonathan Abbey
Michael Maxwell <dr...@No-Spam-see.sig> wrote:
| bro...@arlut.utexas.edu (Jonathan Abbey) writes:
| >
| > Wow, that's a pretty dramatic plea. What would be the benefit of
| > doing so?
|
| The benefit of doing so is that we, as programmers, are not restricted
| by the GPL source "requirements", etc... And commercial developers
| *also* will be less likely to be scared away by the open-source
| "requirement" of the GPL.
|
| release my code as GPL (or parts that are derived from the original
| code) whether I like it or not. So much for consistency. So much for
| standards.
Of course, that doesn't bother me a great deal, in principle. In
practice, I can see how one might want to be able to write a
commercial utility that would talk to the Ganymede server, yet would
be forced to be GPL'ed, as there are certain classes that would have
to be bound to the client.
| GPL is "restrictively unrestrictive".
Of course, that's the point. In any case, I don't speak for the
university or their lawyers, and they are the ones who set the
guidelines for what sort of licensing is acceptable in this situation.
| --
| drwho @ xnet.com BOFH -- http://www.xnet.com/~drwho/
| Please don't email replies to Usenet postings.
--
Jeremy Nelson
>: Say I created a program based on this project. If it's GPL, I *have*
>: release my code as GPL (or parts that are derived from the original
>: code) whether I like it or not.
>
>If that's my condition for giving you access to my work you're free to take
>it or leave it. What's wrong with that? I wouldn't force you to write
>anything based on my code. But if you did you would have to do it by my
>rules.
Because its an extremist position and hinders code use and re-use. It
also gives the unwashes masses the impression that "free software authors"
are not writing software for the benefit of mankind, but to further a
strange and extreme political agenda (to them).
And to those who write free software to be used by all regardless of
purpose, it fosters ill-will and makes people suspicious your good intentions.
Which is not a problem if that does not bother you. Some people think that
software hoarding is a good strategy to use against software hoarders.
Jeremy
--
j...@enteract.com
Four
Lines
Suffice.
Eivind Eklund
> On 17 Nov 1998 12:47:01 -0600, Michael Maxwell <dr...@No-Spam-see.sig> wrote:
> >by the GPL source "requirements", etc... And commercial developers
> >*also* will be less likely to be scared away by the open-source
> >"requirement" of the GPL.
>
> one bit. While a pure GPL has it's problem, LGPL quite
> adequately addresses them. Whining that the GPL needs
> to be replaced with the BSD licence is deceptive at best.
What the fuck are you talking about? Sorry for the language, but the
GPL does block use in console gaming, and when I did console
programming, this did occasionally slow me down.
As for LGPL 'adequately addresses them': Talk to FSF about accepting
use of shared libraries as OK under the LGPL, then come back and
repeat that statement. Oh, and look at modern compiler technology,
and how the LGPL 'adequately address that'. The LGPL is a minefield;
proprietary developers with a clue will consider LGPLed code as if it
was GPLed, keeping it far away from their programs unless they can use
the fact that interfaces can't be copyrighted to keep it clean.
Eivind.
je...@dementia.mishnet
It doesn't slow us down a bit. It doesn't slow Applix down
a bit. It doesn't slow Oracle down a bit. It never slowed
Corel down a bit. It didn't slow down ID or Origin.
Commercial software can and does link to lgpl libraries to
their hearts content on a regular basis.
You're just spreading FUD & rather pathetic FUD at that given
the wealth of counter examples.
Eivind Eklund
> >What the fuck are you talking about? Sorry for the language, but the
> >GPL does block use in console gaming, and when I did console
> >programming, this did occasionally slow me down.
> >
> >As for LGPL 'adequately addresses them': Talk to FSF about accepting
> >use of shared libraries as OK under the LGPL, then come back and
> >repeat that statement. Oh, and look at modern compiler technology,
> >and how the LGPL 'adequately address that'. The LGPL is a minefield;
> >proprietary developers with a clue will consider LGPLed code as if it
> >was GPLed, keeping it far away from their programs unless they can use
> >the fact that interfaces can't be copyrighted to keep it clean.
>
> It doesn't slow us down a bit. It doesn't slow Applix down
> a bit. It doesn't slow Oracle down a bit. It never slowed
> Corel down a bit. It didn't slow down ID or Origin.
Listing companies that have been careless does not consist proof that
they're not careless. And saying "it didn't slow down" requires exact
knowledge of the development processes; I doubt you have that for all
those companies. You're spreading unfounded claims and muddling the
issues.
> Commercial software can and does link to lgpl libraries to
> their hearts content on a regular basis.
... just as they could link to GPLed libraries to their heart's
content; they just might get trouble afterwards.
Clue:
* The GPL is not infective over an interface boundary, as interface
copyrights have been rejected by the courts.
* The LGPL is not infective over an interface boundary, due to the
license text and that interface copyrights have been rejected by the
courts.
* Use of a shared library may or may not be an interface boundary, due
to problems with linker & compiler technology that may in some cases
push library code into the executable, even for shared libraries.
My view is that the GPL does cover its goals nicely, is pretty
explicit about it, and should not be a problem for somebody that is
careful about licenses. I think they are wrong goals for a lot of
cases, but that is another discussion.
LGPL, on the other hand, is a dangerous license because a lot of
people seems to think it is different from the GPL. It is not. Due
to the precedents in the area, the LGPL and the GPL have just about
the exact same effect, except that the LGPL is more explicit in
denying people the ability to create 'work-around-the-GPL' interfaces
(something which may or may not hold up in court).
IMO, the closest you get to a 'GPL-like' license for libraries that
also allow safe commercial use is something like the Eiffel Forum
License. This require you to distribute sources to the library if you
make modifications to it, but allow free use otherwise. I think this
is a fair way of doing it.
> You're just spreading FUD & rather pathetic FUD at that given
> the wealth of counter examples.
Where are your legal precedents (not examples of companies) for your
claims? What you've come with so far is examples that some companies
ignore the problems (I believe this is due to not even considering the
problems with shared libraries, which again is due to the GPL crowd
pushing these issues under the carpet). You've done nothing to
substantiate your claim that 'the GPL does not slow down the industry
in console gaming one bit' [SIC] which I debunked by pointing out with
an example of it slowing console gaming down, and you've not done
anything to substantiate your claim that the LGPL adequately addresses
the problem with executables being 'derivative works'. (The problem
is blatantly obvious in C if you have macros or inline functions; it
can be present in other cases, too.)
Oh, and please de-fake your address. Fake addresses have no place in
serious discussions. (No, mine is not fake; I can't remember ever
having used a fake address.)
Eivind.
h...@lucon.org
Eivind Eklund <eiv...@yes.no> wrote:
> Listing companies that have been careless does not consist proof that
> they're not careless. And saying "it didn't slow down" requires exact
> knowledge of the development processes; I doubt you have that for all
> those companies. You're spreading unfounded claims and muddling the
> issues.
You seem to imply that the lawyers from those commercial
software companyes never bothered to take a look at the
Linux license before they put out commercial softwares
for Linux.
As a Linux developer, I am very glad to see those commercial
available for Linux. As a matter of fact, we are making sure
it is legal to do so under the Linux license. Here is a sample
statement from the revised GNU/Linux license for glibc:
As a special exception, if you link this library or the library,
which is licensed under the GNU Library General Public License
and contains this library, to produce an executable or shared object
file, this does not cause the resulting executable or shared object
file to be covered by the GNU General Public License. This
exception does not however invalidate any other reasons why the
executable or shared object file might be covered by the GNU General
Public License.
This is to clear up any misconceptions about the Linux license. The
final version should be similar to this. Basically, it is ok to use
glibc to produce commercial softwares, shared or executable.
H.J.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Daniel Taylor
>>Michael Maxwell <dr...@No-Spam-see.sig> wrote:
>>: Say I created a program based on this project. If it's GPL, I *have*
>>: release my code as GPL (or parts that are derived from the original
>>: code) whether I like it or not.
>>
>In article <36531...@news.ivm.net>, Noses <no...@noses.com> wrote:
>>If that's my condition for giving you access to my work you're free to take
>>it or leave it. What's wrong with that? I wouldn't force you to write
>>anything based on my code. But if you did you would have to do it by my
>>rules.
>
>Because its an extremist position and hinders code use and re-use. It
>also gives the unwashes masses the impression that "free software authors"
>are not writing software for the benefit of mankind, but to further a
>strange and extreme political agenda (to them).
>
for "use and reuse". Sure it is an extreme position, but if someone
puts that license on their code they intend code release, rather than
money, to be the price for using the code.
Demanding that everyone who wants to use your code pay you money
is an extreme position as well, but few people seem to have a problem
with it in the USA.
>And to those who write free software to be used by all regardless of
>purpose, it fosters ill-will and makes people suspicious your good intentions.
>Which is not a problem if that does not bother you. Some people think that
>software hoarding is a good strategy to use against software hoarders.
>
The GPL does not decree purpose. You may sell a GPL'd product.
You simply **MUST** include the source code.
What is the problem with that?
--
Daniel Taylor
Unix is a Linux-like operating system.
Charlie Sorsby
= The benefit of doing so is that we, as programmers, are not restricted
= by the GPL source "requirements", etc... And commercial developers
= *also* will be less likely to be scared away by the open-source
= "requirement" of the GPL.
Just curious: That being the case, why is it that so much of the
commercial software available for FreeBSD must be run under linux
emulation (my understanding being that linux is GPL)?
And even that (commercial software) which is available for FreeBSD
seems to have been available for linux first.
Lest I be misunderstood, what I'm asking is this: My understanding
is that linux is GPL and yet there seems to be more commercial software
available for linux than for FreeBSD which is not. Even allowing
for the bigger user base, if GPL is so frightening to commercial
software developers, one would think that that would even things out
more so that availability of commercial software is about equally
available under both. Why does that not seem to be the case?
Wouldn't it make sense for these commercial developers, wary of the
GPL, to develop software first for *BSD with its less restrictive
license and then port it to linux? What am I missing?
I'm not saying that you're wrong; only that my (admittedly limited)
observation seems to be inconsistent with your observation.
= Say I created a program based on this project. If it's GPL, I *have*
= release my code as GPL (or parts that are derived from the original
= code) whether I like it or not. So much for consistency. So much for
= standards.
=
= GPL is "restrictively unrestrictive".
--
Best regards,
Charlie "Older than dirt" Sorsby Wheeling, WV "I'm the NRA!"
c...@hgo.net www.hgo.net/~crs USA Life Member since 1965
Fred Weigel
>
> In article <slrn756kv...@dementia.mishnet> je...@dementia.mishnet () writes:
>
> > >What the fuck are you talking about? Sorry for the language, but the
> > >GPL does block use in console gaming, and when I did console
> > >programming, this did occasionally slow me down.
> > >
> > >As for LGPL 'adequately addresses them': Talk to FSF about accepting
> > >use of shared libraries as OK under the LGPL, then come back and
> > >repeat that statement. Oh, and look at modern compiler technology,
> > >and how the LGPL 'adequately address that'. The LGPL is a minefield;
> > >proprietary developers with a clue will consider LGPLed code as if it
> > >was GPLed, keeping it far away from their programs unless they can use
> > >the fact that interfaces can't be copyrighted to keep it clean.
> >
> > It doesn't slow us down a bit. It doesn't slow Applix down
> > a bit. It doesn't slow Oracle down a bit. It never slowed
> > Corel down a bit. It didn't slow down ID or Origin.
>
> they're not careless. And saying "it didn't slow down" requires exact
> knowledge of the development processes; I doubt you have that for all
> those companies. You're spreading unfounded claims and muddling the
> issues.
>
If code gets put "in-line" due to compiler technology from a shared
library... well... that's a very dumb thing to do. May I suggest
that you only use tools which won't do that? How in blazes would
the tool knpw what to copy? In general, this is FUD. Oh, its very
good FUD, but its FUD.
Clue: If code is statically brought in from a shared library, it
wouldn't be shared now, would it? Also, it can't be updated now,
can it? That would be a very stupid use of a SHARED library,
wouldn't it? So, it won't happen. Therefore, your argument is
just FUD.
If that point is ignored (as it should be), the rest of your
anti-LGPL rant doesn't hold up. StarOffice, Corel etc. are just
fine. Oh -- the libc authors aren't going to sue them -- really.
The GPL crowd doesn't have to push these issues under the
carpet. This issue is a non-starter.
If you are REALLY worried about being sued, then partially link
your application, and distribute that. End of issue. (LGPL says
its ok, as long as a new version of the LGPL'd library can be linked
to you application).
But I like the way you tried to argue that. It sounded... almost
plausible.
Fred Weigel.
PS. My email address IS munged -- you can figure it out if you
really want to email me. There are just too many spammers and
too few comets...
Michael Maxwell
> This is all very true. But consider this from a certain Linus Torvalds
> (paraphrased, of course):
>
> "He who writes the code decides the license. Anyone else is just a
> whiner."
>
> If the author of the administration tool suite decides to release under
> the GPL, more power to him.
>
This is true: it is his choice.
However, I have a quote, too:
"The squeaky wheel gets the grease."
:)
Michael Maxwell
> Because its an extremist position and hinders code use and re-use. It
> also gives the unwashes masses the impression that "free software authors"
> are not writing software for the benefit of mankind, but to further a
> strange and extreme political agenda (to them).
And in many cases, they are. Read some of the writings of Richard
Stalin^H^Hlman and you'll see what I mean.
>
> And to those who write free software to be used by all regardless of
> purpose, it fosters ill-will and makes people suspicious your good intentions.
> Which is not a problem if that does not bother you. Some people think that
> software hoarding is a good strategy to use against software hoarders.
Don't get me wrong here... I have nothing against GPL and I believe
that it is beneficial to the development of "free" software. But GPL
isn't the ONLY way to do it, nor is it necessarily the best. My only
argument with GPL is that it is, as I previously stated,
"restrictively unrestrictive" and has a habit of "infecting" any
derivative work.
In the case of an ORIGINAL work, I can understand it, but GPL should
*not* have to be carried over from the original to derived works, but
should rather be the decision of the author of the derived work --
provided the author of the derived work isn't just copying the
original verbatim... in which case, he shouldn't be programming in the
first place :)
Chris Goellner
>
> "The squeaky wheel gets the grease."
Of course the counter quote:
"The raised nail gets the hammer."
And my favorite
"The early worm gets eaten."
Which doesn't really fit into this conversation but its one of my
favorites.
Michael Maxwell
> Just curious: That being the case, why is it that so much of the
> commercial software available for FreeBSD must be run under linux
> emulation (my understanding being that linux is GPL)?
Quite simple: Linux has a much larger user base, especially among
desktop users. It's more popular: the squeaky wheel gets the grease.
But you forget that quite a large amount of (mostly non-desktop)
software and even OS's has been based around the BSD license, or
derived from it (commercial software, that is...)
>
> Wouldn't it make sense for these commercial developers, wary of the
> GPL, to develop software first for *BSD with its less restrictive
> license and then port it to linux? What am I missing?
It doesn't really apply in this case anyway -- the commercial
developers aren't releasing their code as GPL, now are they?
> I'm not saying that you're wrong; only that my (admittedly limited)
> observation seems to be inconsistent with your observation.
If Corel and Applix and so on were releasing their code as GPL'ed,
then I'd agree with you here. But they're not.
--
drwho @ xnet.com, BOFH -- http://www.xnet.com/~drwho/
V pna'g oryvrir lbh npghnyyl obgurerq gb qrpbqr guvf...
Eivind Eklund
> If code gets put "in-line" due to compiler technology from a shared
> library... well... that's a very dumb thing to do. May I suggest
> that you only use tools which won't do that?
Can you point me at some?
> How in blazes would the tool knpw what to copy?
Have you read the C standard recently? How about the C++ standard?
They have these blasted 'arrays' (for which size information can be
encoded), 'macros', and 'static functions' (in some versions called
'inline', which really is a nonsense keyword - the compiler can fully
inline a static function, and can drop inlining a function marked
'inline'). As I said, inlining is a blatantly obvious example of what
can make the LGPL screw you.
> Clue: If code is statically brought in from a shared library, it
> wouldn't be shared now, would it? Also, it can't be updated now,
> can it? That would be a very stupid use of a SHARED library,
> wouldn't it? So, it won't happen. Therefore, your argument is
> just FUD.
You're saying "this would be stupid to do so people don't do it" and
claim this as a proof. Unix linker technology has _always_ been
stupid. It was a tradeoff for memory/work in 1970 (smart technology
existed in the 60s, so it wasn't a question of the knowledge not
existing), and it is a tradeoff of legacy compatibility/work today.
(There are other examples of widely applied stupidity, but going into
that here would just sidetrack us, I think.)
Apart from that, shared libraries are made to optimize disk- and
memory-space. They were not initially designed to make it possible to
upgrade library code, thought this in many cases have been a side
effect. It is, however, not an entirely reliable side-effect.
If you want to avoid these problems, the right technology to use is
something like ANDF. It is designed to allow fully delayed linking.
It seems Linux users like to accuse others of FUD instead of fixing
problems; it is an interesting technique. I don't know exactly what
to call it - it isn't exactly FUD, just desinformation (in many cases
it is probably well meant, too).
> If that point is ignored (as it should be), the rest of your
> anti-LGPL rant doesn't hold up. StarOffice, Corel etc. are just
> fine. Oh -- the libc authors aren't going to sue them -- really.
Fine. Why is the FSF (who has the copyright for the main parts of
glibc, as far as I can tell) refusing to officially state this?
> If you are REALLY worried about being sued, then partially link
> your application, and distribute that. End of issue. (LGPL says
> its ok, as long as a new version of the LGPL'd library can be linked
> to you application).
The LGPL discusses linking; it does not define linking, and it does
not discuss the problems with linker- and compiler-technology that
makes it difficult to separate libraries and things that use them at
anything but the source code level. If you do things really
carefully, the linking level will be an interface boundary. If you
don't do things carefully, the linking level will not be an interface
boundary, and the binary will formally be a derived work of the
library (as opposed to a work using the library), requiring source
distribution.
Using inline functions as an example this should be totally obvious.
Any particular reason you want to deny this?
> But I like the way you tried to argue that. It sounded... almost
> plausible.
If you'd read it carefully, you'd seen the examples (which I listed as
'blatantly obvious' in the previous message, too).
> Fred Weigel.
>
> PS. My email address IS munged -- you can figure it out if you
> really want to email me. There are just too many spammers and
> too few comets...
The right tool for taking care of spammers isn't comets or munged
e-mail addresses - it is personal visits, preferably by a large man in
a nice italian suit.
"Me and Josey wants to talk to you about them there e-mails..."
Eivind.
Eivind Eklund
> > they're not careless. And saying "it didn't slow down" requires exact
> > knowledge of the development processes; I doubt you have that for all
> > those companies. You're spreading unfounded claims and muddling the
> > issues.
>
> software companyes never bothered to take a look at the
> Linux license before they put out commercial softwares
> for Linux.
No, I'm implying they're not experts on compiler and linker
technology, and most likely haven't consulted with such (as they've
probably gotten answers from developers that felt very sure of
themselves without really knowing the issues).
> As a Linux developer, I am very glad to see those commercial
> available for Linux.
Even without being a Linux user or developer, I'm glad :-) I'm in
favor of them being available, and I'm in favor of them NOT being
shot down. I'm raising these issues to have people be careful, not to
have them drop free software development.
>> As a matter of fact, we are making sure it is legal to do so under
> the Linux license. Here is a sample statement from the revised
> GNU/Linux license for glibc:
>
> As a special exception, if you link this library or the library,
> which is licensed under the GNU Library General Public License
> and contains this library, to produce an executable or shared object
> file, this does not cause the resulting executable or shared object
> file to be covered by the GNU General Public License. This
> exception does not however invalidate any other reasons why the
> executable or shared object file might be covered by the GNU General
> Public License.
>
> This is to clear up any misconceptions about the Linux license. The
> final version should be similar to this. Basically, it is ok to use
> glibc to produce commercial softwares, shared or executable.
The statement above doesn't change anything. Actually, for me, it act
as misinformation. It talks of 'special exception', and then goes on
to muddle the issues by repeating stuff that need no exception..
On first reading, I read it as if you were saying that linking with
this library would not (no matter what) cause the resulting executable
or shared object to be covered by the GNU LGPL. This would have been
an exception (and may be what was intended?).
It would also raise the issue of whether all contributors had OKed the
change. (Sorry for seeming suspicious - I've just seen Linux-users
spread so much FUD and misinformation about licenses, and projects
being so careless...)
Eivind.