VLC Core is LGPL
jbkempf.com
jbkempf.com
Anyway, the title is, of course, misleading. VLC core, named libVLCcore is LGPL since last year (I did it too in december) and the wrapper for 3rd party applications libVLC was relicensed too at the same time.
This is different, since most modules of VLC are now LGPL. We speak about codecs, demuxers, format parsers, protocol accesses, filter and outputs. And those modules are way more important in terms of contributors and lines of code than the VLC core. In fact, we speak here of 230 people with around 300,000 lines of code, compared to 80 people and 80,000 lines of code for the VLC core.
Of course, from a higher-level point of view, all those playback modules are part of the "core of VLC" :)
The one that a VLC contributor working for Nokia (Rémi Denis-Courmont) managed to take down, for not being in compliance with GPL?
A cynic would ask if it has anything to do with not working for Nokia anymore...
The LGPL move started some time ago and Rémi was still at Nokia and he was pushing for it.
My understanding of LGPL is that it requires that users be able to switch out the LGPL-licensed code. This implies dynamic linking, not a difficult proposition, but more fundamentally it requires that users are able to access the LGPL code portion, delete it, and replace it with something else. I don't see how any old iOS user can do this without paying a dev fee.
I think not. The issues were mainly 2:
- The Apple EULA was applied ON TOP of the GPL, whatever happened. This was clearly incompatible. And this is not resolved with Apple updates on the iTunes ToS.
- The Apple ToS did not allowed you to use the App for every use, which is a violation of the GPL §0. This is still an issue today.
There is no requirement that end users be able to do any of this on a platform without becoming licensed developers for that platform. (At the time LGPL was written, many platform vendors charged hundreds or even thousands of dollars for their developer tools.)
Preferable in practical terms, as "more professional developers around VLC" sound a bit vague and, if that is really the stated goal, will you follow up on this with statistics to show if the license is drawing more professional developers to the project?
Competition.
AppStores and other crap of the post-PC era. :)
I would be very interested to see some data on that, say gathered over a year or two. Licenses decision really need more scientific approach, and if the main desire from choosing a license is to attract more third-party contributions, GPL vs LGPL is an interesting situation.
Have you seen a change in third-party contributions from companies for the libVLCcore after the license change? Its not the same type of software as the mods, but would still be interesting in this context.
Yes
> Have you seen a change in third-party contributions from companies for the libVLCcore after the license change?
Yes, but most of them asked for more.
Those details can be very useful for the community of free and open source software, and when deciding licensing for oneself.
Unlike other OSS licenses like BSD, Apache, LGPL, etc, GPL makes it impossible to utilize the library in any way in a commercial product. My current company works on some video related stuff, and we use OpenCV, ffmpeg etc but we completely steered clear of libVLC due to the GPL licensing (even though we think it's a fantastic piece of software). We will however be revisiting this now due to this excellent work by jbk.
That's not strictly true. You could license your commercial product as GPL, or (more likely) contact the library's authors and negotiate usage of the code under another license.
So yeah, "contact the authors" can be hard, but an up-front agreement and price can make it pretty easy.
However, whatever your views on closed source products, they are still quite prevalent. IMO LGPL is a great license to get support from companies that sell these products, while ensuring that your software fundamentally remains free.
It remind me a few months ago the launch of meteor.js. I heard so much people saying that it was "not usable commercially"...
And the worse is that the same people have MongoDB in production with it's AGPL license.
If you are not intending to modify Mongo then AGPL is not restrictive, which may be OK. The database API is not usually considered as "linking" as it is a wire protocol.
Why not?
What prevented you from asking someone like the Software Freedom Law Centre or Software Conservacy to help you enforce it? Do you actually need lawyers to enforce the license?
And SFLC and SC care about "more important projects" as we were told.
I usually shut down 2 violations per week and it is not decreasing...
[1] http://dtrace.org/blogs/bmc/2012/08/01/post-revolutionary-op...
[2] http://smartos.org/2012/07/27/corporate-open-source-anti-pat...
"Porting ZFS to Linux is complicated by the fact that the GNU General Public License, which governs the Linux kernel, is incompatible with the Sun CDDL under which ZFS is distributed."[0]
See also this reasoning from the native ZFS linux kernel module port:
"In a nutshell, the issue is that the Linux kernel which is licensed under the GNU General Public License is incompatible with ZFS which is licensed under the Sun CDDL. While both the GPL and CDDL are open source licenses their terms are such that it is impossible to simultaneously satisfy both licenses. This means that a single derived work of the Linux kernel and ZFS cannot be legally distributed."[1]
[0]: https://en.wikipedia.org/wiki/ZFS#Linux
[1]: http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue
Part 2 (probably the more interesting): http://www.jbkempf.com/blog/post/2012/How-to-properly-relice...
Part 1: http://www.jbkempf.com/blog/post/2012/How-to-properly-relice...
I think I quite like it, but only because there is an option to replace their code if they vote no (which admittedly may be very technically difficult). No single contributor can truly veto the license change.
Clearly has it's downsides though.
VLC contributions have mainly been done by 2 dozens of persons. If any of Rémi Denis-Courmont, Laurent Aimar, Gildas Bazin, Pierre d'Herbemont, Rafaël Carré (or me) would have disagreed, I would have stopped right away.
http://multinc.com/2009/08/24/compatibility-between-the-ipho...
Interestingly there's no mention of dissenting opinions from anywhere. Not that I'm implying that this move is a bad thing, I would just expect if you ask a large enough group of developers any question about licensing you would get a variety of arguments cropping up.
- iOS audio output and video display, because author refuses the license change
- Mono, Headphone and Dolby, because author refuses the license change
So there is some dissenting opinion.
> Interestingly there's no mention of dissenting opinions from anywhere. Not that I'm implying that this move is a bad thing, I would just expect if you ask a large enough group of developers any question about licensing you would get a variety of arguments cropping up.
Because the vast majority of VLC developers want their code to be used, not fight over licenses.
I have read part 1, didn't know there was a part 3.
I'm just saying that imagine (in a hypothetical situation) there is a large code module written by an original author under the GPL. Over time it is worked on and line by line it is eventually fully replaced with new code by 5 other people.
Even if you get the 5 to agree to a license change, the original 1 would still have an argument that it was all derived from his original work and should remain under GPL.
I have no idea if this situation applies to you, it was just an idle thought.
This is not the case here. And part 1 explains exactly this, with the git log part.
Part 3 will close the loop altogether.
In my defence I drank a lot of rum last night...
But well, the unfortunate truth is that many people are bad at computers and if they manage to mess their system playback up, VLC can certainly feel like a "rescue" with its stand-alone nature. But well, I doubt most people care about high-quality media files to begin with, and VLC sure plays those 700MB XviD AVIs and so on just fine...
Why so negative?
I certainly understand it's appeal, but there's certainly better yet equally simple solutions out there as well (eg. CCCP for Windows, various MPlayer2 bundles for OS X like MPlayer.app). Of course, the "downside" of DirectShow-based playback solutions on Windows is that if a user has managed to fuck up their DirectShow beyond recognition, it's going to need a lot of unfucking before you can do anything about it, whereas VLC in its stand-alone nature can play stuff even in a situation like this. Though you could also always get a SMPlayer2 & mplayer2 bundle in such a situation too...
I'm not at home right now so I can't reliably confirm if certain long-time issues still remain in the latest version (2.0.4), but VLC has also for the longest time had issues with pause not being completely instant (despite claiming so), the audio glitching slightly when pausing/unpausing, and seeking in H.264 video producing a garbled mess (this at least has gotten better with over time). Matroska ordered chapters support has also been shoddy for a very long time. Subtitle rendering was also absolutely hideous before they started using libass in version 1.0 (IIRC), at which point softsubs had already been in use for quite a long while. As I mentioned, VLC's development in terms of high quality playback has mostly been about playing catch-up with the better players, at worst being years behind them.
Audio pausing is fixed since a long time on all platforms and on development version for Windows.
Seeking on H.264 and MKV ordered chapters issues have been solved since quite some time too.
Subtitles quality has nothing to do with libass, but the video output rendering, and this was fixed in 2.0.
madVR is very CPU heavy, and is EVR only, so not usable for cross-platform.
It most certainly does when we're talking about complex ASS subtitles.
>madVR is very CPU heavy
Actually, it's more GPU-heavy. And while it's only available for Windows, it doesn't change the fact that it's basically the best video renderer out there.
Anyway, I'm certainly going to give VLC 2.0.4 a spin with some of my files when I get home in a couple hours. If some of these issues have finally been fixed, then good for VLC, but again, it sure took them a while to do so in comparison to other players.
If you run Windows, using Media Player Classic - Home Cinema with madVR[1] will give you much, much better quality.
VLC handles some large video files - or file types - very poorly in my experience, too.
VLC is great, because it has an excellent standard of video quality, and it's easy as heck to use and set up for others, but for people who really care about optimal playback, it isn't really the best choice.
---
I think the main allure of VLC used to be that the tortuous labour of finding and installing codecs was suddenly moot. Using MPC-HC requires a lot of painstaking effort, especially once a codec stops working all of a sudden for some reason.
VLC is very Apple-esque in how it does everything for me and gives me an ease of mind, but with no guarantee that I will get the highest quality. And MPC-HC is very Windows-esque in how it requires a bunch of tweaking and pulling out hairs, which will eventually result in superior quality, but all in all perhaps an inferior experience and enjoyment, because it takes jumping through so many hoops to just get there.
Moving on from VLC to MPC-HC is very much like moving on from using primes in typography to curly quotes; it might be more aesthetically pleasing, but most of all, you kinda wish you could just unsee the difference and quit pursuing the folly of proper typography. These days, I can hardly stand reading books with justification, which unfortunately is quite a large majority of them.
It's a blessing and a curse, and I'd properly just recommend most people to find a video player similar to VLC in how easy it is to use, all while providing superior video quality and performance.
If you're watching a movie or TV show, I recommend that you watch it on Netflix or Blu-ray, if the option is available to you. That's what I do. :)
Some random examples: Thor, The Dictator, The Avengers Assemble, (essentially everything published by "Walt Disney Studios Home Entertainment", and many things published by "Paramount Home Entertainment")
Now one might say to "just disable menus!" but unfortunately that is ineffective as they have put a bunch of fake tracks on the disc which cause you to bounce around the movie out-of-order.
Playback works fine on Windows Media Player, PowerDVD, and most hardware players. Only VLC and the DVD extraction software seem to crash. Unfortunately there are likely things in the spec' which allow this.
EDIT: wow, checking now, PowerDVD 'Standard' edition is AU$55 - you can get actual hardware DVD players for less than that!
1) I don't care about sound quality on Skype
2) mplayer2 handles everything perfectly
3) My hardware is a crap on-board chip that's 5 years old and not made any more
I haven't been interested in pursuing a fix for this.
Also, mplayer2 does better upscaling with -vo gl:yuv=4:lscale=5:cscale=5
"master of one" = inferior product
see also: Worse Is Better, Innovator's Dilemma
I guess the keyword is "similarly" here? VLC is the only player that plays all video clips from crappy digital cameras I owned over the years; out of the box, or with a million codec packs, neither VirtualDub nor Premiere nor other video players can parse them. I don't really care about those clips, and they sure are shoddy quality; but it always impressed me, VLC is quite the omnivore. It plays stuff even GSpot can't make heads or tail of. This might not matter for videophiles, who by definition would want their movies to be in a good and modern format, but still, yay VLC :)
I maintain this kind of test suite since I do video production using open source software and I have to make sure it works in all the major video players.
VLC is useful and important but it is no where near perfect.
For people who want to spend hours to configure their system, MPC-HC with madVR can give better upscaling and foobar gives better audio fidelity. Most of the rest is usual rants from issues that VLC had in the past, but that 1337 video people like to bring up to explain how their setup is soooo much better.
Anyway, giving VLC 2.0.4 on Windows a spin, the audio glitch on pause is certainly still there. I guess I'll take your word on it being fixed in "development versions", but I don't think MPC-HC has had an issue like this, like, ever. H.264 seeking and ordered chapters certainly seem to work without any notable issues these days, though. Subtitle rendering still has some issues with complex typesetting, though libass is at fault there.
So there isn't that much of a difference anymore between say, a vanilla installation of CCCP and VLC. I'd still recommend the former for Windows users, though. Why? Because the former is a DirectShow playback solution, you can actually extend and swap its components at ease. Want to install madVR for high quality rendering? Sure, just download and install it and you can instantly use it in MPC-HC (which ships with CCCP) right afterwards. Being stand-alone has its benefits, but it certainly also has its disadvantages. Not to mention that with VSFilter you don't have to ever see that "Building font cache" (which will certainly not take "less than a minute" if you have lots of fonts) window!
VLC has ongoing minor problems (e.g. colorspaces) and a history of more major ones (e.g. buffer overflows in subtitle parsing). Unless you prefer the VLC interface (which would be perfectly reasonable, but I don't see people giving this as a rationale for using VLC), it's worse than either of the two alternatives I mentioned. And yet it's far more popular. This can be frustrating.
There are some files that MPC-HC does play that VLC does not, but these are fewer in my experience than the reverse case.
http://multinc.com/2009/08/24/compatibility-between-the-ipho...
The long, sordid tale of Sun RPC, abbreviated somewhat, to protect the guily and the irresponsible http://spot.livejournal.com/315383.html
GNU/Linux - finally it's Free software http://webmink.com/2010/08/30/gnulinux-finally-its-free-soft...
The Saga of Sun RPC http://ebb.org/bkuhn/blog/2010/08/27/sun-rpc.html
How does the LGPL relicense solve the Apple AppStore problem everyone is talking about? Apple may approve LGPLd code, but as far as I can tell, they still do not comply with it under their current distribution system.
edit: wrote iOS instead of LGPL in the first line, thanks simonh
I can't answer your question, but just point out that huge chunks of iOS itself are LGPL already, such as webkit, and the LGPL version of ffmpeg is already widely used.
There has been some speculation in the past that because iOS mandates static linking that this is a problem for using LGPL libraries, but I fall into the 'linking creates a compilation, not a derived work' camp and if the compilation interpretation is correct then static linking isn't a problem.
But every time I dig into LGPL interpretation and linking issues, eventually my head starts hurting and I give up.
2. The rest of what you said doesn't make much sense to me. I'm not clear on what distinction you are trying to make.
There are those that believe that the question of linking is mostly irrelevant to whether something is a derivative work. Lawrence Rosen is the canonical example of folks in this camp. But even in that camp, static linking may be a problem, it just depends on what is being done.
So it's not really true that "static linking isn't a problem".
Specifically, it cares that the end user can "swap out" the LGPLd code for their modified version, which is not available in the iOS AppStore regardless of compilation vs. derived work interpretation (a distinction without difference if I understand it correctly).
Those options are:
1. Give out source to the library, and either source or object code to the work that uses the library (so that the work can be relinked)
2. Use shared linking and build the work into a .so that would work if the user replaced it (There is a point of contention in LGPL 2.1 as to whether you need to make it possible for the user to replace the .so. It's clear what the spirit is, but the actual wording does not require it)
3. Include a written offer for the stuff in #1.
4. Offer source from #1 through the same place that offers binaries.
5. Verify that the user already has the source, or that you already sent it to the user.
If the app store requires static linking, that rules out #2.
""" For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. """
I believe this makes #1 insufficient, (and by reference, #3, #4, #5) - as that requires apple to also distribute the material needed to sign the executable for your specific phone (as an end user) if they give you the executable signed for your specific phone.
Do you have reason to believe otherwise?
You may want to get into rehashing that discussion, but i've already had that discussion more than once during GPLv3 and LGPLv3 drafting, and it was enough fun there :)
I also am firmly in one of those camps of open source lawyers, and so it wouldn't be appropriate for me to try to reproduce the arguments of the other side, but, at the same time, nothing is ever as black and white as most folks like to think, and I would be stupid to pretend they didn't have a reasonable argument.
In any case, this is why GPLv3 and LGPLv3 is explicit on this point.
Which very often happens.
As long as the author is ok with that, and proprietary interests are happy with merging their own changes on each upstream release, I don't see any wounds.
Also, sometimes it's better for proprietary interests to lift (for example) a working TCP/IP implementation, rather than implementing their own poor thing and put it on the 'net for everybody else to deal with.
rms agrees with you: http://lwn.net/2001/0301/a/rms-ov-license.php3
I understand you may not like BSD/MIT, but LGPL seems pretty reasonable to me. It all depends on how big/important your software is... if it's something that you're sure you'll never be able to make a living out of and that may be useful for others, why ask for anything else other than an acknowledgement?
Some people dont want to see their code being used in a context that might hurt a other human being, like spyware hidden inside a video player. Say someone modified VLC to produce a proprietary video player which included functions that spied on the users activities. As a developer, I would feel slightly at unease if I heard a Chinese citizen died because he watched a unpopular video, and the government found out because the program I wrote helped in spying and identifying that user.
Of course, that doesn't make producers of LGPL (or BSD/MIT) software evil or uncaring. Its up to each and every developer on how they view their work and its impact on society, and how far one want to go on that. Same goes for work, eating and spending habbits, money investments and so on.
Sure, they can produce a video player full of spyware and then give the source of the spyware to their users, but then, that would render that spyware useless as soon a anti-virus got their hand on it. Not to mention, users would avoid the program as the spyware would then be known.
Only users can keep themselves safe -- developers can't.
Or are we so jaded that we think every contracted company to the army, and every sub-contracted company being payed for a job by the NSA/CIA/FBI regularly go around and breaks laws because the think "hu, why not, my boss is the goverment, they wont mind!".
For a lot of developers in commercial positions it can be politically difficult to use GPL code but LGPL is much more politically expedient. These devs may well then contribute themselves either via the form of bug fixes or future work on more open projects once they leave their original employer.
Some of like like our proprietary software very much, thank you. I wouldn't want to live in a world where there would not have been a Photoshop, a Premiere or a Logic Pro but only their open source "alternatives".
>proprietary interests can take free code without giving anything back.
On the contrary. In reality BSD style licenses _enable_ companies to give something back to a project, whereas they would not be able with a GPL license. Sounds strange? Let me explain:
Take a BSD licensed project X.
(a) A company wants to ship something based on X, but as closed source and with proprietary extensions.
(b) They can do it, since X is BSD licensed.
(c) In order not to have to maintain a fork themselves, they also give back their fixes and improvements to the core X project, off which everybody in the community benefits.
So, the company gets to add proprietary extensions and ship closed source code based on X AND the project gets to benefit from the company's work on core X.
If X was GPL, the company would not have touched it, and would have opted for some other project instead. All those contributions back to the X community would have been lost.
That's how it works with Apple and LLVM, for example.
That's one of the reasons developers chose BSD/MIT/LGPL over GPL. Because they _specifically_ want people and companies to be able to have that option.
Pro or against proprietary software, it's a fallacy to assume that in a world where Photoshop didn't exist, its alternatives would be the same. Having a copy of PS for a relatively cheap price is a great incentive not to devote more resources to alternatives.
In principle, yes, it's problematic to assume any alternative reality in which something has changed will otherwise be the same as ours. Things affect each other.
That said, the assumption in this _particular_ case seems like a safe bet to me. For one, Photoshop does not have a "relatively cheap price". It's over $500 dollars by itself, and some thousand dollars with the rest of the suite.
Also note that the people that "have a copy of Photoshop" and need it with all it's power are not the same people that are "devoting more resources to the alternatives". The former are graphic designers and illustrators, where the latter are programmers.
Since most programmers are casual image editing software users, they wouldn't need Photoshop. And indeed, those users get just fine with Gimp. So it's not like if Photoshop wasn't available programmers would have flocked to make an equivalent program.
A price is only cheap or expensive relatively to something. Compared to the necessary money to improve a free program, $500 is ridiculously cheap. It's also pretty cheap compared to the benefits accrued by most professionals users by using it.
Also note that the people that "have a copy of Photoshop" and need it with all it's power are not the same people that are "devoting more resources to the alternatives". The former are graphic designers and illustrators, where the latter are programmers.
Since most programmers are casual image editing software users, they wouldn't need Photoshop. And indeed, those users get just fine with Gimp. So it's not like if Photoshop wasn't available programmers would have flocked to make an equivalent program.
And exactly why wouldn't designers and illustrators pay (read: devote resources) programmers to improve it, just like they do now?
If your claim is that people don't pay for OSS development, my paycheck says otherwise.
No, my claim is that people don't generally pay directly to support OSS development, and never in the scale of supporting huge teams of programmers, equipment, testing, etc like Adobe does.
There are very few examples of people in a field paying directly for OSS programmers to create programs for their profession.
Don't conflate a company paying for OSS software or employing programmers working on OSS (like Sun, Oracle, RedHat, IBM etc), with "people" and specifically graphic professionals paying programmers to create OSS graphic editing programs. (The one counter-example I can think of, Bender, was closed source, and not doing very well financially when people sponsored it's becoming OSS).
Heck, GTK+, the very toolkit used not only by Gimp but by a huge ecosystem of programs, is left with ONE programmer working on it (he posted a complain a few months ago).
It is important to understand the distinction between "open source" and "free software". Open source focuses on the benefits of "open" code and development and how it can create superior software. Free Software focuses on the ethical issues---while free software developers certainly want contributors, the emphasis is on the fact that the software respects your freedom and, for that, it's far superior to any other proprietary alternative; free software users constantly make sacrifices in functionality and usability, and we're okay with that.
http://www.gnu.org/philosophy/open-source-misses-the-point.h...
(I'm not saying that those are the views of the VLC project---I know very little of their opinions.)
Well, the "far superior" part is just, like, your opinion, man. [to quote "The Dude"].
>free software users constantly make sacrifices in functionality and usability, and we're okay with that.
If a more usable program or one with more functionality can make people freer to do stuff with it, then the software doesn't really respect their full freedom, only a constrained software-centric notion of it.
If the program has more functionality, but limits the users in way of Intellectual freedom or Liberties, it doesnt make people more "freer to do stuff". What you got is a program with less freedom but more functionality. Two distinct property of the program. Let me make an exmaple.
Is a video editing program "very free" if it have every function in the world, best usability, and is perfect in every sense, but as a legal requirement it demands all copyright ownership of any video edited? Is that program more "free" than say VLMC? What if the proprietary did allow the users to retain the copyright, but, only if the video included a ad snippet? What if non-ad included was okey, but the video had to first to go a central censor bureau to check that no kittens was harmed? what if the video instead went to the local copyright bureau to be checked for any copyright infringement? What if it included a hidden water stamp?
Freedom is more than functionality.
Hidden watermarks already happen by printer software and some screenshot programs. Some digital cameras also do this. It not a really a big leap to say that a proprietary editing tools would/could auto-include watermarking if there was a business case for it. I would imagine that a photo editing tool bundled with getty or flickr could very easy find a business case to know when a image get posted outside its domain. Actually, there might already exist some photo-editing tools on iphone/android that do this already.
I don't mix them. Reality does. While the two sources are theoretically orthogonal, they are also practically connected -- and it's easy to see why: proprietary a la Adobe equals huge company and tons of paid programmers, including people doing the necessary but less glamorous grunt work, i.e more functionality. So, most of the time, in desktop application software (server OSS software fares better) people have to chose between a more featured proprietary solution, and a less featured open source one. And more often than not they chose the latter, as they for example chose Windows/OS X over Linux. We cannot just turn a blind eye to that choice.
>If the program has more functionality, but limits the users in way of Intellectual freedom or Liberties, it doesnt make people more "freer to do stuff". What you got is a program with less freedom but more functionality. Two distinct property of the program. Let me make an example. Is a video editing program "very free" if it have every function in the world, best usability, and is perfect in every sense, but as a legal requirement it demands all copyright ownership of any video edited?
Well, if what I want to do is make a movie, and I cannot do it at all with an OSS program due to functionality limitations, then yes, the proprietary one is freer, even if I have to give them my copyright.
Which is a strawman argument, by the way. Proprietary software mostly asks for your money, and for you not to tamper with the source. No video editing program asks to hand them over your copyright.
>What if the proprietary did allow the users to retain the copyright, but, only if the video included a ad snippet?
What if? It's between the users and the program. If they accept that, then they want to use the program despite the ad snippet.
I have yet to meet anyone who can convince me that freedoms 1 to 3 should, in fact, be freedoms.
(I do not have a problem with anyone giving her or his software a license that requires everyone to respect those four freedoms. What I do have a problem with is when people are berated for picking a permissive license that, however, doesn’t quite line up with the four freedoms.)
I entered the free software movement slowly (I began software development on Windows as a young boy and was trained to think that bossing the user around was a good thing; I thought it was fun to write DRM system and anti-features). I began using GNU/Linux while still rationalizing my use of proprietary software through Wine or by dual-booting into Windows. I then saw the benefits of the "open source" development model. It wasn't until I spent the time researching the reasons behind the free software movement that things began to click. I was able to look back on everything I learned as a developer for Windows and see that I enjoyed the thought of controlling my users. I enjoyed the power I got from programming---programming was empowerment, and the only way to squeeze the money out of those unsuspecting users was to do it forcefully.
People have fundamentally different philosophies when it comes to programming. Do all proprietary software developers do so out of greed? On some level, sure---they're not contributing that code so that others may benefit from it. But are they doing it for the purpose of controlling their users? Not necessarily, but they still are, even if they have the best of intentions. Is someone who creates proprietary educational software for children in third world companies "evil"? Certainly not. The problem is that they're denying them an additional right---the right to modify that software, learn from it and use their devices as they please.
Of course, we often see proprietary software used unethically, often times for vendor lock-in or greed; corporations are worried that if they lighten their grip on their users, that the users may run, or worse, do something [il]legal. I don't believe that is the place of software developers. I remember, back when I used Windows, I was obsessed with magic/illusion. I purchased a ton of videos online teaching me various magic tricks, but the videos were laced with DRM (which, at the time, as a Windows developer, I applauded). The problem was, that I then upgraded my hardware. My videos no longer worked. I contacted them for a new key, and could view them again. Then I got a new PC. And now I use GNU/Linux. I can no longer watch those videos that I purchased because of this unnecessary, artificial restriction. Was I going to distribute those videos? No. Did that prevent others from stripping the restrictions and distributing it anyway? Certainly not. I was being punished for others' actions and the others weren't any worse off from the restrictions, because they understood how to defeat them.
Of course, DRM's only one of the many issues (and DRM cannot exist in free software, because the community would simply remove the anti-feature). What if I were using some software---let's say Photoshop---and it crashed on me in the middle of my work. Crap. Well, if I were using GIMP, I would run gdb on the core dump (assuming a segfault) and inspect the problem. I would try to repeat it. I could, if I wanted to, get my hands on the source code, fix the problem and distribute that fix to others. If I didn't have the time or ability, others could fix the problem for me, and we have the right to share those changes. We have the right to benefit from those changes. With Photoshop, we'd better start waiting. What if I was able to magically come up with a fix, perhaps by modifying the machine code? Hold on---I'm not allowed to do that! And I'm certainly not allowed to distribute that fix to others. And I'm certainly not allowed to give my son a copy for his PC if he wanted to do an art project for school.
The FSF provides a great deal of information on their philosophy: http://www.gnu.org/philosophy/. You could also gain a great deal of insight by reading up on the history: http://shop.fsf.org/product/free-as-in-freedom-2/ or by reading RMS' essays: http://shop.fsf.org/product/signed-fsfs/.
And ultimately, you may find that you do not agree with our philosophy---many don't. That's certainly your right, and I respect that. What I cannot respect, and will not respect, is when that philosophy is used to exert control over others.
(As a final note: many say we control developers through our "viral" licenses. But keep in mind that we're trying to protect the users from developers. This means taking power away from developers. This is intentional.)
If you choose to, you can give or take away my freedom to further improve these extensions. No different from closed source.
On the other hand if what you are targeting are "companies" that take your code and never give back, then BSD is a fine choice.
All it takes is to list projects like Linux and GCC to show that yes, companies can give something back just fine with GPL.
What you are referring to are companies who wants to use open source in proprietary software, and yes for them GPL is not an option unless they can make a deal with the owners of said GPL licenced software for dual licencing. Then again GPL is created on the premise that all recipients shall have access to the source code so obviously it won't work with proprietary software which typically relies on keeping the source code hidden while charging for binaries.
>That's one of the reasons developers chose BSD/MIT/LGPL over GPL. Because they _specifically_ want people and companies to be able to have that option.
And one of the reasons developers chose GPL over BSD/MIT is that they want to recieve ANY enhancements made to their code.
There's no right or wrong here, developers will make the decision for THEIR code.
So typically an open source developer will choose between:
do I want to allow people/companies to take the code I offer and return nothing/only what they want of any changes they make (BSD/MIT-style)
or do I want them to have to return any changes made to the specific code I share (LGPL,MPL-style)
or do I want them to open source any code with witch they link my code (GPL)
Looking at how these licences are employed in 'real-life' it's my impression that GPL is often used for larger, full solutions/applications, while BSD/MIT/LGPL/MPL etc are dominant in component/framework style code.
Again I'm not taking any sides when it comes to licencing, I also have no problem with proprietary code (unless it tries to lock-in my data by only offering a proprietary format which is a no-no for me).
That only works for server software, like Linux, and basic infrastructure that tons of companies use, like GCC, etc.
And it works because they don't have to distribute said software. On the server side, it doesn't make any difference if the license is BSD or GPL.
In both cases, companies get to make whatever changes they want, deploy at their infrastructure, and NOT release the code (because they're not re-distributing it).
Plus, in a lot of cases, they use Linux as a commodity underlying layer, so they don't care about making proprietary changes at all.
I have bad news for you. Proprietary interests do take GPL code (any version), heavily modify and extend it, without ever giving back. The GPL specifies that you have to give the source code to the entities you distribute the work to - not to the general public or the original authors.
Since most custom software is B2B, it will "never" show up on the internet. In case the software is bundled into something physical, like an expensive CNC machine, it is even less likely.
Naturally, their site has no such thing, and customer service gives you strange looks when you ask for the code that runs on the TV. Its a pretty common red-tape circus. Everyone does that. I have no stake in the matter personally, so I haven't pursued it very far, but you're absolutely correct that GPL code is consistently used inappropriately. The only time the license restricts someone from using it is when they try to follow the rules. "When guns are outlawed, only the outlaws will have guns".
That said, it's still nice to see projects realize this and try to give people that follow the rules more personal freedom to incorporate the code into something that might need to be more closed than a sourceforge project.
GPL was just fine. No VLC on AppStore - I could live without. Hey, I can live without Apple too but this is not about me.
Others like it because it's a way of saying 'you can use this stuff I've put a lot of effort into, but only if we get to see the enhancements you make'.
I know that neither of these things is a priority for some developers, who prefer things to be used as widely as possible and as unrestricted as possible, but that's not for everyone.
> Even though SQLite is in the public domain and does not require a license, some users want to obtain a license anyway. Some reasons for obtaining a license include:
>
> * You are using SQLite in a jurisdiction that does not recognize the public domain.
> * You are using SQLite in a jurisdiction that does not recognize the right of an author to dedicate their work to the public domain.
> * You want to hold a tangible legal document as evidence that you have the legal right to use and distribute SQLite.
> * Your legal department tells you that you have to purchase a license.
>
> If you feel like you really have to purchase a license for SQLite, Hwaci, the company that employs the architect and principal developers of SQLite, will sell you one.