If their goal is to prevent misuse of the project by unethical profit-minded entities, GPL3's anti-tivoization language would have ensured that even if a company profits from building or running a MAME-based cabinet (which is good!), they wouldn't be able to deprive their customers' freedom to fix or upgrade the software that runs it. (As they now can!)

It's even worse for the permissively-licensed parts of the code, which can now be used to build locked-down proprietary cabinets that users can't even inspect. I'm glad they got at least part of the project covered by copyleft.

The "common questions" on their site contains some confusing claims, too:

> Q. Can I include MAME with my product? > A. Yes. You can use 3-clause BSD compliant files but project as whole is under GPL-2.0 license so in case you wish to use those part you need approval from specific developers.

You'd only need permission if you didn't want to comply with the terms of GPL2. There's nothing in GPL2 that requires permission for inclusion with a product.

Maybe that's just leftover from before the license change?

No, the GPL does not do this.

Obeying the requirement to share source code does not necessitate that your profits must evaporate. If your competitor picks up your (A)GPL'd source code? They too then must release their changes.

> because we can't handle the idea, even the /mere possibility/, that someone might be more successful with our own project then we are.

If by "success" you mean "rich," then no. GPL is not concerned with money, it is concerned with the user's freedom to inspect and modify the source code of the software they use.

Go ahead, get rich. Be more popular than me. But if you base your work on mine, I want to see what your software is doing in my computer, or with my information. I want to fix a bug long after you have stopped supporting your software. I want to make the software run on devices that you will never care about. I want all the value and data and time I've spent on your SaaS service to not simply evaporate when your crappy VC-funded startup gets bought and shut down by Facebook.

> People won't stop contributing just because you aren't forcing them, BSD is proof of that,

Yes, some people would still be ethical and contribute back. Many won't. Companies are notoriously sociopathic, especially companies who are legally required to maximize profit for their shareholders, especially companies whose primary goal is return on investment for the VC that funded them.

I don't trust companies to be nice. You want to avoid paying a developer to build a poor NIH mimic of my awesome work? The price is that you must give your users the source code of your changes. I don't care if you get rich in the process. But I reject the implied assertion that you're "obstructed" from doing so.

This is wrong. Copyleft licenses are concerned with freedom, not price.

I don't care if somebody gets rich off my software while I don't.

I don't want somebody to take the work I have done and turn it into proprietary software that other users may no longer have the freedom to inspect, modify, and share. THAT is why all my work is GPL or AGPL. It has nothing to do with whether you make money or those users spend money or I get a cut of some money.

Now that we have so many SaaS startups, "turn it into proprietary software" includes "use it to build a service and never distribute the sources."

GPL and AGPL protects my code from this happening, while licenses like MIT and BSD ("permissive" licenses) do not.

Permissive licensing, in the context of SaaS, is functionally equivalent to proprietary licensing. Somebody benefits (not necessarily monetarily) from the use of my software without paying its price: improvements must be shared.

Precisely. The thought that someone might take the code I wrote and make it into a proprietary product, removing the freedoms I had, is horrible. But if someone made an free software product based on it and made millions, all the better for them!

To put it another way, once you license something under GPL, it is forever GPL. That's a strength of that license in the sense that it has allowed so much excellent and important software to grow and flourish. On the other hand, when you license something under BSD, at any point you have the power to take it to another license or make it proprietary. That's the "permissive" part that many people (including GPL advocates) don't get. The source code itself is still open as long as the original author wishes it to be. Under the GPL, the source code is open for all eternity, even if the original author changes her mind later.

Another aspect of this (and it was mentioned elsewhere in this discussion) is that, even if a company comes along and turns your BSD licensed code into their own proprietary product, you still get to keep your code and continue to improve it. All they've really done is forked it; if they are a good citizen they will even contribute improvements back to you. I think the classic example of this is Mac OS X, which is based in part on FreeBSD. When Apple forked FreeBSD into the base of their new commercial OS, the FreeBSD project didn't magically disappear. Here we are 15 years later and both the commercial OS X and the open source FreeBSD are flourishing. Development of FreeBSD didn't die the day OS X was born.

Neither does the GPL. The GPL does not place restrictions on the author. In fact, as the author of a project, you can declare your project GPL and totally fail to comply with the GPL yourself, because the license is a copyright license, not a contract.

