Skip to main content

Flexibility (Licensing)

33 replies [Last post]
hubick
Offline
Joined: 2006-08-15
Points: 0

Short:

At a *minimum*, license Java as liberally as Classpath+GCJ. (ie, FSF approved, GPL compat, DFSG compliant).

Long:

I currently work for a University with about fourty thousand students. The service platform for the group I work with consists of mostly Free Software, meaning Linux, Apache, Tomcat, running uPortal, Plone, Moodle, custom client apps, etc. I am primarily a Java programmer, and Java technology has played a significant role in our platform. I prefer Free Software for a variety of reasons (philisophical and pragmatic), many of which are the same ones that make Java based technology appealing.

It's mostly about flexibility.

Flexibility through avoiding vendor lock-in. With Linux, we can switch our servers between Intel, AMD, IBM/PPC, Sun, etc. We can choose between any of a multitude of Linux vendors. Similarily with Java based tech, we can switch our OS between Linux, Windows, Solaris, etc. But we do that with Python, PHP, and Perl as well - though I personally prefer Java as a language over the others because of it's object oriented features, strong typing, integral threading support, exceptions, unicode, scalability, etc. The point being, if we encounter a problem with virtually any component of our platform stack, we can either switch vendors or fix it ourself. Free Software gives us some guarantees for the future as well - if a vendor drops support for a product, chances are we (or a community) can continue to provide support for it. Our vendors are forced to compete on implementation, and the one with the best functionality and service+support wins. We are not tied to anyone currently - except perhaps to Sun with our Java apps.

That is why all new code I write is being tested on Classpath today. We currently use RedHat as our preferred Linux vendor, and I have been testing our existing software under GCJ and Fedora Core 5. With the fantastic level of advancement by new Classpath releases, which will be in Fedora Core 6, and eventually RHEL 5, I hope to have the ability to run all of our software on that Free platform out of the box. Yay for JFreeChart support on the latest Classpath release - one of our last blockers. I will soon have the choice of using this on any of several great Free JVM implementations - from Kaffe to IKVM. I don't think for a second that the advancement of the Free Java implementations and Sun's Open Source ruminations are a coincidence.

IMPORTANT: If I find a bug in the Java implementation (VM or libs), I should be able to immediately patch it myself, or download a patch from the net, recompile it, and deploy to our servers or ship those updates to our customers.

That is to say, I don't like the term Open Source, because I don't care if I can *look* at the code, unless I am allowed to *patch* it and *ship* fixes to our customers myself - immediately, with no Sun involvement, forever. This is why I like the term Free Software, and cringe when I hear people say that Java has been Open Source for years. p.s. I don't care if I am not allowed to call what I patch/ship as Java(tm) or can't brand it as official/real Java. Similarily, if someone like Transmeta comes out with some new CPU (which I want to use), they should be able to recompile the JVM software for it and bundle it when they sell their stuff (to me), without having to consult anyone or pass anything - unless they want to label it as official/real Java. I care about such Freedom for other commercial vendors as well - because that gives me more choice.

Personally, I started programming in Java back in 96 when Sun told me it was destined to become and ISO standard. I got burned. Then Sun told me it would become an ECMA standard. I got burned. Then I joined thousands of others in asking for a Linux port. I got burned - at least for years, and I still have to go through headaches rewrapping through JPackage for proper RPM deployment. I filed bugs for problems - I got burned - and sat around for years waiting for you to fix them [ie http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4212070 ]. Sun has always done just about the absolute bare minimum to keep me from defecting - but I'm not happy about it. My message to Sun is basically, that after all these years of being burnt, it's come down to this: I don't really care what you do anymore!

If you choose a license liberal enough to give me as much Freedom as I have with Classpath+GCJ/Kaffe/whatever, then your implementation might continue to be evaluated and tested alongside those others for its features/performance. Otherwise, you are quickly becoming irrelevant to me and the Free Software world I now inhabit.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
atripp
Offline
Joined: 2003-07-15
Points: 0

