The directory aliasing, is rather trivial. I do something like this as part of my default installs by hand in a few minutes (example/root to/home/root,/tmp to/var/tmp,/var/www to/home/apache, etc...).
Sometimes symlinking things like this can be a Bad Thing. Assume, for instance, that somehow/etc/fstab gets hosed, or is for some reason no longer accurate (for instance, you install a new hard drive, edit your partition table, or are migrating over to devfs).
Suddenly root's home directory can't be found. Sure, you could pass "init=/bin/sh" to the kernel when you reboot, but it's just another painful step.
There's a reason root's home directory isn't on/home. There's also a reason why ls (and fdisk, mke2fs, etc.) isn't in/usr.
If the root partition fails completely, obviously you won't be able to boot at all. When you decide where to put things, however, keep this in mind:
If any partition fails, you want to firewall the damage as much as possible. If/home fails, you should be able to log in as root and start trying to correct the damage.
If you are putting root's home on/home instead of / because you're filling your / partition with stuff in root's home directory, chances are you're doing things as root that should probably be done as a user.
The idea is to have a tiny, functional system with nothing other than the root partition, in case of system failure.
This is also a good excuse to have a working knowledge of vi, even if you're the emacs type: if/usr fails to mount correctly, emacs is gone, because the root partition is not the place for big software. However, there is usually a copy of a lightweight vi clone lurking in/bin. When you need to use it, you'll be glad you know how, if even only a little bit.
Well, it was more of a half-hearted attempt to piss off my Windows-using roommate.
He was complaining about slow swapping, and I was like, "hmmm... I can probably swap over the network to the fileserver machine!"
I'm not sure if NBD was in the kernel at the time, and it definitely wasn't compiled in. This was, umm, '98 or '99, I believe.
Of course, this was from my P2-200 with 32 MB of RAM. Our file server was a dual 233, IIRC, with like 128 MB, most of which did nothing most of the time.
Campus network, also -- no 100 mbit, even had the cards supported it, and as a college student I didn't have the cash to dump on faster equipment, but it was more of a proof-of-concept (or, proof of "my OS is more capable than yours").
Could we soon see Apple-branded, multibutton, scrolling mice?
I'd be happy to just to see an Apple-branded, multibutton mouse.
</obapplemousecomment>
(yes, I know they're available, but all display-model Macs I've seen to date have at most one mouse button, and some hardly seem to have a button at all... in other words, refer to my.sig)
I tried something like this a while ago -- I wanted to mount an NFS-exported file via loopback and use it as swap.
The file in question actually resided in a RAM drive on another machine on the LAN.
I couldn't get it to work in the 45 minutes or so I messed around with it. I'm not sure if Linux was unhappy using an NFS-hosted file for swap, or what exactly the problem was, but I did get some funny looks from people to whom I explained the idea (ie, to determine whether the network would be faster than waiting for my disk-based swap).
This is quite possibly the funniest comment I've read in weeks.
Burning karma and browsing at -1...
Re:It's more complicated than that.
on
Linus on DRM
·
· Score: 1
The GPL does NOT make explicit exception for compilers.
It exempts "anything that is normally distributed... with the major components... of the operating system on which the executable runs, unless that component itself accompanies the executable."
A compiler is provided as an example of something which may be normally distributed with the operating system. However, it does not exclude compilers which are not normally distributed with the operating system.
That aside, the GPL says that you must provide "complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable".
It does not say that the executable must be guaranteed to run after installation.
If the target is configured using something such as:./configure --with-key=~/keys/secret.txt
then the GPL seems to say that you must include the configure script (or, at least, whatever is used to generate it), but says nothing of secret.txt, which is not part of the script at all.
Re:It's more complicated than that.
on
Linus on DRM
·
· Score: 1
I'm not entirely sure I agree or understand this.
Say I develop a GPL'd app that only compiles (for whatever reason) with MS VC++.
According to the letter of what you say, I "must give [you] the tools that [I] would use to have that console run a modified version of that" product.
Yet, I obviously can't distribute this tool, which is required for compilation, with the source distribution.
A more realistic example:
Say I manufacture a PC-based product which runs a GPL'd app. Does it violate the GPL if I make everything available to you, source, a copy of the entire development environment, hell, root access to the machine used to develop the product, but fail to provide the BIOS password to the machine I sold you?
Re:It's more complicated than that.
on
Linus on DRM
·
· Score: 1
The GPL guarantees that you will be able to build the code. It doesn't guarantee that given hardware will allow you to _run_ the code.
IANADRM expert (nor do I really much care), but what this sounds like to me is that Linus says that if you want to develop a device that will only execute kernels signed by your private key, that's fine with him.
If I develop a product that will only run on _my_ computer, whether it be tied to aspects of the hardware, the MD5 hash of my root password, being able to receive data at my static IP address, or whatever, that's fine. However, if I provide you with a license to the software, I still have to provide you with source code, so that you can modify the source to run on your hardware as well.
It's separating the rules defining use of the _software_ (more accurately, the source code) from rules defining use of the _hardware_.
I'm disappointed you're not logged in, or you'd have been on my friends list in a heartbeat.
This is certainly OT in the strict sense, but it's about geeking out and making stuff yourself, so the bitchy mods can blow it all to hell.
If you're still reading, or if _anyone_ with experience in auto fab is reading, do you have any advice or stories to tell for the interested newbie?
I've done mechanical work (owned a 3.8L Taurus which had its head gasket for dinner one night, and a Taurus SHO that chainsmoked CV joints, done more roadside repairs than I can count), but never have had the opportunity to break into fabrication.
How does one get started? Is it an engine build you'd begin with, or custom body panels? Chassis design? Auto restoration? There's sooooo much to do, but right now (well, not _right_ now, but eh) I'm behind the wheel of an '89 Vic, and eyeing an '86 Mustang GT droptop that has a damned good price on it. I've got a lead on a free '68 convertible I6 Mustang with a 3-spd tranny (tons of fire-damage, though -- if the doors were opened, it would be in two halves), all I'd have to do is rent a trailer and drive halfway across the country. I have a lower-mileage '87 302 I'm tempted to try to clean up, mod lightly, and put in place of the 150k-mile one currently pulling me around.
My goal is fun, transportation, sport, and learning. I'd _love_ to eventually pursue full auto fabrication, chassis, body panels, suspension, etc., but I really need a place to start.
Like I said, it seems we agree. If you fail to see a problem, stop looking for one.
I'm not whining about how I don't like restrictions placed on me by anything.
The point I was trying to make is that the FSF has its own goals, and that before blindly latching on to the FSF (or GPL, or BSD license, or blah blah blah) it's probably a good idea to try to play devil's advocate and see what you're agreeing to.
The Debian project often does this -- I've seen the FDL issue come up several times in Debian lists.
Regarding the GPL, I simply thought it interesting that while the GPL doesn't impose usage restrictions upon the program, it does impose usage restrictions upon the source to the program. Meaning, the product offered is the program, and you can use the source to modify the functionality of the program (even to the extent of ending up with an entirely different program).
However, it doesn't seem like the intent of the GPL is to enable the free use of the code. I'm not complaining about this fact, I just thought that it was sort of interesting to think of it from the perspective of the code itself being the tool, and imposing no usage restrictions upon the code.
It's "I wrote this program that does XXX, use it however you want to", instead of "I wrote this code that does XXX, use it however you want to." The GPL places no limitations upon use of the program, but certainly restricts freedom regarding what you can do with the code.
In short, I guess, I'm just pointing out the irony that an organization that likes to throw the word "Free" around gets their jollies by restricting freedoms.
And who said there's a problem? Instead of replying with your thoughts on what I've said, you're trying to imply that I'm arguing about something, and accused me of whining about something that I don't even care about, other than on an academic level.
It is my impression that most things one might contribute to GCC are difficult to make use of out of the context of the GCC codebase, at least directly.
How interesting that I am not only wrong, but have my head stuck up my ass. It's nice to see that a "GCC maintainer" will enter into a civil conversation and start throwing insults around.
There's no need to be an ass, you could just correct me. I guess the fact that you decide to insult me as well means that you have big balls, eh?
Context is "discourse that surrounds a language unit and helps to determine its interpretation [syn: linguistic context, context of use] 2: the set of facts or circumstances that surround a situation or event; 'the historical context'".
Now that we've cleared that up, if you examine the original context, the point that I was trying to make was that it is possible (not in all cases, but it's possible) to use information obtained under NDA to develop a product which can be released in source form to the public.
The people who whine about GPL are people who want to take advantage of other peoples work for free.
...and GPL bigots often do the same. Anyone who has downloaded a distribution without paying for it is doing so. There's nothing wrong with taking advantage of other people's work for free, in certain cases.
I'm not whining about anything, simply pointing out that it seems to me that the GPL is _not_ about maximizing developer freedom, which is something you seem to agree with.
We don't want people to steal our code--our code is for everyone equally.
This isn't quite what the GPL says. The GPL says, "Not only is my code for everyone equally, but your code based on my code is for everyone equally. Use of my library is for everyone equally, unless they don't use the GPL."
With the GPL, you place restrictions on the use of your code, sort of an EULA for the users of your code (as opposed to an EULA for the users of your program).
Contributors could just as easily state that they are willing to allow their work to be distributed under the GPL. This would not require copyright assignment.
Again, if you GPL'd your code and gave the FSF an explicit license, they would (under the GPL) have the right to use the source code in another GPL'd project.
If that weren't the case, using GPL'd code in a derivative work would require copyright assignment, and you could never fork a codebase without the author giving you copyright. That would be a Bad Thing.
I agree that any conspiracy theories I've come up with are pretty farfetched.
I do, however, think that the GPL restricts developers while "freeing the source". At times I get the impression that RMS is more interested in spouting off about his own philosophy(1) than providing developers with freedom. Saying that GPL'd libs can only be used by GPL's apps seems a little restrictive to me.(2)
Oh, well, enough flaming the FSF. It's kind of the "sucks less" idea, aka the lesser of n evils. I honestly wish, however, that the BSDs had been more of a success, or even that Linus had chosen a BSD-ish license. Of course, that would have had its own problems, I'm sure. If that were the case, I might be sitting here complaining about how the BSD license allowed commercial (non-free) use.
(1) Not that there's anything wrong with that. (2) To which everyone shouts, "That's why there's the LGPL (and other licenses)!"
Case in point: the driver published in SOURCE FORM by NVidia builds upon information which they are unwilling to release to the public.
They release source code which uses information which would be available only under NDA. It's not a matter of publishing the information contained in the NDA, it's a matter of making use of it.
I've never used Walter's compiler, but, I don't think this is the case. If Bright's compiler is GPL'd, they could use his code and not have him assign the copyright. I understand why they've chosen to stay copyright-pure with the core components of the GNU system. They don't have to, but it just makes things easier if the process servers come knocking at the door with a large lawsuit.
Walter's compiler isn't GPL'd -- it's commercial, closed-source. The point is that if Walter _wanted_ to contribute some code under the GPL to GCC, that wouldn't be enough, because the FSF _requires_ that you assign copyright to them for anything added to GCC.
Before we can accept code contributions from you, we need a copyright assignment form filled out and filed with the FSF.
See some documentation by the FSF for details and contact us (either via the gcc@gcc.gnu.org list or the GCC maintainer that is taking care of your contributions) to obtain the relevant forms. It's a good idea to send assignments@gnu.org a copy of your request.
I stand corrected. Thanks for pointing that out -- I haven't used the Digital Mars compilers, but I don't want to be spreading disinformation about them.
Yeah, Walter has tons of experience, and generally kicks ass. That wasn't to imply that support for templates is even something you can cut and paste across compilers, so even if it were 100% functional regarding the C++ spec, it would take a *ton* of work to allow this to benefit GCC.
The point is that having a compiler that generates good code, and is easy to code for, is something that would benefit an OS by a huge amount. Having enough expertise to contribute useful code to GCC is already pertty hard; why make it that much harder than it already is?
I can potentially write something under an NDA which can be released under whatever license I want.
Refer to many graphics drivers included in XFree86. Often information obtained under an NDA can be used to develop a freely available work.
This is in contrast to taking bits from a GPL'd project and using them in another work. Under the spirit of the GPL, you would only be permitted to do so if your own work were GPL'd.
Also, you failed to address my point regarding copyright assignment: namely that it makes it more difficult to contribute to certain projects.
Sure, you can fork a GPL'd work, but what if I don't _want_ to maintain my own release of GCC? The ability to fork a project is something that the GPL allows you to do, and I made reference to that fact with the EGCS example. Your "argument" is in agreement with what I've said.
But how does this make it any less stupid that you have to assign copyright to the FSF to contribute to GCC? I see no reason this would be a problem unless the FSF wanted the option to release GCC under a license other than their own GPL.
"9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns."
Suggested usage:
"This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version."
Sure, you don't have to provide the specific text of the suggested usage, but the FSF intends for you to copy and paste that code into your app, and I'd imagine that many do.
As I see it, the greatest thing about the Debian project is the fact that they don't subscribe to the typical herd mentality so often seen in the open-source community.
I've seen many, many Debian developers using "GNU/Linux" to describe the operating system, which does give credit where credit is due.
However, the GNU project's goals often frighten me (inasmuch as I give a shit), and it's nice to see that someone in the community is willing to point out their mistakes.
Many have pointed out that you could put the content of an entire work in an "invariant" section of a GFDL-licensed document. I believe there may be certain rules regarding the proportion of invariant sections to non-invariant sections, but defeating this is akin to defeating the Slashdot lameness filters: a definite time-waster, but not impossible.
The GNU Project is shady. Make no mistake about it: The GPL restricts choice as much as an NDA would.
I often wonder how many successful works the GNU Project could claim if it weren't for the restrictions inherent in the GPL. One oft-cited (but quite relevant) example is GCC: stagnation left many unsatisfied, so EGCS was started, blah, blah, blah. Basically GNU took (with permission) the work of those who had made EGCS a much better compiler, and renamed it GCC.
To contribute to GCC, in fact, it is not enough that you GPL your code and give a license to the GNU Project. No, you have to ASSIGN COPYRIGHT of the code to GNU, basically saying that the code is no longer yours, and that you would no longer have the right to take code from an existing work (such as a commercial compiler which you wrote) and contribute it to GCC, because you would no longer own the original code due to copyright violation.
Does this remind anyone of recording companies requiring artists to hand over their original works?
Everything done in a GNU project benefits the FSF (at the very least, with added prestige) -- they can claim that they, and they alone, own the code. This includes the right to, if they chose, hire coders to develop the HURD into a useable OS kernel (refer to my sig here), and release it under a closed-source license. Or, to make major improvements to GCC and sell it commercially under a non-GPL license.
If Walter Bright decided to allow the FSF to use major portions of his C++ compiler, which he sells commercially (and includes, I believe, much better support for C++ templates than GCC), he would have to assign copyright of his code to the FSF, therefore preventing him from using it in releases of his commercial compiler in the future.
The FSF is brain-dead, folks, and kudos to Debian folks for having the cojones to point out one of the more obviously stupid flaws in a GNU license.
(Many may note the fact that I focus a bit on compiler issues here. I have followed, to some extent, the GCC development lists, and from what I have seen, it can be a pain in the ass to contribute to GCC. Apple has many improvements to the compiler in their internal tree, and I often wonder if more of those improvements would have been rolled back into GCC by now if not for the hoops they have to jump through in order to get those changes submitted.
I've seen people make feature suggestions on the list which the Apple guys say they've already done and tested internally. The response is often, "We've done this, but we weren't sure if anyone else would find it useful. We'll look into getting permission to release it." It seems obvious that getting permission to hand over copyright would make that process a little harder.
Why do I focus on compiler issues so much? Various reasons... quality of generated code on Intel vs. other architectures, KDE slowness due to C++ linkages, blah blah blah. The compiler is key to getting code to run quickly on modern CPUs, as anyone pushing a non-Intel architecture would do well to remember.)
Don't trust the FSF. Appreciate their work, but don't hand over your firstborn. They can do whatever they want, including rewrite the GPL to state that any GPL'd code may be sold commercially by the FSF without providing source code.
FSF says free the source. I say free the developer.
Slashdot Mirror
Sometimes symlinking things like this can be a Bad Thing. Assume, for instance, that somehow
Suddenly root's home directory can't be found. Sure, you could pass "init=/bin/sh" to the kernel when you reboot, but it's just another painful step.
There's a reason root's home directory isn't on
If the root partition fails completely, obviously you won't be able to boot at all. When you decide where to put things, however, keep this in mind:
If any partition fails, you want to firewall the damage as much as possible. If
If you are putting root's home on
The idea is to have a tiny, functional system with nothing other than the root partition, in case of system failure.
This is also a good excuse to have a working knowledge of vi, even if you're the emacs type: if
Well, it was more of a half-hearted attempt to piss off my Windows-using roommate.
He was complaining about slow swapping, and I was like, "hmmm... I can probably swap over the network to the fileserver machine!"
I'm not sure if NBD was in the kernel at the time, and it definitely wasn't compiled in. This was, umm, '98 or '99, I believe.
Of course, this was from my P2-200 with 32 MB of RAM. Our file server was a dual 233, IIRC, with like 128 MB, most of which did nothing most of the time.
Campus network, also -- no 100 mbit, even had the cards supported it, and as a college student I didn't have the cash to dump on faster equipment, but it was more of a proof-of-concept (or, proof of "my OS is more capable than yours").
Could we soon see Apple-branded, multibutton, scrolling mice?
I'd be happy to just to see an Apple-branded, multibutton mouse.
</obapplemousecomment>
(yes, I know they're available, but all display-model Macs I've seen to date have at most one mouse button, and some hardly seem to have a button at all... in other words, refer to my
I tried something like this a while ago -- I wanted to mount an NFS-exported file via loopback and use it as swap.
The file in question actually resided in a RAM drive on another machine on the LAN.
I couldn't get it to work in the 45 minutes or so I messed around with it. I'm not sure if Linux was unhappy using an NFS-hosted file for swap, or what exactly the problem was, but I did get some funny looks from people to whom I explained the idea (ie, to determine whether the network would be faster than waiting for my disk-based swap).
Of course, this was back when RAM wasn't cheap...
This is quite possibly the funniest comment I've read in weeks.
Burning karma and browsing at -1...
The GPL does NOT make explicit exception for compilers.
./configure --with-key=~/keys/secret.txt
It exempts "anything that is normally distributed... with the major components... of the operating system on which the executable runs, unless that component itself accompanies the executable."
A compiler is provided as an example of something which may be normally distributed with the operating system. However, it does not exclude compilers which are not normally distributed with the operating system.
That aside, the GPL says that you must provide "complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable".
It does not say that the executable must be guaranteed to run after installation.
If the target is configured using something such as:
then the GPL seems to say that you must include the configure script (or, at least, whatever is used to generate it), but says nothing of secret.txt, which is not part of the script at all.
I'm not entirely sure I agree or understand this.
Say I develop a GPL'd app that only compiles (for whatever reason) with MS VC++.
According to the letter of what you say, I "must give [you] the tools that [I] would use to have that console run a modified version of that" product.
Yet, I obviously can't distribute this tool, which is required for compilation, with the source distribution.
A more realistic example:
Say I manufacture a PC-based product which runs a GPL'd app. Does it violate the GPL if I make everything available to you, source, a copy of the entire development environment, hell, root access to the machine used to develop the product, but fail to provide the BIOS password to the machine I sold you?
The GPL guarantees that you will be able to build the code. It doesn't guarantee that given hardware will allow you to _run_ the code.
IANADRM expert (nor do I really much care), but what this sounds like to me is that Linus says that if you want to develop a device that will only execute kernels signed by your private key, that's fine with him.
If I develop a product that will only run on _my_ computer, whether it be tied to aspects of the hardware, the MD5 hash of my root password, being able to receive data at my static IP address, or whatever, that's fine. However, if I provide you with a license to the software, I still have to provide you with source code, so that you can modify the source to run on your hardware as well.
It's separating the rules defining use of the _software_ (more accurately, the source code) from rules defining use of the _hardware_.
Or did I totally miss the point somewhere?
I'm disappointed you're not logged in, or you'd have been on my friends list in a heartbeat.
This is certainly OT in the strict sense, but it's about geeking out and making stuff yourself, so the bitchy mods can blow it all to hell.
If you're still reading, or if _anyone_ with experience in auto fab is reading, do you have any advice or stories to tell for the interested newbie?
I've done mechanical work (owned a 3.8L Taurus which had its head gasket for dinner one night, and a Taurus SHO that chainsmoked CV joints, done more roadside repairs than I can count), but never have had the opportunity to break into fabrication.
How does one get started? Is it an engine build you'd begin with, or custom body panels? Chassis design? Auto restoration? There's sooooo much to do, but right now (well, not _right_ now, but eh) I'm behind the wheel of an '89 Vic, and eyeing an '86 Mustang GT droptop that has a damned good price on it. I've got a lead on a free '68 convertible I6 Mustang with a 3-spd tranny (tons of fire-damage, though -- if the doors were opened, it would be in two halves), all I'd have to do is rent a trailer and drive halfway across the country. I have a lower-mileage '87 302 I'm tempted to try to clean up, mod lightly, and put in place of the 150k-mile one currently pulling me around.
My goal is fun, transportation, sport, and learning. I'd _love_ to eventually pursue full auto fabrication, chassis, body panels, suspension, etc., but I really need a place to start.
All these leads, and nowhere to go...
Any random pointers, advice, stories, etc.?
When you're downloading OpenBSD, you're downloading Communism!
... I vaguely remember someone saying something to the effect that "all GNU software will continue to expand until it can read mail."
I'd say if you want acceptance into GNU, make it massively flexible, massively portable, and, most importantly, massive.
Like I said, it seems we agree. If you fail to see a problem, stop looking for one.
I'm not whining about how I don't like restrictions placed on me by anything.
The point I was trying to make is that the FSF has its own goals, and that before blindly latching on to the FSF (or GPL, or BSD license, or blah blah blah) it's probably a good idea to try to play devil's advocate and see what you're agreeing to.
The Debian project often does this -- I've seen the FDL issue come up several times in Debian lists.
Regarding the GPL, I simply thought it interesting that while the GPL doesn't impose usage restrictions upon the program, it does impose usage restrictions upon the source to the program. Meaning, the product offered is the program, and you can use the source to modify the functionality of the program (even to the extent of ending up with an entirely different program).
However, it doesn't seem like the intent of the GPL is to enable the free use of the code. I'm not complaining about this fact, I just thought that it was sort of interesting to think of it from the perspective of the code itself being the tool, and imposing no usage restrictions upon the code.
It's "I wrote this program that does XXX, use it however you want to", instead of "I wrote this code that does XXX, use it however you want to." The GPL places no limitations upon use of the program, but certainly restricts freedom regarding what you can do with the code.
In short, I guess, I'm just pointing out the irony that an organization that likes to throw the word "Free" around gets their jollies by restricting freedoms.
And who said there's a problem? Instead of replying with your thoughts on what I've said, you're trying to imply that I'm arguing about something, and accused me of whining about something that I don't even care about, other than on an academic level.
It is my impression that most things one might contribute to GCC are difficult to make use of out of the context of the GCC codebase, at least directly.
How interesting that I am not only wrong, but have my head stuck up my ass. It's nice to see that a "GCC maintainer" will enter into a civil conversation and start throwing insults around.
There's no need to be an ass, you could just correct me. I guess the fact that you decide to insult me as well means that you have big balls, eh?
Do you have any idea what context is?
Context is "discourse that surrounds a language unit and helps to determine its interpretation [syn: linguistic context, context of use] 2: the set of facts or circumstances that surround a situation or event; 'the historical context'".
Now that we've cleared that up, if you examine the original context, the point that I was trying to make was that it is possible (not in all cases, but it's possible) to use information obtained under NDA to develop a product which can be released in source form to the public.
I'm not whining about anything, simply pointing out that it seems to me that the GPL is _not_ about maximizing developer freedom, which is something you seem to agree with.
This isn't quite what the GPL says. The GPL says, "Not only is my code for everyone equally, but your code based on my code is for everyone equally. Use of my library is for everyone equally, unless they don't use the GPL."
With the GPL, you place restrictions on the use of your code, sort of an EULA for the users of your code (as opposed to an EULA for the users of your program).
Contributors could just as easily state that they are willing to allow their work to be distributed under the GPL. This would not require copyright assignment.
Again, if you GPL'd your code and gave the FSF an explicit license, they would (under the GPL) have the right to use the source code in another GPL'd project.
If that weren't the case, using GPL'd code in a derivative work would require copyright assignment, and you could never fork a codebase without the author giving you copyright. That would be a Bad Thing.
Well stated, thanks for the response.
I agree that any conspiracy theories I've come up with are pretty farfetched.
I do, however, think that the GPL restricts developers while "freeing the source". At times I get the impression that RMS is more interested in spouting off about his own philosophy(1) than providing developers with freedom. Saying that GPL'd libs can only be used by GPL's apps seems a little restrictive to me.(2)
Oh, well, enough flaming the FSF. It's kind of the "sucks less" idea, aka the lesser of n evils. I honestly wish, however, that the BSDs had been more of a success, or even that Linus had chosen a BSD-ish license. Of course, that would have had its own problems, I'm sure. If that were the case, I might be sitting here complaining about how the BSD license allowed commercial (non-free) use.
(1) Not that there's anything wrong with that.
(2) To which everyone shouts, "That's why there's the LGPL (and other licenses)!"
Quite simply, you're wrong.
Case in point: the driver published in SOURCE FORM by NVidia builds upon information which they are unwilling to release to the public.
They release source code which uses information which would be available only under NDA. It's not a matter of publishing the information contained in the NDA, it's a matter of making use of it.
Walter's compiler isn't GPL'd -- it's commercial, closed-source. The point is that if Walter _wanted_ to contribute some code under the GPL to GCC, that wouldn't be enough, because the FSF _requires_ that you assign copyright to them for anything added to GCC.
See http://gcc.gnu.org/contribute.html:
Before we can accept code contributions from you, we need a
copyright assignment form filled out and filed with the FSF.
See some
documentation by the FSF for details and contact us (either via
the gcc@gcc.gnu.org list or the
GCC maintainer that is taking care of your contributions) to obtain
the relevant forms. It's a good idea to send
assignments@gnu.org a copy of
your request.
I stand corrected. Thanks for pointing that out -- I haven't used the Digital Mars compilers, but I don't want to be spreading disinformation about them.
Yeah, Walter has tons of experience, and generally kicks ass. That wasn't to imply that support for templates is even something you can cut and paste across compilers, so even if it were 100% functional regarding the C++ spec, it would take a *ton* of work to allow this to benefit GCC.
The point is that having a compiler that generates good code, and is easy to code for, is something that would benefit an OS by a huge amount. Having enough expertise to contribute useful code to GCC is already pertty hard; why make it that much harder than it already is?
No, actually I meant NDA.
I can potentially write something under an NDA which can be released under whatever license I want.
Refer to many graphics drivers included in XFree86. Often information obtained under an NDA can be used to develop a freely available work.
This is in contrast to taking bits from a GPL'd project and using them in another work. Under the spirit of the GPL, you would only be permitted to do so if your own work were GPL'd.
Also, you failed to address my point regarding copyright assignment: namely that it makes it more difficult to contribute to certain projects.
Sure, you can fork a GPL'd work, but what if I don't _want_ to maintain my own release of GCC? The ability to fork a project is something that the GPL allows you to do, and I made reference to that fact with the EGCS example. Your "argument" is in agreement with what I've said.
But how does this make it any less stupid that you have to assign copyright to the FSF to contribute to GCC? I see no reason this would be a problem unless the FSF wanted the option to release GCC under a license other than their own GPL.
If you wrote the code, you own the copyright to it, and are free to start releasing it under public domain if you wish.
Owning copyright means that you can release it under whatever licenses, and as many licenses, as you want.
Screw the source, free the developer.
From http://www.gnu.org/copyleft/gpl.html:
"9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns."
Suggested usage:
"This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version."
Sure, you don't have to provide the specific text of the suggested usage, but the FSF intends for you to copy and paste that code into your app, and I'd imagine that many do.
As I see it, the greatest thing about the Debian project is the fact that they don't subscribe to the typical herd mentality so often seen in the open-source community.
I've seen many, many Debian developers using "GNU/Linux" to describe the operating system, which does give credit where credit is due.
However, the GNU project's goals often frighten me (inasmuch as I give a shit), and it's nice to see that someone in the community is willing to point out their mistakes.
Many have pointed out that you could put the content of an entire work in an "invariant" section of a GFDL-licensed document. I believe there may be certain rules regarding the proportion of invariant sections to non-invariant sections, but defeating this is akin to defeating the Slashdot lameness filters: a definite time-waster, but not impossible.
The GNU Project is shady. Make no mistake about it: The GPL restricts choice as much as an NDA would.
I often wonder how many successful works the GNU Project could claim if it weren't for the restrictions inherent in the GPL. One oft-cited (but quite relevant) example is GCC: stagnation left many unsatisfied, so EGCS was started, blah, blah, blah. Basically GNU took (with permission) the work of those who had made EGCS a much better compiler, and renamed it GCC.
To contribute to GCC, in fact, it is not enough that you GPL your code and give a license to the GNU Project. No, you have to ASSIGN COPYRIGHT of the code to GNU, basically saying that the code is no longer yours, and that you would no longer have the right to take code from an existing work (such as a commercial compiler which you wrote) and contribute it to GCC, because you would no longer own the original code due to copyright violation.
Does this remind anyone of recording companies requiring artists to hand over their original works?
Everything done in a GNU project benefits the FSF (at the very least, with added prestige) -- they can claim that they, and they alone, own the code. This includes the right to, if they chose, hire coders to develop the HURD into a useable OS kernel (refer to my sig here), and release it under a closed-source license. Or, to make major improvements to GCC and sell it commercially under a non-GPL license.
If Walter Bright decided to allow the FSF to use major portions of his C++ compiler, which he sells commercially (and includes, I believe, much better support for C++ templates than GCC), he would have to assign copyright of his code to the FSF, therefore preventing him from using it in releases of his commercial compiler in the future.
The FSF is brain-dead, folks, and kudos to Debian folks for having the cojones to point out one of the more obviously stupid flaws in a GNU license.
(Many may note the fact that I focus a bit on compiler issues here. I have followed, to some extent, the GCC development lists, and from what I have seen, it can be a pain in the ass to contribute to GCC. Apple has many improvements to the compiler in their internal tree, and I often wonder if more of those improvements would have been rolled back into GCC by now if not for the hoops they have to jump through in order to get those changes submitted.
I've seen people make feature suggestions on the list which the Apple guys say they've already done and tested internally. The response is often, "We've done this, but we weren't sure if anyone else would find it useful. We'll look into getting permission to release it." It seems obvious that getting permission to hand over copyright would make that process a little harder.
Why do I focus on compiler issues so much? Various reasons... quality of generated code on Intel vs. other architectures, KDE slowness due to C++ linkages, blah blah blah. The compiler is key to getting code to run quickly on modern CPUs, as anyone pushing a non-Intel architecture would do well to remember.)
Don't trust the FSF. Appreciate their work, but don't hand over your firstborn. They can do whatever they want, including rewrite the GPL to state that any GPL'd code may be sold commercially by the FSF without providing source code.
FSF says free the source. I say free the developer.