Planet Squeak

Torsten Bergmann: Google Summer of Code with Smalltalk

2010-03-09T07:54:57+00:00

There is a new page for the Google summer of code with Smalltalk:

http://gsoc2010.esug.org/

You can read more about it here.

Randal Schwartz: A brief bit of Squeak history

2010-03-09T04:36:06+00:00

On a recent "VOIP User's Conference" podcast, during the second (unscripted) hour, I rambled on a bit about Squeak's history, and dynamic languages, and got a little angry at people who suggest that port knocking is sane. Check it out!

Read and post comments | Send to a friend

The Weekly Squeak: Google Summer of Code – candidates needed at once!

2010-03-08T23:06:07+00:00

The Squeak community are working with ESUG to submit a joint entry to this year’s Google Summer of Code but need your help at once!

Squeak participated in GSoC in 2007 and 2008 but in 2009 Google started to focus on bigger communities, so Squeak developers are working with ESUG this year to put together a joint submission with other groups including open-source projects from all Smalltalk dialects, including Pharo, Smalltalk/X, GNU Smalltalk and Cuis as well as commercial distributions such as VisualWorks, VisualAge, Dolphin and Gemstone. Entries from cross-platform projects like Seaside, AidaWeb, Magma, etc. will also be welcome.

Mariano Martinez Peck will administrate the joint application supported by Janko Mivšek. They need to supply Google with information about ESUG as a mentoring organisation and a list of ideas/projects, each with a description and a nominated mentor. If their submission get selected by Google they will be told how many projects Google will sponsor — the mentor receives $500 and the student who volunteers to work on the projects will receive $4500.

Due to a late start, they are very near to the first deadline! They have until 12th March 2010 to submit all the information of the mentor organisation and give the list of projects with mentors. So as a matter of urgency they need your projects. They’ve put together a webpage to hold details, so if you have project suggestions, send them a short title and a paragraph (for the moment) explaining the idea. You can also reply to Mariano’s email on most of the key developer mailing lists including the squeak-dev mailing list.

Good mentors are often as hard to come by as good ideas, but often being helpful, being aware of the dates, answering emails, etc. can be more important than the Smalltalk knowledge, so if you’re able to act as a mentor or a back-up, let them know at once!

For some inspiration, you can see the ideas proposed in previous years:
2007: http://wiki.squeak.org/squeak/5936
2008: http://wiki.squeak.org/squeak/6031
2009: http://wiki.squeak.org/squeak/6120

Torsten Bergmann: Next Pharo Sprint: March 13, 2010

2010-03-08T16:36:15+00:00

The next pharo sprint:

Date: March 13, 2010
Time: 9:30 - 21:30
Place: Software Composition Group, University of Berne, Switzerland

See here for more details.

Torsten Bergmann: Chapter on Exceptions for Pharo by Example book

2010-03-08T13:03:45+00:00

The http://pharobyexample.org book now includes a new chapter on Exception handling in Smalltalk.

Torsten Bergmann: The Moose Book

2010-03-08T12:58:02+00:00

If you want to do software and data analysis then you should read the
new online book from Tudor Girba:

http://www.themoosebook.org/book

about the Moose technology. Moose is an analysis platform written in Smalltalk.

The (yet unfinished) book already includes descriptions on how to use Moose, how to build a browser with Glamour or how to load the latest Moose version into Pharo using Metacello.

One interesting aspect (beside a good documentation on Moose) is that this is now the second dynamic web book on Smalltalk technologies (after the Seaside online book) which is written using the Smalltalk based Pier Content Management System.

Torsten Bergmann: Squeak is twittering

2010-03-07T21:29:52+00:00

The commits to Squeak trunk (the new community development model) are now also visible in Twitter:

http://twitter.com/SqueakTrunk

Should be easy to follow development now.

If you want to know about other package commits (SqueakSource) then
you could use the already known Planet Squeak code:

http://planetmisc.squeak.org

Torsten Bergmann: ScratchViewer for iPhone/iPad

