Skip to main content

Is anyone else bothered by the JCA?

26 replies [Last post]
dhall
Offline
Joined: 2006-02-17

Here's my concern. I've been working for more than two years on a library that may have application within JDNC. The library is published under the same license as JDNC (LGPL), although there are a number of licenses that would be compatable. I don't really feel that it is appropriate that I sign over joint ownership of my copyrights in the library in order to simply get someone at Sun to look at it.

I could just as easily host a mirror of JDNC on another server and post any changes to it there, at least as far as the discussion phase would go. Would the Sun employees be able to view such a combination on another server and participate in any discussion that arises?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Adrian Sutton

> 5.
> provide a regularly-updates version of the project on a public Sun
> server. Fix java-webstart to allow it to use 1 global jar for all
> projects (possibly with versioning) and not require each project that
> uses it to ship it separately.

I definitely like this approach however it is not much above making
everyone ship it separately. My reasoning for saying that is that a
huge number of Java applications are not deployed via WebStart and thus
don't use the WebStart cache. I love the idea of a central repository
of jars that this hints at and that Patrick Wright talked about.

This option does however avoid my main concern by making it simple to
specify a different version of JDNC than the version that Sun is
currently shipping. Also note that having the latest version isn't
always desired - often applications want an older version that doesn't
exhibit a particular bug or that provides older APIs that have since
been modified or removed.

> [Message sent by forum member 'zander' (Thomas Zander)]

Regards,

Adrian Sutton.

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Mark Davidson

Adrian, Patrick,

Thanks for your comments.

On 07/23/2004 06:15 AM, Adrian Sutton wrote:
>> 5.
>> provide a regularly-updates version of the project on a public Sun
>> server. Fix java-webstart to allow it to use 1 global jar for all
>> projects (possibly with versioning) and not require each project that
>> uses it to ship it separately.

I'm not sure what the issue is with Java WebStart, but the library
approach of using JWS seems to work fine.

I propose that we make the JDNC runtime as a shared library hosted at
javadesktop.org. I've hinted at this on the deployment page:

http://wiki.java.net/bin/view/Javadesktop/JDNCDeploy

Using a shared library has the advantage of having the end user download
it once. All jdnc applications that reference this runtime - even if it
originates from different servers - will not pay the penalty of
downloading the runtime if it already exists in the cache.

This mechanism would make the it trivial to download of the actual xml
jdnc documents and application specific jar files. JDNC applications
could generate less network traffic than html generated UIs.

> I definitely like this approach however it is not much above making
> everyone ship it separately. My reasoning for saying that is that a
> huge number of Java applications are not deployed via WebStart and thus
> don't use the WebStart cache.

We would not make the WebStart library the exclusive way of deploying
applications. However, we have been experimenting with the library
approach internally to mitigate the size of the JAX-RPC runtime. James
just let us know that JXTA takes this approach as well.

I think there is still some work to do to fully understand the security
parameters and implications. For example, does the runtime have to be
signed if the developer supplied classes require access to local
resources? If we provide a signed runtime then the user will be faced
with granting access to 2 certificates.

> I love the idea of a central repository
> of jars that this hints at and that Patrick Wright talked about.
>
> This option does however avoid my main concern by making it simple to
> specify a different version of JDNC than the version that Sun is
> currently shipping. Also note that having the latest version isn't
> always desired - often applications want an older version that doesn't
> exhibit a particular bug or that provides older APIs that have since
> been modified or removed.

Versioning of the runtime is based on the url/location of the runtime
jnlp. For example, 0_5 is the current release, 0_5_1 could be a patch.
The jdnc developer who writes/hosts the jnlp can decide which version of
the runtime to use. They would upgrade by changing the version
referenced in the jnlp and the end user will get it.

--Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Adrian Sutton

> I'm not sure what the issue is with Java WebStart, but the library
> approach of using JWS seems to work fine.

Excellent, I wasn't aware that this was possible though mostly I just
hadn't thought of doing it before now.

> I propose that we make the JDNC runtime as a shared library hosted at
> javadesktop.org. I've hinted at this on the deployment page:

This is definitely an ideal solution for WebStart apps.

> We would not make the WebStart library the exclusive way of deploying
> applications. However, we have been experimenting with the library
> approach internally to mitigate the size of the JAX-RPC runtime. James
> just let us know that JXTA takes this approach as well.

This approach may actually work with applets as well, though I haven't
thought to try it. Of course the reference would be directly to the
jar instead of to a JNLP file.

> I think there is still some work to do to fully understand the
> security parameters and implications. For example, does the runtime
> have to be signed if the developer supplied classes require access to
> local resources? If we provide a signed runtime then the user will be
> faced with granting access to 2 certificates.

I would suggest making both available. Having a combination of signed
and unsigned jars in an application is a real headache so most signed
apps will want a version that is signed. Most unsigned apps will want
to avoid the user seeing any security dialogs and hence want an
unsigned version. Of course for those that want their users to only
see one security dialog they would have to sign the jar themselves and
serve it from their own server (thus missing out on the advantages of
the shared library system).

What would be really nice is an option in JNLP to merge all security
dialogs into one initial dialog. This would probably only work with
jars that were downloaded eagerly - lazy download jars would display
their own security dialog when they are downloaded. I doubt changes
would be needed to the actual JNLP spec for this (unless we wanted to
make the combined dialog optional), a particular JNLP implementation
should be able to make this work without any extra information.

> Versioning of the runtime is based on the url/location of the runtime
> jnlp. For example, 0_5 is the current release, 0_5_1 could be a patch.
> The jdnc developer who writes/hosts the jnlp can decide which version
> of the runtime to use. They would upgrade by changing the version
> referenced in the jnlp and the end user will get it.

