
Meteor meets NoGPL - mapleoin
http://blog.lassus.se/2012/04/meteor-meets-nogpl.html
======
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.

~~~
koko775
I think you're turning this too corporate too soon.

At this stage your most powerful evangelists will be hobbyists and spare-
timers. When I write code, I _like_ to write it open-source. Setting the
obviously negative connotation aside, it is objectively true that the GPL
code, compiled or no, is a license virus that spreads so fundamentally that
linking with non-GPL-compatible code violates the terms. Because the
distinction between client and server code is blurred, this makes the
territory murky and introduces overhead into the developer's mind as to
whether what is being written can ever be open-sourced or not.

\---

Besides dampening enthusiasm for using Meteor, this can also reduce the
quality and usefulness of modules being released. This sounds counter-
intuitive, but consider the following hypotheticals:

Company A develops and maintains a production-ready module that is especially
useful for anyone using Meteor. However, the legal department says that the
company cannot release software under GPLv3 (this _is_ common). Company B and
Person Z want to use it, the former with a commercial license, the latter with
a open-source license.

Because Company A cannot release the module under a permissive license, they
can 1) Release it permissively but in a GPL-incompatible license, thus banning
all Person Z's from developing open-source software with it legally, 2) Opt
not to release it at all to Person Z, and just license it to Company B. 3)
Abandon Meteor for something they can both release openly (to give back and
get more eyes and hands) and develop in-house.

Company C uses a closed-source library, because they're required to use it
because it's the only one out there, and they're contractually obligated
because that's the business they're in. They use Meteor to get the project off
the ground and they never move off, because it's what they know and are good
at. Company C can _never_ write, for example, a white-label platform to
distribute to Company X and Company Y, because at best they could only
distribute the platform sans non-GPL parts. And while the licensing is viral,
the understanding of it will not be. So it may lead to GPL violations down the
road because Company X didn't understand, and Company C may be holding the
bag. Legal doesn't want the company to take the risk and assume liability, so
it says "no" and kills the project's use of Meteor.

Company D thinks about the hypothetical case of Company C, only it was just
founded and is looking at Meteor. Maybe it was founded by Person Z. Because of
the hypothetical of Company C, and because Company D doesn't know what their
business is yet, they decide to avoid a potential future nightmare and write
their own framework. Maybe they open-source it, because it's compelling and
useful, and they want to get as many eyeballs and hands on it as they can,
improving it.

\---

tl;dr I was super-excited about Meteor, but now that it's GPL I will not be
touching it with a ten foot pole. I am _really_ sad about this.

Because I value developer freedom, I do not use GPL'd code in my projects,
even if it is objectively good. Because I support open-source, and want to
give back when I can I do not want use Meteor with a commercial license. So
because of your choice of license - and for no other reason - I can not and
will not use Meteor.

~~~
zobzu
It's so hypocritical tho.

Obviously you want to release only code that will help you code less in the
future (ie: let others maintain feature X for FREE for us; but don't give them
what MATTERS)

And that's the main concern with all the anti-GPL folks - that's also the very
reason why the GPL exists.

~~~
koko775
Having developed and released something under the GPL a long time ago, I am
not anti-GPL, but that doesn't mean I'm not wary of it.

> Obviously you want to release only code that will help you code less in the
> future

No, I want to release code other people might find useful.

> ie: let others maintain feature X for FREE for us

This sounds naive. Virtually nobody writes a library then abandons it when
other people start helping out.

> don't give them what MATTERS

"What matters" is highly subjective and different to different people. What
matters to Twitter is the userbase and user experience. So they open-source
their database stuff, Bootstrap, and a plethora of other things. And why not?

It's not hypocritical. The GPL was critical to the fight against closed OSes
and the closed tools that made writing software essentially limited and pay-
to-program.

My view of open-source and programming in general is that there are many
things that programming can help you do. More often than not, these are the
same things. The more programmers can help each other to spend more time
writing things that are great, the better off we all are.

The GPL fights proprietary software, but for things that are not products on
their own, but are designed to be a component of or integrated into other
products, it can also fight other programmers as well. I use GPL software, but
I don't use GPL libraries or frameworks. (The LGPL is less selfish - the whole
software ecosystem doesn't need to open for it to play its part, but the
library damn well stay open.)

