The Geronimo team is pleased to announce the availability of our first milestone release, 1.0 M1.

M1 marks the first of many milestone releases to come. This milestone integrates the main container components: Geronimo, MX4J, Jetty, OpenEJB and ActiveMQ. It has been amazing to see our communities come together and show such strong support for Apache Geronimo

There is still much work to be done on this integration and we look forward to fostering more collaboration between our projects to create an even more unified M2.

As this is our first release and bound to draw a lot of attention, we have put together a thorough set of release notes which detail the current state of Geronimo.
http://incubator.apache.org/geronimo/RELEASE-NOTES-1.0-M1.html

We advise that this is simply a milestone release and is not for general use, nor is it any indication of a final release. Our goal with this release is to start out slowly with a base set of functionality and gather some initial feedback that we can incorporate into future milestones.

The binaries can be downloaded from Apache at:
http://cvs.apache.org/dist/incubator/geronimo

Information on Geronimo can be found on the wiki at:
http://wiki.apache.org/geronimo

Specific useful resources include:
http://wiki.apache.org/geronimo/Deployment
http://wiki.apache.org/geronimo/Running
http://www.openejb.org/geronimo.html

Please send comments and feedback to geronimo-dev at incubator dot apache dot org or open an issue at:
http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10220

--
The Geronimo Team

Using Jetty and not Tomcat?

From http://incubator.apache.org/geronimo/RELEASE-NOTES-1.0-M1.html

[GERONIMO-215] - Tomcat integration for Servlet 2.4 (JSR 154) and JSP 2.0 (JSR 152) support

An anonymous reader writes "It sounds like James Gosling's nudging Sun closer and closer toward open-sourcing Java,

http://www.sys-con.com/story/?storyid=44679&DE=1

I've brought up the issue of tomcat integration on the geronimo-dev list. Seeing as how Geronimo is an Apache project, Tomcat integration seemed fitting. But since a number of the Geronimo developers are also Jetty developers, Jetty has been given preference. In fairness, I think the Geronimo plan all along has been, and still is for the 1.0 release, to be web-layer-agnostic: users will be able to plug-in their servlet/jsp implementation of choice. Both tomcat and jetty will be supported equally via a common abstraction mechanism. I'll be glad to see that when it happens.

The thing holding up Tomcat integration is not will but time. We would welcome any volunteers eager to work on it.

Jetty seems a lot nicer to deal with than tomcat, especially if you're embedding it somewhere or using it in any way...

I've brought up the issue of tomcat integration on the geronimo-dev list. Seeing as how Geronimo is an Apache project, Tomcat integration seemed fitting. But since a number of the Geronimo developers are also Jetty developers, Jetty has been given preference. In fairness, I think the Geronimo plan all along has been, and still is for the 1.0 release, to be web-layer-agnostic: users will be able to plug-in their servlet/jsp implementation of choice. Both tomcat and jetty will be supported equally via a common abstraction mechanism. I'll be glad to see that when it happens.

Is ActiveMQ the default JMS provider?

http://activemq.codehaus.org/

Yes. ActiveMQ is progressing very fast and we hope to have it integrated with Message Driven Beans in the M2 release.

-dain

I have always liked , used products from apache group. They are a much better and FRIENDLIER group than bunch of jerks like JBOSS. I hope this kills JBOSS.

First congrats on the Geronimo team for their 1.0 milestone release. It is good for competition to have choices in the open source EJB app server field. That said, I'm surpised at the effort going into this. It seems many people are moving away from EJB, especially entity beans. I like the route JBoss is taking using AOP to offer persistence for POJOs. Meanwhile Geronimo is playing catch-up just to offer EJB. For Geronimo to compete against JBoss, it needs to be more innovative.

Michael Mattox

I agree with Michael Mattox's comment. While its fine to get another J2EE server out there, the Geronimo team also needs to differentiate itself from the rest of the pack. The catchword "free" is not good enough.

I agree with Michael Mattox's comment. While its fine to get another J2EE server out there, the Geronimo team also needs to differentiate itself from the rest of the pack. The catchword "free" is not good enough.

No, but "free" combined with "open" will go a long way, especially when a business-friendly license gives you a J2EE compatible platform to build upon or innovate with.

The commoditization of these containers is already in progress, so the competition becomes service, support and what you can build on top. Like everyone else, I'd like to see the J2EE stack everywhere, sort of like an "application environment dialtone" (I know, I know, dot-com cliche'...) which you can depend on to be everywhere and usable by everyone. Maybe a good analogy is the "httpd of J2EE".

geir

No, but "free" combined with "open" will go a long way, especially when a business-friendly license gives you a J2EE compatible platform to build upon or innovate with.

But which ``open'' is best, open standards or open source? The first being very important to myself and the majority of developers I come in contact with on a day to day basis while the latter, while nice, isn't as important. I would also say that just becasue it's open source certainly doesn't make it more innovative or easier to be innovative with (possibly having the exact opposite effect at first). I think you're certainly right WRT to commoditization which is why I also agree with an earlier post that Geronimo seems kind of late and hasn't done anything to _really_ stand out in the crowd, but that's probably a little premature at this point.

But which ``open'' is best, open standards or open source? The first being very important to myself and the majority of developers I come in contact with on a day to day basis while the latter, while nice, isn't as important.

That’s because the latter doesn’t affect you directly, it affects the market. Both are needed for true innovation and evolution.

An open standard helps create a market, while a standard implementation helps the market move beyond that point. Innovation comes when people have more resources to invest in being different.

With a business-friendly implementation out there, vendors have the choice to adopt it and re-channel their resources from spec compliance to extending the QoS of their platforms in new directions.

Open source accelerates the natural commoditization of software. Whereas GPL style license leave business high and dry, BSD style licenses give them something to fall back on and ground to build on.

This is exactly what happened with HTTPd and will hopefully happen with J2EE.

Cheers,

David Blevins

That’s because the latter doesn’t affect you directly, it affects the market. Both are needed for true innovation and evolution.An open standard helps create a market, while a standard implementation helps the market move beyond that point.

I don't argue that point, but it seems that we've had both for some time now so I'm not sure what the benefit is here.

Innovation comes when people have more resources to invest in being different.With a business-friendly implementation out there, vendors have the choice to adopt it and re-channel their resources from spec compliance to extending the QoS of their platforms in new directions.

Doesn't the extension of the platforms in new directions run counter to standardization ergo making innovation and evolution impossible since you stated above that they are _both_ needed ;-) I'm just kidding, I understand what you are trying to say. I will profess ignorance regarding GPL, how does it leave businesses high and dry?

I'm just kidding, I understand what you are trying to say. I will profess ignorance regarding GPL, how does it leave businesses high and dry?

If Eclipse was GPL for example, vendors other than IBM would not be able to offer products founded in it without loosing control of the licensing of their product.

The magic of Eclipse is that it can offer a common IDE which vendors can extend in creating tools specific to their systems that integrate seamlessly with the IDE and other tools in the IDE. It's really fantastic.

Geronimo can offer the industry the same thing for vendors of J2EE related products and tools.

Just as with Eclipse, the magic of Geronimo is in the ability to extend the idea of sharing beyond the open source world and into the commercial world too.

Imagine a world where the IDE and App Server are standard and the innovation of commercial software can build on the next level. We're getting close.

-David Blevins

Imagine a world where the IDE and App Server are standard and the innovation of commercial software can build on the next level. We're getting close.

So I am right back in the world where I need to pay through the nose $100,000 per CPU to be able to take advantage of "innovation". No thank you. I hope we never get there.

Imagine a world where the IDE and App Server are standard and the innovation of commercial software can build on the next level. We're getting close.

So I am right back in the world where I need to pay through the nose $100,000 per CPU to be able to take advantage of "innovation". No thank you. I hope we never get there.

Only for a short while till the "$100,000 innovative" software is eventually standardized and then commoditized. It's the cyclical nature of evolution.

We need this cyclical expanding and collapsing for a healthy economy.

-David Blevins

Only for a short while till the "$100,000 innovative" software is eventually standardized and then commoditized.

It took quite a while for you guys to adopt J2EE, much of it seems passe by now. I don't want to wait for the bread crumbles of someone else's innovation for few years only to find all the exciting technology being developed elsewhere, innovated behind closed doors.

I guess we have to agree to disagree. Your vision is not matching my perceived reality.

Cam, your "perceived reality" doesn't seem to match actual reality. In fact, people who productize BSD-style open source tend to donate the majority of their code changes back into the open source. The items that are kept in-house and closed tend to be a small percentage of the overall effort. And in many cases much of the closed functionality is focused on a very narrow niche - vendor hardware, or a tight vertical, or something similar.

The important thing is that what to contribute remains the business' _choice_. They understand that the license gives them the flexibility to decide what makes the most sense to them. Which lowers barriers tremendously. A company like IBM can contribute tens of thousands of lines of commodity code to something like Apache or Linux and not be forced to give away hooks into their proprietary stuff that they'd like to keep closed.

GPL takes away this choice - it's a take it or leave it proposition for many companies. You can either choose to not sell your work, or sell it open up all of the changes you made to the original base (plus any extra stuff you add in). The real result is that many companies refuse to contribute to GPL works, because their choice is limited. Or if they do contribute to GPL it is tightly limited and controlled to ensure that they don't inadvertently give away the keys to the kingdom (or become forced to).

From the people who make the biggest difference in open source - that is, the people who write code - they are the most constrained by a GPL license. And thereby most likely to be adverse to using it. GPL removes choice for developers.

Yes, in a BSD world some companies will make wholesale revisions and keep them secret. Some companies will donate a lot but keep alot as well. But in the end, in practice, this effect isn't nearly as negative as you perceive. Many developers, and corporations, are afraid of GPL because it limits their choices. Worse - GPL limits your choice on what to do with your own intellectual property that you own. GPL advocates respond to this by saying "If you don't like the license, then don't use the code". Well, guess what Cam - alot of companies choose to do exactly that, and the result is the industry as a whole suffers.

Feel free to cite Linux and JBoss et al as GPL success stories. My response to those will be simple - imagine where these projects would be if they were _not_ GPL licensed. Here's a hint: they would not be closed-source $100,000-a-pop products. Instead, they'd be even richer products because so much fear and misunderstanding was removed from the equation.

    -Mike

Whoops, retract that "..and Linux" part :-)

    -Mike

kindof defeats your whole argument.

Where are the successful BSD style licensed products? I mean successful in the business sense, there are many good and useful applications that use BSD style licenses. Apache httpd? that's a simple program. It does happen to be the best. How about the tens of thousands of lines of donated code?

What does a BSD world look like? The only person who talks about a "GPL world" is Richard Stallman and his fans. There are millions of others contributing code to GPL products. Do you suggest that people choose GPL products on only the merit of the code itself, but would prefer to use BSD licensed products, if only the maintainers were talented enough to surpass GPL code in quality.

For the record, I have nothing wrong with BSD or BSD style licenses. But some people have an attitude that I don't like. I'm a firm believer that GPL products (like Linux and JBoss) are not better because of the maintainers skill or personality, but that there is something about the GPL that draws mindshare. Both from closed source businesses and unwashed idealist programmers.

Where are the successful BSD style licensed products? I mean successful in the business sense, there are many good and useful applications that use BSD style licenses. Apache httpd? that's a simple program. It does happen to be the best. How about the tens of thousands of lines of donated code?

What an odd question - no, I mean that. Your focus is "successful in the business sense". How strange. I'm releasing stuff now under a BSD style license because I think it's useful and want people to use it. My intent isn't to build a business around it. I know others that think and act the same way - they release their work under BSD because they want it to be released out into the wild without strings attached. If people want to take the code and "productize" it, fine. If a community grows up around it, fine. If a corporation feels that paying employees to partially contribute (and maybe partially keep some things in-house), also fine. This is explicitly their choice.

I realize that some companies, like JBoss and others, want to build businesses around open source. And frankly, I don't care. I am not into open source as a business venture, and I care not one iota how other people might try to make money off of my code. I'd just like to see people use my code, period. How to make money off of it is a side issue at best.

For the record, I have nothing wrong with BSD or BSD style licenses. But some people have an attitude that I don't like. I'm a firm believer that GPL products (like Linux and JBoss) are not better because of the maintainers skill or personality, but that there is something about the GPL that draws mindshare. Both from closed source businesses and unwashed idealist programmers.

LOL! Many closed source businesses won't go near GPL/LPGL source code because of the license - they'll use the binaries but won't go near the source itself. And you hit the nail on the head on the latter - idealist programmers. A whole bunch of idealistic people who've fallen in love with Stallman's notion of "free" and see some hippy tie-dyed world of peace and love and sharing. Poll 100 developers who have released code under GPL and 75 of them won't be able to cogently describe the license. And 25 out of that 75 will live under the illusion of "protection" that Gavin has professed here - they believe (L)GPL protects them in ways in which it fact does not.

I won't argue your other point in detail - "....are not better because of the maintainers skill or personality" - because it's so divorced from reality. Skill and personality are what makes or breaks a project. The open source landscape is littered with thousands of worthless GPL projects.

And BTW - there are not "millions" of GPL contributors. I would be quite surprised if the number passed 25,000 world wide. World-wide there are probably far fewer than 50 million programmers in total. And of all of those programmers, far fewer than 1% contribute to open source projects. Go to a random company's IT department, and poll all the developers there to see who contributes to an open source project. In many firms you'll find _zero_ programmers who contribute to open source.

    -Mike

kindof defeats your whole argument. Where are the successful BSD style licensed products? I mean successful in the business sense, there are many good and useful applications that use BSD style licenses. Apache httpd? that's a simple program. It does happen to be the best. How about the tens of thousands of lines of donated code?

How many commercial products written in Java are not using at least on liblary from Apache?

