Why LGPL?

Submitted by jimbethancourt on Sat, 06/28/2008 - 22:14.

Hi all,
I've been looking through the forums and noticing that there are several projects that haven't been included in JNode because they are licensed under the GPL license.

I'm curious why the LGPL license was chosen, since JNode is not a library but is instead a platform.

It looks like a great deal of synergy could be gained by using other Java packages if the GPL license was used instead.

Thanks so much,
Jim

‹ VirtualBox: no luck ever. QEmu: semi-works Using OSGi as deployment model ›

Sad

Submitted by Anda on Wed, 06/30/2010 - 03:47.

Seems to me that this might be why JNode is stagnant.

Jimbethancourt is (i should say was) right on the spot. There is so many great stuff accessible that would accelerate JNode's development. The change of license is a painfull task but could be a necessary evil.

CLarity regarding LGPL

Submitted by ssatturi on Thu, 06/17/2010 - 04:38.

Hi Everyone,
I'm Srikanth. New to LGPL kinda stuff.. I want to modify a LGPL code, (I know it's a derivative work) . So what limitations I will be having.. Can I use the modified one for Commercial product. Do I need to disclose modified code.

Answers

Submitted by Stephen Crawley on Thu, 06/17/2010 - 10:57.

> New to LGPL kinda stuff..

There is lots of information on GNU licenses at "http://www.gnu.org/licenses/licenses.html". You should read it all carefully. Most of your questions will be answered there ... more reliably than here.

