Why composition is often better than inheritance - <AUTHOR> http://joostdevblog.blogspot.com/2014/07/why-composition-is-often-better-than.html <comment><USER3> Meh. I think this phrase has been repeated until it has lost any connection with the original intent and turned into a generic "INHERITANCE BAD! COMPOSITION GOOD!" without much meaning attached to either word.

I haven't found the original source, but I've always presumed the statement originally referred to some of the bizarro "inheritance-as-composition" stuff in the early C++ days: for instance, you might have a class 'Window' and a class 'Button', then combine them with multiple inheritance to get a 'WindowWithButton', then inherit from _that_ and a 'Scrollbar' class to get 'WindowWithButtonAndScrollbar'.

I can't imagine anybody thinking of that as a "good" pattern today, but remember it was the '90s. :)

Nowadays, the basic statement has been dogmatized to the point where you get code like this:

[https://github.com/elm-city- craftworks/broken_record/blob/ma...](https://github.com/elm-city- craftworks/broken_record/blob/master/lib/broken_record/composable.rb)

This code re-implements Ruby's built-in method lookup algorithm, but with per- instance objects and none of the optimizations available to the real thing. It basically remakes inheritance, slowly and poorly, using composition.

The other one that makes me scratch my head: people who rail against inheritance, then suggest mixins as an alternative. At least in Ruby, the two are _equivalent_. Check the `ancestors` property on a class with mixins sometime if you don't believe me.

TL;DR (too late) - use your damn brain to make decisions, not just parrot slogans.

<comment><USER4> You can only inherit from one class in ruby. You can mixin multiple modules into a class. So they aren't entirely equivalent.

<comment><USER5> Under the hood, mixing in modules _actually is_ inheritance. An anonymous class is created that has all the module's methods, and this class is added to the inheritance hierarchy.

They are quite literally identical, even if Ruby tries it's best to hide that fact.

</comment></comment></comment><comment><USER6> While it's possible to overuse inheritance, I don't think replacing it with composition is all that much better, and in addition all those forwarding methods that do nothing more than call another (could they even be optimised out?) are a great example of code that would need to be written, consuming resources like programmer time, but otherwise serves no true useful purpose to the functionality of the software. The complexity only changes form, so instead of tracing the flow through an inheritance hierarchy you're just doing it through chains of forwarding methods. It's for this same reason I don't believe so much his argument for readability and short classes - <USER2> everything up does not make things simpler, it makes the complexity spread out over a larger area; while it may be true that it is easier to understand an individual piece, it becomes more difficult to understand the system as a whole. This is especially important when debugging, where "can't see the forest for the trees" is a big hindrance.

I think his example of flexibility is the strongest argument for composition, because in that case the forwarding methods are not a waste - they would need to do (useful) work to determine which of the multiple composited objects they would need to work with.

Being mostly a C programmer who does OO-things, I use inheritance when it's obvious that most of the "methods" will be passthroughs to the "superclass", and composition when there is something more that needs to be done. Also, as I am not constrained by the OO model/conventions of the language, it's more flexible in that I can do things like "inherit" multiple times and even change that at runtime, so there is really no strict separation between composition and inheritance; to me, it's just "which function do I set this to point to."

<comment><USER7> > The complexity only changes form, so instead of tracing the flow through an > inheritance hierarchy you're just doing it through chains of forwarding > methods. It's for this same reason I don't believe so much his argument for > readability and short classes - breaking everything up does not make things > simpler, it makes the complexity spread out over a larger area; while it may > be true that it is easier to understand an individual piece, it becomes more > difficult to understand the system as a whole.

Preach it! Whilst immense monolithic classes are bad, smashing a system up into a million tiny bits is just as much of a barrier to understanding. It is baffling to me that this is not immediately obvious to everyone.

See also the microservices movement!

</comment></comment><comment><USER8> While it's a well-written article, it really seems like beating a dead horse. Composition over inheritance is a basic rule of OO programming, so much so that it has its own wikipedia page ([http://en.wikipedia.org/wiki/Composition_over_inheritance](http://en.wikipedia.org/wiki/Composition_over_inheritance))

<comment><USER9> This horse still needs to be beaten.

Messy inheritance still plagues product Java, C#, and, with the increasing proliferation of MVC frameworks, JS these days.

Hierarchies usually start out small. But, when new features are added and scope creeps, they get deeper and more abstract and messier.

Substitutability (i.e. the L in SOLID principles) does require more boiler- plate when using composition though. Interfaces and mixins (if available in your language) go some way to helping.

<comment><USER10> I wish we could move beyond this idea that just because someone uses a particular language their code is going to be poorly written.

<comment><USER11> But is true that some languages make some kind of bad/problematic code MORE common, and requiere discipline and/or knowledge to combat it (and like in this case, is likely that the avg developer is not aware of the alternatives at all.)

</comment></comment></comment></comment><comment><USER12> In Python, we use mixins. Mixins can _only_ inherit from 'object' and nothing else, like this:

        class PhysicsobjectMixin(object):
            def update_physics(self):
                pass

            def apply_konckback(self, force):
                pass

            def get_position(self):
                pass

        class FightMixin(object):
            def attack(self):
                pass

            def defend(self):
                pass

        class TalkMixin(object):
            def say_something(self):
                pass

        class Character(PhysicsobjectMixin, FightMixin, TalkMixin):
            pass

        class Pickup(PhysicsobjectMixin):
            pass

        class Projectile(PhysicsobjectMixin):
            pass

it's still inheritance, but the classes will be flat; every class only inherits one deep, so there will be no diamond problems and no repeating code.

<comment><USER13> I don't see the difference to interfaces.

<comment><USER14> With interfaces, the above example would look like this:

        from abc import ABCMeta

        class PhysicsobjectMixin(ABCMeta):
            @abstractmethod
            def update_physics(self):
                pass

            @abstractmethod
            def apply_konckback(self, force):
                pass

            @abstractmethod
            def get_position(self):
                pass

        class FightMixin(ABCMeta):
            @abstractmethod
            def attack(self):
                pass

            @abstractmethod
            def defend(self):
                pass

        class TalkMixin(ABCMeta):
            @abstractmethod
            def say_something(self):
                pass

        class Character(PhysicsobjectMixin, FightMixin, TalkMixin):
            def update_physics(self):
                pass

            def apply_konckback(self, force):
                pass

            def get_position(self):
                pass

            def attack(self):
                pass

            def defend(self):
                pass

            def say_something(self):
                pass

        class Pickup(PhysicsobjectMixin):
            def update_physics(self):
                pass

            def apply_konckback(self, force):
                pass

            def get_position(self):
                pass

        class Projectile(PhysicsobjectMixin):
            def update_physics(self):
                pass

            def apply_konckback(self, force):
                pass

            def get_position(self):
                pass

This is not DRY at all. I like mixins much better.

<comment><USER15> It's not DRY, but then again, the chances of not overwriting, or more likely adding something to that method are pretty small when your project becomes more than an illustration of a principle.

For example, what if you want to add custom animations any time your `Character` takes an action? Suddenly, all that boilerplate you "abstracted" away through mix-ins is back, with a vengeance. How about if your physics for a `Projectile` are different than for a `Pickup`? What if your character suddenly picks up a Sling of Thrown Voices, and needs to apply conversation snippets to its projectiles?

In simple examples, mixins are great and reduce a lot of boilerplate, but in reality they are rarely so clean.

<comment><USER14> > For example, what if you want to add custom animations any time your > `Character` takes an action?

What's wrong with this?

        class Character(PhysicsobjectMixin, FightMixin, TalkMixin):
            def attack(self):
                # custom attack animation here
                return super(Character, self).attack()

            def defend(self):
                # custom defend animation here
                return super(Character, self).defend()

For me, it's still clear that 'attack' and 'defend' extends the funcionality of the 'FightMixin'. I can see even the first glance, those are inherited methods, because they use super() (call parent methods)

> How about if your physics for a `Projectile` are different than for a > `Pickup`?

You need to implement two classes anyway. I see two possibilities:

I. If you have to implement this kind of different physics behavior only for Projectile. (Maybe you don't even need a mixin.)

        class Projectile(object):
            def update_physics(self):
                pass

            def apply_konckback(self, force):
                pass

            def get_position(self):
                pass

II. If you have more Projectile-like objects, but they are not all the same.

       class FastMovingPhysicsobjectMixin(object):
            def update_physics(self):
                pass

            def apply_konckback(self, force):
                pass

            def get_position(self):
                pass

        class Projectile(FastMovingPhysicsobjectMixin):
            pass

        class Arrow(FastMovingPhysicsobjectMixin):
            pass

> What if your character suddenly picks up a Sling of Thrown Voices, and needs > to apply conversation snippets to its projectiles?

Is this a weapon which doesn't shoot projectiles, but make damage with voice or what? :D Then I think it's totally different, because if Character can have all kinds of different weapons and those behave different ways, mixins don't fit here. I would rather implement that like this:

        class Sword(object):
            def attack(self):
                # swing

            def defend(self):
                # defend

        class SlingOfThrownVoices(object):
            def attack(self):
                # shout loudly

            def defend(self):
                # pssszt, be quiet

        class Character(PhysicsobjectMixin, TalkMixin):
            def __init__(self, weapon):
                self.weapon = weapon

            def attack(self):
                # custom attack animation here
                self.weapon.attack()

            def defend(self):
                # custom defend animation here
                self.weapon.defend()

then weapon can be instance of either Sword or SlingOfThrownVoices. Note that Mixins are still in use and no complicated inheritance problem occured even if you have hundreds of weapons.

</comment></comment></comment></comment></comment><comment><USER16> Consider how these things get stored. In the inheritance model, you might have a big quad tree or some other data structure of PhysicsObjects, and just run through and call updatePhysics() on all of them.

In the composition model, we now have multiple classes (Character, Pickup, Projectile), each with an _unrelated_ updatePhysics(). This means code duplication to call the relevant method on each separate class.

We could relate them all via an interface, instead of inheritance; now we can store IEntity or whatever. We will soon discover three needs that are awkward to address:

1\. Whenever we want to add some new method (say `fall`), we must go back and implement it separately in each class.

2\. Different classes will want to share implementations. For example, both Characters and Pickups bounce on fall.

3\. Some classes will want to specialize an implementation to do more. Characters bounce on fall, but also take damage.

In practice you may end up with both: an interface that your engine talks to, but also a common base class that provides sane defaults.

So while interfaces allow uniform interactions with disparate classes, inheritance provides that and also the ability to share and specialize the implementations. So inheritance solves some problems that interfaces cannot.

See also default methods in Java, which makes an interface more like a class, and implementing an interface more like inheritance. The documentation even says that a class that implements an interface inherits its default methods.

<comment><USER17> I've seen this problem in projects I've worked on recently. It's gotten me more interested in Ruby mixins as a solution, though I haven't worked on any really complex object structures in Ruby. The project in question is in C#, and you can sorta-almost do something like it by creating interfaces and putting the methods that should be shared as extension methods on it, but it feels very hacky.

</comment></comment><comment><USER18> I think this is a tooling issue. People initially tend to favor inheritance because it looks cleaner than composition. Mixing a lot of unrelated code in the same class makes things hard to find. (which method applies to which composed object?)

In languages that build in a concept of traits/mixins however, this isn't an issue.

<comment><USER19> I think so too.

In JS it's rather easy to compose objects. In Java it feels clunky, you code looks kinda wrong when you done.

<comment><USER20> I don't quite understand this. In my opinion JS "classes", if you want to call them that, look, feel and act very clunky. My opinion, of course... Please could you explain to me how _you_ feel Java "classes" feel clunky and look wrong? I'm genuinely curious, and open to being convinced.

 _Note_ I substituted your usage of "objects" with classes, because they're vastly different concepts. I know, murky water when it comes to JS, but still.

<comment><USER19> My point was, classes and inheritance feel natural in Java. Object-Composition feels natural in JS.

</comment></comment></comment></comment><comment><USER21> I would prefer this with "why a shallower abstraction pool is better than a deep one." I've seen some compositional concoctions that were just as terrible to deal with as inheritance based ones. I think I've even contributed/originated some.

</comment><comment><USER22> We've known this since at least 1994, when the GoF book [1] famously said:

"Favor object composition over class inheritance"

[1] [http://www.amazon.com/Design-Patterns-Elements-Reusable- Obje...](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object- Oriented/dp/0201633612)

<comment><USER23> Ha, that's one of the few things I remember from that book. (Not knocking the book, just my poor memory.) I remember it being a big "a ha!" for a project I was working on.

</comment></comment><comment><USER24> When I try to choose between the two, I often like to think if the object I try to inherit from is from the same domain/context and solves a related problem. In the example in the article a PhysicsObject solves the problem of calculating coordinates in space and from the beginning it was not designed as something to be used in the game by itself. While the character participates in the actual game and executes the game logic. The character does not 'inherit' from PhysicsObject, it merely knows that PhysicsObject represents it in the space.

</comment><comment><USER25> It's pretty much the same example I used here a couple of days ago: [https://news.ycombinator.com/item?id=7976227](https://news.ycombinator.com/item?id=7976227)

Game development seems to be the poster child for composition over inheritance.

Here's a lengthy article that explains it way better (IMHO): [http://gameprogrammingpatterns.com/component.html](http://gameprogrammingpatterns.com/component.html)

</comment><comment><USER26> I think one of the biggest reasons why most libraries/frameworks/apps/etc. use inheritance over composition is the easy with which the underlying languages allow the use of inheritance as opposed to composition. Most of these software writers know SOLID and other OO principles but when they're faced with the actual implementation, inheritance is just too damned easy to implement.

</comment><comment><USER27> The Wikipedia article chton mentions ([https://en.wikipedia.org/wiki/Composition_over_inheritance](https://en.wikipedia.org/wiki/Composition_over_inheritance)) ends with the following when discussing the drawback of composition (boilerplate for forwarding methods): "This drawback can be avoided by using traits or mixins."

Now this is where things get a little blurry for me.

Mixins can help with the main drawback of Composition - but Mixins ARE inheritance - so isn't this a contradiction?

If I use PhysicsObjectMixin in my CharacterComposition class then I have to inherit from it. So aren't we back with the perils of inheritance?

<comment><USER8> the idea is that you create a mixin that has only the reference to the physics object and the forwarding methods. If you implement that mixin, it will be exactly equivalent as writing them out in your class, but you are spared from having to do it for every single class with a physics object.

Remember that a mixin, by definition, isn't the same as inheritance. The methods, fields and properties are compiled into the class, not inherited. It's essentially a fancy way to 'include' a code file.

<comment><USER28> Mixins can be implemented in a variety of ways, they don't need to be unmodularly inlined into class/object definitions as in scala. Also, mixin- style inheritance is by definition linearized multiple inheritance (at least according to cook/bracha, things get weirder with the Gabriel/Common Lisp definition).

<comment><USER8> It's true that they can be implemented in the same way, but the idea remains the same. Seeing mixins as inheritance is a far narrower definition than held by most languages (or libraries) that implement them. Mixins don't put any requirements on the polymorphism of the object that implements them, which ordinary inheritance does.

It's common to use the Flavors/Lisp defintion of mixins, but I'll make sure to read up on the Bracha-Cook paper about them.

<comment><USER28> There have been many implementations of mixins, and many that I'm aware of, like Scala, are inheritance based. The nice thing about mixin style inheritance is that inheritance becomes much more composable. The type of an object then is not its class, but the set of mixins it extends.

<comment><USER8> Scala's implementation is definitely an interesting and a valuable one. I'm not debating that inheritance-based mixins are useful, they definitely are. It's just that they aren't necessarily inheritance-based, and there are many implementations of mixins that aren't, so defining it as such is at best somewhat limited and at worst misleading.

On a side note: scala's implementation, internally, is composition-based, since they compile forwarding methods to static methods into the class. They add an interface for those forwarding methods, so it can be used for polymorphism (which is what allows the fun things) but for their system to qualify as mixins, that interface is not necessary. For a very quick reference about this, you can look at [http://stackoverflow.com/questions/2557303/how- are-scala-tra...](http://stackoverflow.com/questions/2557303/how-are-scala- traits-compiled-into-java-bytecode)

<comment><USER28> The type enhancement means that traits could replace classes completely in scala, which is kind of exciting. The problem with traits is that state must be inlined even if implementations are not (so they are a mixture of mixins and small talk style traits). I'm well versed in how they are implemented in scalac.

What non-CL mixins are not inheritance based? Python?

<comment><USER8> Oh absolutely, the type enhancement is what makes it so interesting to use, but the point is that it's not necessary for it to be a mixin. It's a very nice extra.

I'm not sure about python, but Ruby completely inlines the mixin's code. It needs to do this because instance variables can be created anywhere, including from inside the mixin, but they still need to apply to the object of the actual class. This gives interesting cases for collisions, where 2 mixins create the same instance variable, but it's a decidedly non-inheritance way of doing it.

<comment><USER28> I use a mixin pattern extensively in C# that involves an interface to say the object provides a mixin object (C# also provides for partial classes, but its not good enough). Polymorphism is preserved via this method (though all clients delegate through MixX). Actually, I don't see private mixins (that don't at least effect the object's v-table) to be very interesting: why not just create and delegate to an object then?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> In this case I'd argue that the roles are a bit messy and Character has too much knowledge. Character should not know that physics objects can be updated, and certainly shouldn't be calling updatePhysics. You could end up with an updated Character interacting with a Character whose physics state hasn't been updated yet.

applyKnockback: Character -> Physics object -> Physics engine

updatePhysics: Physics engine -> Physics object -> Character new position (x, y)

updateCharacter: Character reacts to change

</comment><comment><USER30> By the way, I encourage everyone to try out their game, Awesomenauts. Think Super Smash Brothers meets Dota. It's a lot of fun to play!

</comment><comment><USER31> Couldn't agree more than this. I have also shared my 2 cents on Why composition is better than Inheritance for Java Programmers here [http://javarevisited.blogspot.sg/2013/06/why-favor- compositi...](http://javarevisited.blogspot.sg/2013/06/why-favor-composition- over-inheritance-java-oops-design.html)

</comment><comment><USER32> The burden of proof should fall onto the user of inheritance to justify his decision. Interfaces plug delegates is more tedious to implement, but greatly reduces the chances of an architecture turning into a complete train wreck.

I often wonder why declarative delagating is not a first class concern in programming languages.

</comment><comment><USER33> In my opinion the best arguments against inheritance were written by Richard Gabriel in his book Patterns of Software: [http://dreamsongs.net/Files/PatternsOfSoftware.pdf](http://dreamsongs.net/Files/PatternsOfSoftware.pdf)

</comment><comment><USER34> Sounds like [https://en.m.wikipedia.org/wiki/Triarchy_%28theory%29](https://en.m.wikipedia.org/wiki/Triarchy_%28theory%29)

</comment><comment><USER35> Why often and not always? Can you provide an exceptional case?

<comment><USER36> Exception hierarchies?

<comment><USER35> Thank you very much. I will do my homework.</comment></comment></comment>


TechStars London brings access to UK visa - <AUTHOR> http://brendangill.tumblr.com/post/45752718669/international-entrepreneurs-techstars-london-comes

<comment><USER2> It's a pity the UK immigration system as a whole isn't so forward looking. Our prime minister's recent drive to appease the right has meant a target to cut net migration to 5 figures by 2015. Result? Thousands of people graduating from UK universities no longer have the right to stay for any length of time. Skilled workers from outside the EU find it virtually impossible to move here.

This is a step in the right direction, but for every foreigner accepted into an accelerator like this there's thousands of skilled and willing people being kicked out and turned away.

<comment><USER3> We already have a high level of graduate unemployment/underemployment as is, I'm not sure more immigration is the answer.

<comment><USER2> Employment is completely field specific, but visa rules aren't. I don't know of anyone from my graduating class of mechanical engineers who's still unemployed 6 months after we graduated. The current system denys capable people with valuable skills the ability to seek employment in the UK. We have a shortage of engineers as it is.

</comment></comment></comment><comment><USER4> Great post, but I think that Startup Chile was the first accelerator program to guarantee a Visa, though whether that counts as a top-tier program is subject to debate. Whatever the case, it's great to see the UK leading the US here.

<comment><AUTHOR> Yeah, Startup Chile is a great program but I don't think it's in the same league as TechStars, YCom, 500 startups & Angelpad.

</comment></comment><comment><USER5> Interesting, I was actually looking for something like this late last year. Instead I've decided to leave the UK and join the totalsend.com team here in Cape Town which was a great move.</comment>


Gobot – Go framework for robotics, physical computing, internet of things - <AUTHOR> http://gobot.io/ <comment><USER2> Gobot also has sister libs in Ruby and Node! I have used the Ruby one a bit and it's a ton of fun. I've had a bear of a time with the bluetooth support under Ubuntu though. I guess I need to try Gobot with my Sphero ASAP.

Ron Evans (One of the gobot devs from the blog post linked in beliu's post) was also named a Ruby Hero a few days ago. He was tremendously inspiring in this podcast on teaching kids to program [1]. I dug it so much I wound up demoing a sphero and a "talking fruit keyboard" at a local career day a few months after I heard him.

[1] [http://rubyrogues.com/141-rr-teaching-kids-with-ron- evans](http://rubyrogues.com/141-rr-teaching-kids-with-ron-evans)

<comment><USER3> In case anyone is wondering, this is the sister library in Ruby [http://artoo.io/](http://artoo.io/)

I'm not sure but I think this is the nodejs one: [http://robotwebtools.org/](http://robotwebtools.org/)

<comment><USER4> I think the node one is

[http://cylonjs.com/](http://cylonjs.com/)

All are pretty great, and I'm looking forward to adding support for Mirobot ([http://mirobot.io](http://mirobot.io))

</comment></comment></comment><comment><USER5> Note that this does not run Go on the robot, it runs Go on a host computer and communicates with the robot with Firmata.

<comment><USER6> Yer still waiting for someone to allow me to use these frameworks without ball chaining them to another device in order to use them :(

<comment><USER7> Make a Raspberry Pi robot and run go on the Pi

[http://dave.cheney.net/tag/go-golang- raspberrypi](http://dave.cheney.net/tag/go-golang-raspberrypi)

</comment></comment></comment><comment><AUTHOR> Gobot looks really slick. Here's a link to our liveblog of their talk today at GopherCon. All the code examples for their demos (Game of Life using Spheros, AR Drone with LED light, AR Drone controlled by PS3 controller + EEG device around the pilot's head) were under 100 lines of Go code. Can't wait to play around with this.

[http://gophercon.sourcegraph.com/post/83843443678/gobot- go-p...](http://gophercon.sourcegraph.com/post/83843443678/gobot-go-powered- robots)

</comment><comment><USER8> Saw the live demo for this today at GopherCon; really impressive! The Go code was surprisingly simple and intuitive, yet low-level enough to have tight control.

<comment><USER9> I was there too. There were like 6 demos during the presentation--all of them were awesome! The first rule of presentations is to minimize demonstrations because things can go wrong, but all of there demos were amazing and went off without a hitch. I too thought Go was only a server-side language, but they showed it runs great on embedded devices.

<comment><USER10> This... exactly. Presentation was great. Presenters were really good. Gobot looks solid.

</comment></comment></comment><comment><USER11> Off-Topic

I want to get further into the robotics area but from a design/UX perspective. (Information dashboards, remote controlling interfaces, fleet management interfaces, visual programming interfaces etc)

If anyone has any projects they could use some design help for, fell free to hit me up.

My mail is in my profile.

<comment><USER12> off-off-topic... I could really use help with the software UI for my mobile testing robot -- Tapster (tapsterbot.com). I'll email you, but for anyone else reading... Tapster is an open source (hardware and software) Arduino + Node- powered deltabot for testing applications on smartphones and tablets. It's totally awesome, but I need all kinds of help!

</comment></comment><comment><USER13> Why use Go for embedded systems in robots? It doesn't make any sense. Go relies _strongly_ on the existence of a heap, and doesn't have strong real- time properties.

<comment><USER8> Not as much as you'd think: Go uses the stack. And evidently the soft real- time support is good enough to fly drones and control robots. I saw it today. All of their demos at GopherCon, including the face recognition one, had Sleep calls in it because otherwise it would operate too fast for comprehension and would make the robots/drones hard to control.

<comment><USER13> >Go uses the stack

Only insofar as all programming languages with stack frames tend to use the stack. Many of Go's core language features require the presence of a heap.

> And evidently the soft real-time support is good enough to fly drones and > control robots.

I could probably control a drone with Javascript. It doesn't mean that I should, nor that I can guarantee that it will work all the time.

>had Sleep calls in it because otherwise it would operate too fast for comprehension and would make the robots/drones hard to control.

This means nothing. Just because the language happens to be more than fast enough for a certain thing doesn't mean it will be more than fast enough for all things.

</comment></comment></comment><comment><USER14> Looks great-- where's the Raspberry Pi support? Or am I missing something?

</comment><comment><USER15> Really cool project!

</comment><comment><USER16> Awesome robotics framework, gotta try it out!</comment>


Justin Timberlake To Take Ownership Stake in MySpace - <AUTHOR> http://mashable.com/2011/06/29/justin-timberlake-myspace-ownership/ <comment><USER2> now that is very interesting. Is there $35 million worth of value left in myspace? Probably. With Timberlake involved? Almost certainly. Good luck to them.</comment>


Flash Mob Riots: Crime in the Age of Twitter - <AUTHOR> http://associatesmind.com/2011/08/09/flash-mob-riots-crime-in-the-age-of-twitter/

<comment><USER2> Twitter's press guys finally found a way to spin the london rights to include them! It must have sucked being the future of communication and where the revolution will be tweeted etc, watching RIM get all the stories.</comment>


A federal court has denied a pre-trial motion to dismiss a GPL enforcement case - <AUTHOR> https://qz.com/981029/a-federal-court-has-ruled-that-an-open-source-license-is-an-enforceable-contract/ <comment><USER2> This happened a few weeks ago. But it's just a ruling on a preliminary injunction motion.

That is, it's not even a final decision of a court.

So while interesting, it's incredibly early in the process. The same court could issue a ruling going the exact opposite way after trial.

As someone else wrote, basically a court rule that a plaintiff alleged enough facts that, if those facts were true, would give rise to an enforceable contract.

IE they held that someone wrote enough crap down that if the crap is true the other guy may have a problem.

They didn't actually determine whether any of the crap is true or not.

(In a motion to dismiss, the plaintiff's allegations are all taken as true. This is essentially a motion that says "even if everything the plaintiff says is right, i should still win". If you look, this is why the court specifically mentions a bunch of the arguments the defendant makes would be more appropriate for summary judgement)

<comment><USER3> > This happened a few weeks ago. But it's just a ruling on a preliminary > injunction motion.

Is "preliminary injunction" the right terminology here? It sounds like it was a motion for dismissal.

Anyway, it's appalling how often the press confuses pre-trial motions like this with substantive rulings on the issues of the case.

...and it is also, sadly, no surprise that they also think that this sets precedent. Why is it so hard for them to understand the difference between trial courts and appellate courts and which set precedent?

<comment><USER4> I'll be cynical: some call it "having an axe to grind". Why do research if you can just post something that seems to align with your cause and makes you happy?

 _In all that we do at Quartz, we embrace openness: open source code, an open newsroom, and open access to the data behind our journalism._

<comment><USER3> > "Not so," [yeah, I'm sure this is a literal quote from a court document] > said Judge Jacqueline Scott Corley in her order on the motion on April 25.

That is in fact a literal quote from the court document:

        Defendant contends that Plaintiff's reliance on
        the unsigned GNU GPL fails to plausibly demonstrate
        mutual assent, that is, the existence of a contract.
        Not so. The GNU GPL, which is attached to the
        complaint, provides that the Ghostscript user agrees
        to its terms if the user does not obtain a
        commercial license. Plaintiff alleges that Defendant
        used Ghostscript, did not obtain a commercial
        license, and represented publicly that its use of
        Ghostscript was licensed under the GNL GPU. These
        allegations sufficiently plead the existence of a
        contract. See, e.g., MedioStream, Inc. v. Microsoft
        Corp., 749 F. Supp. 2d 507, 519 (E.D. Tex. 2010)
        (concluding that the software owner had adequately
        pled a claim for breach of a shrink-wrap license).

See page 4, line 17 here: [https://cases.justia.com/federal/district- courts/california/...](https://cases.justia.com/federal/district- courts/california/candce/3:2016cv06982/305835/32/0.pdf)

<comment><USER4> OK, I stand corrected. I'm removing the rant.

</comment></comment></comment></comment></comment><comment><USER5> _To use Ghostscript for free, Hancom would have to adhere to its open-source license, the GNU General Public License (GPL). The GNU GPL requires that when you use GPL-licensed software to make some other software, the resulting software also has to be open-sourced with the same license if it's released to the public. That means Hancom would have to open-source its entire suite of apps._

 _Alternatively, Hancom could pay Artifex a licensing fee. Artifex allows developers of commercial or otherwise closed-source software to forego the strict open-source terms of the GNU GPL if they're willing to pay for it._

This obligation has been termed "reciprocity," and it lies at the heart of many open source business models.

[http://www.rosenlaw.com/pdf- files/Rosen_Ch06.pdf](http://www.rosenlaw.com/pdf-files/Rosen_Ch06.pdf)

The more important issue here is reciprocity, not whether an open source license should be considered to be a contract.

AFAIK, the reciprocity provision of any version of the GPL hasn't been tested in any meaningful way within the US. In particular, the specific use cases that trigger reciprocity remain cloudy at best in my mind.

Some companies claim that merely linking to a GPLed library is sufficient to trigger reciprocity. FSF published the LGPL specifically to address this point.

So I believe a ruling on reciprocity would be ground breaking.

<comment><USER6> Question: Is that what Stallman intended to accomplish with the GPL? Pay a fee for GPL source code and bypass the GPL? (I apologize for my ignorance here.)

It seems like "reciprocity" has an even worse outcome than BSD source code. The origin of the source code can be completely hidden from the user.

Do users deserve to know at least that the original source code was _freely available_? What happens when users discovers that they are paying for something that others are getting for free? Do they care?

Is this a case of taking something that was free (but valuable), i.e., the original GPL source code, and concealing it as a closed source work in order to generate revenue/profit for some specific person or entity?

Stupid question: If someone fixes or adds something valuable to GPL source code and wants to charge for it, then why not just charge for the patch or the additional code?

(Assume that patches or additional source code files are distributed by themselves _without the original GPL source code_ and that they do not contain any functional portion of the original GPL source code. Assume further that they do not use "interfaces" designed by the GPL source code author. Finally, assume that the end user can compile their own software and no binaries are distributed.)

<comment><USER7> > If someone fixes or adds something valuable to GPL source code and wants to > charge for it, then why not just charge for the patch or the additional > code?

You can legally do this, but it will not be easy. You cannot distribute a binary in this way, if you do your patch becomes GPL so the first person who buys your patch can legally give it to everyone else. That means you have to sell the source code to your patch and your customers have to build the binary themselves. You need to ensure that your customers understand that they cannot distribute any binaries they make. (they probably can distribute it within their company but they need to have some process to ensure that their employees know they cannot distribute this)

If anyone is thinking about this, make sure all sales include your lawyer: you will need to ensure that your customer understands all the subtleties otherwise the courts might decide your patch is GPL.

<comment><USER8> As other people already said, intellectual property laws restrict not only the work itself, but also derivative works.

A patch is a derivative work, no matter how you try to dodge that part of the law. So it would still be violation of copyright.

<comment><USER6> To be clear, the silly question I posed was not directed at avoiding copyright violations. What I ask is whether anyone is ever curious about the value of the derivative work versus the original work.

For example, the original work might be very valuable, a significant work. It could be the collective work of many authors. But it has been made available for _free_. The derivative work, maybe patches or some additional source code by a single author, is also valuable but on its own much less so.

Then the large original work is packaged together with the patches and additonal source code as a "derivative work". It is commercially licensed to an end user who sees the value _as a whole_ , most of it coming from the original work, which of course was available for free.

Depending on whether attribution is given, the user may have no idea that the core of the product was open source and available for free.

More importantly, there appears to be no assessment of the relative "value" of the free portion versus the closed-source commercial portion of the product.

</comment></comment></comment></comment></comment><comment><USER9> "Corley denied the motion, and in doing so, set the precedent that licenses like the GNU GPL can be treated like legal contracts, and developers can legitimately sue when those contracts are breached."

The GNU GPL was written on the basis that if someone does not accept its terms, then that without any other license from the copyright holder, redistribution puts that person in violation of copyright law.

Suing for damages on the basis of a breach of copyright law clearly does not require any contract.

So this is more about a technicality of the legal process in this particular case, rather than anything about whether copyleft is legally enforceable or not in general.

Specifically, because the motion denial was based on the defendant's own admission being deemed to be the agreement of a contract, this says nothing about the general enforceability of the GPL (future defendants could simply avoid making such an admission).

Further, since the ruling was in response to a specific motion, it only concerns the claims made in that motion: about whether a contract exists in this particular case. It says nothing about the "copyright violation if you don't accept the license" mechanism of copyleft.

Finally, the article does not provide any evidence that there has been any ruling that determined that the GPL is an _enforceable_ legal contract, contrary to its title. The ruling as quoted just says that the defendant, by its own admission, did accept to enter in to the GPL-defined contract.

<comment><USER8> But if for some reason some court rules the GPL invalid, doesn't it mean that the companies using the GPL'ed software are violating copyright?

Because the GPL license is the only thing granting them the rights to use that intellectual property, right?

<comment><USER9> > ...doesn't it mean that the companies using the GPL'ed software are > violating copyright?

It may be a technical violation. This wouldn't in itself make any difference to anything, however. It would only matter if a court would then award damages to copyright holders as a consequence of the violation. A violation in civil law doesn't mean anything in practice except when damages are awarded (and only changes behaviour when damages _could_ be awarded).

Damages are awarded based on harm done. I think a copyright holder would struggle to show that any harm was done _by the defendant_ , especially as the defendant would have been acting in good faith. Of course this depends on the details of the reason the court ruled the GPL invalid, so it's not really possible to speculate on your hypothetical further.

<comment><USER10> But copyright is different; See [0] under Statutory Damages.

EFF / Github should probable set up a "register copyright for this release" to make it easier for OS developers to use this feature of copyright law.

</comment></comment></comment></comment><comment><USER11> A friend of mine, who is a software engineer turned IP lawyer, made a good point about the GPL - the reason it "has never been challenged in court" isn't about uncertainty, but about certainty. The GPL is based on the most simple, bedrock copyright law. Despite being a clever hack, there's nothing legally exotic about it.

Any judge in the country or anywhere else would laugh a GPL challenge right out of court. Any any IP lawyer reading it would tell their client that that's what's going to happen if they try to challenge it. That's why it's never been fully tested in court... no need.

<comment><USER12> Ah, if only.

To the first point: the GPL is not used nearly as much as it should be. Thus there's still a strong selection bias on court cases in general being about the GPL, since the GPL is not selected very often. (And there's a reason it is avoided: legal counsel to large companies frequently describe the GPL as "untested." This happens still today, which is frankly ridiculous in the light of all that the Software Freedom Law Center, FSF, etc. have done)

To the second point: any court proceeding introduces a huge amount of uncertainty. Costs are up-front, payback may come in a decade or more after all routes of appeal have been exhausted. Judgments are frequently overturned on technicalities; even if the technicalities are flawless the GPL is not unassailable.

On a personal note, I am unequivocally in favor of using Free Software further and wider than it has been used. In every potential conflict of interest, I think there is much to be said for attempting to settle with a "GPL violator" using amicable means, even if it takes a long time. I view "GPL violations" as free advertising -- don't be shy about publishing the proceedings, though doing it with some taste may help the party come into compliance, their actions should speak for themselves!

People use GPL software, extensively.

Any use of GPL software is a compliment to the software authors.

Any contribution back to the software will improve it for everyone.

etc.

<comment><USER13> Big companies don't avoid GPL because it's "untested". Big companies avoid GPL because it's actually quite dangerous for them to use. GPLv2 only so far as if they accidentally taint their proprietary code with it, then they need to open up their code (which is bad enough). But GPLv3 is really fucking scary. As it was once put to me, if a single GPLv3 binary accidentally makes it onto the OS image for iOS, Apple would then legally be required to release the master signing key to the whole world, completely destroying the whole security model of iOS and screwing everybody (not just Apple but also Apple's users who rely on that security). Plus the patent clause in GPLv3 is also nasty.

<comment><USER12> Can you point to actual statements by any company on "why we avoid the GPL?"

Here is a great example of Google reversing course on the AGPL (when they reversed their decision to ban AGPL code from Google Code in Sep 2010):

[https://www.theregister.co.uk/2011/03/31/google_on_open_sour...](https://www.theregister.co.uk/2011/03/31/google_on_open_source_licenses/)

Apple also _still_ ships GPL code in macOS Sierra 10.12:

[http://meta.ath0.com/2012/02/05/apples-great-gpl- purge/](http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/)

People use GPL software, extensively.

Any use of GPL software is a compliment to the software authors.

Any contribution back to the software will improve it for everyone. Would it really be so hard for Apple to maintain a GPLv2 fork of bash that backported the security fixes, a la RedHat?

<comment><USER13> I'm not aware of public statements, I don't know why any big company would actually go on record as saying that. But what I described above is paraphrasing what I personally was told by a lawyer who worked for a big company.

Also, your own link shows that over time Apple has been shipping fewer and fewer GPL-licensed packages, and explicitly makes the case that Apple is trying to get rid of GPL-licensed software.

> _People use GPL software, extensively._

People use all sorts of software. I have no idea why this statement is relevant to big companies shipping GPL software.

> _Any use of GPL software is a compliment to the software authors._

I'm even more confused by the inclusion of this statement.

</comment></comment></comment></comment></comment><comment><USER14> > _That happened when Hancom issued a motion to dismiss the case on the > grounds that the company didn't sign anything, so the license wasn't a real > contract._

... so they admitted to the court that they willfully used the software _without_ a license to do so?

<comment><USER15> This is what happens when you hire short-sighted attorneys with an unreasonable expectation of success.

What's funny is that Hancom is essentially arguing that _shrink-wrap licenses (contracts) are unenforceable_. Ghostscript was open sourced under the GNU GPL which states, in shrink-wrap fashion, that use of the software without an explicit commercial license binds the user to the GNU GPL. Integrated the software into their own closed-source software and distributing said closed- source software is unquestionable use.

At the same time, you can guarantee that Hancom would fully enforce their own shrink-wrap licenses - Terms of Use, Terms of Service, etc. - on others.

<comment><USER9> There is an enormous legal difference between shinkwrap licenses that _limit_ your terms, and a license that _grants you additional permissions_. Your typical "EULA" is the former type. Copyleft licenses like the GNU GPL are the latter type.

A typical "EULA" attempts to reduce your rights, without any further consideration from you (you'll have already paid for it, etc). If you disagree, the authors like to claim that you are bound by their more restrictive terms anyway. That is what is legally dubious.

A copyleft license does the opposite: the software comes with an offer to grant you additional permissions should you choose to accept its terms. You have the option to decline, and nobody is claiming that your rights are in any way further restricted if you choose to decline.

Put another way, you are free to use GPL software without accepting the terms of the license. But if you don't accept the terms, then you violate copyright law every time you make copies of it.

<comment><USER16> There is no such thing as an EULA attempting to limit your terms. Without a licence, you have no right at all.

<comment><USER4> > Without a licence, you have no right at all.

On what grounds do you have no right to use a copy of software you bought without obtaining an additional license from the vendor?

As for copying it's copyright, obviously, but I never understood what's the matter with merely using. IANAL but AFAIK in some EU countries it is recognized that there is no legal basis for EULAs and they officially are void, unless signed as a contract _prior_ to the purchase, of course.

<comment><USER17> > unless signed as a contract prior to the purchase, of course.

Not quite. There is no need to sign anything, what matters is if the EULA was included in the sale contract (so, the buyer was aware that the willingness of the seller to sell you the product depended on the buyer accepting those additional terms as part of the contract). On the other hand, if you do indeed sign an additional contract afterwards on your free will that limits your rights, that might very well be enforcable. But the point is that there is no legal necessity to sign such a contract in order to use the software that you have bought.

<comment><USER4> > There is no need to sign anything, what matters is if the EULA was included > in the sale contract (so, the buyer was aware that the willingness of the > seller to sell you the product depended on the buyer accepting those > additional terms as part of the contract).

Yes, it doesn't have to be _literally_ signed, but it needs to be an agreement made at the time of purchase. If I agree to buy Windows under the condition that I won't use it for the development of nuclear weapons, so be it.

But it's still not clear why I would need Microsoft's license just to use a copy of Windows I have already bought, sometimes even as part of a computer, which is what parent seemed to claim.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> This was a ruling that the contract between the plaintiff and defendant existed, not on the validity of the contract (which is the GNU GPL license).

Defendant (Hancom) was trying to say that because they didn't sign anything they didn't have a contract.

But Hancom "represented publicly that its use of Ghostscript was licensed under the GNL GPU"

Therefore, the Judge ruled that in their own words they publicly acknowledged the contract.

<comment><USER19> It's a very narrow ruling, conditioned on the fact that the defendant, Hancom, publicly acknowledged they were using Ghostscript under GPL. It does not say much, if anything, but IANAL, about a defendant who would not have acknowledged this, which seems like the more interesting question.

Common law judges are very prudent in their ruling.

</comment></comment><comment><USER20> This is great - love or hate the GPL, it brings something unique to the table that no other license does and developers should have the ability to license their software under the terms that fits their motivation for developing it in the first place the best - the GPL does exactly that for many.

</comment><comment><USER21> One thing I often wonder is how a company providing such open source software can find out (and proof) if someone is using it in a closed-source project. All I can think of is "guessing" based on behavior of the downstream tool.

Also, the article doesn't say much about how that lawsuit came to be. Did Artifex approach Hancom beforehand to notify them about the license infringement or just directly sue? I guess in this particular case, Hancom knew what they were doing, but I can imagine some (smaller) companies not being fully aware of open source license specifics and unknowingly running into a lawsuit.

<comment><USER22> >I can imagine some (smaller) companies not being fully aware of open source license specifics and unknowingly running into a lawsuit

This is not a real problem until there are licensing trolls, where their sole purpose is to make money off of breaches.

If a company receives a lawsuit, they can claim ignorance and start to comply with the contract. This would change it into a minor breach of contract, where they would only be liable for actual damages caused. Actual damages would either be nothing or fairly impossible to prove, so the lawsuit would likely be dropped.

<comment><USER21> > If a company receives a lawsuit, they can claim ignorance and start to > comply with the contract.

Are you sure claiming ignorance would make a difference? I tried to google it and found the Wikipedia article on "Ignorantia juris non excusat"[1], which claims that in most countries, not knowing a certain law provides no protection whatsoever.

[https://en.wikipedia.org/wiki/Ignorantia_juris_non_excusat](https://en.wikipedia.org/wiki/Ignorantia_juris_non_excusat)

<comment><USER23> "Usually, whether a breach is material or minor is determined on a case by case basis, with the court using six different guidelines to make its determination. The six guidelines are

1) the extent to which the breaching party has already performed,

2) whether the breach was intentional, negligent or the result of an innocent mistake,

3) how certain it is that the breaching party will perform the rest of the contract,

4) how much of the benefit of the contract the non-breaching party has gotten despite the breach,

5) the extent to which the innocent party can be compensated and,

6) how difficult it would be on the breaching party if the court were to decide that the breach was material and that the innocent party was under no obligation to perform his side of the bargain. "[1]

See point 2. My understanding is that ignorance of the law is basically never an excuse, but ignorance of the facts, for contracts, could be[2].

For example, company X could argue they are ignorant of the fact that software Z is intellectual property of company Y, distributed under GPL. If they stop breaching once informed of that fact they can argue it was an innocent mistake.

But in this case Hancom was advertising that it was using the code under the GPL, so, they certainly can't claim ignorance.

[1][https://nationalparalegal.edu/public_documents/courseware_as...](https://nationalparalegal.edu/public_documents/courseware_asp_files/contracts/PerformanceAndBreach/MaterialVsMinorBreach.asp)

[2][https://en.wikipedia.org/wiki/Mistake_(contract_law)](https://en.wikipedia.org/wiki/Mistake_\(contract_law\))

<comment><USER24> Pretty much all GPL'd code comes with a GPL license header, so you'd need _someone_ to strip that header off.

It would be hard to hide the identity of that someone, thanks to Git.

Once that someone takes the stand, the truth becomes hard to conceal because presumably company X doesn't pay them enough to lie under oath.

</comment></comment></comment></comment></comment><comment><USER25> The GPL has been upheld many times previously, e.g. in BusyBox enforcing its copyright.

[https://en.wikipedia.org/wiki/BusyBox#GPL_lawsuits](https://en.wikipedia.org/wiki/BusyBox#GPL_lawsuits)

In one enforcement, the defendant defaulted and the SFLC ended up with a pile of violating televisions!

[http://www.groklaw.net/article.php?story=20100803132055210](http://www.groklaw.net/article.php?story=20100803132055210)

The enforceability of the GPL is in no way news. That anyone would continue to try to violate it is the real WTF.

</comment><comment><USER15> > Of course, whether Artifex will actually win the case it's now allowed to > pursue is another question altogether.

It's fairly clear that they will win the case in one fashion or another. I am predicting that the case will quickly be settled out of court for a lump sum plus a running licensing fee. You have a public admission from the defendant that they integrated the plaintiff's Ghostscript software into their own without either: 1) making the resulting Hancom office suite open source, or 2) paying Artifex a licensing fee for the software.

The case against Hancom was solid under copyright infringement, and now has the added sting of breach of contract.

</comment><comment><USER26> Excellent news.

<comment><USER27> Yeah few more contributions to GPL projects from companies or/and removing GPL code base from some products using GPL without contibuting back.

<comment><USER28> Fewer contributions? Or fewer companies abusing open-sourced code?

<comment> yoz-y Most probably both. However this is probably for the best.

<comment><USER28> Dura lex, sed lex (c), and there's no way around it.

</comment></comment></comment></comment></comment><comment><USER29> _That means Hancom would have to open-source its entire suite of apps._

Ask HN: What if the vendor had structured their product in a way that GhostScript is its own stand-alone app. Would they still be obligated to release their entire code, or just the portion that uses GhostScript?

<comment><USER30> As long as it's not _linked_ to their binaries, invoking it separately is fine.

I believe they might need to allow for others to download the source of Ghostscript whether modified or not, but that part isn't hard. :)

</comment></comment><comment><USER31> Here is a link to the actual opinion if anyone else is interested.

[https://scholar.google.com/scholar_case?case=377952933561079...](https://scholar.google.com/scholar_case?case=37795293356107925)

</comment><comment><USER32> Actually, a more accurate statement is thst a federal judge has ruled that a plaintiff in a case has alleged the existence of circumstances in which the GPL would be an enforceable legal contract.

<comment><USER18> Basically: If you admit to having a contract, then you have a contract.

</comment></comment><comment><USER33> while an important step, the last line of the article makes it clear it is still pretty early in this process.

</comment><comment><USER34> In my opinion, software equivalent in functionality to Ghostscript should be written using a BSD or similar license. Is there anyone willing to sponsor it?

<comment><USER4> Maybe ask Hancom :p

</comment></comment><comment><USER35> moral of the story is, know you licences. Adhere to the license terms. Seek out projects with more permissive licenses if you plan to do closed source.

It is simple to work around licence issues with your project. You just have to put in the work. Know that your design may have to factor in extra time because you can't use lib XYZ because you have to write your own library to do the same thing. If using lib XYZ will save a bunch of time, then know that you will have to adhere to lib XYZ license. Maybe writing a wrapper application that you opensource, and your closed source application interfaces with might be a design consideration.

In the end, it's your project, your call. Just know when you make a decision you weigh the pro's and con's of going forth with that decision.

</comment><comment><USER36> What happens if they claim they downloaded it from somewhere else that didn't include the license.txt file? There is no proof they ever were even notified of the license. (this is why we usually have people sign contracts)

<comment><USER37> Adobe is about 34 years old, so the copyright on any program that interacts with an Adobe file format (e.g. postscript, pdf) cannot have expired yet (in the absence of time travel). So if the source code did not come with a license, it is _their_ responsibility to obtain one, or they can't use it.

</comment></comment><comment><USER38> This article seems to be declaring victory in war, when really only a minor battle in the war has been won.

<comment><USER18> No, the article is pretty clear that this isn't about the terms of the GNU GPL itself, just about whether there was a contract in _this particular case_.

</comment></comment><comment><USER39> I'm not a big fan of the GPL personally, but this is great!

</comment><comment><USER40> Doesn't MySQL distribute in a similar dual-licensed fashion?

</comment><comment><USER41> I wonder if this applies to non copy left licenses as well.

<comment><USER42> Probably. In the previous case they mention, the license was the Artistic License, which isn't copyleft, and it was considered infringement.

</comment></comment><comment><USER43> The article somewhat overstates the significance of this case in terms of precedential value.

On a procedural level, understand that this is a district court opinion and is not binding on any other court. Of course, if other courts find the arguments persuasive, they can adopt the reasoning. But no court has to adopt the reasoning in this opinion.

On a substantive level, it's important to look at the arguments the court is addressing and how they are addressed:

1) Did the plaintiff adequately allege a breach of contract claim?

We're at the motion to dismiss phase here and the court is only looking at plaintiff's complaint and accepting all of the allegations as true.

There are essentially only 2 arguments the court addresses: A) Was there a contract here at all?; and B) Did the plaintiff adequately allege a recognizable harm?

Understand that in a complaint for breach of contract, a plaintiff has to allege certain things: (i) the existence of a contract; (ii) plaintiff performed or was excused from performance; (iii) defendant's breach; (iv) damages. So, the court is addressing (i) and (iv), which I refer to as (A) and (B) above.

As to (A), the argument the defendant appears to have made is that an open source license is not enforceable because a lack of "mutual assent." In other words, like a EULA or shrink-wrap license, some argue that an by using software subject open source license doesn't demonstrate that you agreed to the terms of that license.

The court, without any real analysis, says that by alleging the existence of an open source license and using the source code, that is sufficient to allege the existence of a contract. The court cites as precedent that alleging the existence of a shrink-wrap license has been held as sufficient to allege the existence of a contract.

But the key word here is "allege." As the case proceeds, the defendant is free to develop evidence to show that there was no agreement between the parties as to the terms of a license. So, very little definitive was actually decided at this stage. All that was decided is that alleging that an open source license existed is not legally deficient per se to allege the existence of a contract.

As to (B), defendant apparently argued that plaintiff suffered no recognizable harm from defendant's actions. The court held that defendant deprived plaintiff of commercial license fees.

In addition, and more important for the audience here, the court held that there is a recognizable harm based on defendant's failure to comply with the open source requirements of the GPL license. Basically, the court says that there are recognizable benefits (including economic benefits) that come from the creation and distribution of public source code, wholly apart from license fees.

This is key - if the plaintiff did not have a paid commercial licensing program, it could STILL sue for breach of contract because of this second type of harm.

That being said, none of this argument is new. There is established precedent on this point.

2) Is the breach of contract claim preempted?

Copyright law in the United States is federal law. Breach of contract is state law. A plaintiff cannot use a state law claim to enforce rights duplicative of those protected by federal copyright law.

So, what the court is looking at here, is whether there is some extra right that the breach of contract claim addresses that is not provided under copyright law.

In other words, if the only thing that the breach of contract claim was addressing the right to publish or create derivative works, then it would be duplicative of the copyright claim. And, therefore, it would be preempted.

Here, the court held that there are two rights that the breach of contract claim addresses that are different from what copyright law protects: (A) the requirement to open source; and (B) compensation for "extraterritorial" infringement.

The real key here is (A), not (B). With respect to (A), the court here is saying that the GNU GPL's copyleft provisions that defendant allegedly breached are an extra right that is being enforced through the breach of contract claim that are not protected under copyright law. Therefore, the contract claim is not preempted.

(B) is a bit less significant for broader application. What (B) is saying is that because the plaintiff is suing for defendant's infringement outside the U.S. ("extraterritorial" infringement), and federal copyright law doesn't necessarily address such infringement, that's an "extra element" of the breach of contract claim. I say this is less significant because it wouldn't apply to a defendant who didn't infringe outside the United States. So, if you were the plaintiff here and the defendant was in California and only distributed the software in the U.S., argument (B) wouldn't apply.

I hope this clarifies what is/is not significant about the opinion here.

</comment><comment><USER44> "GNL GPU", must be Nvidia's new line of graphics cards.

</comment><comment><USER45> This is why if someone were the (usually) imaginary "Free Software zealot" that would like to prevent a private business from profiting off public work, it would be necessary for software not only to be under a Free license, but for the copyright assignment to be held by someone that agrees with said Free Software "zealot".

<comment><USER45> Or to put it another way: if you are contributing to a Free Software project and the copyright is held by some other entity to who you have duly assigned rights, then you may find that they decided to sell the right to use some of your contributions. So, be careful who you turn your copyright assignment over to.

</comment></comment><comment><USER46> _That happened when Hancom issued a motion to dismiss the case on the grounds that the company didn't sign anything, so the license wasn't a real contract._

Hancom's CEO is a thief.

</comment><comment><USER47> Congratulations to Stallman. After all these years the GPL has been tested in court. The man must be drunk with joy... Three cheers for the Mr. Stallman and his gcc (joining in on his celebrations)

</comment><comment> brian-armstrong The GPL has such strong terms, I think there is good reason to avoid ever reading any GPL codebase. Tainting yourself may imperil any code you write for the rest of your lifetime. And to that end, I think github should place a large warning on any GPL repo before letting you see it, as well as delisting them from search results (or at least hiding the contents)</comment>


Runaway complexity in Big Data... and a plan to stop it - <AUTHOR> http://www.slideshare.net/nathanmarz/runaway-complexity-in-big-data-and-a-plan-to-stop-it <comment><USER2> We invented RDMS databases to store large amounts of important data safely on extremely constrained storage hardware (kilobytes were expensive in the 1970s) where you could not economically store redundant copies due to astronomical cost.

Append only immutable DBs are inherently better just because they essentially add a 4th dimension to your data (all history, all data, all the time), and hook up to the fact that Von Neuman machines love splitting things up into constrained sub-streams/problems and crunching through the entire data set in memory across clusters using discrete memory frames/units of work (think Google search index/GPU framebuffers/Integer arithmetic).

Storage is now unlimited and random seeks are very expensive. The more you serialize your processing and split them into in memory units that utilize cache locality - the faster you'll perform. You'll turn performance problems into throughput problems - all you have to do is to keep the data flowing.

RDMS databases are dead for the same reason I don't manage my YouTube bandwith use or bother managing files or bother managing RAM - I have cable now with terabyte hard disks and 32-64 GBs of RAM.

The future is immutable with periodic/continuous historical stream compaction (pre-computation) with queries running across hundreds of clusters and reducing all searches to essentially linear map-reduce (sometimes with b-trees/other speed ups) + a real time dumb/inaccurate stream layer.

1 machine cannot store the Internet - a million machines can. 1 machine cannot process the Internet - but a million machines operating on one 64GB slice of it located in RAM and operating with cache friendly memory-local discrete operations can run through the Internet millions of times a second.

<comment><USER3> Just a few facts that I have to deal with:

1) I can't afford a million machines or hundereds of clusters or keeping petabytes of data around in a way that doesn't make the data completely useless. Yes mutable state causes complexity, but I can't afford to rid myself of that problem by using brute force.

2) Performance is not replaceable by throughput if you have users waiting for answers on questions they just dreamt up a second ago and you have new data coming in all the time.

3) Cache locality and immutability don't go well together. Many indexes will always have to be updated, not just replaced wholesale with an entirely new version of the index.

<comment><USER4> 1) Even with hard drive prices inflated today, we're at over 9GB/$1 for storage. That means for $1 you can store 1.25 _billion_ 64-bit integers. From that perspective, there is very little data (at least in terms of traditional RDBMS data) that is actually cost effective to throw out. To the extent that you do need to throw it out, you can wait until all transactions involving the data have long since completed.

2) I think you misunderstood what was meant here. His point was that your limiting factor really becomes throughput if you have the right architecture.

3) Indexes and cache locality also tend not to play well together. ;-)

</comment></comment></comment><comment><USER5> "Conflating the storage of data with how it is queried" is a misinformed criticism of the relational model. Codd's Relational Algebra (Turing Award material) was in large part a move towards data independence, relaxing what was previously a tight coupling of storage format and application access patterns. Take a look at Rules 8 and 9, or just read the original paper: <http://en.wikipedia.org/wiki/Codds_12_rules>

> "Activities of users at terminals and most application programs should > remain unaffected when the internal representation of data is changed and > even when some aspects of the external representation are changed." > <http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf>

It's not clear from the slides how RDBMSs manage to conflate these two concerns in practice.

It's also unclear to me how the "Lambda Architecture" differs from what we've been calling [soft real-time] materialized view maintenance for decades.

<comment><USER6> It's not a criticism of the relational model. It's a criticism of the relational database as they exist in the world. The normalization vs. denormalization slides explain how these concerns are conflated. The fact that you have to denormalize your schema to optimize queries clearly shows that the two concerns are deeply complected.

<comment><USER7> Your ideas will work very well for small data, big storage. eg daily stock price histories

They will not always work for big data, which often means "max out our storage with crap, don't worry disk is cheap" eg web metrics

When a decision maker goes "don't worry disk is unlimited", the resulting application is prone to maxing out storage.

Whenever your application maxes out your storage, you have no space for previous versions of the data.

<comment><USER8> You realize he works at Twitter, right? And that he's responsible for Storm, and Cascalog?

I'm not going to say anything better than it was said in the slides / book draft, so I'll just encourage you to take these techniques seriously... they're born out of necessity, not because they sound like fun, and real people are using them to solve problems that are hell to solve any other way.

That said, these are not problems that everyone has. If you're not nodding you're head along with the mutability / sharding / whatever complaints at the beginning of the deck, you can probably still get by with a more traditional architecture.

(Also, rereading... I should probably note that not everything needs to be kept forever; only the source data, since the views can be recomputed from them at any time. That makes things a bit cheaper.)

<comment><USER7> > problems that are _hell_ to solve any other way.

'Bigness' of data != data size

'Bigness' of data == data size / budget

Twitter isn't a typical company. I assume they have both a budget and competent management that will let them get away with something like the Lambda architecture.

I reckon it's a lot harder to scale to even a _terabyte_ under the constraints of a grubby setting like a datawarehouse for some instrument monitoring company.

Those guys will allow _at best_ MS SQL for storage, and won't mind putting their developers through _hell_.

</comment></comment></comment></comment></comment><comment><USER9> I'm interested enough in the idea to pick up the (partially-completed) book, but I wonder if this isn't far too complex of a solution for 95% of cases. By the time that your system is in the 5% of cases, you're looking at a massive rearchitecting effort.

Of course, to be fair, you're probably already looking at a rearchitecting effort at this point!

However, looking at the architecture diagram, much of the complexity could be hidden behind the scenes with a devoted toolset built on top of Postgres, rather than trying to cobble together Kafka, Thrift, Hadoop, and Storm. Sometimes, one big tool beats a lot of small tools.

For that matter, I wonder if a series of Postgres-XC (or Storm) servers couldn't do the same thing without learning a series of complex tools.

Step 1: Everything goes through a stored procedure. Deletes, updates, and creates are code generated through a DSL. Migrations would be a pain under this system, but mitigated by the fact that the complexity is being handled by the tool.

This stored procedure then writes to the database of record and then sends a series of updates to, essentially a system of real-time materialized views that serve the same purpose as the standard NoSQL schema.

The lambda architecture purposes would still be fulfilled with lower data-side complexity. After I read through Big Data I'll revisit this with a more nuanced view, but I wonder if hadoop and nosql really give you anything.

</comment><comment><USER10> I really like this. Has some overlap with Command-Query Responsibility Segregation, which I have found very useful: <http://www.udidahan.com/2009/12/09/clarified-cqrs/>

<comment><USER11> There was an interesting production-grade event store released recently which fits the described use-case: <http://geteventstore.com>

Basically, you store all of the data as events (event sourcing) and create separate query views (projections) which are populated from event streams.

</comment></comment><comment><USER12> Interestingly I am just building a complete analytics setup for my ecommerce site, since Google Analytics doesn't give me everything I want to track. I looked at different things like statsd and redis and whatnot but realized that my data is not actually big. I will just put everything in Postgres and will be able to do that on cheap hardware even when I grow tenfold. Since revenue per pageview is high as in multiple cents there will never be an unsolvable performance issue.

tldr - the hand me down from the 90s can be good enough if you are not big yet

</comment><comment><USER13> Interestingly the chart at the end suggests implementations for everything except the raw data, but generating batch views from an arbitrary store and keeping your raw data reliably are hard problems. The charts motivate dumping this stuff in Hadoop (or some distributed file system), but any reliable store would do. (@nathanmarz: would love recommendations)

<comment><USER6> A distributed filesystem, such as HDFS or MapR, is ideal for the master dataset.

</comment></comment><comment><USER14> This is a reasonable architecture, but it introduces complexity of its own - you have to implement all your view creation logic in two places, which should go against every programmer's instincts. If you have a system capable of streaming all the events and writing out the reporting views, why not use it for everything.

At my previous^2 job, we had a distributed event store that captured all data and could give you all events (or events matching a very limited set of possible filters) either in a given time range, or streaming from a given time onwards. For any given view we'd have four instances of the database containing it, populated their own streaming inserters; if we discovered a bug in the view creation logic, we'd delete one database and re-run the (newly updated) inserter until it caught up, then repeat with the others (queries automatically went to the most up to date view, so this was transparent to the query client - they'd simply see bugged data (some of the time) until all the views were rebuilt).

The events system guaranteed consistency at the cost of a bit of latency (generally <1 second in practice, good enough for all our query workloads); if an event source hard-crashed then all event streams would stop until it was manually failed (ops were alerted if events got out of date by more than a certain threshold). This could also happen if someone forgot to manually close the event stream after taking a machine out of service (but at least that only happened in office hours); hard-crashes were thankfully pretty rare. Rebuilding the full view after discovering a bug was obviously quite slow, but there's no way to avoid that (and again this was quite rare).

In use it was a very effective architecture; we handled consistency of the events stream in one place, and building the view in another. We only had to write the build-the-view code once, we only had one view store and one event store to maintain. And we built it all on mysql.

</comment><comment><USER15> I like this idea but my first impression is it sounds like a lot of work to setup and scale. Am I wrong?

Secondarily, if this were a service, wow!

<comment><USER16> It does seem like a lot of work to me.

One of the problems is servicing two workloads, one for "transactional" processing and another for analysis.

For transactional systems you need to be able to change things quickly and consistently. For analysis you need to be able to query lots of data quickly.

For decades people have realized that these are two separate workloads, so have built 2 systems, a transactional system (on an RDBMS) and a data warehouse (generally on an RDBMS). Data is then shipped between the 2 in batch jobs.

The transactional system is normalized, and the data warehouse is normalized. Within the data warehouse you make denormalized copies of the data that fit the reporting workload required so that as much of the workload is pre- computed as possible.

The problem is that as reporting requirements change, you need to modify these pre-computed stores, as they are very heavily tuned for the particular reporting requirement. Building pre-computed stores is generally done in SQL and can be challenging as you are generally shifting a lot of data and you are trusting the RDBMS to get its optimizations right.

There is a trend now to use Hadoop for the building of these pre-computed stores (and even to use Hadoop for the entire data warehouse). However, writing map-reduce jobs for queries is cumbersome compared to SQL so your productivity suffers. But you don't have to pay Oracle or IBM for licenses.

The key problem is that you need to pre-compute stuff to do fast aggregation, but you can't pre-compute everything. So what you pre-compute is dependent on what your users want, and that changes all the time.

So what you want is a system that lets you change what is pre-computed easily and efficiently.

</comment></comment><comment><USER17> The only novel part of this seems to be that you issue realtime queries over the batch view AND realtime view together; otherwise I don't see what else is interesting here. And I think that novelty is unneeded (and therefore only additional complexity).

Why don't you just: 1) Master your data in "normal form" (graph/entity-based data models like Datomic or Neo4j are perfect for this) in a scalable database (e.g., Cassandra) 2) Use Hadoop for offline analytics 3) Index all of the data needed for realtime queries in a search engine (e.g., elasticsearch), smartly partitioning the data for performance

As for "schema" changes -- you don't need them in an entity-based model because you can always be additive with the attributes in your schema. (You may wish to have a deprecation policy for some attributes but doing this allows you to as slowly as you'd like update any applications and batch jobs that depend on deprecated attributes.)

<comment><USER6> It all comes down to Query = Function(All data). The architecture I describe is a general approach for computing arbitrary functions on an arbitrary dataset (both in scale and content) in realtime. Any alternative to this approach must also be able to compute arbitrary functions on arbitrary data. Storing data in Cassandra while also indexing it in elastic search does not satisfy this, and it also fails to address the very serious complexity problems discussed in the first half of the presentation of mutability and conflating data with queries.

The Lambda Architecture is the only design I know of that:

1) Is based upon immutability at the core.

2) Cleanly separates how data is stored and modeled from how queries are satisfied.

3) Is general enough for computing arbitrary functions on arbitrary data (which encapsulates every possible data system)

<comment><USER18> I'm writing a distributed DBMS based on immutable data. I have a different way of providing fast realtime arbitrary querying of all data and it's much simpler. You just cache intermediate results.

For example, if you want to know the sum of the elements in a tree, but you've already calculated the sum of the elements of another tree that differs on only one path, then you won't need to do much work, you can use the precomputed work for most of the tree and just perform calculations for the parts that are different.

<comment><USER18> In fact, my approach is more general than yours because it isn't restricted to catamorphisms.

<comment><USER6> Afraid not. Nothing is more general than function(all data).

<comment><USER18> You rely on mapreduce, so you don't have the ability to calculate any function. You can only calculate catamorphisms of your data, ( <http://en.wikipedia.org/wiki/Catamorphism> ). You can't solve a SAT problem effectively using mapreduce over the tree of the expression for example. I can't think of a case where you'd want to calculate a function that isn't a catamorphism, but saying that you aren't restricted to them is wrong.

<comment><USER19> Is "median" expressible as a catamorphism? What about a neural network propagation?

<comment><USER18> First, let me explain what I mean by catamorphism. I mean a function that operates on the data within a node of a tree and the values returned by performing the catamorphism on its child nodes.

To find the median, you need the data sorted. You can express something like mergesort as a catamorphism. You take the lists of the child nodes and the singleton list of the value at the node and merge them together. However you have to do a linear amount of work at each node and store a linear amount of data, so it's not really within the spirit of mapreduce because it doesn't scale well, although it is possible.

Catamorphisms are operations on trees, so the first problem with neural networks is that you'd have to embed your neural network in a tree. In the worst possible case, a fully connected network, to find the next value of each neuron, you'll have to find the current value of every other neuron. The problem is that you don't have access to "cousin nodes'" data, so it isn't possible.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> The interesting part about timestamping change to records is essentially "effective dating" and it is bread and butter in any transactional system that needs to record employee info. This is done varying degrees to columnar values or entire rows themselves. In an RDBMS, you will create a compound key to allow you to know the history and the current record. I guess the new fangled NoSQL will make it easier to store it easily..?

</comment><comment><USER21> I don't have a critique for the content yet, and HN is usually the place to post this kind of stuff so here goes.

My initial reaction is to close the window immediately due to the font on the slides. I don't know if that is the fault of my browser (chrome 21.x on this PC), slideshare, or the presenter who put together the slides, but the staggered characters drive me bonkers.

<comment><USER22> My bet is on Chrome's sometimes clumsy font rendering. Go fullscreen on the presentation and the characters will render fine.

Edit: scratch that - each letter shows up as a separate span in the generated HTML. There's no sane way to typeset that.

</comment></comment><comment><USER23> It would be useful if there was a speaker narrative, it would be better still if there was a white paper that this presentation was just summarizing.

What I got out of it was "Just store the raw data", always compute results/queries, BigTable and Map/Reduce are cool. I felt like I missed something perhaps someone here can help.

<comment><USER6> The first chapter of my book discusses a lot of what's in the presentation <http://manning.com/marz/BD_meap_ch01.pdf>

<comment><USER24> Out of curiosity, why is it called the lambda architecture?

<comment><USER6> Lambda is the standard symbol used to represent functions (coming from the lambda calculus). Since the purpose of this architecture is to compute arbitrary functions on arbitrary data, and since the internals of the architecture make heavy use of pure functions (batch view is a pure function of all data, and queries are pure functions of the precomputed views), "Lambda Architecture" seemed like an appropriate name.

</comment></comment></comment></comment><comment><USER25> I'm not sure how to square the normalized schema with the immutability; normalization implies schema changes which imply data changes, no?

In particular, what do I do when there is erroneous historical data that violates the new schema (the newly discovered constraint that was there all along)?

<comment><USER16> Essentially they end up rebuilding the "transaction log" that most RDBMS's use to commit data safely.

Before any data is written to the "data" files of the database, it is written to a "log" file sequentially. Once that has succeeded, it will write to the data file, then write to the log file again to say that the write was successful.

That way if the database breaks during the write, the system knows about it. It's also useful because it allows you to restore the database to a point in time, as you have a full log of all the transactions run (and you know how to un-run them).

In this case, they just make the transaction log a little more accessible.

For your example, erroneous historical data would remain in the system but with a new record being added indicating that at a certain date and time the old record was replaced with the new one.

Basically if you think of a store processing a purchase for $100 and refund of $100 as 2 transactions (for $100 and -$100) rather than simply deleting the first transaction.

This is important because things may have happened between the deposit of money and its refunding (e.g. interest payments).

</comment></comment><comment><USER26> Does anyone know what his NewSQL critique was? (The ""NewSQL" is misguided" slide. BTW, I've read the released chapters of his _Big Data_ book, so I know a fair bit of the slides' context.)

<comment><USER6> NewSQL inherits mutability and the conflation of data and queries. It's no longer 1980, and we now have the capability of cheaply storing massive amounts of data. So we should use that capability to build better systems that fix the complexity problems of the past.

<comment><USER19> ... but it is no longr 1980, amd we have massively more data.

</comment></comment></comment><comment><USER18> > MapReduce is a framework for computing arbitrary functions on arbitrary > data.

No, MapReduce is a framework for computing catamorphisms over trees.

<comment><USER19> I think he meant catamorphisms of arbitrary functions over trees of arbitrary data. As in, you can apply any function at the leaves, and the leaves can be any type.

<comment><USER18> This is directly contradicted in the first chapter of his book:

The Lambda Architecture, which we will be introducing later in this chapter, provides a general purpose approach to implementing an arbitrary function on an arbitrary dataset and having the function return its results with low latency.

</comment></comment></comment><comment><USER27> The OP is an engineer at Twitter...doesn't Twitter use NoSQL to store tweets? I know your critique of NoSQL is that it is an overreaction to the pain of schemas, so I'd like to see some discussion on how to implement lambda with data architecture that, at some point, uses document databases.

Thanks for the post...slideshare is annoying to read (on an iPad) but the content was digestible. Mostly, it helped remind me to download the update of the OP's book</comment>


Git wishlist: aggregate changes across non-contiguous commits - <AUTHOR> https://blog.plover.com/prog/git-wishlist.html <comment><USER2> If you have commits:

      (start) <- A <- B <- C <- D <- E

and you want to see the combined effect of, say, A C D:

1\. make a branch at "start", i.e. at the previous of A

2\. cherrypick A C D onto it

3\. diff your branch with "start".

They discuss a problem in the article where you want to see the sum of diffs from separate branches and it's not clear which change should be diffed first, or what if they conflict.

This problem is solved using this branch/cherrypick/diff method because the order in which you cherrypick the commits is the order you'll see in the diffs; if you don't like that order, do the cherrypick in a different order.</comment>