What does a BSD world look like? The only person who talks about a "GPL world" is Richard Stallman and his fans. There are millions of others contributing code to GPL products. Do you suggest that people choose GPL products on only the merit of the code itself, but would prefer to use BSD licensed products, if only the maintainers were talented enough to surpass GPL code in quality. For the record, I have nothing wrong with BSD or BSD style licenses. But some people have an attitude that I don't like. I'm a firm believer that GPL products (like Linux and JBoss) are not better because of the maintainers skill or personality, but that there is something about the GPL that draws mindshare. Both from closed source businesses and unwashed idealist programmers.

Do you really think that if something is popular it means that it is better?
So you are very wrong! There is big amount of people using GNU Linux which have no idea what GNU means. They use it becouse it's the most popular (less then 5% of the market) free alternative to MS Windows. If FreeBSD were now in place of Linux most of those people would be using FreeBSD without any deeper reflection. Simply becouse they don't care.

Michal

Do you really think that if something is popular it means that it is better?So you are very wrong! There is big amount of people using GNU Linux which have no idea what GNU means. They use it becouse it's the most popular (less then 5% of the market) free alternative to MS Windows. If FreeBSD were now in place of Linux most of those people would be using FreeBSD without any deeper reflection. Simply becouse they don't care. Michal

The thing is, most of these people don't HAVE to care. GPL/LGPL only comes into effect in distribution. The majority of programmers live in IT land where there generally is no distribution of code.

Somebody write a BLOG or something on GPL/LGPL vs. BSD so we can continue this interesting discussion under an appropriate title.

Bill Burke :

The thing is, most of these people don't HAVE to care. GPL/LGPL only comes into effect in distribution. The majority of programmers live in IT land where there generally is no distribution of code.

This is what scares me. There are many instances where you might build something with a "keep it close" business model - say an ASP model or the like. But what happens when you want to productize it? If you weren't careful about the licenses of the software you built with, you could be in for some nasty surprises. I'd hate to be a CTO/VPEng/etc that had to tell the CEO that her great addition to the business plan has to be tabled until the software was rebuilt to remove licenses we didn't know was in there or simply understand.

Somebody write a BLOG or something on GPL/LGPL vs. BSD so we can continue this interesting discussion under an appropriate title.

I'll be happy to and post back w/ a URL.

geir

Bill Burke :

The thing is, most of these people don't HAVE to care. GPL/LGPL only comes into effect in distribution. The majority of programmers live in IT land where there generally is no distribution of code.

This is what scares me. There are many instances where you might build something with a "keep it close" business model - say an ASP model or the like. But what happens when you want to productize it? If you weren't careful about the licenses of the software you built with, you could be in for some nasty surprises. I'd hate to be a CTO/VPEng/etc that had to tell the CEO that her great addition to the business plan has to be tabled until the software was rebuilt to remove licenses we didn't know was in there or simply understand.

Somebody write a BLOG or something on GPL/LGPL vs. BSD so we can continue this interesting discussion under an appropriate title.

I'll be happy to and post back w/ a URL.geir

http://blogs.codehaus.org/people/geir/archives/000697_licensing_bsdderived_vs_gpllgpl.html

Maybe the TSS can start a new thread for us?

The thing is, most of these people don't HAVE to care. GPL/LGPL only comes into effect in distribution. The majority of programmers live in IT land where there generally is no distribution of code.

Sounds simple. There's only one problem - define "distribution" for me. When are you not distributing, where are you distributing, and where exactly is the line?

This may seem silly and pedantic, but it's not. LGPL fails to define what "distribute" means, and in a number of situations the interpretation is murky.

Let's say I still worked for SIAC, a subsidiary of the NYSE. I modify some LGPL and a release of that is used in SIAC _and_ by NYSE people. Is exposing it to the NYSE people distribution? On one level you can say SIAC is owned by NYSE, in another you can consider them seperate entities.

Now - what if a piece of that same software makes its way to running a web site that non-NYSE people can access. Maybe it's for a fee, maybe it's not. Is this "distribution"?

Now imagine the same software is offered as part of an explicit fee-based service to exchange members - but it's hosted at SIAC. Is this distribution?

Now imagine, say, Merril Lynch wants to host the service locally on its own machines. Is this "distribution"? Probably - but this differs from the prior example only in who's hosting the software.

The LGPL is written in terms of someone making a binary available - an executable or an object library - and tells us that if such binaries are available then the source must be available, too. But just like the definition of "linking", this is a pretty naive approach given how software works today. Does a web site made available to non-employees of my firm which runs with modified GPL code subject to the GPL distribution clause? That's a tough call. What if part of the code is an applet downloaded to the user's browser - if the previous example was not distribution, does this example become distribution because of a technicality of where the code is running? If I host it, is it distribution? If I give it to someone else to host, does the technicality of where the code is running arbitrarily dictate distribution? If I FTP a .jar file to a NYSE server, is that magically distribution? Does the tightness of corporate relationships dictate when you're internal and not distributing? If so, where's the magic cut off point where you're no longer tight enough? Can I form a paper consortium and get companies to join it to get around this rule via a technicality?

This is the fundamental problem with LGPL - it uses outdated terms and makes assumptions that do not necessarily apply to common cases. It's written in terms of 1980s software technology which don't apply to how software works today. It contains a great deal of uncertainty that's open to interpretation on both sides. This sort of uncertainty is what makes IT people nervous - what seems to be a no-brainer where you could modify GPL scot-free isn't necessarily the case if you look at it a bit more closely. As Geir says - the nightmare is that you create a system which starts out as "internal" but you cross the threshold without realizing it - or you want to cross that threshold and find that you cannot.

    -Mike

Both GPL and BSD serve valid tho' different purposes, but Mike raises an interesting point about distribution. Infact, MySQL's Open Source license specifically states:

"Free use for those who never copy, modify or distribute. As long as you never distribute (internally or externally) the MySQL Software in any way, you are free to use it for powering your application, irrespective of whether your application is under GPL license or not."

So although the GPL may not be specific on this issue, with respect to MySQL at least, it is practically impossible for you to use it in a corporate environment without a commercial license.

The point about distribution isn't interesting at all, it's defined by copyright law. Distribution isn't defined in any open source license because it's unnecessary. You can even go read the definition of copyright in a legal dictionary to see what I mean. For example, from dictionary.law.com, copyright is defined as "the exclusive right of the author or creator of a literary or artistic property (such as a book, movie or musical composition) to print, copy, sell, license, distribute, transform to another medium, translate, record or perform or otherwise use (or not use) and to give it to another by will." This stuff works exactly the same way as it would for closed source software, books, music, etc. If it confuses you, you should probably go talk to your lawyer about it, because it's relevant in far more places then just open source software.

OK Chris - tell me how software works "exactly the same way" for closed source software. Knock yourself out explaining how an Osmon song and 50,000 lines of source code can be treated in the same manner.

Sorry if this confuses _you_.

    -Mike

I said the term "distribution" works exactly the same way. When dealing with copyright law it's a legal term with a well defined definition. Trying to claim that any license is confusing because it doesn't define the term "distribution" is silly, it's unncessary to define it, it's built into the laws themselves.

Oh, and an Osman song and 50,000 lines of source code would work exactly the same way under copyright law. You can't redistribute either of them without permission. Want to know if what you're doing is considered distribution? I'd suggest talking to a lawyer or reading the relevant laws.

Either way, "what is distribution" is not particularly interesting, it's the basis of copyright law and is very well defined.

If you decide to reply, please don't attempt to confuse the issue by taking what I saw out of context again.

I don't concur, Chris. Copyright defines things like fair use - and tends to define this in the sense of "public" distribution. On fair use of copying computer programs and similar materials, you're allowed to create archive copies and that's about it.

For additional rights, you have to go to the author and get permission, which often involves a license or contract of some type. That license or contract defines what you can and cannot do - including "distribituion" and usually a definition of it. In the absence of such clauses, you fall back on copyright law - which says you can't do much of anything with specific authorial permission.

Copyright law defines the limited things you can do with a copyrighted work without the author's permission. For anything else - it says go get the author's permission. Now - you're telling people to go to copyright law to tell them what the definition of "distribution" is, but copyright law tells us to go to the author to define it so we know exactly what rights the author is granting us.

Now in GPL/LGPL, FTPing a copy of a program from one subsidiary in a corporation to another may be considered "distribution". Or use of a piece of a program which serves up pages on a public web site might also define distribution. If we default to copyright law, as you suggest, then it seems to me that Bill Burke is badly mistaken and all sorts of individuals and groups may be "distributing" without realizing it - if you want to stick strictly to copyright. In particular by modifying the source and deploying code all over the place they are certainly doing alot more than making archival copies :-) Note that you can do more than just archival copies (like deploying servers) with most software _because the license and/or contract specifically states this_.

BTW this is a good link to start with on copyright law: http://www4.law.cornell.edu/uscode/17/ch1.html.

I'll leave you with:

Trying to claim that any license is confusing because it doesn't define the term "distribution" is silly, it's unncessary to define it, it's built into the laws themselves.

Go read some licenses and contracts, Chris. You will fine they very, very explicitly tell you what you can and cannot distribute, and how. Such a license might say "You can deploy this on up to 10 CPUs in production. You can use "N" copies in development. You can't do anything else with it except that which is defined by copyright law" - which is basically fair use and things like archival copies.

    -Mike

The difference between "Stallman GPL" and "MySQL GPL" is even greater than between GPL and BSD so there is not much use discussing without being specific.

You could call the MySQL version "commercial GPL".

It would be interesting to ask Stallman what he hates the most! ;)

You can not dismiss the GPL/LGPL license just because there are border cases. Border cases will always exist in law or contracts, as everywhere else in life.

Regards
Rolf Tollerud

The difference between "Stallman GPL" and "MySQL GPL" is even greater than between GPL and BSD so there is not much use discussing without being specific.You could call the MySQL version "commercial GPL".It would be interesting to ask Stallman what he hates the most! ;)You can not dismiss the GPL/LGPL license just because there are border cases. Border cases will always exist in law or contracts, as everywhere else in life.RegardsRolf Tollerud

It IS quite ironic isn't it? Poor Stallman. I bet he never thought (L)GPL would be key to an open source business model. What's even more funny is that you have people that pay to not live in Stallman's view of the world.

the people who write code - they are the most constrained by a GPL license. And thereby most likely to be adverse to using it.

Just looking at the success of Linux and all the related software written on the GNU platform and the open source landscape in general makes the above statement appear quite ludicrous.

My response to those will be simple - imagine where these projects would be if they were _not_ GPL licensed.

I don't have to imagine. OpenBSD. Hardly a success compared to Linux and the related Linux business.

Yes, Linux is successful. But you could make a very, very strong case that Linux would be a better platform were it not GPL. That is my point. It's not that you can't succeed with GPL, or you will succeed with a BSD license - that's silly (and saying Linux success proves something about GPL is meaningless). My point is that GPL biases and constrains in one direction, and BSD works in a whole different direction. And I believe ultimately that the BSD style is the one that is best for the industry as a whole.

As for the "GNU platform" - give me a break! Most software written directly under the GNU auspices suck, to put it mildly. The biggest success under GNU was gcc - which was always more of an experimental compiler than anything else.

I don't have to imagine. OpenBSD. Hardly a success compared to Linux and the related Linux business.

If you think Linux succeeds because of GPL you're very, very mistaken. Linux succeeds solely because of Torvalds, and his attitude of ignoring the GPL when it's convenient to him (and just about any legality :-).

You may not wish to concede it (or realize it), but there are companies that don't work on Linux because it's GPL. Just like there are companies that won't work on JBoss because it's LGPL. It's a fact, a reality. This phenomenom does not occur with BSD-licensed software.

    -Mike

If you think Linux succeeds because of GPL you're very, very mistaken.

Sure, whatever.

Developers don't want to get screwed any more than anyone else does. That means big IBM taking their code and making million bucks off of it without giving anyone else (including the original developers) an equal chance to compete.
Gavin King makes this point very clear in his post. Many open source developers agree.

So Linux's success has very much to do with the fact that it is under GPL license. Developers are comfortable participating in it, and that creates the positive feedback loop.

There's a lot of idealistic "cyclical evolution" theories with BSD license but the reality speaks differently. The BSD license has been around for a long time and I can't think of a single project that I could point to for an example of this happening. I can't see any revolution or software "innovation" with BSD style licenses, no positive feedback loop from closed source back to the open source, etc. No "next level of software development" nirvana. Nothing. The biggest thing around is probably Apache's HTTPD and there's no innovation happening there. None. It's a stagnated project and it is not going to suddenly jump to the "next level" because some company was able to innovate on it behind closed doors and years later decides to throw a bone of that work for the rest of us to gnaw on.

And I do believe there's a simple reason for this. There is no incentive with a BSD license to make this cycle emerge. Without that incentive, nothing will happen.

Cam: Developers don't want to get screwed any more than anyone else does. That means big IBM taking their code and making million bucks off of it without giving anyone else (including the original developers) an equal chance to compete. Gavin King makes this point very clear in his post. Many open source developers agree.

But most open source users and developers aren't in it "for themselves" -- they are working for businesses. So while they are "developers," they are also "employees" and their main goal is to find solutions to problems while avoiding downsides like legal liability. They don't contribute to GPL codebases because they can't legally use GPL codebases, and quite often they can't use LGPL codebases either.

BSD etc. is a palatable option for most businesses to both use and contribute to, even though (as Gavin points out) it's not a way to protect what you release as "open source" from being used by others outside of the realm of open source.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

From the people who make the biggest difference in open source - that is, the people who write code - they are the most constrained by a GPL license. And thereby most likely to be adverse to using it. GPL removes choice for developers.

I don't agree with this. I am a developer, and I can tell you that if I had to contribute some code (even something as small as a bug fix) to an open-source project, I would be comfortable doing it only in a GPL context. People don't want to work for free.

