Meteor meets NoGPL • Hacker News Board

Re: Meteor meets NoGPL

#21

Post by msy » Fri, Apr 13, 2012, 12:48 PM UTC

caf wrote: post #10

jasonkester wrote: post #7

Personally, I'd prefer they just kept it closed source and charged money for it rather than making it "open source, but not really since you can't use it to build anything unless you give out all your code or can lawyer your way past this obnoxious, ambiguously worded license". I don't care about being able to look at somebody else's source code. I just want something that I can use. Meteor looked really cool until I…

How is dual proprietary/GPL anything other than strictly less obnoxious than proprietary alone? You can, after all, stick your fingers in your ears and pretend that it's proprietary alone, and there will be no observable difference.

I think the obnoxious part is not being entirely upfront and clear about what you're looking to do. Sencha make no secret of the fact they're a business, with Meteor you need to infer it from a vaguely worded FAQ point and the licence type.

Re: Meteor meets NoGPL

#22

Post by rbanffy » Fri, Apr 13, 2012, 12:59 PM UTC

chrisrhoden wrote: post #20

This is by no means a clear cut situation. The question of whether a piece of code which uses this library is a "derivative work" is not an easy one to answer, and the GPL only applies in situations where one is distributing said work. Imagine if the client side libraries for Meteor end up in the Google CDN. Then you're only distributing your own code and linking against a separately distributed GPL library. Beyond t…

> linking against a separately distributed GPL library.

Unless you are changing your underlying JavaScript implementation, I don't think you are really linking your code to anything in this case. It could be that your JavaScript runtime got linked to the library, but the runtime/interpreter being GPL doesn't require your programs to be GPL too.

Re: Meteor meets NoGPL

#23

Post by olalonde » Fri, Apr 13, 2012, 1:03 PM UTC

GPL doesn't require you to distribute your server-side code if you are hosting it on your own servers (AGPL does). The client side code does have to be open sourced since it is distributed but Javascript code is pretty worthless without the server-side API, HTML and CSS that goes with it.

In other words, all the commercial license does from a business point of view is allow you to sue people who copy your client side code. That's a pretty poor incentive since most businesses don't even care about people stealing their Javascript.

In addition, as mentioned in the article, the GPL license makes people feel like they are contributing because they legally have to rather than because they want to give back to the community, which is not a good thing from a psychological point of view[0].

FWIW, I would advise the Meteor team to pick a more permissive license and reconsider their business model. Perhaps they can provide consulting, hosting, job board, certification, etc.?

[0] http://www.youtube.com/watch?v=oV0cbCFGAtU

Re: Meteor meets NoGPL

#24

Post by regularfry » Fri, Apr 13, 2012, 1:03 PM UTC

CodeMage wrote: post #11

pwpwp wrote: post #5

It's a question of whether a program using Meteor is to be considered a "derived work". http://en.wikipedia.org/wiki/GNU_General_Public_License#Link...

That's one thing that has been bugging me since the first time I've heard of GPL. If I use a library or framework that's licensed under GPL, without modifying said library/framework in any way, do I still have to (as TFA puts it) "extend the copyleft nature" of GPL to my code? It would be great if someone could finally lay this question to rest.

Yes, you do. From memory there's one get-out: if there are non-GPL products which would be drop-in replacements for the user, the GPL isn't contagious.

Re: Meteor meets NoGPL

#25

Post by macmac » Fri, Apr 13, 2012, 1:05 PM UTC

stefantalpalaru wrote: post #18

pwpwp wrote: post #5

It's a question of whether a program using Meteor is to be considered a "derived work". http://en.wikipedia.org/wiki/GNU_General_Public_License#Link...

I agree. It would be very hard for a lawyer to prove that using a public API amounts to derived work. Even so, GPL allows modified but not distributed versions (like you would see on a meteor server). The author of this blog post does not seem to fully understand GPL.