------
nkoren
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 commercial Meteor license, then I can
put that into my business plan, see what kind of impact it has under different
scenarios, and make a judgement call. But a "let's discuss your revenue model
and see what makes sense" approach simply _can't_ happen during the earliest
stages of product development. Which means that basing my product around
Meteor would introduce a potentially catastrophic risk into my business,
should their licensing terms turn out to be too onerous, once that
conversation can finally be had.

So, with considerable regret -- because it looks awesome -- Meteor is unusable
to me. I'm certain that many other people are in the same boat.

Its developers say that they've chosen this license because they want maximum
contributions from the community. By seriously limiting the size of the
community that can use Meteor, they've chosen the wrong way to do it. I would
strongly urge them to reconsider their choice of licenses. The MPL[1] would
probably be the most compatible with their aims, since it requires any
modifications to the core Meteor components to remain open source, while
allowing the inclusion of closed-source components without violating an
aggressive copyleft. This is a constraint that I would be very happy to live
with. Choosing between an agressive copyleft or whatever is behind the mystery
curtain labeled "commercial license" is not.

If the Meteor team wants to fix this, they can either:

1\. Clearly state that they require a commercial license for commercial use,
and state the price and terms of that license upfront (the Sencha approach).
Or, better yet:

2\. Switch to a license such as MPL, BSD, or MIT.

The former will allow commercial developers like myself to begin adopting
Meteor; the latter is guaranteed to produce a much more robust open-source
community around it. If Meteor is to become the next Rails, then that's what
it needs to do.

Barring this, I'll just wait for other enterprising developers to take the
Meteor concept and re-implement it with a more permissive licensing scheme. If
Meteor is as good as it looks, then this should happen relatively quickly.

[1] <http://www.mozilla.org/MPL/1.1/>

~~~
ajross
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 in your post is that you would use this if
it were free under a permissive license, but not if it costs money or is GPL.
That's not an uncommon position, but it's not something that rises to a multi-
paragraph complaint on HN. You're complaining about the "GPL" instead of
complaining that "the authors want to charge money", and that seems
inequitable and unfair. If they were just another tool vendor, you wouldn't
have posted: basically you're _punishing_ them for releasing free software.

~~~
WiseWeasel
One of the main points is that Meteor supposedly seeks to build a community
around their project, and that the GPL is a hindrance to this goal. Without a
strong community, a tool such as this might not have much relevance in the
future, relative to others which _have_ successfully built a rich ecosystem
around themselves.

~~~
ajross
There are plenty of GPL projects with robust communities though. (Albeit not
in the web development space). The same kind of thing was argued c. 1998 when
the "Open Source" branding movement started and all the cool projects went
with permissive licenses. And it really wasn't correct. GPL projects continue
to be very successful a decade and a half later. The apocalypse never came.

So I guess I'm saying that I understand that argument, but I don't buy it.
Which side of the argument you land on tends to be colored mostly by your
emotional feelings about the GPL (I find as I age that I'm becoming more and
more a pinko commie copyleft fanboi, for example), and not really well
grounded in practice.

~~~
WiseWeasel
I typically land on the side of pragmatism over idealism, and as a lifelong
observer of human behavior and psychology, I would say the argument carries
some weight. A project I can start using without even thinking of licensing
issues, and grow to become dependent on, is one I'm much more likely to
contribute towards, simply out of selfish necessity and convenience.

~~~
ajross
Sure. But that's only pragmatism in the sense of "I want what's best for me
and my project". It's the kind of "pragmatism" that led Andy Rubin to demand
rewriting the GPL userspace with a clearly inferior one for Android, for
example.

After enough years and enough projects, I find my perspective is broader. The
GPL helps more than it hurts. Efforts to _explicitly avoid_ the GPL (not just
to use permissive licenses for free software projects -- that's clearly a good
thing) tend to hurt more than they help.

~~~
WiseWeasel
How does saying "If you use my code, you have to give me your code" make me
want to use it, let alone join your "community"? It seems toxic and coercive
to me. It's suggesting that my code is of much lower value than your code, so
don't worry about it. This might be correct most of the time, but when it's
not, it's a problem.

Good communities are founded on mutual respect and voluntary engagement.

~~~
Avshalom
>"If you use my code, you have to give me your code"