@rolibad:
> If you are interested in understanding the details, e-mail me

Why must you always label the person who disagrees with you as just not understanding? Can't you just agree that either:

a. The GPL copyleft really does kick in when you subclass, or
b. That a lot of lawyers may *think* it does, or
c. That a lot of companies may avoid the GPL even if a few lawyers are just a little nervous about it, or even
d. That a lot of companies will avoid any license that doesn't say exactly what they wish it would say.

falde
Offline
Joined: 2006-11-05
Points: 0

> If a lawyer strictly interprets the GPL that's
> exactly what he'll read in it, that you can't extend
> a Java class released under GPL without making that
> new class GPL as well.
>
> Effectively that will prevent people from using Java
> for non-GPL projects, spirit of the license or no
> spirit (and the spirit of the GPL IS to force
> everyone to release everything under GPL).
>
Thats not entirely true. For example MySQL:s client is under the GPL but there are a lot of non-GPL software using it. GPL doesnt prevent Sun from licensing their software under other licenses to others. Why should java be free for those that writes closed-source applications?
>
> That's why many companies will not touch GPL code and
> even prohibit their people from looking at it in
> their spare time (to prevent someone from claiming
> they used lines of code remembered from a GPL source
> in their own product).
> The latter may be a bit extreme, but given the viral
> nature of the think I fully agree that it should
> never be used anywhere in conjunction with code you
> don't want to release under GPL yourself.
>
Yeah, but do you really think sun will use a license where you can copy and past code from the jdk and sell under your own license?

webmink
Offline
Joined: 2003-06-06
Points: 0

> Thats not entirely true. For example MySQL:s client
> is under the GPL but there are a lot of non-GPL
> software using it.

Interestingly, MySQL are in the process of devising a very restrictive GPL exception exactly because of concerns about this at Debian. See http://www.mysql.com/company/legal/licensing/foss-exception.html

falde
Offline
Joined: 2006-11-05
Points: 0

For non-gpl project there are commersial licenses of mysql. When it comes to the libraries they could also use the LGPL license, i think Mono does this. But in my opinion sun should use the GPL everything except the libs to make sure they control it.

webmink
Offline
Joined: 2003-06-06
Points: 0

> For non-gpl project there are commersial licenses of
> mysql.

Yes, but this MySQL exception is for Free software projects not using the GPL. For example, some people believe running an Apache-licensed program on top of MySQL is a GPL violation. MySQL could have used the same exception as Classpath but that appears to deliver too many freedoms to commercial users for MySQL so they are inventing their own exception.

falde
Offline
Joined: 2006-11-05
Points: 0

> > For non-gpl project there are commercial licenses
> of
> > mysql.
>
> Yes, but this MySQL exception is for Free software
> projects not using the GPL. For example, some people
> believe running an Apache-licensed program on top of
> MySQL is a GPL violation. MySQL could have used the
> same exception as Classpath but that appears to
> deliver too many freedoms to commercial users for
> MySQL so they are inventing their own exception.

The freedom it would provide to commercial users is to use MySQL for free. By this they force users to buy a "full" license if they want to use MySQL as if it had a LGPL license. The point of using MySQLs dual-license model as an example is to show that GPL/LGPL isnÂ’t more limited then you make it. Users that wants to do something else could always negotiate another agreement with the copyright holder.

To say that using anything with GPL would force you to open all your sourcecode is a huge oversimplification of how it works. If the copyright holder is a GPL fanatic that never allows anything else then its probably true. But its never more then a contract that can be renegotiated into something else. Those that claim this usually also makes it sound like that GPL also makes the copyright holder lose control over the code, by being unspecific about who this risk applies to. This is where it crosses the line and becomes FUD. GPL even allows the copyright holder to withdraw the right to use the software, thus making him/her/them fully in control.

