Slashdot Mirror

protection of copyrighted software has always been bad for people who use software. The case for free(as in freedom) music is much the same as the case for free software. The only difference is that refusing to share software causes material harm to the other person, because it something you use, and without which you cannot do the job.
The case for free music is weaker because music is not something you use. But everything else said about software being free applies to music also.

Try looking there : http://www.gnu.org/gnu/linux-and-gnu.html

Think what you want of RMS, but if there ever was a good programmer that has contributed code
who is also a GNU/Linux advocate, that's the man.

Now, I'll leave it up to you to decide if he's a wacko...

LILO sucks, try GRUB. GRUB lets you boot from arbitrary kernel images, has a nice menu and doesn't need to be rerun after every kernel install. It works with *BSD, HURD, and maybe other OSes as well.

1 - the FSF is in violation of the GPL by distributing on CD-ROM GPL-ed software at substantially more than the physical cost of duplicating...

No no no no no. There is absolutely nothing in the GPL that prevents you from charging for software. (Section 1 of Terms and Conditions: "You may charge a fee for the physical act of transferring a copy".) You just can't charge those people who buy the software for the source, at least beyond cost of duplication. (Section 3b: "to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code".)

GNU GRUB (the GRand Unified Bootloader) can be downloaded from:

http://www.gnu.org/software/grub/

Only a very limited set of realmode code, mostly used to switch to protected mode.
GRUB understands the common filesystems, ext2, one of the BSDs, vfat in seperated protected mode modules.
No more rerunning lilo after recompiling a kernel.
Boot menu support.
readline compatible commandline editing capability in case you need it.
Much cleaner code inside.

Shipped by NetBSD (not sure) and OpenLinux eDesktop 2.4.

Only if it's code that has been modified.

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

I noticed in the comments section there is a claim that GNU GRUB never had that problem. Has anyone used GRUB? I am interested in knowing if LILO has any advantages over it. I'm not trying to start a flame war, but I have noticed that LILO and loadlin seem to be the boot loaders of choice among the HOWTOS.

According to the grub page, grub isn't publicly available. Only alphas are--can an alpha bootloader really be better than LILO? (which is more established) Is there any meat to this guys comment?

That doesn't sound correct. Section 2b of the GPL reads:

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

The original question was:

What if a company uses software released under the GPL as part of a larger software product, and does not modify the GPL'ed stuff at all?

Which to me clearly fits into this category and must be GPLed. This is why the LGPL exists, so that programs or libraries designed to be linked to (libraries, etcetera) can be linked to by commerical non-GPL software packages.

How far this goes is totally beyond me. If MS Office were to suddenly start calling ispell, I don't think it would apply. As for a hard technical definition of why it wouldn't... I don't know.

http://www.gnu.org/copyleft/gpl.html

http://www.gnu.org/copyleft/lesser.html

That doesn't sound correct. Section 2b of the GPL reads:

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

The original question was:

What if a company uses software released under the GPL as part of a larger software product, and does not modify the GPL'ed stuff at all?

Which to me clearly fits into this category and must be GPLed. This is why the LGPL exists, so that programs or libraries designed to be linked to (libraries, etcetera) can be linked to by commerical non-GPL software packages.

How far this goes is totally beyond me. If MS Office were to suddenly start calling ispell, I don't think it would apply. As for a hard technical definition of why it wouldn't... I don't know.

http://www.gnu.org/copyleft/gpl.html

http://www.gnu.org/copyleft/lesser.html

I care that when you copy and distribute his mp3s, you are breaking the law

I don't care about the law. Nor for any other instruments of the duelistic mind.

and you are stealing his art.

To steal you must take. A taking incurs a loss. There is no loss here.

Now you could argue (dumbly) that it is a loss because they would have made money had xxx person purchase this. But this shit only exists in the minds of sick fucks otherwise know as lawyers.

It's not a loss. It's lack of a gain.

This is why 'piracy' requires it's own set of laws, because the common law act of robbery (aka theft) does not apply.

You didn't know that your comments are submitted to /. under GPL. This means they can be redistributed by Katz, et al, and anybody is free to twist your words around to say whatever they want, as long as a copy of your original post is made available to anyone asking for it.