On the other hand what you are saying the GPL not working for _companies_ is definitely true.

But you have to look at history. When IBM decided to spend $1B on Linux, it was because Linux was already a great product, and it became that through small, fine-grained efforts by _individual_ developers. BSD has existed for a while, but it never became as big as Linux, and the reason is probably that people don't want to write code for free which other people will later sell and basically misrepresent as their own.

Personally, I think the issue of BSD vs. GPL depends on the nature of the software in question.

I don't agree with this. I am a developer, and I can tell you that if I had to contribute some code (even something as small as a bug fix) to an open-source project, I would be comfortable doing it only in a GPL context. People don't want to work for free.

I don't follow you - people make money off of other's GPL contributions all the time. RedHax does it directly, JBoss does it indirectly, mySql does it through agreements.

The difference is this: if you write some GPL code and someone wants to expand it in any way, _you_ are trying to control _other_ people's IP and how they use it. GPL vs. BSD isn't about how people use _your_ code - it's about how you interact with _other people's code_.

When you release under GPL, you are trying to dictate terms in how other people release their software.

But either way - BSD or GPL, people can and will make money off of it without you getting a dime.

When I've released my own stuff under BSD, I do it with the expectation that other people will use it, even make money off of it, and have no obligation to me. Why should they have an obligation to me? That's the whole point, to me, of open source - it's not about obligations, it's about openness. GPL, to me, isn't about openness, it's a lame attempt at controlling other people's IP. It's certainly not about protecting your own IP - it does nothing there that plain old copyright doesn't.

    -Mike

When you release under GPL, you are trying to dictate terms in how other people release their software.

Mike, I have seen this argument in a few places, but never really understood it. Can you explain how the GPL dictates terms concerning how you release software? I am not trying to bait you, I just don't understand the statement well. I probably agree with you, I just haven't rationally digested the idea yet.

 Can you explain how the GPL dictates terms concerning how you release software?

Sure. The GPL requires that if you:

   a) modify the source to a GPL-licensed codebase, and
   b) "distribute" your modified version

...then part of your distribution must be source code. In the simplest terms, it requires that any mods to GPL code must be released in source form.

On the surface, that may seem fair enough. OK, I twiddle Joe's GPL code a bit, so I must release the twiddled version. That doesn't seem too objectionalable.

The problem is, is that the GPL has poorly defined limits to this requirement - on purpose :-) For example, let's say I wanted to upgrade JBoss to do true distributed transactions and to implement full XA recovery. In order to do so, I must modify existing JBoss code, plus write a non-trivial amount of code myself. If I went ahead and did such a thing, I would own all of my new code, and points of intersection (e.g. modified files) would in one way or another be a jointly owned thing. But here's the thing - even though I own all of the code I wrote, since JBoss is GPL (well, LGPL but that doesn't matter in this instance) the license requires me to release all of the source for this change if I "distribute" it. JBoss Inc. doesn't own the code I wrote, but their license terms dictate how my code must be distributed. They are telling me how I must release my own property.

Now let's say I already have a giant chunk of code that I want to integrate into a codebase like that. To integrate it, I'd need to modify some classes of theirs and then include my own (and maybe even write some bridge classes). Depending on how it's done, and whether we're talking LGPL or GPL, in doing so I may or may not have to release my independently developed chunk of code in source form - even though it was developed independently (maybe even prior to the code base I'm contributing to). If it turns out that I do have to, then the GPL is applying to code that was written before the GPL work even existed (and which still isn't owned by the GPL licensing person or entity). If it turns out I don't, I'll still have to release in source form the changes I made to accomplish this integration, and any bridge classes - even though said code is useless without my larger "Giant chunk of code" work.

The big problem, in my eyes, comes in when there is a large discrepancy in code bases. Let's say I want to pull a GPL-released library directly into my own code base - let's say it's some huge CMS system. For technical reasons, I'd like to pull the library directly into this system and make extensive modifications to it to tightly integrate it into my CMS. Now let's say this library is 10,000 lines of code and took 3 months to develop, and my CMS is a million lines of code that took many man-years to develop. Well guess what? This little 10K line of code library may end up dictating release terms to the million line CMS system. The typical way around this is to either not integrate it, but keep it arms length - which may work, particularly if you're talking LGPL - or to just say "forget it, it's not worth it".

The GPL and LGPL makes all of these items a tough judgement call as well. When are you modifying a work, and when are you keeping it seperate enough that it can't be considered modifying? At what point is there a cross-over between GPL and LGPL (e.g. when do you cross the line from library-style access to not being library style access)? What does "distribute" mean?

Fundamentally, the idea behind GPL is that if you "modify" my code, you must release such mods. The problem is the definition - and scope - of the term "modify". And the fact that person A is telling person B how they can legally treat their code - even though person A doesn't own B's code at all.

    -Mike

JBoss Inc. doesn't own the code I wrote, but their license terms dictate how my code must be distributed. They are telling me how I must release my own property.

This has got to be the worst argument I've ever seen. This is like me saying:

"I made a bike seat. This seat goes on Schwinn bicycles. Now Schwinn is telling my I have to BUY one of their bicycles if I want to sell a Schwinn bicycle with my bike seat attached. They are dictating how my bike seat must be distributed. They are telling me how I must release my own property."

In your example, you identified three codebases:

A) JBoss Code
B) Shared Code
C) Mike Code

You can do whatever you want with C. No copyright license can restrict that in any way shape or form.

Your problem is that you are referring to A and B as 'my code' and 'my property', above. It is not your property. A is their property. B is shared property.

"I made a bike seat. This seat goes on Schwinn bicycles. Now Schwinn is telling my I have to BUY one of their bicycles if I want to sell a Schwinn bicycle with my bike seat attached. They are dictating how my bike seat must be distributed. They are telling me how I must release my own property."

An awful analogy, and I'll tell you why: software does not need to be physically produced in the manner of other goods.

A) JBoss Code
B) Shared Code
C) Mike Code

You can do whatever you want with C. No copyright license can restrict that in any way shape or form.

Sorry Corby, it's you who are wrong here. If the code is not perceived as "linking", but having deeper connections, the LGPL goes all viral on my ass. There are specific situations where "C) Mike Code" would be under the JBoss LGPL license - even though I own the copyright to C.

If you don't understand this, see Gavin's post - he's afraid of people making big mods to Hibernate and keeping them closed source. The implication is clear here - if someone writes 100,000 lines of new code that in Gavin's judgement extends Hibernate's core functionality in a non-linking manner, then it falls under LGPL and must be released.

To be clear - GPL and LGPL are not just about shared works, they are also about entirely new works _of which a portion incorporates GPL/LGPL code_.

Now the interesting part is that GPL and LGPL does not necessarily apply, and I think this is where you're coming from. In particular with LGPL, it all depends in how your code "sees" and uses other code. There are clear cases where you are part of the work and fall under LGPL, and other clear cases where you are clearly not part of the work and not LGPL - and then there's a whole messy middleground where no one really knows. You can have a situation as you outline of A), B), and C) where "C)" would be forced as coming under LGPL, and you can slightly change your coding strategy to define your changes as "linking" and suddenly not be subject to LGPL.

Using Gavin and Hibernate as a guinea pig - if someone adds a significant feature to Hibernate in one manner, he falls under the licensing terms and must release his code as LGPL. If instead he adds some genericity into strategic parts of Hibernate, a few Factories and Class.forName(), then plugs in his closed source implementation against that - now suddenly that plugin does not fall under the LGPL license, only his slight changes for genericity do.

The problem with the LGPL is that the definition of "linking" is so vague that no one really knows what it means in all cases. Some people may subject themselves to LGPL using some LGPL code in the wrong way and not realize it - or may circumvent supposed LGPL license terms by trivially changing their strategy to a linking one. Gavin loses because he does not have the protection he thinks he has - anyone could massage Hibernate to be pluggable enough that they can then plug in the proprietary, closed features that will presumably render him unable to compete. But at the same time, developers could innocently run afoul of the LGPL without even knowing that they crossed some fuzzy technical line.

The end result - fuzziness of the linking clause means Gavin doesn't have the protection he thinks he has. And fuzziness of the definition of "derived works" in open source developemnt means people like MarcF can write threatening lawyer letters to intimidate competing projects.

    -Mike

let's say I wanted to upgrade JBoss to do true distributed transactions and to implement full XA recovery. In order to do so, I must modify existing JBoss code, plus write a non-trivial amount of code myself. If I went ahead and did such a thing, I would own all of my new code, and points of intersection (e.g. modified files) would in one way or another be a jointly owned thing. But here's the thing - even though I own all of the code I wrote, since JBoss is GPL (well, LGPL but that doesn't matter in this instance) the license requires me to release all of the source for this change if I "distribute" it. JBoss Inc. doesn't own the code I wrote, but their license terms dictate how my code must be distributed. They are telling me how I must release my own property.

No - you can release your property any way you want. If you want to release your property as closed source then you are free to do that. You just can't distribute JBoss source code that way.

And you are absolutely right that it's about control. Commercial software is also about control. You control the software by removing the source. GPL controls the software by forcing the source to be there.

Freedom's got nothing to do with it as far as I am concerned.

No - you can release your property any way you want. If you want to release your property as closed source then you are free to do that. You just can't distribute JBoss source code that way.

Welcome to the slippery slope, Guglielmo. Where is the line between my code and JBoss code? Tell me, specifically, the point where code is no longer "linking" JBoss but has more intimate contact with it.

This is a much more difficult problem to figure out then it seems to be.

It's clear that if you modify a JBoss file checked into CVS, then you're doing a derivative work type of thing.

It's clear if I have a library that has nothing to do with JBoss, then it has nothing to do with JBoss.

But when I hook the two things together, tell me precisely where the line is. And tell me who defines what that line is. Gavin seems to believe that commercial companies can't add significant features to Hibernate in a closed source manner - and that idea is directly in contradiction to what you say. Who is right? And if someone's right - where is that line? At precisely what point do you stop linking and step over the line from being "Mike's code" to "JBoss code"? If you give the simple and obvious answer, then LGPL is giving Gavin and many other people _none_ of the protections they think they have against commercial competition - commercial competitors could trivially circumvent the license via linking. If the answer is not the obvious one, then most likely a huge amount of code out there is in violation of various LGPL licenses right now, and other people's intellectual property is at risk without them knowing it.

NOTE: The "obvious" interpration is Stallman's and GNU's and the FSF - they state pretty clearly what they think it is (but neglect to put this clearly in the license), and is particularly interesting in Java's case. And Stallman hates the LGPL because the obvious interpretation means the license can be easily circumvented in many cases - and trivially done so in a language like Java which effectively doesn't have a link step. In a language like Java, one camp or the other is pretty much screwed - either you can trivially link and avoid the license, thus voiding much of LGPL's supposed protection, or you can't trivially link - and suddenly LGPL is way _too_ viral and affects far more code than it's supposed to.

    -Mike

At precisely what point do you stop linking and step over the line from being "Mike's code" to "JBoss code"? If you give the simple and obvious answer, then LGPL is giving Gavin and many other people _none_ of the protections they think they have against commercial competition - commercial competitors could trivially circumvent the license via linking.

Actually I thought that was indeed the case with LGPL - just ship a bunch of jars. And maybe one of the jars that are LGPL requires small changes to allow integration with the commercial code, in which case you make _those_ changes free, and keep the rest locked up.

That should work, right?

Actually I thought that was indeed the case with LGPL - just ship a bunch of jars. And maybe one of the jars that are LGPL requires small changes to allow integration with the commercial code, in which case you make _those_ changes free, and keep the rest locked up.

As other people have pointed out, the LGPL was written with C and C++ in mind. It doesn't have a freakin' clue about Java at all, and gives very few hints on how the C concepts should be transferred to Java.

Here's some examples - you tell me what they mean in a Java context:

When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not.

Try to translate this one into Java - which doesn't have header files, and .class files are quite a bit different in many respects from object files.

If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)

Again, what does this mean in Java land? And what about the sneaky "inline functions (ten lines or less in length)"? And how does "inlining" apply to .class files?

Also troubling, but in a different fashion, is this:

A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.

Please define what "derivative" means in this context. The intent is that you can't copy a piece of an LPGL library into your library. But what does it mean in practice?

Then consider this:

However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.

The intent here is to distinguish between shared libraries and statically linked libraries. If you link so that you use an LGPL library as a shared library, then you don't fall under the license. If you statically link, then you do fall under the LGPL.

What does this mean in Java? Can you draw an analogy between .jar files and static linking? Or do .jar files not count in that manner? Is all of Java acting like a "shared library", and thereby this clause is completely invalid for Java?

Answer to all of the above: beats me. The FSF have presented a number of semi-official guidelines and clarifications on what this means for Java - and these clarifications and guidelines have zero, zip, nada legal binding. What matters is what the license actually says, and what it says is confusing as hell in a Java context.

And of course I haven't even pointed out the worst part about LGPL. Most people do LGPL in such a way that gives the FSF control over the license - not the author of the work. In particular, it says:

13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation.

Hmmm - so an author can specify a version, or not. Either way, the _user_ (not the author) can see fit which version applies to them. So if the FSF released a new version of LGPL which was less restrictive, it would automatically torpedo the few protections it gives authors today.

    -Mike

As other people have pointed out, the LGPL was written with C and C++ in mind. It doesn't have a freakin' clue about Java at all, and gives very few hints on how the C concepts should be transferred to Java.

I was under the assumption that a .jar file is treated like a .so file.

I wish I could chat more but I have to go.

Mike,

I'm confused about the example you gave of adding XA recovery to JBoss.