jwenting
Offline
Joined: 2003-12-02
Points: 0

> > I think a CDDL only license is one sided, in that
> Sun could use GPL software components in their JVM,
> but then wouldn't let the JVM components be used in
> GPL software.
>
> Um. That's not correct to my knowledge. CDDL-licensed
> code can not use GPL-licensed code (and vice versa).
>

GPL prohibits the use of any other license in any code it touches.

robilad
Offline
Joined: 2004-05-05
Points: 0

@jwenting: That's not entirely correct.

The GPL prohibits combining GPLd code with code that's licensed under terms which add restrictions on top of those in the GPL. If a license does not do that, it's called GPL-compatible, and such code can be combined with GPLd works.

That's why you'll find a lot of files under licenses other than the pure GPL in FSF's projects like gcc.

With the addition of a linking exception, though, the GPL stops requiring that code using GPL+linking exception licensed works needs to conform to the GPL as well, or have other restrictions on its licensing.

jwenting
Offline
Joined: 2003-12-02
Points: 0

If a lawyer strictly interprets the GPL that's exactly what he'll read in it, that you can't extend a Java class released under GPL without making that new class GPL as well.

Effectively that will prevent people from using Java for non-GPL projects, spirit of the license or no spirit (and the spirit of the GPL IS to force everyone to release everything under GPL).

That's why many companies will not touch GPL code and even prohibit their people from looking at it in their spare time (to prevent someone from claiming they used lines of code remembered from a GPL source in their own product).
The latter may be a bit extreme, but given the viral nature of the think I fully agree that it should never be used anywhere in conjunction with code you don't want to release under GPL yourself.

robilad
Offline
Joined: 2004-05-05
Points: 0

@jwenting: Well, I said already that a GPL with a linking exception would be preferrable to the plain GPL, as hubick elaborated.

I've explained in another thread how the GPL works in conjuction with uncopyrightable bits like standard interface names (i.e. it can't propagate obligations to works using the same interface names), so there is no particular reason to go over that topic in every thread.

But that's really just a small issue with your particular understanding of the GPL, not something that's being proprosed here for the JDK class library by hubick. If you are interested in understanding the details, e-mail me, and I'll try to answer your questions as good as I can.

I've only been doing that for 5 years now. ;)

jwenting
Offline
Joined: 2003-12-02
Points: 0

> @jwenting: Well, I said already that a GPL with a
> linking exception would be preferrable to the plain
> GPL, as hubick elaborated.
>

Doesn't matter, it's still untouchable.
Any hint of having some GPL code in your product should be avoided at all cost to prevent being accused of breaking the GPL and loosing control over your sourcecode.
Having any GPL code in your company in whatever form is enough to cause that suspicion.

You may have been a GPL advocate for 5 years, but that only means you have 5 years of experience in tricking people into accepting a license for their product that ultimately means they loose control over that product.

robilad
Offline
Joined: 2004-05-05
Points: 0

@jwenting: Please try to avoid attacking the integrity of other participants in the discussion.

thank you.

hubick
Offline
Joined: 2006-08-15
Points: 0

> > I think a CDDL only license is one sided, in that Sun could
> > use GPL software components in their JVM, but then
> > wouldn't let the JVM components be used in GPL software.
>
> Um. That's not correct to my knowledge. CDDL-licensed code
> can not use GPL-licensed code (and vice versa).

FYI: My (possibly innacurate) CDDL information was from here:
http://www.eweek.com/article2/0,1759,1735520,00.asp?kc=EWRSS03129TX1K000...

Thanks for the clarification.

webmink
Offline
Joined: 2003-06-06
Points: 0

The Sun JDK has been licensed under a new license, the DLJ[1], specifically to overcome objections from Debian to the binary distribution license[2]. While the source is not yet open, the binary can now at least be carried in the non-free repository which, while pedantically not a "part of Debian" as Dalibor explains, makes the Sun JDK available with simple and familiar commands to every Debian user who chooses to enable access to the non-free repository.