Should have thought of that myself actually. Good idea. I would add
to this:

* signed/unsigned
* latest - for those who like to live on the wild side and
automatically get whatever updates are available.
* An URL for each major revision that automatically upgrades to the
latest bug fix for that version.

I'm essentially thinking about an URL based equivalent of JNLP's 1.3*,
1.3+ type specifications. Sadly, each of these different URLs would
result in a new jar being downloaded instead of just referring to the
already downloaded jar. Sounds like another feature request of the
JNLP spec.

This is starting to get off-topic into ways to improve JNLP but I think
the basic idea of having centrally stored version of JDNC files
available in multiple versions should be a very good solution for
deployment using currently available tools.

> --Mark

Regards,

Adrian Sutton.
----------------------------------------------
Intencha "tomorrow's technology today"
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.com
[PGP.sig]

Mark Davidson

On 07/23/2004 10:49 PM, Adrian Sutton wrote:
>> We would not make the WebStart library the exclusive way of deploying
>> applications. However, we have been experimenting with the library
>> approach internally to mitigate the size of the JAX-RPC runtime. James
>> just let us know that JXTA takes this approach as well.
>
> This approach may actually work with applets as well, though I haven't
> thought to try it. Of course the reference would be directly to the jar
> instead of to a JNLP file.

Correct. The shared library approach would work with applets. Here is an
except from a document that I wrote describing this mechanism:

"Shared Libraries using the Plugin

To some extent, sharing libraries currently exists in JavaPlugin. The
plugin cache file selection is based on the URL of the file. Therefore
if multiple applets refer to a jar file from same URL, they all use the
same cached jar file.

For example, if an Applet uses libraries delivered by Sun which
represents web services client runtime and the Java Look and Feel
graphics, the applet tag may look like:

[code]
archive="myapp.jar,
http://java.sun.com/products/jlf/jlfgr-1_0.jar,
http://java.sun.com/webservices/1.0/jwsdp-client.jar"
code="my.domain.Main.class"/>
[/code]

Another site referencing the same set of jar files would look like:

[code]
archive="myotherapp.jar,
http://java.sun.com/products/jlf/jlfgr-1_0.jar,
http://java.sun.com/webservices/1.0/jwsdp-client.jar"
code="my.other.another.Main.class"/>
[/code]

The result is that the same jar file the Plugin cache would be used in
both applications.

>> I think there is still some work to do to fully understand the
>> security parameters and implications. For example, does the runtime
>> have to be signed if the developer supplied classes require access to
>> local resources? If we provide a signed runtime then the user will be
>> faced with granting access to 2 certificates.
>
> I would suggest making both available. Having a combination of signed
> and unsigned jars in an application is a real headache so most signed
> apps will want a version that is signed. Most unsigned apps will want
> to avoid the user seeing any security dialogs and hence want an unsigned
> version. Of course for those that want their users to only see one
> security dialog they would have to sign the jar themselves and serve it
> from their own server (thus missing out on the advantages of the shared
> library system).

Agreed. However, all applications originating from the developers server
would take advantage of the shared library approach. The trade off is
between convenience (Sun hosted libraries) vs. control.

> What would be really nice is an option in JNLP to merge all security
> dialogs into one initial dialog. This would probably only work with
> jars that were downloaded eagerly - lazy download jars would display
> their own security dialog when they are downloaded. I doubt changes
> would be needed to the actual JNLP spec for this (unless we wanted to
> make the combined dialog optional), a particular JNLP implementation
> should be able to make this work without any extra information.

I just had a hallway conversation with one of the web start engineers
about this issue. Currently, they don't support this and don't have any
plans to. However, we are going to take your request and turn it into an
RFE for discussion. The engineer will be meeting with the Java security
folks this week (by coincidence) and has promised to bring this up.

My initial impression is that having a common dialog is a potential
security risk. Ideally, each certificate should be scrutinized and
determined if they originate from legitimate certification authorities.
I would think that most end users don't really understand the
implications of granting unrestrictive access to their computers
resources. Making it more convenient by consolidating all the security
certificates in one dialog with a single "OK" button would be dangerous.
A cracker can slip in a malicious self certified jar file in the midst
of legitimate resources.

However, this could be designed so that the single dialog is a
convenient way for granting access to all certificates individually.
Perhaps the dialog could also alert the user about the existence of
"Anonymous" self signed certificates.

>> Versioning of the runtime is based on the url/location of the runtime
>> jnlp. For example, 0_5 is the current release, 0_5_1 could be a patch.
>> The jdnc developer who writes/hosts the jnlp can decide which version
>> of the runtime to use. They would upgrade by changing the version
>> referenced in the jnlp and the end user will get it.
>
> Should have thought of that myself actually. Good idea. I would add to
> this:
>
> * signed/unsigned
> * latest - for those who like to live on the wild side and automatically
> get whatever updates are available.
> * An URL for each major revision that automatically upgrades to the
> latest bug fix for that version.

These are good suggestions. All file the RFE for this based on your
descriptions.

>
> I'm essentially thinking about an URL based equivalent of JNLP's 1.3*,
> 1.3+ type specifications. Sadly, each of these different URLs would
> result in a new jar being downloaded instead of just referring to the
> already downloaded jar. Sounds like another feature request of the JNLP
> spec.

This could be hashed out from the URL side - which is more a matter of
deployment policy that we can control.

Given the scenario in which we have a release train like this:

0.5 - latest release (stable)
0.5.1 - beta release
0.5.1-07_26_04 - nightly/weekly build
0.6 - development (experimental)

we could have URLs which map to:

.../0_5_0/... -> 0.5 stable and fixed for perpetuity.
.../0_5/... -> currently 0.5 but will point to 0.5.1 when released.
.../latest/... -> 0.5.1-07_26_04
.../0_5_1/... -> 0.5.1-07_26_04 will be stable and fixed when 0.5.1
is released.
.../development/ -> 0.6 will point to the leading release for
development/testing purposes.

This is just a proposal. I'm sure we can rejig this policy that will
satisfy the requirements of the community.

> This is starting to get off-topic into ways to improve JNLP but I think
> the basic idea of having centrally stored version of JDNC files
> available in multiple versions should be a very good solution for
> deployment using currently available tools.

Agreed. This will save bandwidth and will reduce the startup time of
WebStart deployed apps.

--Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Adrian Sutton

> Correct. The shared library approach would work with applets. Here is
> an except from a document that I wrote describing this mechanism:

Excellent. I'll have to rework our build process again to take
advantage of this then.

> I just had a hallway conversation with one of the web start engineers
> about this issue. Currently, they don't support this and don't have
> any plans to. However, we are going to take your request and turn it
> into an RFE for discussion. The engineer will be meeting with the Java
> security folks this week (by coincidence) and has promised to bring
> this up.

I've got to get me one of those web start engineers to put in my
hallway, they seem quite useful. :) Thanks for passing this on. Will
the RFE be public and is there anything I can do to help?

> My initial impression is that having a common dialog is a potential
> security risk. Ideally, each certificate should be scrutinized and
> determined if they originate from legitimate certification
> authorities. I would think that most end users don't really understand
> the implications of granting unrestrictive access to their computers
> resources. Making it more convenient by consolidating all the security
> certificates in one dialog with a single "OK" button would be
> dangerous. A cracker can slip in a malicious self certified jar file
> in the midst of legitimate resources.
>
> However, this could be designed so that the single dialog is a
> convenient way for granting access to all certificates individually.
> Perhaps the dialog could also alert the user about the existence of
> "Anonymous" self signed certificates.

Yes, I see three ways of going about the single dialog:

1. Effectively repeat the information that is shown in the current
dialogs but in a single window. So the dialog would contain a list of
certificates with a warning on any that are unsigned etc.

2. Provide an aggregate of the information. So if any jar is
self-signed or has an expired certificate a warning is displayed that
"some jars are signed by an untrusted authority". If all jars are
signed by a trusted cert and haven't expired then the dialog states
that as an aggregate. Obviously the user should be able to expand the
detail to view each certificate individually.

3. If all jars are trusted and valid then display a single dialog in
either style above but if any of the jars is untrusted or expired then
separate dialogs are displayed.

I think 3 is the best option, probably displaying the certs in the
style of option 1 when they are all trusted. That makes it impossible
to slip a malicious self certified jar in the midst of legitimate
resources (though you can still slip a malicious trusted jar file in).

>> Should have thought of that myself actually. Good idea. I would add
>> to this:
>> * signed/unsigned
>> * latest - for those who like to live on the wild side and
>> automatically get whatever updates are available.
>> * An URL for each major revision that automatically upgrades to the
>> latest bug fix for that version.
>
> These are good suggestions. All file the RFE for this based on your
> descriptions.

Again feel free to point me over at relevant RFEs and discussions.

> we could have URLs which map to:
>
> .../0_5_0/... -> 0.5 stable and fixed for perpetuity.
> .../0_5/... -> currently 0.5 but will point to 0.5.1 when released.
> .../latest/... -> 0.5.1-07_26_04
> .../0_5_1/... -> 0.5.1-07_26_04 will be stable and fixed when 0.5.1
> is released.
> .../development/ -> 0.6 will point to the leading release for
> development/testing purposes.
>
> This is just a proposal. I'm sure we can rejig this policy that will
> satisfy the requirements of the community.

I like that URL layout and it provides enough flexibility. However it
would be nice to be able to specify "anything above 0_5_0" and have it
use a version that the user has already downloaded if available,
otherwise download the latest stable version. Similarly it would be
good to be able to say "anything from the 0_5_0 branch" so that if the
user has 0_5_0 downloaded they will use that but if they have 0_5_1
downloaded that will be used and if they don't have it at all 0_5_1 is
downloaded. Currently that's not possible with WebStart resources
other than the JRE but it might be nice to have if WebStart libraries
become more commonly used.

I probably should go log a RFE bug on this but I'm not sure I've
thought it out carefully enough yet.

> --Mark

Regards,

Adrian Sutton.
----------------------------------------------
Intencha "tomorrow's technology today"
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.com
[PGP.sig]

Danno Ferrin

Adrian Sutton wrote:

[snip]

>> we could have URLs which map to:
>>
>> .../0_5_0/... -> 0.5 stable and fixed for perpetuity.
>> .../0_5/... -> currently 0.5 but will point to 0.5.1 when released.
>> .../latest/... -> 0.5.1-07_26_04
>> .../0_5_1/... -> 0.5.1-07_26_04 will be stable and fixed when
>> 0.5.1 is released.
>> .../development/ -> 0.6 will point to the leading release for
>> development/testing purposes.
>>
>> This is just a proposal. I'm sure we can rejig this policy that will
>> satisfy the requirements of the community.
>
>
> I like that URL layout and it provides enough flexibility. However it
> would be nice to be able to specify "anything above 0_5_0" and have it
> use a version that the user has already downloaded if available,
> otherwise download the latest stable version. Similarly it would be
> good to be able to say "anything from the 0_5_0 branch" so that if the
> user has 0_5_0 downloaded they will use that but if they have 0_5_1
> downloaded that will be used and if they don't have it at all 0_5_1 is
> downloaded. Currently that's not possible with WebStart resources
> other than the JRE but it might be nice to have if WebStart libraries
> become more commonly used.
>
> I probably should go log a RFE bug on this but I'm not sure I've
> thought it out carefully enough yet.