For example, let's say I wanted to upgrade JBoss to do true distributed transactions and to implement full XA recovery. [...] If it turns out that I do have to, then the GPL is applying to code that was written before the GPL work even existed (and which still isn't owned by the GPL licensing person or entity). If it turns out I don't, I'll still have to release in source form the changes I made to accomplish this integration, and any bridge classes - even though said code is useless without my larger "Giant chunk of code" work.

Isn't it exactly what the Arjuna guys did with Arjuna+JBoss?
They added their MQ and their TM to JBoss without releasing their source code.
AFAIK, their products remain under a closed source license and they didn't have
to relicense them under LGPL or GPL.
Am I missing something?

--
jeff

My previous company had a voice based software product where we wanted to use an open source VXML browser (instead of buying/building one). So we started using an open source project that we knew had heavy contributions from a large company (and knew they needed it and were open source friendly). We assumed that with such backing, the project would likely produce a complete product that we could use, so we started using it in our product.

We were right about the large company needing it, but wrong about it them staying with the project to completion. About half way through, all the contributors from that company were no longer contributing (so the project basically died). My understanding is that this company is going to be releasing the full product for pay. We were then left in a fix because at that point we no longer had the resources to buy or build.

Certainly don’t know if that company would have contributed to the project if it were LGPL, but doubt we would have been stuck the way we were if it had been.

I don't agree with this. I am a developer, and I can tell you that if I had to contribute some code (even something as small as a bug fix) to an open-source project, I would be comfortable doing it only in a GPL context. People don't want to work for free.

On the other hand what you are saying the GPL not working for _companies_ is definitely true. But you have to look at history. When IBM decided to spend $1B on Linux, it was because Linux was already a great product, and it became that through small, fine-grained efforts by _individual_ developers. BSD has existed for a while, but it never became as big as Linux, and the reason is probably that people don't want to write code for free which other people will later sell and basically misrepresent as their own.Personally, I think the issue of BSD vs. GPL depends on the nature of the software in question.

GPL attracts individual developers to contribute, and BSD attracts large companies' investments.

Linux success is one singular case.

It worked in the start because: 1.Linus' effort and capacity; 2.lots of smart developers looking for a feasible alternative to the expensive Unix (then, GPL attracted them).

It worked later, and gained all of its commercial momentum, because the industry (IBM) was desperately fighting Microsoft's monopoly, not because it was GPL.

I don't think that another GPL project will achieve the same success of Linux ever again, because the industry isn't desperate anymore, it doesn't have to submit to the GPL anymore.

So, for now on, the large projects that will succeed will be the ones that brings some advantage for companies. Apache's HTTPD is the best example. It is great because of all the investments made by companies, that can embed it in their own products, without the fear of being sued for license violation.

I think that LGPL is commercial-friendly enough, because it permits embedding without license infringement. But it is a GPL sibling, and many companies fear it too.

At my work, sometimes a nice library alternative is discarded because it is GPL, and it can't mix with commercial software.

Take MySQL for example. More specifically, its official JDBC Driver. Since version 3.0, it's been realeased in GPL terms, what hinder me distributing it with our software. Of course, MySQL AB intention is to force commercial companies to pay for it.

In the end, GPL is being used to force others to pay for using software...

Ronald!

"In the end, GPL is being used to force others to pay for using software.."

You are by far the best candidate for the 2004 Socrates award "Being able to think independently".

And, if you have concerns that your voluntary contribution will be commercialized you have more reason to fear GPL than BSD. With BSD the companies at least has to add something to the software to sell it and other companies are free to compete by doing the same. With GPL the copyright owner(s) can sell the software at any time (with the dual license system) without having to do any modifications at all and they are protected against competition because the people that fork can not do the same.

Regards
Rolf Tollerud

=P

Guglielmo said :

I am a developer, and I can tell you that if I had to contribute some code (even something as small as a bug fix) to an open-source project, I would be comfortable doing it only in a GPL context. People don't want to work for free.

I don't understand this. When you contribute open source software under either the GPL, ASL, MPL, etc, you are usually working for free.

I, or anyone else, can still take your work and make money with it. There are lots of companies that make serious money from Linux, for example.

Even with a BSD-derived license, only through improvement or value-add can someone really make money. You could try and sell people a Jakarta project codebase, for example, but without some improvement or additional service bundled with the codebase, your market would be limited to people that didn't know that you are just re-selling free software that they could also get from Jakarta. And if you did add an improvement or additional service, why isn't what happens to that improvement (in the case of code) *your* choice?

And finally enforcing a real quid pro quo paradigm is the real underlying question behind all these threads...

MySQL CEO - Marten Mickos - wrote a few months ago:
"Our philosophy is one of "quid pro quo" ("something for something". We are very happy to share our source code for no payment with those who themselves are in the free software / open source space. But we also think it is fair for us to charge a payment from those who are not ready to live by the open source licences.

So, in summary our licensing policy is harmful only to the one who attempts to get an unfair benefit of other peoples' work. All the others either fall into the category of open source / free software project or the one of commercial operation. The choice of licence is completely up to the user."

And as Richard Stallman puts it, "Think free speech, not free beer", there is still a big rule missing in all the current open source license(GPL, BSD, Apache, whichever OSI licenses): "being able to enforce a real quid pro quo". Then only contributors may begin getting paid without inventing crazy open source commercial business models by selling services while developing software. Then only you will get rid of technology free riders that only want free (like in free beer) technology without wanting to put their hands in the code or to sponsorize any new developments... Open source projects were initially based on an economic of respect and merits... With the success of certain of them, this paradigm seems to be more and more neglected... Quite a shame as it is (was) the basis of a successful open project. Perhaps time to really enforce the "Think free speech, not free beer"...

Stéphane
www.collaborativesource.org

In real practical terms, the difference between BSD-ish licenses and GPL-ish licenses is this:

If I would have released Hibernate under a BSD-ish license, then by now there would undoubtedly be one or more commercial companies selling forks of Hibernate, competing directly with the Hibernate project. There would be at least one JDO vendor with an implementation based on Hibernate, and probably at least one appserver vendor whose CMP engine would be based off of Hibernate.

Now, consider that a second. I would be competing against these vendors on a completely unequal footing. Any change we made to Hibernate, they could immediately copy. Any new feature they added to their fork of Hibernate, we would have to reimplement by ourselves, completely from scratch. How could we possibly hope to produce a better product?

BSD-ish licenses, are popular with big corporates who sponsor the Apache foundation, etc. But you will see that smaller, independently minded projects very often favor the GPL or LGPL. Why? Because it protects the integrity of the project, and the interests of the original authors.

Anyone can fork Hibernate, anytime. But if they do, they have to make their changes available when they distribute a modified version. And thats just the right balance. It puts me on /equal footing/ with closed-source competitors, so I at least have a hope of competing. And that adds incentive for me and the other guys to keep improving Hibernate.

Hi Gavin,

I think the core principle here is that it's your code and you get to make the choice on how to license it (and people should respect that as your personal choice -- they can go write their own if they don't like it. ;-) Obviously, the Geronimo dudes didn't like the licensing options available (think JBoss and JoNaS) and so they decided to go write their own J2EE app server and release it under the BSD license.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

Cameron: "it's your code and you get to make the choice on how to license it"

Yes but in this case there are small text in fine print that works like the forms con-insurance salesmen makes you sign.

One of the problems with GPL is that for the most part it is not public or exactly clear whom that controls the copyrights. GPL and BSD licenses are just agreements. Copyright laws still rules and the copyright-owners can at any time change their mind and begin to charge money for their software.

If you own 60-70% of the copyrights in a project it is no match to take control over the rest (by persuading, replacing and so on). What is to stop JBoss from suddenly announce that "Tomcat is now coming with a dual license system"? If I am not wrong Marc sometimes ago commented that he controlled 40 percent or something, he only needs to hire one or two more of the important developers, and then he is in business.

Regards
Rolf Tollerud

Rolf Tollerund:

Cameron: "it's your code and you get to make the choice on how to license it"Yes but in this case there are small text in fine print that works like the forms con-insurance salesmen makes you sign.One of the problems with GPL is that for the most part it is not public or exactly clear whom that controls the copyrights. GPL and BSD licenses are just agreements. Copyright laws still rules and the copyright-owners can at any time change their mind and begin to charge money for their software.

Yes, but only for future changes. Any copy that has been placed 'out there' can't be retrieved. This is a source of much FUD that gets thrown at the BSD-ish licenses. (I'm not suggesting you are doing this, but it gave me an opportunity to speak up...)

IOW, I've heard the spin that BSD-ish is bad because the copyright owner can just stop distributing open source versions, but this is true with GPL as well. MySQL AB does this - they offer both an open source licensed version (GPL) and other kinds of licenses.

If you own 60-70% of the copyrights in a project it is no match to take control over the rest (by persuading, replacing and so on). What is to stop JBoss from suddenly announce that "Tomcat is now coming with a dual license system"? If I am not wrong Marc sometimes ago commented that he controlled 40 percent or something, he only needs to hire one or two more of the important developers, and then he is in business.RegardsRolf Tollerud

Mark was apparently "misquoted" by the press when he said that. JBG hasn't offered a clarification, though.

JBG already has hired Remi, one of the major developers on the Tomcat project now.

But the copyright for the entire Tomcat codebase is owned by the Apache Software Foundation. Individual contributors own their contributions that are specifically theirs - they grant copyright to the ASF for a copy, and they still have copyright to a separate copy, if you will - but except for brand new contributions, this generally consists of patches that are worthless w/o the code that is being patched.

So if you wanted to go fill in the banks around source and patches that you had clear copyright ownership of, you'd need to somehow implement the base on which your patch is based, something that would probably be impossible to do w/o violating the copyright of the material that you were replacing.

-geir

IOW, I've heard the spin that BSD-ish is bad because the copyright owner can just stop distributing open source versions, but this is true with GPL as well. MySQL AB does this - they offer both an open source licensed version (GPL) and other kinds of licenses.

... another point to consider is that any dual licensed software is perhaps open source but has nothing more to do with "community software". In the case of MySQL, in order to keep a dual license (GPL - commercial), MySQL AB needs to own 100% of the exploitation rights. Otherwise speaking if you want, as a contributor, to add a GPL only extension to the MySQL kernel without agreeing to provide to MySQL AB a free unlimited worldwide,... license to reuse, sublicense, commercialize,... your work, this will never be added to the MySQL kernel. For a bug fix, no problem to accept such conditions, but what if you want to contribute a real major extension?

So yes you may fork MySQL but as the MySQL mark is trademarked worldwide you will have to remove it everywhere in the API (quite a lot of work) and of course you will compete with the 100 employees of MySQL AB to keep a competitive offering. Finally as you will never own the MySQL copyright, you will never be able to dual license it to make some money (= problem of JBoss now BTW ;-)).

So finally the GPL could be also quite close of a standard commercial license especially if you enforce a strong viral effect as MySQL AB is currently doing. So GPL = really free software? Mmmh!

Stéphane

Thank you for the clarification. It seems that Tomcat is not in any immediate danger then. But I have one more question that does not have directly to do with GPL/BSD license but,

Do Sun own all the copyright to J2EE SDK 1.5? Including all the JSRs?
If not does anyone know how many percent of J2EE SDK 1.5 copyrights that belongs to Sun?

If yes how it is possible that Sun has been able to maintain control? Do all of the participants in the JCP community have to assign over their rights to Sun?

Regards
Rolf Tollerud

Thank you for the clarification. It seems that Tomcat is not in any immediate danger then. But I have one more question that does not have directly to do with GPL/BSD license but,Do Sun own all the copyright to J2EE SDK 1.5? Including all the JSRs?If not does anyone know how many percent of J2EE SDK 1.5 copyrights that belongs to Sun?If yes how it is possible that Sun has been able to maintain control? Do all of the participants in the JCP community have to assign over their rights to Sun?

Here's an area where the situation for Java things based on JCP standards gets even more interesting. There is a difference between the license for a *specification*, which is what the Java Community Process (JCP) produces, and the license for an *implementation* of one of those specs.

Copyright for JCP based specs is held by the individual(s) or organiza tion Specification Lead for the corresponding JSR. Thus, if you download the spec for J2EE 1.4, for example (http://jcp.org/en/jsr/detail?id=151), you'll see that the spec is copyrighted by Sun, since Sun was the spec lead. On the other hand, a JSR like "Implementing Enterprise Web Services" (JSR-109) is copyright IBM, since IBM was spec lead there. Owning copyright for the specification is one of the compensations for the non-trivial cost of being a spec lead (since this organization is obligated to provide the spec itself, a Reference Implementation (RI) that implements it, and a Technology Compatibility Kit (TCK) that can be used by others to test their implementations.

An implementation of J2EE, as with implementations of any JCP spec, must pass the corresponding TCK in order to comply with the usage restrictions in the spec license. However, the license under which the implementation itself is distributed is up to the owner of that code. Thus, we see commericial software licenses on many J2EE-compatible app servers (Sun, IBM, Oracle, BEA, ...), but we'll also see (once they pass the TCK) distributions under the Apache license (Geronimo) and GPL (JBoss) as well.

So if Sun wants to include a JSR into Standard Java they have to do a clean room implementation of the spec? And pay actual money for the TCK? :)

The licensing fee is one of the ways that Sun realizes income on Java. I sure like to know how much that is yearly. But my guess is that we will never know..

By the way, has Geronimo received the TCK scholarship yet?

Regards
ROlf Tollerud

By the way, has Geronimo received the TCK scholarship yet?

Yes it has:

https://theserverside.com/news/thread.tss?thread_id=22483

All production Releases of Geronimo will be certified.

Sun have also gone public on pricing for the J2EE1.5 release:

http://jcp.org/en/jsr/detail?id=244

So now we know :)

Thank you Jeremy, for the link!

There are two Compatibility licenses available for commercial users, which include CTS and brand licensing.