2010-03-06T00:31:03+00:00

John is building a scratch viewer for the iPhone and iPad.

Gilad Bracha: Through the Looking Glass Darkly

2010-03-05T16:46:53+00:00

In January, I gave a guest lecture in a class on reflection and metaprogramming at HPI Potsdam. A screencast of the talk is now available. It’s an introduction to the concept of mirrors, which is the goodthink way of doing reflection. It’s mostly language neutral, but there is a brief demo using mirrors in Newspeak.

Because it’s a screencast rather than a video, occasionally some detail may be unclear, but by and large it is the most comprehensive introduction to mirrors available other than the OOPSLA paper.

Some people may not have an hour to watch the entire screen cast, and the paper is by no means an easy read, so I’ve decided to post the executive summary here.

The classic approach to reflection in object-oriented programming languages originates with Smalltalk, and is used in most class based languages that support reflection: define a reflective API on Object. Typically, Object supports an operation like getClass() which returns an object representing the class of the receiver. The API of classes defines most additional reflective operations available. For example, in Java, you can get reflective descriptors for a class’ methods (java.reflect.Method), fields (java.reflect.Field) and constructors (java.reflect.Constructor). You can even use these descriptors to evaluate program code dynamically - say, ask the user for the name of a method and invoke it. In Smalltalk, you can also add and remove methods and fields, change a class’ superclass, remove classes from the system etc.

Another approach is used in many scripting languages. The language constructs themselves introduce code on the fly, modifying the program as they are executed. For example, a class comes into being when a class declaration is evaluated, and might change if another declaration of a class with the same name is executed later.

The third approach is that of mirrors, and originates in Self. Mirrors have been used in class based systems such as Strongtalk, and even in the Java world. JDI, the Java Debugger Interface, is a mirror based reflective API. Here, the reflective operations are separated into distinct objects called mirrors. This seemingly minor restructuring has significant implications. Reflection is no longer tied into the behavior of every object in the system (as it is via getClass()) or (even worse) into the very syntax of the language. Instead, it resides in separable components that can be removed or replaced. Reflection is now a distinct capability, in the sense of the object capability model.

If you are worried about security, this is good news. If you don’t provide a program with the means to manufacture mirrors (e.g., you do not provide the mirror factory object), said program cannot do any reflection. You can also provide mirrors with limited capabilities - say mirrors that only reflect the program’s own code, or mirrors that do not allow you to modify code or access non-public members etc.

Caveat: The truth is, mirrors have not really been used for security. Their utility for security seems clear, but a working API has yet to be demonstrated.

Mirrors are good news for other reasons. Say your program doesn’t use reflection, and needs to fit into a small footprint such as an embedded device. It is easy to take it out. Another advantage is that you can easily plug in alternate implementations of reflection - so if you need to reflect on remote objects, you can do so.

Historical note: This is why JDI uses mirrors; indeed, it is why JDI had to be introduced. The original intent was that Java reflection would be used to support debugging; but once you need to deal with cross-process debugging, you need a distinct implementation of reflection; core reflection is tied to a single built in implementation.

Mirrors support a clear boundary between the base-level of your program (the level which deals with the problem domain your program is intended to solve) and the meta-level (the level where your program is discussing itself, where reflection takes place). The classic design, where the class is the main repository of reflective information, tends to blur these lines. Classes often have both base level functionality (like creating instances) and meta-level functionality (reflection). This is most acute in languages like Smalltalk and CLOS. In Java, the base level roles of classes are often supported by specialized constructs like constructors (which have their own, worse, problems) and
static members (likewise). Even in Java, class objects may be used in a base level capacity (as type tokens, for example).

There is much work to be done in this area. No mirror API has yet fulfilled all my claims and ambitions - least of all the Newspeak mirror API, which needs extensive revisions. Still, I hope you’re curious enough to watch the talk and/or read the paper.

Squeak Oversight Board: Meeting Report for 3/3/2010

2010-03-03T22:28:28+00:00