On Ubuntu, it's become as simple as checking a box in Synaptic because of this. We still need the source opened[3] (I disagree profoundly with Scott Handy on this[4]) but the source of pain has been alleviated for now for the pragmatic majority.

[1] https://jdk-distros.dev.java.net/
[2] http://blogs.sun.com/roller/page/webmink?entry=jdk_on_gnu_linux_something
[3] http://blogs.sun.com/roller/page/webmink?entry=why_bother_open_sourcing_...
[4] http://news.com.com/2061-10795_3-6106388.html

hubick
Offline
Joined: 2006-08-15
Points: 0

I just wanted to say THANKS!!!! to Sun, and that the use of the GPL+exception is *great* news to me!

After all these years of quasi-open, I was really suspect it was going to actually happen - but when all the bits are out there, you guys will have come through big. The GPL is a license that I understand and trust.

I can't wait until I can finally test all my Java software on a copy of Debian, right out of the box :)

Thanks!

p.s. Once upon a time Sun talked about standardizing Java through the ISO... any thoughts about resurrecting that effort - with the GPL'd version serving as the reference implementation?

jwenting
Offline
Joined: 2003-12-02
Points: 0

>
> However, my personal concern is that chosing such
> restrictive (or free, depending on your POV) license
> as GPL could limit uses of this implementation.
>

it would prevent Java from being used for anything that's not to be released under the GPL.
I'd call that more than "limit uses", I'd call it crippling.

> Some companies wouldn't touch anything GPL-related,
> for example. But then again, there are those who
> wouldn't use anything non-GPL.
>

GPL is counter (by design) to commercial use.

jacinto
Offline
Joined: 2004-07-28
Points: 0

>
> GPL is counter (by design) to commercial use.

Maybe is too late a comment, but I think we should
start by avoiding oversimplifications like the
statement above.

GPL does not prevent programmers for being paid
(whatever they want) for their codes. We still can
sale our software in any market. The difference is
that we have to give away open and without further
restrictions for re-distribution (just like
with BSD or the Apache license). The second
level difference (between GPL and Apache, for
instance) is "copyleft": whoever re-used the
code AND WANTED TO REDISTRIBUTE IT would have
to do it under the same conditions.

I think that the JVM should be licensed with GPL.
This will guarantee that the improvements come
back to the same community.

But, maybe, to compete with alternative libraries and
languages, is more convenient to release the Java
API under LGPL or some other licence without
copyleft.

atripp
Offline
Joined: 2003-07-15
Points: 0

> For example, ASF's inability to collaborate on a
> GPL-compatible class library led to Harmony losing
> many potential contributors and VMs, as they can't
> distribute code under the Apache license in their
> VMs. That's been a very sad process to go through. I
> hope Sun learns from our successes as well as from
> our failures.

Are you saying there have been some successes with respect to open-source Java implementations? We all know of the Classpath/Harmony failure and the ASFv2/GPLv2 incompatibility failure. What "success" is it that Sun that Sun should learn from?
falde
Offline
Joined: 2006-11-05
Points: 0

>
> Are you saying there have been some successes with
> respect to open-source Java implementations? We all
> know of the Classpath/Harmony failure and the
> ASFv2/GPLv2 incompatibility failure. What "success"
> is it that Sun that Sun should learn from?
>

Mono. There you have an interesting project. With its java-like nature it would also be good if JDK and Mono had a compatible license so they could share components.

abramsh
Offline
Joined: 2004-08-24
Points: 0

> I don't see how other FSF-approved licenses (like
> CDDL) would not satisfy your requirements, though.

The problem with CDDL is that, depending on who you are, there are certain restrictions that make it difficult to redistribute CDDL licensed code in binary form. For example, the burden of making the original source available.