[snip]

WebStart has a versioning specification that can support "any 0.5" or
"0.5.1 or greater" The way I see it fitting into this spec is to map it
to ... and have the jnlp versioning handle the serving of particular
versions, bhandeling the specified "?version-id=0.5.0+0.5.1.*" query
param. The developers pack has a servlet that handles the diffs
automatically (including incramental diff jars) at
http://java.sun.com/products/javawebstart/download-jnlp.html. You could
use the specified directory mapping and then use the version.xml file to
point the non-pathed ones to the right version.

--Danno

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Patrick Wright

Hi

I am glad people are addressing this question, just wanted to throw in a
couple of bits.

1) There needs to be a distinction between
a) 'useful and approved' libraries
b) 'official extensions'
c) 'core'

in the Java environment. Many Apache libraries would fit in category a),
that is, they are widely used, production quality, look good, but are not
officially part of the Java distribution. Java 3D would be in category b),
that is, a library that is a standard issued by Sun, but which doesn't
ship to people that don't need it. c) would include all libraries that Sun
considers part of a standard Java environment, and which defines the a
compatibile version of Java.

My suggestion is that JNDC is a category a) or b), but certainly not a c).
The question is then how to make category a) and b) easy to install,
distribute, etc.

There are complaints that too many things are winding up in category c),
and that the core is too large--both to understand and as a download. We
are probably a few years away from having networks so reliable that we can
always download on demand, so it makes sense to have more stuff in one
download when possible.

But what we appear to need, is the ability to have a central repository of
versioned packages, a way to install and uninstall them. The basics would
include
a) Standard means to identify packages available for distribution
b) Package signing
c) Package checksums
d) Standard-unique naming and versioning per package

A suggested approach
a) Distribution occurs through websites using JNLP to declare official
package name and version; should support signing and MD5 or other checks.

b) Libraries are loaded into a central Java package repository on the
user's machine. The repository is divided by package, and within package
by version, possibly with distributor at the top, so
/javadepo/apache.org/commons/1.5.1/jar/commons-1.5.1.jar

c) The repository can be loaded or unloaded by any approved process,
including WebStart, a CLI, or a Swing GUI. You might receive components on
a CD, through a downloaded Jar, etc. Checksums should ensure that the same
jar is never re-loaded into the repository.

d) When webstarting, dependent libraries can be downloaded into the
repository, in this case, JDNC would be an example. In case the standard
source for the file is unavailable, the target library could include a
mirror of the file, as long as checksum is respected.

Ideally there would be a way to see which libraries are not in use and
remove them, but that would be a whole nother level of control.

The Apache tool Maven does something like this. I am not pushing Maven (I
have nothing to do with them), but I have to say, I have a *lot* of
3rd-party (and Sun non-standard) libraries on my machine, and it is a rats
nest in there.

I think that .Net has some approach for this, and I haven't heard of a JSR
related to it.

As far as JDNC, I am not saying all of the above has to be in place
immediately, but perhaps that we start moving towards something like that.

I realize some of the proposal appears in related forms--there are JNLP
caches and applet caches, the JRE extension mechanism, etc.

Patrick

> I wanted to pick up on a comment made earlier by Joshua about including
> JDNC in the JRE as it hits upon some concerns that I have.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

zander
Offline
Joined: 2003-06-13

>
> I'm not really sure I know what the solution to this
> problem is but
> wanted to flag the issue early so that people can
> start thinking about
> it. Some possible options I see are:
[snipped]

5.
provide a regularly-updates version of the project on a public Sun server. Fix java-webstart to allow it to use 1 global jar for all projects (possibly with versioning) and not require each project that uses it to ship it separately.

James Todd

What is the motivation for "1 global jar" given that WebStart/JNLP can
"chain" JNLP files across projects? We do this in JXTA all the time:

http://weblogs.java.net/pub/wlg/790

- james

