bundleage

cwright's picture

In response to gtoledo's notes (in a slight thread hijack).

gtoledo3 wrote:
If you backwards engineer something, and distribute the resulting code, you are distributing code that isn't yours. So, using the analogy, if my qtz has been reduced to assembly or something (don't kill me with my semantics), and I use class dump to then backwards engineer it, and then distribute swarths of programming based on it, it's actually violating TWO principles. Backwards engineering & distribution of copyrighted materials.

you're building a strawman. Why would anyone reverse engineer a function that exists in QC, and then re-distribute it? The function's already there for use! (I even wrote a dyld-like linker to get access to non-exported functions, fun stuff that). The only cases where reverse engineering assembly (in the context of QC + skankysdk stuff) is to figure out an interface (interfaces aren't copyrighted), to figure out how something works because you plan on making a similar one (in which case, you're not redistributing the same function), or because you need to shim a function (so again, what you're producing isn't the same function). This quickly devolves into "what is a derivative work" and all that, and that's for the courts to decide. I've not reimplemented any built-in functions exactly, because there's no need to do so. If I make a song that happens to have the same note as one of yours, did I copy it? what if I happen to have a single instruction in common in a program? A single function? Where's the line?

gtoledo3 wrote:
The mention of bundling the framework is potentially hacky and egregious, but I also suggest that this may not be the only solution. Maybe it is. I suggest the framework bundle, or other "grab working code to make a patch" route, even though I'm pretty famously a defender intellectual property, because I think this rates about a zilch on Apple's radar (eh, yeah, I'm wresting with justification on that. It shouldn't be redistributed). I do know it (structure hijinx) was a surprise that came up after release of the last QB.

Bundling the framework is illegal. End of story. Bundling functions that work similarly is not (patent stuff notwithstanding). I agree that there's another potential solution (shim the world), but the cost of implementing it vs. the benefit of the result probably don't make it justified (that's for Kosada to decide).

gtoledo3 wrote:
Remember: QB already grabs things that are not redistributable Apple sample code. ImageDiffer, and friends, are not redistributable sample code. The fact that QB bundles them into resources is a hack, and already a violation.

anther strawman. There are potentially legal cases for those to be redistributed, and it's under user control. QB isn't in the copyright enforcement business, so it's obviously not going to prevent you from doing illegal things. However, it by itself is not an illegal product. If it started shipping with legacy versions of QC.framework, QB itself would be illegal for Kosada to distribute. Again, Period. If you're suggesting it simply includes the user's current framework version (so it doesn't ship with them), it's plausible, but the number of users who could legally use that feature can be counted on zero hands. There's no infrastructure in QB for swizzling runtime frameworks in the manner you're suggesting, so new functionality would need to be developed which would almost certainly legally benefit nobody. That's not an effective use of developer resources.

gtoledo3's picture
Re: bundleage

Splitting this off, and making it a separate topic is non-productive.

What would have been productive was alpha testing Quartz Builder so that the bugs wouldn't have seen release, in the same manner as has been done previously. I stated it wasn't alpha tested per the usual, and I got a "what the heck are you talking about" (paraphrasing) from Jaymie that was disingenuous to say the least.

That's the issue; passive aggressive half assery in updating a product that I use quite a bit and have directly spec'ed some functions of (you can skewer my semantics if you wish), and knowing that not only could some of the initial bugs have been avoided (you know, the ones that necessitated a new version within a day or two), but also, some currently outstanding ones.

I wonder how long it would have taken to send the alpha per usual. How many keystrokes does that take, and is it worth it? 4-5 keystrokes? 30 seconds?

