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:54:36 GMT