• Changes to source files propagate back to original maintainer for use in its closed-source projects.
• Not compatible with other popular free software licenses (e.g. GNU GPL).

• Changes to source files propagate back to original maintainer for use in its closed-source projects.
• Not compatible with other popular free software licenses (e.g. GNU GPL).

• Changes to source files propagate back to original maintainer for use in its closed-source projects.
• Not compatible with other popular free software licenses (e.g. GNU GPL).

• Pricing.

  It is notoriously difficult to get pricing information for QNX.

  I have heard differing reports on comp.os.qnx, including that it is "very expensive, hundreds of dollars per system," or, on the other hand, the vague answer of "you can license it reasonably economically." (With no definition of what "reasonably economical" means, of course.)

• If people should start thinking of QNX, then they should also start thinking of:
  • VSTa

    A copylefted system that "lifts" ideas from QNX and Plan 9

    It looks like development has not been terribly active lately.

  • MIT Exokernel

    Again, not terribly active, but an interesting OS kernel.

  • EROS

    Eric Raymond thinks it's mindblowing, so the Eric Raymond Personality Cult should all be preparing to drop Linux in favor of EROS. (Of course, it isn't yet capable of self-hosting, which indicates that it's not all that useful at this point. But, to cultists, usefulness is irrelevant...)

  • Possibly even Hurd

    It's different from the other options; certainly not a tiny OS option...

  • eCos
  • RTEMS

    Which, like QNX, appears to be used in some reasonably critical system environments...

  • Fiasco

    Which is a "lighter microkernel than Mach"...

  • On Linux, people interested in QNX should almost certainly look at SRR -- QNX API compatible message passing for Linux

    This is the critical programming abstraction that QNX uses heavily which isn't all that widely used on traditional UNIXes, namely asynchronous messaging.

  These are all interesting alternatives, albeit not all being of identical levels of interest.

Is it OK to call GNU/Linux and *BSD "UNIX-like" systems? It seems that NetBSD is ripping off the GNU tagline.

When fixing the code is an option, there is a solution that eliminates most of the issues involved with buffer sizes. It can allow values of arbitrary length to be handled in cases where you don't want to set an upper limit, such as free-form text fields. And it has been around in glibc for ages. Obstacks! If libsafe is an airbag, then obstacks is a tank. Each makes the road safer (for you) in its own way.

Someone mentioned this a couple of months back, but you could use GNU Stow for all but a few base libraries. Stow isolates each "package" into its own directory, creating links in /, /usr, or /usr/local automatically. All of the symlink management is done without a database file: you can use `make install prefix=/usr/local/stow/mypkg`, tar up mypkg, and you've got a self-contained binary package. To install, untar, and run `stow mypkg`.


43rd Law of Computing: Anything that can go wr

Well, I might fall under your definition of 'Debian facist', but really, no distribution should stop you from grabbing source tarballs, building stuff, and installing it on /usr/local/. Preferably using GNU Stow to manage the packages.

Anyway, let me be just a bit of a facist: since I switched to Debian from RedHat, I've hardly ever had to muck around with anything to get it to install. I've had to do it a couple of times, but mind you, I run the unstable tree.

And with the nice little script stowES (found it on freshmeat a couple weeks ago), installing from source couldn't be easier (as long as the packages use configure).

Of course, nothing beats Debian, but if something isn't packaged yet, stow[ES] does a very nice job.

YDD

Some synthesizers are called "programmable" with note sequences. Many can store their sequences in standard MIDI format (*.mid; *.kar; *.rmi). Tools like Timidity can "compile" these MIDIs into *.wav, and even a really lame encoder can "link" the results into "executable" MP3 files. So we have a "Program" that can be released under the GNU GPL; draw your own conclusions.

http:\\slashdot.org\

