Bulldog charge £40 pcm for that service plan in the city I live. Further, they don't offer static IP addresses as standard for consumer accounts and they charge an extra £10 per month for 8 addresses on top of the £52 they ask for their business service plan.
Interesting, but they need some serious competition.
In the UK, the most common situation is to pay BT, the former nationalised telco, £10.50 (about US$19) per month for 'line rental' (i.e voice only). ADSL usually costs £25-50/US$44-88 (for 'activation', sometimes including the loan of a basic router or USB modem) then between £15 and £25 (US$27-$44) per month for a 512kbps/256kbps 50:1 connection. Most ISPs are currently in the process of doubling the 512kbps to 1Mbps for the same price.
The regulator ruled a few years ago that BT had to open up the local loop to third party telcos, but we're only starting to get widespread takeup of this. As far as I can see, most of the action is in London.
We also have cable TV telcos like Telewest and NTL; I'm not an expert on their pricing (I've never bothered looking into it, since my home isn't cabled, despite being in the inner city and in a street in which all the ordinary houses have spurs) but I think prices start from about £15 per month including a voice line, a basic cable package and broadband (2Mbps/256kbps, I think).
Ryan C. Gordon would be the first person I'd contact to do a port of a Windows game to Linux. If he isn't able to do it (probably due to time restraints, rather than anything else), he will probably know someone who can.
Obtain a large number of memory sticks branded distinctively with the company's logo/colours. Hand these out freely to employees. Make replacements easily obtainable on request subject to a record of issue being made.
Only company-branded memory sticks can be used in company-owned machines. Using non-company-owned sticks in company-owned machines is considered a disciplinary offence.
Company-owned sticks that are inserted into non-company owned machines must be considered compromised and the company must be informed of such events.
On termination of employment, all company-issued property must be returned, including memory sticks. These are scanned for presence of illegitimate files.
The above policies aren't perfect, but they may be good enough to stop the most stupid offenders.
Alternatively, just put physical locks on the USB ports of company-owned hardware.
1. What end user can add a repository without special training?
Anyone that can download a file and do 'rpm -ivh batman-repo-0.1-1.noarch.rpm' or whatever (i.e. it has the sole function of dropping a.repo file in/etc/yum.d/, or equivalent for Debian).
2. Why would a commercial vendor want to setup an entire repository just to distribute his 5 megs of software?
There's nothing special about a repository; it's just an ftp or http site that has some packages in directories, and has a tool run over it periodically (e.g. off a cron job) to extract headers for use by dependency solvers such as yum and apt.
3. What end user is going to want to add a repository for every piece of software he wants to install?
Well, it'll only be one per independent manufacturer. And, really, what's the big deal about making the standard Linux install procedure (assuming the user has never previously installed a Batman, Inc. package, otherwise it's just step c):
a) download batman-repo-0.1-1.noarch.rpm
b) rpm -ivh batman-repo-0.1-1.noarch.rpm (some GUIs can easily automate this, just with a double click)
c) yum -y install batman-app
? Why is this obviously worse than:
a) insert CD
b) open it, click setup.exe, or maybe install.exe, or possibly bma037bw.exe
c) answer lots of "technical" questions
d) find serial number/license key
e) find correct serial/license key
f) pray that installer finds nothing unexpected on your system, causing it (or your system on the next reboot) to explode in a shower of sparks
Note that, conceivably, the batman-repo package I described initially could be customised for each user and contain authentication details in the URLs used in the.repo file, thus eliminating the need for users to remember keys.
4. How does the vendor know that primary repository changes won't break his software without even a new OS release coming out?
That's no different to Windows (XP SPs broke badly-written apps) or MacOS. If you don't want to release source for your application so it can be maintained by the community, then you need to put some work into doing regular testing (and possibly rebuilds or bug reports - depending on whether you're targeting an unstable-API 'hacker' distro such as Fedora or a stable-API 'enterprise' distro such as RHEL, respectively).
Which reminds me of AREXX. On the face of it just a scripting language. But the killer feature was that most 'modern' (post AmigaOS 2.x) Amiga programs listened to AREXX messages. The result was that you could write a script to automate a program - or several programs. Batch converting a bunch of pictures was a few lines of AREXX, and more elaborate scripts could do quite amazing things.
[...]
It would be nice if more of the good ideas in AmigaOS were adopted in mainstream OS'es, though. Ubiquous scripting support for one.
UNIX tackles the same problem, but using a different approach. Rather than expecting monolithic do-everything applications to be able to respond to scripting messages or whatever, true UNIX applications are built such that what would have once been a sensible AREXX exported functions are built as individual, pipe-able, programs (often referred to as "do one thing, and do it well"). The shell interpreter picks up the rest of the slack. The approach places very low barriers for application developers, but as long as they play by the rules, their applications can be combined with others to do the most amazing things.
It's a shame though, that now UNIX has more monolithic applications (i.e. openoffice, mozilla, and nearly everything for GNOME and KDE) that it's uncommon for these to have any scripting mechanism whatsoever. Some don't even take command line arguments!
Oh, I remember Art Studio. The hours I spent creating images using that thing...
Also, I hacked my copy of Art Studio to remove the lenslok protection and put on a turbo loader to load it from tape at, IIRC, 3000 baud rather than the standard 1500 baud.
Art Studio's manual also taught me how to write a driver for the Kempston E parallel printer interface. I used this to create a driver for the Romantic Robot Multiprint interface I wanted to use with a word processor called The Writer. The Writer wasn't intended to be extended, so I had to fit my driver into, IIRC, 32 or 34 bytes. I did it in 27. This became my GCSE project; probably one of the shortest in existence!:-)
Martin Taylor states (in incredibly vague terms) that Linux and the surrounding FOSS environment is brittle. Perhaps if he was a little more precise in his assertions, we could take him more seriously. Something that Linux does do better than Windows is being able to easily move the discs from one machine to another of the same architecture and have everything carry on working the same as before, without any re-installation. His anecdote regarding Flyi.com doesn't jive with my experiences. If they combined the upgrades with some re-architecting of their own applications (possibly to deal with their own design flaws) maybe. But otherwise, they should have been able to rip the discs out of the 32MB 386DX-40 they were using and stuff them in a 4GB Xeon with no changes (though replacing the kernel and a few other packages with i686-optimized versions would improve performance further).
Having access to source code is important, as no matter how good the documentation is (and Microsoft's developer documentation is lousy, according to some my of developer friends), nothing beats being able to look at the source of the library or OS component you're using to see exactly what it does. At the very least, it allows you to see that that component isn't built to handle the situation you're trying to get it to deal with, and you can work around that, or change the environment to match the assumptions made by the programmer of that component. Since different people rely on different parts of the OS, 65% source code availability may meet the need of 100% of developers (if no-one ever uses the remaining 35%) or 0% (if the 65% available isn't interesting to anyone). Only 100% availability is guaranteed to meet the needs of 100% of developers.
Regarding the GPL, Taylor at least gives the honest answer that he "[doesn't] know enough". Firstly, the GPL covers patents, and says that code licensed under the GPL must license any patented techniques used therein for "everyone's free use" or the code may not be licensed under the GPL at all. Secondly, people can build upon FOSS and monetize their innovations; without restrictions if the components they use are licensed under the terms of the LGPL or BSD licenses (and they comply with the terms of those licenses) or with some restrictions if not. Red Hat are successfully monetizing their innovations despite having to comply even with the terms of the GPL. Done right, anyone else can too.
On buffer overflows, Taylor states that "people didn't really understand buffer overruns and port 80 and I/O issues 10 years ago". Well, the guys writing articles for Phrack probably did, seeing as they published an in-depth explanation on 8 November 1996. What Taylor probably means is that people at Microsoft didn't really understand buffer overruns ten years ago. Shame on them. It was taught on the mediocre Computer Science degree course I followed between 1992 and 1995.
he most annoying things about VMS - to a UNIX geek - are
* a) no 'cd' command -
SET DEF
No, I literally mean 'cd'. 'cd' is a pretty standard way of changing directory and it applies to AmigaDOS, DOS, UNIX and CP/M (I think).
* b) apparent lack of relative paths
DIR [---.FOO.BAR.SNIVLE]SNAGGLE.BAZ
Each "-" send you up one level, and ".", if you remember, is the subdirectory delimiter
Cool. I suspected there might be, hence my 'apparent'. I don't recall any of my VMS-hacking peers showing me '-'.
* c) system-wide date/time a la Windows,
Huh?
UNIX has per-user date/time, derived from the system clock combined with the per-user TZ environment variable. The UNIX system clock always runs as UTC, and everything else is derived from it. Windows' system clock seems intended to be run as local time. VMS seemed to me to be a confusing mix of the two approaches, depending on what software you have installed.
Unix was very strange to me, with it's cryptic commands and *ix could definitely learn a thing or 20 from the VMS command-line parser, like only having to type in a maximum of 4 characters for each command and option, even when it's a long command like DIRECTORY.
Shell aliases and tab completion have been around for many years now.:-)
As are ASN.1 parsing vulnerabilities because ASN.1 is so hard to parse that nearly everyone who uses it ends up using the same flawed ASN.1 parsing codebase.
As a fairly dyed-in-the-wool UNIX type (or more precisely, POSIX, since I started with the Amiga, which is more POSIX-like than anything else, IMHO), VMS seemed very odd to me when I picked up bits and pieces from an ex-DEC greybeard VMS geek.
Bits of it are marvellously elegant and I struggle to think of clean ways of implementing equivalent things within a UNIX-like OS. Other bits seem oddly like DOS or embedded OSs such as vxWorks (more precisely, DOS and vxWorks sometimes look a bit like VMS). And then, if you install UNIX-originated software such as TCPware on VMS, bits of it/do/ start looking like UNIX.
I was able to support TCPware on UNIX purely because many of the tools were ports or recreations of key parts of the BSD IP stack. I was even able to help a customer set up PPP when none of our experienced TCPware engineers could, because it was using pppd, as on Linux.
The most annoying things about VMS - to a UNIX geek - are a) no 'cd' command b) apparent lack of relative paths c) system-wide date/time a la Windows, except in parts, when TCPware is installed (making for a very confusing experience around DST changeover days, especially if you have NFS in the mix too).
You're entirely right that a lot of licenses should be really MPL-like, definitely not the GPL. This just shows the ignorance regarding the licenses. Law firms, ahoy!
Only if the original author has the intention from the outset of having the possibility of easily producing a non-GPL licensed edition (i.e. without having to seek permission or reassignment from every individual contributor at a later date). I think in most cases, original authors have made a positive choice to use the GPL for their code. I know I have (in preference to BSD and Artistic) for a package I wrote and for which the primary purpose was as a piece of example/demonstration code for a third-party library.
What I meant was that dual-licensing is happening all over! Small projects wanna do it.
I think original authors are entitled to have the right to dual license if they wish, though I'd prefer they wouldn't, and didn't feel the need to.
AFAIK, the only big projects that are carefull are OO.org and the FSF. They demmand that you fill a paper form and snail-mail it giving up on your copyright.
I agree that that the prudent approach is that of not assuming you can dual-license, but a lot of people are assuming the contrary, either due to unfairness or ignorance (the hype and noise around GNU, Linux and the GPL).
People need to be conscious about what they're getting into if they contribute to a project. Is it serious? Or are they going to dual-license it and just say "thanks very much for your code", or simply turn it closed-source once they think it's good enough?
My point was that the BSD license levels the playing field for everybody. Either that or the LGPL. Projects like JBoss use the LGPL because they want the reciprocity that it provides.
Now you've lost me. What additional reciprocity or protection from dual-licensing does the LGPL give that the GPL does not? The only extra the LGPL allows that the GPL does not is that closed, proprietary applications may be linked against it (providing they use the published API) without themselves being subject to the (L)GPL. As the copyright owners of JBoss, JBoss Inc. could, if they wished, take the next version of JBoss proprietary. You have only their honour and their word that they won't (combined with the threat of legal action from an offended contributor who didn't want to implicitly reassign their copyright), just like with any other GPLed project. JBoss Inc. are not bound by the terms of the LGPL regarding code that they own unless they want to be.
However, the FSF actively plays against the the LGPL and they renamed it to "Lesser GPL." This license is adequate for libraries, though.
Well, it depends on the code. As I wrote in a previous commment, pick the right license for the code according to its role. If you're building something that you'd like to be used as standard (e.g. a desktop environment) in Free operating systems, even by proprietary applications, LGPL is probably the way to go. If you've built something valuable and unique that you'd like to only make available to Free applications (in effect providing a Unique Selling Point for Free OSs and applications), then the GPL might be a better bet.
I guess we can assume from this discussion that there are a lot more subtleties to licensing than people assume. Knee-jerk reactions defending the GPL just won't cut it.
What differentiates the GPL and the BSD license is that, having contributed with the original authors they are the ones who sell the software. You cannot do it, legally.
No, you're thinking of MPL-like licenses where the original author explicitly reserves this right for themselves but does not grant it to contributors.
The GPL says nothing about whether contributions can be dual-licensed and so this defaults to normal copyright law (i.e. the contributions are owned by their respective authors unless they have explicitly signed over their copyright to the original author, or some organisation or foundation).
Therefore, anyone - even the original author - who attempted to release a proprietary fork under a non-GPL license would be on dangerous ground if any contributor objects and cares enough to sue, I reckon. IANAL, though. Someone defending the proprietary forker might very well make the case that by contributing to a GPLed project, contributors had implicitly assigned their copyright to the original author unless they explicitly reserved and asserted it with a copyright notice or similar. I'd be genuinely surprised if that defense would win, though.
As you say, though, the GPL is untested, but that's because so far, anyone accused of infringement settles before going to court. To my mind, they'd only do that if that's what they lawyer advises them to do. A prudent approach, in my opinion, is to assume that you aren't allowed to dual-license contributions if you're the original author, and that the original author is allowed to dual-license if you're a contributor. If you don't like that, don't accept contributions without explicit reassignment of rights or don't contribute, respectively. I'd say it's rare that an individual contribution warrants significant thought on the matter, though.
Ultimately, though, no-one forces anyone to incorporate Free software into their product. If they don't like the rules the copyright owner(s) have set, they should ignore it and write their own damn code. Heck, the GPL allows one to study code and use it as a reference for your own code.
Being the sole author or my software allows me to dual license it. If somebody wants to use my code in a closed-source project, I can grant them a seperate license in exchange for a fee.
And that is why anyone with half a brain should never contribute to your project, because that would mean you take their code too, and sell it, while they can't do it.
Not necessarily. If the OP's code is sufficiently unique and useful, then it may be used regardless of the license. If it is then discovered that it needs to be modified, this may also happen. After a cycle or two of trying to keep the patchsets private (entirely allowed by the GPL, providing no distribution is taking place) they may very well contribute them so they no longer have the costs of maintaining the patchset (effectively a private fork) themselves.
Only the BSD license allows fair play.
The BSD license is fine, but the GPL and LGPL are rather more assertive. If you don't like their rules, don't play and write your own code. Personally, I think that (with the exception of trying to supply the canonical implementation of a standard) people who release code under the BSD license are allowing themselves to be taken as mugs. That's their choice though.
So you'd have to pay $225 to save $150; and of course you wouldn't.
That assumes:
a) that all information is available to the customer.
b) that the prospective customer has done the maths.
c) that the customer acts rationally.
If you ask me, those are some pretty big assumptions.
1) Stop and uninstall network servers that you will never need (e.g. rpm -e)
2) Stop and Disable network servers that you do not need right now (e.g. chkconfig --del)
3) Restrict access to the rest using built in ACLs, tcp_wrappers (i.e. hosts.allow/hosts.deny) and/or iptables/netfilter.
4) Set strong passwords where applicable.
5) Keep patched up-to-date.
6) If your distribution includes SELinux, consider enabling it. Test thoroughly before moving to production status.
7) Perform regular backups.
8) Test your backups and your backup hardware.
9) Monitor log files.
To do anything more than that requires fairly extreme justification, and will increase costs due to administrative overhead. Doing the above will probably render your site a less attractive target than 90-something percent of sites. If you and a friend are running away from a tiger, you don't need to outrun the tiger - just your friend.:-)
The ideal scenario is some kind of PDA-gadget they take with them to the market to compare the prices at that store with others in the same area, or for web purchases, something that interjects at the point-of-purchase.
That would be the perfect time to say, "Yes, Cocoa-Puffs ARE cheaper here, but did you know they anally rape their employees with weed whackers?", or something like that.
As far as I can see, there is a need for a minimal set of about four Free software licenses:
BSD-like for code that either isn't terribly interesting or important enough to care about it being embraced and extended or code that represents a canonical implementation of a proposed standard that it is hoped will be widely adopted. Yes, even by Microsoft.
GPL-like for interesting and unique code that presents a "Unique Selling Point" for Free-as-in-speech software. Organisations that want use it to reduce development costs and to later redistribute products need to accept the author's terms, or get off their arse and develop their own equivalent code.
LGPL-like for code that would, if it weren't for its intended usage, be otherwise licensed as GPL-like above, but it's better if it's widely used. Yes, even by proprietary applications.
MPL-like for 'donated' code for which the original author wishes to reserve rights for themselves that they don't necessarily wish to grant to others. Their code, their right to choose. If you don't like it, play somewhere else.
None of what I've written above is original, even rms has said similarthings in the past.
Conceivably, I can accept (and even hope for) the theoretical possibility that the time will come when everyone accepts that Free software is here to stay and that no-one wishes to try to selfishly exploit it. Just like the possibility that one day humans will learn to treat each other with respect and consequently, police forces, weapons, property rights and even laws are no longer necessary to deter unwanted exploitation. Sadly, that day is not yet here. And that's where I disagree with esr.
Now add the cost for a decent quality (e.g. Asus, Intel, Gigabyte, Tyan) motherboard (and basic VGA card if one isn't included onboard) and RAM. The last time I did this (for Xeon vs. Opteron) the Opteron system turned out to be more expensive.
If you look at it like that, then Assursys also exists to make money for its owners. But that doesn't mean the owners don't think what they do also helps outs the world in some small way.
Quite possibly, since Assursys was, and presently is just l'il 'ole me. Its primary function, though, was unashamedly to make me money. That said, it's quite easy for small companies to be representative of individual ethics. This isn't usually the case with larger organisations, mainly due to the devolution of personal responsibility for actions carried out by and for the organisation.
That is why I hire a bank, an organization that exists only to secure my money and insure nobody gets it without my permission.
No, banks exist to make money for their shareholders. They do so by loaning multiples of the money you deposit and charging a differential interest rate to that they pay you. As long as they keep your money safe enough (or refund you when they don't) such that you don't lose confidence in them, they carry on rolling.
Indeed; security vulnerabilities are an externality. If Microsoft (or whoever) thought they'd make (at least) proportionally bigger profits by writing more secure software than they do at present, they'd expend the effort. As it is, though, the market signals to them that the software they're selling right now is 'secure enough' by continuing to buy it.
Typical solutions to externalities and other market failures are either a) regulation (usually imposed by government) or b) widespread boycott of offending organisations. Pick your poison.
Slashdot Mirror
Interesting, but they need some serious competition.
The regulator ruled a few years ago that BT had to open up the local loop to third party telcos, but we're only starting to get widespread takeup of this. As far as I can see, most of the action is in London.
We also have cable TV telcos like Telewest and NTL; I'm not an expert on their pricing (I've never bothered looking into it, since my home isn't cabled, despite being in the inner city and in a street in which all the ordinary houses have spurs) but I think prices start from about £15 per month including a voice line, a basic cable package and broadband (2Mbps/256kbps, I think).
Ryan C. Gordon would be the first person I'd contact to do a port of a Windows game to Linux. If he isn't able to do it (probably due to time restraints, rather than anything else), he will probably know someone who can.
Obtain a large number of memory sticks branded distinctively with the company's logo/colours. Hand these out freely to employees. Make replacements easily obtainable on request subject to a record of issue being made.
Only company-branded memory sticks can be used in company-owned machines. Using non-company-owned sticks in company-owned machines is considered a disciplinary offence.
Company-owned sticks that are inserted into non-company owned machines must be considered compromised and the company must be informed of such events.
On termination of employment, all company-issued property must be returned, including memory sticks. These are scanned for presence of illegitimate files.
The above policies aren't perfect, but they may be good enough to stop the most stupid offenders.
Alternatively, just put physical locks on the USB ports of company-owned hardware.
Anyone that can download a file and do 'rpm -ivh batman-repo-0.1-1.noarch.rpm' or whatever (i.e. it has the sole function of dropping a .repo file in /etc/yum.d/, or equivalent for Debian).
2. Why would a commercial vendor want to setup an entire repository just to distribute his 5 megs of software?
There's nothing special about a repository; it's just an ftp or http site that has some packages in directories, and has a tool run over it periodically (e.g. off a cron job) to extract headers for use by dependency solvers such as yum and apt.
3. What end user is going to want to add a repository for every piece of software he wants to install?
Well, it'll only be one per independent manufacturer. And, really, what's the big deal about making the standard Linux install procedure (assuming the user has never previously installed a Batman, Inc. package, otherwise it's just step c):
a) download batman-repo-0.1-1.noarch.rpm
b) rpm -ivh batman-repo-0.1-1.noarch.rpm (some GUIs can easily automate this, just with a double click)
c) yum -y install batman-app
? Why is this obviously worse than:
a) insert CD
b) open it, click setup.exe, or maybe install.exe, or possibly bma037bw.exe
c) answer lots of "technical" questions
d) find serial number/license key
e) find correct serial/license key
f) pray that installer finds nothing unexpected on your system, causing it (or your system on the next reboot) to explode in a shower of sparks
Note that, conceivably, the batman-repo package I described initially could be customised for each user and contain authentication details in the URLs used in the .repo file, thus eliminating the need for users to remember keys.
4. How does the vendor know that primary repository changes won't break his software without even a new OS release coming out?
That's no different to Windows (XP SPs broke badly-written apps) or MacOS. If you don't want to release source for your application so it can be maintained by the community, then you need to put some work into doing regular testing (and possibly rebuilds or bug reports - depending on whether you're targeting an unstable-API 'hacker' distro such as Fedora or a stable-API 'enterprise' distro such as RHEL, respectively).True, and GNOME has (or did have, anyway) CORBA at its core. But I've not seen much touting them as a technology for end-users (albeit power-users).
[...]
It would be nice if more of the good ideas in AmigaOS were adopted in mainstream OS'es, though. Ubiquous scripting support for one.
UNIX tackles the same problem, but using a different approach. Rather than expecting monolithic do-everything applications to be able to respond to scripting messages or whatever, true UNIX applications are built such that what would have once been a sensible AREXX exported functions are built as individual, pipe-able, programs (often referred to as "do one thing, and do it well"). The shell interpreter picks up the rest of the slack. The approach places very low barriers for application developers, but as long as they play by the rules, their applications can be combined with others to do the most amazing things.
It's a shame though, that now UNIX has more monolithic applications (i.e. openoffice, mozilla, and nearly everything for GNOME and KDE) that it's uncommon for these to have any scripting mechanism whatsoever. Some don't even take command line arguments!
Also, I hacked my copy of Art Studio to remove the lenslok protection and put on a turbo loader to load it from tape at, IIRC, 3000 baud rather than the standard 1500 baud.
Art Studio's manual also taught me how to write a driver for the Kempston E parallel printer interface. I used this to create a driver for the Romantic Robot Multiprint interface I wanted to use with a word processor called The Writer. The Writer wasn't intended to be extended, so I had to fit my driver into, IIRC, 32 or 34 bytes. I did it in 27. This became my GCSE project; probably one of the shortest in existence! :-)
Having access to source code is important, as no matter how good the documentation is (and Microsoft's developer documentation is lousy, according to some my of developer friends), nothing beats being able to look at the source of the library or OS component you're using to see exactly what it does. At the very least, it allows you to see that that component isn't built to handle the situation you're trying to get it to deal with, and you can work around that, or change the environment to match the assumptions made by the programmer of that component. Since different people rely on different parts of the OS, 65% source code availability may meet the need of 100% of developers (if no-one ever uses the remaining 35%) or 0% (if the 65% available isn't interesting to anyone). Only 100% availability is guaranteed to meet the needs of 100% of developers.
Regarding the GPL, Taylor at least gives the honest answer that he "[doesn't] know enough". Firstly, the GPL covers patents, and says that code licensed under the GPL must license any patented techniques used therein for "everyone's free use" or the code may not be licensed under the GPL at all. Secondly, people can build upon FOSS and monetize their innovations; without restrictions if the components they use are licensed under the terms of the LGPL or BSD licenses (and they comply with the terms of those licenses) or with some restrictions if not. Red Hat are successfully monetizing their innovations despite having to comply even with the terms of the GPL. Done right, anyone else can too.
On buffer overflows, Taylor states that "people didn't really understand buffer overruns and port 80 and I/O issues 10 years ago". Well, the guys writing articles for Phrack probably did, seeing as they published an in-depth explanation on 8 November 1996. What Taylor probably means is that people at Microsoft didn't really understand buffer overruns ten years ago. Shame on them. It was taught on the mediocre Computer Science degree course I followed between 1992 and 1995.
* a) no 'cd' command -
SET DEF
No, I literally mean 'cd'. 'cd' is a pretty standard way of changing directory and it applies to AmigaDOS, DOS, UNIX and CP/M (I think).
* b) apparent lack of relative paths
DIR [---.FOO.BAR.SNIVLE]SNAGGLE.BAZ Each "-" send you up one level, and ".", if you remember, is the subdirectory delimiter
Cool. I suspected there might be, hence my 'apparent'. I don't recall any of my VMS-hacking peers showing me '-'.
* c) system-wide date/time a la Windows,
Huh?
UNIX has per-user date/time, derived from the system clock combined with the per-user TZ environment variable. The UNIX system clock always runs as UTC, and everything else is derived from it. Windows' system clock seems intended to be run as local time. VMS seemed to me to be a confusing mix of the two approaches, depending on what software you have installed.
Unix was very strange to me, with it's cryptic commands and *ix could definitely learn a thing or 20 from the VMS command-line parser, like only having to type in a maximum of 4 characters for each command and option, even when it's a long command like DIRECTORY.
Shell aliases and tab completion have been around for many years now. :-)
As are ASN.1 parsing vulnerabilities because ASN.1 is so hard to parse that nearly everyone who uses it ends up using the same flawed ASN.1 parsing codebase.
Bits of it are marvellously elegant and I struggle to think of clean ways of implementing equivalent things within a UNIX-like OS. Other bits seem oddly like DOS or embedded OSs such as vxWorks (more precisely, DOS and vxWorks sometimes look a bit like VMS). And then, if you install UNIX-originated software such as TCPware on VMS, bits of it /do/ start looking like UNIX.
I was able to support TCPware on UNIX purely because many of the tools were ports or recreations of key parts of the BSD IP stack. I was even able to help a customer set up PPP when none of our experienced TCPware engineers could, because it was using pppd, as on Linux.
The most annoying things about VMS - to a UNIX geek - are a) no 'cd' command b) apparent lack of relative paths c) system-wide date/time a la Windows, except in parts, when TCPware is installed (making for a very confusing experience around DST changeover days, especially if you have NFS in the mix too).
Only if the original author has the intention from the outset of having the possibility of easily producing a non-GPL licensed edition (i.e. without having to seek permission or reassignment from every individual contributor at a later date). I think in most cases, original authors have made a positive choice to use the GPL for their code. I know I have (in preference to BSD and Artistic) for a package I wrote and for which the primary purpose was as a piece of example/demonstration code for a third-party library.
What I meant was that dual-licensing is happening all over! Small projects wanna do it.
Examples?
Large projects do it. MySQL does it.
MySQL are the original authors of their code, and so they're perfectly entitled to do so. I agree with Linus Torvalds' view that "He who writes the code gets to say the copyright, and _nobody_ has the right to complain about his/her choice of copyright". As far as I'm aware, MySQL AB have always offered MySQL under other licenses than the GPL, thus they could well be an exception to my previous comment about a 'implicit assignment' defence being unlikely to be upheld.
I think original authors are entitled to have the right to dual license if they wish, though I'd prefer they wouldn't, and didn't feel the need to.
AFAIK, the only big projects that are carefull are OO.org and the FSF. They demmand that you fill a paper form and snail-mail it giving up on your copyright. I agree that that the prudent approach is that of not assuming you can dual-license, but a lot of people are assuming the contrary, either due to unfairness or ignorance (the hype and noise around GNU, Linux and the GPL). People need to be conscious about what they're getting into if they contribute to a project. Is it serious? Or are they going to dual-license it and just say "thanks very much for your code", or simply turn it closed-source once they think it's good enough? My point was that the BSD license levels the playing field for everybody. Either that or the LGPL. Projects like JBoss use the LGPL because they want the reciprocity that it provides.
Now you've lost me. What additional reciprocity or protection from dual-licensing does the LGPL give that the GPL does not? The only extra the LGPL allows that the GPL does not is that closed, proprietary applications may be linked against it (providing they use the published API) without themselves being subject to the (L)GPL. As the copyright owners of JBoss, JBoss Inc. could, if they wished, take the next version of JBoss proprietary. You have only their honour and their word that they won't (combined with the threat of legal action from an offended contributor who didn't want to implicitly reassign their copyright), just like with any other GPLed project. JBoss Inc. are not bound by the terms of the LGPL regarding code that they own unless they want to be.
However, the FSF actively plays against the the LGPL and they renamed it to "Lesser GPL." This license is adequate for libraries, though.
Well, it depends on the code. As I wrote in a previous commment, pick the right license for the code according to its role. If you're building something that you'd like to be used as standard (e.g. a desktop environment) in Free operating systems, even by proprietary applications, LGPL is probably the way to go. If you've built something valuable and unique that you'd like to only make available to Free applications (in effect providing a Unique Selling Point for Free OSs and applications), then the GPL might be a better bet.
I guess we can assume from this discussion that there are a lot more subtleties to licensing than people assume. Knee-jerk reactions defending the GPL just won't cut it.
Likewis
No, you're thinking of MPL-like licenses where the original author explicitly reserves this right for themselves but does not grant it to contributors.
The GPL says nothing about whether contributions can be dual-licensed and so this defaults to normal copyright law (i.e. the contributions are owned by their respective authors unless they have explicitly signed over their copyright to the original author, or some organisation or foundation).
Therefore, anyone - even the original author - who attempted to release a proprietary fork under a non-GPL license would be on dangerous ground if any contributor objects and cares enough to sue, I reckon. IANAL, though. Someone defending the proprietary forker might very well make the case that by contributing to a GPLed project, contributors had implicitly assigned their copyright to the original author unless they explicitly reserved and asserted it with a copyright notice or similar. I'd be genuinely surprised if that defense would win, though.
As you say, though, the GPL is untested, but that's because so far, anyone accused of infringement settles before going to court. To my mind, they'd only do that if that's what they lawyer advises them to do. A prudent approach, in my opinion, is to assume that you aren't allowed to dual-license contributions if you're the original author, and that the original author is allowed to dual-license if you're a contributor. If you don't like that, don't accept contributions without explicit reassignment of rights or don't contribute, respectively. I'd say it's rare that an individual contribution warrants significant thought on the matter, though.
Ultimately, though, no-one forces anyone to incorporate Free software into their product. If they don't like the rules the copyright owner(s) have set, they should ignore it and write their own damn code. Heck, the GPL allows one to study code and use it as a reference for your own code.
And that is why anyone with half a brain should never contribute to your project, because that would mean you take their code too, and sell it, while they can't do it.
Not necessarily. If the OP's code is sufficiently unique and useful, then it may be used regardless of the license. If it is then discovered that it needs to be modified, this may also happen. After a cycle or two of trying to keep the patchsets private (entirely allowed by the GPL, providing no distribution is taking place) they may very well contribute them so they no longer have the costs of maintaining the patchset (effectively a private fork) themselves.
Only the BSD license allows fair play.
The BSD license is fine, but the GPL and LGPL are rather more assertive. If you don't like their rules, don't play and write your own code. Personally, I think that (with the exception of trying to supply the canonical implementation of a standard) people who release code under the BSD license are allowing themselves to be taken as mugs. That's their choice though.
That assumes:
a) that all information is available to the customer.
b) that the prospective customer has done the maths.
c) that the customer acts rationally.
If you ask me, those are some pretty big assumptions.
2) Stop and Disable network servers that you do not need right now (e.g. chkconfig --del)
3) Restrict access to the rest using built in ACLs, tcp_wrappers (i.e. hosts.allow/hosts.deny) and/or iptables/netfilter.
4) Set strong passwords where applicable.
5) Keep patched up-to-date.
6) If your distribution includes SELinux, consider enabling it. Test thoroughly before moving to production status.
7) Perform regular backups.
8) Test your backups and your backup hardware.
9) Monitor log files.
To do anything more than that requires fairly extreme justification, and will increase costs due to administrative overhead. Doing the above will probably render your site a less attractive target than 90-something percent of sites. If you and a friend are running away from a tiger, you don't need to outrun the tiger - just your friend. :-)
That would be the perfect time to say, "Yes, Cocoa-Puffs ARE cheaper here, but did you know they anally rape their employees with weed whackers?", or something like that.
Like the Corporate Fallout Detector, you mean?
BSD-like for code that either isn't terribly interesting or important enough to care about it being embraced and extended or code that represents a canonical implementation of a proposed standard that it is hoped will be widely adopted. Yes, even by Microsoft.
GPL-like for interesting and unique code that presents a "Unique Selling Point" for Free-as-in-speech software. Organisations that want use it to reduce development costs and to later redistribute products need to accept the author's terms, or get off their arse and develop their own equivalent code.
LGPL-like for code that would, if it weren't for its intended usage, be otherwise licensed as GPL-like above, but it's better if it's widely used. Yes, even by proprietary applications.
MPL-like for 'donated' code for which the original author wishes to reserve rights for themselves that they don't necessarily wish to grant to others. Their code, their right to choose. If you don't like it, play somewhere else.
None of what I've written above is original, even rms has said similar things in the past.
Conceivably, I can accept (and even hope for) the theoretical possibility that the time will come when everyone accepts that Free software is here to stay and that no-one wishes to try to selfishly exploit it. Just like the possibility that one day humans will learn to treat each other with respect and consequently, police forces, weapons, property rights and even laws are no longer necessary to deter unwanted exploitation. Sadly, that day is not yet here. And that's where I disagree with esr.
here. Edited highlights:
Power supplies: Built-in li-ion battery pack with approximately 2-3 hours of battery life (depending on model).
Width: Approximately 128-inch [sic] (exact width depends on model)
Weight: Approximately 7 lbs. with battery (exact weight depends on model).
Not exactly a lightweight G4/Pentium M, is it?
Now add the cost for a decent quality (e.g. Asus, Intel, Gigabyte, Tyan) motherboard (and basic VGA card if one isn't included onboard) and RAM. The last time I did this (for Xeon vs. Opteron) the Opteron system turned out to be more expensive.
Actually, now we've implemented the European Copyright Directive, deliberate infringment may be a criminal offence.
Quite possibly, since Assursys was, and presently is just l'il 'ole me. Its primary function, though, was unashamedly to make me money. That said, it's quite easy for small companies to be representative of individual ethics. This isn't usually the case with larger organisations, mainly due to the devolution of personal responsibility for actions carried out by and for the organisation.
No, banks exist to make money for their shareholders. They do so by loaning multiples of the money you deposit and charging a differential interest rate to that they pay you. As long as they keep your money safe enough (or refund you when they don't) such that you don't lose confidence in them, they carry on rolling.
Typical solutions to externalities and other market failures are either a) regulation (usually imposed by government) or b) widespread boycott of offending organisations. Pick your poison.