Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meteor meets NoGPL

blog.lassus.se

Post reply on HN
Print view View original

71–80 of 121 posts

Re: Meteor meets NoGPL

#71

Post by Stratoscope »

madhadron wrote: post #42

Other folks have already pointed out that using a library does not constitute a derivative work, so the author's point is irrelevant anyway. There are times when BSD license and equivalent are sensible choices. Berkeley was releasing a reference set of source code. Their whole point was to have a common platform that everyone was building off of. Similarly, a BSD licensed reference implementation of TCP/IP back in th…

> Businesses have a fiduciary responsibility to maximize shareholder profits. If you're selling software, that means minimizing costs and maximizing income. It is the legal obligation of a company to take any permissively licensed code it can get its hands on and thinks will speed things up, extend it a little, and sell it.

This is not true.

First, not every business is a corporation or has shareholders.

Second, fiduciary responsibility does not require maximizing shareholder value (or profits). This has been explained several times here on HN and elsewhere by people who know much more about it than me. Here's one good explanation and discussion:

http://www.linkedin.com/answers/law-legal/corporate-law/corp...

Excerpt: "...there is no law stating that the purpose of a corporation must be to maximize shareholder return. The corporation’s purpose may be any legal purpose, chosen by the creator and/or the shareholders. There is no requirement of law that profit or the maximization of value or return must be paramount or even on the list of objectives. The overwhelming majority of U.S. corporations have in their articles of incorporation an article stating that the corporation shall have the right to engage in any legal activity."

Re: Meteor meets NoGPL

#72

Post by eaurouge »

mechanical_fish wrote: post #61
nkoren wrote: post #38

As exciting as Meteor is (VERY!), their approach to licensing kills it for me. The products I am working on cannot be licensed under GPL for a large number of reasons, and their "talk to us and we'll see what we can do" policy puts too much risk into my business plan. At the early stage of product development, I don't necessarily know the finer points of how my revenue model will work. If there's a fixed fee for a co…

their "talk to us and we'll see what we can do" policy puts too much risk into my business plan You're thinking of adopting a framework that has been publicly released for a grand total of three days and this is the source of risk to your business plan? Have you tried talking to the Meteor folks directly about licensing terms, yet? Maybe so. This comment sounds like the opening of a public negotiation, an aggressive…

They may only need one customer. Ask the folks who sold MySQL to Oracle

The folks who sold MySQL, sold MySQL to Sun before Sun was bought by Oracle. They were able to sell to Sun because they had a LOT more than one customer using MySQL in the first place.

Re: Meteor meets NoGPL

#73

Post by zavulon »

nkoren wrote: post #38

As exciting as Meteor is (VERY!), their approach to licensing kills it for me. The products I am working on cannot be licensed under GPL for a large number of reasons, and their "talk to us and we'll see what we can do" policy puts too much risk into my business plan. At the early stage of product development, I don't necessarily know the finer points of how my revenue model will work. If there's a fixed fee for a co…

Fully agree, AND it's just bad business decision by them. At this point, what they want is Meteor being used by as many developers as possible. That's a big reason Rails, Node.js, etc got so successful. Instead, they cut off their own feet before learning how to walk.

Unless they change their licensing terms, when Yahoo's Mojito framework finally comes out (or some other competitor who is just as good as Meteor) under MIT license, Meteor will go the way of ExtJS, Powerbuilder, HD-DVD and Betamax.

Re: Meteor meets NoGPL

#74

Post by nkoren »

ajross wrote: post #69
nkoren wrote: post #68

Earlier quoted context omitted.

Excuse me, but why are you talking about "threats"? Saying "I wish I could use your product, but I can't" is a threat ? No, Meteor isn't a risk to my business plan, because I wouldn't put a three-day-old framework into my business plan under any circumstances. What I am saying is that I won't ever put a framework which has this license plus an obfuscated pricing model into my business plan, and that makes me sad. And…

But... every product that doesn't have a price sticker attached to the box (which includes pretty much every development tool out there) has an "obfuscated pricing model". Are you saying you'd never buy a commercial database product? A RHEL site license? Maybe not, but if so: why are you complaining about the GPL specifically instead of just stating that you won't buy products without fixed pricing?

I'm complaining about the GPL in conjunction with obfuscated pricing. If their pricing were more transparent, I would certainly have less of a problem.

And yes, I know that many products are sold on a negotiated, non-fixed-price basis. I generally do everything possible to avoid buying those products, as that is too often a cover for predatory pricing practices. There are plenty of ways to do sensible price differentiation while still stating your policies clearly.

Re: Meteor meets NoGPL

#75

Post by bjxrn »

zavulon wrote: post #73
nkoren wrote: post #38