No, the GPL says "If you use my code, you have to let people use yours too"

~~~
WiseWeasel
An important point, it's true, but you've gone too far in the other direction.
It's more like:

" _If you use my code, you have to share yours under the terms I determine._ "

It muddies my main point about the relative value of the code in question,
however.

------
olalonde
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>

~~~
mistercow
> 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.

~~~
getsat
Are they GPL, or AGPL? The AGPL removes the so-called "network service
loophole". Unsurprisingly, few projects use it.

------
marcusf
First of all, it's of course the Meteor team's prerogative to chose whatever
license they want, and wanting attribution and pull requests is in no way an
unworthy cause.

That said, GPL made me look twice. Mainly because client and server are so
intertwined, that I assume the entire app would need to be GPL'd to use Meteor
without getting a commercial license. Now I've nothing against the dual
licens, and paying for a framework that makes us money , but before shopping
Meteor around the company it'd be good to have some specifics on what they're
thinking in terms of a commercial license model. I hope that's on their
priority list. It's hard to motivate investing in something that may later
turn out to be prohibitively expensive.

------
zdw
LGPL with a linking exception for platforms that require solid binaries (like
iOS, some embedded systems) covers the vast majority of use cases that the
"anything but GPL" crowd cares about.

In Meteor's case, as it's middleware, the LGPL would be the more appropriate
license anyway.

I get the feeling that they're searching for business models with Meteor. The
most obvious one would be optimized paid hosting ala Heroku...

------
antoviaque
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.

------
jasonkester
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 realized they
had those two points exactly backwards.

~~~
bguthrie
It took years to convince the wider commercial technical community to so much
as expose portions of their source code, regardless of license. It's
invaluable for bug identification, security auditing, and general programmer
education. I'm glad they're sharing it under any license, and I hope your
attitude does not become more widespread.

~~~
praxeologist
Actually, what needs to die is the idea that anyone can own an idea (or
pattern of words/code).

------
shawndrost
I met these guys last night, and I'd really recommend you write them before
you let the GPL stop you from developing software using Meteor. It sounds like
they'd be happy to license it otherwise to anyone that wants to use it now,
but they don't want to neuter their monetization for all the people that sign
up later. (If I were them, I'd formalize that fact and dual-license for early
adopters to bootstrap their community.)

------
cek
We started digging into Meteor this week (we are using Node.js with
express/LazyBoy etc... now) and were really excited about it.

But now, this has created FUD for us.

It's all so complex and confusing at a time when we really just want to be
writing code. Our startup is not far enough along to know for certain what
licensing terms make sense.

I can't believe we will be alone in having this reaction. Which is a shame
because Meteor had such a chance of being a real big thing.

------
obituary_latte
I think I prefer the paid-support model a-la RedHat. I think the OP makes a
good point of this licensing possibly hindering uptake/contributions to the
Meteor project. Just by virtue of Meteor choosing this licensing model, I've
lost some of my excitement to try it out. I would most certainly use it for
something commercial and because it looks so sweet I would be willing to shell
out some $ for, say, some email support or maybe for some bleeding-edge
features.

Having to worry about not being able to use Meteor in a commercial capacity
without knowing the price-point breaks the deal off the bat. I'm a one man
team and don't have the time nor resources to swim through legalities and
pricing--I need to be writing code.

This isn't to say, though, that if I wanted to do something outside of the
scope of a commercial app I wouldn't try Meteor--but who knows when/if that
will happen.

~~~
woodhull
That's kind of a silly view. You would rather spend 6 months "writing code"
than spend 1 day negotiating a contract that would save you 6 months of
effort?

What if sending them an email that took as long to write as this HN post would
get you a quote?

Psychology of product purchasers is fascinating.

~~~
obituary_latte
How about if my budget for negotiating contracts is $0?

If I don't have a baseline price and I am worried about licensing, I'm not
going to spend time trying to fight for a budget to then spend time trying to
negotiate a contract--I don't have time.

If I could dev without licensing worries, _then_ I _would_ fight for a budget
for things like support and add-ons.

Also, may I ask why you put "writing code" in quotations?

------
mindslight
It's quite entertaining to see "Proprietary Software 2.0" developers
complaining about _finally_ being affected by a requirement of Free Software.