I agree that the poster only has a superficial understanding of the GPL. Interestingly in the case of Wordpress themes the Software Freedom Law Center has argued that these are derivative works, even though one could argue that these merely use a API cf http://wordpress.org/news/2009/07/themes-are-gpl-too/

Re: Meteor meets NoGPL

#26

Post by chrisrhoden » Fri, Apr 13, 2012, 1:09 PM UTC

rbanffy wrote: post #22

chrisrhoden wrote: post #20

This is by no means a clear cut situation. The question of whether a piece of code which uses this library is a "derivative work" is not an easy one to answer, and the GPL only applies in situations where one is distributing said work. Imagine if the client side libraries for Meteor end up in the Google CDN. Then you're only distributing your own code and linking against a separately distributed GPL library. Beyond t…

> linking against a separately distributed GPL library. Unless you are changing your underlying JavaScript implementation, I don't think you are really linking your code to anything in this case. It could be that your JavaScript runtime got linked to the library, but the runtime/interpreter being GPL doesn't require your programs to be GPL too.

I meant linking in the web sense - literally pointing at some offsite bit of code that you do not distribute and adding its APIs to the context you're currently running in.

Re: Meteor meets NoGPL

#27

Post by antoviaque » Fri, Apr 13, 2012, 1:17 PM UTC

They're making an amazing framework - something a lot of us have been waiting for. They spent time & energy on it, and yet make it freely available. The only thing they ask in exchange is to share what you do with it under the same terms, or pay for their work if you really want/need to be proprietary.

I'm always amazed by this reaction - ie being ok to use the generosity of others, but refusing to reciprocate.

Re: Meteor meets NoGPL

#28

Post by wavephorm » Fri, Apr 13, 2012, 1:23 PM UTC

The real reason permissive licences are preferred is developers are greedy. I know, I'm a developer and I'm greedy. I don't want to admit I'm using other people's code to do my work. I want to silently include that code and pretend that I did all of it myself and impress people with my amazing programming skills. If I have to buy a license I have fess up, and admit to myself I need their code, whereas if I can just use it freely there isn't that moral barrier to cross.

Re: Meteor meets NoGPL

#29

Post by pcc » Fri, Apr 13, 2012, 1:24 PM UTC

CodeMage wrote: post #11

pwpwp wrote: post #5

It's a question of whether a program using Meteor is to be considered a "derived work". http://en.wikipedia.org/wiki/GNU_General_Public_License#Link...

That's one thing that has been bugging me since the first time I've heard of GPL. If I use a library or framework that's licensed under GPL, without modifying said library/framework in any way, do I still have to (as TFA puts it) "extend the copyleft nature" of GPL to my code? It would be great if someone could finally lay this question to rest.

Yes generally you do. But you are only obligated to make source available to parties to whom you distribute the binaries you've built.

Typically a web app that generates and serves html, would not be 'distributing' the derivative work, so there would be no source obligation (GPLv2; AGPL etc changes this).

If its a web app that includes client-side js that in turn relies on a particular server-side API, things are perhaps less clear-cut.

Re: Meteor meets NoGPL

#30

Post by clarkevans » Fri, Apr 13, 2012, 1:38 PM UTC

CodeMage wrote: post #11

pwpwp wrote: post #5

It's a question of whether a program using Meteor is to be considered a "derived work". http://en.wikipedia.org/wiki/GNU_General_Public_License#Link...

That's one thing that has been bugging me since the first time I've heard of GPL. If I use a library or framework that's licensed under GPL, without modifying said library/framework in any way, do I still have to (as TFA puts it) "extend the copyleft nature" of GPL to my code? It would be great if someone could finally lay this question to rest.

For what it's worth, Larry Rosen argues that use of a unmodified GPL'd work, as specified in its API, doesn't necessarily create a derived work.

In my opinion, this question won't ever be put to rest since it's about specific cases, law and human interpretation. It matters quite a bit about what the GPL'd work is, what the application is that uses it, how they are related, and the public intent of both parties. While some lines may form in the future, the boundary of safe use itself will always be a bit blurry.