Option 1: The CTS (Compatibility Test Suite) will be licensed without the RI, for a flat fee of $350K per year per Marketed Product*. To promote broader distribution of the J2EE technology, companies may elect to pay a Compatibility fee of 2% of Adjusted Revenues* per year, subject to an annual cap of $700K per year per Marketed Product.

Option 2: The CTS and RI with redistribution rights will be licensed for a flat fee of $500K per year per Marketed Product. To promote broader distribution of the J2EE technology, companies may elect to pay a Compatibility fee of 3% of Adjusted Revenues per year, subject to an annual cap of $1,000K per year per Marketed Product.

I would do anything to se Marc Fleury's face when he sees this prices´! :)

We have a saying in my home country that translates to "here goes shame on dry land". The only thing that Sun has done is to prodece the ridiculous EJB 1.0 specification. "Made by aliens" according to Cameron Purdy. Then Weblogic and IBM invest a large amount of time and effort, and costs- and make it usable thanks to knowledge from the practical field. A total rewrite!

Then Sun instead out being thankful slap them with these outrageous license fees! It is comic is it not? The poor vendors probably don't know if they should laugh or cry..

I used to think that Dilbert was an exaggeration. Now I know better.

Regards
Rolf Tollerud

Rolf: One of the problems with GPL is that for the most part it is not public or exactly clear whom that controls the copyrights.

Actually, it is quite clear. GPL is about licensing, not about copyright, and it doesn't change any part of copyright law. The copyright holder maintains their own copyright, period.

Rolf: GPL and BSD licenses are just agreements.

Yup .. @see Locke -- even just being born in a particular country is an agreement. These agreements are what civil society and its markets are built on.

Rolf: Copyright laws still rules and the copyright-owners can at any time change their mind and begin to charge money for their software.

Yes, but if they have licensed it previously under GPL / LGPL / BSD (or any other such license) then whatever they previously licensed cannot be retracted. In other words, you don't have to pay them just because they started charging for it.

Rolf: If you own 60-70% of the copyrights in a project it is no match to take control over the rest (by persuading, replacing and so on). What is to stop JBoss from suddenly announce that "Tomcat is now coming with a dual license system"? If I am not wrong Marc sometimes ago commented that he controlled 40 percent or something, he only needs to hire one or two more of the important developers, and then he is in business.

That's right, JBoss could start charging for a commercial license of Tomcat and they could also release Tomcat as GPL so you couln't link to it without becoming virally infected.

But, as I said above, that would *not* affect any Tomcat users unless they decided to obtain this "new" JBoss product called JBoss-Tomcat instead of the real Tomcat from Apache.

That's because Apache Tomcat would still exist, and still be BSD, and JBoss cannot have any effect on that.

(Note: This has already been done by several companies, such as Borland, which ships Tomcat as its own commercial J2EE app server, and Oracle which shipped JServ as its own commercial J2EE app server.)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

Cameron: "Yes, but if they have licensed it previously under GPL / LGPL / BSD (or any other such license) then whatever they previously licensed cannot be retracted. In other words, you don't have to pay them just because they started charging for it."

Yes yes, they can not start demanding payment for the old installments of course, I am not worried as a customer. But if I was a contributor together with many others I would be greatly irritated if some company took ownership of the "our" code and makes a bundle. That is quite possible. To assign your rights is made to be seen as a mere formality when in fact it is very important. Who have the copyrights is "THE" question.

Regards
Rolf Tollerud

In real practical terms, the difference between BSD-ish licenses and GPL-ish licenses is this:If I would have released Hibernate under a BSD-ish license, then by now there would undoubtedly be one or more commercial companies selling forks of Hibernate, competing directly with the Hibernate project. There would be at least one JDO vendor with an implementation based on Hibernate, and probably at least one appserver vendor whose CMP engine would be based off of Hibernate.Now, consider that a second.

Honestly I doubt it. After all Hibernate is not that excelent.. and all major
players have at least comparable frameworks which are used in their products.

I would be competing against these vendors on a completely unequal footing. Any change we made to Hibernate, they could immediately copy. Any new feature they added to their fork of Hibernate, we would have to reimplement by ourselves, completely from scratch. How could we possibly hope to produce a better product?

Better then what? Better then them?

And what you mean by I cannot "compete with them"?
If you really want you can make parts of your "thing" closed and sell it as others do. Or make the shitty code and sell docs :)
You're position is even better as you control the code ...

BTW: There is nothing bad in making money using somebody's else work.

I am happy when somebody can do this with my work (I am Apache committer).
But to have a chance to do this you must really innovate and BSD like license
is promoting innovations and healthy competition.

We at Apache simply don't object if projects like Hibernate are using our libraries of parts of our code and make improvements.
We don't even care what's will be the license or if project will be open or closed source. That's _open_ source and free software.

For me the difference between BSD and GPL is like between Philanthropy and Communism.
First works and is healthy and second ...

BSD-ish licenses, are popular with big corporates who sponsor the Apache foundation, etc. But you will see that smaller, independently minded projects very often favor the GPL or LGPL.[...]

I haven't seen such process yet...
My company (which is quite small) is not using anything which is released with GPL lic. Most of the other companies which I know do the same.

AFAIK also most of the project @Apache is not sponsored and every project is independent.

Michal

Gavin, you keep using the word "competing" in your post. Perhaps this explains the difference between my outlook and your own. I don't release code to compete with anyone, I release it because it was useful to me and may be useful to others.

If someone takes it and improves it - great! That's the whole point.

You mention a fear that some vendors would take Hibernate and you wouldn't be able to compete. Huh? How does someone taking Hibernate from you diminish what you've already done? If Hibernate were BSD, and someone took it and added a slew of features - guess what? _THEY ADDED THOSE FEAUTRES_ - not you. If you want to add those features to Hibernate - what is stopping you?

The implication here really is that some huge corporation will come in and make changes which open source people could not make - that is truly what your argument comes down to. And a fear that some corporation could do it better than you, sell it for a profit, and out-do your open source version. And for some mysterious unspecified reason open source people would be unable to duplicate this effort.

You also overlook the cost of forking. The reality is that making a big enough fork to make a difference is a significant effort - and a continuuing one. If they wanted to keep taking features from Hibernate as it evolved in open source, that alone would be a full time job - integrating the features and refactorings you produce into forked code. Remember - this mythical multinational company will have made enough changes and added enough value that you're afraid of them. Such change implies that maintaining diffs between their fork and the open source base would be a non-trivial exercise.

Really, I find your attitude confusing. Oh my God, someone chagned my code and wouldn't release their own work! Those bastards!! The whole argument you're putting forth is that these big companies are going to be creating something that you and your team could not - and you want to, more or less, force them to either give you those changes or not use your stuff at all.

    -Mike

How does someone taking Hibernate from you diminish what you've already done? If Hibernate were BSD, and someone took it and added a slew of features - guess what? _THEY ADDED THOSE FEAUTRES_ - not you.

What you could is release the features as a library, and if there are parts where you absolutely to have the source (like an interface, or something), you make those parts as small as possible and you release those as GPL, which is fair because by definition they are minute changes to a large amount to GPL code.

Gavin King :

In real practical terms, the difference between BSD-ish licenses and GPL-ish licenses is this:If I would have released Hibernate under a BSD-ish license, then by now there would undoubtedly be one or more commercial companies selling forks of Hibernate, competing directly with the Hibernate project. There would be at least one JDO vendor with an implementation based on Hibernate, and probably at least one appserver vendor whose CMP engine would be based off of Hibernate.Now, consider that a second. I would be competing against these vendors on a completely unequal footing.

I don't quite believe this, and competing for what? What do you personally lose if I use Hibernate and make money? certainly not the money that I made, as you aren't a) charging for it or b) going after the customer.

As hibernate is released under the LGPL, users like me can simply just incorporate hibernate in their commerical offering. They can build JDO on top of Hibernate (I assume there's no techinical reason why not) and just include the standard distribution. While I don't think it's possible right now for technical resons, they can include Hibernate in an appserver, and just provide the standard distribution.

My point is that the LGPL lets people just use Hibernate as is, and if someone was going to compete against Hibernate by using the Hibernate codebase, if they had no added value, the market would figure it out and they wouldn't last long. If they do add value? Probably good for Hibernate in the long run.

Look at the Apache web server, which is licensed under the ASL, a BSD-license derivative. Even during the bubble, when flinging malformed XML-like bytestreams over the wire was all the rage, who forked httpd? Lots of people built new solutions on httpd, or made a business out of supporting it, but every successful instance of that did it by adding value on top of the core, which people trusted. And as more commercial success was had w/ httpd and httpd-based products and services, the trust and acceptabliity of httpd grew - and thus enabled more commercial success.

I would think that Hibernate would be *stronger* if you had a list of commercial entities that were betting at least part of the farm on Hibernate. It certainly have given people confidence in httpd (>70% of the web at this point) no matter what the source.

Any change we made to Hibernate, they could immediately copy

And right now, we all just take advantage of those features by using it.

Any new feature they added to their fork of Hibernate, we would have to reimplement by ourselves, completely from scratch.

I could build a product that adds features on top of hibernate, and the LGPL lets me do that. I can't see what stops me. I can't do a "deep" feature integration, but certainly a layered approach is ok.

How could we possibly hope to produce a better product? BSD-ish licenses, are popular with big corporates who sponsor the Apache foundation, etc.

Hang on there, Gavin. I'm not familiar with the 'corporate sponsors' of the ASF. Individuals and corporations make *donations*, but it's a non-profit - we need that to survive and provide the infrastructure. And anyway, the LGPL is popular with corporations too. I think this is a rathole that we might not want to explore, given the commercial relationship between Hibernate principals and JBoss Group, Inc.

And addressing the point, of course they are - they are also popular with small ISVs who want to innovate and build new products and services.

<blockqote>But you will see that smaller, independently minded projects very often favor the GPL or LGPL. Why? That's actually a great question, and I'll note that smaller, independently-minded projects also very often favor BSD-ish or other business friendly licenses - I don't think that the "BSD is for large corporations and their benefactors" strawman is valid here.

Because it protects the integrity of the project, and the interests of the original authors.Anyone can fork Hibernate, anytime. But if they do, they have to make their changes available when they distribute a modified version. And thats just the right balance. It puts me on /equal footing/ with closed-source competitors, so I at least have a hope of competing. And that adds incentive for me and the other guys to keep improving Hibernate.

I'd like to see an example of how the LGPL protects "integrity" of a project - maybe a case where the lack of LGPL was the reason for corruption. Corporate influence in opensource seems to be fairly well distributed between *GPL and BSD-ish -licensed projects, so it's unclear what you are referring to above.

-geir

I could build a product that adds features on top of hibernate, and the LGPL lets me do that. I can't see what stops me. I can't do a "deep" feature integration, but certainly a layered approach is ok.

See my slightly earlier post on this, Geir. If you accept the FSF's definitions and clarifications on LGPL linking (which BTW such statements are not legally enforcable since they're not part of the license itself) - anyway, if you accept those definitions, then you could easily bolt any amount of functionality on top of Hibernate that you'd like and not release any of the functionality. Even for deep integration, all that would be required would be for you to insert generic hooks at the right points in Hibernate - and only release those hooks as LGPL, while keeping the code that plugs into those hooks closed source and proprietary.

     -Mike

In résumé:
http://www.oreillynet.com/lpt/a/policy/2001/12/12/transition.html

Great article, Stephane. And it's directly on point to what is being discussed here (despite having a date of 2001).

Of particular interest to me are the quotes:

However, upon further reflection we came to the realization that our perception of software freedom did not harmonize with the copyleft enforcement mechanism. We believed in the freedom of developers to make their own choices about their own efforts. Contributors, not the original author, should decide if and how their own contributions should be made available. Copyleft would preclude such a choice.

This is dead on in my opinion - the original author should not decide how your own contributions should be made available.

Our fear of exploitation was overcome by observing that there is surprisingly little evidence of commercial exploitation, and that commercial corporations actually do contribute voluntarily.
[...]
A main motivation for choosing GPL is to prevent your code from being exploited. But rather than automatically choosing copyleft to prevent that exploitation, it's instructive to look at the issues around that, including whether you mind your code being exploited, and whether your code will gain or lose from developers in corporations using it. Also it's worth considering what it costs a corporation to exploit code, and even how code may benefit from such exploitation.

Again, I concur, and I find your arguments surprisingly close to my own. People fear a commercial exploiting boogeyman that doesn't really exist in practice; corporations do in fact contribute voluntarily and extensively to non-GPL projects; and when exploitation occurs it is not "free" as people like Gavin seem to feel that it is.

But the key point to me is this one:

While the "free riding" does nothing to further our project, it doesn't hinder it either.

The above is the point that so many GPL/LGPL advocates miss completely. In a nutshell - how can someone hiner or damage code that you own by changing it? How do such changes limit the value of your code or otherwise diminish it? The obvious answer is: they don't.

Your comments on costs and benefits of exploitation are also excellent, but too large to quote here, and the same goes for the info on LGPL - I urge people to read the submission in the whole to get a better balanced sense of the real issues here.

    -Mike

In fact, the GPL looks better and better as a business idea IMO, a la MySQL. You just publish a project and if anyone wants to contribute you make them sign over the copyright. Then your code is better protected than even in ordinary commercial software!

So the license that was made to "make all software free" is better used in "good old capitalistic practice". I wonder if Stallman et al though of this? :)

I must see if I have some old software in the cellar..

Regards
Rolf Tollerud

Rolf Tollerud: " In fact, the GPL looks better and better as a business idea IMO"<br><br>

I'll be damned! So you _can_ teach an old dog to sit! :)