------
drpancake
Sencha took a similar approach with ExtJS and it pains me to watch it falling
into obscurity. The framework itself is elegant and well thought-out; it seems
that everything Backbone and its various offshoots give us now was already
available there years ago.

~~~
clarkevans
I don't think they are falling into obscurity -- last I talked with people
there, Sensha is quite profitable and growing rapidly.

~~~
drpancake
Sencha Touch is growing because they stopped dual-licensing it. Going on my
own personal experience, ExtJS doesn't have much mindshare in the circles I
care about i.e. valley-style startups.

------
chrisrhoden
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 that, you don't even care if the library is
actually Meteor, you just care that it has the API that you use, meaning it
can't really be suggested that you know you're linking against GPL code.

What about the server/client split? Could you make an argument that they're
implementation agnostic to one-another? So why would you need to distribute
your server side code just because you distribute your client code? Simple
answer is that you don't under the GPL.

~~~
rbanffy
> 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.

~~~
chrisrhoden
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.

~~~
rbanffy
Technically, you are instructing your runtime to load and execute source code
hosted elsewhere. I don't think this is the kind of linking GPL refers to.

------
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.

------
pwpwp
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...](http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works)

~~~
CodeMage
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.

~~~
pcc
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.

~~~
zmoazeni
_(GPLv2; AGPL etc changes this)_

Could you clarify? GPLv2 doesn't require source in this case and AGPL does? Or
both GPLv2 and AGPL (along with versions) do?

~~~
Lazare
If your application lives on your own server, and only static HTML/CSS is
served to clients, then under the letter of the GPL no "distribution" has
taken place, and you do not need to make your source code publicly
available[1]. This is known as the "ASP loophole".

The AGPL was specifically developed to close this ASP loophole, and a app on
your own server, again only serving static HTML/CSS to clients, _would_
require you to make the source code available under the AGPL.

Now, the big question is, what about apps that serve up JS to clients? Again,
the spirit of the GPL is clear here: You are distributing GPL code to clients,
and must make the source code for everything (client, server, build scripts,
unit tests, media assets, _everything_ ) available. But unlike in the static
example, the letter of the GPL is very unclear.

Many people - including Sencha, who have built an entire business around this
interpretation - believe that webapps with significant client-side components
are "distributed" under the terms of the GPL, and thus the ASP loophole does
not exist for JS-heavy GPL-licensed webapps; the source code must be made
available, and that this requirement extends to both the client and server-
side codebases.

Other people have argued that - contra Sencha - the GPL only applies to the
client code of webapps. Still others have argued that the ASP loophole _does_
still exist for GPL-licensed JS applications. Other people argue that the
somewhat archaic terms used in the GPL don't even apply to modern interpreted
languages. It's even been suggested that you can't even legally visit a
website using GPL JS on a non-free webbrowser like IE, nor use Google
Analytics on any GPLed website. The whole thing is, frankly, a royal mess.

Anyhow, coming back to Meteor: Ultimately a court's interpretation will be
binding, but no court has ruled on this issue. Until then, you're probably
safest following the wishes of the author. If - as with Sencha - the author
says that there is no ASP loophole it's safest (not to mention morally
correct) to follow their wishes. In this case, the Meteor dev's appear to be
following an interpretation very close to Sencha's. So the safe/moral answer
is - at least until there's more clarification - assume that for any Meteor
app that the GPL and AGPL are effectively the same. :)

[1]: You would be, of course, thumbing your nose at the spirit of the GPL.

------
madhadron
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 the day meant that everyone could
get the protocol up and running much faster with far fewer inconsistencies.
BSD licensing is useful for social engineering.

But for most cases this isn't so. Why would anyone who wrote a JavaScript
library and gave it away want to make it easy for someone else to build a
company around taking their work, extending it a little, selling it, and
giving nothing back other than enough tidbits to keep the community (if any)
from getting up in arms? This is what happened to the Lisp machines, and it's
exactly why the GPL is the way it is. 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. My response:
if I'm not trying to engineer your behavior, stop leaching off the community
and buy your underlying components.

The GPL exists for a reason. Every so often, some cheap bastard complains
about it because he can't make a quick buck by ripping someone else off.
Tough. That's why it's there. You want to use my work on this? Give me yours
in exchange.