For the last official meeting of this instantiation of the Squeak Oversight Board everyone was present: Jecel Mattos de Assumpção Jr, Ken Causey, Bert Freudenberg, Craig Latta, Andreas Raab, Randal Schwartz, and Igor Stasenko.

First we would like to remind everyone that the 2010 election for the Squeak Oversight Board is coming up very soon. For more information see http://wiki.squeak.org/squeak/6150.

Recently we announced an anticipated release date for the MIT/Apache licensed Squeak 4.0. The word is getting out as evidenced by the fact that this site received 5-10 times the usual amount of traffic soon after that announcement was posted. Ronald Spengler is kindly leading the effort to finalize the packaging of Squeak 4.0 and you should be watching squeak-dev for pre-release versions and related news.

Relatedly we continue to work with the Software Freedom Conservancy to finalize issues related to our joining this organization. We are hopeful of completing this not long after Squeak 4.0 is released as this release is essential to the process.

Our next meeting is scheduled for 3/24/2010. Note that this is a week later than our usual meeting date. The plan is to have a special meeting with all current and newly elected SOB members to get the new board up to pace quickly. We will be contacting candidates soon to clarify the plan.

Squeak Oversight Board: Special Agenda for 3/24/2010

2010-03-03T20:37:48+00:00

This will be a special meeting of both new and old Squeak Oversight Board members to facilitate ‘passing the ball’ to the new Oversight Board.

Torsten Bergmann: Cologne Smalltalk Meetup Website

2010-03-02T15:07:46+00:00

There is now a new website available for the Cologne Smalltalk Meetup.

Torsten Bergmann: Physical Etoys

2010-03-02T08:35:01+00:00

Physical Etoys is a visual programming tool that connects the virtual world of computers with the real world in which we live in. Now a first beta version is released.

It is based on the Squeak Smalltalk system. The announcement is here.

Torsten Bergmann: Printed version of "Dynamic Web Development with Seaside"

2010-02-28T19:41:43+00:00

Lukas announced the printed version of "Dynamic Web Development with Seaside".

The Weekly Squeak: Dynamic Web Development with Seaside

2010-02-28T11:10:58+00:00

A print-on-demand, softcover copy of the book “Dynamic Web Development with Seaside” is now available from Lulu.

Seaside is an source framework for developing highly dynamic and interactive web applications, and makes building web applications as simple as building desktop applications. The book gives you all the instruction and support necessary to get up and running in all the popular distributions of Smalltalk, with separate chapters on Pharo and Squeak, Cincom Smalltalk, Gemstone/S, GNU Smalltalk and VASmalltalk.

The printed book is based on the free online version and the purchasable PDF version of the book, and will be updated regularly. The book costs around €28/£24/$40 and will be delivered within 3-5 working days, so order your copy now!

The authors wish to thank the European Smalltalk User Group (ESUG), inceptive.be, Cincom Smalltalk, Gemstone Smalltalk, and Instantiations for generously sponsoring this book.

Milan Zimmermann: Free Squeak Coming

2010-02-25T07:02:03+00:00

The Squeak Oversight Board plans to finalize the multi-year effort of re-licensing Squeak. Squeak 4.0 is scheduled to be released on Monday, March 15th, 2010 and will be licensed under the MIT License with some original parts remaining under the Apache License. Further details are on the Squeak Oversight Board page.

Randal Schwartz: Finally! Home stretch for Squeak Licensing

2010-02-25T01:07:29+00:00

For the past two years, my presence on the Squeak Oversight Board has been substantially dominated by the effort to get Squeak Smalltalk into a clean license situation. This is needed both to have a platform that can be used by educational and commercial institutions without worry of license trouble, and also so that Squeak can become a project under the umbrella of the Software Freedom Conservancy.

Well, after an immense amount of collective work with important legal and social restrictions and ramifications, I'm happy to see that we are in the home stretch!

