The solution to this would be update or make a FOSS version of Java that implements Java 5.
That is one possible solution, but this is a difficult task -- much more so than making OpenOffice work with the features GCJ offers today. One day GCJ will have full Java 5 support, but until then the Java Trap is quite real. People who don't want to use proprietary software can't use all the features of OpenOffice. This is a practical problem right now and it's one the OpenOffice developers can quickly and easily solve if they want to. Fortunately it looks like they want to.
Also The Harmony project (if it is successful) would seem to lay to rest any FOSS advocate's qualms about Java.
Indeed, but so far the Harmony project has shipped nothing. When the Harmony project ships a free software JRE compatible with the Java 5 standard there will be no principled objection to Java from free software advocates. Until then these qualms are real and reasonable.
Huh? A version of OpenOffice that will not compile and run with properly with GCJ is completely useless to someone who wants to avoid proprietary software like the Sun JRE. This is also the case for people who want to run NetBSD or Linux PPC where the Sun JRE is not available. You may not be one of these people but pretending that their concerns are unimportant is impolite -- much more so than any "threat" of forking.
Unless the OpenOffice developers are prepared to cooperate with this portion of the community (and fortunately it seems they are) forking is the only alternative to abandoning OpenOffice entirely and recommending alternative projects. Blaming the negative consequences from such a move to the OpenOffice project on people who are just trying to get work done without compromising their principles or buying new hardware is boneheaded.
Yeah, yeah, we get it. You're a fearless nonconformist, just like everyone else around here. You say we have to live with the consequences of the patent system as it is? What an amazing insight! Nobody else realized that! You're a hero!
Suppose for the sake of argument that there is no answer, that there is no reason time should be spent productively. That would make my assertion that time should be spent productively... well, unproductive. But there would be no reason for you to point this out to me. That would be unproductive too. Why bother? All possible behaviors would be equally pointless. In the best case, the entire universe would vanish in a puff of casuistry.
smokin a 'lil ganja never hurt no one, in fact it, and many of the other great art works of the world were developed under the use of some sort of 'illicit narcotic'.
I don't dispute the notion that some recreational drugs have mild side effects or even that it's possible for some to have positive effects under some circumstances. On the other hand while I hear this rationalization frequently I'm not ready to accept the implied suggestion that such drugs help artists to create better work. That a particular piece of art was created under the influence of drugs doesn't prove that it wouldn't have been even better if produced by someone with a clear head. Obviously I haven't proven that it wouldn't have been worse with this line of reasoning either, but it's an open question.
Don't get me wrong, I'm not going to get in the way of your habits if you're not directly hurting anyone. Whether or not you're hurting yourself is interesting to debate, but it's your prerogative.
Marijuana has helped me come up with solutions to programming problems too many times to count.
So you say. I would guess that you are biased and misattributing the cause of your productivity, but of course that's just a guess. I'll believe you when I see controlled experiments conducted by credible authorities. Had you provided a link I would have followed with an open mind, but since you can't be bothered I can't be bothered to google for it either.
I'd actually like to hear a good [...] logical discourse to support my position against marijuana use.
I am also against recreational drug use. (And for the benefit of whiny and defensive defenders of recreational drugs, yes I include alchohol and tobacco in that category.) I don't have any religious objections. While some of these do gruesome things to the body or impair vital motor skills, others don't. Such things are not the most important concern to me. I would even be against a hypothetical perfect recreational drug that had no directly harmful side effects of any kind. Nothing would happen to the people who used such a drug.
And that's the problem.
Recreational drug use can be an effective substitute for other forms of recreation that are actually productive: playing outside, reading, programming and so on. Life is too short for meaningless, drug induced stupor.
In principle, yes. In practice, no. As an example, consider the task of concatenating two strings. In C this would require malloc() most of the time, so a call to free() would be needed somewhere and could be forgotten. In C++ this requires new and delete which are equivalent, but the STL string class handles that automatically, so there's nothing to forget.
Concentrating on using safer, more productive languages and making code easier to understand is the direction we should all be aiming for.
Safer and more productive? You must be advocating C++ over Java. Well written C++ code uses the standard template library. Pointers and manual memory allocation are used rarely if at all, so there is no practical risk of memory leaks or buffer overflow. Constructors and destructors can be used for resource allocation so even things like file handles and database transactions are managed automatically. That's safety Java can't match.
Meanwhile what Java means by safety is a startling lack of powerful features. Tasks that are easy to handle with a few lines of C++ require mind numbing verbosity in Java. This makes Java more "productive" only if one measures raw lines of code rather than accomplished objectives.
Linux is horrid to install and reconfigure compared to Windows (any version after Windows 2.x)
Get a cheap machine and a set of installation CDs for both Windows XP and Fedora Core 3 (you can replace this with the most recent version of Mandrake, Ubuntu or Xandros if you prefer). Install each and set it up for desktop use by a non-technical user. Actual experience will change your mind.
You are *already* a convert. For Linux to increase market share on the desktop, only the opinions of those not using Linux matter.
Read what I was replying to and what I wrote more carefully. I didn't say my opinion on the subject was particularly important by itself. I mentioned it only to show that technical users can disagree on what is easier for administrative work. The issue is subjective. Of course, the issue is also irrelevant to the question of broader adoption because non-technical users don't do administrative work. They get non-technical users to do it for them for the same reason they hire a mechanic to repair their cars.
Perhaps you should listen to them (and maybe even learn something) rather than try to tell them why you think they are wrong and why you think you have bigger Linux testicles than they do.
I have been listening. What I'm hearing are vague and subjective generalizations such as "installation is much harder" and "administrative tasks are much harder" without supporting facts. I have installed and configured both GNU/Linux and Windows XP for a variety of mundane and technical tasks. In my experience the former is much easier to work with in every way. Maybe your experience is different, but if so you'll have to get specific if you actually want to teach me something.
Meanwhile, you should pay more attention to what's going on around you. Desktop use of GNU/Linux systems is real and growing. Maybe if you took a break from pondering testicles and actually tried out a recent release you would find out why.
The trouble is, thats after someone has set the machine up for them.
Have you never had the experience of setting up an Windows XP system for someone? I have, and it's at least as difficult as setting up a GNU/Linux system.
There is a lot more to using a PC than just surfing the net on a default install.
Maybe for you and me. Not so much for non-technical users who just want to check email and shop online.
Some admin work is inevitable(sp) and its a hell of a lot easier under Windows than Linux to do stuff like add hardware, install new programs, change ISP settings etc.
You're welcome to your opinion, but opinion is all that statement amounts to. Perhaps you just have more experience with Windows than Unix. I find all of those things *much* easier to do on a Fedora Core 3 box than on any flavor of Windows.
Apparently a fact or two in support of your claim that Linux is pulled in 100 directions at once or that there are 10,000 ways to close a window is too much to ask -- nevermind evidence that these things have caused actual harm. What you're saying amounts to this: ignorance is truth, strength is weakness and so on. Good luck getting that message across. Should you ever decide to rejoin the real world however, you'll want to be aware of a few simple facts.
First, distribtions based on Linux already have a stronger presence than Solaris on the desktop. Maybe that's because there is no schizophrenic marketing department to do the hokey pokey on support for popular commodity hardware. One of the most successful promoters of Linux on the desktop is... well, Sun Microsystems. That is what the current "Java" Desktop system is built on, you know. A company that changes its strategy every other Thursday for no apparent reason doesn't inspire confidence.
As for picking a path and sticking to it, that isn't exactly something the Solaris developers are famous for on the desktop. They started with OpenWindows, moved to CDE and are now moving to Gnome. That's right, they are abandoning their desktop environment in favor of one that grew up on Linux based systems. Meanwhile companies like Novell are offering streamlined distributions based on Linux with sensible defaults for window managers, word processors and everything else.
Finally, while the Mozilla project was able to successfully build a free software product from a formerly proprietary code base, they had no credible competition for capable developers in that space. They also settled managed to settle on a license -- something Sun has yet to do. Maybe someday Solaris will catch up and offer meaningful competition. Maybe. Most of the world will wait to see if a free software Solaris can actually tread water on the desktop before declaring it the fastest swimmer in the pool. But don't let such simple and obvious facts distract you from daydreams in fantasy upside-down land where versatility is a weakness and offering people choices is a disadvantage.
I've been using Java for five years and forcing checks on exceptions is my number 1 most favorite feature of Java.
All that proves is that you have bad taste. I expressed clear reasons why checked exceptions are a bad idea and all you can come back with is, "yeah, well I like them"? Whatever.
I currently monitor sixty developers, fyi.
I'm glad I'm not one of them. You don't seem terribly bright.
So you shouldn't have checked exceptions because people might be dumb? [...] I could use the "people are dumb" argument to say that you should have checked exceptions as well.
No, one shouldn't have them because they complicate programming and provide no useful benefit in exchange. Someone *did* use the "people are dumb" argument to say checked exceptions are good. I was answering the claim that one could rely on throws clauses to document the exceptions a method might raise by pointing out that in practice those dumb people are too clever. Checked exceptions don't solve the problem. In context your reply is irrelevant.
Uh-huh. I haven't seen one that does this automatically for C#, it relies on the programmer to list them. Microsoft's own libraries have some documented exceptions that can be thrown but not all of them.
So? I made no claims about C# or any language other than Java. I said that the right way to ensure that exceptions get documented is to use an automated tool to collect that information without burdening programmers with busywork. Your comment does not address that.
Use a rapid prototyping language if that's what you want.
Rapid prototyping is important in any language. Sun agrees: see http://java.sun.com/docs/white/langenv/Intro.doc2. html for example. Nevertheless, I was not claiming that this is the only criteria by which a language should be judged. I was giving an example of one ways in which checked exceptions cause problems. Strict typechecking has disadvantages, but unlike checked exceptions it has advantages too.
if the new implementation you dropped in throws some random exception that I don't catch because I didn't know you could throw it,
Client code can use "catch (Exception e)" and have some default behavior for dealing with unanticipated exception types. This is the correct thing to do, because it gives library implementations maximum flexibility while still permitting exceptions to be caught and handled specially where necessary. Many times the interface implementation is effectively a callback mechanism for the client code, so they belong to the same codebase and there is no question about what exceptions can be thrown.
Nothing you've said can obscure the fact that checked exceptions offer no benefits but do impose substantial costs.
Relying on documentation to tell API users what exceptions can be thrown is a really terrible idea if you're trying to write server software that has to actually work. And work all the time, 24/7, not just in a demo.
First of all, checked exceptions are not the only, not the best and not even a particularly good way to get documentation about what exceptions might be thrown. Programmers can and often do declare "throws Exception" which completely defeats the purpose. An automated documentation tool like javadoc can and should enumerate the possible exceptions each method might throw.
Second, checked exceptions are an unacceptable burden on programmers for several reasons. They are a tedious obstacle to rapid prototyping, where a programmer cannot really know what exceptions are likely to be thrown and shouldn't be asked to enumerate them. You won't get a chance to write a server application that has to work 24/7 if you can't create an effective demo in time. Even when creating production code there is no reason to soak up programmer resources fighting pointless compiler errors. Some code simply should ignore exceptions, but checked exceptions don't allow that.
A good example of code that should ignore exceptions is interfaces. Checked exceptions make it impossible to correctly declare interfaces because there is no way a programmer can forsee every possible checked exception anyone might ever want to throw in an implementation class. Were all of this not true, why would Sun have officially enshrined swallowed exceptions in the JDK libraries with the "cause" method?
No other mainstream programming language has checked exceptions, and even languages that exist primarly to duplicate the good features of Java aren't adopting them. Why? Because they are a bad idea. It's that simple.
Only Microsoft could steal a language and do away with enforced Checked Exceptions (making try blocks optional) because it was "too confusing" to bother to check for errors.
Nonsense. Checked exceptions are bug not a feature. An exception is useful because it allows a programmer to handle an error or unusual condition in the place on the stack that makes the most sense. Checked exceptions force intermediate code that has no sensible way to address the condition to declare a throws clause. That's nothing more than pointless drudgery.
Worse, the entire concept breaks down when interfaces are involved. An interface can't predict what kinds of exceptions its implementations might want to throw, so there is no correct way to define them. Checked exceptions do more harm than good and should be removed from Java. I'm not a.NET user but I'm glad Microsoft had the good sense to leave them out.
However, I can tell you that every company I have worked for
forbade GPL, but have encouraged me to contribute to multiple projects
using Apache, BSD and SCSL licensing. Actually, even a few
LGPL.
Anecdotal and irrelevant.
If I go and collect the opinions of all the people on the JCP
(whom all use different licenses) or just Java-using companies in
general, the results would be just the opposite.
Obviously you didn't notice that the original column from which the
author collected his data was posted on ZDNet, which is not exactly a
pillar of the free software community. Even so, I say again that this
was not an election. Evan Leibovitch did not set out to compare how
many people prefered the GPL against how many didn't, nor did I bring
the article to your attention to show that the GPL was winning some
kind of popularity contest. He started by *noticing* that the GPL was
winning the *money* contest and asked why.
Whether you admit it or not, the reality in the market place is
full of evidence that the GPL does not in fact harm the free software
community and in fact is probably helping to bring in companies that
don't contribute to projects with less restrictive licenses. (That is not to say that companies that do contribute to non-GPL licensed free software are not contributing to free software -- they are. Think of it as a two pronged approach.)
For something like the Grep utility, there is no difference if
it is run from a GUI find-button; as I understand it.
Running an application and using as a library are different things and are affected by the GPL differently. Anyone, including Microsoft, can
freely run a GPL licensed application. No, they
cannot simply transform it into a library and incorporate the code for
it into a proprietary software application. That is why we must
distinguish between the use of GPL code as a part of a GPL application
or as part of a library. I want my code to be usable in the first way
but not the second. Maybe you have different goals for your code, and
if so you should not use the GPL to cover it.
Everyone is afraid of Microsoft stealing their code and claiming
it to be their own. I just don't honestly think any license will stop
them, since they seem to break them all the time. Sure, they end up in
never-ending lawsuits, but they still do it.
Microsoft is forced to comply with licenses they have violated
and often to pay significant damages all the time. Nevertheless,
(can you tell what's coming next?) you've missed the point. I don't
want *any* company anywhere to incorporate my code into proprietary
software. Even if the GPL somehow just didn't apply to Microsoft
it would be solving most of the problem for me.
When contributing to the Apache Ant project, they insisted I not
event look at GPL code.
I find that claim suspicious, so perhaps you would care to back it
up with some facts. I notice that the Apache Ant task
guidelines explicitly mention the incompatible nature of the
license they use an the GPL. I see that checking that a task does not
depend on GPL or LGPL code is listed as an important step before
submission. That is all quite sensible. However I see no indication
there that merely reading the GPL licensed source code with a similar
purpose is enough to disqualify submissions. One would think such a
requirement would be well documented to eliminate confusion.
I don't
doubt that you have been given such instructions when working on
propriretary products. That is how the proprietary software industry
looks at these things. Such an attitude would be quite appropriate
regarding most non-disclosure agreements covering proprietary
software, but that doesn't mean this is a sensible policy for GPL
covered code.
Even if I concede all this nonsense for the sake of argument, it
would still fail to prove that the differences between the GPL and
BSD-style licenses
While that may be true on the Linux platform, I do not believe
that to be accurate on either my Windows or BSD box. MOST of the
software on my BSD box is free and NOT GPL.
Over half of all free software available on the most important
internet archives for the stuff is licensed under the GPL. Check the
statistics found here. I
didn't say that half of the software on your FreeBSD or Windows
machines was GPL licensed. More than half the software on your
Windows machine is surely proprietary. I'm sure that the FreeBSD base
system is almost entirely BSD licensed. However, stroll over to the
ports system. There you will find a convenient way to install GCC,
Bash, Emacs, and an endless selection of powerful and useful GPL
applications and libraries.
Does FreeBSD even come with a C compiler that isn't GCC? On my
FreeBSD machine "cc --version" gives me GCC output, but the first
thing I do when I install such a thing is setup a variety of useful
GPL applications, so I very well may have clobbered or overlooked some
anonymous BSD licensed compiler along the way.
Do you disagree? Are you saying it is OK for me to scavenge code
from GPL software to make other non-GPL free software? You make it
seem like GPL is the only 'free' solution.
Are you even paying attention? I did not say it was acceptable for
you to scavenge code from GPL software and place it into proprietary
code. However, merely looking at GPL code will not prevent you from
writing your own oringinal non-derivative but possibly similar code
that does similar things. Read the GPL and tell me where it says that
you can't do this.
Even IBM has their own open source license.
I have said over and over again that the choice of whether to use
the GPL is a strategic one. Have you read the IBM public license?
Here is what the FSF has to say about
it:
The IBM Public License is incompatible with the GPL
because it has various specific requirements that are not in the GPL.
For example, it requires certain patent licenses be given
that the GPL does not require. (We don't think those patent license
requirements are inherently a bad idea, but nonetheless they are
incompatible with the GNU GPL.)
In other words, the GPL is not restrictive enough for IBM in some
cases. Meanwhile IBM contributes to GPL projects including Linux all
the time, so they are clearly not allergic to it.
However, nothing on either of those pages show anything about
the "Spirit of the GPL". However, a quick search of Google OR Slashdot
will show that people quite regularly complain about projectX or
licenseY breaking the Spirit of the GPL.
Good grief. Do you mean to say that the hoards on slashdot and
various web logs are a better arbiter of what is and is not within the
spirit of the GPL than the Free Software Foundation, the organization
that created it, simply becuase the latter doesn't use the exact
phrase "Spirit of the GPL" on the page?
Perhaps this is an issue that would be better resolved directly
with licensing@gnu.org, with whom I will email directly to get
clarification.
Yes, do. I'm sure you'll be back with an out-of-context quote that
you've only half understood and turned upside down to make into some
nefarious thing, but at least you will have had the opportunity to see
learn something.
And can that resulting application be BSD-licensed? NO! It has
to be GPL'd.
And your point is what exactly? What I said was that the GPL gives
you an incentive to make your work free software, and it does that.
However, if the code was Public Domain, then NO ONE would
question that everyone could use it without reinventing the wheel. GPL
does not add this capability -- since Public Domain (BSD, etc) all
have been around with that sa
Why does it appear that so many of the new and most
actively developed open-source projects these days are being done
under the GNU license, rather than the BSD one which proponents say is
more business-friendly?
And this one:
Likewise, IBM, SGI, and other companies don't want to
contribute source code to the community if competitors can use it
against them.
And this one:
And while some big companies such as Microsoft and Apple
use BSD-based code, few of them encourage its use by
others.
I could go on, but before long I'll have quoted most of the
article. Once again, the point is that many companies prefer to
contribute to GPL licensed projects. That makes your claim that this
license is hurting the community because companies are afraid to deal
with it seem rather weak, to say the least.
He also said that most of the developers he talked to were GPL-fans,
which obviously skews the overall results.
Exactly how does it skew the results? This wasn't an election. He
was collecting arguments and attempting to understand why corporate
sponsors seemed to prefer GPL licensed projects. Are you suggesting
that there are BSD license advocates with powerful points to make who
simply didn't bother to communicate them for some reason? Or are you
just seizing a point you barely understand and waving it around as
usual?
I think that is where you and I differ. If I had to choose between
everyone (even MS) using my code or only the Linux users using my code
(because that is where most of the GPL development is), I would choose
widespread usage.
No, I think you have managed to misunderstand yet again. For one thing, you have failed to distinguish between
running code and integrating it into proprietary applications. I have
no objection to Microsoft or anyone else running my code for any
purpose, studying it to learn from it, redistributing copies or
improving the program for the benefit of everyone. What I don't want
is to permit a situation like what happened with Kerberos, where
Microsoft made proprietary changes to create incompatability and
refused to release them. Notice the BSD-style license there. I also
want to prevent organizations that might one day maintain my code from
later deciding to make the code proprietary, as almost happened to the
X Window System twice now. Again there is a BSD-style license
involved. Have you ever heard of something like this happening to a
GPL project? I haven't.
I find the GPL an effective tool against that, and so do many
people around the world. Maybe you don't care if your code becomes the next thing Microsoft mangles in an effort to protect market share. In that case, go ahead and release your code under a BSD
license if you want, or just commit it to the public domain. Any
contribution to the free software community is a good thing, so I'll
not complain. But spare me the nonsense about how the GPL is hurting
the community.
For another thing, your claim that most GPL development is done on
Linux is suspicious. Maybe it's even true, but it is certainly
unenlightening. FreeBSD, NetBSD and OpenBSD all ship GPL licensed
applications in their distribution. I am sure you are using plenty of
GPL applications on your FreeBSD machine without even knowing it. I'm
also sure that many capable engineers from all three projects have
made valuable contributions to GPL projects over the years, just as
people who prefer the GPL have nevertheless been quite willing to
contribute to projects using BSD-style licenses. I know for a fact
that some FreeBSD kernel hackers have contributed to the Linux kernel
and vice versa. The quasi-religious schizm you imagine is mostly
fictional among the people who do the heavy lifting.
Sure, reinventing is a waste of my time and their money,
but wouldn't it be better for the community (and even what they claim
to be encouraging) if I were to make their product better for the
whole community?
You've said this before, and I've already addressed the loss of
your potential input and fixes. Plenty of people much smarter than
you are not troubled by the GPL and are more than happy to contribute
improvements. Obviously the programmers who chose the GPL believe
that losing the few people who think the way you do is more than made
up for by those who will be encouraged by the GPL to make their
applications free software. You are welcome to disagree, but there is
a vast body of widely used GPL software out there that you need to
explain. Why is over half (and that's a conservative estimate) of all
free software covered by the GPL if that license harms the
community?
The developers and companies would be willing to spend their
time and money giving back to the community, but can't because they
can't use GPLd software.
This is complete nonsense. Almost every Fortune 500 company is
using GPL licensed software in one form or another today and many
contribute improvements to the community. For instance, IBM
contributes to the Linux kernel even though they also sell a variety
proprietary operating system kernels. Companies that "can't" use GPL
licensed software in general are simply those who have been misled by
ignorant statements of the sort you are making.
If I am writing a Grep utility, and I download (and thus
possibly browse the source for) a GPLd version, I am breaking the
spirit of the license, even if not the letter of the license, by using
GPL ideas to write non-GPL code. [...] You can correct me if I am
wrong there.
You are wrong there. In the first place, copyright covers
expression and not ideas, the dreamy hopes of proprietary software
companies notwithstanding. Furthermore, one of the four fundamental
kinds of freedom required for free software is to allow people to
study source code and learn from it. You violate neither the letter
nor the spirit of the GPL by downloading code, studying it and using
ideas to inspire your own independent and original work. Go to the FSF philosophy
pages and do some reading before making comments on the spirit of
the license.
What incentive? Even as an independant developer, I don't see
that part of it.
First, if you make your application free software using a GPL
compatible license (such as the BSD license without advertising
clause) you can link with that vast body of GPL licensed code I
mentioned. That means fewer wheels reinvented and more time to focus
on other aspects of the application. Second, if you actually use the
GPL you need not fear that your competitors will take your
application, improve upon it and use your own work against you in the
marketplace without making their changes available in turn.
I accept that this sort of thing is beyond your understanding and I
don't expect to penetrate your closed mind on the matter. Still, if
this incentive is so inscrutable, how do you explain the preponderance
of GPL licensed code out there?
Yes, I agree. However, the "Open Source Community" these days
seems to be more GPL vs. Non-GPL. It should not be that way.
Actually, it is not that way -- except perhaps in the minds of a
few people like yourself. People who like and advocate the GPL
usually don't object to non-GPL licenses. Even the Free Software
Foundation, which is surely the most avid of GPL proponents, does not
suggest using the GPL for all software and considers non-GPL licensed
free software to be perfectly acceptable.
I'm sorry. I am not familiar with BSDi.
BSDi is a company that made a proprietary version of FreeBSD. They
didn't succeed in overshadowing FreeBSD. This fact is often used by
BSD license advocates to demonstrate that
Here is an article that offers further explanation of how the GPL helps the free software community and is even advantageous for corporations in many cases.
No, but the assumption is that [Sun] would have to OpenSource the
core libraries as well as the VM itself.
Certainly. But the assumption that the libraries must be released
under the same license as the virtual machine doesn't follow from
that. Even the Free Software Foundation notes that the GPL is not the
best license for all software. They recommend a BSD-style license
sometimes, as for the Vorbis libraries. More to the point, the FSF
already distributes GNU
Classpath, which implements much of the Java standard library,
under an LGPL-like license.
Anyway, I think we can all agree that retroactively revoking the
freedom to create non-GPL licensed Java libraries and applications
(even if such a thing could be done, which seems improbable to me)
would be quite impolite and not especially clever. People who wish
that Sun would release the virtual machine under the GPL or some other
free software license most likely do not mean anything of that sort.
I certainly don't.
Since many companies have made me rewrite things because the
current implementations were GPL (ie: reinvent the wheel), I claim
this hurts the open source movement.
I would believe you if said this hurt you or the company that paid
you to rewrite things, but I don't see how this hurts the free
software movement (sorry, but I don't particularly care about the open
source movement). Reinventing the wheel is the price one pays for not
cooperating with the community.
Had those library been LGPL, for example, those companies would
have allowed me to use and even improve upon (and return to the
community) those libraries. Since they were GPL, we were not even
allowed to download them.
Why did you put "return to the community" in parenthesis? This is
the *only* germane part of your argument. No amount of harm to you or
your company counts when asking whether the GPL harms the free
software community, of which a company that forbids even *downloading*
anything licensed under the GPL (an idiotic policy, by the way) is
clearly not a part. Also, you are failing to distinguish between GPL
applications and GPL libraries. Anyone willing to return improvements
to the community should have no problem with the former. Do you admit
that what you really despise is the use of the GPL for libraries and
not the license itself?
As far as libraries go, even the FSF notes that whether the GPL or
LGPL is preferable depends on strategic concerns. When there are
competing proprietary libraries they prefer the LGPL for exactly the
reason you mentioned. Only when a library is unique and innovative do
they recommend the GPL. In such cases the loss of your potential
improvements is probably made up for by the incentive this gives to
more sane organizations to make their application free software.
Remember that helping people to create proprietary applications is not
the goal of the free software community.
Even if a court chose to say otherwise, doesn't the whole
concept that EVERYTHING extends Object (even if you don't do it
explicitely) require GPL, by the Spirit of the GPL?
Not really, no. The GPL was created in order to prevent companies
from improving free software and releasing the result under restricive
proprietary licenses instead of giving those improvements back to the
community, essentially tempting users away from free software using
the efforts of free software developers themselves. This is
essentially the situation economists call the Tragedy of the Commons.
Public domain software and software that is licensed under BSD-style
terms is regularly treated this way.
(In practice free software development has turned out to be so
effective that proprietary companies have trouble keeping up. BSDi
isn't as successful as FreeBSD, for example. Still, that isn't the
case for every project and there are other good reasons for using the
GPL in many cases. For example, I don't want soft
What I thought it *might* be doing is something like SkinL&F
[l2fprod.com], which, as I understand it, can read the GTK and KDE
themes themselves, thus emulation should be completely
accurate.
I am skeptical that it is even possible to do what I want with pure
Java for the reasons I already mentioned, but I'll check it out.
A few scripts might get the point across, but every time I have
seen this situation, they stress tested the website to determine how
well it would scale.
One stress tests a prototype to learn how much performance needs to improve, not because it is expected to be fast enough for production use. The point, after all, is to get something work ing quickly to prove that the application as proposed can get the job done. Python CGI scripts are great for this purpose. Clearly
a mod_python application will beat the performance of a CGI Python
version, and I have never said anything to the contrary.
The point is that Python is more flexible than Java because (among
other reasons) it permits this simple and effective techinque.
Servlets and JSPs are demonstrably more complex to create and install.
Python is also every bit as portable and free of pointer problems as
Java. And as for simplicity, try teaching both to a non-technical
user. I could go on, but you've clearly made up your mind that Python
is no good ages ago.
I am not having [the experience of considerable overhead
required to bring up a Java virtual machine] on FreeBSD or
WinXP.
I suspect that is because you don't compare apples to apples by
considering equivalent C programs. No doubt once one is conditioned
to accept the sluggish start-up time of a Java virtual machine
everything seems fine. I use shell scripts for many kinds of task and
find them much snappier than command-line Java programs even though
they often need to launch several processes running C programs.
However, without hard numbers which neither of us have at hand or
are inclined to go generate, this is just so much subjective chatter.
Go ahead and use command-line Java programs if you find that helpful
for getting work done. I'll stick with C programs and shell
scripts, thanks.
The fact is, however, they complain about performance and bugs,
but prefer to stick with one that is no longer being patched instead
of using the one that fixes their issues.
This supposes that later editions of Java simply fix their issues
and introduce no new problems. That simply isn't true. Backward
incompatible changes constantly creep into Java releases. On the
basis of technical intuition, I doubt that the increase in support
calls on this issue will cost more than the extra development time
needed to identify and work around version compatability problems. Of
course, any such problems that escape the testing net will generate
those extra support calls anyway. Apparently the professional bean
counters whose job it is to make such calculations for those vendors
based on hard numbers agree.
In my personal experience, the only problem (other than the
'assert' or 'enum' changes) is that they specifically create a JVM in
JNI code, which breaks because the user has a more up-to-date system
then the distro.
And you think it is acceptable that JNI code can break between
minor VM releases? I don't. Release a new interface and implement
the old one interms of it, if necessary. Anyway there are plenty of
actual classes that change their behavior between releases, so JNI is
not the whole of the problem by any means.
Back to that argument? If Sun were to make the single class
'Object' GPL, it would cut off most of their development
support.
Back? Please consider what I actually wrote: Actually, if Sun
does choose to release a free software virtual machine they will
certainly use the GNU GPL or something like it. Are you really
unable to distinguish between the Object class and a virtual machine?
As far as making Object GPL goes, y
But, since Swing ALREADY has the GTK theme, I have to disagree that writing all the peers is any easier than calling a single line of code to switch themes.
This is misleading for two reasons. First, what Swing has already is NOT what I want. Since it is necessarily written in pure Java, the best it can do is emulate the look and feel of GTK. Perhaps it can do a reasonably good job, but it seems unlikely to be perfectly correct in all cases and even a small visual inconsistency can be distracting. Swing is less likely still to quickly adjust to GTK theme improvements over time. Of course, having a Swing theme that emulates the *default* GTK theme and one that emulates the *current* GTK theme whatever it may be are different things. I very much doubt that Swing does or will ever do the latter. (I notice that gtkswing clearly states that only the default theme is supported. Is that the theme you are referring to?) Remember that new GTK themes are created all the time, just as Swing themes are. How could Swing possibly have support for all of them, and why would the developers even bother trying? Using AWT peers will give complete and correct support for the current -- not just the default -- GTK theme no matter when it was created or where it came from, for no additional effort.
Second, much of the work needed to write such peers has already been done. Perhaps the GCJ team is reusing work done for java-gtk in which case the heavy lifting is already finished. Either way, from my perspective it's just a matter of waiting. Meanwhile my AWT applications, while terrifically ugly, are quite functional and will get better looking with no code changes when the GTK peers appear.
Starting a new process for every incoming request is insane regardless of language. Otherwise, Thread Pools wouldn't exist.
Not so. Starting a new process for every incomming request is perfectly sensible if performance requirements are within a certain range (this depends on the hardware in use and what other applications need to run on the same machine). Clearly a persistent approach such as mod_python or servlets will give better performance, but this is not always needed and is always more complex. That means more time consuming to create and debug. Consider a company that needs a prototype of a web application, for instance. A few simplistic Python scripts can be put together easily and will likely be more than fast enough to get the point across. Doing the same thing with Java is not likely to be a good idea, because the syntax is more complex, because there is a separate compile step (Python compiles to byte-code as it runs) and because performance is sure to be dire.
I think it more likely that the Apache mod is the problem, rather than the Java VM. Pure java apps from the command-line seem to run very fast on both Windows and BSD. It is only from Apache that they seem slow.
I think it is impossible for Apache to be the problem, because it has no idea what language a CGI script is written in and therefore would have to deliberately introduce delays to slow down Java. In my experience the overhead required to bring up a Java virtual machine is considerable, and this makes command-line performance unacceptable for many purposes where Python does fine. This point of view is seconded by engineers at Sun Microsystems in the internal memo I linked to last time.
Personally, I have installed a few different applications that installed their own JRE, and I submitted bug reports to those companies because A) They were installing JDK 1.2 when I already had 1.4.2 on my system; B) They were ILLEGALLY installing the JRE (which gets back to your original point).
Point A is quite deliberate and I expect your bug reports don't get far before being stamped WILL-NOT-FIX. These vendors want a JRE that they can depend on to behave pre
Slashdot Mirror
The solution to this would be update or make a FOSS version of Java that implements Java 5.
That is one possible solution, but this is a difficult task -- much more so than making OpenOffice work with the features GCJ offers today. One day GCJ will have full Java 5 support, but until then the Java Trap is quite real. People who don't want to use proprietary software can't use all the features of OpenOffice. This is a practical problem right now and it's one the OpenOffice developers can quickly and easily solve if they want to. Fortunately it looks like they want to.
Also The Harmony project (if it is successful) would seem to lay to rest any FOSS advocate's qualms about Java.
Indeed, but so far the Harmony project has shipped nothing. When the Harmony project ships a free software JRE compatible with the Java 5 standard there will be no principled objection to Java from free software advocates. Until then these qualms are real and reasonable.
Huh? A version of OpenOffice that will not compile and run with properly with GCJ is completely useless to someone who wants to avoid proprietary software like the Sun JRE. This is also the case for people who want to run NetBSD or Linux PPC where the Sun JRE is not available. You may not be one of these people but pretending that their concerns are unimportant is impolite -- much more so than any "threat" of forking.
Unless the OpenOffice developers are prepared to cooperate with this portion of the community (and fortunately it seems they are) forking is the only alternative to abandoning OpenOffice entirely and recommending alternative projects. Blaming the negative consequences from such a move to the OpenOffice project on people who are just trying to get work done without compromising their principles or buying new hardware is boneheaded.
-2, unpopular concept
Yeah, yeah, we get it. You're a fearless nonconformist, just like everyone else around here. You say we have to live with the consequences of the patent system as it is? What an amazing insight! Nobody else realized that! You're a hero!
Now shut up.
Suppose for the sake of argument that there is no answer, that there is no reason time should be spent productively. That would make my assertion that time should be spent productively... well, unproductive. But there would be no reason for you to point this out to me. That would be unproductive too. Why bother? All possible behaviors would be equally pointless. In the best case, the entire universe would vanish in a puff of casuistry.
We can't have that, so make yourself useful.
smokin a 'lil ganja never hurt no one, in fact it, and many of the other great art works of the world were developed under the use of some sort of 'illicit narcotic'.
I don't dispute the notion that some recreational drugs have mild side effects or even that it's possible for some to have positive effects under some circumstances. On the other hand while I hear this rationalization frequently I'm not ready to accept the implied suggestion that such drugs help artists to create better work. That a particular piece of art was created under the influence of drugs doesn't prove that it wouldn't have been even better if produced by someone with a clear head. Obviously I haven't proven that it wouldn't have been worse with this line of reasoning either, but it's an open question.
Don't get me wrong, I'm not going to get in the way of your habits if you're not directly hurting anyone. Whether or not you're hurting yourself is interesting to debate, but it's your prerogative.
Marijuana has helped me come up with solutions to programming problems too many times to count.
So you say. I would guess that you are biased and misattributing the cause of your productivity, but of course that's just a guess. I'll believe you when I see controlled experiments conducted by credible authorities. Had you provided a link I would have followed with an open mind, but since you can't be bothered I can't be bothered to google for it either.
Y'mean like slashdot?
Exactly. :-)
I don't mean to suggest that recreational drugs are the only way to spend time unproductively, just that they are a particularly effective one.
I'd actually like to hear a good [...] logical discourse to support my position against marijuana use.
I am also against recreational drug use. (And for the benefit of whiny and defensive defenders of recreational drugs, yes I include alchohol and tobacco in that category.) I don't have any religious objections. While some of these do gruesome things to the body or impair vital motor skills, others don't. Such things are not the most important concern to me. I would even be against a hypothetical perfect recreational drug that had no directly harmful side effects of any kind. Nothing would happen to the people who used such a drug.
And that's the problem.
Recreational drug use can be an effective substitute for other forms of recreation that are actually productive: playing outside, reading, programming and so on. Life is too short for meaningless, drug induced stupor.
In principle, yes. In practice, no. As an example, consider the task of concatenating two strings. In C this would require malloc() most of the time, so a call to free() would be needed somewhere and could be forgotten. In C++ this requires new and delete which are equivalent, but the STL string class handles that automatically, so there's nothing to forget.
Concentrating on using safer, more productive languages and making code easier to understand is the direction we should all be aiming for.
Safer and more productive? You must be advocating C++ over Java. Well written C++ code uses the standard template library. Pointers and manual memory allocation are used rarely if at all, so there is no practical risk of memory leaks or buffer overflow. Constructors and destructors can be used for resource allocation so even things like file handles and database transactions are managed automatically. That's safety Java can't match.
Meanwhile what Java means by safety is a startling lack of powerful features. Tasks that are easy to handle with a few lines of C++ require mind numbing verbosity in Java. This makes Java more "productive" only if one measures raw lines of code rather than accomplished objectives.
Linux is horrid to install and reconfigure compared to Windows (any version after Windows 2.x)
Get a cheap machine and a set of installation CDs for both Windows XP and Fedora Core 3 (you can replace this with the most recent version of Mandrake, Ubuntu or Xandros if you prefer). Install each and set it up for desktop use by a non-technical user. Actual experience will change your mind.
You are *already* a convert. For Linux to increase market share on the desktop, only the opinions of those not using Linux matter.
Read what I was replying to and what I wrote more carefully. I didn't say my opinion on the subject was particularly important by itself. I mentioned it only to show that technical users can disagree on what is easier for administrative work. The issue is subjective. Of course, the issue is also irrelevant to the question of broader adoption because non-technical users don't do administrative work. They get non-technical users to do it for them for the same reason they hire a mechanic to repair their cars.
Perhaps you should listen to them (and maybe even learn something) rather than try to tell them why you think they are wrong and why you think you have bigger Linux testicles than they do.
I have been listening. What I'm hearing are vague and subjective generalizations such as "installation is much harder" and "administrative tasks are much harder" without supporting facts. I have installed and configured both GNU/Linux and Windows XP for a variety of mundane and technical tasks. In my experience the former is much easier to work with in every way. Maybe your experience is different, but if so you'll have to get specific if you actually want to teach me something.
Meanwhile, you should pay more attention to what's going on around you. Desktop use of GNU/Linux systems is real and growing. Maybe if you took a break from pondering testicles and actually tried out a recent release you would find out why.
The trouble is, thats after someone has set the machine up for them.
Have you never had the experience of setting up an Windows XP system for someone? I have, and it's at least as difficult as setting up a GNU/Linux system.
There is a lot more to using a PC than just surfing the net on a default install.
Maybe for you and me. Not so much for non-technical users who just want to check email and shop online.
Some admin work is inevitable(sp) and its a hell of a lot easier under Windows than Linux to do stuff like add hardware, install new programs, change ISP settings etc.
You're welcome to your opinion, but opinion is all that statement amounts to. Perhaps you just have more experience with Windows than Unix. I find all of those things *much* easier to do on a Fedora Core 3 box than on any flavor of Windows.
Apparently a fact or two in support of your claim that Linux is pulled in 100 directions at once or that there are 10,000 ways to close a window is too much to ask -- nevermind evidence that these things have caused actual harm. What you're saying amounts to this: ignorance is truth, strength is weakness and so on. Good luck getting that message across. Should you ever decide to rejoin the real world however, you'll want to be aware of a few simple facts.
First, distribtions based on Linux already have a stronger presence than Solaris on the desktop. Maybe that's because there is no schizophrenic marketing department to do the hokey pokey on support for popular commodity hardware. One of the most successful promoters of Linux on the desktop is... well, Sun Microsystems. That is what the current "Java" Desktop system is built on, you know. A company that changes its strategy every other Thursday for no apparent reason doesn't inspire confidence.
As for picking a path and sticking to it, that isn't exactly something the Solaris developers are famous for on the desktop. They started with OpenWindows, moved to CDE and are now moving to Gnome. That's right, they are abandoning their desktop environment in favor of one that grew up on Linux based systems. Meanwhile companies like Novell are offering streamlined distributions based on Linux with sensible defaults for window managers, word processors and everything else.
Finally, while the Mozilla project was able to successfully build a free software product from a formerly proprietary code base, they had no credible competition for capable developers in that space. They also settled managed to settle on a license -- something Sun has yet to do. Maybe someday Solaris will catch up and offer meaningful competition. Maybe. Most of the world will wait to see if a free software Solaris can actually tread water on the desktop before declaring it the fastest swimmer in the pool. But don't let such simple and obvious facts distract you from daydreams in fantasy upside-down land where versatility is a weakness and offering people choices is a disadvantage.
I've been using Java for five years and forcing checks on exceptions is my number 1 most favorite feature of Java.
All that proves is that you have bad taste. I expressed clear reasons why checked exceptions are a bad idea and all you can come back with is, "yeah, well I like them"? Whatever.
I currently monitor sixty developers, fyi.
I'm glad I'm not one of them. You don't seem terribly bright.
So you shouldn't have checked exceptions because people might be dumb? [...] I could use the "people are dumb" argument to say that you should have checked exceptions as well.
No, one shouldn't have them because they complicate programming and provide no useful benefit in exchange. Someone *did* use the "people are dumb" argument to say checked exceptions are good. I was answering the claim that one could rely on throws clauses to document the exceptions a method might raise by pointing out that in practice those dumb people are too clever. Checked exceptions don't solve the problem. In context your reply is irrelevant.
Uh-huh. I haven't seen one that does this automatically for C#, it relies on the programmer to list them. Microsoft's own libraries have some documented exceptions that can be thrown but not all of them.
So? I made no claims about C# or any language other than Java. I said that the right way to ensure that exceptions get documented is to use an automated tool to collect that information without burdening programmers with busywork. Your comment does not address that.
Use a rapid prototyping language if that's what you want.
Rapid prototyping is important in any language. Sun agrees: see http://java.sun.com/docs/white/langenv/Intro.doc2. html for example. Nevertheless, I was not claiming that this is the only criteria by which a language should be judged. I was giving an example of one ways in which checked exceptions cause problems. Strict typechecking has disadvantages, but unlike checked exceptions it has advantages too.
if the new implementation you dropped in throws some random exception that I don't catch because I didn't know you could throw it,
Client code can use "catch (Exception e)" and have some default behavior for dealing with unanticipated exception types. This is the correct thing to do, because it gives library implementations maximum flexibility while still permitting exceptions to be caught and handled specially where necessary. Many times the interface implementation is effectively a callback mechanism for the client code, so they belong to the same codebase and there is no question about what exceptions can be thrown.
Nothing you've said can obscure the fact that checked exceptions offer no benefits but do impose substantial costs.
Relying on documentation to tell API users what exceptions can be thrown is a really terrible idea if you're trying to write server software that has to actually work. And work all the time, 24/7, not just in a demo.
First of all, checked exceptions are not the only, not the best and not even a particularly good way to get documentation about what exceptions might be thrown. Programmers can and often do declare "throws Exception" which completely defeats the purpose. An automated documentation tool like javadoc can and should enumerate the possible exceptions each method might throw.
Second, checked exceptions are an unacceptable burden on programmers for several reasons. They are a tedious obstacle to rapid prototyping, where a programmer cannot really know what exceptions are likely to be thrown and shouldn't be asked to enumerate them. You won't get a chance to write a server application that has to work 24/7 if you can't create an effective demo in time. Even when creating production code there is no reason to soak up programmer resources fighting pointless compiler errors. Some code simply should ignore exceptions, but checked exceptions don't allow that.
A good example of code that should ignore exceptions is interfaces. Checked exceptions make it impossible to correctly declare interfaces because there is no way a programmer can forsee every possible checked exception anyone might ever want to throw in an implementation class. Were all of this not true, why would Sun have officially enshrined swallowed exceptions in the JDK libraries with the "cause" method?
No other mainstream programming language has checked exceptions, and even languages that exist primarly to duplicate the good features of Java aren't adopting them. Why? Because they are a bad idea. It's that simple.
Only Microsoft could steal a language and do away with enforced Checked Exceptions (making try blocks optional) because it was "too confusing" to bother to check for errors.
Nonsense. Checked exceptions are bug not a feature. An exception is useful because it allows a programmer to handle an error or unusual condition in the place on the stack that makes the most sense. Checked exceptions force intermediate code that has no sensible way to address the condition to declare a throws clause. That's nothing more than pointless drudgery.
Worse, the entire concept breaks down when interfaces are involved. An interface can't predict what kinds of exceptions its implementations might want to throw, so there is no correct way to define them. Checked exceptions do more harm than good and should be removed from Java. I'm not a .NET user but I'm glad Microsoft had the good sense to leave them out.
However, I can tell you that every company I have worked for forbade GPL, but have encouraged me to contribute to multiple projects using Apache, BSD and SCSL licensing. Actually, even a few LGPL.
Anecdotal and irrelevant.
If I go and collect the opinions of all the people on the JCP (whom all use different licenses) or just Java-using companies in general, the results would be just the opposite.
Obviously you didn't notice that the original column from which the author collected his data was posted on ZDNet, which is not exactly a pillar of the free software community. Even so, I say again that this was not an election. Evan Leibovitch did not set out to compare how many people prefered the GPL against how many didn't, nor did I bring the article to your attention to show that the GPL was winning some kind of popularity contest. He started by *noticing* that the GPL was winning the *money* contest and asked why.
Whether you admit it or not, the reality in the market place is full of evidence that the GPL does not in fact harm the free software community and in fact is probably helping to bring in companies that don't contribute to projects with less restrictive licenses. (That is not to say that companies that do contribute to non-GPL licensed free software are not contributing to free software -- they are. Think of it as a two pronged approach.)
For something like the Grep utility, there is no difference if it is run from a GUI find-button; as I understand it.
Running an application and using as a library are different things and are affected by the GPL differently. Anyone, including Microsoft, can freely run a GPL licensed application. No, they cannot simply transform it into a library and incorporate the code for it into a proprietary software application. That is why we must distinguish between the use of GPL code as a part of a GPL application or as part of a library. I want my code to be usable in the first way but not the second. Maybe you have different goals for your code, and if so you should not use the GPL to cover it.
Everyone is afraid of Microsoft stealing their code and claiming it to be their own. I just don't honestly think any license will stop them, since they seem to break them all the time. Sure, they end up in never-ending lawsuits, but they still do it.
Microsoft is forced to comply with licenses they have violated and often to pay significant damages all the time. Nevertheless, (can you tell what's coming next?) you've missed the point. I don't want *any* company anywhere to incorporate my code into proprietary software. Even if the GPL somehow just didn't apply to Microsoft it would be solving most of the problem for me.
When contributing to the Apache Ant project, they insisted I not event look at GPL code.
I find that claim suspicious, so perhaps you would care to back it up with some facts. I notice that the Apache Ant task guidelines explicitly mention the incompatible nature of the license they use an the GPL. I see that checking that a task does not depend on GPL or LGPL code is listed as an important step before submission. That is all quite sensible. However I see no indication there that merely reading the GPL licensed source code with a similar purpose is enough to disqualify submissions. One would think such a requirement would be well documented to eliminate confusion.
I don't doubt that you have been given such instructions when working on propriretary products. That is how the proprietary software industry looks at these things. Such an attitude would be quite appropriate regarding most non-disclosure agreements covering proprietary software, but that doesn't mean this is a sensible policy for GPL covered code.
Even if I concede all this nonsense for the sake of argument, it would still fail to prove that the differences between the GPL and BSD-style licenses
While that may be true on the Linux platform, I do not believe that to be accurate on either my Windows or BSD box. MOST of the software on my BSD box is free and NOT GPL.
Over half of all free software available on the most important internet archives for the stuff is licensed under the GPL. Check the statistics found here. I didn't say that half of the software on your FreeBSD or Windows machines was GPL licensed. More than half the software on your Windows machine is surely proprietary. I'm sure that the FreeBSD base system is almost entirely BSD licensed. However, stroll over to the ports system. There you will find a convenient way to install GCC, Bash, Emacs, and an endless selection of powerful and useful GPL applications and libraries.
Does FreeBSD even come with a C compiler that isn't GCC? On my FreeBSD machine "cc --version" gives me GCC output, but the first thing I do when I install such a thing is setup a variety of useful GPL applications, so I very well may have clobbered or overlooked some anonymous BSD licensed compiler along the way.
Do you disagree? Are you saying it is OK for me to scavenge code from GPL software to make other non-GPL free software? You make it seem like GPL is the only 'free' solution.
Are you even paying attention? I did not say it was acceptable for you to scavenge code from GPL software and place it into proprietary code. However, merely looking at GPL code will not prevent you from writing your own oringinal non-derivative but possibly similar code that does similar things. Read the GPL and tell me where it says that you can't do this.
Even IBM has their own open source license.
I have said over and over again that the choice of whether to use the GPL is a strategic one. Have you read the IBM public license? Here is what the FSF has to say about it:
In other words, the GPL is not restrictive enough for IBM in some cases. Meanwhile IBM contributes to GPL projects including Linux all the time, so they are clearly not allergic to it.
However, nothing on either of those pages show anything about the "Spirit of the GPL". However, a quick search of Google OR Slashdot will show that people quite regularly complain about projectX or licenseY breaking the Spirit of the GPL.
Good grief. Do you mean to say that the hoards on slashdot and various web logs are a better arbiter of what is and is not within the spirit of the GPL than the Free Software Foundation, the organization that created it, simply becuase the latter doesn't use the exact phrase "Spirit of the GPL" on the page?
Perhaps this is an issue that would be better resolved directly with licensing@gnu.org, with whom I will email directly to get clarification.
Yes, do. I'm sure you'll be back with an out-of-context quote that you've only half understood and turned upside down to make into some nefarious thing, but at least you will have had the opportunity to see learn something.
And can that resulting application be BSD-licensed? NO! It has to be GPL'd.
And your point is what exactly? What I said was that the GPL gives you an incentive to make your work free software, and it does that.
However, if the code was Public Domain, then NO ONE would question that everyone could use it without reinventing the wheel. GPL does not add this capability -- since Public Domain (BSD, etc) all have been around with that sa
That isn't what I got from reading that article.
Apparently you overlooked passages like this one:
And this one:
And this one:
I could go on, but before long I'll have quoted most of the article. Once again, the point is that many companies prefer to contribute to GPL licensed projects. That makes your claim that this license is hurting the community because companies are afraid to deal with it seem rather weak, to say the least.
He also said that most of the developers he talked to were GPL-fans, which obviously skews the overall results.
Exactly how does it skew the results? This wasn't an election. He was collecting arguments and attempting to understand why corporate sponsors seemed to prefer GPL licensed projects. Are you suggesting that there are BSD license advocates with powerful points to make who simply didn't bother to communicate them for some reason? Or are you just seizing a point you barely understand and waving it around as usual?
I think that is where you and I differ. If I had to choose between everyone (even MS) using my code or only the Linux users using my code (because that is where most of the GPL development is), I would choose widespread usage.
No, I think you have managed to misunderstand yet again. For one thing, you have failed to distinguish between running code and integrating it into proprietary applications. I have no objection to Microsoft or anyone else running my code for any purpose, studying it to learn from it, redistributing copies or improving the program for the benefit of everyone. What I don't want is to permit a situation like what happened with Kerberos, where Microsoft made proprietary changes to create incompatability and refused to release them. Notice the BSD-style license there. I also want to prevent organizations that might one day maintain my code from later deciding to make the code proprietary, as almost happened to the X Window System twice now. Again there is a BSD-style license involved. Have you ever heard of something like this happening to a GPL project? I haven't.
I find the GPL an effective tool against that, and so do many people around the world. Maybe you don't care if your code becomes the next thing Microsoft mangles in an effort to protect market share. In that case, go ahead and release your code under a BSD license if you want, or just commit it to the public domain. Any contribution to the free software community is a good thing, so I'll not complain. But spare me the nonsense about how the GPL is hurting the community.
For another thing, your claim that most GPL development is done on Linux is suspicious. Maybe it's even true, but it is certainly unenlightening. FreeBSD, NetBSD and OpenBSD all ship GPL licensed applications in their distribution. I am sure you are using plenty of GPL applications on your FreeBSD machine without even knowing it. I'm also sure that many capable engineers from all three projects have made valuable contributions to GPL projects over the years, just as people who prefer the GPL have nevertheless been quite willing to contribute to projects using BSD-style licenses. I know for a fact that some FreeBSD kernel hackers have contributed to the Linux kernel and vice versa. The quasi-religious schizm you imagine is mostly fictional among the people who do the heavy lifting.
Realistically, I wish *all* code was Public Do
Sure, reinventing is a waste of my time and their money, but wouldn't it be better for the community (and even what they claim to be encouraging) if I were to make their product better for the whole community?
You've said this before, and I've already addressed the loss of your potential input and fixes. Plenty of people much smarter than you are not troubled by the GPL and are more than happy to contribute improvements. Obviously the programmers who chose the GPL believe that losing the few people who think the way you do is more than made up for by those who will be encouraged by the GPL to make their applications free software. You are welcome to disagree, but there is a vast body of widely used GPL software out there that you need to explain. Why is over half (and that's a conservative estimate) of all free software covered by the GPL if that license harms the community?
The developers and companies would be willing to spend their time and money giving back to the community, but can't because they can't use GPLd software.
This is complete nonsense. Almost every Fortune 500 company is using GPL licensed software in one form or another today and many contribute improvements to the community. For instance, IBM contributes to the Linux kernel even though they also sell a variety proprietary operating system kernels. Companies that "can't" use GPL licensed software in general are simply those who have been misled by ignorant statements of the sort you are making.
If I am writing a Grep utility, and I download (and thus possibly browse the source for) a GPLd version, I am breaking the spirit of the license, even if not the letter of the license, by using GPL ideas to write non-GPL code. [...] You can correct me if I am wrong there.
You are wrong there. In the first place, copyright covers expression and not ideas, the dreamy hopes of proprietary software companies notwithstanding. Furthermore, one of the four fundamental kinds of freedom required for free software is to allow people to study source code and learn from it. You violate neither the letter nor the spirit of the GPL by downloading code, studying it and using ideas to inspire your own independent and original work. Go to the FSF philosophy pages and do some reading before making comments on the spirit of the license.
What incentive? Even as an independant developer, I don't see that part of it.
First, if you make your application free software using a GPL compatible license (such as the BSD license without advertising clause) you can link with that vast body of GPL licensed code I mentioned. That means fewer wheels reinvented and more time to focus on other aspects of the application. Second, if you actually use the GPL you need not fear that your competitors will take your application, improve upon it and use your own work against you in the marketplace without making their changes available in turn.
I accept that this sort of thing is beyond your understanding and I don't expect to penetrate your closed mind on the matter. Still, if this incentive is so inscrutable, how do you explain the preponderance of GPL licensed code out there?
Yes, I agree. However, the "Open Source Community" these days seems to be more GPL vs. Non-GPL. It should not be that way.
Actually, it is not that way -- except perhaps in the minds of a few people like yourself. People who like and advocate the GPL usually don't object to non-GPL licenses. Even the Free Software Foundation, which is surely the most avid of GPL proponents, does not suggest using the GPL for all software and considers non-GPL licensed free software to be perfectly acceptable.
I'm sorry. I am not familiar with BSDi.
BSDi is a company that made a proprietary version of FreeBSD. They didn't succeed in overshadowing FreeBSD. This fact is often used by BSD license advocates to demonstrate that
Here is an article that offers further explanation of how the GPL helps the free software community and is even advantageous for corporations in many cases.
No, but the assumption is that [Sun] would have to OpenSource the core libraries as well as the VM itself.
Certainly. But the assumption that the libraries must be released under the same license as the virtual machine doesn't follow from that. Even the Free Software Foundation notes that the GPL is not the best license for all software. They recommend a BSD-style license sometimes, as for the Vorbis libraries. More to the point, the FSF already distributes GNU Classpath, which implements much of the Java standard library, under an LGPL-like license.
Anyway, I think we can all agree that retroactively revoking the freedom to create non-GPL licensed Java libraries and applications (even if such a thing could be done, which seems improbable to me) would be quite impolite and not especially clever. People who wish that Sun would release the virtual machine under the GPL or some other free software license most likely do not mean anything of that sort. I certainly don't.
Since many companies have made me rewrite things because the current implementations were GPL (ie: reinvent the wheel), I claim this hurts the open source movement.
I would believe you if said this hurt you or the company that paid you to rewrite things, but I don't see how this hurts the free software movement (sorry, but I don't particularly care about the open source movement). Reinventing the wheel is the price one pays for not cooperating with the community.
Had those library been LGPL, for example, those companies would have allowed me to use and even improve upon (and return to the community) those libraries. Since they were GPL, we were not even allowed to download them.
Why did you put "return to the community" in parenthesis? This is the *only* germane part of your argument. No amount of harm to you or your company counts when asking whether the GPL harms the free software community, of which a company that forbids even *downloading* anything licensed under the GPL (an idiotic policy, by the way) is clearly not a part. Also, you are failing to distinguish between GPL applications and GPL libraries. Anyone willing to return improvements to the community should have no problem with the former. Do you admit that what you really despise is the use of the GPL for libraries and not the license itself?
As far as libraries go, even the FSF notes that whether the GPL or LGPL is preferable depends on strategic concerns. When there are competing proprietary libraries they prefer the LGPL for exactly the reason you mentioned. Only when a library is unique and innovative do they recommend the GPL. In such cases the loss of your potential improvements is probably made up for by the incentive this gives to more sane organizations to make their application free software. Remember that helping people to create proprietary applications is not the goal of the free software community.
Even if a court chose to say otherwise, doesn't the whole concept that EVERYTHING extends Object (even if you don't do it explicitely) require GPL, by the Spirit of the GPL?
Not really, no. The GPL was created in order to prevent companies from improving free software and releasing the result under restricive proprietary licenses instead of giving those improvements back to the community, essentially tempting users away from free software using the efforts of free software developers themselves. This is essentially the situation economists call the Tragedy of the Commons. Public domain software and software that is licensed under BSD-style terms is regularly treated this way.
(In practice free software development has turned out to be so effective that proprietary companies have trouble keeping up. BSDi isn't as successful as FreeBSD, for example. Still, that isn't the case for every project and there are other good reasons for using the GPL in many cases. For example, I don't want soft
What I thought it *might* be doing is something like SkinL&F [l2fprod.com], which, as I understand it, can read the GTK and KDE themes themselves, thus emulation should be completely accurate.
I am skeptical that it is even possible to do what I want with pure Java for the reasons I already mentioned, but I'll check it out.
A few scripts might get the point across, but every time I have seen this situation, they stress tested the website to determine how well it would scale.
One stress tests a prototype to learn how much performance needs to improve, not because it is expected to be fast enough for production use. The point, after all, is to get something work ing quickly to prove that the application as proposed can get the job done. Python CGI scripts are great for this purpose. Clearly a mod_python application will beat the performance of a CGI Python version, and I have never said anything to the contrary.
The point is that Python is more flexible than Java because (among other reasons) it permits this simple and effective techinque. Servlets and JSPs are demonstrably more complex to create and install. Python is also every bit as portable and free of pointer problems as Java. And as for simplicity, try teaching both to a non-technical user. I could go on, but you've clearly made up your mind that Python is no good ages ago.
I am not having [the experience of considerable overhead required to bring up a Java virtual machine] on FreeBSD or WinXP.
I suspect that is because you don't compare apples to apples by considering equivalent C programs. No doubt once one is conditioned to accept the sluggish start-up time of a Java virtual machine everything seems fine. I use shell scripts for many kinds of task and find them much snappier than command-line Java programs even though they often need to launch several processes running C programs.
However, without hard numbers which neither of us have at hand or are inclined to go generate, this is just so much subjective chatter. Go ahead and use command-line Java programs if you find that helpful for getting work done. I'll stick with C programs and shell scripts, thanks.
The fact is, however, they complain about performance and bugs, but prefer to stick with one that is no longer being patched instead of using the one that fixes their issues.
This supposes that later editions of Java simply fix their issues and introduce no new problems. That simply isn't true. Backward incompatible changes constantly creep into Java releases. On the basis of technical intuition, I doubt that the increase in support calls on this issue will cost more than the extra development time needed to identify and work around version compatability problems. Of course, any such problems that escape the testing net will generate those extra support calls anyway. Apparently the professional bean counters whose job it is to make such calculations for those vendors based on hard numbers agree.
In my personal experience, the only problem (other than the 'assert' or 'enum' changes) is that they specifically create a JVM in JNI code, which breaks because the user has a more up-to-date system then the distro.
And you think it is acceptable that JNI code can break between minor VM releases? I don't. Release a new interface and implement the old one interms of it, if necessary. Anyway there are plenty of actual classes that change their behavior between releases, so JNI is not the whole of the problem by any means.
Back to that argument? If Sun were to make the single class 'Object' GPL, it would cut off most of their development support.
Back? Please consider what I actually wrote: Actually, if Sun does choose to release a free software virtual machine they will certainly use the GNU GPL or something like it. Are you really unable to distinguish between the Object class and a virtual machine? As far as making Object GPL goes, y
But, since Swing ALREADY has the GTK theme, I have to disagree that writing all the peers is any easier than calling a single line of code to switch themes.
This is misleading for two reasons. First, what Swing has already is NOT what I want. Since it is necessarily written in pure Java, the best it can do is emulate the look and feel of GTK. Perhaps it can do a reasonably good job, but it seems unlikely to be perfectly correct in all cases and even a small visual inconsistency can be distracting. Swing is less likely still to quickly adjust to GTK theme improvements over time. Of course, having a Swing theme that emulates the *default* GTK theme and one that emulates the *current* GTK theme whatever it may be are different things. I very much doubt that Swing does or will ever do the latter. (I notice that gtkswing clearly states that only the default theme is supported. Is that the theme you are referring to?) Remember that new GTK themes are created all the time, just as Swing themes are. How could Swing possibly have support for all of them, and why would the developers even bother trying? Using AWT peers will give complete and correct support for the current -- not just the default -- GTK theme no matter when it was created or where it came from, for no additional effort.
Second, much of the work needed to write such peers has already been done. Perhaps the GCJ team is reusing work done for java-gtk in which case the heavy lifting is already finished. Either way, from my perspective it's just a matter of waiting. Meanwhile my AWT applications, while terrifically ugly, are quite functional and will get better looking with no code changes when the GTK peers appear.
Starting a new process for every incoming request is insane regardless of language. Otherwise, Thread Pools wouldn't exist.
Not so. Starting a new process for every incomming request is perfectly sensible if performance requirements are within a certain range (this depends on the hardware in use and what other applications need to run on the same machine). Clearly a persistent approach such as mod_python or servlets will give better performance, but this is not always needed and is always more complex. That means more time consuming to create and debug. Consider a company that needs a prototype of a web application, for instance. A few simplistic Python scripts can be put together easily and will likely be more than fast enough to get the point across. Doing the same thing with Java is not likely to be a good idea, because the syntax is more complex, because there is a separate compile step (Python compiles to byte-code as it runs) and because performance is sure to be dire.
I think it more likely that the Apache mod is the problem, rather than the Java VM. Pure java apps from the command-line seem to run very fast on both Windows and BSD. It is only from Apache that they seem slow.
I think it is impossible for Apache to be the problem, because it has no idea what language a CGI script is written in and therefore would have to deliberately introduce delays to slow down Java. In my experience the overhead required to bring up a Java virtual machine is considerable, and this makes command-line performance unacceptable for many purposes where Python does fine. This point of view is seconded by engineers at Sun Microsystems in the internal memo I linked to last time.
Personally, I have installed a few different applications that installed their own JRE, and I submitted bug reports to those companies because A) They were installing JDK 1.2 when I already had 1.4.2 on my system; B) They were ILLEGALLY installing the JRE (which gets back to your original point).
Point A is quite deliberate and I expect your bug reports don't get far before being stamped WILL-NOT-FIX. These vendors want a JRE that they can depend on to behave pre