~~~
Stratoscope
> 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...](http://www.linkedin.com/answers/law-legal/corporate-
law/corporate-law/LAW_COR_CRL/834796-1078684)

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."

------
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.)

------
rcthompson
Am I missing something here? My understanding is that when you use GPL
software in your product, you are not required to GPL your own code unless
your code and the GPL code are compiled into the same executable that is
distributed to the user. Looking at the Meteor website's front page, I don't
see anything that suggests it compiles your code and its own coffee into a
single executable, so I don't think that using it would require you to GPL
anything except possibly any customizations that you make to Meteor itself.

Obviously this is not legal advice, and may in fact be the delusional
ramblings of someone who has no understanding of the GPL. But please enlighten
me if I'm wrong.

------
alecco
Original authors have the right to license their code whatever way they
please. This kind of article is disgusting.

If it were a proprietary license nobody would raise a finger. HN is a very
hypocritical community.

------
47
Sencha has used GPL/Commercial License business model successfully.

------
lucian1900
This is likely irrelevant for the server-side bit, and it remains to be
determined if it is for the client-side.

It will hinder contributions if they require attribution, however.

~~~
madhadron
Absolutely. The license difference is why FreeBSD is so much more widespread
than Linux. </sarcasm>

~~~
cperciva
The license difference is why you're aware of so many places that Linux is
used. It's hard to miss a blob of text as big as the GPL.

There are a lot of boxes running FreeBSD internally which you never hear
about. We try to convince vendors that it's ok to talk publicly about using
FreeBSD, but an awful lot of them consider it to be "secret sauce" which they
don't want their competitors to hear about.

------
dabeeeenster
"The basic idea is that the source code is publicly available for people to
look at and modify and that it costs nothing to use as long as you’re building
a GPL application with it and give out your source code too"

Can anyone confirm whether this is actually accurate? I'm not sure it is...

~~~
zmoazeni
I've been reading up on GPL because I know little about the nuances, but I
think you only need to GPL and provide the source code if you distribute it to
others. Web seems tricky for GPL, but I thought that was the purpose of AGPL.
Please correct me it I am wrong.

~~~
davidroetzel
AGPL closes the "loophole" for server-side code.

Meteor pushes a lot of code to the client. This most probably constitutes
distribution.

See Sencha's take on this: <http://www.sencha.com/legal/open-source-faq/>

They make money by dual-licensing JS code.

------
markh
This has all the makings of a 'KDE vs Gnome'-like battle. For those not around
at the time, a quick refresher: KDE was launched to applause and was based on
a (then) restrictive Troll Tech license (for its QT library). This restrictive
license lead directly to the creation of the Gnome project and so we saw a
very promising desktop environment lose momentum and support as community
resources were diverted to reinventing the wheel with Gnome (IMHO).

Yes, we have more choice now in the world of Linux desktops, but I still
believe hundreds of man years were wasted and the Linux desktop effort set
back years, due to Troll Tech's choice of license. Of course, Troll Tech
finally realized the error of their ways, but as history clearly shows us, it
was too late.

So, does Meteor want to risk being a KDE (or even Svbtle) and have the
community praise it for their ideas and invest huge amounts of time
reinventing the wheel, or do they want to harness the unstoppable momentum of
the developer community?

------
wavephorm
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.

~~~
protomyth
It's not greed, it's friction. Developers don't like friction in development
and worrying about licensing is a type of friction that requires real money. I
want to help them (I contribute $ to a few projects), but I need to know my
stuff will work with there's before I go paying. There are few things worse
than paying for software, deploying, and finding out you need to switch to
something else.

I am fine with attributing others. I have actually done it after paying even
when paying removes the need (e.g. glyphicons pro).

~~~
zobzu
attributing != sharing back

it's greed, ego, etc.

~~~
protomyth
I'll share back too if it I have some improvement (I am going to test in on my
own site first).

Greed is actually a very poor reason for not sharing back. It actually costs
more money to maintain a forked code base than contributing the change back
and getting it maintained by everyone. It is also fairly stupid to hide what
software you are using from a recruitment point of view.

I prefer the BSD / MIT licenses because the sharing occurs on my schedule,
less stress, and less friction. I like doing things because it is right and
not because I have a lawyer at my door.