I would urge those who are in the unenviable position of picking the license to pick one with more liberal redistribution than CDDL.

trembovetski
Offline
Joined: 2003-12-31
Points: 0

The original poster mentioned that:
> At a *minimum*, license Java as liberally as Classpath+GCJ. (ie, FSF approved, GPL compat, DFSG compliant).

Then he listed a bunch of requirements, which GPL apparently satisfies.

My point was that CDDL also satisfies all of them.

Or may be I just fail to see how CDDL is different from GPL in the sense you mention:
> For example, the burden of making the original source available.

Also, my [limited] understanding is that you only need to make available CDDL-licensed files which you modified.

Thanks,
Dmitri

hubick
Offline
Joined: 2006-08-15
Points: 0

> The original poster mentioned that:
> > At a *minimum*, license Java as liberally as Classpath+GCJ. (ie, FSF approved, GPL compat, DFSG compliant).
> My point was that CDDL also satisfies all of them.

I agree that the CDDL will suffice as the bare *minimum*.

I also stated that Sun has always seemed to have done the bare minimum to keep me from defecting, and that I am NOT very happy about it. I'm really hoping that trend doesn't continue.

If you look at the more specific list I wrote in the sixth post, you will see that GPL Compatibility is a strong desire as well.

I would ideally like to see code shared back and forth between Sun, Harmony, and Classpath, etc.

As others have stated WRT the CDDL, I think a CDDL only license is one sided, in that Sun could use GPL software components in their JVM, but then wouldn't let the JVM components be used in GPL software. That kind of attitude doesn't exactly foster community building though. What would be my incentive to contribute to a project like that, instead of to GCJ+Classpath? If I want as many people to benefit from my contributions as possible, GPL+Apache gets that work into more hands than just CDDL does.

I think CDDL+GPL (w classpath exception, or LGPL) would give me most of what I want. CDDL+GPL+Apache might be good enough to not drive away Harmony folks and their customers, and thus make everyone happy. If you go GPL+Apache though, I don't know what CDDL offers in addition.

trembovetski
Offline
Joined: 2003-12-31
Points: 0

> I think a CDDL only license is one sided, in that Sun could use GPL software components in their JVM, but then wouldn't let the JVM components be used in GPL software.

Um. That's not correct to my knowledge. CDDL-licensed code can not use GPL-licensed code (and vice versa).

Thanks for your comments, btw. Folks who make the decisions do read these forums.

Dmitri

robilad
Offline
Joined: 2004-05-05
Points: 0

Dmitri, code A using GPL+linking exception can be used by CDDL licensed code B (or code under any other license), without A imposing any requirements on the license of B.

That's by design of the linking exception licensing mechanism, which has been created back in the early days of gcc for the small amount of 'glue code' between an operating system, and an executable compiled by gcc.

The effects of GPL+linking exception are in practice very similar to those of CDDL: it turns GPL into a file-based license.

hubick
Offline
Joined: 2006-08-15
Points: 0

Using http://rfc.net/rfc2119.html terms, for me personally to be satisfied with the license:

- Those wishing to bundle the Java implementation to execute their applications MUST NOT be forced to open source their applications.
- The Java implementation MUST be licensed so that it can be distributed with a Linux distro like Debian (DFSG).
- Everyone MUST have the ability to freely patch and ship changes to the Java implementation themselves.
- Users MAY be required have their modifications pass some compatibility test in order to call it Java (tm).
- Users who modify and extend the Java implementation MAY be forced to contribute those changes back to the community.
- The Java implementation SHOULD be able to be intregrated into, and distributed/sold with, other GPL and LGPL software.
- The Java implementation MAY, or even SHOULD, be dual/multi-licensed. Any given user may not understand the terms of all the license choices offered, but given several popular alternatives there is more chance that user will understand one of the choices, and consider it acceptable.