The SFC asserted that we needed one final "call to all interested parties", and that has begun. Once that's complete (hopefully without a hitch), the current 3.10.2 release will be relabeled as Squeak 4.0, and made available under a combination of the Apache and MIT licenses.

This is a great step forward for Squeak. Finally!

Read and post comments | Send to a friend

Randal Schwartz: Pier2 on Seaside3 on Squeak Trunk

2010-02-25T00:55:15+00:00

Apparently, while I wasn't looking, some Very Smart People finally ported Pier to new Seaside, which I've been waiting for as a prerequisite to cutting www.stonehenge.com over to Seaside and away from Perl. It's a bit tricky to get it all installed, but I have this magical set of incantations that can bring it in as needed:

(Installer ss project: 'MetacelloRepository') install: 'ConfigurationOfMetacello'; install: 'ConfigurationOfPier2'!
ConfigurationOfMetacello loadLatestVersion!
ConfigurationOfMetacello project latestVersion load: #('UI')!
ConfigurationOfPier2 load!

Stick these into a file ending in ".cs", and then drag that file into an updated Squeak-Trunk image, or pull up a file list and browse to it and file it in. After about 5 minutes and a lot of net downloads, you have a "squeak trunk plus seaside 3 plus magritte plus pier 2" image. Yeay!

UPDATE: Apparently, that was a bit overkill, since a ConfigurationOfXXXX knows how to update itself and its dependents already. So, this is simply now:

(Installer ss project: 'MetacelloRepository') install: 'ConfigurationOfPier2'!
ConfigurationOfPier2 load!

Read and post comments | Send to a friend

Torsten Bergmann: Re-licensing Squeak

2010-02-25T00:17:43+00:00

After years it is very close:

"The Squeak Oversight Board plans to finalize the multi-year effort of re-licensing Squeak. Squeak 4.0 is scheduled to be released on Monday, March 15th, 2010 and will be licensed under the MIT License [1] with some original parts remaining under the Apache License [2]."

Read more here ...

Squeak Oversight Board: Intent to Change License for Squeak 4.0

2010-02-25T00:01:39+00:00

The Squeak Oversight Board plans to finalize the multi-year effort of re-licensing Squeak. Squeak 4.0 is scheduled to be released on Monday, March 15th, 2010 and will be licensed under the MIT License with some original parts remaining under the Apache License. This release will be functionally equivalent to the previous 3.10.2 release. Current development work will be released as 4.1 as soon as possible following the release of 4.0.

This notice is intended as a “last call” before the actual license change takes effect. We have assembled re-licensing agreements from every identifiable contributor. However, if you have contributed to Squeak or know of someone who has contributed and has not been contacted about the re-licensing effort, this notice is intended to make you aware of the upcoming change and to allow you to contact the Squeak Oversight Board regarding your contributions before the license change takes place.

Please distribute this notice widely. Questions or comments should be sent to relicensing@squeak.org.

Gilad Bracha: Serialization Killer

2010-02-24T00:23:06+00:00

Way back in October 2009, I threatened to write a post about how serialization can serve as a binary format. The moment of reckoning has arrived.

Object serialization is probably most widely known due to Java serialization, but of course has a long history before that. Modula-2+ supported pickling long before Java, for example, as did Smalltalk systems.

Java serialization serializes objects in a most un-object-oriented way: it separates the object’s data from its behavior. Only the data is actually serialized. The object’s behavior (namely its class) is represented symbolically (as fully qualified class names; more on that later). During deserialization, the symbolic class information is used to reconstruct the classes of objects.

The problem is that this only works properly when both serializer and deserializer agree on the interpretation of the symbolic class information. For example, when two VMs running identical versions of the code communicate via RMI (the original use of Java serialization).

If the code in the deserializer differs from that in the serializer, as is very often the case (say, when one wants to load old serialized data) problems arise. The serialized data may not describe instances of the class on the deserializing side at all, because the private representation of the class may have changed.

Tangent: Java serialization introduced an extra-linguistic mechanism for creating instances, that was not considered as part of the language design, which only foresaw objects being created via constructor calls. This too is problematic. What if the invariants imposed by the constructor change over time?