jdnc-interest@javadesktop.org wrote:
>>I'm not really sure I know what the solution to this
>>problem is but
>>wanted to flag the issue early so that people can
>>start thinking about
>>it. Some possible options I see are:
>
> [snipped]
>
> 5.
> provide a regularly-updates version of the project on a public Sun server. Fix java-webstart to allow it to use 1 global jar for all projects (possibly with versioning) and not require each project that uses it to ship it separately.
> ---
> [Message sent by forum member 'zander' (Thomas Zander)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=18790&#18790
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>

--
Java == platform independence
XML == application independence
JXTA == network independence

Secure End-to-End Computing

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Adrian Sutton

I wanted to pick up on a comment made earlier by Joshua about including
JDNC in the JRE as it hits upon some concerns that I have.

> I don't think this likely since it's quite easy to version the APIs
> and say that version X will be in JRE y, but you can use a more recent
> version if you want to. Remember when the XML APIs moved into the JRE?

The problem with this is that when JDNC is moved into the JRE it winds
up on the boot classpath and becomes difficult or impossible to
override. This caused a lot of problems for the Xalan project when it
was included in the JRE because most people don't understand the
extension override mechanism and even when they do, it makes
application deployment more difficult. Worse still, for applets
there's no way to override the library.

I was very pleased to see that the version of Xerces shipped with JRE
5.0 was moved into a different namespace so that it's possible to
easily switch between the JRE version and a different version, however
that's not really an option with JDNC because it has public APIs that
would be broken.

I'm not really sure I know what the solution to this problem is but
wanted to flag the issue early so that people can start thinking about
it. Some possible options I see are:

1. Don't include JDNC in the JRE.
Pros: Really simple.
Cons: Every JDNC app has to ship a copy of JDNC
Reduces exposure of JDNC
Leaves Swing as-is instead of benefiting from the JDNC improvements.

2. Change the JDNC package when including it in the JRE.
Pros: Avoids problem while still allowing Swing to benefit from
improvements.
Cons: Existing apps will still have to ship the JDNC jar file or
change all their import statements. The upside of this is that
existing apps won't break as they'll be shipping the jar anyway.

3. Make it really simple to change JDNC's package so developers can put
the version they want in their own package and thus avoid the version
in the JRE.
Pros: Doesn't affect users who just want a version of JDNC or are
happy with the JRE
Allows Swing to benefit from the improvements.
Cons: Difficult to achieve, particularly when reflection is used.
Can make general development more difficult.

4. Do nothing and let people deal with it themselves.
Pros: Simplest for the JDNC team.
Cons: Annoying for users who have to deal with the problem.

I know the popular opinion is that WebStart is the solution to
everything and people shouldn't use applets at all but for a number of
things applets are the only solution so it would be good to at least
consider how to deal with the issues even if the JDNC team decides to
take option 4.

Personally, my favorite out of those is option 3, most likely
implemented by a fairly simple find/replace on the package name across
files. If that were supported by being able to perform the replace,
build and run the tests easily (and hopefully automatically every so
often) then it should be pretty simple to manage.

Any thoughts?

Regards,

Adrian Sutton.
----------------------------------------------
Intencha "tomorrow's technology today"
Ph: 38478913 0422236329
Suite 8/29 Oatland Crescent
Holland Park West 4121
Australia QLD
www.intencha.com
[PGP.sig]

rameshgupta
Offline
Joined: 2004-06-04

> I wanted to pick up on a comment made earlier by
> Joshua about including JDNC in the JRE as it hits upon
> some concerns that I have.
>
[snip]
>
> The problem .. is that when JDNC is moved into the JRE it winds
> up on the boot classpath and becomes difficult or
> impossible to override. This caused a lot of problems for the
> Xalan project when it was included in the JRE because most people don't
> understand the extension override mechanism and even when they do,
> it makes application deployment more difficult. Worse still,
> for applets there's no way to override the library.
>
[snip]
> I'm not really sure I know what the solution to this
> problem is but ... Some possible options I see are:
>
> 1. Don't include JDNC in the JRE...
>
> 2. Change the JDNC package when including it in the JRE...
>
> 3. Make it really simple to change JDNC's package so developers can
> put the version they want in their own package and thus
> avoid the version in the JRE...
>
> 4. Do nothing and let people deal with it themselves...
>
> Personally, my favorite out of those is option 3, most likely
> implemented by a fairly simple find/replace on the package name
> across files. If that were supported by being able to
> perform the replace, build and run the tests easily (and hopefully
> automatically every so often) then it should be pretty simple to manage.
>
> Any thoughts?
>
> Regards,
>
> Adrian Sutton.

These are well thought-out options, though I like 4 the least :-) My preference (in order): 2, 3, 1, 4

Ramesh

dhall
Offline
Joined: 2006-02-17

Another question for Sun -- and this shows that I've been reading _way_ too much Groklaw. Is the JCA specific enough to qualify as a copyright assignment for specific files?

James Todd

I find the following puzzling in the context of an open source project:

>fixed all those annoying bugs in the public repository long ago. Also; how much time >are you willing to spent discussing a change in your own API with a Sun engineer that >has a different look upon things.

Discussing designs/features/bugs/et al on an open source project, licensing
issues aside for the moment, regardless as to one's motiviations be it
personal or sponsorred is moot. It is about collaboration, for the betterment
of all ... so that we can build better/richer apps.

If you contribute code/ideas/etc then defending your work and incorporating
feedback is all part of the process ... a "good" process by all measures.

This project is a good thing. It sets precedents on a number of fronts. I
very much want (and plan) to use the derivatives. I see no reason to stand
in the way of progress regardless as to the reasons individuals are contributing
code here, be it Sun sponsored or otherwise. This is no different then any
number of other open projects Sun employees contribute to. As a company we
are collectively quite good at this process, bar none, and this project is
no different. Feel free to talk and share ideas. People listen. Be prepared
to recieve feedback. It is part of the process ... I repeat ... a good process.

- james

jdnc-interest@javadesktop.org wrote:
>>Hey Zander,
>>
>>
>>>I write open source software because I want to share
>>>my work and want to build upon others work (to stand
>>>on the shoulders of giants). To keep the pool of
>>>shared code healthy I feel that others can only
>>>derive from my work if they agree to do the same.
>>
>>What I don't understand is how allowing Sun to have
>>joint copyright ownership would cause the pool to
>>become unhealthy. IF you suspect that Sun would
>>intentially take LGPL code (or any other license, for
>>that matter), take what they want and not contribute
>>back, then I can understand a little bit of
>>sqeemishness.
>
>
>
> First of all; the fact that you can't base the LGPL project on other LGPL code is a bigger loss IMO then the second point.
> To answer your question; Sun has made it clear it does want to re-release the LGPL under a non LGPL licence. In the JRE specifically. The StartOffice product is an example of this happening in the past. The GPL does not allow the taking of others work and basing a product on that without opening those changes to the public for a reason.
>
>
>>I cannot see the worst case scenario being all that
>>bad. Lame, but not bad. Bad would be if you lost all
>>copyright ownership all together.
>
>
> That indeed is the worst case; but is the proposal so much better? You can't just include an open source component to make better and build on top of. When the JRE comes out your 17 month old code is still found on millions of desktopns while you fixed all those annoying bugs in the public repository long ago. Also; how much time are you willing to spent discussing a change in your own API with a Sun engineer that has a different look upon things.
> ---
> [Message sent by forum member 'zander' (Thomas Zander)]
>
> http://www.javadesktop.org/forums/thread.jspa?messageID=18215&#18215
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>

