This poster is beginning to break the problem down into parts that need to be handled separately.
For the runtime part of Java, maybe what is needed is a license scheme that can parent copies of code licensed as both GNU and BSD.
How about another level of licensing abstraction?
Lets explore dual licensing for Java's runtime: the Java runtime and runtime modules ought to be dual licensed. A BSD style license is for Sun to create a family "run anywhere" runtime products for many operating systems. The same starting source code (with proprietary API calls replaced) should be released under the GNU license.
The point to a dual license is to preserve an intellectual space for Sun to market a product and to also allow development and extension in the GNU style.
The problem with a pure BSD license is it causes a dead end proprietary product like Mac OSX. I mean dead end in the sense that BSD code doesn't migrate back to Linux or X11.
Another example of how the BSD license stagnates a product is PostGresql. Open as it is, system extensions and interfaces and complete implementations appear as prototypes, and the refined products appear only as proprietary products for sale.
Yet another BSD license problem is appropriation and extension by Microsoft. BSD blocks others from seeing the source.
The reason for keeping a BSD license is it does enable the existence of proprietary product that potentially can be certifiable and secure.
For the sake of creating a proprietary, supported product, actually included with OEM browsers and operating systems, and for something that can be downloaded and upgraded fast, license a primary Sun brand name runtime with the Berkeley Style.If Sun has access to Microsoft proprietary APIs, then let this instance of the runtime be made with those proprietary system calls.
The Microsoft Windows and Microsoft Internet Explorer environments and business computing users need a Java product that can be sold with a guarantee or warranty or certification status. It seems to me that a BSD license is better for parts of a Java runtime product.
But we need a simulotaneous license for the runtime as GNU open source. GNU licenses lead to fabulous juggernauts like the Linux kernel and the Gnu utilities.
Dual licensing does lead to a problem: the dreaded code fork. And in particular, there is no way for developments accomplished on the GNU side to be rolled into the BSD or proprietary licensed side. Dual licensing suggests that the two code bases would drift apart.
The problem is to keep one GNU code base for the runtimes AND dual license the Java runtime AND not give the source to Microsoft under a BSD license.
Suppose Sun creates two code bases, one GNU and one BSD (for it's own use). "what happens in the future as open source develops one way and the proprietary BSD runtime develops another way?" Well it is a disaster.
Lets engage with that conflict: Create a parent structure that can supply both License code bases with the same source.
As a possible example, could the GNU license applied to the initial Sun codebase be modified with a time limited grant to Sun (say 5 years) to use a specific developed block of open source code under the BSD license?
This could lead to parallel Java runtimes: A Sun product that they sell and warranty, complete with versions for business computing uses. A similar pure GNU runtime that passes the same suite of tests with source code GNU licensed (with proprietary API calls removed and proprietary licensing stuff commented out).
I am migrating from Red Hat (7 years) to Debian (20 days) and I understand Eric Raymond's pain at figuring out CUPS.
My experience is that solving configuration problems is easy for programs with a complete but brief man page.
A good man page gives you the syntax, names of configuration files and pointers to associated program man pages.
I have been trying to think of solutions to the general documentation and configuration problem with Linux in these two ways:
A: Make a configuration framework that is customized by a local search and indexing engine: Use a startup framework like the RUTE user guide and annotate the text with local machine links created by a little indexing engine.User guides could be written around different perspectives (like Red Hat or Debian), and in different languages. The indexing engine would populate the guide based on what software was installed on the specific local machine.
B: A simpler approach is to come up with a way to write "shadow" man pages, independently contributed alternate man pages that correct and extend what the original authors created to accompany their original program.
Claim modest cost savings.
Open source software can do powerful useful stuff the proprietary desktops can't. You will still need people to plug in kicked out power cords and change toner cartridges.
Just making a laundry list of the interesting things your business can do makes me dizzy! Just itemize every open source technology frontier and you will see business value opportunities:
GnuPGP - digital signatures and authentication.
Morphix - business custom bootable systems.
Cluster computing - You have 250,000 CPU hours per day.
Email and mailing lists - most underappreciated business tool.
Leave the MS desktops intact and add a new disk and RAM for Linux use.
Note your firm's potential in asynchronous desktop computer supercomputing. With 60K computers idle at night you can do a lot of financial modeling.One of the major mantras of cluster computing is doing more computing with less manpower.You have so many CPUs available, your cluster computing project may show electricity cost itself exceeding the cost of manpower administering the cluster.
Morphix is a great way to demonstrate a Linux desktop (and a great way for you to distribute a business customized Linux application selection).Note Morphix is a recursive way to propogate new and different computer systems.
So from the money you save not moving to the next round of proprietary PC software consider this:
Out of the $400 not spent, up grade to 1Gig Ram and a 200Gig 2nd disk drive and a $.50 cd copy of your companies chosen MD5checksum applications.
On the management side, the kind of work that hundreds of support and admin people do will change. The management task is to figure out how to organize the work so that the tasks are doable, done and delivered.
You will need a web site WIKI and a set of email groups for organizing and delegating open source involvement throughout the company.You want some involvement and knowledge about several projects.
On the licensing thing... tell em your company is not a programming house, you are an application user. Open source contribution and participation is the appropriate path. Open source programs forked into a proprietary version breeds dead ends and support costs. Business data is proprietary. Configurations and configuration files are a boundary item with a 90 day half-life.
Recycling is ethically right.
The problem with making recycling work is raw materials like virgin plastic cheap.
Lets assume some kinds of raw plastic made from petroleum probably cost about the same per pound as gasoline sold at retail. A $1.99 gallon of gasoline weighs about 6.96 lb. So the plastic feed stock used to make a 2.5 ounce milk carton costs $.04. Just use your calculator.
If it costs only 4 cents to make a pure sterile milk carton from virgin non-recycled plastic there is no narrow economic basis to sustain a recycling program.
I recommend the GnuCash people raise themselves some money using the donation scheme worked out by affero.net. Affero receives credit card donations and charges a 6% handling fee.
There are surely several paid careers just waiting to be staffed by businesses that need competent support and feature implementation of the GnuCash system.
GnuCash installs perfectly under Red Hat, and I sympathize with the reports of dependency hell. I suffer the same hell trying to get back my Lyx and SciPy system.
Inelegant as it may sound, I suggest the GnuCash people package up an all dependencies resolved static package. There are too many reports of agony on this comment board to ignore. Like Lyx, the package is struggling from several angles, one problem is the disappointed victims of dependency hell.
I have explored going back to Jr. College to get an accounting certificate so I would have educational credentials to accompany a modest retirement career setting up GnuCash systems for small businesses.
Slashdot Mirror
This poster is beginning to break the problem down into parts that need to be handled separately.
For the runtime part of Java, maybe what is needed is a license scheme that can parent copies of code licensed as both GNU and BSD.
How about another level of licensing abstraction?
Lets explore dual licensing for Java's runtime: the Java runtime and runtime modules ought to be dual licensed. A BSD style license is for Sun to create a family "run anywhere" runtime products for many operating systems. The same starting source code (with proprietary API calls replaced) should be released under the GNU license.
The point to a dual license is to preserve an intellectual space for Sun to market a product and to also allow development and extension in the GNU style.
The problem with a pure BSD license is it causes a dead end proprietary product like Mac OSX. I mean dead end in the sense that BSD code doesn't migrate back to Linux or X11.
Another example of how the BSD license stagnates a product is PostGresql. Open as it is, system extensions and interfaces and complete implementations appear as prototypes, and the refined products appear only as proprietary products for sale.
Yet another BSD license problem is appropriation and extension by Microsoft. BSD blocks others from seeing the source.
The reason for keeping a BSD license is it does enable the existence of proprietary product that potentially can be certifiable and secure.
For the sake of creating a proprietary, supported product, actually included with OEM browsers and operating systems, and for something that can be downloaded and upgraded fast, license a primary Sun brand name runtime with the Berkeley Style.If Sun has access to Microsoft proprietary APIs, then let this instance of the runtime be made with those proprietary system calls.
The Microsoft Windows and Microsoft Internet Explorer environments and business computing users need a Java product that can be sold with a guarantee or warranty or certification status. It seems to me that a BSD license is better for parts of a Java runtime product.
But we need a simulotaneous license for the runtime as GNU open source. GNU licenses lead to fabulous juggernauts like the Linux kernel and the Gnu utilities.
Dual licensing does lead to a problem: the dreaded code fork. And in particular, there is no way for developments accomplished on the GNU side to be rolled into the BSD or proprietary licensed side.
Dual licensing suggests that the two code bases would drift apart.
The problem is to keep one GNU code base for the runtimes AND dual license the Java runtime AND not give the source to Microsoft under a BSD license.
Suppose Sun creates two code bases, one GNU and one BSD (for it's own use). "what happens in the future as open source develops one way and the proprietary BSD runtime develops another way?" Well it is a disaster.
Lets engage with that conflict: Create a parent structure that can supply both License code bases with the same source.
As a possible example, could the GNU license applied to the initial Sun codebase be modified with a time limited grant to Sun (say 5 years) to use a specific developed block of open source code under the BSD license?
This could lead to parallel Java runtimes: A Sun product that they sell and warranty, complete with versions for business computing uses. A similar pure GNU runtime that passes the same suite of tests with source code GNU licensed (with proprietary API calls removed and proprietary licensing stuff commented out).
I am migrating from Red Hat (7 years) to Debian (20 days) and I understand Eric Raymond's pain at figuring out CUPS.
My experience is that solving configuration problems is easy for programs with a complete but brief man page.
A good man page gives you the syntax, names of configuration files and pointers to associated program man pages.
I have been trying to think of solutions to the general documentation and configuration problem with Linux in these two ways:
A: Make a configuration framework that is customized by a local search and indexing engine: Use a startup framework like the RUTE user guide and annotate the text with local machine links created by a little indexing engine.User guides could be written around different perspectives (like Red Hat or Debian), and in different languages. The indexing engine would populate the guide based on what software was installed on the specific local machine.
B: A simpler approach is to come up with a way to write "shadow" man pages, independently contributed alternate man pages that correct and extend what the original authors created to accompany their original program.
Claim modest cost savings. Open source software can do powerful useful stuff the proprietary desktops can't. You will still need people to plug in kicked out power cords and change toner cartridges. Just making a laundry list of the interesting things your business can do makes me dizzy! Just itemize every open source technology frontier and you will see business value opportunities: GnuPGP - digital signatures and authentication. Morphix - business custom bootable systems. Cluster computing - You have 250,000 CPU hours per day. Email and mailing lists - most underappreciated business tool. Leave the MS desktops intact and add a new disk and RAM for Linux use. Note your firm's potential in asynchronous desktop computer supercomputing. With 60K computers idle at night you can do a lot of financial modeling.One of the major mantras of cluster computing is doing more computing with less manpower.You have so many CPUs available, your cluster computing project may show electricity cost itself exceeding the cost of manpower administering the cluster. Morphix is a great way to demonstrate a Linux desktop (and a great way for you to distribute a business customized Linux application selection).Note Morphix is a recursive way to propogate new and different computer systems. So from the money you save not moving to the next round of proprietary PC software consider this: Out of the $400 not spent, up grade to 1Gig Ram and a 200Gig 2nd disk drive and a $.50 cd copy of your companies chosen MD5checksum applications. On the management side, the kind of work that hundreds of support and admin people do will change. The management task is to figure out how to organize the work so that the tasks are doable, done and delivered. You will need a web site WIKI and a set of email groups for organizing and delegating open source involvement throughout the company.You want some involvement and knowledge about several projects. On the licensing thing... tell em your company is not a programming house, you are an application user. Open source contribution and participation is the appropriate path. Open source programs forked into a proprietary version breeds dead ends and support costs. Business data is proprietary. Configurations and configuration files are a boundary item with a 90 day half-life.
Recycling is ethically right. The problem with making recycling work is raw materials like virgin plastic cheap. Lets assume some kinds of raw plastic made from petroleum probably cost about the same per pound as gasoline sold at retail. A $1.99 gallon of gasoline weighs about 6.96 lb. So the plastic feed stock used to make a 2.5 ounce milk carton costs $.04. Just use your calculator. If it costs only 4 cents to make a pure sterile milk carton from virgin non-recycled plastic there is no narrow economic basis to sustain a recycling program.
I recommend the GnuCash people raise themselves some money using the donation scheme worked out by affero.net. Affero receives credit card donations and charges a 6% handling fee.
There are surely several paid careers just waiting to be staffed by businesses that need competent support and feature implementation of the GnuCash system.
GnuCash installs perfectly under Red Hat, and I sympathize with the reports of dependency hell. I suffer the same hell trying to get back my Lyx and SciPy system.
Inelegant as it may sound, I suggest the GnuCash people package up an all dependencies resolved static package. There are too many reports of agony on this comment board to ignore. Like Lyx, the package is struggling from several angles, one problem is the disappointed victims of dependency hell.
I have explored going back to Jr. College to get an accounting certificate so I would have educational credentials to accompany a modest retirement career setting up GnuCash systems for small businesses.