> I want to modify a LGPL code, (I know it's a derivative work. So what limitations I will be having. Can I use the modified one for Commercial product.

Yes. None of the GPL or LGPL licenses forbid use of the covered software in commercial products. The terms are largely about how you make your code available. This makes certain models of commercial exploitation impossible, but does not discriminate against commercial software per se. Indeed, there are lots of companies making good money out of GPL'ed and LGPL'ed software.

But you have to obey the rules ... or not build your code on GPL / LGPL'ed software.

> Do I need to disclose modified code.

If you distribute code that uses a modified version of LGPL'ed code, then you must make available the source code of your modifications.

my choice is GPL

Submitted by boss jhonson on Mon, 07/07/2008 - 10:21.

hi all,
for JNode, I'll say GPL better, as said by Crawley. As here the OS kernel version mainly releasing so we better choose GPL, then we may have other license for different application libraries, and we can support more other external libraries more freely.

But it also a true fact, we need all developers acceptance for doing the change of license.

thank U all for the dicussion,
GOODBYE,
boss (Swarup Choudhuri)

Let's not copy UNIX's directory layout

Submitted by Daniel Noll on Thu, 07/03/2008 - 22:07.

It would probably be a good idea to avoid the UNIX directory layout. It's full of design decisions which no longer make sense in the modern world.

e.g. separating bin and sbin when you could use the +x flag to distinguish the two types of executable, separating bin into /bin, /usr/bin, etc. to support boot-time repair when live CDs are a better solution. About the only principle which still applies is that user data should be on a different partition to system files as the system files are more easily created from scratch. And that's only when a user actually cares about data integrity, the vast majority of users can make do with a single partition these days (not counting swap of course.)

The only Linux distro I know of without this problem is GoboLinux (there is probably at least one more.)

Having the commands similar is fair enough I think, although you'll get a fair number of people who say they're used to dir and not ls.

Licences is always a

Submitted by Peter on Sat, 06/28/2008 - 22:29.

Licences is always a problem. Perhaps GPL means you can use more external code more easily but LGPL also means your code can be used more often by other projects.
I personally would be disapointed if we wouldn't be able to have closed source code in jnode too. Look at Linux, it's still a mess if binary drivers are ok or not.

This is my personal opinion and as the copyright holder of jnode code are widespread and many are not active anymore changing the license would be difficult.

Ideally ...

Submitted by Stephen Crawley on Sun, 06/29/2008 - 02:57.

In an ideal world, I think the best approach would be for JNode as a whole to be licensed as a GPL collection, with individual separable components (libraries and applications) licensed individually under LGPL, GPL or other compatible license. This is how typical Linux distro's are licensed.

Whether this would "work" from a legal perspective for a JNode distro is not clear. If we were ever to contemplate this, we would need to consult an expert (e.g. the FSF lawyers) to be sure.

And as Peter rightly points out, any change to licensing of existing JNode code would involve contacting and getting permission from the code's copyright holders. That would be difficult for a number of reasons.

GPL v3 + CE?

Submitted by jimbethancourt on Mon, 06/30/2008 - 19:26.

Has using the GPL3 license plus Classpath Exception (CE) been investigated? The GPL v3 allows for many more libraries to be used in GPL'd code than the GPL v2 did, and the Classpath Exception clause allows for programs that are run on the classpath of the executing JVM to not be constrained by the GPL terms. This is what Sun did with the JVM and OpenJDK.

Peter, I'm a little confused by your statement -- could you please clarify?
"This is my personal opinion and as the copyright holder of jnode code are widespread and many are not active anymore changing the license would be difficult."

I guess I'm wondering -- Is JNode considered to be a collection of libraries that developers are compiling against, or as an OS platform that they are running their programs on? If it's considered to be a platform, migrating the license to GPL + CE wouldn't impact people running their programs on it.

What closed source libraries are being used in JNode in its present state?

I'm thinking more developers might be willing to get involved in JNode if it is developed under a GPL license rather than a LGPL license, that way they know their intellectual property they donate will be kept free and safe.

Cheers,
Jim

It's a collection of libraries

Submitted by Daniel Noll on Wed, 07/02/2008 - 03:48.

We're considering it to be a collection of libraries and running them under the Sun JVM, but as far as I can tell, the classpath exception allows this use case too.

By reading the documentation it seems the only difference is that with LGPL and the plain GPL, there are other third-party modules whose licences are considered "incompatible", which is not the case with the GPL+CE. That being said, more and more libraries have been becoming compatible with the GPL lately anyway.

Would it really make any difference?

Submitted by Stephen Crawley on Wed, 07/02/2008 - 02:00.

Bearing in mind that JNode does not require copyright assignment ... would it make any difference to you if we changed license? Specifically, is our use of LGPL the only thing that is stopping you from contributing? Really?

My theory is that few (if any) developers are interested enough to want to contribute to JNode, but are deterred from contributing solely because of the licensing arrangements. At least, I don't see any evidence of them.

Re: Would it really make any difference?

Submitted by jimbethancourt on Thu, 07/03/2008 - 19:35.

Hi Stephen,
I didn't mean to come across as being rude, and I apologize if my message was read that way. I probably could have worded my question differently.

I'd like to see JNode with a GPL license since it is pretty much one of a kind, but also so we can use algorithms, code, and libraries written under other licenses (such as GPL, EPL, and ASL licenses) in it as well. Levente has mentioned that some closed source projects have contributed back their changes to JNode, which is great. Other closed source systems can still use JNode libraries under the GPLv3 + CE, but just not the source code itself. The GPL v3 is also much more clear about what kind of libraries can be used in GPL'd bodies of work. See http://www.informationweek.com/blog/main/archives/2007/07/apache_foundati.html and http://www.cbronline.com/article_news.asp?guid=BF4D9528-C8E5-44A0-9B26-A3B1DEF837F0

I've emailed back and forth with Levente about some ideas that I think would help give the project a better design:

  • refactor the plugin system to use OSGi / JAM. They're (thankfully) being merged:
    http://weblogs.java.net/blog/mandychung/archive/2008/04/supporting_osgi.html
  • The Spring Application Platform has a really neat tool that can take and turn a normal WAR into an OSGi bundle. This code could be used to do similar things for JARs, but we could reuse their code only if we move to a GPL v3 based license, since the Spring Application Server is licensed under GPL v3
  • Use Terracotta to allow for an extremely large memory pool (maybe even use it somehow to have the same code run on multiple processes simultaneously without any effor on the part of the user). We could use different OSGi modules to segregate what is clustered and what is not. I was thinking that only programs that run on a Server VM would be considered for clustering. I would seriously consider licensing JNode under the AGPL v3 + CE license when used in this manner, as most programs that would be running in this fashion would not require distribution of the source code.
  • Use dependency injection to make JNode code more testable and flexible. Consequently, there's a Terracotta module for Guice that makes it easy to scale code that uses Guice. Spring beans are also easy to cluster with Terracotta
  • Use Maven 2 as the build system so it is easier to manage the build script, JNode's dependency versions, and take advantage of its code health reports. This would require a little bit of refactoring, but not a great deal. Mostly it would involve moving the production source code into "src/main/java" and the unit tests into "src/test/java" folders. On top of that, it's a breeze to move from one IDE to another.
  • Use Spring LDAP and Spring Security. They're both mature and in wide use.
  • Maybe use Quartz and / or Spring Batch for chron jobs.
  • Use more off the shelf open source libraries wherever possible in general. There are plenty of open source Java libraries that are top notch, and it would allow the project to focus more on the problems that haven't been solved yet. For example, perhaps the use of JDistro would be considered since it is a mature desktop system. Using a GPL v3 + CE license would make this possible
  • Have JRuby and Groovy consoles. Levente had mentioned he tried this out and met with some success.
  • Use more tools that are available to open source projects: SonarJ, Headway101, JIRA, FishEye, Crucible, Bamboo and / or TeamCity, various profilers, etc.
  • Have a directory layout and commands similar to UNIX / Linux distributions so people will both feel comfortable using it (since they know what to expect) and can be just as productive in a JNode environment. This would also allow Groovy and JRuby scripts that have been written to run in JNode without having to change them.

Using a number of these libraries would only be possible to use if the GPL v3 license were used since they use a license other than the GPL, but to avoid causing the downstream users to GPL their code, the Classpath Exception could be used as well.

What are your thoughts?

Thanks,
Jim

My thoughts on this ...

Submitted by Stephen Crawley on Fri, 07/04/2008 - 13:06.

I'm sorry to be negative, but we have no shortage of good ideas for JNode. What we need is people with the interest, skill and time to do the work.

And I'd like to repeat once again that the core developers are not keen on spending their limited time chasing down JNode copyright owners and persuading them to agree to relicense their code under some "better" license. At least not at this time.

Not at this moment please.....

Submitted by tango_java_06 on Mon, 07/07/2008 - 05:02.

yeh...

the most important thing for us now giving our time finding out from our daily life and busyness..and research for new logics and enhance the Jnode for next generation computing. It is very tough for us to finding out time and working here with deep concentration. But, we hope always for the best and like to contribute on this platform more and more.

So, it is not the time for JNode for discussing and coming on the debate for using the Liscences more benefitial for working etc or not.
i hope we will get time for that.

Many different developers

Submitted by Peter on Tue, 07/01/2008 - 19:45.

I meant that changing the license of JNode would require the permission from all developers. There are many different ones and many are not reachable anymore.