Now you are getting it, GPL, BSD et al are not "anti-commercial" licenses, they are simply the next level of competitive dimensions on the free market.
There will no doubt be extremely successful companies in the future built around GPL:d and BSD:d products, as well as probably "closed source" shops.
It has happened over and over in the past and will happen over and over again: the competitive environment changes drastically, the real question is just who will adapt and flourish, and who will bitch and desperately try to hold on to the past while fading away into the corporate grave-yard.

The great majority, I should say 99% of all GPL'ed software at Sourceforge does not meet this requirement: "a good business idea". They have adopted a Laissez Faire policy and neglected to manage the copyrights and it is a hopeless task to collect the rights from all the contributors. I am sure that Linux fall into this category, as well as JBoss and many other famous projects.

So what we are meaning with GPL in "daily speak" is something that belongs to all and everybody and that nobody can exploit because it would be a hopeless task to unite all the contributors. This is the NORMAL GPL- understood without being explicit.

This state is a sad story and in that case the BSD license is a thousands time better IMO, allowing exploitation in the positive sense.

To do as MySQL has done and retain all copyright is extremely rare. This is definitely the way to go if you have a product that is not middleware but is aimed direct to the customer.

This "new GPL" is an entirely different beast that has nothing to do with the normal "idealistic" GPL that is nothing more than "useless good old communist practice."

Even if FSF now has endorsed the dual license system, I am sure that it was not anything they though of from the beginning. Evolution doing its job again!

But of course all old dog GPL people will scream "but it was this we meant from the beginning!". :)

Regards
Rolf Tollerud

I hope for gods sake that the Spring people have been meticulous in this regard. Rod and Juergen has really deserved to earn a little money on Spring.
IMHO.

There is no "new GPL" or "idealistic" GPL and it was never about communism.

Do you know something about communism, are you living in some communist country ?
I contribute for open source sofware and communists killed a lot of people in my country, please do not try to find communism analogies in open source.

There is no "new GPL" or "idealistic" GPL and it was never about communism.Do you know something about communism, are you living in some communist country ?I contribute for open source sofware and communists killed a lot of people in my country, please do not try to find communism analogies in open source.

I think that Rolf was indeed not quite right when he wrote about "useless good old communist practice."
But certainly there is quite a lot of analogies between communism and GPL ideology.

BTW: Don't confuse the communism ideology and theory with its implementation
(communism were never really implemented). They are two very different things.

Many people found and are still finding ideas propose by communism very attractive.

I myself think that ideas proposed by GPL in many aspects are quite comparable and as harmful as those proposed by communists and should be actively fought against.

For example the idea that everything should be based on GPL license
(there is quite a lot of people even lobbing for making lava GPL!!).


I also think that in this disscussion between GPL and BSD camps won't be any winner and we are not able to convince each other. But such discussions are more important for people who have no clue about philosophical background of both camps. And I personally just have a little hope that some of them will better understand what's all about and make a right decision which one of those two is better.

Michal

But such discussions are more important for people who have no clue about philosophical background of both camps. And I personally just have a little hope that some of them will better understand what's all about and make a right decision which one of those two is better.Michal

There is no philosophical background in BSD or GPL licese, it just a ways to sell software. People say a lot of stupid things about communism and opensource, but it does not mean ommunism and opensource is the same.

But such discussions are more important for people who have no clue about philosophical background of both camps. And I personally just have a little hope that some of them will better understand what's all about and make a right decision which one of those two is better.Michal

There is no philosophical background in BSD or GPL licese, it just a ways to sell software.

There certainly is quite a lot of philosophical background in GPL and GPL license reflects well this philosophy:

They even officialy call it "GNU Philosophy"
http://www.gnu.org/philosophy/

People say a lot of stupid things about communism and opensource, but it does not mean ommunism and opensource is the same.

I didn't say that open source = communism. I hate communism but I love open source.

I just said that both communism and GPL have some points in common and are both utopic.

if you read article like this:
http://www.gnu.org/philosophy/why-free.html (Why Software Should Not Have Owners) you will easly find quite touching similarties to Marx and Engels works.

Communism was never never really implemented in any place in the World and on paper looks much better then in pratice. But even as the set of ideas is IMHO very, very wrong.


Michal

.if you read article like this:
http://www.gnu.org/philosophy/why-free.html (Why Software Should Not Have Owners) you will easly find quite touching similarties to Marx and Engels works. Communism was never never really implemented in any place in the World and on paper looks much better then in pratice. But even as the set of ideas is IMHO very, very wrong. Michal

There are a lot of lame articles on inet, but open source *is* implemented in practice and it not about the philosophy or communism. Some people want to find philosophy or art in sofware, but this is not a motyvation to write code in practice.

Communism was never never really implemented in any place in the World and on paper looks much better then in pratice.

IMHO this is an oximoron sentence, right?

The great majority, I should say 99% of all GPL'ed software at Sourceforge does not meet this requirement: "a good business idea".

Why not? cant I just take any open source software out there and sell it (GPL, BSD, whatever) if I want, as long as I distribute the source code? Correct me if I am wrong, but AFAIK, I don't need each and all contributor's OK in order to be able to do it. Aren't source code distribution and price of the software two different and unrelated things?

Regards,
Henrique Steckelberg

Henrique,

We must always compare if it got to be interesting.

Of course you can sell GPL software but don't you think that it is a little difficult when people can download exact same code for free? And if you add things you must give it back so again your presumptive customers can download the new code, inclusive your enchantment. Do you call this a good business idea?

I call it brain-less destruction of a market. You have not only destroyed for yourself, but also for everyone else! If you really want to be idealistic give it away completly!

Compare to MySQL that can give something of value to the customer that no one else can (distributing rights). Should they choose so they can also sell an enchanted "full" version.

So the conclusion is:

Either give it away completely with a BSD like license, or do as MySQL has done. Anything in between is brain-less IMO.

Regards
Rolf Tollerud

In fact, the GPL looks better and better as a business idea IMO, a la MySQL. You just publish a project and if anyone wants to contribute you make them sign over the copyright. Then your code is better protected than even in ordinary commercial software!So the license that was made to "make all software free" is better used in "good old capitalistic practice". I wonder if Stallman et al though of this? :)I must see if I have some old software in the cellar..RegardsRolf Tollerud

GPL "freedom" is not about the money, end user has freedom to modify software and to use his "better" version, but he has no freedom to redistribute or sell this "better" modified or linked version without source code, new code must be "protected" too, it means this code can be GPL only.
"Closed source" library is more "free" than GPL, you do not need to make your code "free" if it is "linked" with "closed source".
It is not about "capitalism", you can sell sofware linked with GPL, but you can not use your license ( "open" or "closed").
BSD is "better" for user, GPL is "better" for author. So both are very good :)

You don't understand the market.

Why would you buy apples from the grocery story when you can go pick them yourself? Or deal directly with the farmer. Contributing to the GPL codebase is like planting an apple tree. Your code is still there, and other people can use it. You have increased the amount of wealth in the economic system, thereby bringing down the price of products. Thereby enabling others the opportunity to increase wealth. There's no guarantee the people who pick apples from your tree with plant more, but you stil get your apples. BSD is like giving away apples. It's nice, but there is no net gain unless someone else decides to plant the seeds.

It doesn't seem logical, but a market system works on surplus. You say "what if there is no surplus", but that hurts a closed system just as much as an open system. If there are no companies with created wealth to give to your system, there is no growth.

Think of a bank loan. Why would you buy money for more than what it was worth? Even more, why would someone lend you money and take a chance of not getting it back if there was nothing in it for them. But you buy the money (plus interest) in the belief that the capital will allow you to create more wealth than the interest. It isn't a closed system. The bank gives you $50,000 and you buy a house. But at the end of thirty years, the bank has $125,000 and you sell the house for $375,000. That's 10 times as much money as the original loan. It doesn't exist just because the government printed it. The money is a representation of created wealth (30 years of your labor) not just inflation.

Aaron, you say Geir doesn't understand "the market".

Well guess what - your statements seem to show a lack of understanding of Intellectual Property, and how it differs from other forms of property. Manufacturing and sales viz a viz supply and demand do not apply to intellectual property. Once code is written there can be no "surplus" of it. It costs effectively zero dollars to re-create. There can be no "shortage" of a given piece of intellectual property. Any attempt to draw an analogy with physical goods will fail and fall flat on its face. Once code is created it takes 0 resources to replicate.

Analogies drawn to the monetary system and things like loans also don't hold. A loan is a contract where someone gives you money and you agree to give them that money plus interest over time. Now - compare this to a BSD licensed code base.

Here's a bunch of source code. It exists. It costs zero dollars to reproduce. How does this compare to a loan? Money has an assigned value which fluctuates according to a fuzzy set of rules. Code has no intrinsic value - and again, costs zero dollars to reproduce.

    -Mike

Why would you buy apples from the grocery story when you can go pick them yourself? Or deal directly with the farmer.

There's all sorts of reasons why you might not want to go pick apples yourself, and all of them come down to economics - generally, apple-picking is a low cost activity, and as long as your time is worth more than an agricultural worker, you'd be better served spending your time on something with a higher economic return than apple picking. That is, unless you enjoy apple picking.

Contributing to the GPL codebase is like planting an apple tree. Your code is still there, and other people can use it. You have increased the amount of wealth in the economic system, thereby bringing down the price of products. Thereby enabling others the opportunity to increase wealth. There's no guarantee the people who pick apples from your tree with plant more, but you stil get your apples. BSD is like giving away apples. It's nice, but there is no net gain unless someone else decides to plant the seeds.

I just don't grok the analogy regarding GPL/BSD and the apple. Why is there a difference? In both cases, your code is still there, and other people can use it. You may or may not have increased the wealth in the system - it does depend on the definition of wealth, but I think that it's fair to say you haven't done that until you can assign a measurable economic value.

It doesn't seem logical, but a market system works on surplus.

Not with software. The marginal cost of software is zero - once you have the program running, you can create as any instances of that program that you wish with no additional material investment.

You say "what if there is no surplus", but that hurts a closed system just as much as an open system. If there are no companies with created wealth to give to your system, there is no growth. Think of a bank loan. Why would you buy money for more than what it was worth? Even more, why would someone lend you money and take a chance of not getting it back if there was nothing in it for them. But you buy the money (plus interest) in the belief that the capital will allow you to create more wealth than the interest. It isn't a closed system. The bank gives you $50,000 and you buy a house. But at the end of thirty years, the bank has $125,000 and you sell the house for $375,000. That's 10 times as much money as the original loan. It doesn't exist just because the government printed it. The money is a representation of created wealth (30 years of your labor) not just inflation.

I think a house is a lousy analogy, becuase you aren't investing capital in order to build wealth, you are actualy tying up capital in a generally risk-free,conservative, investment. Some wealth is created (because real estate valuation increases seem to be greater than inflation), but not by a large margin.

aaron: You don't understand the market.

Nobody does. That's the first law of economics.

aaron: It doesn't seem logical, but a market system works on surplus.

No, a market system works on scarcity. See "The Wealth of Nations."

aaron: The bank gives you $50,000 and you buy a house. But at the end of thirty years, the bank has $125,000 and you sell the house for $375,000. That's 10 times as much money as the original loan. It doesn't exist just because the government printed it. The money is a representation of created wealth (30 years of your labor) not just inflation.

That's an interesting theory. The price of the house is based on supply and demand in that housing market, and may be lower than the original purchase price if (for example) the population in that market is decreasing. There are towns in the midwest with population steadily decreasing, and people don't even bother to sell their homes, they just abandon them. (The same happened during the Great Depression.) Generally though, in the US and many other affluent countries, the steady influx of workers has helped to build property values, giving reason for you to believe that there is some other thing (e.g. "labor") that has contributed to that wealth.