You, who devoured QC, realized the wisdom in that approach, when you were the lead on the project. I've seen this same "passive aggressive things into mediocrity" and "defend code, against all common sense and logic, that is wrong/crashes/is bunk " happen in other areas @ kineme aside from this project, and I'm not exactly crazy about the shift. At least this one only costs around $20 (can't remember the price).

If it's spiraled into something else (and I guess it has), I don't feel like indulging that any more here. You know my email, and you have my phone number.

mattgolsen's picture
Re: bundleage

As a constant lurker on these forums, and observer of how this community is handled I would like to chime in with my 2 cents.

Firstly, I would agree on separating the topic from the original topic. It didn't add anything to the original bug posting.

The way that I look at Kineme is that when cwright left, the entire expectation of how they communicate, develop products etc changes completely. This also applies to how they test things. It's not reasonable to have the same expectations or relationship with smokris or jstrecker, as was had with cwright. I think that's a pretty fair assessment.

My general impression George, and please correct me if I'm wrong, is that you seem to be coming from a very emotional point of view. You had certain expectations of bug testing software that you were previously included in, but with the "change of the guard" so to speak, that's no longer occurring. I'd hate to see what I perceive as a good community, and in some cases, friends, suffer over something that ultimately boils down to logistics and communication.

I think ultimately though, all this is moot as the writing on the wall for QC is pretty clear. With the advent of several newer technologies, I fear that QC will be relegated to a technological curiosity.

gtoledo3's picture
Re: bundleage

There's a man behind the curtain here, so to speak...

We (kineme and I) are (were?) working on another project that you aren't aware of (I'm bringing this up, because there's a whole layer that is not apparent here, and now I'm somewhat forced to). Your assessment is a bit off - the basic flow of things has persisted well after cwright's departure.

So, in another "project" which is/was a collab, I criticized an idea that I felt was particularly poor (not just saying "this sucks, but enumerating the reasons why). I also endured the performance/coding of something else they were hired to do that would crash QC just from starting the thing (as in, it wasn't even tested on two machines), and the reaction was, instead of working that idea over into something good, or addressing the actual valid issues.... the reaction was (I feel) to start passive aggressively doing things like "oh, didn't send you that one", and/or moving like molasses. On this one, it's irksome, because there's issues (imo), and users can still pop a qtz in the thing, hit compile, and wind up with something wildly wrong, some of which would have been avoided, save for excessive hubris on the part of kineme.

I think it's reasonable to state that if the thing had been alpha tested (as I did on the original thread), that some of the bugs had been avoided. The part that didn't belong is the "huh, what makes you think it didn't get alpha tested" (paraphrasing), which is a ridiculous defensive reaction that flies in the face of reality, as is the idea that many of the bugs we're talking about are such a big deal to handle.

dust's picture
Re: bundleage

although I'm trying to follow what the root issue is here in regards to QB bugs. chris makes some interesting points in reference to getting access and backwards engineering code etc... it seems to me backwards engineering is how many products are made. i mean you are always taking the risk that someone could backwards engineer your patent then change a few things. that is why usually you would want to make your patent abstracts as vague as possible, so you can sort of not narrow your process down to specific material for example. so by saying things like this part is attached by a screw, a nut, a bolt or and adhesive etc.. protects your intellectual property from being reverse engineered easily. if you say i attach X to Y with a bolt all someone has to do is attach with a adhesive to change your process and be legally binding. which brings up some very interesting points when your dealing with code and frameworks i suppose it gets a lot more interesting. like amazons one click patent i guess would be a good example of what i'm talking about.

Quote:
There's no infrastructure in QB for swizzling runtime frameworks in the manner you're suggesting,

this part is pretty interesting to me as i have been playing around with runtime frameworks. as far as i can tell this sort of stuff is apple store legal. I'm not sure about swilling private frameworks or reversing some assembly and or swizzling the graph during run time. thats all sounds pretty complicated. it is interesting though. from what i understand swizzling is kind of like subclassing but your subclassing per say a method implementation instance at run time so its not really a subclass, or well I'm pretty sure a you can send a class a message in runtime so you could swizzle a class or subclass i guess. the point is if your re-implimentling the method or class at run-time it does sort of become a bit more unique. when your talking about swizzling methods particularly private ones i guess it becomes gray.

its really hard to say and all depends what kind of functionality your extending and how important it is. with qc being a developer tool its kind of like what is the point really if its a built-in function. how ever doing run-time things on the iPhone is very interesting to me and have been playing around with this sort of story board simulator i guess i would call it. as far as i can tell, although i have not tried lately you can not build an app with a plugin or bundle target type of architecture for the iPhone like you can for the mac using QC as an example of an app with a plugin architecture. so it seems this would be warranted to investigate and or be beneficially justifiable to do so in the iOS context and obviously warranted when there was no official QC plugin architecture.

i like how QB bundles resources for you. although in GT defense certainly reading a qc file in text - xml to check for a property in the file isn't to much of request. at least that would protect people from building your qtz file if you have copyright info filled in or some other sort of unique identifier. that doesn't stop you from changing or editing the info property though. now incorporating some sort of encryption protection sandbox or what ever into QB sounds like a good idea to me. more or less so people can create there own serial number scheme or something could be cool. just some thoughts ;)