The comment about sleeping lions is well taken, but I've worked with apple legal before, when they had their own building and were really mean (and overfed, happily :-)
I'd wait till all the heavies on this board weigh in for a concensus, but we do have a lawyer with some time he owes us and a lot of experience with our software and protecting it. I think he could probably do the job for us as a community, I'd volunteer him for the trenches if there is community interest, with the goal being absolute clarification (given legalese) of what's a hands off integration relationship with squeak, i.e. solid protection for plugin apps that do not have any squeak side modifications that aren't open sourced. In my own case, protect my plugin and let me keep my copyright on my unique grammar for communicating with my plugin, I'll even cough up _all_ my squeak side code, base platform or pure application.
If you're amenable or opposed to this idea, send me a note. I'll tabulate results for a few days and then repost them, and everybody can pitch in and bitch :-)
This is presupposing I'm not murdered on .dev for casting aspersions at iterator loop speeds.......
Regards
Mark
-----Original Message----- From: squeakfoundation-admin@lists.squeakfoundation.org [mailto:squeakfoundation-admin@lists.squeakfoundation.org]On Behalf Of squeakfoundation-request@lists.squeakfoundation.org Sent: None To: squeakfoundation@lists.squeakfoundation.org Subject: Squeakfoundation digest, Vol 1 #94 - 10 msgs
Send Squeakfoundation mailing list submissions to squeakfoundation@lists.squeakfoundation.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.squeakfoundation.org/listinfo/squeakfoundation or, via email, send a message with subject or body 'help' to squeakfoundation-request@lists.squeakfoundation.org
You can reach the person managing the list at squeakfoundation-admin@lists.squeakfoundation.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Squeakfoundation digest..."
Today's Topics:
1. Re: What I would like to promote (Bijan Parsia) 2. RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs (Mark Mullin) 3. Re: What I would like to promote (Dan Ingalls) 4. Re: RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs (Cees de Groot) 5. AW: [Squeakfoundation]RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs (Andreas Raab) 6. Re: What I would like to promote (Dan Ingalls) 7. AW: [Squeakfoundation]What I would like to promote (Andreas Raab) 8. Re: AW: [Squeakfoundation]RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs (Cees de Groot) 9. Re: AW: [Squeakfoundation]What I would like to promote (Cees de Groot) 10. Re: AW: [Squeakfoundation]What I would like to promote (goran.hultgren@bluefish.se)
--__--__--
Message: 1 Date: Wed, 30 Jan 2002 08:25:14 -0500 (EST) From: Bijan Parsia bparsia@email.unc.edu To: squeakfoundation@lists.squeakfoundation.org Subject: Re: [Squeakfoundation]What I would like to promote Reply-To: squeakfoundation@lists.squeakfoundation.org
On Wed, 30 Jan 2002, ducasse wrote:
Yes. Celeste mostly, at the moment. It really needs to be split up, and some of the classes it depends upon (E.g., MailDB) need, themselves to
be
refactored.
So celeste could be a good testbed for a refactoring process. Have you approach the celeste users and the people taking care of it.
There have been rumbles on the squeak-dev list from time to time ;)
Could you set up a war plan to clean celeste?
I think so.
Celeste is also interesting because it has a lot of functionality that even non-Celeste users might want. For example, sometimes you want to compose and send an email message from Squeak, but *don't* want to be a full fledged Celeste user. (E.g., mailing changesets/bugs/etc. to the list). There are a variety of Celeste UIs, etc.
It would be good to extract celeste from the squeak image, do a call for tests and lead a refactoring efforts. This way we could: - have a better celeste - learn in the process
Yep. And gain a few things in the process. Celeste's persistence mechanism is a tad primative...but useful! If it can be made so that the *interface* is relatively stable, but the storage backend and filter/query process were registerable, well, that would rule :)
I think that Celeste is "well" separated from the core so this could be interesting to try.
Yes.
Cheers, Bijan Parsia.
--__--__--
Message: 2 From: "Mark Mullin" mark@vibrant3d.com To: squeakfoundation@lists.squeakfoundation.org Date: Wed, 30 Jan 2002 10:32:22 -0500 Subject: [Squeakfoundation]RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs Reply-To: squeakfoundation@lists.squeakfoundation.org
OK, Cees seems to know whereof he speaks, he certainly calls our concerns out clearly, I'm off to read the GNU Library license again.
I'd be curious if anyone has already clarified it's application to the reverse situation, i.e. our VR engine is fundamentally a (great big fat badtempered) plugin library for Squeak. We have no problem giving away any changes we make to squeak or any non-VR code, we just want to protect our copyrights on our core library plugin. Anyone seen how the LGPL has been applied to this, say in creating 3rd party commercial libraries for gnu compilers.
Re the death of IP in general, Cees, I'd tend to agree, software patents show how low we are sinking. On the other hand, one needs to make a living. And in general, if you give it away and ask them to pay if it works, you starve.
Mark
--__--__--
Message: 3 Date: Wed, 30 Jan 2002 07:49:09 -0800 To: squeakfoundation@lists.squeakfoundation.org From: Dan Ingalls Dan@SqueakLand.org Subject: Re: [Squeakfoundation]What I would like to promote Reply-To: squeakfoundation@lists.squeakfoundation.org
Yes. Celeste mostly, at the moment. It really needs to be split up, and some of the classes it depends upon (E.g., MailDB) need, themselves to be refactored.
So celeste could be a good testbed for a refactoring process. Have you approach the celeste users and the people taking care of it. Could you set up a war plan to clean celeste?
It would be good to extract celeste from the squeak image, do a call for tests and lead a refactoring efforts. This way we could:
- have a better celeste
- learn in the process
I think that Celeste is "well" separated from the core so this could be interesting to try.
I agree. If you look at changeSet #3746, ... ----------------- Introduces a new image partitioning tool that is essentially a local version of majorShrink. The idea is to pick some application like Scamper, or some cluster like all the 3D classes, and remove it, and also remove everything that is solely referred to by it. The way it works is: Record all unsent messages and unused classes at the outset Mark the application or cluster as removed Note all *newly* unreferenced methods and unused classes and iteratively remove them as well For example, the expression Smalltalk reportClassAndMethodRemovalsFor: #(Celeste Scamper MailMessage) reports 63 classes and 155 other messages that can be removed.
Also, introduces a new method, fileOutAndRemove:... that will take such results, build a changeSet from them, fileOut everything that is about to be removed, and then remove all of the classes and related messages as well. For the above example, this method produces a 290k fileOut, and saves about 104k from the system. More importantly, if you fileIn the changeSet afterward, the system returns to approximately its former size, and you can run Scamper again. It's a way to fileOut a package that never existed. -------------------
So a year ago, that group and that method (for which there is now equivalent code in modules) worked perfectly as a module a year ago.
- Dan
--__--__--
Message: 4 To: squeakfoundation@lists.squeakfoundation.org From: cg@home.cdegroot.com (Cees de Groot) Subject: Re: [Squeakfoundation]RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs Date: 30 Jan 2002 17:23:47 +0100 Organization: cdegroot.com Reply-To: squeakfoundation@lists.squeakfoundation.org
Mark Mullin mark@vibrant3d.com said:
I'd be curious if anyone has already clarified it's application to the reverse situation, i.e. our VR engine is fundamentally a (great big fat badtempered) plugin library for Squeak.
That centers around "If the Modified Software contains modifications, overwrites, replacements, deletions, additions, or ports to new platforms of: (1) [class lib], or (2) any part of the virtual machine, then [you have to share the source].
I would not call a plugin library an addition to the virtual machine - the VM is for me the SLANG stuff plus the platform glue, and I think that that's what is meant in the license.
I *think* that Apple did not mean to call a plugin library an addition to the virtual machine. However, a bad-tempered lawyer at Apple *could* construe your plugin library to be an addition to the virtual machine. Given the track record of big companies' legal teams smelling profit, blood, or just fun, I'd get a statement from Apple "we don't consider the vibrant 3D plugin as a blahblahblah"...
(even though I always had A's in business school for Law: I.A.N.A.L.)
-- Cees de Groot http://www.cdegroot.com cg@cdegroot.com GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B
--__--__--
Message: 5 From: "Andreas Raab" Andreas.Raab@gmx.de To: squeakfoundation@lists.squeakfoundation.org Subject: AW: [Squeakfoundation]RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs Date: Wed, 30 Jan 2002 19:21:36 +0100 Reply-To: squeakfoundation@lists.squeakfoundation.org
I would not call a plugin library an addition to the virtual machine - the VM is for me the SLANG stuff plus the platform glue, and I think that that's what is meant in the license.
At the time the license was written, there was no such concept as a Squeak VM plugin. However, one of my major motivations for doing the VM plugins was in particular to be able to "access" proprietary code. In other words, a plugin is nothing but an optimized FFI interface (it really is). That's my way of thinking about it and I don't believe that anyone would consider some function called through FFI being an "addition to" the virtual machine.
I *think* that Apple did not mean to call a plugin library an addition to the virtual machine. However, a bad-tempered lawyer at Apple *could* construe your plugin library to be an addition to the virtual machine.
That reminds of a recent conversation with a lawyer. Asking "okay, so how can make this issue airtight" the response was "Heck, you are talking about law here! There is no such thing as 'airtight' in law. Companies can sue you and they _will_ sue you no matter what you do."
Given the track record of big companies' legal teams smelling profit, blood, or just fun, I'd get a statement from Apple "we don't consider the vibrant 3D plugin as a blahblahblah"...
Actually, having a number of companies ask for their permission might just raise their interest. Don't wake sleeping lions...
Cheers, - Andreas
--__--__--
Message: 6 Date: Wed, 30 Jan 2002 11:07:34 -0800 To: squeakfoundation@lists.squeakfoundation.org From: Dan Ingalls Dan@SqueakLand.org Subject: Re: [Squeakfoundation]What I would like to promote Reply-To: squeakfoundation@lists.squeakfoundation.org
ducasse ducasse@iam.unibe.ch wrote...
I think that Celeste is "well" separated from the core so this could be interesting to try.
Hi Stef -
I've been reflecting more on this since responding to your message. I completely defer to you and Henrik on which way to go, but I see a choice here:
Either we... Find various small things that are pretty modular and do them first
Or we... Take various big chunks that are pretty modular and do them first.
By "big chunks", I'm thinking along the lines of the various discardX methods in SystemdDictionary (like all of 3D, all of networking, etc). So this would mean instead of doing Celeste, we do all of Networking as a chunk. Then *later* we refine this and break networking down into Celeste, Scamper, IRC, HTML, PWS, etc.
I just have the feeling that it might not be much harder to draw isolation lines around the big chunks than it is around the little ones, and the payoff might be higher, in that it might *soon* be possible for mere mortals to perform their own versions of majorShrink, and have it really work.
As I say, I'm happy to go with whatever you guys decide, but I did want to call attention to the choice, and have you make a conscious decision.
- Dan
--__--__--
Message: 7 From: "Andreas Raab" Andreas.Raab@gmx.de To: squeakfoundation@lists.squeakfoundation.org Subject: AW: [Squeakfoundation]What I would like to promote Date: Thu, 31 Jan 2002 00:04:20 +0100 Reply-To: squeakfoundation@lists.squeakfoundation.org
Dan,
Personally, I'm in for some of the larger chunks first. Why? Well, for one thing it's going to test out the framework in some areas that'll really benefit all of us. Secondly, it's perhaps not as easy to define the boundaries for an application like Celeste (some people have already pointed out that some of the stuff Celeste is doing might be of interest for other apps so a careful definition of boundaries is important). Thirdly, having fast and "big" results (like the ability to cut out and load stuff like Wonderland and 3D) will convince people that we're _seriously_ talking about modularity and encourage them to build their own designs into their frameworks.
Just my =80.02, - Andreas
-----Urspr=FCngliche Nachricht----- Von: squeakfoundation-admin@lists.squeakfoundation.org=20 [mailto:squeakfoundation-admin@lists.squeakfoundation.org] Im=20 Auftrag von Dan Ingalls Gesendet: Mittwoch, 30. Januar 2002 20:08 An: squeakfoundation@lists.squeakfoundation.org Betreff: Re: [Squeakfoundation]What I would like to promote =20 =20 ducasse ducasse@iam.unibe.ch wrote...
I think that Celeste is "well" separated from the core so=20
this could be
interesting to try.
=20 Hi Stef - =20 I've been reflecting more on this since responding to your=20 message. I completely defer to you and Henrik on which way=20 to go, but I see a choice here: =20 Either we... Find various small things that are pretty modular and do them first =20 Or we... Take various big chunks that are pretty modular and do them first. =20 By "big chunks", I'm thinking along the lines of the various=20 discardX methods in SystemdDictionary (like all of 3D, all of=20 networking, etc). So this would mean instead of doing=20 Celeste, we do all of Networking as a chunk. Then *later* we=20 refine this and break networking down into Celeste, Scamper,=20 IRC, HTML, PWS, etc. =20 I just have the feeling that it might not be much harder to=20 draw isolation lines around the big chunks than it is around=20 the little ones, and the payoff might be higher, in that it=20 might *soon* be possible for mere mortals to perform their=20 own versions of majorShrink, and have it really work. =20 As I say, I'm happy to go with whatever you guys decide, but=20 I did want to call attention to the choice, and have you make=20 a conscious decision. =20
- Dan
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation =20 =20
--__--__--
Message: 8 To: squeakfoundation@lists.squeakfoundation.org From: cg@home.cdegroot.com (Cees de Groot) Subject: Re: AW: [Squeakfoundation]RE: Squeakfoundation digest, Vol 1 #93 - 8 msgs Date: 31 Jan 2002 08:33:29 +0100 Organization: cdegroot.com Reply-To: squeakfoundation@lists.squeakfoundation.org
Andreas Raab Andreas.Raab@gmx.de said:
[...]. That's my way of thinking about it and I don't believe that anyone would consider some function called through FFI being an "addition to" the virtual machine. [...] Actually, having a number of companies ask for their permission might just raise their interest. Don't wake sleeping lions...
Maybe it'd be an idea if SqC would ask Apple for a clarification here. I think it is a very important issue that we can make clear (in terms that a lawyer will accept) what is and what isn't allowed in the area of proprietary extensions - if you want to make a product a success, you need to be prepared for companies wanting to earn money with it. The plugin bit seems to be a big hole in the license...
(or maybe it would be enough to strike the term 'plugin' and call it 'fastFFI' ;-))
You may be right with your remark about now waking sleeping lawyers. I may be right with my remark about better being safe than sorry. WANL (we are not lawyers). IMHO, the fact that this arouses questions that I feel we cannot answer is a bug that should be fixed.
-- Cees de Groot http://www.cdegroot.com cg@cdegroot.com GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B
--__--__--
Message: 9 To: squeakfoundation@lists.squeakfoundation.org From: cg@home.cdegroot.com (Cees de Groot) Subject: Re: AW: [Squeakfoundation]What I would like to promote Date: 31 Jan 2002 08:34:14 +0100 Organization: cdegroot.com Reply-To: squeakfoundation@lists.squeakfoundation.org
Andreas Raab Andreas.Raab@gmx.de said:
Personally, I'm in for some of the larger chunks first.
Add my vote to that.
-- Cees de Groot http://www.cdegroot.com cg@cdegroot.com GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B
--__--__--
Message: 10 Date: Mon, 28 Jan 2002 11:01:10 +0100 Subject: Re: AW: [Squeakfoundation]What I would like to promote To: squeakfoundation@lists.squeakfoundation.org From: goran.hultgren@bluefish.se Reply-To: squeakfoundation@lists.squeakfoundation.org
cg@home.cdegroot.com (Cees de Groot) wrote:
Andreas Raab Andreas.Raab@gmx.de said:
Personally, I'm in for some of the larger chunks first.
Add my vote to that.
Another vote too. By the way - I have voting capability on SqueakDot now, so I added this one, and I have already voted for me, Cees and Andreas - vote here:
http://marvin.bluefish.se:8080/squeakdot
This is what I referred to as the "Cell Splitting Approach". :-)
regards, Göran
--__--__--
_______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
End of Squeakfoundation Digest
Hello Mark Mullin,
At 10:42 31-1-02 -0500, you wrote:
The comment about sleeping lions is well taken, but I've worked with apple legal before, when they had their own building and were really mean (and overfed, happily :-)
I'd wait till all the heavies on this board weigh in for a concensus, but we do have a lawyer with some time he owes us and a lot of experience with our software and protecting it. I think he could probably do the job for us as a community, I'd volunteer him for the trenches if there is community interest, with the goal being absolute clarification (given legalese) of what's a hands off integration relationship with squeak, i.e. solid protection for plugin apps that do not have any squeak side modifications that aren't open sourced. In my own case, protect my plugin and let me keep my copyright on my unique grammar for communicating with my plugin, I'll even cough up _all_ my squeak side code, base platform or pure application.
If you're amenable or opposed to this idea, send me a note. I'll tabulate results for a few days and then repost them, and everybody can pitch in and bitch :-)
This is presupposing I'm not murdered on .dev for casting aspersions at iterator loop speeds.......
Regards
Mark
Well - I could have done more programming if I had not been forced to spend quite a lot of time in Dutch court-cases (not related to software development at all). So I have some real life experience with courts and lawyers (and prefer to do my own cases, and to stay out of courts). What concerns me are the following general points:
1. To protect Squeak from any commercial take-over if it is getting succesful. (E.g.: What if MS takes over Apple?) 2. To protect Squeak and SqueakFoundation from any legal threats (for this is how lawyers appear to work: Start a court-case and break down the opponent simply by being forced to defend oneself: most persons have too much to loose not to be willing to "compromise" and "settle"). 3. To keep Squeak definitely open source - which seems to me (but I am naive and ignorant here) by having all code contributors both own their code and giving it away as open source (as in science: your contributions, if any, will be part of science, but your publications are yours, and you get the public credit, as in "So-and-so's Theorem"). 4. Allow commercial application of Squeak without any consequences for Squeak's open source status and development (as e.g. geology is applied by oil-businesses).
Most of this seems covered by the Squeak license, in intent at least, but one of my problems is that I've read diverse licenses and discussions on their relative merits I can't make much of, being no lawyer and no US citizen.
Also, being a philosophical type I'm interested in how Squeak and open source fit in any property-law at all, but this probably is up to courts and legal philosophers rather than practical lawyers. (To me it appears Squeak is developed mostly like a free conversation between free individuals, and just as in conversations there are responsibilities and originators but no ownership issues, since there is no transferable commodity. This is similar again to science, and what complicates matters is that Squeak.exe etc. is applied science and technology.)
In any case, I for my part would with interest read the legal opinion of a specialist, especially if it is written in English, not legalese - and if I don't have to pay for it. But maybe my concerns are too academic ....
Regards,
Maarten.
------------------------------------------ Maarten Maartensz. Homepage: http://www.xs4all.nl/~maartens/ ------------------------------------------
squeakfoundation@lists.squeakfoundation.org
-
Maarten Maartensz -
Mark Mullin