Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Java Programming Software Apache

Sun Works With Apache Software Foundation 129

Posted by Hemos from the he-said-she-said dept.
The Jakarta group had raised some concerns over the proposed Java Specification Participation Agreement. After some hemming and hawing, it appears that the Java Community Process chair (Sun) has agreed with the ASF's concerns - but IANAL ? . If you have more info, paste it below.
This discussion has been archived. No new comments can be posted.

Sun Works With Apache Software Foundation More

Sun Works With Apache Software Foundation

Comments Filter:
  • <sarcasm>
    Could you please provide a link where we can get more information?
    </sarcasm>

    -davidu

  • Tomcat (Score:3, Interesting)

    by Anonymous Coward on Friday March 22, 2002 @04:50PM (#3209965)
    Jakarta's Tomcat [apache.org] was threatened, and, from someone who works in the J2EE market, that woulda been baaaaad. Tomcat is great for prototyping and working at from home (trust me, you don't want to lug Weblogic or Websphere onto your home machine).

  • I'm not really suprised... (Score:4, Insightful)

    by thesupraman ( 179040 ) on Friday March 22, 2002 @04:54PM (#3209986)
    With Apache representing such a massive (and impressive, they are certainly a great example of success)number of internet/intranet servers out there, I'm not suprised Sun takes them seriously, they probably represent one of the strongest areas of java development currently.

    I would truly love Sun to take java *implementation* a little more seriously, they seem to put a lot of work into API designs and the legal situation of java, but don't seem that commited to providing a stable and simple to install environment for developers and users.

    The number one bug bear I have repeatedly hit with java is convincing users that it is worth the trouble to get the 'right' implementation installed on a given machine to allow the required functionality to work, and this can sometimes be hit and miss, which is a big problem.

    I would love to see Sun dedicate perhaps 6 months to working with other implementers to get java working smoothly and seemlessly on a wide range of hardware and operating systems, as it just doesn't seem to yet.

    I know that microsoft has thrown a lot of hurdles in the way of java, however it's not just windows where there seem to be problems. It is just too hard to get users to get their execution environment 'right' to use.

    I think this situation will limit java to vertical apps and server use until it is addressed, as these are the only situations where the extra time to get it working is acceptable.

    • Re:I'm not really suprised... (Score:4, Informative)

      by md17 ( 68506 ) <james@NoSpAM.jamesward.org> on Friday March 22, 2002 @05:22PM (#3210133) Homepage

      This is F-U-D.

      ...but don't seem that commited to providing a stable and simple to install environment for developers and users.

      Have you used Java lately? Forte? NetBeans? Eclipse? Tomcat? JBoss? There are plenty of stable and simple to install environments for developers and users. I use them everyday!

      I would love to see Sun dedicate perhaps 6 months to working with other implementers to get java working smoothly and seemlessly on a wide range of hardware and operating systems, as it just doesn't seem to yet.

      Once again... Have you used Java lately?
      At my company we run and host Java Apps written on every different platform out there. How often are the Java Apps incompatible? Only when someone decides to use Micro$oft specific Java. (Which isn't that often.)

      Why do so many on Slashdot people feel compelled to write FUD about Java just because it's not GPL?

      I suspect that if it were all of a sudden GPL'd everyone here would bow down and start worshipping it, because it's the coolest thing since the hula-hoop.

      • Re:I'm not really suprised... (Score:5, Insightful)

        by rhizome ( 115711 ) on Friday March 22, 2002 @06:20PM (#3210415) Homepage Journal
        Why do so many on Slashdot people feel compelled to write FUD about Java just because it's not GPL?

        Aside from you pulling that GPL crack out of your ass (your comment's parent didn't mention the GPL once), there seems to be plenty of room for criticism of Sun's relationship with Java and OSS. Want to install the JDK on FreeBSD? Be sure to a)install a GUI; b)install a browser that works with the various linking methods that Sun uses; c) register for a sun.com account and waste time telling Sun important things like your address; d) log in; e)Agree to the SCSL; f)download something that says "Linux" in the name (there are very few references to FreeBSD at Sun, and none in the JDK download section); g)manually download the source file; h)Agree to a license *again*; i) etc...

        Leave it to Sun to infect FreeBSD with the Microsoft-style inefficiencies that FBSD has been so good at distancing itself from. It's not about the GPL, it's about Sun and the way they treat people who aren't their cheerleaders. Being an employee of wide-line Java shop, you probably don't have occasion to relate to that.
        • The fact is that it would cost Sun _real money_ to support FreeBSD. That is because they have to _pay_ their employees to do the work. I'm sure if you agreed to _pay_ Sun's employees for better FreeBSD support, you could have a better FreeBSD experience too.

          So, how much are you willing to pay? Zero dollars, you say? Well, what a coincidence, that's how much Sun wants to pay too!

          Why not use all zero dollars to create your own J2SE/J2EE platform implementation and give it away for free? When you are done, somewhat will complain that you don't have it running on GeoWorks on Commodore-64; what will you say to them?
      • Why do so many on Slashdot people feel compelled to write FUD about Java just because it's not GPL?

        Nice troll. Where the hell did the poster mention the GPL in that post!? He might have been under-informed, etc, but the poster didn't once mention the GPL, or open source at all. Go ahead and refute his actual claims, but spare us the straw men and the "I'm hipper than all you OTHER /.'ers because I'm criticising the GPL and all it's hippy followers!" I hate to tell you this, but it's been done. (/me looks over in Carnage4Life's direction... just kiddin' Dare. ;-)
        • None of the so-called "GPL hippy followers" ever say that Java not being Open Source is the source of their hatred. I love the GPL, OpenSource, and all the hippy followers. I just think that many people automatically criticize Java because it's not OpenSource or GPL, without ever really using the technology or learning about the JCP. That is what I attempted to point out with my GPL comment.
          • I just think that many people automatically criticize Java because it's not OpenSource or GPL, without ever really using the technology or learning about the JCP. That is what I attempted to point out with my GPL comment.

            Well, then, you did a much better job of explaining it this time around. (and good for you for not taking my playful flamebait. ;)

            http://slashdot.org/comments.pl?sid=29895&cid=32 10 240

            The above post basically sums up what I think about Java... it's a great technology, it's just a real shame that Sun insists on dominating the language. It's their right, but I think it's also their folly. I wonder sometimes where Free Software could be right now if Java was made an independant, more open standard... (for that matter, think of where JAVA could be!)
      • Did you read the post?

        The poster was not suggesting that there was any problems with the stability of the apps once they are set up right, or that there were any problems with compatiblity between systems.

        Here's an example of what they are talking about:

        Take an average MSCE. Give them whatever type of box they like (NT, XP, 2K whatever). Ask them to get Tomcat running. Time them. If it takes them longer than 10 minutes (and it will) to get it running properly there needs to be work done. Now repeat for Forte, Netbeans, Eclipse, etc...

        The point isn't that it can't be done its that its not easy enough yet.

        Another case in point, take a non-technical Mom. Explain Classpaths, src vrs class, and java vs javac to her to the point where she can understand it. Now repeat with VB. The knowledge required is just much less.

        That said all the applications you mentioned are incredible. I love them. To be honest Java is the neatest thing in development I've worked with (and thats saying ALOT). When done right its provides stellar results.
        • I did read the post and my comments stand. The poster mentioned "developers and users"

          Developers: First of all I do not consider the average MSCE a java developer. Also, since I doubt that the average MSCE's has a good understanding of the Java platform asking them to install tomcat is like asking them to pull a list of the top 50 email senders out of /var/adm/mail.log and sort them alphabetically all with a string of unix commands. The point is that any Java developer can install any of the mentioned apps pretty quickly.

          Users: With Java most users just need a web browser and / or J2SE 1.3.1 from Sun. How is that difficult?
          • the point is that the java programmers aren't the ones that install this kind of thing. It's the sysadmin's. So his point is quite valid, as MCSE's are the sysadmin's (ok, at least in theory).
        • Another case in point, take a non-technical Mom. Explain Classpaths, src vrs class, and java vs javac to her to the point where she can understand it. Now repeat with VB. The knowledge required is just much less

          Not sure why a non-technical mom would need to understand any of these... but let's play anyway..

          Classpath vs DLL versions in VB src vs executable vs form definition files in VB compiler vs runtime in VB

          I really fail to see the difference... these are basic elements in any development environment.... even in VB

      • I suspect that if it were all of a sudden GPL'd everyone here would bow down and start worshipping it, because it's the coolest thing since the hula-hoop.

        You know, for kids.

    • Re:I'm not really suprised... (Score:4, Informative)

      by Guillermito ( 187510 ) on Friday March 22, 2002 @05:36PM (#3210203) Homepage
      While I think some of your points are valid, I also think Sun has made a huge improvement in the area of application setup with their Java Web Start product (now part of the standard jre distribution)

      http://java.sun.com/products/javawebstart/ [sun.com]

      With Java Web Start installed in the client's computer you can distribute your Java application by just setting up a web page with a configuration file. The user just click a link in the page and Java Web Start downloads your code, all the libraries and even a newer version of the jre if needed. The application runs on an applet-like sandbox, so it will not read or modify local files, unless the user authorizes it. The applicacion is then cached for future use, so it will not be downloaded again, unless an automatic checking proves it has changed. If you are using Windows Java Web Start will ask you whether you want to add an icon to the menu the second time you start an application.

      Of course, all this wonderful features work only if you have the jre installed in the first place. So it's some kind of chicked and egg situation. Anyway, I don't find the standard jre installation more complex that, say, installing Acrobat Reader, or other commonly used plug-ins.

      Sun mantains a collection of links to third party Java applications:
      Swing sightings [sun.com]. Some of them very interesting, some of them Web-startable.
    • Well you are only partially right.... Yes the execution environment holds up wide spread acceptance. The problem lies in the developers that distribute the applications and not with anything that sun does or does not do. It is the job of the application installer to ensure a proper runtime environment. This is the one thing that is horribly missing in most distributed java applications. I recently did a install of limewire on a machine and that is one program that is written to install correctly. It was a simple installation and no I did not have to set up class paths or any crap like that it just worked. Perhaps developers should concentrate on deployment a little just as well?????

  • Stupidity (Score:1, Interesting)

    by Ogerman ( 136333 )
    This kinda nonsense is ridiculous. Java and all related technology would be much better handled as an open industry project rather than by an arrogant corporation that hasn't quite realized yet that proprietary is going the way of the dino. So it doesn't fit their current cost structure. Boo hoo! Restructure the company how 'bout.

    • Re:Stupidity (Score:1, Flamebait)

      by furiousgeorge ( 30912 )
      oh boohooo............. go make your own Java. Come up with your own ideas and quit bitching about what somebody else does with theirs.

      oh yeah......nevermind. not a single freaking original thing has ever come out of the open source whiners brigade...
  • who thought that Indonesia was complaining that they had a hammerlock on the name "Java" or "Jakarta", and was prepared to immediately boycot all Indonesian...um...pencil cases until this was cleared up?

    <crickets>

    </crickets>

    Okay, never mind then. Bastards.

  • Above and beyond (Score:4, Insightful)

    by axlrosen ( 88070 ) on Friday March 22, 2002 @05:17PM (#3210108) Homepage
    It really looks like Sun went above and beyond the call of duty here. I doubt Apache expected them to use $3 million of their own money to help fix this, but they did it anyway because it turned out that that was the only way to fix issue #4 on their list. Pretty cool. Chalk up one Open Source Brownie Point for Sun.

    • Re:Above and beyond (Score:5, Informative)

      by ddstreet ( 49825 ) <ddstreet@iee e . org> on Friday March 22, 2002 @06:15PM (#3210388) Homepage
      use $3 million of their own money

      I think if you read it more closely, it says:

      Sun will therefore offer an annual support scholarship program to suitably qualified efforts to cover access to support services for TCKs offered by Sun.

      Which limits it to TCKs offered by Sun - meaning Sun doesn't actually spend any money, they just don't take any money in for those specific cases (they're not losing anything, since those implementors can't afford Sun's prices anyway!)

      So while it's kinda nice, Sun is not spending 3 million, and is not really losing any money either - those who get the free license by definition couldn't afford it in the first place.

      • Read the quote again:
        Sun will therefore off an annual support scholarship program to suitably qualified efforts to
        cover access to support services for TCKs offered by Sun. Emphasis added
        This means that Sun will fund the support services required by the selected "efforts" in the course of certifying their projects via the TCKs. The note states these support services can be costly to provide and that is where the $3 million of Sun's money comes in.
        • Sun will fund the support services

          If the TCK is offered by Sun, who is providing the support service? I would certainly guess Sun...so we're back to my original statement. Essentially Sun is doing work for no pay, not actually paying someone else. Of course the support staff does get their normal salary, etc...so it's not totally free. But those costs are fixed and already in Sun's budget...

          Now if Sun offers a TCK that is supported by an outside party, in that case Sun would have to spend $. I would be suprised though, why would Sun outsource support for a TCK it offers? Doesn't make sense to me...

      • Which limits it to TCKs offered by Sun - meaning Sun doesn't actually spend any money, they just don't take any money in for those specific cases (they're not losing anything, since those implementors can't afford Sun's prices anyway!)

        No, that would be the case if they were just throwing the license "over the wall", to quote the article. But they're not, they're saying that they realise that TCKs are potentially useless without support from the vendor.

        The scolarships are there to provide that support to at least some of the people using the free licenses, and therefore have an actual cost to Sun in terms of resources.

        And of course its limited to Sun's TCKs, they can hardly support those of other vendors can they?
        • TCKs are potentially useless without support from the vendor...they can hardly support those of other vendors can they?

          You are saying 'Sun pays the vendor to give support to the implementor' and then 'Sun is the vendor'. This is exactly what I said, Sun is not actually paying anyone else.

          • "You are saying 'Sun pays the vendor to give support to the implementor' and then 'Sun is the vendor'. This is exactly what I said, Sun is not actually paying anyone else"

            The last time I checked, support services equalled people. People cost money. And this means either Sun's own professional services, or contractors. Either way, Sun will be paying real dollars, either in salaries or contractor fees.

            • support services equalled people.

              if you read my other reply, you would see this:

              Of course the support staff does get their normal salary, etc...so it's not totally free. But those costs are fixed and already in Sun's budget...

              Of course doing business is not free. But there is a huge difference between paying someone else 3 milion dollars, and doing something for free that you would normally charge 3 million for. Of course it's nice of Sun. But the actual cost to Sun of that 3 million is unquestionably much less - since the markup on support services is usually quite high. And that cost is very likely a flat rate (salary), which Sun is going to pay (to the support staff) anyway. So in the end Sun possibly may provide 3 million in free support, which costs them little or nothing more than their normal payouts.

  • It's about time (Score:4, Informative)

    by WndrBr3d ( 219963 ) on Friday March 22, 2002 @05:20PM (#3210126) Homepage Journal
    I figured this would happen eventually. It seems all Web Server software (other an IIS of course) will merge to become an Application Server. Well, not as much merge but mature.

    This happened last year with the relase of ColdFusion Server 5.0 which had a built in J2EE Aplication Server. This gave ColdFusion programmers the platform to incorporate Java into their CF apps (but if they were smart they'd use it as a springboard to merge all apps over to Java).

    This will probably be a big step forward for Apache and I'm interested to see whats cranked out.

  • this is totally offtopic but (Score:5, Funny)

    by Chundra ( 189402 ) on Friday March 22, 2002 @05:31PM (#3210179)
    Is it just me, or is the java icon they're using a styrofoam cup of coffee with cigarette butts floating in it? If so, it's cool (even though it was copped from a perl jounal a while back). If not, what the hell is that floating in there?

  • This looks really positive... but... (Score:5, Interesting)

    by JohnMunsch ( 137751 ) on Friday March 22, 2002 @05:36PM (#3210206) Homepage
    There's one detail that I notice and it may be very important. They list at the end of the document a set of JSRs that they are committed ("at a minimum") to changing to meet Apache's requirements. Can you see which one is missing?

    JSR 151, Java 2 Platform, Enterprise Edition 1.4 (J2EE 1.4) Specification is not in the list. That's the one that JBoss really needs (or JSR 58 for J2EE 1.3) access to testing on and a guarantee that Sun isn't going to go after them for implementing an open source version of their specification.

    Now I could be overreacting, it could be that they left 151 out of the list because it is still open and they intend to get to it for that reason, but if that was the case you would expect to see 58 in the list. I'm hoping this is more oversight than an actual attempt to continue the foolishness with JBoss.
    • From the end of the article:

      The revised JSPA will govern the execution of JSRs which are created after it has gone into effect, which is probably several months away. When that occurs, all new JSRs (led by Sun or others) will be governed by an agreement that satisfies Apache's requirements.

      Again in the interests of meeting the spirit of the requirements, Sun will modify the specification licenses of all the JSRs currently in progress to reflect Apache's requirements as met in the new draft JSPA. And we reaffirm a previous statement that we would work over time to change the licenses of previously completed JSRs to comply with the new JSPA draft. We specifically commit to doing such changes at a minimum for:

      JSR 31 (JAXB), JSRs 52, 53, 152, 154 (JSPs/Servlets), JSR 63 (JAXP), JSR 67 (JAXM), JSR 93 (JAXR), JSR 101 (JAXRPC), JSR 127 (Java Server Faces), JSR 172 (J2ME Web Services)

      From my reading, they are committing to make it happen retrospectively for the above JSRs (as a minimum) and it will be in place for future JSRs.

      Of course, this is providing that this new wording is passed by the committee for JSP-99.

      I suppose it will be back to beating up Sun for not putting Java under the GPL ;-)

    • I think the real issue will be whether or not JBoss will "qualify" for the free TCK. JBoss is free but the JBoss founders are making cash through consulting and other means.

      Also, even if JBoss passes the test, they won't be able to use the J2EE brand, because testing is not the only requirement to be J2EE branded, I believe.
  • I think, JCP or not, Java has essentially become a proprietary system. It started out as a small language with a focussed library, something that could have set a widely implemented standard. Sun was promising to submit the language and a set of core libraries to a standards board. Several vendors were starting to come up with independent implementations. But Java 2 has become so big and complex that the only "standard" implementation is Sun's.

    The mechanisms at work here are essentially the same as with Microsoft Windows or Microsoft VisualBasic: in the absence of multiple implementors, people will just keep adding functionality to the single codebase and ship the stuff. There is no pressure on Sun to keep things small, manageable, and independently implementable. And since Sun's Java implementation is not Open Source (although you can get the source with lots of restrictions under some legal agreement or other), it still gets controlled by just one company. The overall effect is also the same as with Microsoft: either you follow Sun wherever they go, or you are out of luck.

    It's a shame that it had to come to this. I think, on balance, once Mono and similar projects have matured enough, ECMA C# (but not Microsoft C#/.NET) is going to be the better long-term choice for people interested in Java-like languages. I expect that's going to be less than a year. That is regrettable because an open source Java equivalent of ECMA C# would have been available years ago if only a standard equivalent to ECMA C# had been created for Java. And I think Sun would be doing better in the long run as well if that had come to pass--Microsoft may be able to get away with this sort of thing for decades, but I doubt Sun will.

    • Re:it's like rearranging deck chairs on the Titani (Score:5, Insightful)

      by corey_lawson ( 562933 ) on Friday March 22, 2002 @06:04PM (#3210327)
      ...and you don't think that eventually Mono will have to do the same monkey tricks that Apache has to do now with Microsoft? All MS has to do is make a key piece of functionality proprietary and not disclose it to Mono, and they have many legal layers they can wrap it under, just like with Samba and Kerberos. Will ActiveState release Perl.net for non-Win32 systems? Will the (crazy?) people who put out Cobol.net do the same? Will MS allow some of the libs used by .Net to be made hostable from non-Win32 systems?
      • err..they already have done this right ? Winforms libs are already proprietary to win32. and they're too big for anyone to implement on *nix.
        The thing is that it doesnt matter. if i have a subset of .NET on *nix i can write my code for that subset. As long as the subset compiles on win32 (or the CLR runs) i've achieved portability.
        Unless there is some really critical block of code that's winforms specific in general the subset is all that matters. the GUI stuff will have to be rewritten but since .NET involves SOAP to abstract the GUI anyway, it doesnt really matter.
        i cant see how M$ could do this with .NET (make it proprietary while still keeping ECMA happy) with the ECMA subset of C#/.NET . But i can definitely see Sun doing it with Java -- theres no oversight commitee to bash Sun over the head if it decides to completely close java.
      • ...and you don't think that eventually Mono will have to do the same monkey tricks that Apache has to do now with Microsoft?

        No. The reason is is that Sun set out to create a single, universal, platform-independent language and runtime environment. Mono and .NET, however, each have a much more modest goal: provide a Java-like language with a few libraries that work on different platforms and provide easy ways for people to use their platform-specific stuff. C# doesn't aim as high as Java: C# is just a Java-like language to replace C++, with a few portable libraries.

        In different words, Apache has to care about Sun stuff like J2EE because Sun has made Java an all-or-nothing proposition; if they don't support all the latest Sun APIs, they aren't Java compliant. There is no such pressure on Mono.

    • That is regrettable because an open source Java equivalent of ECMA C# would have been available years ago if only a standard equivalent to ECMA C# had been created for Java.

      It wouldn't have even taken that much for there to be a Free Software version of Java. Because Sun released Java under there horrible shared source-like license, Kaffe had a whole world of trouble preventing IP pollution.

      It's really ashame.
    • 1) Java is not going away. It has a lot of momentum, a number of mature implementations and competing implementations. While .NET will be successful the two are assured of uneasy coexistance for the forseeable future.

      2) The specification process for the Java platform is public, includes vendors of competing implementations and gives them an equal vote. MSFT will do all that when hell freezes over, pigs fly and user error is a thing of the past.

      3) Don't believe the ECMA C# hype. That is only a small part of the .NET platform and as such is in no way comparable to the level of open specification present in the JCP.

      4) Furthermore, anyone who believes that MSFT is going to play nice needs to take a refresher course on recent history. A vendor with dominent market share has nothing to benefit from high levels of interoperability. The internet alone set MSFT back substantially in continued and extended market domination.

  • No OSS RI licensing is news to me (Score:3, Interesting)

    by ddstreet ( 49825 ) <ddstreet@iee e . org> on Friday March 22, 2002 @06:27PM (#3210454) Homepage
    "2. The JSPA must grant an Expert Group the right, at the Expert Group's discretion, to release its own Reference Implementation (RI) and/or Test Compatibility Kit (TCK) under an open source license (Apache-style license minimum.) ..."

    The draft of the JSPA submitted for community review would permit the TCK to be so licensed, but not the RI.

    That's news to me, when we moved into the public review period [jcp.org] for JSR80 (javax.usb) [jcp.org], the JCP PMO suggested that we host the RI, licensed under the Common Public License [ibm.com], on our own server [ibm.com].

    We have written and circulated a change to the draft JSPA that would permit the RI to be so licensed.

    Well that's good news. I thought it was already ok! Guess that's why IANAL.

    • Of course, the orignal Java USB API was/is LGPL'd (jusb.sourceforge.net [sourceforge.net]). But the terms of the various JCP agreements prevent JCP processes from working with such an effort (even for expert group membership, much less the other issues). The jUSB effort predated JSR-80 by over a year. See the FAQ entry on that topic (at the jUSB site).

      If IBM is going to mention their javax.usb API as an example of OSS and Java, I think it's worth highlighting that there's a very strong argument to be made that Sun permitted that OSS license to preclude a Free Software effort taking hold. Notice that even the Apache effort was having a hard time getting accepted as an OSS/JCP process ... this USB example shows that Sun is clearly willing to bend its process quite a lot to prevent Free Software from gaining headway.

      Now if Sun were willing to let (a) the Reference Implementation (RI) and (b) the Test Compatibility Kit (TCK) be Free Software, and (c) structure the JCP so that Free Software contributors can fully/Freely contribute to the spec, as opposed to needing to license themselves to Sun at zero cost ... then I could agree that there's been some real progress.

      Until then, all I see happening is that Sun continues to be opposed to a true "Community Process" because it's excluding the Free Software community.

      • The jUSB effort predated JSR-80 by over a year

        Check your facts. You are wrong. And javax.usb was started internally (at IBM) long before starting the JSR.

        Sun permitted that OSS license to preclude a Free Software effort taking hold

        Ah, so 2 groups have never worked on similar projects before eh? Hello, gnome, kde? We have no desire to 'preclude' David or his project, he/it is free to continue obviously.

        In the specific case of JSR80, the RI is Open Source. There is no TCK yet, but it will (as far as I know) be Open Source also.

        Now, if you are talking about the process, I have no argument; it's closed and the JSPA is (was?) so restrictive I would never sign it as an independent developer.

        • Check your facts. You are wrong.

          Let's see, CVS for the jUSB effort has files dating from April 2000. But IBM's effort only entered public review in September 2001 (according to the JSR project page, which doesn't list the CVS for the RI). That seems like almost a year and a half to me.

          I think there's an argument to be made that the essence of "Open Source" has a lot more to do with open development process than just ability to get source code. That's not to say that having source isn't useful ... it's just to say that in the long term, what's important is that processes are open (dare I say "Free"?). I do understand that corporations may prefer the definition of "open" which amounts to "we can easily accept other peoples' bugfixes, and yet maintain total control".

          ...if you are talking about the process, I have no argument; it's closed

          Well, that's the basic point I was making. It's closed enough that even "Open" sourcing is a huge step, and Free Software is still basically precluded by the JCP rules. Given that, the software produced by the JCP can't ever be "open" in the most essential meaning of that term.

          • public review in September 2001

            JSR80 started in Sep 2000. Look at its web page [jcp.org], that is what I meant by check your facts. In fact, it was being developed internally since 1999. Just because it wasn't public doesn't mean it didn't exist.

            there's an argument to be made that the essence of "Open Source" has a lot more to do with open development process

            I agree. So why are you bashing JSR80? The expert group had no choice (read the JSPA [jcp.org] and/or IEPA [jcp.org]) on when to make the docs/code public.

            "we can easily accept other peoples' bugfixes, and yet maintain total control".

            I don't know where you got the idea that either the CPL [ibm.com] or javax.usb itself somehow "maintains total control". Like any other OSS/FS project, we control our copy of the code and anyone else is welcome to use, contribute, and even fork it if they want. How exactly could a corporation "maintain total control" over code under an OSS or FS licese anyway?

            Free Software is still basically precluded by the JCP rules.

            Only the API "belongs to Sun". Yeah, that sucks. But the RI and TCK, and any other implementation, can have any license they want (if I read Sun's announcement correctly). And the API should be difficult to change, since by definition APIs shouldn't bounce around. However it's quite changable, the expert group just has to have a mainentence review and update it.

            You should really read up on how the JCP works [jcp.org] and things may be clearer to you.

  • We will fund the program at or above a rate of at least 30 efforts per year (current value of approximately $1M) for at least the next 3 years.

    What happens in three years if Sun decides to discontinue the program? This smells of Sun "buying time" so that everyone will quit complaining. I am glad Sun is accomodating OSS, but I do not see a long term solution to the problem in Sun's proposal.


    Greg

  • Jboss certification (Score:2, Interesting)

    by chicoy ( 305673 )
    This is a step in the right direction. Apache made a stance and stood their ground. Sun gets sick of everyone's complaints - so they listen (plus I wouldn't mess with Apache).

    Now that Sun-Apache is better (not perfect), can Sun PLEASE solve the issue with JBoss. They are not as big as Apache, yet, but the certification of an open source implementation of J2EE is very important.

    It is not over yet, I think this is very promising, but until Sun 'really' decides where they stand on OSS, Java will continue to get hurt.
    • I think the main reason for Sun to make peace with Apache is the fact that Jasper (Jakarta's JSP engine) is embedded in iPlanet iAS 6.5 as iAS' JSP engine. iPlanet is, especially since it became 100% Sun this week, Sun's official commercial J2EE container.

      Moreover, Tomcat and Jasper are also part of the J2EE reference impl, IIRC.

      Coincidence? I think not. Sun sees Jakarta as a source of cheap, very good technology and can't affort to piss them off too badly. JBoss lacks that status.

      JdV!!
    • It depends what the problem here actually is. JBoss originally claimed that it could not afford the J2EE certification cost that Sun quoted them ... now they are saying that Sun won't certify them at any cost??? Its imposible to get a straight answer... certainly they (JBoss) can't expect something for nothing, if that's the case.

      • Re:Jboss certification (Score:3, Informative)

        by Kerg ( 71582 )
        The JBoss team can afford to get the certification (and have sponsors who were willing to pay for this, and told SUN about it). The problem is that to get certified you need to agree to Sun legal documents that disallows the distribution of source code for J2EE certified products. Hence no Open Source J2EE implementation can be certified. This is the reason Lutris for example chose to close the source for their J2EE implementation. For them it was more important to get certified than to support Open Source development. For the JBoss team the opposite is the case. We will not close the source base just so that we can get a "J2EE Certified" sticker for the product.
  • Comment removed based on user account deletion

Slashdot Top Deals

There must be more to life than having everything. -- Maurice Sendak

Close