GUI/Gorm code freeze
All,The code in gui and Gorm is frozen in preparation for the release. Only critical fixes to existing functionality should go in at this point.I am attempting to stabilize Gorm and GUI for the release.Later, GJC--Gregory John Casamento___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/Gorm code freeze
On 2006-08-26 14:32:02 +0200 Gregory John Casamento <[EMAIL PROTECTED]> wrote: The code in gui and Gorm is frozen in preparation for the release. Only critical fixes to existing functionality should go in at this point. I am attempting to stabilize Gorm and GUI for the release. On a side note, wouldn't it make sense to keep a list of 'most wanted but still missing classes' for Foundation/AppKit around, say on Wiki, so people can 'subscribe' to implement these classes? Just a thought. -- Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/Gorm code freeze
Chris,This would make a lot of sense although... I thought we already had a list like that here:https://savannah.gnu.org/task/?group_id=99It would be better to track this as a set of tasks so that the process is less ad-hoc.Later, GJC --Gregory John Casamento- Original Message From: Chris Vetter <[EMAIL PROTECTED]>To: gnustep-dev@gnu.orgSent: Saturday, August 26, 2006 10:02:23 AMSubject: Re: GUI/Gorm code freezeOn 2006-08-26 14:32:02 +0200 Gregory John Casamento <[EMAIL PROTECTED]> wrote:> The code in gui and Gorm is frozen in preparation for the release. > Only > critical fixes to existing functionality should go in at this point.> I am attempting to stabilize Gorm and GUI for the release.On a side note, wouldn't it make sense to keep a list of 'most wanted but still missing classes' for Foundation/AppKit around, say on Wiki, so people can 'subscribe' to implement these classes?Just a thought.-- Chris___Gnustep-dev mailing listGnustep-dev@gnu.orghttp://lists.gnu.org/mailman/listinfo/gnustep-dev___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/Gorm code freeze
On 2006-08-26 18:27:12 +0200 Gregory John Casamento <[EMAIL PROTECTED]> wrote: This would make a lot of sense although... I thought we already had a list like that here: https://savannah.gnu.org/task/?group_id=99 It would be better to track this as a set of tasks so that the process is less ad-hoc. Ah, yes, I thought I remembered having seen it but couldn't find it anymore. Cool. At least the Wiki should link to it. However that brings me to another question that may look like flame-bait... Let's say there's a framework that implements one or more 'wanted' classes but are licensed under, say, BSDL. Would it be permissible to add those classes to GNUstep (since it's LGPL) or would those classes have to be 'handed over' to FSF, changing the license in the process? And what if the author doesn't want to change the original license but adds a section that additionally puts the code under LGPL (that is, as a dual license) provided / as long as the code is used in GNUstep? I honestly do not know, but would like to... -- Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/Gorm code freeze
On Sat, 26 Aug 2006 19:01:39 +0200, Chris Vetter <[EMAIL PROTECTED]> said: [...] > However that brings me to another question that may look like > flame-bait... > Let's say there's a framework that implements one or more 'wanted' > classes but are licensed under, say, BSDL. Would it be permissible to > add those classes to GNUstep (since it's LGPL) or would those classes > have to be 'handed over' to FSF, changing the license in the process? > And what if the author doesn't want to change the original license but > adds a section that additionally puts the code under LGPL (that is, as > a dual license) provided / as long as the code is used in GNUstep? I think that the LGPL would prevent itself from being applied "as long as the code is used in GNUstep". (i.e. I believe that the LGPL essentially requires that you're able to rip it apart and distribute bits and pieces of it on their own, licensed under the LGPL.) But I don't think that in this case, licensing should be a problem, since the (3-clause) BSD license is, AIUI, compatible with the LGPL. The situation would be different for code licensed under a different license. The copyright assignment question, though, is a different matter, which I am not in any position to answer. There are ways around this, though, as long as the licensing is compatible, by wrapping the 'wanted' classes in an external library, and then having GNUstep call that library. Thus the library is not part of GNUstep (and hence wouldn't require copyright assignment), but GNUstep still gets to use the classes. Although this method is probably less desirable to actually having the classes in GNUstep. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
