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
Re: GUI/Gorm code freeze
On 2006-08-26 11:01:39 -0600 Chris Vetter <[EMAIL PROTECTED]> wrote: 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? I would prefer that classes that we consider part of the 'core' system be assigned to the FSF and integrated as LGPL. I don't think other frameworks have to be handled that way. In many cases this can provide more flexibility for development. The only problem with separate frameworks, though, is that they have to be distributed and installed separately. With the lack of a package manager, this makes things very hard for the user. 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? Yes, that would be much easier that having to figure out how GNUstep should be used under multiple licenses. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/Gorm code freeze
On 8/28/06, Adam Fedor <[EMAIL PROTECTED]> wrote: [...] > 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? Yes, that would be much easier that having to figure out how GNUstep should be used under multiple licenses. I was asking because I got a couple of classes that are 'missing' in GNUstep, that I'd like to 'hand over' to GNUstep directly, most of all NSNetServices and I usually put everything under a dual BSD/(L)GPL and I'm not very keen on signing anything (in general). However, if there's interest in at least adding NSNetServices, and signing is a requirement for inclusion, I'll do so. -- Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/Gorm code freeze
On 2006-08-28 01:44:33 -0600 Chris B. Vetter <[EMAIL PROTECTED]> wrote: I was asking because I got a couple of classes that are 'missing' in GNUstep, that I'd like to 'hand over' to GNUstep directly, most of all NSNetServices and I usually put everything under a dual BSD/(L)GPL and I'm not very keen on signing anything (in general). However, if there's interest in at least adding NSNetServices, and signing is a requirement for inclusion, I'll do so. If it definitely can be separated from other classes and doesn't need, for instance, additions or changes to base library classes to work (other than correct implementation of the classes as documented, of course), then I think that would be OK. Putting this 'under GNUstep' would help as it can be documented and distributed in one place and that avoids a lot of the problems people have just getting GNUstep working. I just have to figure out how to handle the repository - typically I require someone to have an FSF assignment to get write access to SVN. Perhaps setting up a separate, non-FSF repository would work for this kind of stuff. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/Gorm code freeze
Le 26 août 06 à 19:01, Chris Vetter a écrit : 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. May be the Summer of Code 2006 page which lists most of missing classes. There is a link on the wiki front page: mediawiki.gnustep.org/index.php/Summer_Of_Code_2006> Cheers, Quentin. -- Quentin Mathé [EMAIL PROTECTED] ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/Gorm code freeze
On 2006-08-29 14:03:36 +0200 Quentin Mathé <[EMAIL PROTECTED]> wrote: > May be the Summer of Code 2006 page which lists most of missing classes. > There is a link on the wiki front page: mediawiki.gnustep.org/index.php/Summer_Of_Code_2006> Check the history of that page ;-) But that's not exactly what I had/have in mind. I was more thinking of an official 'list of classes that want to have implemented' to which people can set their name as a 'I will do/implement that.' -- Chris ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