--
Java == platform independence
XML == application independence
JXTA == network independence

Secure End-to-End Computing

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

zander
Offline
Joined: 2003-06-13

Hi,

> zander wrote:
> > The whole idea of the LGPL is to keep your work free
> > and to keep others from highjacking it for their own
> > needs.
>
> I don't believe LGPL can prevent hijacking. And, in
> that respect, JDNC is equally vulnerable, right?

By hijacking I did not mean to create derivative works; thats fine in my opinion, as long as the licence is adhered to.
By hijacking I meant taking the code without adhering to the licence it was distributed under. As copyright owner you are free to change the licence. In effect the JCA allows Sun to ignore the LGPL (since they just became copyright holders). So this is not about any licence difference; this is about Sun asking us to sign an exception from the values LGPL guarantees the writer of a piece.

I write open source software because I want to share my work and want to build upon others work (to stand on the shoulders of giants). To keep the pool of shared code healthy I feel that others can only derive from my work if they agree to do the same. Naturally everyone can use the software without any restrictions.

The JCA requirement means the stuff in Suns CVS can not be based on any work in already in the LGPL pool, and at least one company can use/sell without giving back.

Hope this makes my former post clearer.

rbair
Offline
Joined: 2003-07-08

Hey Zander,

> I write open source software because I want to share
> my work and want to build upon others work (to stand
> on the shoulders of giants). To keep the pool of
> shared code healthy I feel that others can only
> derive from my work if they agree to do the same.

What I don't understand is how allowing Sun to have joint copyright ownership would cause the pool to become unhealthy. IF you suspect that Sun would intentially take LGPL code (or any other license, for that matter), take what they want and not contribute back, then I can understand a little bit of sqeemishness.

Personally, I don't think that this is really an issue. Sun has a pretty good history of opening up source (OpenOffice being one of many), and they are doing it a lot more (JDNC, JDIC, Solaris, etc).

Besides, even if they DID decide to shut down their open source projects and everything, we still have whatever the latest in CVS was for JDNC. In the classic open source spirit we can extend that code however is necessary (ala Firebird SQL/Interbase).

I cannot see the worst case scenario being all that bad. Lame, but not bad. Bad would be if you lost all copyright ownership all together.

zander
Offline
Joined: 2003-06-13

> Hey Zander,
>
> > I write open source software because I want to share
> > my work and want to build upon others work (to stand
> > on the shoulders of giants). To keep the pool of
> > shared code healthy I feel that others can only
> > derive from my work if they agree to do the same.
>
> What I don't understand is how allowing Sun to have
> joint copyright ownership would cause the pool to
> become unhealthy. IF you suspect that Sun would
> intentially take LGPL code (or any other license, for
> that matter), take what they want and not contribute
> back, then I can understand a little bit of
> sqeemishness.

First of all; the fact that you can't base the LGPL project on other LGPL code is a bigger loss IMO then the second point.
To answer your question; Sun has made it clear it does want to re-release the LGPL under a non LGPL licence. In the JRE specifically. The StartOffice product is an example of this happening in the past. The GPL does not allow the taking of others work and basing a product on that without opening those changes to the public for a reason.

> I cannot see the worst case scenario being all that
> bad. Lame, but not bad. Bad would be if you lost all
> copyright ownership all together.

That indeed is the worst case; but is the proposal so much better? You can't just include an open source component to make better and build on top of. When the JRE comes out your 17 month old code is still found on millions of desktopns while you fixed all those annoying bugs in the public repository long ago. Also; how much time are you willing to spent discussing a change in your own API with a Sun engineer that has a different look upon things.

Joshua Marinacci

>>I cannot see the worst case scenario being all that
>>bad. Lame, but not bad. Bad would be if you lost all
>>copyright ownership all together.
>
>
> That indeed is the worst case; but is the proposal so much better?
> You can't just include an open source component to make better and build on top of.
> When the JRE comes out your 17 month old code is still found on millions of
> desktopns while you fixed all those annoying bugs in the public repository
> long ago. Also; how much time are you willing to spent discussing a
> change in your own API with a Sun engineer that has a different look upon things.

I guess I honestly do not understand this controversy. In my mind, I
contribute to these Java.net projects because I want better libraries to
ship with my applications. I never plan to make money or sell tools. I
simply want the core library support to be better, because that makes my
applications better. In most cases eventually moving the code into the
core APIs improves the library and makes my life easier. Since shipping
code in the JRE requires a non-GPL license I have no trouble

The only downside I see is if Sun moved a project into the JRE and shut
down the open source project. I don't think this likely since it's quite
easy to version the APIs and say that version X will be in JRE y, but
you can use a more recent version if you want to. Remember when the XML
APIs moved into the JRE? Still, with the dual license it's possible
that could happen. In the event that it does we still have the latest
version in CVS to do with as we please. The code could never be stolen,
just forked, however unlikely.

- Joshua

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

dhall
Offline
Joined: 2006-02-17

I think I see both sides. In my case, I'd like that the code I contribute end up in the JDK someday -- one of the things I was doing at JavaOne was getting a feeling for the JCP and how much time and effort it would take and how likely it would be to succeed. I know in that case that I would have to assign copyrights.

