Paul Fisher wrote:
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> > We *can* create a cleanroom implementation if we wish, we just have
> > to abide by the above restrictions.
>
> Sun says we can only create a clean room implementation if we release
> the clean room version under the terms of the JTPL (see the JTPL
> licensing FAQ).
>
> Sun's taking the stance that an API can be copyrighted. This issue
> hasn't been 100% settled in the courts.
>
> --
> Paul Fisher * [EMAIL PROTECTED]
Here is a probably "illegal" reprint of the relavent sections .
GL.18 "Specifications" means the specifications for the Technology and
other documentation, all as listed in Attachment E.
And here is Attachment E.
ATTACHMENT E.
Jini Technology Compatibility Kit (TCK) (description
of tests, procedures and
requirements):
To Be Defined
It the test kit and startdards kit. IT looks like the equivilent of the
Compatibility test kits used for the JVM.
It does not say that the public programing API is only avialable from
Sun . Do they whant to try to
force everyone who buys a book on Jini programming to sign a license? If
so then RMS is correct to forget about Jini.
You can build a prefectly acceptable Jini clone but you cannot certify
it without turning it over to Sun.
The relative merits are really a seperate issue. I suspect they would
allow GPL clones as long as they could
somehow integrate it back into Jini under a "stricter" license. It would
be nice to see Sun directly address the GPL in there license.
Sotheing to the effect of waing license for GPL if author allows Sun
rights to ingerate code back into jini.
In this case Sun is not providing a reference implementation becuse they
want only one standard implementation.
Its up to the free software community to help Sun and see how the GPL
can be extened to include a
the concept of a standard implementation.
In effect the Linux kernel offers this by having a dual track release.
The stable standard and the development kernel.
Sun is attempting alibet poorly to try to come up with a way to express
this legally. Hey there newbie's give thame a break : )
This is a a real programing model found the FS community,
because changes which do not get integrated back into the next release
tend to die. And example where this is failing is the egcs/gcc stuff
emacs/xemacs.
But it works for the Linux kernel. If you don't get your stuff bundled
into the next release then you must repatch and support it yourself.
This is the painful situation faced by the Sun JDK porting team.
Suns goal as I see it are
1.) Provided a reliable single standard implementation
2.) Foster open developement for everyones benefit
3.) Garuntee that no memeber of th Jini community leverages there
postion to tie customers to there implementation.
The GPL does not in my opinon address 1 and 3 very well.
Companies tend to have a group mentatility of a street thug.
If your going to let these guys into Open Software "heaven" then you
need to work a bit on the rules.
I see something like a GPL fore everybody but the Standard Body is
given the right to integrate the code into
the standard release and proclaim it part of the standard. To support
the standard body the "Standard" is release under
several differnet licenses. I think that open devlopment is sufficient
support for Jini such that if you GPL your sources
allong with releasing them back for inclusion into the standard then you
owe no royalties regardless of your use of the code.
You have paid with your time. No royaltie are also needed for binary
only use.
Royalties and thre stricter contract are only required if you wish to
use Jini without distributing the resulting work under GPL.
The trick is its basically the GPL but with the addedrestriction that
the Standard body gets the right to include it into the Standard
Distribution. Under a diffrent Standard Distribution Contract. This is
one part of Jini.
This contract is what I would call the SGPL. ITs essitianly the GPL
but giving the Standard body right's
to include the code in a Standard distribution wich may be avialable
under diffrent contracs. But it also requires that the
Standard body always makes ALL of its code also avialabe under SGPL even
code contributed to the standard body under a
diffrent contract.
You have a choice use the SGPL or use one of the strictier Standard
Distribution Contract's
The SGPL option should be commercially viable under conditions. For
example companies should be able to include Jini in SGPL format
in commercial distributions. You could set a SGPL fee as low as 1
dollar or 1% of sale price which ever is the lesser for SGPL commercial
use.
Or not bother about it at all and set up a volantary SGPL support fund.
And all code under Standard Distribution Contract should be avialable
under SGPL.
This way both groups win. The free softwaregroup gets unfettered acces
to all the SGPL code.
The Standard body can garuntee a stable reliable body of software for
everyone to use.
And act as a montor transfering SGPL code into the comercial sector and
comercial code into the SGPL space.
For the mutaul benefit of both parties. I could certianly see a bit of
rivalry on who had the greatest contribution to Jini. : )
The Standard body simply represents the manager of this technology
transfer.
I only see two types of Contracts either the SGPL or some sort of
Standard Distribution Contract for companies with
lots of money who don't like the SGPL. I woul thin thre contracts would
alos include some sort of support and direct
Standard voting rights. So the SGPL guys only get htre stuff included if
it's so cool everybody whants it.
The "Standard Distribution Contract signers" Get to vote get
certification of there code etc etc.
It would be similar to the Jini license out there now. But I could care
less what the standard contract is as long as all code
can be had via the SGPL. The Standard Distribution Contract signers
should care less about the SGPL contract.
I challenge RMS to come up with a contract which allows a standard body
to garuntee
a single stable standard open API and single standard open
implementation ,
and allow inovative open source development.
Mike