> To put it another way, once you license something under GPL, it is forever GPL. That's a strength of that license in the sense that it has allowed so much excellent and important software to grow and flourish.

Both the GNU GPL and BSD licenses are non-revocable (except, in the case of the GPL, if a reuser violates the license)

> On the other hand, when you license something under BSD, at any point you have the power to take it to another license or make it proprietary.

Assuming "you" refers to the author of a project, they can change the license they use for the project in the future regardless of whether they initially chose BSD or the GPL.

(I'm on the Debian ftpmaster team, which checks all new binary packages submitted to Debian; I review licenses for fun)

It's forever GPL for people who use it under the GPL license. If you're the copyright holder, not a licensee, you can change the license if you want to. Of course that doesn't stop people from using existing GPL copies, and you do have to be the actual copyright holder (e.g. if you accepted patches from other parties, you have to get permission from their authors to make such a change). But given such permission, a change can totally be made.

An example is the Mozilla code, which used to be licensed under a tri-license that included the GPL and was relicensed to a different license (MPL2). This process required finding everyone who had copyright on the codebase (several companies and a number of individuals) and getting their permission for the license change.

Now it's true that using the BSD license means you don't have to hunt down those other contributors and get their permission to relicense, so the bar for the author taking the code proprietary is lower (and in fact identical to the bar for anyone else doing so).

The MPLv1 already had an auto-upgrade clause that allowed any downstream to use and distribute the code under a later version published by the license steward; the MPLv2 also is implicitly a triple-license with LGPL/GPL.

MPL v1.1 "6.2. Effect of New Versions" does mention the new version of the license has to be published by Netscape instead of the Mozilla Foundation; was that the issue perhaps?

This page seems to agree with my reasoning in "Does Mozilla need permission from anyone to change the MPL?"

https://wiki.mozilla.org/MPL_Upgrade

"No permission is needed from any contributor to upgrade the codebase from MPL 1.1 to MPL 2 because the MPL 1.1 contains within itself a provision which allows software under 1.1 to be redistributed under a later version of the licence."

And that's why I would NEVER contribute code to any of your projects. You want people to work for you for free, then when you're ready just close the code and run with it? Yeah, right, try again.

The GPL is a "you can't screw me, I can't screw you" license. The BSD is a "whatever" license, much like the MIT or a CC0/Public Domain. If I don't care about the code, if it took me no effort to create, I may consider the BSD... or just the CC0, whatever. Otherwise, you're either looking at a real contract or the GPL, and you better don't try to screw me either way.

Oh, and you can re-license YOUR code under any license you wish. If you published it once under the GPL, it only affects whoever may get it from that publication; you can still re-publish it in the future under any other license you wish, since it's YOUR code, to do as you please.

If they accepted changes from someone else, that someone else has copyright on those changes and the license can't be changed without them agreeing to it (or possibly their changes being removed from the codebase; I am not an IP lawyer and you should consult one if you want to be sure on this score).

IANAL but as best i can tell, neither apply for GPL.

The changes do not have to go back to the original developer. All that is required is that the code changes are published if ever binaries based on those changes are made public.

And going proprietary is possible if everyone involved agrees. Note the number of multi-license projects out there, including some fairly substantial ones like Qt.

I feel this argument is weak: even if I license my works under BSD, no one can make my BSD licensed code that has already been distributed into to a proprietary product, even not myself.

To make that software that I licensed under BSD a proprietary product they would need to somehow convince all users of my software to get rid of all copies as well as convincing me to stop distributing it under a free licence.

Building a proprietary product that includes my code does NOT remove anyones freedom to use my code, no?

But what if your code writes files or communicates over the network? And what if, say, Microsoft takes your permissively-licensed code that is just beginning to gain popularity, changes one piece of it to make it incompatible with yours, and doesn't release their change? They use their massive marketing department or pre-bundling to get lots of Windows users to use it. Everyone is still free to use "your" version of the code, but nobody wants to, since it is incompatible with the more popular Microsoft version, now on its way to becoming "the standard."

If you are okay with that, no rabid copyleft zealot like me has any place to criticize you. Release your code with a permissive license. That's fine. (Permissive licenses are considered "Free Software" by FSF and rms as well, after all.)

But to me, that seems grossly unfair for code I spent my valuable time designing and developing, so I don't release my code under a permissive license. If Microsoft wants to build a product with the work I have done, it needs to convey the same freedoms to its users that I did. That's the cost.

And sure, everyone is free to use the v2 version of the code (i.e. gcc 4.2), but nobody wants to, since all new development is happening with the v3 version, which is now the standard.

Linux is a famous exception: it omits the "or any later version" clause, and so avoids getting steamrolled in the way you describe.

How can they relicense the code unless every contributor signed a Contributor License Agreement granting them that right?

A quick search seems to indicate that GCC has no such CLA.

So if you write something under the GPLv2, and I change it and publish it, then the GPL says I need to release the source under the GPLv2 or later. This means that I can publish it under the GPLv3, and you can't take back my changes unless you upgrade your software to the GPLv3.

Linux removed the "or later" text from their version of the GPLv2, meaning that I can't change the Linux kernel and publish the result under the GPLv3.

However, you can "upgrade" LGPL code to GPL, see LGPLv3 "2. Conveying Modified Versions".

There is a FLOSS license that has an implicit upgrade to new version clause: the Mozilla Public License, see "6.2. Effect of New Versions" in MPLv1.1.

It looks like the "or later clause" is a built in option, but not a built in default, of the GPLv2. With that I mean that the meaning of that phrase is explained in the 9th clause.

At least to my knowledge the opposite seems to be more common. Experts release a library under a very permissive licence, and everybody wins. One such example is libPNG.

http://www.libpng.org/pub/png/src/libpng-LICENSE.txt

KHTML (LGPL, not GPL) taken by Apple to make WebKit (LGPL), later "rewritten" and licensed BSD for 2.0.

Apple did also the dirty trick of giving a single huge patch against the previous release of KHTML making it almost impossible to integrate back to the main codebase. Even LGPL can be abused. Lesson learned the hard way by the community.

And you now have everyone parroting how great WebKit is, nobody remembers the original team at KDE. It was brutal.

> While Microsoft uses the Kerberos protocol, it does not use the MIT software.

The license of the original implementation is thus irrelevant. Pretty much the only thing that would have prevented MS would have been if there were patents on Kerberos.

How would the Oracle lawsuit change anything? Protocols are almost explicitly the things that are not protected by copyright. The problem is, people here are confusing interfaces in human-readable code (copyright-eligible) with interfaces for binary interoperability between systems (not eligible).

1. http://www.heise.de/newsticker/meldung/Microsoft-und-Open-So... 2. http://slashdot.org/story/00/05/02/158204/kerberos-pacs-and-... 3. http://features.slashdot.org/story/00/05/18/2015251/our-atto...

Or the zillion of extensions being made by companies on top of LLVM.

> "Embrace, extend, and extinguish", is a phrase that was used internally by Microsoft to describe its strategy for entering product categories involving widely used standards, extending those standards with proprietary capabilities, and then using those differences to disadvantage its competitors.

https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

MS did embrace and extend standards, but that is a very different thing from code.

I have long been annoyed by this canard. Yes, someone can create a piece of code, slap a GPL license on it, and charge $10,000 a copy. In the real world, that developer will make exactly $10,000, because their first user is free to share the code with the rest of the world at zero cost.

"Free as in free speech and beer, not just free beer." FTFY

In order to interpret that one sentence the way you did, you had to:

- divorce it from the context where the software was released as copyleft

- ignore that person getting wealthy must share their source code

- willfully misinterpret "don't get rich" as "get paid nothing"

- presume that money given to some charity is more of a societal good than software

- presume that that the creation of free software "counts for nothing"

But please do continue to abuse me as "incredibly" naive and/or stupid, and make comparisons to "slavery!" It might not feel like a genuine Hacker News discussion if you didn't.

Some people make software for fun, or to help others. If my software helps someone make millions, then cool, good for them. Personally, I would certainly monetize free software I made if I saw the opportunity. However, some people might already be wealthy and want to play with their kids or something instead of chasing a new startup opportunity, so they shouldn't care if someone else makes millions off of their software. You are acting very arrogant when you assume everyone's values line up with yours.

Some people code to enjoy themselves.

Let's not forget that this profession is also a hobby for many.

While the style of your comment was acidic, it still remains a psychological fact that people do not value things that are free.

One can be afraid of a perception that since "everybody can code" and "opensource is free as in ... beer? Speech? I don't care, it's free so it's basically worthless" that the intrinsic value of people who code is not that high. This is not a risk in large corps and dedicated software houses but it can create crappy management-employee dynamics in smaller orgs where code is just the enabler for the main product.

That said, it is up to the authors to decide how they feel about the fruits of their labour being used. There is nothing wrong with being generous and embracing all positive externalities - or blocking them or attempting to extract value from them for that matter.

For an ncurses-style version of zenity/kdialog, there's dialog http://linux.die.net/man/1/dialog and whiptail http://linux.die.net/man/1/whiptail .

Here's another project that attempts something similar: https://github.com/berdario/invewrapper

Here's a sortof-blog-post and some more discussion about the superiority of modifying a subshell rather than sourcing a bunch of janky shell-functions that modify your current shell: https://gist.github.com/datagrok/2199506

edit: after looking at the doc, my impression is that invewrapper seems to follow virtualenvwrapper's design more closely with a large number of subcommands with names similar to virtualenvwrapper's, most of virtualenvwrapper's options and features (except hooks and maybe some of the project stuff). I would describe the options as "comprehensive." I specifically wanted something with a dramatically simpler interface and feature set.

invewrapper also seems primarily or only intended to run a shell. I get personal use out of running arbitrary commands under vex as if it were sudo or something.

It is an improvement not to modify the current environment and couple tightly to specific shells either way, though.

One thing I do envy is the PowerShell prompt ;)