In fact, the theory you cite above is scarily like a paper Engels wrote 150 years ago, which became The Communist Manifesto (with Marx's name on it to boot.) It argued that capital and the industrial capability (e.g. machinery) that it purchased itself was worthless, and the true value came from the labor. In fact, the communist economic theory holds that value only comes from labor.

However, all that said, I don't think that the GPL is a bad thing, and while it is a bit "communistic" in some economic ways, it is not Bolshevistic (what we typically mis-label as "communistic".) The GPL is a natural response to the conditions of the market, and is having a huge impact, which depending on your point of view (Microsoft shareholder? IT purchaser? developer?) might be a good or bad thing. It's hard to suggest though that it has been a negative thing overall, as it introduced choice into markets that were artificially closed by natural monopolizations. In other words, GPL has the ability to re-open markets that "for fee" products could never puncture; consider the operating system (Linux) and database (MySQL) markets.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

I understand what you're saying, Cameron, but I don't think it's very relevant. The fundamental impact of open source in general (not just the GPL) is to greatly increase the available pool of knowledge - captured in the form of code.
This is not a reaction to the market, it's a reaction to people fundamentally wanting to share knowledge. Companies may take advantage of this with a profit motive - but that's a side effect.

The evidence, to my way of thinking at least, clearly points to this. Most of the open source software out there isn't there for any reasons having to do with competition, or markets, or companies locked in an epic struggle. It's there because someone wrote it and wanted to share it. All sorts of people may have dollar signs dancing in the back of their head when their writing such code, but most of them realize that releasing code open source isn't really the avenue to get there all by itself - profits will come from secondary effects, not directly from the code itself.

Look at the lay of the open source land, and you'll find huge numbers of projects at every level and in every niche, and a quickie analysis shows that the open source out there matches the interests and capabilities of the programming population. People are doing what interests them and are sharing it.

This has always been the case, since the very first computers came on-line. People have always been biased to share code. The difference today is that the structure of the Internet and its pervasive makes it ridiculously easy to do such sharing. You don't have to connect to a BBS at 1200 baud, or get a floppy disk with a magazine, or mail away with your SASE. Today you download it with any numbers of tool of the 'net, and away you go.

Yeah, I know this sounds uncharacteristically hippie of me, with echoes of Stallmanesque overtones, but it's really not. I don't see some wonderous future with people wearing too-tight white jumpsuits in a moneyless economy soaring around in their little jet pods. If anything I see it more like Futurarama - more of the same, just with more gadgets. But fundamentally - the easier it is for people to share information (and that's all IP ever is, information) then the more likely they are to do so. And to a large extent corporations are piggybacking along on this and getting a free ride - and the smart people don't care about this (indeed, many are quite happy about it).

The GPL advocates kinda-sorta understand this - but their mistake is that they're trying to force it. They want to force a "sharing" mindset down people's throats (and presumably get to the body-hugging one piece jump suits a little bit faster).

The mistake many people are making today is to think that a profit motive is a fundamental aspect of open source, that they're in competition with others. Even if the currency isn't dollars, it's some sort of competition with some sort of reward out there. These are the people who post all over the 'net hawking their free wares, attaching slick marketing slogans to their brain childs that consist of 12 utility classes and a couple of pages of javadoc - or the people with 30,000 lines of code and professional looking web sites who still ultimately are trying to sell something which is fundamentally free (sadly, you do not all know who you are :-().

Are a really low-level, programmers today are doing what scientists have been doing for years. Yeah, yeah, you've got a day job and have to pay the bills. But at a basic level, people in the sciences (and programmers) realize that their jobs are so complex that they cannot be accomplished alone. No one person, or even company, can work alone on quantum physics, or materials science, or XA transaction systems, and ge such a genius as to know everything and have done everything. So scientists have been in the business of swapping information such the profession was born, and programmers are just rediscovering this. The end result in such an environment is that the net-sum is that everything tends to get better - commercial products and the freebies.

Yeah, governments and companies and "agencies" may tune into it and pump it for all it's worth - and hence some of us will be able to continue to live in NYC :-) But it doesn't exist because of these organizations, it exists because this is what technical people do to be successful at their jobs.

    -Mike

Why make it so complicated. Just ask yourself if you ever met a GPL advocate that was charming, well-behaved, with table manners and generally behavior that are compatible with ordinary decent people?

That can discuss quietly and politely, reject Ad Hominem attacks and reason with logic and common sense without confusing cause and person?

In short, have you ever met an advocate for the "software belongs to all" type of GPL license that did not have bacon between his teeth's?

Do you think this people has anything common with the professionals at the Apache?

No? So then.

You can argue about Open Source phenomena as much as you want but their représentants speaks for themselves.

Regards
Rolf Tollerud

Why make it so complicated. Just ask yourself if you ever met a GPL advocate that was charming, well-behaved, with table manners and generally behavior that are compatible with ordinary decent people?That can discuss quietly and politely, reject Ad Hominem attacks and reason with logic and common sense without confusing cause and person?In short, have you ever met an advocate for the "software belongs to all" type of GPL license that did not have bacon between his teeth's?Do you think this people has anything common with the professionals at the Apache?No? So then.You can argue about Open Source phenomena as much as you want but their représentants speaks for themselves.RegardsRolf Tollerud

Rolf, try not to confuse cause and person, or to resort to Ad Hominem attacks, please... ;)

I will profess ignorance regarding GPL, how does it leave businesses high and dry?

It doesn't. The most succesful open source businesses to date are all based on GPL style licenses. The Apache advocates always seem to neglect to mention this minor detail.

The most succesful open source businesses to date are all based on GPL style licenses. The Apache advocates always seem to neglect to mention this minor detail.

An the key phrase here is open source businesses, with a BSD style license you don't have to be an open source business.

-dain

An the key phrase here is open source businesses, with a BSD style license you don't have to be an open source business

Yes but I prefer open source business. I get the software free of charge, I get access to the source free of charge. I can modify the source free of charge.

I don't care much for closed source business. Open source business is more friendly to my business.

Yes but I prefer open source business. I get the software free of charge, I get access to the source free of charge. I can modify the source free of charge.I don't care much for closed source business. Open source business is more friendly to my business.

Really? So I can redistribute mySQL with my application free of charge?

Anyway, who cares about businesses? Who wants an opensource project driven by profit motives? I prefer my opensource projects focused on what is best for the users (notice I did not write customers) and not what is best for the venture capitalists.

-dain

I will profess ignorance regarding GPL, how does it leave businesses high and dry?

It doesn't. The most succesful open source businesses to date are all based on GPL style licenses. The Apache advocates always seem to neglect to mention this minor detail.

You're speaking of the copyright holder's ability to profit from the industry.
 
I am speaking of the industry’s ability to profit from extending the software.

GPL allows just the first one, BSD allows both. GPL has its place and so does BSD. But when trying to provide a common building block that doesn't exclude everyone but the creator from profiting, BSD is the only choice.


-David Blevins

No, but "free" combined with "open" will go a long way, especially when a business-friendly license gives you a J2EE compatible platform to build upon or innovate with.

But which ``open'' is best, open standards or open source?

That's up to you. :) (There's openness of community too...)

The first being very important to myself and the majority of developers I come in contact with on a day to day basis while the latter, while nice, isn't as important. I would also say that just becasue it's open source certainly doesn't make it more innovative or easier to be innovative with (possibly having the exact opposite effect at first).

I wasn't suggesting at all that being open source necessarily makes it innovative - innovation has nothing to do with the availability of the source. What I was saying was that if you wish to build upon a platform, an open source platform gives you opportunities you don't generally have with a closed source platform - namely extension or modification of the platform itself at any level you choose or need, and doing what you wish with those changes. Having this choice is important, and the Apache Software License gives you that choice.

Mine is not an anti-closed source position - I personally am supportive of people doing what they think best, and personally use/choose lots of closed-source software.
 

I think you're certainly right WRT to commoditization which is why I also agree with an earlier post that Geronimo seems kind of late and hasn't done anything to _really_ stand out in the crowd, but that's probably a little premature at this point.

Agreed - I think that's very fair - it's too early, and I don't believe that there were any claims made to that effect. I think that what is being offered is a snapshot view of the container architecture, and early stages of pieces that people are familiar with (JMS, EJB, JMX, Servlets).

What about Java? At the root, java is a closed source system, yet many open and closed source systems have been built on top of it, due to open standards, not source.

Does Geronimo have any plans for supporting AOP?

Does Geronimo have any plans for supporting AOP?

Yes. We are plan to support AOP by partnering with one (or more) of the AOP projects. We have been talking with a few projects, but have no concrete plans yet. I hope to work out some details next week at The Server Side Symposium.

-dain

First of all, I would like to congrats the Apache team for the first version of Geronimo. Like others I also feel a bit pitty as we already have JBoss and JOnAS out there - especially JOnAS from ObjectWeb which is actually quite flexible with their licensing politics.

But anyway this attitude "not invented here" happens everywhere in Open Source community :-) Just take a look at the eLearning platform area (I'm working in this area), gee, you have huge choices! Much more than in the J2EE container area. Maybe because it's quite easy to implement an eLearning platform :-)

I know that the best experience and learning strategy you can get is to do "learning by doing", so in this case the developers who are involved in the Geronimo project would get a lot of good experiences. On the other side this is also the reason why component-based (especially binary-based reuse) software engineering has failed.

Cheers,
Lofi.
http://www.openuss.org

Like others I also feel a bit pitty as we already have JBoss and JOnAS out there - especially JOnAS from ObjectWeb which is actually quite flexible with their licensing politics. But anyway this attitude "not invented here" happens everywhere in Open Source community :-)

I'm a little offended by your comments, Lofi. You seem to be completely ingoring OpenEJB's role in all of this. It has existed just as long as JBoss and JOnAS and has just as much of a right to the ideological support you show for those projects.

Geronimo has adopted OpenEJB, rather than following the "not invented here" attitude as you would have people beleive.

As the co-founder of OpenEJB, I am thrilled that the project I have dedicated for years of my time and money to is being used as it was always intended -- as a pure EJB container for a larger J2EE server.

Geronimo is uniting the BSD J2EE world.

you need to check your attitude. He was just observing that the NIH syndrom was common in open source because people learn by coding. He also observed that componentization does not work because you often need to know exactly how the components work in order to use them -- (perhaps unintentally) a strong argument against the J2EE stack.

He probably doesn't realize that Geronimo is not like most open source products, in that the two primary motives for it's creation are spite and greed, since there are already open source implementations available and you all are obviously competent enough coders. You give BSD bigots a bad name by associating them with yourself.

you need to check your attitude. He was just observing that the NIH syndrom was common in open source because people learn by coding. He also observed that componentization does not work because you often need to know exactly how the components work in order to use them -- (perhaps unintentally) a strong argument against the J2EE stack.

I don't think NIH has any special monopoly in open source. It seems to be a very pervasive phenomena.

As for componentization - we'll just have to see how well Geronimo does in that department, now won't we? :-) From what I've seen they seem to be doing all right in that area so far.

He probably doesn't realize that Geronimo is not like most open source products, in that the two primary motives for it's creation are spite and greed, since there are already open source implementations available and you all are obviously competent enough coders. You give BSD bigots a bad name by associating them with yourself.

You seem to have a bone to pick - and I think you're letting your passion blind you a bit on this subject. The reason for Geronimo is to have a non-GPL/LPGL application server so that it may be used in the same manner as, say, Apache. Such a beasty did not exist in Open Source, and that's what the Geronimo project is all about.

   -Mike

He probably doesn't realize that Geronimo is not like most open source products, in that the two primary motives for it's creation are spite and greed, since there are already open source implementations available and you all are obviously competent enough coders. You give BSD bigots a bad name by associating them with yourself.

I was one of the ASF member sponors of the project, and one of the proposers. I was also the designated member 'shepherd' while we had that model in the incubator. I now help with process and politics, and utterly trivial coding whenever that's needed.

None of my actions were motivated by spite or greed. I don't get paid for this, and I really don't have it in for anyone. Rather I wanted to see an open-source application server developed by an open community of volunteers and licensed under a business-friendly license, the ASL, thinking that this would be useful for the development community at large. I also wanted to utilize the ASFs status as a not-for-profit corporation to apply to the scholarship program for the J2EE TCK, so we could certify.

-geir

Excuse the terrible typos in my previous response. Here is my sincere response again, no typos. Wouldn't it be great if TSS had a spell checker?

Like others I also feel a bit pitty as we already have JBoss and JOnAS out there - especially JOnAS from ObjectWeb which is actually quite flexible with their licensing politics.But anyway this attitude "not invented here" happens everywhere in Open Source community :-)

I'm a little offended by your comments, Lofi. You seem to be completely ignoring OpenEJB's role in all of this. It has existed just as long as JBoss and JOnAS and has just as much of a right to the ideological support you show for those projects.

Geronimo has adopted OpenEJB, rather than following the "not invented here" attitude as you would have people believe.

As the co-founder of OpenEJB, I am thrilled that the project to which I have dedicated four years of my time and money is being used as it was always intended -- as a pure EJB container for a larger J2EE server.

Geronimo is uniting the BSD J2EE world.

This second time around, I'll add that I know your heart is in the right place, Lofi. I feel as you do, that open source projects should support each other, not step on each other.

I am proud to be participating in an effort where other projects are being integrated without being forced to assimilate. Not everything Geronimo touches needs to be branded with the Geronimo name. It's a true collaborative effort.

<david>
I'm a little offended by your comments, Lofi. You seem to be completely ignoring OpenEJB's role in all of this. It has existed just as long as JBoss and JOnAS and has just as much of a right to the ideological support you show for those projects.
</david>

sorry I did not mean to offen you or your OpenEJB container at all. Yes, you are correct by remembering me on OpenEJB (I still remember as I wrote an article for JavaMagazin about EJB container in year 2000/2001: I compared JBoss, JOnAS and OpenEJB :-)).

What actually I'm asking is the idea of the J2EE container. IMO, it would be just enough to have one standard Open Source J2EE container, which can be filled in with "container services" like EJB container (OpenEJB, ...), Web container (Tomcat, Jetty, Enhydra, ...), Mail (SMTP, POP - James, ...) container, FTP container, etc. I wrote about this topic once in this forum...

In my understanding JOnAS, JBoss have already such a J2EE container, which can be filled in with those services. Why should Geronimo works on their own J2EE container? For the container users (like me) it is just a burden of different configuration files (JOnAS, JBoss and I think Geronimo) will be totally different to configure (although the main principle - with plugin services - is the same).

It would be very nice to have one standard J2EE container (same procedure every where :-)) with many services, which can be installed with the same procedure. So in this case I can choose my EJB container like OpenEJB and for example Enhydra as my Web container.

This is why I'm saying "not invented here" -> J2EE container and not the components/services on it.

Greets,
Lofi.

In my understanding JOnAS, JBoss have already such a J2EE container, which can be filled in with those services.

Technically speaking, neither group has an J2EE container. Only when the software passes the TCK can it be called a J2EE container because only then can you be sure that all the services and behaviors you expect in J2EE are there. (And even then....) Until that happens, it's Just Another Container. (Which is what Geronimo is at this moment.)

Why should Geronimo works on their own J2EE container? For the container users (like me) it is just a burden of different configuration files (JOnAS, JBoss and I think Geronimo) will be totally different to configure (although the main principle - with plugin services - is the same).It would be very nice to have one standard J2EE container (same procedure every where :-)) with many services, which can be installed with the same procedure.

Anything like that would benefit all users - and having commercial vendor participation would help even more (making the migration from an OSS container to a commercial one much easier.)

The 'hangup' is that the various containers are trying different approaches to just about everything, innovating in their own way, which is healthy, which makes having common config a bit of a challenge. Just look at Jetty and Tomcat - two excellent servlet cotainers, totally different in approach.

In my understanding JOnAS, JBoss have already such a J2EE container, which can be filled in with those services. Why should Geronimo works on their own J2EE container?