Try right-clicking an empty area of the Windows® 98 taskbar and choosing Toolbars > Address. Now click in the address box (you may need to make your taskbar bigger) and type \windows\system and notice how Windows changes backslashes to forward slashes. The only reason Windows uses \ instead of / is bug compatibility with MS-DOS 1.0, which used / instead of - to specify option switches on the command line. When subdirectories, device drivers, and other features imitating Unix® were hacked into DOS 2, the Unix-like / directory separator was already taken, so they had to use \. Anyway, DOS is perfectly happy if apps pass it / (command.com blocks it because of the option problem), and it's the default for the DOS Bourne Again Shell, part of the DJGPP port of GNU.

> I always thought Stallman pretty much spoke for the FSF on the philosophy section, but realize I may have made an incorrect assumption. I thought the FSF wanted all software to be free for it's own sake as a free speech issue -- you know, code for it's own sake.

No, you didn't make an incorrect assumption. Stallman wishes all software was open source.

*Points to evidence -->

http://www.gnu.org/philosophy/why-free. html

and

http://www.gnu.org/philosophy/should befree.html

While it is a lofty goal to have all software with the freedom of source and copyleft, Stallman seems to think the right of the developer should be "restricted" for the greater good. As a liberterain, I don't think that's right to "deny" someone the freedom on the basis of the rest of society.

Cheers

> I always thought Stallman pretty much spoke for the FSF on the philosophy section, but realize I may have made an incorrect assumption. I thought the FSF wanted all software to be free for it's own sake as a free speech issue -- you know, code for it's own sake.

No, you didn't make an incorrect assumption. Stallman wishes all software was open source.

*Points to evidence -->

http://www.gnu.org/philosophy/why-free. html

and

http://www.gnu.org/philosophy/should befree.html

While it is a lofty goal to have all software with the freedom of source and copyleft, Stallman seems to think the right of the developer should be "restricted" for the greater good. As a liberterain, I don't think that's right to "deny" someone the freedom on the basis of the rest of society.

Cheers

All software should be open under a GPL or simpler license.

For the student, geeks and computer sciences that have to actucally work with the source code/software it is 100 times easier if the code is freely (as in speech) avaiable.

For the commerical blood suckers they should fight and make money on terms of good software/support and not on marketing and a huge amount of lawyers.

I am sorry, but I don't see ANY reason that software should be closed. What vaule does closed software have? less than nothing

Just because closed software has the ability to make immoral and unethical money though slezzy business practices, doesn't mean it is right. Business can make money though open source software and services, but the companies will have to work 100 times as hard, and compete based on product/service rather than lawyers/marketing.

Ohh you can see the rant building up in his eyes, lets get out of here, it is about to go off

I agree that moderation with regard to licensing is a good thing. Not everything I run on Linux is free software, but 95% is. (I happen to fall on the GPL side of things). Nevertheless, it is me or does Love give a lot of marketspeak? For example, you already can remotely administer Linux. Hmm...I wonder how this kind of talk affects Wall Street perception of Caldera?

--

Well, what happened ? There's all sorts of version control, but why don't we still have file version numbers as part of the OS itself ?

and was listed at www.gnu.org as a member

Actually, it is not GPL compatible. Nothing is except the LGPL. The only way to be GPL compatible is to neither add nor take away nor even change any GPL restrictions. Only licenses that allow relicensing qualify. This is according to RMS and it is a relatively new stance for him.

Interesting to note that the commercial companies that use BSD code will most often give back.

Yes, God yes. I've been reading this whole thread, swearing that if no one else asked this, I would have to. I've wanted to ask RMS this myself, especially now that FreeNet has appeared, espousing that the havoc it wreaks through convenience piracy is of no matter, because they (FreeNet) follow RMS's beliefs.

