Not only is it open source, it's free software! I am very pleasantly surprised to see that the GNU GPLv3 license has been chosen. I've been harsh on Light Table because the source was nonfree and the promise to "open source" it eventually didn't look promising or community-friendly. I expected a permissive license or an open-core strategy to monetize proprietary components and not be friendly with the free software community, but that doesn't seem to be the case here. I look forward to seeing where development goes.
I'm genuinely curious — if I understand you correctly, you consider a "permissive license" (such as BSD or MIT) to be inferior: less community-friendly, less "free". Why?
The reason I ask is because I think the opposite is the case: what you call "permissive licenses" give me freedom to do whatever I want, while GPL, especially v3, is very restrictive as to what it allows me to do.
Please, I do not want to discuss the merits of each approach, I would just like to understand the point of view, especially the seemingly conflicting uses of the words "free" and "permissive".
"Permissive" licenses like MIT and BSD literally permit you do more things with the software. In particular, it is not legal to combine GPL software with GPL-incompatible software (e.g. anything proprietary) and redistribute the result. This is why we cannot distribute a version of Julia pre-built with Intel's MKL even though we have MKL developer licenses that were generously donated by Intel. The fact that we use some GPL libraries makes the combination illegal to distribute. With permissive licenses like MIT and BSD, that isn't a problem.
In terms of choosing a license for an open source project, I think you should choose the most permissive license that will sufficiently encourage people not to make proprietary forks. The GPL was designed on the premise that it would be necessary to legally force people to contribute changes back, but the success of so many projects with MIT and BSD licenses shows this often isn't necessary. I think the choice depends on how "infrastructurey" or "producty" the project is. For projects like libraries, compilers or programming languages, it turns out that proprietary forks don't happen because of simple economics. Why would anyone pay for a forked proprietary version of a library when the original open source project is available? And if no one wants to directly pay for a forked version of some library, why would any company bother maintaining a fork when they can just contribute their improvements back and let the open source community maintain them for free?
With a self-contained product like Light Table, on the other hand, there's a very real danger that some company could come along, fork the code base, make a bunch of improvements and start selling their version. Using a viral open source license like the GPL makes this illegal, ensuring that only the original author can sell forks of the product.
tl;dr – GPLv3 is a great choice of license for Light Table because it is a product, but it's overkill for most open source projects which provide much lower level functionality.
Just to clarify - it's not illegal to sell GPL'd code, so long as you provide the source with the binary.
In fact, this is exactly what happened with Dosbox Turbo (https://play.google.com/store/apps/details?id=com.fishstix.d...). Dosbox is licensed under GPL, but here it's still being sold on Google Play. The author, fishstix, will send you the source if you've paid for the binary. This is completely legal.
> Just to clarify - it's not illegal to sell GPL'd code, so long as you provide the source with the binary.
This is, however, not much of a business model, because the customers get the code under a license that allows them to redistribute it. Your first customer could buy the binary and then start selling it on Google Play themselves or give it away to everyone. Selling GPL code is pretty much just syntactic sugar over asking for donations.
Conversely you could also argue "it's not much of a business model to sell apps on app stores, because Chinese companies will copy and resell your app".
In my experience, dealing with GPL software that was sold for $5k+ -- no one ever bothered doing so. And this was a PHP app, so it's not like distribution would be difficult for the would be pirate, nor was there any copy protection. It's just, for those sorts of products, no one ever bothered. I thought it was interesting.
I'm not sure you can really classify someone who has no right to distribute your code a 'pirate' - real pirates kill people. Your point stands, though, to be sure.
Real pirates often try as hard as possible not to kill people. Crew are usually worth more money alive. If you do kill someone, often you get fined by your captain and have to continue piracy to work off the debt.
So real pirates and music "pirates" share that it's not their goal to kill people. The latter still kill far fewer people, and the former still engage in much more violence.
Sorry, I'm just being horribly pedantic, but I suspect that music pirates kill far more people than real pirates, purely because so many people are technically music pirates, wheras the real pirates are very few in number and are also quite likely to be pirating the latest sea-shanties, so there is a lot of overlap.
Sure, to be more precise... "real pirates are disproportionately more likely to kill people by virtue of being real pirates; the same is not true of music pirates."
Well, I could guess your sentiment even though I thought it was wrong.
It just made me think of those stupid 'you wouldn't steal a car' ads before movies and I thought I'd point out that they have every legal right to re-sell GPL code if they want.
My feeling is that the fairness effect comes into play strongly with open source distribution models. People are willing to play fairly (i.e. not re-distribute source code that's probably only a google search away anyway) when the author does the same.
Frans De Waal demonstrates an experiment with Capuchin Monkeys showing this effect in action.
You can only strictly expect to sell the first copy. That's not a problem if selling the first copy covers your costs (contract work), but that can sometimes be a business model.
What happens if your software haves 2 binaries that talk to each other and one of them contains the GPL'd code; can I just give the code for that one or do I have to release the source of both?
Sooner or later, laws will get interpreted by a judge/jury. You question is equal to asking at what point a work should be considered a derivative work.
The answer is sadly quite blurry, and country specific. US law say something like: "A “derivative work” is a work based upon one or more preexisting works, such as ... abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted."
What would a judge say about two separate programs that talk to each other? A lot of people and companies has their opinion about it, but there is not much of case law in existence. All one can say is that the GPL author does not consider IPC level of communication to trigger a derivative work.
I was pondering what the key psychological difference between "product" and "infrastructure" is – why are people willing to pay for one and not for the other? I'm not sure, but I think that for products polish is paramount, whereas for infrastructure, maintainability is paramount. Proprietary software is a nightmare for installation, deployability and maintenance, whereas open source is great. This is why open source has won the hearts and minds of people who build and deploy websites and other computing systems everywhere while companies producing polished products still rule the desktop.
> The GPL was designed on the premise that it would be necessary to legally force people to contribute changes back
This is the rationale Linus gives for using GPL: Wanting to let people use your stuff while requiring them to give you access to any modifications. However, Richard Stallman (who wrote the GPL) has been very explicit that it is not the premise behind the license and that he disagrees with Linus on that point.
The premise behind GPL is to promote freedom[1]. In short, to ensure that the user always has complete control over the software they run. GPL ensures these freedoms, while permissive licenses that allow distribution of derivative binaries without sources do not.
The argument that software that you're not allowed to use in certain ways is somehow more free just doesn't pass the sniff test for me. RMS's rationale is very much an "ends justify the means" argument: it takes away immediate freedoms to promote freedom at large. My point is that for many kinds of software the means of imposing legal restrictions simply isn't necessary to achieve the same ends – the freedom of the software maintains itself just fine for technical rather than legal reasons.
Well, the way I understand RMS's fomulation of the 4 basic freedoms is that the right to keep your code secret is a freedom of the individual, not of the software, because no one can enjoy software that they couldn't have had if that right hadn't been granted. On the other hand, removing this right "frees" the software. You see, the FSF is all about "free software", not free people. Only indirectly do the people benefit from the software being free.
More practically, history has shown us that the GPL is necessary in order to ensure that companies don't short the community, suddenly improve everything and leave us with 99% of people using the proprietary fork. To illustrate my point, the clearest example (and the only large one) is the free distributions of BSD, mainly used by companies developing proprietary forks for it and contributing back very little. On the other side is Linux, used by companies for its freedom, security and reliability. The companies using it contribute back because they have to, continually making it stronger and always remaining free (unlike BSD, which can have many proprietary and untrusted libraries which cannot be used with security or reliability in mind). Linux is therefore getting larger only thanks to the GPL and its strong enforcement.
And this example can be applied to the entire copyleft vs permissive license debate, showing how software being free benefits the people more than people being free.
While it doesn't really changes the conclusions, you're a bit off the mark.
The FSF is about free people. Free software is just a mean, and they will use whatever licenses they think promotes freedom the most. That's why the GNU C standard library is in LGPL: the GPL itself would have prevented GCC from becoming popular, resulting in less freedom for the people. Also, looking at the history of GCC and the Hurd kernel, you can see they don't limit themselves to licenses.
You seem to imply that the GPL forbids you to keep your code secret. It doesn't. The right for private modification is preserved by the GPL. Only public modifications must be distributed in source form.
Companies don't contribute back to Linux because they have to. First, it's often more cost-effective to push changes upstream than maintaining them yourself. Second, monetizing private changes with GPL software is very very hard when the main distribution channel is gratis. Third people like to be good citizen. If I do changes for my company, and my company cannot possibly monetize the secrecy of those changes, why not contribute back?
If people and companies were forced to contribute back changes, they probably wouldn't use the software in the first place.
Now yeah, Linux is indeed larger than BSD thanks to the GPL.
RMS's rationale is to protect the freedoms of the end users of the software: The freedom to run the software however you want, the freedom to modify the software however you want and the freedom to distribute your modifications of the software to whoever you want. The rationale is to ensure all users of GPL software have those freedoms.
The only restriction is that you cannot remove any of those freedoms from any users of your derivative works. That restriction is enforced by the license.
For example, if you create a derivative work, as long as you keep using it only yourself, you're not required to give the sources to your modifications to anyone (you are the only one using it and you have all the freedoms). However, if you wish to share your derivative work with someone else (which you always have the freedom to do), you cannot limit that user's freedoms. You cannot, for example, refuse to give them the source code because it would take away the user's freedom to modify the software. You also cannot attach a proprietary license that would remove the user's freedom to distribute copies of the software to whoever they want.
GPL ensures that your fork's users get the same freedom to use the software that you get from the original/base... If you don't like the license, don't use it. There are plenty of people that don't use any commercial software if they can avoid it.
> GPL ensures that your fork's users get the same freedom to use the software that you get from the original/base...
That phrasing presumes that the existence of a fork is not determined by the license terms.
GPL guarantees that the would-be users of a fork that would have been made by someone not interested in (or able to, because of conflicting requirements necessary to actually produce the fork in question) providing Free software on the particular terms in the version of the GPL used by the particular upstream provider on which the putative fork would depend get nothing at all.
I guess you didn't read my post higher up. You cannot redistribute software that uses both GPL libraries and proprietary libraries. This is not an academic concern: we cannot distribute Julia with Intel's MKL even though we have developer licenses because we also use some GPL libraries (readline, FFTW) – the result would have to be GPL but we cannot provide the source for MKL because we don't have it. Lots of people would be very happy if they could download Julia and just flip a switch to choose between OpenBLAS and MKL; we can technically do that but we can't legally do it because of the GPL.
There is a way: acquire a GPL licensed copy of MKL.
Okay, you can't. Well, this is a textbook example of the GPL discouraging people from distributing proprietary software, and seeking free alternatives instead. This is its exact purpose.
I feel somewhat sorry for you, but this looks like a net win.
In the case of GPLv3, the development of software for hardware devices that are tamperproofed -- unless those devices are intended for "business" rather than "consumer" markets. [1]
The GPLv3 restricts the features of products made with software licensed under it based on how the products are intended to be used.
[1] "business" and "consumer" are rough descriptions, the actual definitions are more complicated and are contained in the GPLv3.
In the case of GPLv3, the development of software for hardware devices that are tamperproofed
This is not true. All the GPLv3 requires is for you to provide the means to modify or replace the software contained in the device. In the case of a tamper-proof device, this would entail providing the user with a master key or password which would allow her to unlock a developer mode of some kind.
Alternative, a tamperproofed device can be immune to any form of modification or replacement of the software contained in the device.
The issue GPL fixes is when device manufacturers exercise ownership control of the device after sale (ie, do things that the owner is not allowed/enabled to do). If the manufacturers can modify or replace the software, then the device owner must be able to do the same.
Alternative, a tamperproofed device can be immune to any form of modification or replacement of the software contained in the device.
Sure, you can develop one of those, as long as you subsequently provide a means to circumvent the tamper-proof mechanism. There is a critical semantic distinction that I think a lot of people are missing: the GPL does not restrict your ability to develop any sort of product you wish, it merely imposes additional obligations designed to ensure your users have the same freedom of development that you had when you developed the device.
> Sure, you can develop one of those, as long as you subsequently provide a means to circumvent the tamper-proof mechanism
No, you do not need to add a way to circumvent the tamper-proof mechanism. Thats the whole point of my comment.
Section 6, Conveying Non-Source Forms:
"this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM)."
If the device is completely immune to software modifications, the anti-drm requirement of GPLv3 won't come into effect.
Last, a device which the manufacturer has ability to tamper with is not a device I would call tamper-proof. The attacker just need to get the developer key, so maybe Tamper-resistant is a better description?
If the device is completely immune to software modifications, the anti-drm requirement of GPLv3 won't come into effect.
Right, I had forgotten that. The reasoning behind it is that a non-programmable ROM chip might just as well be considered hardware for the purposes of programmability. Of course, the user might decap the chip and modify the code stored there with a scanning-tunneling microscope so the term tamper-proof in the absolute sense is probably not applicable to any device made by humans.
There is an old saying in computer security that the only secure program is one that is in a computer that is turned off, locked inside a safe, located in a bunker.
So maybe tamper-proof is not the best term, but at least physical security add something more than just a digital signature. The device owner has a much better chance to see if someone took apart the device, decapped the chip and then put it together. If I as the consumer want a tamper-proof device, I would go with physical security every time.
> The argument that software that you're not allowed to use in certain ways is somehow more free just doesn't pass the sniff test for me.
Intuition. If I may, you should learn to "shut up and multiply"[1]. The various costs and benefits (in terms of freedom) are pretty much nailed down: freedom at large is simply way bigger than immediate freedoms, for a simple reason: the only freedom the GPL doesn't give you, is the freedom to further restrict your users. (Contrary to how most comments are worded here,, you don't have to contribute back changes. You have to contribute back public changes.)
The end doesn't always justify the means, but sometimes it does.
Even that isn't strictly true - you only have to contribute forward public changes. Of course, since your users have the ability to share things, and since your changes are probably "out there" you might as well contribute them back at that point and doing so usually eases development.
> ensuring that only the original author can sell forks of the product
I consider this the absolutely worst reason to use the GPL. Quite a few companies (large companies like MySQL/now Oracle or small ones like Macromates) require contributors to sign an agreement that allows the company to distribute the code under a different, proprietary license.
Doesn't this circumvent everything the GPL stands for? If I contribute to such a project, what guarantee do I have that the owner doesn't just distribute the software, including my contributions, under a proprietary license and stops making improvements public?
Why would it be ok to take non-copyleft software like clang and make proprietary forks with it, but not ok to sell exceptions in order to fund copyleft software?
EDIT: As an Octave developer, I greatly respect how FFTW's copyleft is used, for example. Matlab buys a license exception to use FFTW. Octave gets FFTW under the terms of the GPLv3, just like Octave itself, which we in turn contribute back to everyone else. Matlab and Octave are both using the exact same library for Fourier tranforms.
I like this model. Everyone is paying one way or another, no freeloaders, just lots of freedom.
Thanks for the link, those were some good thoughts on the topic. However, I disagree with Stallman. (probably because I make a living from selling something that he might call a 'proprietary extensions')
I think the problem I have with the practice of selling exceptions is that it gives more rights to the owner. I feel that open source licenses should give equal rights to everyone. Dual licenses undermine that equality. I understand that people want to stay in control of their software, but for me the words 'free' and 'open' somehow imply 'equal rights for everyone'.
But they provide no hard incentive for someone to pay in order to benefit non-freely from free software. I prefer to attack the problem from the point of view of figuring out what proper revenue sharing would be with copyright assignments. What the MIT guys are doing with FFTW is doing is good. What Oracle is doing with MySQL and Virtualbox is bad.
I'll ask the FFTW guys what do they do about external contributions.
Also, thinking about it more, there is nothing wrong with copyright holders having extra rights as long as they do not use these rights abusively. After all, they did the work, so they deserve to be compensated for it. Nobody would dispute that. It is problematic if they use these extra rights to try to make people pay for proprietary software that is not otherwise available freely. This is what I dislike about what Oracle does.
> After all, they did the work, so they deserve to be compensated for it.
The problem is that many Open Source projects aren't created by an individual, or even a single company. Large projects have hundreds of contributors. If a project requires copyright assignment, all these contributors have fewer rights than the maintainer of the project.
If a project doesn't require coypright assignment, and uses a single license, all contributors have equal rights to the collective work.
> The problem is that many Open Source projects aren't created by an individual, or even a single company. Large projects have hundreds of contributors.
It's some sort of empirical law that almost all of the code in free projects is written by at most a handful of all contributors. If this law holds, and I can think of only few examples where it doesn't, it seem fair for the tiny minority to benefit the most from selling exceptions.
What the FSF does when requesting copyright is a two-way agreement. The FSF drafts a contract that promises that they will never use the copyright aassignment for creating non-free software. Similar contracts could be drafted that agree to share revenue proportionally and provides clauses for arbitration if this proportion is in dispute.
> If I contribute to such a project, what guarantee do I have that the owner doesn't just distribute the software, including my contributions, under a proprietary license and stops making improvements public?
None. But if they do that then you can fork the latest free release and carry on improving that (e.g. OpenOffice -> LibreOffice), and from then on the company's version receives no more contributions from the community.
And it's unambiguously better for the principles of the GPL than the alternative of licensing the project under a BSD-style license and requiring contributions to be made under such a license, which allows not only the original maintainer but anybody whatsoever to do the thing you're objecting to.
I didn't mean to imply that it was a good thing that the original author could sell forks but rather that it was better that only the original author(s) could. This is one of the reasons I'm not fond of CLAs (contributor license agreements) and why Julia doesn't have one – the code belongs to the whoever wrote it and we can't relicense their contributions any more than they can relicense ours.
You don't. And that's why people stop contributing to such projects and forks are created (see MariaDB). But that's not really a fault of the GPL. You could require contributors to agree to whatever you want regardless of the license you choose. Contributing to proprietary software (often as a result of an employment) sure comes with requirements other than the code itself.
It's not a particularly good one unless a static linking exception is included (dylibs on OS X are a pain for no serious benefit, it's not viable at all on Android or iOS).
LGPL is just fine in this regard – you can ship with and link against an LGPL library together with proprietary libraries because the combined result need not be under the LGPL. Whether you link dynamically or statically is irrelevant from a legal perspective.
The parent poster is talking about static linking against a third-party LGPL library, not your own library. In such a case, failing to provide the complete source code, or the original compilation dependencies (.o, .a, .so) and the build chain, is very much against the LGPL.
There is a massive reluctance in the QT community over this currently -- people want to distribute single-binary applications, and they are told to be careful about doing it.
Except that's not actually true. See, the point of the LGPL is not just that the user has access to the source, but that the user can modify the source and run it. Dynamic linking allows the user this freedom. Static linking generally does not, so unless you provide a way for users to delink your binary then you have to distribute the entire binary as LGPL.
Not the OP, but: the GPL is more restrictive, in that you are not free to reduce the software freedom of some other person (say, by turning it into a proprietary product). This is the perspective that considers GPL more 'free': though the software itself is more restricted, the freedom of all of the users of the software is protected.
Not everyone agrees with this position (I also am not interested in arguing about it) but this is my explanation of this point of view.
> Not the OP, but: the GPL is more restrictive, in that you are not free to reduce the software freedom of some other person (say, by turning it into a proprietary product).
No one's software freedom is reduced if I release a closed source derivative of a permissively-licensed open source product. All the rights that existed to the originally permissively-licensed product are intact.
Speaking as a user of commercial software, and speaking as someone who prefers to enforce no copyright whatsoever over the code that he writes: STOP IT.
Stop this condescending, paternalistic treating me like an imbecile who can't make informed decisions about what kind of software to use. Stop acting like you can decide for me what rights I do and do not wish to exercise. Stop acting like the freedoms I want to have, including the freedom to enter into a lawful contract with a provider of proprietary software, don't count because they don't correspond with your values. Stop preaching that my entire system for deciding what software I do and do not want to install on my own computer is wrong because it doesn't match up with your ideology. Just stop being such a @$%^! ideologically-motivated authoritarian. And most of all, stop pretending that your authoritarianism is somehow defending my liberties.
I've got no problem with the GPL. If you want to maintain some sort of legal control over how others are allowed to use intellectual property that you create, you've every right to do so. That goes for releasing the source code with limitations on incorporating it into proprietary software every bit as much as it does for keeping it all proprietary in the first place. What I do have a problem with is you trying to tell me that I'm doing something wrong by choosing to be less controlling about the code I create. And what I have a problem with is you trying to tell me that my choice to place no restrictions whatsoever on what people do with the code I share is somehow stomping on somebody's rights. That includes allowing third parties to incorporate it into proprietary software. If you're uninterested in using that proprietary software, fine, it makes no difference to you whether the software existed or not. OTOH, people who are willing to pay for a proprietary modification might benefit from one existing, and in that case, more power to them - I don't care, and I don't see why 4th parties who don't have any basis for claiming ownership of the software should care.
You made a false claim. Your choice of a closed-source license means no one can make derivatives of your work; if you had chosen a permissive license, your users would have greater software freedom. Hence, someone's software freedom is impeded.
Your ad hominem, however, is misdirected. I too oppose FSF's mission to value our craft at $0.00/hour. People have the right to compensation when others enjoy their creative output and if that impedes software freedom, so be it. Software freedom is a good thing but by no means an inalienable right.
I support open source because it's in our collective interests to subsidize the creation of freely available and high-quality platforms/tools with our earnings from proprietary software. I don't think we'd have those earnings without proprietary software, though.
Some people point to the Red Hat model. But most people don't need those kinds of guarantees. Third parties (i.e. every system administrator who's ever been responsible for at least one CentOS box and is not a Red Hat employee) can provide good enough support for drastically cheaper because they don't have the extra costs associated with developing the product.
Without proprietary software, it is in no one's interest to make software. (Well, maybe for personal amusement.) Not even line-of-business software, because you're just handing your competitors the ability to undercut your prices and push you out of the market (similar productivity boost, lower costs than you).
Nobody's freedom is impeded. They didn't have the freedom to modify the code in the first place, since they didn't have the source code. Nothing they could do before has been taken away.
It's really intellectually dishonest to use this freedom and morality rhetoric when you're actually talking about compelling people to give away something they have created.
Not that I think it's conceptually a bad idea. I see nothing wrong with the idea of the GPL as a concept. A contract that says 'if you use this software, you agree to also give away any code you base on it' seems fine.
But I see no reason not to just call it 'permanenrly malleable' software or something like that.
It's the faulty rhetoric around freedom that is presented as a moral crusade that is a problem.
There's no intellectual dishonesty here, just a semantic mismatch. You're using the negative definition of freedom, which is the lack of explicit restrictions on behavior; the logic you expose only holds under that particular school of thought.
The GPL is instead defined on the tradition of positive liberty, which defines freedom as the number of options freely available to each person to choose. There's a very real risk of those being reduced by permissive licenses, as you can no longer ignore network effects, as negative freedom (being defined over individual atomic actions) does.
History shows us that if you allow open source code to be relicensed as proprietary, the competitive advantage of companies building and selling products with enhanced features tend to displace the original project, which gets abandoned. This happened to Unix, to Mac OS X, and is now happening to Android. If this continues for an extended time, the whole ecosystem evolves and the old software becomes unusable, greatly reducing the total options that users can effectively perform - not by an legal or coercive restriction, but because of pragmatic impossibility. There are permissive projects where this doesn't happen (at least for a while) because of the economic incentives of remaining close to the free+open project, but the risk is always there.
What good is the permission to run the original, abandoned version of a software project if all the available hardware has been locked and is uncapable of running it, and it's impossible to modify it to support the modern functions that are available in the proprietary platform and required for any productive usage? Those are very real threaths, and the GPL was designed to combat them (as a reaction to the first time they happened on a large scale). Avoiding this "reduced total available options" scenario is what GPL projects call freedom, not "reducing the number of restrictions" definition that you use. Not a problem of rhetoric, but of chosen vocabulary.
I don't use a 'reducing number of restrictions' definition. That's a straw man that I was responding to.
I also don't accept "history shows us" as establishing some law of nature when the history we're talking about is a couple of decades.
I think the abandoning of ecosystems can just as easily be explained by them being based on inadequate foundations, than by a mythical horde of developers somehow being prevented from working on them. Usually systems are abandoned because of a lack of economic incentive, after all the displacement you describe can only happen if proprietary development produces enhancements more efficiently than open source. Witness the failure of the Linux desktop.
I think 'greatly reducing the total options that users can effectively perform' is a statement that needs much more qualification. To me, that's a function of design, extensibility, and how much leverage a system provides, and is independent of whether the source is available or not. Extending by forking is a last resort.
Nevertheless, I do respect the hypothesis that a GPL style open system provides an important counterbalance to proprietary systems.
What I do not support is the dishonest use of language and morality to further it.
If you are using positive freedom, then there is much more to be gained through improvements in software design - e.g. along the lines of Alan Kay's FONC - to increase leverage - than through ideology.
We are talking of UNIX here. It has not been abandoned as an unsuccessful ecosystem, it has been rewritten away from the legalistic minefield that its permissive licensing allowed it to be; and that ''did'' prevent developers from freely working on it, and business from freely deploying it despite its open source origins. The history we've watched is that of Linux and GNU on the server (UNIX didn't have any strong desktop environment to begin with); and the UNIX wars span nearly 40 years, with Linux being the last half of it.
I still fail to see what is it that you call dishonest use of language. If freely talking of one's perspective and goals is dishonest, then all ideologies are.
Except that FreeBSD is just as freely deployable without the need for the GPL, so it is not the GPL that causes this property to come about.
The dishonest use of language is the misappropriation of the word 'freedom', and the moralizing around what is essentially a business problem. But, if you are claiming to be an ideologue, then fair enough.
In which case, I'd love to hear more about how that ideology translates into a better future economic future for software developers. To me it seems to just translate into greater dependence on powerful corporations.
Someone switches to your product, or a new user chooses your product over the open-source alternative. The proportion of people who can modify their software decreases. That is a decrease in software freedom.
Not necessarily a bad thing (your product might be legitimately better), but it is a decrease in software freedom.
Freedom hasn't decreased at all. Those people have exactly the same choices as before. They can use the open-source alternative if they want to change the code. Merely 'using' a closed source product doesn't prohibit them from doing that.
Lots of people who would otherwise be Linux or BSD users instead use OSX. Consequently, they are not free to modify their operating systems where (had it not been for Apple) they would have been. Their freedom has been reduced voluntarily, but it has been reduced.
Forking FreeBSD is not remotely the same thing as forking OSX and you can't "just use the open-source alternative if they want to change the source code" of OSX.
Their freedom has not been reduced, as they are still free to choose an alternate, FOSS operating system if they prefer. Instead, they have access to more options than they otherwise would have, because it's highly unlikely that Apple would have expended so much effort in improving their OS, which is a competitive advantage for them, if they were forced to turn over all of that work to anyone who wanted it.
I really don't like the idea of licences which compel their users to act in a certain way. Freedom cuts both ways.
Software freedom has a specific meaning which necessarily encompasses freedom to study and modify the software you're running.
OSX users do not have this freedom. Hence, prevalence of OSX reduces software freedom. Ability to choose between OSX and alternatives is something but it is not software freedom.
> OSX users do not have this freedom. Hence, prevalence of OSX reduces software freedom.
This doesn't follow. Like most arguments about proprietary software reducing, rather than not providing, software freedom, it seems to rest on the assumption that if proprietary software did not exist, it would be replaced use-for-use with Free software, that is, that license models have no impact on the creation or distribution of software.
That's why this rhetoric is dishonest. It's the use of this specialist meaning of the word freedom in a way which is opposite to it's conventional meaning.
If you stop using this misleading word, the whole GPL thing looks more reasonable, but also less like a moral crusade.
Not really. Freedom to modify your software is a kind of freedom which cannot exist when you are exercising your freedom to use proprietary software. Like many things in our world, it's a tradeoff.
That seems like a narrow definition of software freedom , but in that case I'd argue that the utility gained from software freedom is not as valuable to users as the incentive gained by developers for being able to distribute their software under a more permissive licence.
If such an amount of software is being produced under the GPL that inability to borrow from that pool of work is significantly hampering proprietary development, I'd say it's plainly false that this is the only way to incentivize software development and quite possibly the case that it's not the best way.
You removed my qualification, attributed the result to me, and called it an absolute position. I would not make, with confidence, the statement "There is never a need to release under a more permissive license." To get there from what I said, you would need "There is never a need to distribute under a less permissive license." I do think this need is exaggerated, but labeling that "absolutist" strikes me as odd.
I have no objection to "paid software" as a business model, because the term is too broad. Paying someone to add a feature I want to a GPL project and release the result is, I think, not something anyone would object to. I have objection to "proprietary software" as a business model, because it collapses the value that the software can provide; I am not convinced that this objection is sufficient to say that proprietary software is always the wrong choice. I have more objection to proprietary software where, having paid, I cannot see the source and make changes (or pay others to make changes).
There are a number of alternatives for funding development of mass-market software that are more compatible with copyleft licenses (donations, threshold pledge models, consulting) and I'm currently working on an innovative project in this space.
Freedom has still not been reduced. This so-called gain in freedom of OSX users to modify the code has come at the expense of a corresponding loss of freedom of Apple to choose whether to release their code or not.
I make software, and I do not want people who use it, share it, or modify it to be under the threat of being sued. Legal violence is to me is near equal to physical violence, and thus a moral issue.
I do also not care if the legal violence happened because of changes an other developer did on my work. Just because they added something does not give them the right to use what I made into a legal weapon.
"I too oppose FSF's mission to value our craft at $0.00/hour."
Eliminating the revenue from selling the same work multiple times is probable consequence of the FSF's mission. It is uncharitable to say that it is the FSF's mission. It is also false that this implies an hourly rate of $0.00 - there is a huge amount of programming work for which the first copy is the only copy, and that can be sold just as readily as ever in a world using even the strictest AGPL for everything. And that's not even considering donations, threshold pledge systems, &c.
Stallman advocates for a utopia in which software is developed by the masses for enjoyment and individual utility.
Programmers are expected to work other jobs to subsidize their hobby. IIRC he also suggested that they could sell copies of their software on physical media, but this is irrelevant in the bittorrent era.
He acknowledges that realization of the FSF's goals would most likely end the phenomenon of professional developers and is perfectly okay with this.
It's somewhere on the Philosophy section of the gnu project's website. It's late, but I'll find the specific link later.
I'm both a user and a developer of commercial software, and I would like for you to apologize for speaking as if you represented anyone other than yourself in this ignorant and hateful screed.
And the author of that software doesn't need to use software that is GPL if they want to create a commercial product... they can use more permissive software (MIT etc), license commercial libraries, or write their own.
Yup. . . and as others have pointed out, there are some very good reasons why it makes sense to prefer the GPL over a more permissive license for a product light Light Table. I've got no argument there; if I were in the same circumstances I might have made the same choice.
What I'm bristling at is the line of thinking that says that I would somehow be harmed if Light Table's maintainers had chosen a license that permits proprietary derivatives.
ok, so perhaps you exercise some restraint with copyright. you're making the world an easier place to live in.
however, you are not representative of the commercial world. patents/copyright mean money, and no business with rational business leadership would choose not to shutdown competitors with patent disputes if possible, let alone not licence code in a restrictive fashion (i.e closed source, not free, etc.)
regardless, this isn't just about copyright and patent disputes. it's about trust. i'm using a computer right now, and i don't trust the hardware, or even the software i'm using. i have no way of verifying that it's doing exactly what it says it's doing, and that it's not doing something that i don't want it to.
which is weird, because.. i own it.
i get into my car, and there are (probably) hundreds and thousands of lines of code between me and the wheels. but i don't know what's going on really? maybe there's something wrong with ECU's management of fuel injection. maybe there's a bug in the ABS controller.
i can't trust any of the electronic equipment that i use. that's.. pretty bizarre, given that i am employed to work on these things, don't you think?
so what purpose does the viral clause in the GPL have? it's simple really -
lets say i program.. a home automation system (one that's not just.. terrible). i've got a few raspberry pi's, some arduinos, all talking over wifi/ethernet. control of things like lights, heating, doors, the whole thing. i've got an app i run on my phone, it's looking pretty slick. the source is a bit of a hack, probable buffer over/underflows, no comments, i only have the app on my iphone.. it's not perfect, but it works. and if it doesn't, i can fix it. the literal last thing i'm thinking about (i almost forgot to write about it, in fact), is the code licence. but fuck it, i can't be bothered. MIT looks simple enough, why the hell not.
a few months later, PicoHard (c) release something amazingly similar, but with more functionality. they have android apps, more polish, they have their own custom wall sockets that switch on and off the power.. you get the idea. it's on sale for a few thousand dollars. but hey, i don't care, i can do all that if i want to. i haven't lost anything, and this company hasn't infringed on my rights.
thousands of people have installed this system now, but nobody (except maybe the original author) knows really anything about how it works.
june 2013 happens, and suddenly there is a guy on TV saying that the government have almost certainly got backdoors in my software. now thousands of peoples rights are infringed.
> Your users can't modify (and must pay for) your derivative.
Which doesn't reduce their freedom, since they couldn't modify it -- or have the choice to pay for it and use it -- before I made the proprietary derivative.
The only "reduction in freedom" is based on the assumption that I would have made and shared a Free derivative if I did not have the choice to distribute a proprietary one, rather than either not making a derivative, or making a derivative for my own use and not providing it to others.
If you make a superior, closed-source derivative and users switch to it (or new users choose it instead), the proportion of people in the world who have the ability to modify the software they're using is smaller because of you. That is a reduction in software freedom.
I'm perfectly okay with this. The abysmal UX of desktop linux is proof that profit motive is necessary to drive the development of high-quality end user software when that development is difficult and/or not sexy.
But the only assumption required is that someone uses your product instead of the free alternative. He might have higher quality software, but he does have less software freedom.
> But the only assumption required is that someone uses your product instead of the free alternative. He might have higher quality software, but he does have less software freedom.
No, he has the same software freedom -- he has the freedom to choose to use and/or modify the free version and any free derivatives people have chosen to make, and the freedom to choose to use the non-free derivative, with perhaps less freedom to modify it.
If anything, he has less freedom when the creation of non-free derivatives is prohibited.
Once he becomes locked in to the non-free platform, his is not free to modify the platform he relies on and is instead required to migrate to a completely different platform in order to make (potentially small) modifications.
By this logic, OSX is free software because I have the freedom to choose Windows instead.
I'm not advocating for the prohibition of non-free derivatives, but the position that adoption of propriety software doesn't reduce software freedom is ridiculous.
You "by this logic..." is wrong because the post you are responding to doesn't make any argument about what is a piece of "free software", it discusses what the effects on software freedom are of the exercise of rights under particular free software licenses.
Freedom is the power to make choices rather than suffer external dictates. If a particular piece of free software exists, the existence of non-free derivatives doesn't reduce anyone's freedom, as they are free to choose the free software.
This kind of ages old flame war is discouraged on Hacker News. From the guidelines: "Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them. "
The BSD vs. GPL, which is more "free" or "permissive", argument has been going on for decades and is not going to be settled in this thread.
Your trying to pour oil on untroubled waters. Discussing the rationale and pro/con for selecting a specific Open Source License for a particular project _is_ generally interesting.
I'm trying to encourage people to respect the guidelines of the site. And, I happen to strongly agree with said guidelines.
Can you not see that no one is changing anybody's minds here, and everyone who is chiming in has a fiercely held position? This is one of the classic hacker flame wars, and flame wars are a waste of everybody's time.
In short: Arguing about GPL vs BSD is a shitty thing to waste this great community on, and I felt like it was worth risking the ire of all the people who love flame wars in order to say so. The guidelines exist for a reason (and this thread is more evidence that this particular guideline is useful and relevant; if pg didn't have this particular argument in mind when he wrote it, I'd be moderately surprised).
The difference can be broadly characterized as individual vs. societal freedom. To resolve your problem with the meaning of "free", you have to think about who the intended recipients of the freedom are.
If there are no restrictions against (to pick a colorful example) letting your dog go to the toilet on the sidewalk, then individually you have more "freedom to do whatever I want", but societies work better when you can walk around without constantly stepping in dog poop.
So, the way I look at it is that the GPL attempts to build a society where total happiness is greater than in the society that gave more permissions to everyone. If you agree with the existence of laws that prevent poor behaviors, you're already sympathetic to this view in principle; it just becomes a practical question of whether the harms that the GPL is trying to avoid are serious enough for it to make it worth the trade-off with individual liberty. Reasonable people disagree about this.
> what you call "permissive licenses" give me freedom to do whatever I want, while GPL, especially v3, is very restrictive as to what it allows me to do.
A common distinction is that 'permissive licenses' give the developer more freedom, where 'free licenses' give the end user more freedom.
Giving the developer freedom allows them to constrain the freedoms of the end user, where giving the end user freedoms constrains the freedom of the developer.
So yes, if you're optimizing for your own personal freedom, a permissive license is best, but if you're optimizing for ecosystem or social freedom, a 'free' license is best.
In what way is GPLv3 'especially very restrictive as to what it allows you to do'?
It added the tivoization clause which prevents companies from selling hardware to you with GPLv3 code and not allow you to run your own modified version of the code on said hardware.
Also if you distribute GPLv3 licenced code, you grant all recepients of that code a patent grant to any patents you hold within that code.
I find these to be perfectly valid additions of what the GPL licence is for: granting and preserving end user rights.
> It added the tivoization clause which prevents companies from selling hardware to you with GPLv3 code and not allow you to run your own modified version of the code on said hardware.
That depends on who "you" are. In the FSF's view some users are permitted to want to purchase hardware that can't be tampered with, and others are not.
Please don't spout this false old lie. Its been correct a few hundred times already on HN, so how can you have missed it?
If the tamper proof hardware resist modification by everyone (including the people who produce/sell them), GPL is perfectly fine with it. Sell it, bake it, do what ever you want. However, if a producer want to sell tamper proof hardware which they exclusively have a way to tamper with, its not tamper proof and it is not fair to the person who bought it. At minimum, give the owner of the device the same right to do modifications.
If you want to quibble over the wording describing the exact combination of features the FSF is willing to allow some users the freedom to choose to have served by products with GPL-licensed software from anyone but the copyright owner, but where they would deny that freedom to other users, you are missing the point of the objection.
Is your argument that giving someone else exclusive control of things you own is a feature? I guess a thief could argue that stealing stuff from people house is a feature too.
GPL denies people to circumvent property rights of the devices owner - ie, the person who bought it. If you object to stopping such activities, I hope you don't object when people circumvent other laws.
There are three possible, reasonably coherent views of the anti-tivoization clause I can see:
1. Either the restrictions it places on device features in the consumer market are essential to software freedom, in which case GPLv3 segregates markets and prioritizes something else over essential elements of software freedom in the business market, or
2. The restrictions it places on device features in the consumer market are not essential to software freedom, and the GPLv3 segregates markets and imposes restrictions on what can be done with GPL-licensed software in ways that restrict rather than promote freedom in the consumer market.
3. Or "software freedom" means different things in different markets.
My personal view aligns more with the second of those options, but I wouldn't be happy with any of them.
> Is your argument that giving someone else exclusive control of things you own is a feature?
If it is in the business market (where the FSF seems to think it is) then it is in the consumer market.
> GPL denies people to circumvent property rights of the devices owner - ie, the person who bought it.
It would be more accurate to say, for what it defines as "User Products", that the GPLv3 actively encourages device renters to circumvent the property rights of devices' owners, and bars device owners from having the technical tools to prevent that.
1: A license that do not allow circumvention of property law is friendly to the business market. As such, your claim that it would prioritize "something" over "essential elements of software freedom" are wrong.
2: Not allowing circumvention of property law is neither promotion or restriction of freedom. It has the same purpose such as anti-theft laws. business markets depend on property law, and could not operate without it. However, selecting enforcement of property law can be exploited in the market, and a segregation between those who exploit and those who don't then happens.
3: anti-theft laws and "software freedom" are not directly related. This is where the confusion comes from.
> It would be more accurate to say, for what it defines as "User Products", that the GPLv3 actively encourages device renters to circumvent the property rights of devices' owners, and bars device owners from having the technical tools to prevent that.
You seem to imply that manufacturer are the device owner after they have sold the device. Here we must come to a disagreement, as I follow the classic view that a trade results in a change in ownership. The financial transaction causes the manufacturer to assign ownership of a specific device over to the buyer in exchange for money. The new owner of the device is thus no longer the manufacturer, but the person who paid money for it.
Maybe the wikipedia article, or a dictonary would help you here. Renting is not the same as a trade. I can see how you might get those two words confused, but really, they are not the same thing.
If device manufacturers want lease out devices rather then trade them, they can likely do so without having comply with the requirements in the GPLv3 license. Leasing out devices is commonly not viewed as distribution (case law lacking).
> You seem to imply that manufacturer are the device owner after they have sold the device.
No, that's irrelevant.
> If device manufacturers want lease out devices rather then trade them, they can likely do so without having comply with the requirements in the GPLv3 license.
The anti-tivoization clause specifically applies to transfer of a "User Product" with the right to possession and use of the device either permanently (sale) or for a period of time (rental).
With both "free" and "permissive" licenses, everyone who gets code from the original author can use the code for pretty much whatever they want—boil it, mash it, stick it in a stew—but for code under a "permissive" licence, downstream recipients do not necessarily have the same rights. For example, Microsoft used some of the BSD sockets implementation in NT's network stack, but Windows users do not have the same rights of modification and redistribution for that code that Microsoft enjoyed, even if they separately obtain a permissive licence to that code by downloading a fresh copy of the code from the original authors.
Thus, "permissive" licenses tend to split a community into at least two groups: developers who can make use of the original code directly and enjoy the liberties the "permissive" licence allows, and users who are only allowed to use the things the developers create for them, and have none of the liberties granted by the original licence. By contrast, a "Free" licence (in the FSF sense) guarantees that everybody who obtains some piece of code, no matter how far removed from the original developer, has exactly the same rights to it. Thus, it does not split the community in the same way, and that's why some people regard "Free" licences as more community-friendly and useful than "permissive" licences.
>but Windows users do not have the same rights of modification and redistribution for that code that Microsoft enjoyed, even if they separately obtain a permissive licence to that code by downloading a fresh copy of the code from the original authors.
Yes they do. They have exactly the same rights microsoft enjoyed, over the exact same code microsoft enjoyed those rights. They don't have the rights to microsofts code, which is a completely different thing.
I'm sorry, I may be misunderstanding what you're asking, but it seems you're asking about the old GPL vs. BSD/Apache/whatever, free software vs. open source software. If I'm misunderstanding you, I apologize.
[1] explains the difference. Why is a BSD license not free but the GPL is? Because a BSD type license allows you to take software and turn it into non-free software. IOW, you could take BSD software, base your new software on that software and not release your changes or your source code.
I'm not imparting morality here, just trying to explain to you the difference between BSD and GPL and why some consider BSD to be not free.
GPL ensures that any derivatives will also remain open source, permissive licencing permits proprietary derivatives.
The benefits of GPL when it comes to derivatives is that all the code will remain open, so if someone forks project A into B and make changes, project A can incorporate those changes or maybe everyone jumps onto project B, and perhaps someone will later combine project A and project B into forked project C, etc.
Either way the source code of all derivatives remain open.
With permissive licencing there is the option of proprietary forks, which means that nothing ensures that any changes made in a proprietary derivative will ever reach the open project. That doesn't mean that no code will be contributed back, but again there's nothing saying it will.
> Because a BSD type license allows you to take software and turn it into non-free software.
No, it doesn't. A BSD-type license doesn't let a third party make the software anything but BSD-licensed software. It does let them distribute derivatives under different licenses, but that doesn't change anything about the original.
I apologize, I should have said it allows you to turn a derivative work into non-free software. The link explains what is really meant (note that it isn't my opinion here).
I thought you got this backwards, then I realized that it depends on how you classify "developer" and "user".
I think of "user" as someone who downloads the licensed software and uses it. And "developer" I associate with whoever wrote the licensed software that was downloaded.
Based on this definition, GPL gives more right to the developer, and less rights to the user. The user can't create derivative works from it and distribute it without also releasing the source code. This is a restriction that affects the use of the code by someone who downloaded it. Any derivatives are contributed back, giving the developer the right to integrate it to the original.
Just for the record, the FSF considers software licensed under permissive licenses to be "free software" (assuming no patent issues). The worry is that future modifications may not remain free software.
I’m not the parent, but is it possible he’s referring to the restrictions on derivative software?
If someone develops something amazing based off of LightTable with LightTable on GPL, aren’t they required to release that something on GPL as well? I believe under MIT derivative products can be created for commercial purposes (please correct me if I’m wrong!).
Yes, wonderful news! A GPLv3 release of all code far surpasses my expectations, and I've griped about the lack of a source release in the past, so I think I owe the devs a public apology here. Sorry for doubting you!
I do have a question about the licensing -- will you be requiring copyright on code contributions to be assigned to you?
If not, you can't then sell those contributions outside of the terms of GPLv3, because you have to own them before you can relicense them, or obtain the owner's permission.
(If so, it's a little distasteful for the people contributing to know that their code is being used to make money for other people and they won't receive any of it.)
Is it really that distasteful? I think it's a beautiful scheme, it allows the code to be free and obligatory open source, so a true contribution, whilst the possibility for the project leader to make money remains open.
You can always fork the project, put your own branding on it and make money off your contributions still :) It's just not possible to make money under their brand, or in a closed source product.
It's a good question. Today, I definitely agree with you that the Light Table team has given far more to the world than the world has given back to them, so it seems like a very fair trade. But in a few years, we could imagine that the majority of contributions come donated for free from volunteers. Would it still be fair then?
> You can always fork the project, put your own branding on it and make money off your contributions still :) It's just not possible to make money under their brand.
This doesn't sound right. You'd be forbidden from selling non-GPLv3 access to any of the existing code, even under a new brand, and any plugins that you created would either be GPLv3, or not distributable at all.
> This doesn't sound right. You'd be forbidden from selling non-GPLv3 access to any of the existing code, even under a new brand, and any plugins that you created would either be GPLv3, or not distributable at all.
You can definitely sell GPLv3 software. As long as the source is available and you abide by the terms of the licence.
I know that -- that's why I said "selling non-GPLv3 access". The point is that the LT devs can do something with your contributions (sell them under non-GPLv3 for money as part of a non-GPLv3 Light Table) that you can't, and it's reasonable that some would find this distasteful.
Unless you do a copyright assignment to them, they couldn't sell your GPL3 contributions under a non-GPLv3 license. It wouldn't just be distasteful, but would be against the license.
They actually can't, since your contributions have to be GPLv3 and thus their inclusion of your code has to be as well. The entire point of the GPL is to prevent what you're suggesting.
That is true, if the LT team doesn't require a copyright assignment by all contributors (or similar). If they do, they can relicense it. That's the question being discussed.
> This doesn't sound right. You'd be forbidden from selling non-GPLv3 access to any of the existing code, even under a new brand, and any plugins that you created would either be GPLv3, or not distributable at all.
Yes sorry, I realised my omission and edited my post just before you commented. You are right that you wouldn't be able to sell your code under a different license than GPLv3, whilst the person you signed the copyright to would.
> But in a few years, we could imagine that the majority of contributions come donated for free from volunteers. Would it still be fair then?
I would hope that by that time, all significant contributions would be in the form of plugins, which are not required to be GPLv3 as far as I'm aware, or even require a sign away of copyright. The question would then be, do you want to sell your plugin through their system, or distribute it on your own.
I disagree that it's distasteful. It's only distasteful if it's dishonest or coercive. I think it's actually a great way to fund a Free Software project. It's like github. You pay nothing, and everything is public. You pay for privacy. With the GPL and selling exceptions, it's very similar in spirit. You pay nothing, and you must give back. You pay something, and you may restrict your users.
If someone contributes code and licenses their copyright to LightTable, knowing full well that the product they support and invested time in may acquire some funds because of it, gosh, I just don't see how that's a bad thing. And if they believe that their patch is significant enough to demand reimbursement, that they would like to charge LightTable for a copyright license, they are free to negotiate such a trade. And if LightTable actually makes money from relicensing, they'll probably be happy to pay for such things.
I do, however, hope that they ask for copyright licenses rather than copyright assignment. Copyright assignment turns the author into a person powerless to use their own work. See harmonyagreements.org.
If you think it's that distasteful just don't contribute. There are a lot of things in the world one can find "distasteful" where the simple solution is to avoid it. How is this even a concern? (I know you put it in parentheses, but still).
It might be useful to the people releasing code if how they are doing it is alienating some set of people.
Perhaps they are not aware of this and it matters to them; this makes it useful information.
If they don't care (or care but have other, more compelling reasons, for their choices) then fine. But at least they can make a more informed decision.
A copyleft license is actually more conductive to Open Core development because it allows the copyright holder to reserve the right to create proprietary addons while shutting the community out of that option [1]. Not trying to insinuate that Light Table specifically is going to do this, but the option is still available.
This whole license flame war you've started is entirely unhelpful, and totally orthogonal to what you actually care about.
If parts of the code remain proprietary then this is Open Core and if they don't, it isn't. The licence doesn't enter into it.
Remember, the copyright holder is not bound by the GPL. And in this case external contributors are required to sign the Apache CLA[1]. So it is a permissive project as far as the original developers are concerned, and copyleft for everyone else. This is exactly the kind of situation that often leads to Open Core-like projects and proprietary vendor forks down the track, and is in no sense better for the user than if the code was permissively licensed for everyone.
[1] https://github.com/LightTable/LightTable/blob/master/CONTRIB...
BTW if the developers are reading, I find that description oversimplistic to the point of dishonesty. It is very unexpected that a GPL project would accept only Apache-licensed contributions, and your summary of the CA offers no hint that the developer is about to agree to it.
I expected a permissive license or an open-core strategy to monetize proprietary components and not be friendly with the free software community, but that doesn't seem to be the case here.
So you don't consider a permissive license to be friendly with the free software community, or is that a typo?
As a game developer, you're hurting our entire industry by shutting us out of using your software. And in the end, we'll find a way, with or without you. We'd rather stand with you, but we can't go near GPL'd code.
You know CodeCombat recently open sourced their game? They're basically the first gamedev company in the history of gamedev to do that -- a non-indie company who open sourced their current-gen tech. It's a good idea, and I hope more companies follow. So, times are changing, but in the meantime your strict adherence to "GPL license == good guys; MIT license == bad guys" is detrimental to pretty much an entire community of programmers. (Programmers with zero options; they're not going to ragequit the gamedev industry just because engines are closed source.)
> As a game developer, you're hurting our entire industry by shutting us out of using your software. And in the end, we'll find a way, with or without you. We'd rather stand with you, but we can't go near GPL'd code.
Poor you. The game industry _chooses_ not to go near GPL'd code because they want to sell proprietary software. Counteracting the existence of companies doing proprietary software is the very reason why the free software movement was started in the first place.
Yes, the free software movement is supposed to be detrimental to the developers of proprietary software and has no incentive to cater to their needs. Do you think we want to make Windows or iOS a more attractive platform? Or to build components to be used to improve proprietary engines instead of helping free ones because hey, the proprietary devs may send a bugfix our way? No.
MIT-license users are not bad guys -- I have both GPL and MIT code out there myself -- but choosing a non-copyleft license because it helps proprietary developers is not a good reason. I chose MIT to interoperate with other free software; if it wasn't for that I would have chosen the GPL or the LGPL.
> hurting our entire industry
I think the entire software industry is _helped_ if I drive it towards free software. I don't care how many billions the next Call of Duty game will make. I care if local developers in my country can get a consulting gig because the system my government uses is open source and so they have a shot at fixing its bugs instead of having my government sign a multimillion dollar contract with a major foreign company and get locked-in to it.
> (Programmers with zero options; they're not going to ragequit the gamedev industry just because engines are closed source.)
Weak argument. Back then would you say "system programmers are not going to ragequit the industry just because operating systems are closed source". But instead, they wrote open operating systems. Follow their example. Write a free engine. That's the entire point.
Firstly, I want to be clear that I responded specifically to the idea that "MIT license == somehow bad". Releasing code under GPL is not in any way a bad thing, and I'm not arguing against the GPL. People can do whatever they want, and there are a lot of solid reasons to prefer the GPL. My purpose here is to stick up for fellow gamedevs, because it's absurd to believe that we're not interested in contributing to open source just because we prefer the MIT license. I could name several gamedevs off the top of my head who have contributed in a big way to open source software. Interestingly, they all tend to use MIT licenses.
Back then would you say "system programmers are not going to ragequit the industry just because operating systems are closed source". But instead, they wrote open operating systems. Follow their example. Write a free engine. That's the entire point.
The gamedev industry isn't like other industries. You can't spend a decade writing an engine. You therefore need talent in order to write a competitive non-toy engine. This means you must work in the game industry for a period of time to get that talent. You also need to be brought up steeped in the sort of culture that makes you mentally inclined to open source your years of hard work rather than keeping it closed and proprietary. That's why it's a mistake to villify the MIT license -- you're cutting off an entire generation of programmers from open source culture. Specifically, the generation of programmers who want to be game developers. The reason is because they are going to be working in the gamedev industry, and hence the MIT license is going to be their only option to participate in open source culture. Villifying them will drive them away, and future talent will write proprietary closed-source engines as a result rather than free and open source ones.
In summary, villifying the MIT license is directly counterproductive to your philosophical goal of seeing less proprietary software.
Why are you conflating two different industries? If you are going to question the validity of his point, actually do that instead of throwing in a red herring. The software of your government is nowhere near the same as video games.
In fact, I would say the video game industry is somewhat unique in the case of software dev, as it is not generally a "life improver". Video games are not tools that would improve the world if everyone had free access to them. In fact, most big games being proprietary (and not free) is probably a blessing for the productivity of the entire human race.
I personally don't want most of my multiplayer games to be open source (you used the example of Call of Duty), because when the client is open source it is much easier to cheat (and build your own "cheat client")
Counteracting the existence of companies doing proprietary software is the very reason why the free software movement was started in the first place.
Is this really true? I always thought it was to counteract the abuses of companies doing proprietary software.
MIT-license users are not bad guys -- I have both GPL and MIT code out there myself -- but choosing a non-copyleft license because it helps proprietary developers is not a good reason.
Proprietary developers might disagree with you. There is a lot of evil done by proprietary software companies. Especially...
...have a shot at fixing its bugs instead of having my government sign a multimillion dollar contract with a major...
...situations like that, but not everyone who does proprietary software is automatically evil. In my philosophy, evil comes about through non-consensuality. It's providing choice that stops evil and it's suppressing choice that encourages it. The emergence of open source software, then, is a good. The elimination of all proprietary would be an evil.
Why would I want to give free labor to massively wealthy AAA studios who don't want to give back anything? If they want to use my code in their proprietary products, they can pay me to license it, just like they expect others to pay them. I don't see how it's "standing with me" to use my code to make the next Madden, without giving back either code or cash.
By this logic why would anyone contribute to the OSS of large corporations like Oracle or Facebook? I'm also a game developer and was able to open source a chunk of AI software to the development community which has been used in commercial games but also many education and personal projects. That would not be possible without licenses like MIT.
If you wrote the software you can do whatever you want with it, including releasing it under the GPL.
Nope. Gamedevs are covered under both non-disclosure and non-compete agreements. There's a lot of red tape to cut through to release something as open source. Even if you've written it at home on your own time, companies have made a big deal about employees open-sourcing code before.
This is doubly true in the finance industry.
Without MIT licensing, there would be an extra hurdle of "GPL? We cannot under any circumstances be associated with GPL." It's absolutely silly, but absolutely true. I'm speaking as someone with firsthand, I've-been-there-in-person-and-dealt-with-this experience.
Also, by releasing it as GPL, no other gamedevs can use it. We gamedevs like to release code that other gamedevs can use.
That doesn't sound like a GPL problem, it sounds like an industry problem. As a game developer I'd rather complain with the industry and try to follow an ethical path (i.e. freedom with GPL) rather than complain to those people who release their hard work for free under the GPL. I admire those people.
Some game developers have been able to contribute software using LGPL to get around the restrictions of both corporate legal departments and the confidentiality agreements you have to make with Sony, Microsoft and so on. Electronic Arts for example made a port of Webkit which can run Playstation and Xbox, which is a linkable library and includes no reference to third party API's.
Personally I choose a license relevant for the kind of software and what it will be used for. When that includes software I want people to be able to use in commercial software I use MIT. I'm still releasing hard work for free, I don't have your admiration, but people get to use it.
Facebook uses the PHP license for HHVM which is a very significant OSS contribution, and has very similar terms to MIT.
Like people said, that you have a non-disclosure agreement has nothing to do with the GPL. My point was that no matter what other things you do with the software, including using it for a commercial game, you can also release it as GPL.
Other gamedevs absolutely can use it. The only thing they can't do is include it in a shipping product. Light Table appears to be an IDE, and there is no problem using a GPL IDE for writing a commercial product any more than there is a problem compiling it with GCC.
Yup. Personally, as an indie developer who is certainly not massively wealthy, I've submitted a PR to GLFW (my windowing/input system) to support Retina screens on OS X. Of my other open-source dependencies (boost, vorbisfile, logog, physfs, and GLEW), there's just nothing I've needed to patch. Otherwise I would've.
There's nothing under GPL/LGPL I need or particularly want, but I do benefit from BSD-based stuff if only because I can't statically link LGPL stuff and I find the GPL unethical. Of course I'll give back where I change stuff, because I'm not an asshole. But GPL/LGPL ignores reality in too many ways to be viable; I personally like the CDDL quite a bit but nobody uses it.
I'm not a game developer; that industry is welcome to continue on without me, they have done great so far.
The fact that some code is licensed with the GPL is in no way detrimental to anybody. If the person who had written the GPL code had instead made the code completely closed source, "game programmers" would have been in a situation that would can only be the same, or worse. They would still have to write their own code, and wouldn't have even the choice of building upon the free software and making it free to everyone else.
Open source developers are under no obligation to do your work for you, or to make your life easier. That some choose to do so is fantastic. To expect everyone to give away their code with no form of compensation is silly (even if that compensation is simply paying it forward).
And there's always the third option... pay someone for an alternate license to the code. Do you really dig Lighttable, and want to incorporate it in your closed source videogame? Pay the developer enough money that he'll license it to you without any of the GPL clauses.
You're preaching to the choir, my friend. I think the GPL is great.
I also think the MIT license is great, or at the very least that people who use it shouldn't be vilified. As I mentioned elsewhere, vilifying the MIT license is counterproductive to our mutual goal of seeing less proprietary software. https://news.ycombinator.com/item?id=7026368
As a game player, you're hurting an entire customer base by shutting us out of modifying your software. The primary goal of the GPL is to allow end users the freedom to fully utilize the software that they use, including the ability to extend as they see fit, not for developers to collaborate with each other.
Talk about entitlement. People choose the GPL because they don't want their code used in proprietary software. We don't want to help the proprietary game development industry. We care about user freedom, not programmer freedom.
Yes. Those are old engines, not current-gen tech. They make money off current-gen tech until open-sourcing it makes more sense to them from a financial perspective. This is distinctly different from what CodeCombat has done, which is to open-source their current-gen tech. There aren't going to be any financial consequences (or any other kind), because it's a good idea and there's no reason not to open source. I'm just saying they're the first non-indie Gamedev company to do so (as far as I know) and they deserve all the credit for it.
They only open-sourced them once their value to Id was approximately zero.
It's still a really cool thing to do, but neither Id (or any other game company I'm aware of, anywhere, ever), has released their game as GPL while they were still making significant amounts of money from it (which in practice means within the first couple of months, for almost all games).
I think that game industry's reliance on the proprietary model is somewhat odd because they could do a really nice code is open source, but the art assets, sounds, etc. are licensed. Let people have and modify the engine, and if they purchased the game, they're free to add or do whatever, but no one can take your assets and resell them legally.
Permissive licenses (or "licenses" like SQLite's Public Domain declaration) like BSD/MIT have lower barriers for use by many organizations, and many of them will contribute back because having a bigger community involved in maintenance benefits them, even without a GPL-shaped gun to their head.
That community effect can make BSD/MIT/etc. better for users.
The idea that GPL is "best for users" seems to rest on at least one two assumptions, both of which are flawed:
1. No one considers licenses when they select free software, so that someone who would use a piece of software under a permissive license will use it under a GPL-style license (discounting the fact that there are organizations that simply won't touch software with GPL-style terms, that would use it with BSD-style terms),
2. People always and only give back when legally required to do so.
There are lots of communities around GPL licensed software as well, so that's kinda a moot point, no?
The assumptions you cite are not the primary reason GPL software is considered "best for users" (by some). The second point is not even relevant for users but developers.
GPL software is guaranteed to stay free. That's what's relevant for the user.
(Personally I like both kinds of licenses, so I'm not arguing for/against either)
> There are lots of communities around GPL licensed software as well, so that's kinda a moot point, no?
No, the point wasn't "only permissively licensed software can have communities" (which would be ridiculous), it was "the fact that many organizations are less receptive to the GPL can result in larger potential contributing communities for permissively-licensed projects".
> GPL software is guaranteed to stay free.
GPL software is no more guaranteed to stay free than permissively licensed software is.
The closest thing to that that is a real difference between GPL and permissively-licensed software is that, assuming no radical change on the part of the FSF (or, alternatively, assuming the "or any later version" option isn't used), GPL software is guarantted to not have legal non-free derivative works not separately licensed by the copyright owner. Which is relevant to the degree of control that the copyright owner can exercise -- and why it is popular for commercial Open Core schemes -- but not particularly relevant, at least in a positive sense, for users.
> "the fact that many organizations are less receptive to the GPL can result in larger potential contributing communities for permissively-licensed projects".
"Can" result, perhaps, but there seems to be little real word data behind that claim. I've heard this a few times, but I've never seen any numbers to back it up. As a counter example: The Linux kernel seems to be the most commercially backed OSS project of all. If what you say would be true, why would the major players not flock to the BSD:s instead?
> not particularly relevant, at least in a positive sense, for users.
What you say about the GPL is only true for projects where copyright is assigned away from the contributor. And a lot of developers as well as users tend to shy away from those for just the same reasons you state.
> "Can" result, perhaps, but there seems to be little real word data behind that claim.
There's a reason I use "can" instead of "does". Its very hard to quantify the effects of licensing since you can't easily isolate it from other contributing factors.
> As a counter example: The Linux kernel seems to be the most commercially backed OSS project of all. If what you say would be true, why would the major players not flock to the BSD:s instead?
That's a very good point. OTOH, while there are widely used GPL RDBMS, which ones have the non-first-party commercial backing of SQLite or Postgres?
> What you say about the GPL is only true for projects where copyright is assigned away from the contributor.
From the point of view of a downstream developer, its more of a concern with assignment, true. In any case, its not a positive benefit for users.
> "Can" result, perhaps, but there seems to be little real word data behind that claim.
The wording of the claim is particularly relevant. You seemed to acknowledge it, but then ignored it. The claim doesn't require data; it's using a priori reasoning. In particular, it assumes that the GPL is one potential road block preventing certain entities from using software. If a roadblock is removed, then that can result in a larger community. (N.B. Removing a road block, in and of itself, doesn't imply that more people will come.)
This is specifically one practical reason why I use permissive licenses. I want to maximize the number of people using my software. If I use the GPL, due to its infectious nature, people tell me they can't use it because their employer won't allow it. This conflicts with my goal of maximizing the number of people who can use my software.
> As a counter example: The Linux kernel seems to be the most commercially backed OSS project of all. If what you say would be true, why would the major players not flock to the BSD:s instead?
That's not a counter example. The claim in question here does not imply that GPL projects cannot have large communities.
>In particular, it assumes that the GPL is one potential road block preventing certain entities from using software. If a roadblock is removed, then that can result in a larger community.
But on the other hand a permissive licence could just as well be a road block preventing 'certain entities' from contributing code, and if it had a copyleft licence it could result in a larger amount of contributions.
In short, in lack of any data to back either of these hypothesises means they are just that, hypothesises.
There are successful collaborative projects using both types of licences, andydroid pointed out Linux which is GPL licenced and also the largest collaboratively developed software project in the world, so certainly GPL is not a serious problem when it comes to getting contributions or use (Linux is practically everywhere).
Looking at the larger open source landscape, it's my impression that copyleft is predominantly used in larger, finished application type projects (of which Light Table is a perfect example), while permissive licencing dominates in component/framework style code.
At the end of the day it's up to the developer to choose the licence for _their_ code, both copyleft and permissive licencing fulfills a need, else they would not be so popular amongst developers.
>This is specifically one practical reason why I use permissive licenses. I want to maximize the number of people using my software.
Nothing wrong with that, but there's also nothing wrong with wanting to licence your code so that end users of your code and it's derivatives are given rights (which include the source).
> But on the other hand a permissive licence could just as well be a road block preventing 'certain entities' from contributing code
A permissive license, by definition, cannot prevent an entity from contributing to it. I've never heard anyone tell me they won't use a permissively licensed project for any reason related to its licensing.
> In short, in lack of any data to back either of these hypothesises means they are just that, hypothesises.
If you still think this claim requires data, then I'm afraid you're missing the point. The claim is using a priori reasoning, and makes an assumption about removing road blocks from using open source projects. The claim does not make any quantitative claims relating permissively licensed projects and GPL projects.
In any case, making a quantitative claim here is nearly impossible. There are too many confounding factors.
> Nothing wrong with that, but there's also nothing wrong with wanting to licence your code so that end users of your code and it's derivatives are given rights (which include the source).
I don't understand your point here. I didn't say there was anything wrong with that. I merely stated that the claim made by dragonwriter actually factors into my decision to use permissive licenses. i.e., Anecdotally, the GPL is enough of a barrier that I perceive a permissive license as better if I want to maximize the number of people using my software.
>A permissive license, by definition, cannot prevent an entity from contributing to it.
Nor can a copyleft licence 'prevent' an entity from contributing it. It is a choice, just as someone could choose to only contribute to permissive projects they could also choose to only contribute to copyleft licenced projects, so I fail to see what point you are trying to make here.
>I've never heard anyone tell me they won't use a permissively licensed project for any reason related to its licensing.
Now you bring up 'use' which is different from 'contributing'. And given that copyleft requires the source code to be open, it can't be used with proprietary projects (which of course permissively licenced code can), but that is by design as copyleft exist to give end users the rights which proprietary software typically removes.
>and makes an assumption about removing road blocks from using open source projects.
And I pointed out the assumption is flawed since he (dragonwriter) talked about 'contribution'.
Saying that a lot of 'entities' are happy to _use_ permissively licenced code is not the same as them _contributing_ code under permissive licences.
> I merely stated that the claim made by dragonwriter actually factors into my decision to use permissive licenses.
And I merely pointed out that there are other factors than 'maximising code use' which developers may consider when licencing their code.
Oh, and I'd like to take the opportunity to thank you for Wingo, really like it!
I never said the GPL was a roadblock for people contributing code. I said it was a roadblock for people using it.
Pure and simple: someone works for an employer whose policy is not to use GPL'd code. Therefore, they cannot use any code I publish under the GPL license.
No such policy exists (that I've heard of) for permissively licensed code.
> Now you bring up 'use' which is different from 'contributing'.
You're the one who said "contributing"! :-) I initially said "use" several comments ago: "I want to maximize the number of people using my software."
> Oh, and I'd like to take the opportunity to thank you for Wingo, really like it!
Thanks :-) Come hang out on IRC/FreeNode at `#wingo`. (Although it's kind of dead.)
Yes it is. Given the counter example one might just as well argue that the GPL can attract more commercial contributors than a permissively licensed project, or even that such licensing is a "roadblock" for some contributors.
You really find this sort of "a priori reasoning" meaningful?
A counter example demonstrates a claim as false by assuming it is true, and the demonstrating that, in reality, it is false.
Your counter example does no such thing. It merely shows that a GPL project can be popular. In particular, your example does not denote any relationship between GPL and permissively licensed projects.
> You really find this sort of "a priori reasoning" meaningful?
Yes. Re-read my last comment to you. I explicitly described how it was meaningful. I'd rather remove roadblocks to using my software than add them.
I'd say this is a strong reason why GPL is the most popular licence as it also benefits developers as they in turn become end users when someone distributes changes made to their code, which then means they have the right to recieve the source code of those modifications made to their code.
GPL is perfectly fine. It's a good match for something like LightTable. However companies that practice dual-licensing and that require copyright assignment for contributions do not have to play by the same rules as the third-parties that are contributing and I think this is poisonous.
It's a good business strategy of course, however, how many times have you heard of such a company that does profit sharing with the third-parties that contributed code? It's also bad for the company ... if some third-party releases some really good plugin as GPL, without doing copyright assignment, then it means the plugin in question will never be a part of the official distribution, which hurts all parties.
This is why I prefer the open core model, in which anybody can build proprietary things on top. For example IntelliJ IDEA Community Edition is licensed with the Apache 2.0 license. Apache 2.0 is IMHO the best open-source license. IntelliJ IDEA Ultimate edition includes all kinds of smarts and JetBrains is doing well - it obviously doesn't hurt them when third-parties release plugins such as this one: http://cursiveclojure.com/ - it actually helps them, because they don't have the resources to build plugins for everything under the sun.
BTW - I'm happy that LightTable was released as open-source. I would have preferred another license, preferably one that is compatible with EPL (that's pervasive in Clojure's ecosystem), but can't complain, it's their right to do as they please.
I know x264 (and upcoming x265) uses this method to make money off their open source software, they release it for anyone to use under GPL but also offer licences for those who wants to use it in proprietary projects.
AFAIK the money made is shared amongst x264 key contributors, but I have no idea if any money trickles down to less prolific contributors.
> if some third-party releases some really good plugin as GPL, without doing copyright assignment, then it means the plugin in question will never be a part of the official distribution,
Why not? I don't see why a third-party plugin should be excluded from the official open source distribution? Obviously they can't offer a proprietary licence for it alongside their own code, but it could still be part of the official release.
>This is why I prefer the open core model, in which anybody can build proprietary things on top.
Hmm... actually I prefer that if someone should make money off proprietary use of open source code, then it should be the authors of that open source code, so personally I prefer the dual-licence mechanism that the x264 devs use.
Anyone can use x264 in full open source fashion under GPL, if someone wants to use their work for proprietary means, the x264 developers are compensated for allowing this.
However, many (nontechnical) users just want software that's free (as in beer) and works well. Therefore, what's best for developers (i.e. what attracts developers) is also seen as good for these users.
No, the term "free software" was not invented by RMS. He's certainly championed it the most, but back then there simply was no other common term for this kind of software. People were already using it long before he started using it or wrote the GNU manifesto or uttered a word about the topic.
The term "open source", however was coined Eric Raymond and the Open Source Initiative. Nobody before OSI ever said "open source" to refer to software. The term was coined during a brainstorming session prior to the release of Mozilla. There is an unrelated, older occurrence of the term in "open source intelligence" which is about how to spy on people using publicly available sources, but nothing about software nor all the other things people mean with "open source" nowadays.
As a marketing term, open source has met its goal admirably: it is a far more popular term than "free software", being used to describe many things and situations other than software, and many of them almost completely unrelated to anything that OSI originally intended.
The thirteenth amendment to the US constitution is also restrictive. It protects the right of people to not be owned, at the expense of our right to own others.
Not every possible action is a freedom. There is no right to own others in any cohesive ethical framework. (It would violate the principle that all humans ought to have the same rights.)
>BSD is restrictive. It protects certain freedoms at the expense of others.
It is objectively and unequivocally less restrictive than the GPL. All it restricts is your ability to claim it is your own code. The GPL adds several more restrictions. Thus it is more restrictive. Arguing that you think those restrictions serve a purpose does not mean you can claim they are not restrictions. Lame straw man crap like pretending anyone ever said the GPL wasn't "valid" doesn't belong in a reasoned conversation.
>Neither of those licenses allows you to claim some code is "your own"
This is a completely irrelevant statement. What was your intended purpose for making it?
>I can easily rephrase that as GPL adds more freedoms
You could, but it would what is known as "lying". I could easily say that the sky is green too, but that doesn't mean it is.
>Your restriction is somebody else's freedom
No, restrictions are restrictions. Words have meanings, and you don't get to just pretend they mean the opposite of what they actually mean. The GPL imposes additional restrictions. You like those restrictions because of their consequences. That is fine. But that does not make them cease to be restrictions.
>I can claim anything I like
Sure, but you can't expect anyone to treat you like a rational adult if you make obviously false claims and say "I can do whatever I want!" as a rationale for it.
That is a false statement. Please try understand copyright law when making statements about it.
Copyright impose restrictions, and GPL gives permission where you do not have any. If you get sued for copyright infringement, its your job to waive the GPL as your permission to distribute. The legal permission granted in the GPL is what protect your distribution, and without it, anything requiring copyright permission is illegal.
Words have meanings indeed, and the word restrictions is thus wrong, plain and simple. The GPL provide permission under a set of requirements. This is true for any software license, including BSD/MIT.
So the obviously false claims are yours here, Im sorry to tell you. If you don't want to be granted permission under the license, all you need to do is stop infringing the copyright of the author. That and possible pay compensation for any current act of infringement.
>Please try understand copyright law when making statements about it.
I understand it quite well. You are simply confused. The GPL gives you permission to do things that you couldn't do otherwise due to copyright law. But it gives you that permission under several restrictions. MIT/BSD/ISC license also give you permission to do things that you couldn't do otherwise, but does so under fewer restrictions. This is not complex or difficult to understand.
You see the world in black and white. You are right and everybody who disagrees is wrong, a liar, childish or confused (all direct quotes from you).
I was simply going to ignore your aggressive behavior, but now that others chimed in...
> MIT/BSD/ISC license also give you permission to do things that you couldn't do otherwise, but does so under fewer restrictions.
Somebody takes a BSD program, extends it, and distributes binaries. This restricts my ability to inspect, improve, or extend the code. Restrictions don't have to be written into a license. You ignore those implicit restrictions and their consequences, while complaining about explicit restrictions.
Anyway, I'm pretty sure you're not going to agree and just add another aggressive or insulting reply.
No, it doesn't. Your ability inspect, improve, and extend the BSD licensed code is not affected by the release of the closed derivative, and you had no ability to do that to the closed derivative before it was created and released, so there is no meaningful sense in which that release restricts an ability you had without it. There is a huge difference between failing to give you a new ability which you don't have prior to the release and restricting an ability.
I see simple objective questions in black and white because they are. Is 1+1 2? Yes. There is no grey area. The answer is yes. If you say it is 3, then you are in fact wrong.
>Somebody takes a BSD program, extends it, and distributes binaries. This restricts my ability to inspect, improve, or extend the code.
No it does not. See, this is precisely what I mean. You are simply making an objectively false statement. Here is some BSD licensed code: http://openssh.org/ I challenge you: restrict my ability to inspect, improve or extend it. Hundreds of closed source pieces of software use that code. Yet it is still there, still BSD licensed, my ability to inspect, improve and extend has not been magically removed.
>Anyway, I'm pretty sure you're not going to agree and just add another aggressive or insulting reply.
You might want to consider some introspection. You are screaming 1+1=3 at me and calling me "aggressive and insulting" for correcting you.
You are using the word "restrictions" incorrect. Words has meaning, but incorrect usages of them only create sentences without meaning.
For a restriction to happen, you got to have permission in the first place. Since you do not have any permission, a copyright license can not in any form add a restriction. It is not possible under the English language.
Permission can be granted under conditions, also called requirements. A sale for example is to exchange an asset under the condition that the consumer can pay. Its not valid English to say that its an exchange of an asset under the restriction that the consumer can pay.
Your insistence on using incorrect English only paint a picture of someone with a agenda. Words has meaning, and you are trying to ignore it. Please stop.
You are trying to be pedantic, but you are simply incorrect. The GPL imposes restrictions as part of the license conditions. Obviously you are not subject to those restrictions if you do not accept the license, and obviously you also don't get the permissions that go with those restrictions either. Nobody is claiming otherwise. The exact nonsense you are doing is precisely why people hate GPL nuts. You are deliberately dishonest and try to hide behind misguided pedantry.
The only deliberately dishonest person here is you. The linked dictionary show quite clear how wrong you are, but I guess I can't expect you to actually read what you link. A restriction can only limit something you already have (read your link). You can not gain something by limit it, nor is a limited area bigger than the whole area itself.
The only way GPL can limit you, is if what you had previous is more. You might feel self-restricted by accepting a license, in the same way that my income will be restricted if I buy a new car every week. The car however is not a restriction, nor is the trade a restriction. Its my action of purchasing beyond my credit limit that is the restriction.
What people hate is irrational people that you represent here that refuses to actually use correct language in favor of pushing your agenda onto people. Calling you nut might be a bit crude, but what else is there to say.
In practical terms open source is the same as free software. I think just about any licence that is approved by the Open Source Initative is also approved by the Free Software Foundation.
The Eclipse Foundation and the Free Software Foundation consider that both licenses are incompatible.
"The EPL and the GPL are not compatible in any combination where the result would be considered either: (a) a "derivative work" (which Eclipse interprets consistent with the definition of that term in the U.S. Copyright Act ) or (b) a work "based on" the GPL code, as that phrase is used in the GPLv2, GPLv3 or the GPL FAQ as applicable. Further, you may not combine EPL and GPL code in any scenario where source code under those licenses are both the same source code module.
Based upon the position of the Free Software Foundation, you may not combine EPL and GPL code in any scenario where linking exists between code made available under those licenses. The above applies to both GPL version 2 and GPL version 3."
I was wondering this as well. According to Wikipedia:
The EPL 1.0 is not compatible with the GPL, and a work created by combining a work licensed under the GPL with a work licensed under the EPL cannot be lawfully distributed.
I haven't looked, but Light Table is using some EPL software for sure, starting with ClojureScript itself.
I should add that I am still a bit skeptical, especially since a nonfree operating system is clearly the favored platform, but I have a lot more hope now.
Agreed this is absolutely great news. Really looking forward to see where LT goes as an alternative to the pay2upgrade hassle of most modern code editors and as an antidote to plain ole text editors.
So technically LightTable is a web app coded in ClojureScript, HTML and CSS running in Chromium Embedded Framework (C++ application) [1] with a child Node.js background process.
Also, from your link to the issue indicating why CEF isn't used:
"The wrapper for embedding Chromium in C++ apps from CEF is useless to node-webkit, and it adds complexity and costs. Regarding the statement Content API and is not intended to be a starting point for a robust application, I don't think that's true -- Chrome is based on Content API and it's clearly a robust application. Maybe it just want to say Content API is not as easy to use as CEF API."
I understand the reason for picking GPL for the editor. The, rather large, downside I see to this is that effectively all plugins are now GPL, correct?
I run a small side business sell packages for Sublime Text and considered the concept of something similar for Light Table. While you certainly can sell GPL software, you can not prevent redistribution, so you effectively get into the business of providing support. I can't foresee being able to run a small support business without catering only to the enterprise. And even then "small" would be a relative term.
If you're interested in this, get ahold of us and I'm sure we can work something out. The plan was always to do a dual licensing scheme to enable exactly what you're talking about.
Anyone else not want to read any of this comment thread because the first thing you see is how it descends into a discussion of the GPL? Please, it's like politics and religion. Is it possible to just talk about the software itself? I'm sure there are some great comments hidden in there, but I'm not willing to slog through the mess to find them.
In other news, I downloaded Light Table and I'm willing to give it a shot.
Hacker News Enhancement Suite [1] is pretty great with collapsible comments, even shows you new comment count after you revisit home page. Styling may be a personal taste thing though.
As a backer I'm really happy that it's now open source.
As a user I'm a bit concerned by this phrase '"plugin" is a bit of a misnomer - they are capable of fundamentally redefining in or adding anything to Light Table.' I understand that the dynamic nature of clojure makes this possible, but I'm reminded of all the issues monkey-patching causes. I would hate to spend hours diagnosing plug-in interactions.
This is pretty much how Emacs has worked for almost 40 years and it doesn't even have namespaces. As far as stability Emacs is definitely competitive with the many editors / IDEs I've tried in the past so I'd wager Light Table will do just fine with this model.
(Complaining about emacs, which I feel I am "addicted" to, on HN is my hobby, so allow me to jump in. :)
Maybe emacs' level of brokenness is comparable to other editors, but it's far short of the ideal of problem-free software -- it suffers from all kinds of little bugs because of weird package interactions.
E.g., there's a mode to edit grep results, and a mode to edit multiple occurrences of a symbol inline, but using these two modes together doesn't work, for some reason. There's a mode to highlight the current line, and a mode to run a shell inside emacs, but highlighting the current line doesn't work on the most-recent line of the shell, for some reason. Highlighting the current line also doesn't work when jumping to compile errors (for me, anyway) -- that last one particularly frustrating since jumping to a compile error is one of the times you want line-highlighting most...
Another interesting part of this is the use of behavior diffs, which means the user can at any point easily remove a behavior that is causing a conflict. Unlike in most situations where multiple plugins may add functionality and you're stuck with whatever the mixture is, it's very easy to take just what you want with LT plugins. One of the key goals of BOT was to enable people to handle conflicts downstream without needing to touch the source.
As an avid Emacs user and having debugged unintended side-effects in minor-modes[1] I definitely know that this is possible there. At the same time though I would hope we learn from what works and doesn't work in Emacs and apply it to new tools.
I think one of the big challenges will be establishing the best practices for plug-ins to avoid user-experience-ruining clashes.
[1] - I help maintain the smooth-scrolling minor-mode and diagnosing and solving some of the interactions with evil-mode and macros has been... fun. Thankfully the Emacs community is populated by people who provide excellent bug reports!
Good point. I wonder if LightTable could become the new Emacs, which is basically a Lisp interpreter. Clojure should offer a significant performance improvement over elisp.
I've been working with LT for a bit over a month now by picking at it through the dev inspector and grepping over the compiled cljs source. I've used that to build two plugins in JS [1][2] to help LT meet my needs as a day to day editor. The biggest takeaway I had is that an editor built on the DOM is a _very_ natural experience to work with. I come from a heavily emacs background and was always fond of its extensibility, but I found it fairly imposing to try and create or update nontrivial UI functionality. The usage of HTML and CSS greatly streamlines that process and makes it feel much more accessible.
Perhaps more importantly, not trying to restrict plugins to using a particular API has opened LT to integration with the tons of projects already built for the web -- from terminal emulators to emmet.io, integration is very nearly as simple as including the project's source and embedding it's root element into a tab. There's a lot of low hanging fruit at this stage in the game, so I look forward to seeing rapid plugin development in the coming weeks.
Not at the moment, but it sounds like an excellent project. At the moment my plate is a bit full with:
1. A SASS-based theme framework for LT that modularizes all of the widgets and plugins into partials. It's pretty difficult to just dive into the existing CSS and figure out what to change to achieve a particular effect. You're basically required to poke around in the dev inspector.
2. A proper C++ language mode via clang.
Once those are up in several weeks if nobody else has tackled an org-mode implementation I'll probably investigate it. If you have any free time and a desire to learn or use clojure I'd definitely recommend giving it a shot though. The community would definitely appreciate it.
I think the key is to get used to hitting Ctrl+space to do everything. Pretty much everything that Light Table is capable of is through that interface.
Sure, similar to Sublime's Cmd+T choice. The problem I have though, is that in Sublime I really can use that for near everything- even opening new files. You don't have that same option with Light.
Why not? There's a `File: open file` command, and then there's the navigator to look through files that are in the workspace. You can also add files to the workspace from the command pane with `Workspace: add file` or `Workspace: add folder`.
Right, but none of those options are particularly fast.
In Sublime, if I want to open my Gemfile(at root), I just go
Cmd+T: Gem
And it's selected.
If I want to open my admin_controller, located inside of /app/controllers/, I use
Cmd+T: adm
And it's selected.
If I wanna do my Admin Controller test(spec) file, at /spec/controllers/admin_controller_spec.rb?
Cmd+T: adm sp
This is all a ton faster than what I'm seeing currenltly in Light Space, where I'm essentially forced to use my mouse, or OSX's poor keyboard controllers for open menu navigation.
If you'd prefer not to deal with workspaces, you can try the claire plugin [1], which is inspired by emacs ido-mode. It performs iterative fuzzy search over the entire FS.
If I find I'm running the same command several times I map it to a shortcut key (very easy to do in LightTable). It doesn't take long before I hardly ever hit Ctrl+space.
I love Light Table. I just wish there was a text-only mode/version too (even if it's somewhat limited) that I could use when I'm doing development via ssh on other machines, which accounts for a large portion of what I do. If that pops up sometime it would likely become my primary editor pretty quickly.
I'm 100% sure that somebody will port TRAMP to LT - and sooner rather than later :) LT looks like it's the only editor capable of pressuring Emacs in the future and to do this it has to have features like transparent handling of remote filesystems via a bazillion of protocols either in core or as a plugin. So I think it will get one eventually :)
I have to second the comment saying "just use SSHFS", I use it for everything and I would never go back. The non-console versions of editors are worth it, nevermind the rest of the conveniences.
Awesome work, guys. I've got a quick question. I know there's a way to connect to a remote REPL for Clojure live eval, but is there currently a way to open up a remote Python session for eval?
I'm working on an embedded device with a Python interpreter, and I'd love to be able to run that environment remotely, over ssh with a Python session.
If it doesn't exist, can you steer me to a place to get started building this as a plugin? Thanks!
Right now the python plugin works by running a little tcp client and connecting to LT's main tcp server. You'd just need to flip those. The Clojure nREPL stuff does this, though it might be a hair bit more complicated than what you'll need for the python one: https://github.com/LightTable/Clojure/blob/master/src/lt/plu...
I'd never heard of light table before this. Came here to see what other devs thought of it. Found furious discussion about open source licenses instead. Feels like usenet in 1995.
Sorry, my question was unclear, I was asking whether they will be using GitHub (or another publicly visible place) for their daily development or is this just where released versions will be pushed?
Will Light Table get OS-specific keyboard shortcuts (Command-based shortcuts on a Mac instead of Ctrl-based ones) in the future? They're probably the biggest reason I'm a fan of Sublime Text.
I expect a homepage to have a brief description of its product on the front page of the site. Barring that, I expect a similar brief description and feature set description on an "about" page. This has neither.
I am eventually able to find out more, but only after assuming what it is and extrapolating what problems it's trying to solve.
I had no clue what Light Table is, so I went to the website and found out it's an IDE, but couldn't easily find out what makes it different from editors such as Sublime.
Also on the main website, the background image has a height of just 762px, but stretches to the full height of the browser window. In my case, to 1920px (pivot). Needless to say it makes for an amateurish appearance.
PS. Just from the name, I expected it to be a Lightroom clone.
Where most IDEs rely on static analysis to give you information about your code, Light Table is based around live interaction with your code. You can eg attach to a running browser and inject new js or css code into the page from you editor without refreshing. Check out some of the demos:
Light Table is also designed to be easily extensible, in the same way that emacs is. There is a small core which mostly defines interfaces and the rest of the features are implemented as plugins.
Nice announcement, but where is the actual source? The github repo "build instructions" currently tell you to run a script that downloads a binary release from CloudFront, unpacks that and runs whatever was in in it. Sorry, that is not source. Well, at least not complete source.
Where is the source for the binaries that are being downloaded and build instructions for them?
Thanks, that helps a bit.
So the ltbin binary blob is actually just a renamed nw binary from https://s3.amazonaws.com/node-webkit/v0.8.4/node-webkit-v0.8... release.
I was unable to find out where the libffmpegsumo.so binary came from (I know it is part of FFMpeg and also integrated into Chromium, but what exact version is compiled there and with what options? They differ a lot, even in the legal context).
And then there is the whole plugins folder which contains more sources that are not in git for some reason.
There is no real point for LightTable to be providing some bunch of binaries. A pointer to node-webkit would be enough, they have binaries (and build instructions) on their github front page.
The reason plugins are not in the main git is that each of them has its own repo. Which begs the question - why are they copied from a release zip and not cloned from repos?
There are a few more funnies there: .gitignore does not ignore the binary files added by these scripts, if there is a new node-webkit and then LightTable release and you re-run the script, your local old node-webkit copy will overwrite the new copy you just downloaded :)
Someone needs some solid packaging help. Oh and node-webkit people need a LOT of very good packaging help. Their build process is so convoluted, it might actually spawn an extra-dimensional entity.
The code highlighting comes from CodeMirror. Adding ruby support should be fairly simple. The python plugin (https://github.com/LightTable/Python) is only ~300 lines of cljs and ~750 lines of python and the cljs side shouldn't need too many changes.
I'm impressed by the performance and start-up time of their JS-based environment; it's ridiculous that it's that fast while a heavily modularized OSGi-bnased Eclipse environment takes an order of magnitude more time to start, in spite of lazy loading of modules.
The font rendering is shitty, tough, but that's probably expected when using OpenGL.
Wait, I thought they were using Chromium for rendering. Are you saying that chromium uses OpenGL or that they aren't using chromium? And why would OpenGL be the cause of shitty font rendering? OpenGL handles points and shaders, not fonts - that's the job of something like freetype.
I just downloaded it. Besides creating a file, typing some stuff. I don't understand how it works or what it's meant to do... Quick google search, I can't figure it out... Am I missing something?
I look at some of the Kickstarter projects I sponsored (mostly hardware and software) and it seems most of them are a year behind schedule. It is nice to see that I'm not the only one bad at estimating project schedules. :)
I remember a little while ago people being very suspicious about LightTable being open sourced, quoting the fundraising page, doubting about extensibility. Kudos to ibdknox for his creation!
Very cool! Hopefully this will lead to some more enthusiasts contributing and making this as full-featured and robust an IDE as it has the potential to be. Good job open sourcing this.
This is pretty cool. Does Light Table have plain text configuration that can be stored in git? I would consider an editor that isn't configured that way to be a regression.
(Build instructions currently consist of dumping part of the current binaries and rebuilding the CLJS bits, which is straightforward but doesn't help much with porting to other archs)
Definitely a possibility -- LT is very flexible. Even if you choose to more or less ignore the plugin interface, you can interact directly with the DOM. I imagine the path of least resistance for a terminal plugin is just to open a new named tab via the API and then inject an existing HTML terminal emulator into it with access to the local machine.
I'm trying to picture this. So I have LT open, and then I interact with it via a 3rd party terminal application? Maybe the terminal app can "pull" output from LT (or LT "pushes" output to the terminal app?
You could certainly set up a bridge over sockets or ajax, but I think the true beauty of LT is that you can actually embed an extant web-based terminal directly into LT's dom and interact with its native events. LT runs in node-webkit, which is essentially chromium. The only barrier to entry I can think of is that it might be difficult to set up the terminal emulator to interact with the local FS, but its definitely a solvable problem. My current plugins both interact directly with the DOM and the local FS for various purposes using node and jQuery. The jQuery is honestly unnecessary thanks to only needing to support webkit, but it was a simple expedient and its luxurious not worrying about byte count since everything is running off the local machine.
The Windows install instructions listed on the repo didn't work right out of the box for me - the app would just stay the "light table" welcome screen and nothing would happen. Figured out through the nw console that bootstrap.js was missing in core/node_modules/lighttable, and adding that seemed to do the trick. Maybe I did something wrong, though.
The EPL would have been far preferable to the GPL given that it's not hard to imagine derivative open source projects that would bundle and mix Light Table's source code (or parts of it) with other Clojure/Script projects' source code, the majority of which is published under the EPL.
Unfortunately, the EPL and the GPL don't play nicely together.
For what it's worth, the EPL is as amenable as the GPL is to the copyright holder's offering the option of a paid, non-reciprocal "commercial license".
So, given that's the case, the real question comes down to how long you want or need the fangs of the license's reciprocal clauses to be. I personally have no problem with copyleft, and will be taking the EPL + commercial option route with one of my own projects in the near future.
I realize that monetization strategies are a big deal if you're essentially trying to "pay the bills" with your open source project. I can't help thinking, though, that choosing the GPL when the vast majority of the Clojure ecosystem is under the EPL - and given that the two licenses are incompatible - is a misstep. I hope to be proved wrong. :-)
Its been mentioned elsewhere here, but you should probably think about having copyright assignment before accepting third party (non-plugin) patches, so that you can continue to work something out with people in the future too.
One question (from above in the mass of licensing argument) according to Wikipedia the EPL is incompatible with the GPL:
The EPL 1.0 is not compatible with the GPL, and a work created by combining a work licensed under the GPL with a work licensed under the EPL cannot be lawfully distributed.
I am both happy and kind of annoyed by this announcement. As a backer, I felt that I "paid" for some extra licenses by backing this project based on the reward levels. I did get a T-shirt though.
Anyway, it's better for the community that it's free(ish) though I wish Kickstarter would exercise some control over its reward system, but lesson learned.
and you're right. Kickstarter is not an investment platform. Which is why i don't ever contribute to a kickstarter, unless i know i m getting some return on investment back (either in the form of payment, or an appropriate amount of discount for the product).
I wish there is a true crowd funding platform where you could "own" and partake in the profits generated from the funding.
well, isn't it annoying when you paid for "nothing"? i.e., you've subsidized a product that your competitor didn't (here, competitor is basically every other human being) have to, and yet both got the same benefit. Therefore, you've been "disadvantaged".
I pay taxes for services I will never use (therefore I paid for "nothing) (and often could not use e.g. I don't have children and don't plan to have any either but my taxes subsidise state education (which is fantastic)).
I donate money to open source projects who release their projects and code to people who have never paid (which is a tiny fraction of what the people who write open source code and then give it away give).
The buddhists (I'm an atheist but there is much to admire in some religions) have a concept called pāramitā "the perfection of giving" which (horribly and likely inaccurately described) is the idea of giving without attachment expecting no return.
Also in this case the person who paid for X got X, that others also got X has no effect on the person who paid.
This looks interesting, and I always wanted to learn lisp/clojure, but the website doesn't say much on how to use the tool. Anyone with good blog posts about clojure with light table on windows ?
it should be noted that if you find the vim support lacking in LightTable it's just a matter of adding what you need to CodeMirror (which is where LightTable gets its vim support) and then LT, and everything else that uses CodeMirror will get better, and all us vim users will be thankful.
First you have to install the plugin. In the menu at the top, go to View then click on Commands. The commands will appear on the right side (and note that you can just start typing the name of a command to filter it out). Click on this one "Plugins: Show plugin manager". Then on the Plugins, make sure you go to the Available section. Scroll down and find Vim and click on it.
Now you have to enable it. Go back to Commands and find "Settings: User behaviors" . Then go to the :editor section between the square brackets. Type "vim" and it will show a popup with several items it can complete. Pick this one: "Vim: Activate Vim mode".
It should then insert this: :lt.plugins.vim/activate-vim
Save the file and it should now work!
it will be happening TWICE!
I asked the original question, as I've been spending a bit of time creating an IDE, I'll be continuing development and will also be open sourcing it.
This is the first time I read about lighttable and I'm glad I did. It looks really sweet. Now all I need is good vim plugin and I think I'm finally set.
Well, the question is, best for what? If the goal is to maximize the amount of Free (as in libre) software, then the GPLv3 is arguably the best choice. If the goal is to provide liberty, as in letting people choose what to do with the code for themselves, then MIT might be a better choice.
The GPL is infectous by choice: If some part of your project is under the GPL, the whole has to be licensed under GPL. This is not the case with the MIT license.
If the goal is to provide liberty, as in letting people choose what to do with the code for themselves, then MIT might be a better choice.
This really depends on whose liberty and what kind of liberty you have in mind. From a GNUish perspective, the MIT license gives you the liberty to... restrict downstream users' liberty to modify the software and distribute the modified versions. The GPL restricts your liberty to restrict other people's liberty in that manner.
Which is more free in some kind of libertarian sense probably depends on what you consider the status of copyright in the first place. If you think the ability to restrict downstream users through the copyright system is a kind of natural right (perhaps by analogy to property), then the GPL is adding restrictions on your ability to exercise that right, and MIT/BSD licenses are freer. If, on the other hand, you think the ability to restrict downstream users' distribution through copyright is an artificial privilege granted by the State, then the GPL constraining your exercise of it is not really a loss to liberty.
The GPL is not "infectuous" or "viral" or any of that nonsense. The GPL does not spread on its own. Your code isn't going to catch copyleft by sitting next to some free software.
Ah, sorry for being unclear, I wasn't aware that this was such a loaded term. I am not against the GPL, and I don't mean that in a negative way. I meant that in the sense that it dictates conditions for the "combined work", not only the source code directly under the license.
It may be better for commercial users, because they don't have to give back their improvements, but it's worse for the project itself for the same reason.
> It may be better for commercial users, because they don't have to give back their improvements, but it's worse for the project itself for the same reason.
OTOH, another perspective is that the GPL is worse for the projects because the restrictions it imposes may make people less likely to touch it at all, and those who don't touch it aren't going to give anything back whether they have to or not, and commercial users demonstrably do give back to projects that are under licenses that don't require them to do so -- and even pay people to work directly on the projects.
but having commercial users "altruistically" contribute back means having to trust in them. Had lightable not been GPL, commercial entities could easily have just taken it, make a nice derivative (e.g., make it into a game dev IDE), but never contribute that back at all. TLDR; they got a free lunch.
With GPL , said commercial entity either have to provide their derivative's source (thus contributing back via more features/code), or pay the owners of lighttable a fee for not revealing the sources. Neither way allows them to get a free lunch. This is a good thing imho.
That isn't actually the case, just the rational used to make the choice. Actual experience has shown that commercial users simply avoid restrictive licensed projects, and frequently give back contributions to liberally licensed projects. Ogre3d for example switched from LGPL to MIT and got more contributions from the commercial software world.
Maybe, but the counterpoint would be that you don't necessarily know about companies using MIT projects and similar because they don't have to announce it at all.
That is not a counterpoint, it is an assumption. A counterpoint would be actual experience of getting less contributions with an MIT/BSD/ISC project. Saying "but in my imagination it doesn't work that way!" does not counter actual real world experience.
The difference is that the GPL is designed with users in mind. The idea being that if you have the right to run code, you should have the right to modify that code.
I'm sure you've used software that has frustrated you, knowing full well that you could easily fix the problem, if only you had the source. I expect every programmer has had that thought at least once. That is what the GPL is designed to resolve.
The MIT license, on the other hand, grants no rights to the users.
Once you get use to the keys and put a nice color scheme the efficiency that you gain is something out of pray, but i think that efficiency is no everyones call.
Happy hacking, Light Table devs.