As exciting as Meteor is (VERY!), their approach to licensing kills it for me. The products I am working on cannot be licensed under GPL for a large number of reasons, and their "talk to us and we'll see what we can do" policy puts too much risk into my business plan. At the early stage of product development, I don't necessarily know the finer points of how my revenue model will work. If there's a fixed fee for a co…

Fully agree, AND it's just bad business decision by them. At this point, what they want is Meteor being used by as many developers as possible. That's a big reason Rails, Node.js, etc got so successful. Instead, they cut off their own feet before learning how to walk. Unless they change their licensing terms, when Yahoo's Mojito framework finally comes out (or some other competitor who is just as good as Meteor) unde…

Mojito was released two weeks ago: http://developer.yahoo.com/blogs/ydn/posts/2012/04/yahoo%E2%...

On github: https://github.com/yahoo/mojito/

Edit: It's released under a BSD license.

Re: Meteor meets NoGPL

#76

Post by debergalis »

[I'm one of the Meteor authors.]

We released under the GPL Tuesday because our single goal was to share our work and direction of thinking with everyone. We hoped to spur a discussion about new ways to build apps that dramatically changes the skill sets required and the time it takes. We look at Meteor as part of an exciting transition from LAMP to a new architecture of rich client applications (see also http://www.firebase.com/ that launched yesterday!).

That's still the main focus for now. Hundreds of developers have deployed apps to meteor.com. We've got pull requests for new features to sort out, and many technical questions to answer. There's a whole buffer of screencast ideas we want to do.

The four of us are a company. We intend to make money while committing ourselves to an open-source strategy. We want to see great software -- not just ours -- be something developers can sell. So while we'll give away much of what we build, we'll also look for places where developers who gain benefit from Meteor can give something back.

We did not expect such strong interest in writing closed source commercial apps this quickly on the platform. It's clearly something we have to sort out faster than we thought, and we will. For now our offer stands: please just write us if you need a commercial license for a closed source project and we will find a way to accommodate your needs. I'd imagine over the next couple weeks we'll have more concrete things to say.

Re: Meteor meets NoGPL

#77

Post by mistercow »

olalonde wrote: post #23

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…

> GPL doesn't require you to distribute your server-side code if you are hosting it on your own servers

This is very clearly true, yet I know of several GPL libraries whose maintainers believe the opposite. It is very strange.

Re: Meteor meets NoGPL

#78

Post by eaurouge »

Nokia faced a similar problem after they bought Trolltech (creator of Qt). How to increase adoption and encourage community contributions. They opted for LGPL which, as mentioned elsewhere in the comments, allows proprietary software to link to the Qt source.

Re: Meteor meets NoGPL

#79

Post by webjprgm »

I dislike GPL because it makes business decisions (licensing concerns) get in the way of any and all programming.

Sometimes I make a lib that I want to use for myself, proprietary but not profit making. Sometimes I later want to use that library in a consulting project (now it's profit making). In general, I don't know whether all the desired end uses of my code will be commercial, open source, or just simply code I use personally but don't want to release.

(I believe the GPL triggers upon release/distribution of software, right? If I keep my modified version on my local system and don't sell it or ship it then there's no conflict. However, using it on my personal machine to serve up a publicly accessible website, I believe, also triggers it. Since lots of my "personal" code gets used on my personal, non-commercial, web site, I stay away from GPL even when I think I'm never shipping a piece of code.)

Re: Meteor meets NoGPL

#80

Post by webjprgm »

ajross wrote: post #57
nkoren wrote: post #38

As exciting as Meteor is (VERY!), their approach to licensing kills it for me. The products I am working on cannot be licensed under GPL for a large number of reasons, and their "talk to us and we'll see what we can do" policy puts too much risk into my business plan. At the early stage of product development, I don't necessarily know the finer points of how my revenue model will work. If there's a fixed fee for a co…

Um... how is "talk to us and we'll see what we can do" a problem? Isn't that exactly how proprietary licensing works for non-shrink-wrap developer tools like this. You'll get the same response if you want to buy ClearCase or a CAD tool, etc... It's a commercial product that also happens to be available under a free license you can't use. How does the second part impact the first? Edit: it seems the implicit context i…

I'm sure there's some element of not wanting to pay money in the original comment, but the commenter clearly stated that one viable option is to make the pricing explicit.

I agree (almost) completely. When the pricing is obfuscated you can't take the risk of building software without knowing how much the license is going to cost you. Where I don't agree is that you can probably talk about pricing before you start coding, while developing your business plan. Hopefully they are flexible enough to have reasonable negotiations even though your business plan is not yet fixed in stone. Ideally the negotiations would simply be them stating a fixed price and a bit of haggling. It's complicated if they want a percentage of profits. But you don't know until you ask.

Post reply on HN