Apply the GPLv3 to my code and clarify the license of the PyObjC parts.

darcs-hash:f938f41421ba30e34d6bef095829ac1950b4dfa9

1 files changed, 53 insertions, 0 deletions

diff --git a/JOURNAL b/JOURNAL
index f446a32..972a92a 100644
--- a/JOURNAL
+++ b/JOURNAL
@@ -1,5 +1,58 @@
 -*- mode: muse -*-
 
+* 2007-09-26, 00:13:11 CEST
+
+** Licensing
+
+Licensing is another open question.  For the moment, I'm releasing this
+project under the terms of the GPLv3.  This seems like a reasonable
+choice, because it gives me the option of giving people more permissions
+later by applying the LGPLv3 to my code.  I must be aware that only I am
+allowed to do this, though, and even then only if all contributors agree
+(if someone actually makes a contribution, that is).  I may want to
+require all contributors to dual-license their contributions, or maybe
+to make them available under the terms of the LGPLv3 in the first place
+(though the latter would make marking them difficult).
+
+
+* 2007-09-25, 20:59:40 CEST
+
+** Value Conversion Madness
+
+Open question: Should NSArray instances be converted to lists or arrays
+automatically?  If so, we ought to make functions like OBJC-CLASS-OF
+behave in a reasonable way for those kinds of objects, i.e. return
+NSArray or NSMutableArray (whatever it is that INVOKE makes out of them
+when converting them into Objective-C instances again).
+
+Note that we *must not* convert NSMutableArray instances or any other
+mutable objects in this way!  Note also that our decision *must* be based
+on the dynamic type of the object, not the static one, because a method
+whose return type is NSArray may as well return an NSMutableArray that
+we've fed it sometime earlier.  This is okay for immutable objects, but
+mutable objects are bound to cause trouble when such a thing happens.
+
+Related types of objects are strings (NSString), hash tables
+(NSDictionary), and numbers (NSNumber).
+
+Note that such behaviour would make it impossible to fully identify CLOS
+classes with Objective-C classes, as arrays would have no Objective-C
+class to belong to.  Then again, why would you want to distinguish
+Objective-C arrays from Lisp arrays in your Lisp code, anyway?  Real
+integration means not having to worry about such things.
+
+On the other hand, conversion of large NSArrays may be prohibitively
+expensive, so a switch is needed, either way.  The real question is what
+the default behaviour should look like.
+
+There's an alternative to consider, too.  For NSArrays, there is
+Christophe Rhodes' user-extensible sequence proposal, but even without
+support for that, we can provide a *conduit* (a package) that looks like
+the COMMON-LISP package, but overloads all sequence and hash-table
+functions.  Overloading all sequence functions might be a lot of work,
+though.
+
+
 * 2007-09-23, 17:09:07 CEST
 
 ** Improved Memory Management for the Masses