But the need for JDNC and other projects that use a truly open source license is a little stickier, particularly up front. When the first few messages about having to sign the JCA came up, it was phrased along the lines that we'd have to sign the JCA before we could post code (and when reading that message in a forum, its natural to assume that means before posting code in the forum).

For code that I might submit that is truly meant to be an extension to JDNC and has no utility without it, then assigning copyright is no problem. For other code, taken from ongoing development projects, then Zander's points come into play. We know the cases that Sun has in mind now -- preserving the possibility of moving some of the code to be covered by the standard java license, for example. I actually don't have a problem with this, but I can see where a number of open-source developers would.

I would like to know from Sun that the joint ownership doesn't just flow toward Sun. For example, suppose that I submit a class from an ongoing project that Sun accepts into JDNC. Sometime later, a bug is found and Sun puts a bug fix into CVS. Can I then take the bug fix and port it back into the project from whence it came? Now further suppose that the class makes it into a product that Sun ships that is not distributed with an open source license -- what are my rights with respect to bug fixes as co-owner of the copyright in this case?

zander
Offline
Joined: 2003-06-13

> I would like to know from Sun that the joint
> ownership doesn't just flow toward Sun.

Licences being what they are they have to be clear before the writer 'explains' them.

> For example,
> suppose that I submit a class from an ongoing project
> that Sun accepts into JDNC. Sometime later, a bug is
> found and Sun puts a bug fix into CVS. Can I then
> take the bug fix and port it back into the project
> from whence it came?

The answer depends on where the bugfix is made. If the bugfix is made in the sourcetree of the JDK, you can't.
If the bugfix is made in the public CVS, you can, since the latter is automatically licenced under the LGPL, which you can use.

The other way around is harder; a bugfix made to that class in the external project can't be ported to the jdnc project without ALL copyright owners of that file (in my experience thats 3 to 6 people on average) agreeing to the JCA.

> Now further suppose that the
> class makes it into a product that Sun ships that is
> not distributed with an open source license -- what
> are my rights with respect to bug fixes as co-owner
> of the copyright in this case?

None whatsoever.

Roger Brinkley

jdnc-interest@javadesktop.org wrote:

> I know JDNC is not the only project that requires JCA with LGPL. JDIC
> does too. Anybody know of other projects? I am no fan of JCA myself,
> but I think it is important to have a healthy discussion and address
> people's concerns sooner rather than later :-)

Netbeans, OpenOffice, Java Games (the entire community), Java3D, Java
Media Frame Work, Java Advanced Imaging, Project Looking Glass, JDIC.
Basicly any open source project from Sun has a Joint Copyright Agreement.

All Sun sponsored open source projects have required a copyright
assignment similar to the one used by the Free Software Foundation. In
response to community concern, Sun has been working on an innovative way
to handle copyright assignment. The result is the JCA which has been
applauded by the OpenOffice.org and Netbeans communities.

To understand the advantage of the JCA, consider the problems Mozilla is
experiencing in trying to license its code base under a MPL/LGPL/GPL
tri-license without the benefit of copyright assignments. See:
http://www.mozilla.org/MPL/relicensing-faq.html. Requiring JCAs will
also give JavaDesktop community projects the flexibility to make their
code available under other licenses such as the SPL, MPL or the Apache
Software License in order to contribute portions of a JavaDesktop
community project to other projects.

The JCA requirement also provides for better enforcement of the each
project's license. Without copyright assignment, any court action
related to a JavaDesktop community project's code would require the
participation of all contributors as copyright holders. The JCA allows
Sun to represent the JavaDesktop community in any enforcement action,
while still allowing the community to participate at their choice as
joint copyright holders.

The JCA does not in any way change the rights or responsibilities of the
JavaDesktop community under the individual project licenses. Sun is only
requesting that you take one additional step to increase the JavaDesktop
community's flexibility, protect the JavaDesktop community code base and
make alternative licensing models possible by executing a JCA for any
contribution. In order for the JCA to work, it will be necessary to
obtain an assignment from all past (what few there might be), present
and future contributors.

Finally, we are in the process of creating a single JCA for all projects
that are in the JavaDesktop Community. Any Sun sponsored project will be
requiring the joint JCA for code contribution. Other projects will have
the option of enforcing the JCA or not.

Roger Brinkley
JavaDesktop Community Leader

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

dhall
Offline
Joined: 2006-02-17

[[ Snipped from the other thread: Applying Generics and Functors for Object Realization ]]

>> This sorta brings up the discussion issues that I
>> mentioned in the 'Is anyone else bothered by the
>> JCA?' thread.

> Personally, I too am bothered by the JCA, and I have
> raised issues surrounding this within Sun. But, I can't
> help agree with many of the points made in the Wired
> article, a link to which was posted by Mark Davidson in
> a separate thread: http://www.wired.com/wired/archive/12.07/linux.html?pg=6

> Perhaps the most convincing reason for the JCA is to
> force contributors to acknowledge that they have the
> authority to contribute whatever it is they are
> contributing, and to hold the accepting party harmless
> from claims by a third party.

--