To deal with these problems, one may opt to store data using a more stable schema than the in-memory representation (e.g., a database, an agreed external data format etc.).

Alternatively, one can add conversion routines that map old representations into new ones. This requires identifying the version of the object’s class (aka the serialVersionUID) when serializing an object. This approach is problematic however. Each change of representation requires a new version number, and a new conversion routine. These must be in place before the objects are serialized.

The reliance on class names is also an issue. What of anonymous classes? This is a problem in any case, but aggravated due to the reliance on names.

Tangent: the serialization team was, however, perfectly justified in assuming every class had a well defined name. They were working with Java 1.0, before the introduction of inner classes. Likewise, the inner class team was working on a system without serialization. No one saw the conflict until after the release combining the two - when it was far too late to do much about it.

In contrast, if one actually serializes the objects rather than just the data (that is, one serializes the data and the behavior), the serialized objects are much more self contained. (at some point one still wants to cut things off, but at stable APIs like Object).

If you want to bring old objects up to date, you must convert them; but:

You don’t have to; they work exactly as they did the day they were serialized, just like a mummy come to life.
You can add the conversion after the fact, at any time; for example, you can deserialize and then convert. The only requirement is that the necessary information is available via the object’s public API.

The serialization team didn’t have the option of serializing the classes in the manner just described. The Java byte code verifier makes that impossible. The verifier imposes a nominal type system, which means you cannot have two classes with the same name running in the same class loader.

Tangent: The wonders of byte code verification probably deserve a post of their own. For now, just note this as another example of the kind of difficult-to-foresee interactions that occur between seemingly unrelated parts of a complex system.

Assume we have a system where we can serialize objects including their behavior. Can we use the serialization format as a binary format for code? Specifically, can we use serialized class objects as our binary format?

In Newspeak, top level classes, also known as module declarations, are stateless. Hence the serialized form of these class objects is stateless as well, fulfilling a key requirement for a binary code representation.

Module declarations have no external dependencies, so we needn’t serialize a great tangle of objects as is often the case with object serialization.

Tangent: This is what a module is supposed to be: something that can be built independently! This also means that you can load modules declarations in any order. I note with glee that this runs against the entire tradition of ADTs as the basis for software modularity.

Entire applications can be represented this way as well - it’s simply a matter of creating an object that ties together the various module declarations used by the application. This source form of this object acts like your makefile, and its serialized form is analogous to an executable (or a JAR or whatever). To make this more concrete:

A Newspeak application is an object conforming to a standard API. This API consists of a single method, main:args:.

class BraveNewWorldExplorerApp fileBrowserClass: fb = (

| BraveNewWorldExplorer = fb. |

)(

“MAIN METHOD”

public main: platform <nsplatform> args: argv <list> = (

| fn <string> |

fn:: argv at: 1 ifAbsent:[ 'C:/Users'].

platform hopscotch core HopscotchWindow openSubject:

((BraveNewWorldExplorer usingPlatform: platform) FileSubject onModel: fn

)))

You need not understand every detail here; what is important is the following:

An serialized instance of BraveNewWorldExplorerApp acts as our binary. The Newspeak runtime loads such a serialized object, deserializes it, and invokes its main:args: method. The latter invocation is very similar to what a JVM does when it loads the main class of a program and calls its main() method, or for that matter, what C does with the main() function.

The method is invoked with two parameters (here we differ from the mainstream). The second of these represents any (command line) arguments to the program, just like argv in a C program. What is different is the first argument, platform, which represents the Newspeak platform. The precise meaning of the expression inside the method is relatively unimportant. What matters is that we use the platform argument in two places: first, to instantiate the file browser module, so that it can make use of platform code; and second to access the GUI (platform HopscotchFramework).

In this case, the application instance is created with a single parameter, the module declaration for the file browser.
More complex applications tie several modules together; in that case, the app module would be instantiated with a series of parameters, one for each module declaration required by the application.