I just discovered your project, so I haven't tried it yet, but since the approach seems similar, it should work just fine on Windows (maybe with some tweaks)... and you can just add the Powershell prompt to your docs, no need to envy it :)

I agree that pew is intended as a virtualenvwrapper replacement, obviously you can get something similar to `vex env cmd` with `pew in env cmd`...

Unfortunately I've neglected a little bit the project lately: the most serious thing I want to do is rewrite the test suite, to be able to run it on windows.

Since you mention PowerShell maybe you use it quite often? I'd like to get some feedback on Windows (I added Windows support out of completeness, but I seldom use that OS), since I don't know anyone who uses pew on windows :)

BTW, I discovered some new tools to manage environments in the last year:

pyenv (I actually already knew rbenv), modules[1] and I even started to use Nix

These have not the same scope, and in fact I appreciate the latter 2 idea of using the same system to manage dependencies and versions for all different kind of tools. I don't have an opinion yet on what's the correct way to do these things so, in the meanwhile, even tools that are python-specific (like ours) have a niche to fill

[1] https://archive.fosdem.org/2014/schedule/event/hpc_devroom_e...

deliberation: https://plus.google.com/106336989542410513415/posts/avV5eL1P...

follow-up: https://plus.google.com/u/0/106336989542410513415/posts/PR4e...