(I hope you don't mind the thread jumping -- I thought that it was more appropriate to continue this part of the discussion over here.)

I understand completely the need to document that I own the copyrights to my work. It is an issue in open source development, and I can certainly understand Sun's hesitation to jump on code that might have questionable ownership. There are a lot of companies that try to assert ownership over every idea in your head. Thankfully, I've always been able to strike out that language and get agreement on the restriction that there must be clear overlap with work related activities before any question of ownership comes into play -- anything that I do on my own time with my own equipment is mine as long as it is not work related or uses company IP.

I'm not sure that in a lot of cases, you're really buying all that much value from the paperwork. I already assert copyright ownership by virtue of placing a notice in every file that I write. Now suppose that I agree to joint ownership and Sun uses my work to derive some econmic benefit. If one of my previous employers decides to go all SCO on us, then regardless of any paperwork between us, they'll go after Sun knowing the extent of my personal assets. If Sun were to use my work via the LGPL, then the same hypothetical previous employer would be no more or less likely to go after Sun. In either case, their first step is to attack the validity/ownership of my copyright, and my authority to grant anyone permission/ownership of any kind.

With all that said, a pretty good example to support Sun's desire to have joint copyright ownership is the way in which the GNU works. They pretty much require outright copyright assignment to them if you want to submit fixes to any GNU project.

One of the things that struck me was the apparent timing: it appears from the wording of the various messages related to the JCA and the JCA itself that Sun wanted ownership of the specific code in question before it would even enter into discussions of whether to use the code or not. For new work that is directly derived from JDNC (for example, an One-to-Many form control that contains records from many database records) I think this makes a fair amount of sense. It is somewhat more of an issue when considering projects that have been under development for some time.

zander
Offline
Joined: 2003-06-13

> With all that said, a pretty good example to support
> Sun's desire to have joint copyright ownership is the
> way in which the GNU works. They pretty much require
> outright copyright assignment to them if you want to
> submit fixes to any GNU project.

"They" are the FSF (Free Software Foundation) which owns various projects and licences them under the GNU licence.
Most GNU-licenced software does not belong to the FSF and has no-such restriction.

The Linux kernel, for example, does not have such a restriction. Note that the Linux kernel is an order of magnitude more complex then the whole j2se (200Mb for linux vs. 45Mb)

rameshgupta
Offline
Joined: 2004-06-04

> Here's my concern. I've been working for more than
> two years on a library that may have application
> within JDNC. The library is published under the same
> license as JDNC (LGPL), although there are a number
> of licenses that would be compatable. I don't really
> feel that it is appropriate that I sign over joint
> ownership of my copyrights in the library in order to
> simply get someone at Sun to look at it.
>
> I could just as easily host a mirror of JDNC on
> another server and post any changes to it there, at
> least as far as the discussion phase would go. Would
> the Sun employees be able to view such a combination
> on another server and participate in any discussion
> that arises?

Sure. Participation in discussions is not a problem. So, whether the discussions take place here or elsewhere, is moot. But if I were to believe the lawyers, Sun employees won't be able to accept any contributions to JDNC and fold them into the codebase that they are working on, as long as that code remains encumbered with a copyright that Sun is not party to.

zander
Offline
Joined: 2003-06-13

The whole idea of the LGPL is to keep your work free and to keep others from highjacking it for their own needs. Saying that you can't accept LGPL without that signature means you don't respect the LGPLs intentions. It means Sun wants to be able to control other peoples work without their say in the matter.

I would applaud that someone would download and open the sourcebase of the JDNC to be a fully compatible LGPL project without the encumbrance of Suns not-really-helpful commit policy.

rameshgupta
Offline
Joined: 2004-06-04

> The whole idea of the LGPL is to keep your work free
> and to keep others from highjacking it for their own
> needs.

I don't believe LGPL can prevent hijacking. And, in that respect, JDNC is equally vulnerable, right?

The idea behind LGPL is to loosen the restrictions placed by GPL so that your code is more palatable to a broader development community. This is supposed to give project owners a greater advantage over GPL'd code when their primary motive is to quickly drive up the adoption rate, and turn their code/API into a de-facto standard. If hijacking is a concern, then shouldn't one look at GPL, instead?

> Saying that you can't accept LGPL without that
> signature means you don't respect the LGPLs
> intentions. It means Sun wants to be able to control
> other peoples work without their say in the matter.

As with any code under LGPL, users are free to use other people's work without seeking the project owners' consent or accounting for it in any way, as long as they adhere to the license. So, this is not an issue that stems from JCA, right?

Also, from the JCA, the original creators do not give up their right, and can do anything they want with their code:

>>You hereby assign to Sun joint ownership ...
>>in Your Contribution to the extent allowable
>>under applicable local laws and copyright conventions.
>>...Except for the rights granted herein, You retain
>>all right, title and interest in and to Your
>>Contributions and may use the Contribution for
>>Your own purposes. ...

I know JDNC is not the only project that requires JCA with LGPL. JDIC does too. Anybody know of other projects? I am no fan of JCA myself, but I think it is important to have a healthy discussion and address people's concerns sooner rather than later :-)

Ramesh

ronaldtm
Offline
Joined: 2003-07-18

> The idea behind LGPL is to loosen the restrictions
> placed by GPL so that your code is more palatable to
> a broader development community. This is supposed to
> give project owners a greater advantage over GPL'd
> code when their primary motive is to quickly drive up
> the adoption rate, and turn their code/API into a
> de-facto standard. If hijacking is a concern, then
> shouldn't one look at GPL, instead?

AFAIK, LGPL and GPL are the same, the only difference is scope. Both say 'you can use, but if you modify you must distribute with the sources of all derivative work'. What is different is that LGPL considers library linking as 'use', thus, outside its scope, while GPL considers library linking as 'derivative work', thus, inside its scope.

> > Saying that you can't accept LGPL without that
> > signature means you don't respect the LGPLs
> > intentions. It means Sun wants to be able to control
> > other peoples work without their say in the matter.

Kinda. Sun needs the JCA because it needs to release the JDK under a license other than LGPL, to ensure compatibility (commercial interests aside). LGPL permits re-releasing only under LGPL compatible licenses, which makes it impossible to Sun to release JDNC classes with the JDK.

(Well, I think :) )

Tetsuo