Because I can't legally integrate OpenEJB into any of those projects without making it (L)GPL. It is against the law, pure and simple. They can, but I can't.

GPL projects can use our (BSD-style) projects, because the BSD license permits it. But the GPL license prohibits us from doing the same. In their mind, we are just as bad as Microsoft -- perhaps worse for "derailing" the FSF agenda.

As a user, you can do just about anything you want because you are not directly tied to the server. As an integrator, I don't have that same right.

-David Blevins

In their mind, we are just as bad as Microsoft -- perhaps worse for "derailing" the FSF agenda.

Man, you have swallowed a whole lot of religion. Go take a break, will you?

In their mind, we are just as bad as Microsoft -- perhaps worse for "derailing" the FSF agenda.

Man, you have swallowed a whole lot of religion. Go take a break, will you?

These aren't my perceptions and I know there are many people behind GPL that don't perceive this as true either. If you read one of my prior posts you'll see I've said both GPL and BSD have their place. I'll also not that Geronimo has a particularly good relationship with ObjectWeb. The both of us are committed to working together and they have even switched JOTM to from GPL to BSD so we could legally use it.

But... my comments on GPL hostility towards BSD come from feedback from the GPL creator himself, Richard M. Stallman, who caught wind of this discussion. I'll note once more that I don't share his perceptions:

I should mention that I do not advocate "open source" licensing.
I disagree with the basic values of the open source movement.

I founded the free software movement, which says that computer users
are ethically entitled to the freedom to redistribute and change
software. The open source movement was founded, many years later,
specifically to reject that position.

While I don't believe the spirit of most projects using GPL or BSD differ that greatly, the two are legally incompatible; non-GPL projects can't integrate GPL software.

There is no J2EE solution legally accessible at an integration level to the BSD world, we are creating one using existing BSD-compatible components and, as I mention, with the help of historically GPL shops like ObjectWeb.

All the best,
David Blevins

In their mind, we are just as bad as Microsoft -- perhaps worse for "derailing" the FSF agenda.

Man, you have swallowed a whole lot of religion. Go take a break, will you?

These aren't my perceptions and I know there are many people behind GPL that don't perceive this as true either. If you read one of my prior posts you'll see I've said both GPL and BSD have their place. I'll also not that Geronimo has a particularly good relationship with ObjectWeb. The both of us are committed to working together and they have even switched JOTM to from GPL to BSD so we could legally use it.But... my comments on GPL hostility towards BSD come from feedback from the GPL creator himself, Richard M. Stallman, who caught wind of this discussion. I'll note once more that I don't share his perceptions:

I should mention that I do not advocate "open source" licensing.I disagree with the basic values of the open source movement.I founded the free software movement, which says that computer usersare ethically entitled to the freedom to redistribute and changesoftware. The open source movement was founded, many years later,specifically to reject that position.

While I don't believe the spirit of most projects using GPL or BSD differ that greatly, the two are legally incompatible; non-GPL projects can't integrate GPL software. There is no J2EE solution legally accessible at an integration level to the BSD world, we are creating one using existing BSD-compatible components and, as I mention, with the help of historically GPL shops like ObjectWeb.All the best,David Blevins

Actually, JOTM switched from LGPL to BSD, not GPL to BSD. Big difference. LGPL and BSD can coexist just as proprietary closed source and LGPL can coexist. Your problem is with the rules forced upon you by the Apache Foundation, not with any legal licensing issues.

LGPL and BSD can coexist just as proprietary closed source and LGPL can coexist. Your problem is with the rules forced upon you by the Apache Foundation, not with any legal licensing issues.

I'm not so sure it's that simple. Can non-LGPL sofware implement an interface that is under the LGPL? How about subclassing from LGPL code?

LGPL and BSD can coexist just as proprietary closed source and LGPL can coexist. Your problem is with the rules forced upon you by the Apache Foundation, not with any legal licensing issues.

I'm not so sure it's that simple. Can non-LGPL sofware implement an interface that is under the LGPL? How about subclassing from LGPL code?

http://lists.debian.org/debian-legal/2003/debian-legal-200307/msg00234.html

Message from David Turner to Debian. David Turner manages licenses at FSF.

Unfortunately Bill, an FSF interpretation does not have any sort of legal binding. To be frank, FSF people can and do say what they want to "interpret" a license but it means zero, zip, nada to courts. Just because a blowhard declares a license means "XYZ" does not make it so - all that matters is what the license says, and what the courts decide. Companies do not care what a zealot says an interpretation of a license should be read as - they care what the license in and of itself _actually says_ (fancy that!). The FSF can interpret all they want - it has no bearing on reality. I hope that as an employee of a company that has gone the LGPL route you understand the difference - and that you understand the nasty rules of "use whatever FSF license floats your boat". I'm sure your investors are _real_ happy that the FSF can change licenses right out from under you!

   -Mike

Unfortunately Bill, an FSF interpretation does not have any sort of legal binding. To be frank, FSF people can and do say what they want to "interpret" a license but it means zero, zip, nada to courts. Just because a blowhard declares a license means "XYZ" does not make it so - all that matters is what the license says, and what the courts decide. Companies do not care what a zealot says an interpretation of a license should be read as - they care what the license in and of itself _actually says_ (fancy that!). The FSF can interpret all they want - it has no bearing on reality. I hope that as an employee of a company that has gone the LGPL route you understand the difference - and that you understand the nasty rules of "use whatever FSF license floats your boat". I'm sure your investors are _real_ happy that the FSF can change licenses right out from under you! -Mike

You can interpret all you want, it has no bearing on reality as you are not a lawyer, nor are you a lawyer skilled in open source law, nor are you a lawyer skilled in copyright law. Unlike yourself, we actually consult lawyers that have actually argued open source cases. The FSF's interpretation actually does have a bearing on reality as they are the authors of the license and can provide basis for the original intent of the license. Also, it is clear you did not read the fine print of the LGPL as they cannot change the license from under you.

I'm sure you cannot resist having the last word, but this is EOD for me, but the facts remain clear:

1) Most software developers are unaffected by GPL as they their companies do not distribute software.

2) Even less are affected by LGPL and those companies will have no problems as long as they play ball with the terms of the license.

3) The FSF has clearly stated the intent of the LGPL license as it pertains to Java.

4) Thousands of companies are using GPL and LGPL based software (Linux, MySql, JBoss, etc...)

No, IANAL. That doesn't mean I don't have a brain - or that I haven't consulted with some lawyers along the way.

Your take on the FSF's license author's intent is interesting. What you are telling me is that I need to know to go out and find some FSF's people interpretation of a license before I can understand what the license means. I'd prefer a license that was clear enough that I would not need such interpretation. It's also a very interesting position to yourself in - you're relying on a third party to define how you license your own property? How are you going to feel if next week the FSF issues an "interpretation" which you do not agree with? You're going to let an FSF mouthpiece dictate how your software can be released?

Also, it is clear you did not read the fine print of the LGPL as they cannot change the license from under you.

Unfortunately for you, this is one of the few areas where the LGPL is clear. From http://www.fsf.org/licenses/lgpl.html:

LPGL License

13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation.

Your own code does not specify a version number, so the receiver of the license may pick which ever version suits them.

Oops.

1) Most software developers are unaffected by GPL as they their companies do not distribute software.

2) Even less are affected by LGPL and those companies will have no problems as long as they play ball with the terms of the license.

Bill, you still haven't been able to define what "distribute" means in the LGPL. You're an LGPL author - tell me what you think it means. Then show me supporting text in the license which backs up the claim.

I don't give a damn what FSF mouthpieces say - you don't ship them with your software :-)

3) The FSF has clearly stated the intent of the LGPL license as it pertains to Java.

4) Thousands of companies are using GPL and LGPL based software (Linux, MySql, JBoss, etc...)

Downloading your AOP beta, my own clue to license terms is:

/***************************************
 * *
 * JBoss: The OpenSource J2EE WebOS *
 * *
 * Distributable under LGPL license. *
 * See terms of license at gnu.org. *
 * *
 ***************************************/

So I go to the site and read the license. I am not required to read the spin of FSF experts to license your software - I am only required to follow the written terms of the license text.

To be quite frank, here's why you're being stupid: you're telling me to go to the FSF to find out how to license _your_ software. Why? To find out what distribute means, you seem to be telling me to go talk to some FSF person. Why? To find out what "linking" means in an LGPL context, I do not wish to consult an FSF spinmeister - I'd like to see what the license says.

So here's a radical thought for you: rather than all this vagueness and uncertainty, _why not make the license clear_? Why are you pointing people to mailing lists to find out how to interpret your license? _Why not just put it into the license_?

And why are you licensing your own property in such a way that people you don't know can change the terms without your permission (hell, without even consulting you)? What're you gonna do if Stallman has another fit and changes the LPGL in a way you don't like?

    -Mike

The "original intent" of the authors of a contract is almost always considered if there is a question as to what a contract means. So, what the FSF says about a license is very relevant. If a case ever appeared before a judge which questioned, for example, "linking", it would be absolutely normal for that judge to review any interpretations or explanations provided by the authors of the contract. That doesn't necessarily mean that the judge would use that interpretation, especially if it's an attempt to redefine a commonly used word or there is case law in opposition of the interpretation. Contracts aren't just the words on the piece of paper, it's a "meeting of the minds" between two parties and during a contract dispute, the intent of those parties important.

Problem in case of LGPL and Java is, what FSF says about their "original intent" is mostly irrelevant because its an afterthought. LGPL is older than Java and never really was designed for such circumstances. Trying to readapt to this new language without updating the license is naive.

Chris: GPL and LPGL are not contracts. There is no meeting of the minds because no one negotiates these things. "Customers" of JBoss or some other (L)GPL work do not get together and hammer out a contract - you just get a license, and you accept what it says or what you don't.

Certainly, if a case came up like you describe the court would likely listen to what the FSF people had to say, and they could make arguments. But, as you say - their interpretation is not definitive. In a case like LGPL JBoss, there is no negotiating going on behind the scenes, Joe User does not get together with the FSF and create a deal to their mutual satisfaction. Most importantly - the FSF isn't involved at all with me downloading and using a copy of JBoss, nor could the course have a reasonable expectation that I would seek out FSF people to get their interpretations e.g. their interpretations are presumed to be unknown to me, because I've never interacted with them. My only well-defined interaction is with the license text itself.

In such a mythical case, if an FSF person stood up and said "Clause 6 is interpreted by us in this context as [blah blah blah]", _I_ could reasonably respond "How was I supposed to know that?".

    -Mike

Mike, IANAL, but AFAIK these definitions must remain generic on the license in order to be "future-proof". It would be impossible to enumerate every possible way of linking and distributing software in today's technology, even less with ones yet to be invented, so the only way to protect software under a license is to be generic, and resolve any conflict either by adding minor adjusts in the license itself (versioning), or by offering clarifications in additional public documents (FAQs), or face to face at the court floor. I can't see how to have a generic license like GPL which would cover every possible hole or imaginable usage of every GPLed sofware and its components in all different technologies in such a way that wouldn't leave any doubt for its users, present or future, unless you would like to add a 20Mb license file with every GPLed source code out there... ;)

The moment you get generic, you risk opening it for different interpretations. The moment you get specific, you risk leaving relevant things out of it. You just can't have both.

Regards,
Henrique Steckelberg

Henrique, I agree completely, and that's where my own question comes in: given what you've said, why would you want to use it? Is a generic license going to adequately and unambiguosly serve the needs of the authors and users? My opinion is, no, it's not.

Look at JBoss as an example - is the LGPL really serving the author's interests here? Does it give the protections that authors thinks it does? And how about users, and particularly those who are interested in modifying the work. Is the average such individual going to understand the license sufficiently to not get himself in hot water?

Now imagine JBoss released under an LGPL-like license tailored to JBoss and Java. Here's what you can do, folks, here's what you can't do. Best of all for JBoss authors, the FSF can't come in and re-write the license out from under them - they control their own license for their own code.

Now I've heard arguments about why such a profliferation of licenses would be bad - but I don't agree with them. First off, most of those objections come from the FSF themselves. They lose power and visibility when someone uses their own license. The second argument is that by doing your own license, you're going to screw it up somehow. Well, you'd think a well-financed company like JBoss could write their own license :-) Tiny little nothing companies manage to create licenses for their own products, why can't open source companies do so? And as for screwing it up - screwed up how? Compared to the already screwed up and inappropriate-in-a-Java-context (L)GPL?

The don't-do-your-own-license thing may fly for individuals who don't know much of anything about licenses, but for big projects, with many smart people running it, it just doesn't make much sense. In an Apache context it makes sense, in that you're contributing to a non-profit organization that wants to have a measure of control, and so you want an org-specific license. But when you've got your own indepedent project, I can see people doing alot better (and clarifying alot of unnecessarily murky issues) by abandoning the (L)GPL and rolling their own. This doesn't mean people have to abandon the general idea behind Copyleft - it means that they're abandoning the shoddy FSF implementation of it.

    -Mike

It's good to see Apache foundation finally released Geronimo. But it looks like a bundle than a product. It will take a while for Gernonimo to catch up with the technology and JBoss !

Are JBoss folks scared to see another JBoss killer breeding

I propose a new version of Godwin's Law, called Godwin's Millenium Law:

The first version to mention how much a particular open source license sucks automatically loses the conversation, and the thread must henceforth be terminated with the winner being implicitly declared to be the non-mentioner.

First person that is, not version. Versions don't have conversations with other versions, nor can they win or lose an argument.

I have another suggestion. The first person to have debunked 1000 things without ever had taken a single stand for anything whatsoever wins. I have been keeping count and you are the leader at the moment with 892 cases! I will cross my fingers for you..

Regards
Rolf Tollerud
(how does it go with your C# exercises?)

I was wondering if anyone used this? Some insights into how good is this