debian wiki: https://wiki.debian.org/InstallingDebianOn/Thinkpad/X230/whe...

A couple weeks ago I upgraded to a Fujitsu Lifebook u904, for the 14" QHD (3200x1800) display. I was surprised at how very well it works with Linux, given how little information I could find about compatibility.

debian wiki: https://wiki.debian.org/InstallingDebianOn/Fujitsu/LifebookU...

Gnome hasn't got their act together yet around high-resolution displays so font configuration is a bit wonky but that's not a hardware incompatibility deal-breaker. Even the touch-screen works.

You mention a bulk import. Will you provide a bulk export, or will I have to keep my own backup database to avoid lock-in?

I see in your API example a bucket, a source, and a target. Would you consider a "value" field, for graphs with weighted edges? (The question is moot if I can't modify the recommendation algorithm to employ it.)

As for bulk export, yes in the sense of "download all the calculated recommendations" (perhaps you want to dump that to a local db to access that data directly, rather than rely on hitting my api every time you need something), but not "download all the data exactly as I put it in". For the most part, the data you put into my service should already exist in your own database (what products your users have purchased, what products your users elected as liking). In addition, you'll likely want to use a one-way hash to hash sources (especially if you use usernames or email addresses to uniquely identify users).

I probably won't launch with the ability to add weights to edges, although that's probably one of the first post MVP features on my todo list.

Get professional help immediately. Any/all of your reservations against doing so are misplaced.

We can't tell you what meds to take, which exercises to do, which foods to eat or avoid, or what lifestyle changes to make. Different people experience depression for different reasons, and for _no reason at all_.

See a pro.