Re: Bringing License arguments to Sun
On Wednesday 23 August 2006 13:22, Leo Simons wrote: Licensing - On Sat, Aug 19, 2006 at 07:38:36PM -0700, Stefano Mazzocchi wrote: [what license should Sun use to open source java] I'll bite: the MIT license. +1, for all the reasons Stefano described. Along with the neccessary, explicit, relevant patent grants, preferably with GPL-compatible terms (eg non-reciprocical; would probably automatically meet requirements off standards bodies and open source orgs worldwide). Typically standards orgs have a patent policy already in place, see e.g. [1], [2]. These are probably the result of quite a lot of thought and discussion, so they should be read not just as something with which a proposed patent grant needs to be compatible but also as prior art in this field. [1] http://www.ecma-international.org/memento/codeofconduct.htm [2] http://www.niso.org/committees/OpenURL/PATPOL.pdf -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: Bringing License arguments to Sun
(I looked at http://community.java.net/jdk/opensource/ for a feedback button or something but can't find it. Thanks for listening anyway!) Licensing - On Sat, Aug 19, 2006 at 07:38:36PM -0700, Stefano Mazzocchi wrote: [what license should Sun use to open source java] I'll bite: the MIT license. +1, for all the reasons Stefano described. Along with the neccessary, explicit, relevant patent grants, preferably with GPL-compatible terms (eg non-reciprocical; would probably automatically meet requirements off standards bodies and open source orgs worldwide). The most important concern as I see it in terms of open source java license choice is to de-fragment the ecosystem as much as possible. If sun makes haste, I can still see java becoming the #1 language for desktop applications 'n stuff, and I can still see us all surviving the longhorn assault that's coming. Dalibor's written a lot of good stuff on his blog: http://www.advogato.org/person/robilad/diary.html?start=103 (I would paint a little different history lesson and I don't like dual licensing as a long-term strategy, but other than that its spot on.) Now, to dwell on alternatives. My personal opinions. If MIT license is not possible, next up is ASLv2 since it will still mean (after GPLv3 finalizes) that code can be incorporated downstream in both apache (harmony and other projects, think jakarta commons, xml commons, yoko) and GNU (classpath and other projects like gcj). If ASLv2 is not possible the next preference up is probably a custom license that still allows pieces to be mixed and matched with both the Free Software and Open Source parts of the ecosystem. I imagine any such license would still come somewhat close to ASLv2, and I'll highlight how painful introducing new licenses is for the entire ecosystem. Please don't do it again :) If that is not possible, I'll go and be an ASF heretic and say it should be GPLv3. That way, at least healthy co-operation between the GNU communities and jonathan java will still be possible. In a way it'd be tough luck for harmony, since we've pretty much determined already we wouldn't be able to depend on GPLv3 pieces, but it would still allow a fruitful downstream merge with jonathan java and classpath incorporating the best harmony bits. The bigger ecosystem still wins. And most apache java people will have no problem making use of GPLed stuff - we're all GCC users already for example ;). If that is not possible, I guess the last realistic alternative is the CDDL. I like the CDDL and I use it for some of my hobby projects. Its category B in the ASF 3rd party license policy draft [1], so it would still allow some kind of co-operation between jonathan java and harmony. **But** IIUC its still undecided whether the GPLv3 will be compatible with the CDDL, which potentially means closing off -- rather permanently -- a really big part of the FLOSS java community. In this picture, I see all java being ripped out of OpenOffice (or OO.o suffering from forks and communit dissent), Java-GNOME and the like not being used, in favor of mono, and java permanently losing a position on the desktop of anyone but java developers themselves. Sure, it'll still thrive on the server and open source java will still be loads of fun, but I'd be removing the swing keyword off my resume. Last legal point -- I'm guessing all license choices are somehow ok to the opensolaris community -- GPL is by virtue of having GCC and gnome and stuff around, CDDL is obviously, and ASL is too by virtue of having the web server on there. Governance -- You know, I'm just not too fussed. You guys will get it right enough. Java.net seems to be working as intended these days, opensolaris.org is shaping up nicely, even OO.o is seeing more and more of an actual community. Listen to all the stuff Geir has to say about the JCP and opening that up further and then we'll be fine. The jini stuff coming to apache is a further nice exercise. Cool! - Its not just about those 400-or-so open source developers who will be working on java. Its about all the weird stuff you're not planning or expecting that will rock the industry; providing rocket fuel to the crazy rocket scientists. The proper port to BSD might unearth a 10 year old bug than when fixed means a 15% performance improvement on linux. Who knows. The network is the computer, and the community is the real network. I know I know, preaching to the choir, but somehow this is all being de-emphasized. Open source is cool, and open source java will be, too! My main personal interest is that I'll somehow be able to bootstrap a system all the way from bootstrapping GCC up to big J2EE-based systems while doing all sorts of interesting measurements (Re: gump) and thus improve the stability/maintainability of the whole stack. But I'm a little weird like that. All I need now is open source oracle... LSD [1] -- http://www.apache.org/legal/3party.html
Re: Bringing License arguments to Sun
Hi Wes, On Mon, 2006-08-21 at 13:53 -0500, Wes Felter wrote: If One TCK is so important, let me propose a semi-heretical idea: don't open it. Certainly the 400 JVM developers should be able to run the TCK, but it's not clear that they need to distribute modified versions. (Of course, they could still submit bug fixes and such to the TCK maintainers.) I don't think the Linux distros need to distribute the TCK either, so their OSI or die policy doesn't appear to affect the TCK. Of course the Linux distros need it! One of the great strenghts of distributions is their ability to run the testsuite for all packages they build. And to give their users the power to repeat the build process and do their own checking of the results. It is a critical part of quality control. So when you build your deb/rpm/etc (possibly with distro specific patches) you run the testsuite and fail if some tests don't give clean results. That is how GCC for example works. There are even distros that only ship (easily buildable) source code so as to optimize any binary for your personal system. Then it is even more important that the user also gets the testsuites to make sure their special customized build on their own hardware is perfect. And it might very well be that to do that you have to adapt, modify and hack the testsuite to run and build in your particular packaging environment (and run it non-interactively). Don't forget that free software breaks down the artificial barrier between users and developers. Everybody is a core library, runtime, compiler, package, etc hacker now. So everybody should also take the responsibility and run any testsuites. Your users will demand it from you. Cheers, Mark
Re: Bringing License arguments to Sun
On Aug 20, 2006, at 09:54, Chris Gray wrote: +1 to Stefano Mazzocchi: Noted, thanks. (and edited so I am making fair use of your copyrighted material - I don't want to get sued...) The specs should be licensed in a way that is compatible with the requirements of standards bodies such as ISO, ANSI, ECMA, even if Sun doesn't intend to head that way just yet. Keep in mind that Sun doesn't get to decide this any more, it's up to the JCP, and there are plenty of voices other than Sun who would likely oppose this. While I sympathise, open sourcing Sun's Java implementations has nothing to do with the JCP and is made possible by the JCPA 2.5 and later. S.
Re: Bringing License arguments to Sun
On Aug 20, 2006, at 03:38, Stefano Mazzocchi wrote: So, if we assume for a second that Sun can use the license as a carrot rather than a stick, my suggestion would be to use the simplest and more compatible license possible. I'll bite: the MIT license. Thanks, Stefano, I appreciate the rationale and the time and thought that's gone into writing it. I'll make sure this outlook is represented. S.
Re: Bringing License arguments to Sun
On Sunday 20 August 2006 12:27, Simon Phipps wrote: On Aug 20, 2006, at 09:54, Chris Gray wrote: +1 to Stefano Mazzocchi: Noted, thanks. (and edited so I am making fair use of your copyrighted material - I don't want to get sued...) My cat can be vicious. :-) The specs should be licensed in a way that is compatible with the requirements of standards bodies such as ISO, ANSI, ECMA, even if Sun doesn't intend to head that way just yet. Keep in mind that Sun doesn't get to decide this any more, it's up to the JCP, and there are plenty of voices other than Sun who would likely oppose this. While I sympathise, open sourcing Sun's Java implementations has nothing to do with the JCP and is made possible by the JCPA 2.5 and later. True, but quite often the spec lead is from Sun, e.g. for 218/219 (JavaME CDC/ FP). In such cases, if the Exec Comittee agrees Sun can set an example by licensing the specs in a way which would not preclude them being adopted as a standard by ISO co. BTW the comments made by EC members wrt JSR 218 seem to indicate that there is quite widespread support for a more open approach[1]. Best regards, Chris [1] http://jcp.org/en/jsr/results?id=1991. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369
Re: Bringing License arguments to Sun
Simon Phipps wrote: On Aug 20, 2006, at 03:38, Stefano Mazzocchi wrote: So, if we assume for a second that Sun can use the license as a carrot rather than a stick, my suggestion would be to use the simplest and more compatible license possible. I'll bite: the MIT license. Thanks, Stefano, I appreciate the rationale and the time and thought that's gone into writing it. I'll make sure this outlook is represented. Simon, Thank you. -- Stefano.
Re: Bringing License arguments to Sun
Geir Magnusson Jr wrote: CDDL is an example of clever lawyer work to modernize best licensing practices, but those are best practices in protection not in social empowerment! I don't understand that. Do you see the CDDL as somehow restricting communities? No, I see CDDL something that will significantly slow or hinter the licensing compatibility assessment from both the ASF and the FSF. I fully recognize the lack of IP protection in older licenses (which might look like a naive if we ignore it maybe it will go away policy ) but I think that licensing the code, the trademarks and the IP separately is another fully viable strategy. I would use an MIT license for the code and a different license for the IP. The injected IP problem can be dealt with a contribution agreement which does *not* need to be part of the license (like apache did, for example). As far as IP protection is concerned, Sun owns (or has acquired the rights to relicense) the existing IP, they will only need to be concerned about new ones coming in from contributions and for that they can have contributors sign IP agreements (like we do for Harmony, for example, even if the license, in theory, already covers that). So, in theory, one could take an MIT-licensed RI, add some code with special IP (say a new garbage collector), pass the tests and then decide to charge people for the license of that IP. Sun could decide that they consider this free riding and that they want everybody to have a piece of that cake, so they can use a license that is not violently reciprocal on code donations but it is on IP (and CDDL falls under this category). The problem with this, it's that it makes it incompatible with the GPL, ending up alienating some of the very people they are counting on pleasing (and you can expect all sort of internal and external frustration would that happen). So, the choice is, in my eyes, whether to 'enforce' the reciprocity of IP licensing of not. Here, there is a lesson to be learned from the reciprocity on code: the BSD license does *not* force you to contribute back but many do anyway, and the freedom of being allowed *not to* is what makes the BSD license more palatable than, say, the GPL to many (unless you use a mysql-like unlock-the-gpl business model, which is another story). People contribute back even if they are not forced to because it's convenient for them to do so, or they are left with the burden of maintaining a branch. The same exact argument applies to IP. So, if the RI license does *not* force people to donate the IP to the modifications that are made and redistributed (after passing the tests and obtaining certification), they are actually forking, just like OSI licenses are designed to allow. But they are now on their own, against the rest of the world. The FOSS ecology has shown that branches are very hard to maintain anyway, especially against very active and healthy communities (which has become the ASF motto, community is more important than code, and, I would add, a license has to protect the community more than the code). And if the fork is killed or goes unfeasible and people try to inject known or submerged IP with contributions to the RI, the community watching and a solid contribution agreement will prevent that. In case of contributions that are covered by unknown IP, there is very little one can do to prevent in the license that covers the usage of the code. My reasoning for going simple and non-reciprocal for both code and IP is *not* that I'm ignoring the issue, it's that there is no need for a reciprocal licensing of the IP, as I claim that it will be socio-economically inconvenient for anybody to do so. They will try, they will fail, as much as there is no apache# or tomcat++. Just like the BSD, giving people the freedom of choice on whether to donate code back or keep it for themselves, has been proved to be *extremely* effective in creating healthy, innovative and open contribution ecosystems. I believe the same freedom on IP contribution is a valid and not more risky strategy that will make the java RI code maximally used and, just like other examples, foster compatibility by becoming, de-facto, the only socio-economically maintainable/feasible implementation over time. And the choice of maximum freedom (given OSI/free-software parameters) and maximum compatibility is, IMHO, a necessary condition for a social ecosystem and dynamics that will guard the RI way more effectively (and at lower costs!) than any license or army of lawyers can do. I think that CDDL is a reasonable license, and if I wasn't allowed to use a BSD-style license for whatever reason, I'd go that way... I never said it's a bad license. I'm saying it's not the one I would choose and I gave a socio-economical analysis on why I think this is so. CDDL will lower the perceived fear of free riding using IP protection strategies in Sun executives, but at the price of alienating a huge part of the java