To make it easy for developers, our IDE uses a standard convention for instantiating and serializing application objects. If a top level class has a class method packageUsing:, the IDE will assume the class represents an application, and allows us to create a deployable app with the push of a button.

public packageUsing: ideNamespace = (

^BraveNewWorldExplorerApp fileBrowserClass: ideNamespace BraveNewWorldExplorer

)

The IDE will call the class method, passing it a namespace object as a parameter. The method can use that namespace to look up any available module declarations that it needs to gather into the application, and compute an application object that references them all. This application object is then serialized. This packaging process is somewhat analogous to constructing a JAR file.

Semi-tangent: We also allow you to output more common/mundane deployment formats like Windows executables. Likewise, MacOS apps or Linux rpms can (and likely will) be added; a small matter of programming. Most interesting, and still in flight, deployment as web pages.

We have serialized/deserialized applications, such as the compiler and the IDE, into binary objects a few hundred kilobytes in size. However, this isn’t our standard modus operandi yet. Right now, we are still slowly untangling ourselves from the Squeak environment.

What then is the moral of the story? Well, one moral is that a running application can be thought of as an object, combining state and behavior; moreover, classical binary formats like a.out can be thought of as serialized objects.

Why is this profitable? Because we can cover more ground with less concepts, and less implementation effort. For example, rather than class files, JAR files and serialized objects, we can do with serialized objects alone. Moreover, we can do better with this one mechanism than we did with the other three combined. Less is more. And that is the moral of many stories.

Torsten Bergmann: Seaside book

2010-02-23T14:44:51+00:00

Lukas has a first copy of the Seaside book which is printed from the online version.

Michael van der Gulik: Dammit, Nethack!

2010-02-21T22:17:19+00:00

I have been a bit... distracted lately by a certain chaotic elven wizard with a penchant for Yendorian amulets. I'll be back into SecureSqueak shortly.

The Weekly Squeak: Squeak Board candidates wanted

2010-02-20T12:02:58+00:00

Göran Krampe has begun the process for this year’s elections for the Squeak Oversight Board.
The Squeak Oversight Board (SOB) consists of seven members from our community, all of whom are elected by popular vote. The members are responsible for

building a legal presence – currently by working with the Software Freedom Law Center as part of their Conservancy;
providing the network services that support the various mailing lists and repositories that in turn make a community possible;
helping coordinate the various interest groups and projects being pursued by Squeakers;
making decisions where there is no clear community consensus.

The current board members are:

Jecel Assumpcao Jr
Ken Causey
Bert Freudenberg
Craig Latta
Andreas Raab
Randal Schwartz
Igor Stasenko

