to be fair, we can time stamp those network messages in SC. Or, as we
call it, tame stimp them.
On 22 Jan 2010, at 14:53, Kassen wrote:
> Alex;
>
> Well if a free software ecosystem gives maintainers the responsibility
> to accept patches, without fragmenting the development effort, then it
> seems to me that with GPLd ChucK you don't have that right. If you
> take the FSF definition of free (a big if, admittedly), partially
> encoded in the GPLv3 (rather than the definition behind e.g. the BSD
> license) , then I don't think you can call ChucK a free software
> ecosystem if it also engages with the iphone.
>
>
> Well, I was assuming that none of the bits that got ported to become
> ChiP were patches by people who aren't also in Smule. That seems
> like a fairly safe assumption if you compare the list of ChucK
> authors to Smule employees. I have no proof for this but am assuming
> good intentions and my contacts with the people involved make me
> believe that good intentions are a safe assumption as well :-). As I
> read things the worst that could happen would be that Smule would
> violate the GPLv2 if third party patches would have gotten into ChiP
> somehow. As unpleasant as that might be I don't see how that would
> affect the ChucK source which I still have right here which is still
> under the GPLv2. The GPL allows me to do things to and with it, I
> don't see how it prevents Ge, Perry, Spencer, etc from also doing
> other things with it seeing as how the GPLv2 doesn't imply they are
> waving the copyrights that they hold. I still fail to see the
> problem though admittedly some trust is involved.
>
> compare;
> http://www.smule.com/about
> http://chuck.cs.princeton.edu/doc/authors.html
>
> We could fork it, in a way I already did as I'm running a slightly
> customised version using a fix to a UGen by Tom but I don't see how
> that would prevent a hypothetical Smule made up of sneaky bastards
> from putting that fork on the iPhone too. If you would be such a
> sneaky person you could do such things, some parties have been known
> to. That's something I associate with a certain Redmond company
> though, not with Toplap members.
>
>
> If you would indeed demand that patches get accepted then you could
> call ChucK non-free because it's often not all that easy to get
> patches in. That would be a bit pedantic, I feel, because the chief
> issue there seems to be a infrastructural mess and overworked devs,
> not a literal reluctance to accept patches as such; we could use
> some ( http://wiki.cs.princeton.edu/index.php/ChucK/Bugs/Release ).
> It should be noted that where ChucK borrows code (for example from
> the STK or from SC) that is noted quite clearly in the source.
>
> Maybe I misunderstand the exact issue that you are pointing out. If
> so you may need to clarify it and we may need to get some real
> comments form the people involved. For me the fragment of the list-
> post I quoted in my last mail is good enough but it may not address
> your problem.
>
>
> On the subject of fork vs spork -- I think supercollider allows
> similar sample accurate concurrency but I don't know of any others.
> Did I already link to this paper?
> http://lambda-the-ultimate.org/node/3332
>
>
> I believe SC uses a client-server model between the server and the
> language and this uses a network connection (most likely to local
> host). Network messages aren't realtime in the strict formal sense.
> They aren't guaranteed to arrive in order, in time or even at all,
> as I understand things. Of course they will, most of the time, but
> that's a real difference.
>
> Personally I think it would be a very good thing if our esteemed
> colleagues / mortal enemies in the SC scene would adopt some more
> funny words of their own as funny words are funny.
>
> Yours,
> Kas.
Received on Fri Jan 22 2010 - 14:59:55 GMT