I'm a programmer. I believe I'm a good one. I believe (perhaps arrogantly) that the best programmers are artists, not just technicians, and this field is an art, just like writing, painting and music. Many of the best programmers I know are very creative people, and do write, paint and make music. (Or would if they didn't program so darn much). I believe I make great software. Lord knows I try. I put more hours into making great software than I really should. I would be perfectly happy to give my software away for all to enjoy. But I don't. I'm one of the evil ones. I'm a capitalist. I sell my software. Why?

Because I own a car. And I have bills. And I bought a house. And I like to eat nice food when I'm not eating burritos and doritos and Mountain Dew. And I like to travel and ski and play when I'm not programming. And someday I will have kids, and I want to give them a good home and childhood. And in our world, this means I need to make money. And not small amounts of it either.

I'm not opposed to working hard -- far from it, I work too hard already and don't play enough. I read The article about reward and creativity on the gnu.org site. It's correct, yes. But it doesn't mean all of us programmers (and other artists and IP-authors by association) should give our hard work away. It means we want to feel sufficiently compensated that we don't have to worry about creating for money, and we can get on with creating great works for the sake of creating great works.

I don't want to be a waiter. I see through the handwaving about Free Software authors making a living 'through other means'. I don't want my company to make a living through that nebulous 'support' thing. I want to make software that's so great that the masses don't need to pay someone to support it. Besides, building on that business model means you end up focussing all of your company's efforts and resources on a whole bunch of support infrastructure and (unhappy and hard-to-staff) support positions, and not on the real deal: writing great code and making a great product. Tom Gooding (anonymous Coward) said it well in #153, above. No offense to anyone involved but it's easier to make a living supporting a moderately complex hacker-ish product like Emacs, an OS like Linux, the GNU tools or a web server like Apache, than it is to do the same with an application like Photoshop.

I read Atlas Shrugged. I'm not a frothing objectivist, but I agree with ronfar (above). A wise person I once knew said, "Yes, but great programmers must also eat." The Internet offers many ways to streamline the software development and distribution process, and I take advantage of every one I can to improve the relationship between my company and our customers to help deliver a better product and a better experience with it. But the day I can no longer make a decent living doing what I enjoy (coding great stuff) is the day I quit making great stuff and go become a ditch digger, and keep the fruits of my art to myself. And maybe, finally, have a healthy lifestyle and a suntan.

Now THERE is a baseless generalization. Care to back that up in any way?

Go here and keyword search on piracy

Here is a direct quote: "Note that the GNU Project recommends avoiding the term piracy since it implies that sharing copies is somehow illegitimate."

I could site numerous other examples.

For several years the GNU project has touted its Guile Scheme interpreter as the future configuration/scripting language for GNU applications. To date, none of the major GNU programs (GCC, GDB, Emacs, Make) embed Guile. Do you expect this to change soon? Have you considered replacing Scheme with Java in this plan?

Thanks
-John

There have already been a bunch of great ideas; here are mine.

Build community ties. By helping out with other projects, you get your own name out there. When people know who you are, especially when you have helped them with their projects, they will be more likely to use and advertise for your site. How can you help out others?

• Offer to code review projects you are interested in
• Offer to write content. Sites like osOpinion, OS Online, and Kuro5hin are always looking for content. themes.org has been advertising for help for a while, in a bunch of areas, inclusing webmastering, PHP development,and mysql management.
• The GNU project is always looking for help, and has a large tasks list; helping out the FSF is a great way to establish yourself.

Once you have content up on some of these sites, its easy to reference your own site, whether through direct links, author bios, or something similar. I'm not advocating using other sites for your own gain; I'm advocating reciprocation. You help them, they help you. You may even find that your site has a very natural tie-in with another site, and you can work together to share data, user info, stories, and the like.

Of course, you can always just stick some advertising in your /. sig.

darren

There have already been a bunch of great ideas; here are mine.

Build community ties. By helping out with other projects, you get your own name out there. When people know who you are, especially when you have helped them with their projects, they will be more likely to use and advertise for your site. How can you help out others?

• Offer to code review projects you are interested in
• Offer to write content. Sites like osOpinion, OS Online, and Kuro5hin are always looking for content. themes.org has been advertising for help for a while, in a bunch of areas, inclusing webmastering, PHP development,and mysql management.
• The GNU project is always looking for help, and has a large tasks list; helping out the FSF is a great way to establish yourself.

Once you have content up on some of these sites, its easy to reference your own site, whether through direct links, author bios, or something similar. I'm not advocating using other sites for your own gain; I'm advocating reciprocation. You help them, they help you. You may even find that your site has a very natural tie-in with another site, and you can work together to share data, user info, stories, and the like.

Of course, you can always just stick some advertising in your /. sig.

darren

If we imagine a number of operating systems and hardware developers, all cooperating on an equal footing, UDI (if technically feasible) would be a very good idea. It would permit us to develop just one driver for any given hardware device, and then all share it. It would enable a higher level of cooperation.

• "People could run free GPL-covered Linux drivers with Windows systems." If the GPL-covered drivers are dynamically loaded, this is probably true. However, the cat's out of the bag on this one; the proprietary company could always port the GPL driver to UDI themselves.
• "It would not directly hurt us, either; but the developers of GPL-covered free drivers could be discouraged to see them used in this way, and that would be very bad." Look at the flip side; developers of GPL-covered free drivers might be very encouraged to see their driver used on a wide variety of free kernels, knowing that their efforts have been leveraged to increase the greater good. (This could outweigh the downside of possible use by proprietary systems, couldn't it?)
• "People could run non-free Windows drivers on GNU/Linux systems." The cat's out of the bag on this one already also; since Linus has declared the API between the Linux kernel and device drivers to be public, and not covered by the GPL, it is already possible to distribute proprietary drivers for Linux. (One might try to argue that this is still improper under the GPL, but Linus would have to enforce it, and it appears that he won't.)
• "To the extent that the community began to accept the temptation, we would be moving to using non-free drivers instead of writing free ones." This is a user/developer education issue more than anything. It is important to help people understand the value of freedom for its own sake. Many people have trouble with that concept (witness the struggles of the Libertarian Party), since too many people are willing to sacrifice liberty for convenience. This is an ongoing battle, with or without UDI.
• "But why encourage the community to be weaker than it needs to be? Why make unnecessary difficulties for the future of free software? Since UDI does no good for us, it is better to reject UDI." Having a lack of stable APIs for device drivers makes us weaker. (Look at how often Linux drivers have needed to be recoded to adapt to kernel architectural changes.) Having incompatible drivers between different free operating systems (e.g. Linux, FreeBSD, NetBSD, HURD) creates unnecessary difficulties, keeping us much more factionalized, which makes us much weaker than Windows. If free operating system developers could cooperate and leverage their efforts, we have a lot to be gained here. What does Microsoft have to gain here? Not much; the hardware vendors will always write drivers for Windows without Microsoft lifting a finger, as long as Windows is the dominant platform. If we could level the playing field with UDI, Microsoft would lose a key strategic advantage they currently enjoy over free operating systems.
• "Given these consequences, it is no surprise that Intel, a supporter of UDI, has started to ``look to the Linux community for help with UDI.'' How does a richand self-seeking company approach a cooperating community? By asking for a handout, of course. They have nothing to lose by asking, and we might becaught off guard and say yes." I agree that Intel was less than tactful in asking (nay, expecting) Linux developers to assume the burden of UDI driver development. (Bear in mind, however, that UDI originated with SCO a number of years before Intel recently jumped on the bandwagon; it started as a standardization attempt for UNIX systems.) Indeed, Intel is hoping to freeload off our efforts. They should have offered some fair compensation for our efforts, such as writing their own UDI drivers for all old and new Intel hardware, and releasing those drivers as free software along with hardware specifications. A commitment like that would have been taken more seriously. Instead, they asked for a handout, and it backfired on them. Now we have many honorable members of the free software community hostile to the idea of UDI (irrespective of the technology) because of the (correct) perception that Intel (and others) would like to take advantage of our efforts in this area. At the same time, "don't cut off your nose to spite your face." Free software can benefit greatly from a common API (whether UDI or not), and refusing to use one because it might help "the enemy" still leaves us in the same mess we've been in for too long. Let's evaluate it on the benefits we can derive, not on the benefits we can deny to the opposition.
• "One way to make a deal a good one could be by modifying the UDI project itself. Eric Raymond has proposed that UDI compliance could require that the driver be free software. That would be ideal, but other alternatives could also work. Just requiring source for the driver to be published, and not a trade secret, could do the job--because even if that driver is not free, it would at least tell us what we need to know to write a free driver." Actually, a good start would be to convince them to honor their commitment to place the specification in the public domain as described in the following paragraph from the "Project UDI Policies and Procedures" page:
  
  

  The definition of any specification developed by the working group will be placed in the public domain, not subject to copyright, patent or any other intellectual property right, so that any party may implement or utilize the specification. However, any party may develop and assert intellectual property rights over a particular implementation of the interface.

  This statement couldn't be any more clear, yet the UDI 1.0 specification as finally released has an entire page filled to the brim with copyright declarations. A good question for Project UDI is why they failed to follow through on this commitment. (The lawyers probably insisted...)
  
  UDI drivers released by vendors would be valuable to us, even if some of those vendors fail to release their UDI drivers as free software. First, the source to a non-free driver might be published by the vendor, simply to increase market share -- UDI compatibility is only guaranteed at the source level. Even if the source is not released, the UDI driver is tightly constrained; it must funnel all interaction with outside code and actual devices through the UDI environment implementation -- this allows "black box" investigations that can easily see what effects the driver has, even if the source is not available. This should make UDI drivers easier to reverse-engineer than Windows drivers, especially if a special "test-rig" UDI environment implementation was created to facilitate such reverse-engineering.
• "One difficulty with any deal with Intel about UDI is that we would do our part for Intel at the beginning, but Intel's payback would extend over a long time." Not necessarily; we could implement UDI environments for free operating systems and wait for them to start creating some UDI drivers before we put too much more effort into it. After all, they have a vested interested; they'll surely invest some effort into writing drivers if they can't get us to subsidize their bottom line with charity work. Free-software developers might still port some drivers in their own interest (e.g. a FreeBSD hacker porting a Linux driver to UDI, perhaps) but we wouldn't have to "loan" our efforts to Intel (et al) if we choose not to. Even if we don't, we might as well implement UDI environments to take advantage of the work of proprietary companies...

If we imagine a number of operating systems and hardware developers, all cooperating on an equal footing, UDI (if technically feasible) would be a very good idea. It would permit us to develop just one driver for any given hardware device, and then all share it. It would enable a higher level of cooperation.

• "People could run free GPL-covered Linux drivers with Windows systems." If the GPL-covered drivers are dynamically loaded, this is probably true. However, the cat's out of the bag on this one; the proprietary company could always port the GPL driver to UDI themselves.
• "It would not directly hurt us, either; but the developers of GPL-covered free drivers could be discouraged to see them used in this way, and that would be very bad." Look at the flip side; developers of GPL-covered free drivers might be very encouraged to see their driver used on a wide variety of free kernels, knowing that their efforts have been leveraged to increase the greater good. (This could outweigh the downside of possible use by proprietary systems, couldn't it?)
• "People could run non-free Windows drivers on GNU/Linux systems." The cat's out of the bag on this one already also; since Linus has declared the API between the Linux kernel and device drivers to be public, and not covered by the GPL, it is already possible to distribute proprietary drivers for Linux. (One might try to argue that this is still improper under the GPL, but Linus would have to enforce it, and it appears that he won't.)
• "To the extent that the community began to accept the temptation, we would be moving to using non-free drivers instead of writing free ones." This is a user/developer education issue more than anything. It is important to help people understand the value of freedom for its own sake. Many people have trouble with that concept (witness the struggles of the Libertarian Party), since too many people are willing to sacrifice liberty for convenience. This is an ongoing battle, with or without UDI.
• "But why encourage the community to be weaker than it needs to be? Why make unnecessary difficulties for the future of free software? Since UDI does no good for us, it is better to reject UDI." Having a lack of stable APIs for device drivers makes us weaker. (Look at how often Linux drivers have needed to be recoded to adapt to kernel architectural changes.) Having incompatible drivers between different free operating systems (e.g. Linux, FreeBSD, NetBSD, HURD) creates unnecessary difficulties, keeping us much more factionalized, which makes us much weaker than Windows. If free operating system developers could cooperate and leverage their efforts, we have a lot to be gained here. What does Microsoft have to gain here? Not much; the hardware vendors will always write drivers for Windows without Microsoft lifting a finger, as long as Windows is the dominant platform. If we could level the playing field with UDI, Microsoft would lose a key strategic advantage they currently enjoy over free operating systems.
• "Given these consequences, it is no surprise that Intel, a supporter of UDI, has started to ``look to the Linux community for help with UDI.'' How does a richand self-seeking company approach a cooperating community? By asking for a handout, of course. They have nothing to lose by asking, and we might becaught off guard and say yes." I agree that Intel was less than tactful in asking (nay, expecting) Linux developers to assume the burden of UDI driver development. (Bear in mind, however, that UDI originated with SCO a number of years before Intel recently jumped on the bandwagon; it started as a standardization attempt for UNIX systems.) Indeed, Intel is hoping to freeload off our efforts. They should have offered some fair compensation for our efforts, such as writing their own UDI drivers for all old and new Intel hardware, and releasing those drivers as free software along with hardware specifications. A commitment like that would have been taken more seriously. Instead, they asked for a handout, and it backfired on them. Now we have many honorable members of the free software community hostile to the idea of UDI (irrespective of the technology) because of the (correct) perception that Intel (and others) would like to take advantage of our efforts in this area. At the same time, "don't cut off your nose to spite your face." Free software can benefit greatly from a common API (whether UDI or not), and refusing to use one because it might help "the enemy" still leaves us in the same mess we've been in for too long. Let's evaluate it on the benefits we can derive, not on the benefits we can deny to the opposition.
• "One way to make a deal a good one could be by modifying the UDI project itself. Eric Raymond has proposed that UDI compliance could require that the driver be free software. That would be ideal, but other alternatives could also work. Just requiring source for the driver to be published, and not a trade secret, could do the job--because even if that driver is not free, it would at least tell us what we need to know to write a free driver." Actually, a good start would be to convince them to honor their commitment to place the specification in the public domain as described in the following paragraph from the "Project UDI Policies and Procedures" page:
  
  

  The definition of any specification developed by the working group will be placed in the public domain, not subject to copyright, patent or any other intellectual property right, so that any party may implement or utilize the specification. However, any party may develop and assert intellectual property rights over a particular implementation of the interface.

  This statement couldn't be any more clear, yet the UDI 1.0 specification as finally released has an entire page filled to the brim with copyright declarations. A good question for Project UDI is why they failed to follow through on this commitment. (The lawyers probably insisted...)
  
  UDI drivers released by vendors would be valuable to us, even if some of those vendors fail to release their UDI drivers as free software. First, the source to a non-free driver might be published by the vendor, simply to increase market share -- UDI compatibility is only guaranteed at the source level. Even if the source is not released, the UDI driver is tightly constrained; it must funnel all interaction with outside code and actual devices through the UDI environment implementation -- this allows "black box" investigations that can easily see what effects the driver has, even if the source is not available. This should make UDI drivers easier to reverse-engineer than Windows drivers, especially if a special "test-rig" UDI environment implementation was created to facilitate such reverse-engineering.
• "One difficulty with any deal with Intel about UDI is that we would do our part for Intel at the beginning, but Intel's payback would extend over a long time." Not necessarily; we could implement UDI environments for free operating systems and wait for them to start creating some UDI drivers before we put too much more effort into it. After all, they have a vested interested; they'll surely invest some effort into writing drivers if they can't get us to subsidize their bottom line with charity work. Free-software developers might still port some drivers in their own interest (e.g. a FreeBSD hacker porting a Linux driver to UDI, perhaps) but we wouldn't have to "loan" our efforts to Intel (et al) if we choose not to. Even if we don't, we might as well implement UDI environments to take advantage of the work of proprietary companies...

The GPL and LGPL are great licenses, but unfortunately they don't allow you to link to all free software. Is there room for another GPL license, call it GPL-F, that is based on the GPL, but has the following exceptions: (1) You can link any GPL-F to any free software program. Etc.

The GNU Lesser GPL already does that; the GNU GPL includes clause 10 that lets you add a "compatibility clause" to your README saying "This code may be linked to any code that is released as free software." Or just release the same code under multiple licenses, as was done back when BSD had the ad clause.

The GPL and LGPL are great licenses, but unfortunately they don't allow you to link to all free software. Is there room for another GPL license, call it GPL-F, that is based on the GPL, but has the following exceptions: (1) You can link any GPL-F to any free software program. Etc.

The GNU Lesser GPL already does that; the GNU GPL includes clause 10 that lets you add a "compatibility clause" to your README saying "This code may be linked to any code that is released as free software." Or just release the same code under multiple licenses, as was done back when BSD had the ad clause.

The GPL and LGPL are great licenses, but unfortunately they don't allow you to link to all free software. Is there room for another GPL license, call it GPL-F, that is based on the GPL, but has the following exceptions: (1) You can link any GPL-F to any free software program. Etc.

The GNU Lesser GPL already does that; the GNU GPL includes clause 10 that lets you add a "compatibility clause" to your README saying "This code may be linked to any code that is released as free software." Or just release the same code under multiple licenses, as was done back when BSD had the ad clause.

The GPL and LGPL are great licenses, but unfortunately they don't allow you to link to all free software. Is there room for another GPL license, call it GPL-F, that is based on the GPL, but has the following exceptions: (1) You can link any GPL-F to any free software program. Etc.

The GNU Lesser GPL already does that; the GNU GPL includes clause 10 that lets you add a "compatibility clause" to your README saying "This code may be linked to any code that is released as free software." Or just release the same code under multiple licenses, as was done back when BSD had the ad clause.

Cheers,
Gary.

The FSF boycott of Apple was dropped in 1995. See http://www.gnu.org/bulletins/bull18. html#TOC13

1. Why GNU Will Be Compatible with Unix
   Unix is not my ideal system, but it is not too bad. The essential features of Unix seem to be good ones, and I think I can fill in what Unix lacks without spoiling them. And a system compatible with Unix would be convenient for many other people to adopt.

Patrick Volkerding of Slackware fame preferes Boxes to Breifs. Do you agree with this, or have negative feels towards this?

Do you think this issuse has any impact on the Open Source Movement, and do more OSS developers prefer one to the other? What is the trend with commerical developers, and how is the Boxers or Breifs issuse related to software development?

Clearly, the crucial difference between information and acceptable kinds of property is not abstractness per se. So what is it? I propose a simple and practical explanation.

United States copyright law considers copyright a bargain between the public and "authors" ... The public trades certain freedoms in exchange for more published works to enjoy.

In other words, it appears to me that with the availability of both copy right and left, we are having our cake and eating it, too. We have propriety software to lead development in marginally worthwhile things, and rich people that will pay them to do it. And for the rest of us, we have an increasingly vast corpus of good freebeer freedom software.

Or to put it another way: is not the GPL itself implemented in copyright? It is as if you were for Unix but against C.

He answers it at http://www.gnu.org/philosoph y/microsoft-antitrust.html.

You should ask that question from ESR; we're not members of the open source community, we're members of the free software community. Please see this page for an explanation.

First, congratulations and thank you. I remeber reading the GNU Manifesto in Dr. Dobbs' back in the 80's and being totally blown away.

I've just returned from rereading the essay on the GNU site concerning the BSD license . In it, you refer to the "obnoxious BSD advertising clause".

Subsequent to the publication of this essay, you went on record asking the community not to refer to a Linux system as just "Linux"

I've seen reports that your position on "GNU/Linux" versus "Linux" goes farther than the temperate and informative essay linked to above -- for example refusing to answer questions at press conferences/public Q&A sessions/etc. about "Linux" until the question was rephrased to use "GNU/Linux" or () "Lignux".

How is this insistence different from the "obnoxious advertising clause" that you so rightfully object to in the classic BSD license?

First, congratulations and thank you. I remeber reading the GNU Manifesto in Dr. Dobbs' back in the 80's and being totally blown away.

I've just returned from rereading the essay on the GNU site concerning the BSD license . In it, you refer to the "obnoxious BSD advertising clause".

Subsequent to the publication of this essay, you went on record asking the community not to refer to a Linux system as just "Linux"

I've seen reports that your position on "GNU/Linux" versus "Linux" goes farther than the temperate and informative essay linked to above -- for example refusing to answer questions at press conferences/public Q&A sessions/etc. about "Linux" until the question was rephrased to use "GNU/Linux" or () "Lignux".

How is this insistence different from the "obnoxious advertising clause" that you so rightfully object to in the classic BSD license?