(From http://www.squeak.org/Foundation/Board)

The schedule and process of the Election is as follows:

Nominations

Candidates should nominate themselves by 3rd March and start their campaign on the squeak-dev mailing list. Or if you nominate someone else, make sure that person really wants to run. Göran will not put anyone on the candidate list until that person makes it known on squeak-dev that he/she does run.

Final candidate list

The list will be closed on 3rd March. The candidates should ideally present themselves on squeak-dev, unless they have already done so, and the community can ask questions.

Online election starts

The voting period starts on 10th March 6PM (18.00 UTC) and is one week long. Ballots are sent out via email.

Online election ends

The voting process will end on 17th March 6PM (18.00 UTC). Results will be announced immediately when the election ends.

Registering

If you were invited to vote last year you are already on the voter list, no worries! If you are a new Squeaker and wish vote do ONE of the following:

Get a “known” Squeaker to vouch for you. If a known Squeaker sends an email to voters@squeak.org giving your name and email address then Göran will add you.
Send an email to voters@squeak.org yourself (and CC to squeak-dev if you like) with information/arguments showing that you are indeed serious about voting and that you are indeed a Squeaker.

When the voting period starts all voters will receive an email with instructions and a link to the voting website.

More information

Everything about the election, including schedule above and more, can be tracked here:

http://wiki.squeak.org/squeak/6150

Julian Fitzell: My new job

2010-02-19T09:19:06+00:00

I'm happy to announce that I have accepted a full-time position with Cincom in the UK. As a result, I will be laying down my consulting hat for a while, and heading to London at the end of the month. I'll be doing Pre-Sales Consulting (or Sales Engineering, as some call it) for their Smalltalk products in Europe and also working on another product in development. I'm really looking forward to focusing my energy on customers and product/business challenges for a while... it should be interesting.

I still intend to keep active with Seaside, though my role and availability may shift somewhat. With an active user base providing amazing support on the mailing list these days and a 3.0 beta release just around the corner, this is pretty good timing. Once we get the beta out there, we'll need to start discussing what comes next but first things first... and more on that in the next little while.

In the meantime, I encourage those of you in and around London to keep in touch - I'm going to need to find out where the good watering holes are. :)

Torsten Bergmann: Hobbes for Pharo

2010-02-19T07:25:26+00:00

Pavel announced "Hobbes for Pharo". Hobbes (Highly Objectified Blue Book Equivalent Smalltalk) is a virtual machine for the original Smalltalk-80 Version 2 by Xerox.

The Squeak/Pharo port is available now at SqueakSource:

http://www.squeaksource.com/Hobbes.html

Hobbes was first ported to Squeak by Dan Ingalls, later ported to VisualWorks by Vassili Bykov. There is an old version for Squeak available here.

You can see the VisualWorks version in action on a Simberon page.

Torsten Bergmann: Iliad webframework

2010-02-18T07:42:02+00:00

The Iliad web framework for Smalltalk now has a new website online:

http://www.iliadproject.org

Squeak Oversight Board: 2010 Election Announced

2010-02-17T23:41:51+00:00

The current Election Team Leader, Göran Krampe, has announced the plan and schedule for the election of the 2010 Squeak Oversight Board. Please read it and be prepared.

Squeak Oversight Board: Meeting Report for 2/17/2010

2010-02-17T21:09:04+00:00

For the (likely) penultimate meeting of this instance of the Squeak Oversight Board everyone other than Jecel Mattos de Assumpção was present: Ken Causey, Bert Freudenberg, Craig Latta, Andreas Raab, Randal Schwartz, and Igor Stasenko. Keep your eyes peeled on squeak-dev for announcements related to the upcoming Oversight Board Election.

Our discussions with the Software Freedom Conservancy continues and progress is occurring, if slowly at times. Right now we are clarifying the exact wording regarding the licensing of the 4.0 release. Squeak was originally released under a license written by Apple that we refer to as the Squeak License.

In 2006 Apple agreed to relicense the final release of Squeak from Apple (1.1) under the Apple Public Source License. After further thoughts and discussions this was decided to be a less than optimal choice and Apple agreed to relicense the release, this time under the Apache License.

Since that time work has been going on to solicit agreement from Squeak contributors to relicense all subsequent contributions under the MIT License. The result now is that parts of the image that are clearly descendants from the 1.1 release are under the Apache License and more recent contributions are under the MIT License. These two licenses are compatible.

The question is whether we can simply say ‘MIT License’ or have to say something like ‘parts under the Apache License with the remainder under the MIT License’. We are awaiting guidance from SFC on this issue. Once we sort that out we will be announcing the intent to officially release a version under the new licensing conditions as widely as possible with the goal of ensuring that all contributors to Squeak are aware of the change.

We spent most of the rest of the meeting discussing trunk work and the possibility of an imminent release. We are currently thinking of a release in about 2 months if everything goes smoothly. Expect email from Andreas on squeak-dev soon discussing what needs to be done and soliciting opinions and assistance.

Our next meeting is scheduled for March 3rd, 2010.

Squeak Oversight Board: Preliminary Agenda for 3/3/2010

2010-02-17T20:59:15+00:00

Election

Squeak 4.0 and SFC

Free server hosting options

Promotion and Visibility of Squeak

Development Progress

Squeak Swiki Improvement