Thursday, September 27, 2007
It is perfectly legal to "bundle" collections of xGPL and Non-GPL/Non-Free binaries packages on installer medium or on a live CD/DVD or in a hardware appliance as long you abide by the terms of the xGPL licenses for the xGPL binaries. ( For example Redhat's trademark protected or Novell's proprietary enterprise distribution bundles - Still OK to do so? )...
... but what about combining xGPL code and non-GPL licensed items inside an application bundling system ( i.e. Glick http://www.gnome.org/~alexl/glick/ ) ...
"An application bundle is a single file that contains all the data and files needed to run an application, so all the user has to do is start it. There is no need to install it, and if you don't like it you can just remove that file and the whole program will be gone." ...
I'm thinking of the use of something similar to Glick for the distribution of products with all GPL/LGPL/AGPL licensed source code combined with Non-GPL licensed game/service/customized data.
The Non-GPL items in the application bundle could require Per-seat/unit/person licensing, and the combined bundle in some cases may not be legally redistributed...
Assuming that application bundling system could give the the user the ability to :-- (a) un-bundle the xGPL'ed licensed binaries ; AND
- (b) the vendor/packager provides the xGPLed source and downstream rights under the terms of the xGPL ; AND
- (c) the vendor/packager provides tools for the end user to combine modified xGPLed compiled binaries into a modified clone of their copy of the application bundle ; Then ..
Nothing would prevent retribution of the xGPL source or binaries, or the creation of third party rebuilds that replace the non-xGPL components and trademarks. For example projects that provide replacement game-files for the GPL Quake engines or rebuilt clones of Redhat's enterprise distribution that remove Redhat's trademark. However, depending of the licensing of the application bundle, any modified clone of an end users application bundle might not be legally redistributable.
Is distributing such application bundles, as described above, legal under the terms of the GPLv3, LGPLv3 and AGPLv3?Monday, July 17, 2006
Friday, May 19, 2006
Bronwyn H. Hall and Megan MacGarvie's The Private Value of Software Patents takes an economic view of the patent system.
The first conclusion of the paper states "First, we conclude that, as measured by the stock market's reaction to legal decisions expanding the patentability of software, there is no evidence that the expansion of software patentability benefited firms in the software industry."
The second conclusion, derived from an analysis of stock values, states "Combining these two sets of findings, we conclude that the market evaluated software patents as unimportant ex ante and expected that the expansion of software patentability would negatively affect firms in downstream sectors and firms without patents."
If there is no actual benefit to the software industry why do we need to grant such monopolies?
Saturday, February 18, 2006
In answer to Douglas Sorocco
See My February 24, 2005 Questions to USPTO On-Line, which may in part have prodded the USPTO and open source community into this latest action.
Failing direction from governmental legislation, software and other abstract method patents have been forced on the USPTO and the rest of the world by the back doors of legal and administrative precedent. How many countries have actually passed legislation explicitly legitimizing software or abstract patents? Not the USA for one.
Can the you point to any instances where the granting of software related patents has been an actual benefit to the progress of science, useful arts and the software industry in general? In a similar vein, can the you point to any instances where the granting of business method related patents has been an actual benefit to the progress of science, useful arts and industry in general? Have the intellectual property gurus even attempted to address the issues raised by the critics of software patents over the last two decades?
If no positive answer can be given to the above questions, why do we need to grant such monopolies?
Because of the time it takes to get a patent and the six to ten years it has taken to drag the first cases though the courts and appeals, the major negative effect of software patents have just begun to become noticeable. It is going to get a lot worse.
Because of the existing precedent, removing software patents will require the introduction of explicit legislation. That will take time, probably many years to undo the damage from the lobbying by intellectual monopoly advocates such as yourselves.
Until then, helping he USPTO track down prior art in publicly available open source software will greatly reduce the number of patents the software development industry will have to concern itself with.
Also opening up the patent application process could end up improving the quality the remaining granted patents.
Friday, October 28, 2005
I have set up and supported remote sites and home based telecommuting. Listen to my advice, listen very carefully and save your sanity.
If your organization is large enough then it is likely that you will have a few older desktop PCs that have been or are due for replacement during an upgrade cycle. PCs that are inadequate for Microsoft XP and Office2003 are more than powerful enough for many current versions of Linux, especially for the role of server. Also second hand PCs with the required specifications are very cheaply acquired.
1) Find an older PC, at least a PII 300 with 256 MB memory, to set up as a headless ( no display or keyboard ) server and firewall. A simple web based interface ( or even an external hardware push button ) can be used by the local users to start/stop the server and internet connection. All other maintenance should be handled remotely via ssh, webmin and VNC.
2) Install a second NIC or connect the modem directly to the server. Connection to the Internet should be through the server and connection to the Office should be through a VPN on the server. Use a dynamic IP service for each site so you can remotely log on to the local server via ssh.
3) Install a new IDE hard drive in a 3.5" removable rack and tray. The drive should be than big enough for the operating system (Linux of course) and copies of some of the local desktop partitions. A telecommuter can shut down the server and bring in the drive during the day to resync and repair.
4) Install a DHCP demon on the local server to allocate local IP addresses, DNS and gateway settings. If the desktops are network boot capable then install TFTP to remotely boot and use Knoppix via PXE and the network. If the desktop OS is constantly crashing, or is infected by malware, the user can select PXE/network boot via the BIOS, and boot into Knoppix. The user can then be instructed over the phone to enable the ssh server to allow remote scan,repair and reimaging of the desktop partitions. The user can use the Knoppix desktop to continue working with full access to files while the the remote administrator fixes/reimages the drive in the background.( Consider hiring someone who knows how to customise Knoppix or another live Linux system for your setup )
5) Partition the desktops with as small as required C: partition ( or in the case of Linux the root partition ) for software. When software is install, use dd and netcat via live Knoppix to copy/clone a snapshot of the partition to the server. You can allocate the remaining free space as a persistent partition where documents are stored.
6) Install and enable remote VNC service on all the platforms, but only allow incoming connections from the local server ( which is redirected over a SSH tunnel ).
7) For local backup, create share directories on the desktop accessible by the server. On the local server create loopback encrypted file systems, unmount and copy the images to the desktops shares in chunks, using redundancy if enough space is available on the desktops. Checksum ( MD5 is enough ) each piece.
8) If the network load to the Office is taking up all the available internet bandwidth or the connection is just too slow then install proxy servers on the local server. You can also consider using a distributed filesystem ( OpenAFS is still the best ) with access to the local users via a SAMBA share.
9) If phone charges are eating into the budget, and the internet connection is good enough, then install Asterisk on the local server ( upgrade the server to a Celeron 800Mhz or better ) and PCI cards with enough FXS ports for each local user. Don't bother with software based phones/headsets. The phone will work when the desktop does not.
10) Set up a Linux server at the Office that operates as a thin client application server. Allow remote access though both FreeNX and VNC. Create login accounts and logins that operate as virtual meeting rooms, with multiple users logging in via VNC. Use VNCserver with a screen size of around 1000x600, that will operate via a VNC viewer on any 1024x768 desktop. Use phone based conference calling for voice -- it's a lot less hassle for the users
11) Add the usual list of cross platform applications: Firefox, Thunderbird, Gaim, and even OpenOffice etc.
The return on investment from the reduction in desktop downtime will quickly outweigh any initial outlay for any new hard drives and possibly FXS cards.
Sunday, October 09, 2005
Our Data:an appeal - a "Plimsoll line" for apps
From June 14 2002However relatively bad the security of Microsoft's products are in comparison to what the free licensed and open source communities ( as well as practically every other vendor on the planet ) provide, Microsoft is not alone in the presence of vulnerabilities, this is a major issue for Linux/BSD and Unix as well as ever other OS and vendor.
From the Plimsoll Club history
Samuel Plimsoll brought about one of the greatest shipping revolutions ever known by shocking the British nation into making reforms which have saved the lives of countless seamen. By the mid-1800's, the overloading of English ships had become a national problem. Plimsoll took up as a crusade the plan of James Hall to require that vessels bear a load line marking indicating when they were overloaded, hence ensuring the safety of crew and cargo. His violent speeches aroused the House of Commons; his book, Our Seamen, shocked the people at large into clamorous indignation. His book also earned him the hatred of many ship owners who set in train a series of legal battles against Plimsoll. Through this adversity and personal loss, Plimsoll clung doggedly to his facts. He fought to the point of utter exhaustion until finally, in 1876, Parliament was forced to pass the Unseaworthy Ships Bill into law, requiring that vessels bear the load line freeboard marking. It was soon known as the "Plimsoll Mark" and was eventually adopted by all maritime nations of the world.
The risks,issues and solutions for providing a more secure operating and application enviroment have been known for decades.
Those who do not already comprehend the issues and are willing to learn, should take some time out to listen to some of the speeches at Dr. Dobbs Journal's Technetcast security archives, starting with Meeting Future Security Challenges by Dr. Blaine Burnham, Director, Georgia Tech Information Security Center (GTISC) and previously with the National Security Agency (NSA)
The design and implementation of some applications and servers are just too unsafe to use in the "open ocean" of the internet.
Numerous security experts have railed against Microsoft's lack of security, best summed up by Bruce Schneier Founder and CTO Counterpane Internet Security, Inc who rightly said:
Honestly, security experts don't pick on Microsoft because we have some fundamental dislike for the company. Indeed, Microsoft's poor products are one of the reasons we're in business. We pick on them because they've done more to harm Internet security than anyone else, because they repeatedly lie to the public about their products' security, and because they do everything they can to convince people that the problems lie anywhere but inside Microsoft. Microsoft treats security vulnerabilities as public relations problems. Until that changes, expect more of this kind of nonsense from Microsoft and its products. (Note to Gartner: The vulnerabilities will come, a couple of them a week, for years and years...until people stop looking for them. Waiting six months isn't going to make this OS safer.)
However Microsoft's products are not alone in the presence of vulnerabilities, this is a major issue for Linux/BSD and Unix as well as any other OS and vendor.
In a recent speech "Fixing Network Security by Hacking the Business Climate", also now on Technetcast, Bruce Schneier claimed that for change to occur the software industry must become libel for damages from "unsecure" software. However, historically this has not always been the case, since most businesses can insure against damages and pass the cost along to the consumer.
The Ford Pinto and more recently the Ford Explorer's tires are two examples of public and media pressure being more successful than just threat of lawsuits. Even so, just as with the automotive industry, eventually though public pressure the governments around the world have to step in and pass regulations that set up a minimum set of requirements an automobile has to meet to be deemed "road worthy". This includes crash testing as well as the inclusion of safety equipment on all models. The requirement are not constant and change to meet the expectations and demands of the public and lawmakers.
The onus is not only on the automotive industry itself but also on the users. Most countries require that all automobiles undergo regular inspection and maintain an up to date "Warrant of Fitness".
In the same way, if you want a secure IT infrastructure, eventually the software design, implementation and each deployment will have to undergo the same type of regulation and scrutiny.
Unix,Linux,BSD and especially OpenBSD are currently far superior in terms of security, both in closing the vulnerabilities in applications before they have the chance to be widely exploited and implementing more secure access subsystems ( SELinux/LSM etc ).
However, should the Unix, open source and free licensed
communities and vendors be taking a more active approach,
including lobbying government, to
1) set up a minimum set of expectations, in the design and
implementation of internet "accessing" software ; and
2) ensure that all deployments are more securely implemented ;
and/or
3) remove inherently unsecure products from the marketplace,
IMO the above three are preferable to all software vendors, including Microsoft, than attempts to allow liability lawsuits against vendors for deployments which the vendors do not necessarily have any control over.
Thursday, September 29, 2005
The above linked article about a failed deployment of SAP on Linux raises questions about Linux installation, configuration, updating and problem diagnosis. However, at least at the operating system level, Crest's IT manager Anthony Horton's statements don't quite ring true.
About OS Installation : SAP's documentation sets down guidelines for partitioning and the Red Hat package RPMs required. The contractor should have had set the system up for an installation of SAP and if requested, provided a kickstart script that would automate a pre-configured reinstall. The actual installation of the SAP provided RPMs is a breeze, (see for yourself). In comparison with Win2k and Win2k4 server, a Linux install can be a lot easier.
About OS Configuration : Red Hat Enterprise as well as Suse distros provide both CUI (ncurses) and fully GUI ( X11 ) interfaces for configuration and management. Both methods are remotely access able using SSH ( with port forwarding for X11 ). It is better to consult the manuals on how to use the provided interfaces, before diving in and manually editing config files in /etc directory. More often than not, updating problems are caused by administrators short cutting the distribution's configuration scripts -- work with the system not against it.
About OS Updating : For both Red Hat and Suse, SAP only certifies the kernels packages and glibc libraries. Aside from glibc, SAP links all their binaries to SAP provided libraries. It is easy enough to set Red Hat Network update to ignore the kernel*, glibc* and nscd for automatic updates. Automatic updates would then not affect the SAP deployment. Any updated packages dependent upon updated kernels or glibc packages would be installed automatically once the kernel or glibc packaged were manually upgraded.
About OS Problem Diagnosis : In comparison with Win2000 and Win2003 server, Linux is by far the easiest to provide remote support and diagnosis. Any credible contractor should have been able diagnose and fix any software problem via remote SSH ( or for servers behind firewalls a Reverse SSH tunnel ) connection. For Linux servers, the most likely issue that would cause a "core dump" is almost always related to either hardware based RAID drivers or just failing RAM modules. I have found that for Red Hat 3 and 2.4.X Linux kernels, software based RAID with SCSI is a lot more stable. For Red Hat 4 and later 2.6.X Linux kernels most Adaptec and Promise based hardware RAID is more than stable enough.
"We asked the customer to do a diagnostic test and the customer never responded, so it was impossible for us to address the issue,". The "failure" of Linux at Crest Electronics is probably due more to internal politics or incompetence rather than the choice of OS platform. That Anthony Horton, who inheriting the decision [to use Linux] when he took the job, chose not to respond to Red Hat's request, suggests that he was not all that enthusiastic to get SAP working on Linux. The Red Hat-recommended contractors, if actually consulted, should at least have been able to diagnose the hardware and system crashes post mortem, if only by turning on kernel debugging and passing the log information along to Red Hat and IBM.
If Mr Horton took over the deployment and management of SAP on Linux servers, then he probably approached managing Linux with the experience, skills and methods he acquired when administrating SAP on AIX. Although most of the skills can be translated to Linux, AIX is not Linux ( in fact there a few older Unix stalwart I know of who claim that AIX is barely UNIX ). Mr Horton probably got frustrated and started mucking around in the /etc directory with the result of screwing up the deployment on Linux, but it would have taken only a couple of rounds emails to SAP's and Red Hat's email forums to fix the problem.
Once installed, SAP provides a very similar interface to manage itself on Linux, Unix and Windows with IBM's or SAP's own Database. SAP's offerings are difficult to correctly deploy within an Enterprise, whatever the OS platform. I could believe that it could take a couple of days longer to deploy a solution on Linux rather than Windows, but not "The installation of SAP took two days on Windows, the installation on Linux Red Hat took two weeks". How much of the enterprise dependent configuration of the SAP environment were just copied over from the Red Hat to the Windows hosted deployment? Without that question being answered it looks more like a case of Pro-Microsoft FUD.
In Microsoft's sponsored studies and commissioned papers, Linux Vs Windows Total Cost of Ownership calculation rarely if ever take into account the amount of downtime suffered by the respective platforms once deployed. In terms of stability, Linux and open source has a far better record of reliability. In my experience, any extra effort employed to deploy a solution on Linux is almost always rewarded by long term solid solution that suffers a lot less downtime than a similar Windows hosted solution.
Update: Deploying Linux for ERP works better for others