Given my limited understanding of the current world, I personally would vote for LGPL (maybe requires a Classpath type clause?), or dual LGPL+Apache. I think preferably LGPL 3 and/or Apache 2 so that associated patent and compatibility issues will hopefully be in a more understandable state.

leouser
Offline
Joined: 2005-12-12
Points: 0

'- The Java implementation MUST be licensed so that it can be distributed with a Linux distro like Debian (DFSG).'

I thought this was already happening with Debian? Or am I confusing their inclusion to download the JDK with "distribution".

"- Users MAY be required have their modifications pass some compatibility test in order to call it Java (tm)."

I would hope if there was some freedom on this that there would be some of constraints on what you could modify and still call it "Java". I wouldn't want someone ripping out the security in the JDK and have some poor unsuspecting user like me suddenly find his system trashed by a faux-Java VM.

leouser

hubick
Offline
Joined: 2006-08-15
Points: 0

> '- The Java implementation MUST be licensed so that it can be distributed with a Linux distro like Debian (DFSG).'
>
> I thought this was already happening with Debian? Or am I confusing their inclusion to download the JDK with "distribution".

http://www.debian.org/doc/manuals/debian-java-faq/ch5.html#s-license-con...

'To quote one open source developer, the SCSL is "about as free as the former Soviet Union".'

leouser
Offline
Joined: 2005-12-12
Points: 0

Im not too deeply into watching Debian, but the last I heard Java was part of their non-free archive. Maybe I missed some event where it was removed. I suppose being in the non-free section means it isn't part of the distribution?

leouser

robilad
Offline
Joined: 2004-05-05
Points: 0

That's right. non-free is not part of Debian.

From the Debian Social Contract:

We acknowledge that some of our users require the use of works that do not conform to the Debian Free Software Guidelines. We have created "contrib" and "non-free" areas in our archive for these works. The packages in these areas are not part of the Debian system, although they have been configured for use with Debian.

Message was edited by: robilad

trembovetski
Offline
Joined: 2003-12-31
Points: 0

Thanks for the feedback.

I don't see how other FSF-approved licenses (like CDDL) would not satisfy your requirements, though.

> it's come down to this: I don't really care what you do anymore!

Obviously, you do, if you took the pains to write all this.

Thank you,
Dmitri

robilad
Offline
Joined: 2004-05-05
Points: 0

It'd be good not to have yet another license proliferation issue to worry about, and to have three different class library implementations (Classpath, Harmony, Sun) under three different licenses. That just makes sharing code harder.

For example, ASF's inability to collaborate on a GPL-compatible class library led to Harmony losing many potential contributors and VMs, as they can't distribute code under the Apache license in their VMs. That's been a very sad process to go through. I hope Sun learns from our successes as well as from our failures.

trembovetski
Offline
Joined: 2003-12-31
Points: 0

> That just makes sharing code harder.

This is true to an extent. Chosing one of the licenses used by Harmony or Classpath also makes sharing code harder, right? If it's GPL -> the project can't share code with Harmony. If it's APL -> can't share with Classpath.

However, my personal concern is that chosing such restrictive (or free, depending on your POV) license as GPL could limit uses of this implementation.

Some companies wouldn't touch anything GPL-related, for example. But then again, there are those who wouldn't use anything non-GPL.

Good thing I'm not the one making the choice. My head would explode.

Thanks,
Dmitri

robilad
Offline
Joined: 2004-05-05
Points: 0

Indeed. Both projects should be able to use and work on anything both GPLv2/v3 and Apache compatible - be it through dual licensing, or through a common middle ground (apache license with a patent retaliation exception, or ability to dual-license under the GPL, or ...).

There are a lot of ways to make this happen, and Sun could afford being more flexible and inclusive than either ASF or FSF could afford to be, which wouldn't be a bad thing for anyone, I think. There is an opportunity for Sun to be that harmonizing, unifying force, something we failed to achieve between Apache and Classpath, unfortunately.