VLC Core is LGPL(jbkempf.com)
jbkempf.com
VLC Core is LGPL
http://www.jbkempf.com/blog/post/2012/I-did-it
16 comments
Could you explain in a bit more details why you did this move from GPL to LGPL? The blog post did not want to expand on this, and I for one would very much like to hear, from your view, what benefits the project might get from this move.
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?
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?
We are not able to enforce the GPL anyway, so let's help companies use VLC and contribute back, so this benefits all users.
Competition.
AppStores and other crap of the post-PC era. :)
Competition.
AppStores and other crap of the post-PC era. :)
okey, so beyond AppStore and theirs rules/eula/requirements and so on, the goal is to increase third-party contributions from companies?
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.
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.
Most commercial work these days leverage several open source libraries. And once a library becomes part of your core product, it is in your interest to support further development of that library by contributing code, time, money, etc.
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.
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.
"GPL makes it impossible to utilize the library in any way in a commercial product"
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.
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.
I'ts not just "not strictly true," it's not true at all. Nothing in the GPL prohibits GPL'd code from being used in commercial products. What is prohibited is using it in proprietary, closed-source products. You can have a product which is both F/OSS and commercial. Ask Red Hat, for example.
You are right, of course. "commercial" was the wrong terminology; I meant proprietary, closed-source products as you said.
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.
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's sad to see how the FUD around the GPL is widespread.
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.
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.
With JavaScript and the GPL it is very unclear what "linking" is. Probably your entire website becomes GPL including content. Who knows as the language was written for system libraries. So I can see lawyers having an issue.
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.
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.
As the OP has demonstrated, "Contact the library's authors and negotiate usage of the code under another license" is EXTREMELY difficult for a project maintainer and would thus be near impossible for anyone else.
It is much better if the price and terms are simply public up front. For instance, we were worrying about PyQt (GPL + commercial option) vs. PySide (LGPL) for a project, where PySide didn't support certain things that we needed. But then we realized that the PyQt commercial license comes with reasonable terms, and costs only £350, and it wasn't even worth the time worrying over it any more.
So yeah, "contact the authors" can be hard, but an up-front agreement and price can make it pretty easy.
So yeah, "contact the authors" can be hard, but an up-front agreement and price can make it pretty easy.
This is how the x264 developers do it IIRC, they offer x264 under GPL and if you want to use it in a proprietary manner you need to buy a licence from them in order to do so.
> okey, so beyond AppStore and theirs rules/eula/requirements and so on, the goal is to increase third-party contributions from companies?
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.
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.
Could you give, or point where one might find more details. How many more lines of code from third-party patches? 2x? 5x? 10x? Hows the quality? Are there more donations? If one take a scientific point of view, whats been the practical changes of how third-party contributions?
Those details can be very useful for the community of free and open source software, and when deciding licensing for oneself.
Those details can be very useful for the community of free and open source software, and when deciding licensing for oneself.
So far, this is just a feeling, but I cannot give numbers, because I don't have them. I'll try to compute some in the next months.
> We are not able to enforce the GPL anyway
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?
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?
Because it is very hard, very boring and time consuming.
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...
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...
Very nice, so will we see a new VLC app for iOS? I've been carefully syncing and copying my copy to insure it stays on my iPad.
How does that play with the iOS VLC port?
The one that a VLC contributor working for Nokia (Rémi Denis-Courmont) managed to take down, for not being in compliance with GPL?
The one that a VLC contributor working for Nokia (Rémi Denis-Courmont) managed to take down, for not being in compliance with GPL?
Rémi Denis-Courmont is the biggest contributor of VLC, so far, and he pushed forward the LGPL move... :)
But, since, LGPL enables the iOS port as an option again, what made RD-C change his mind?
A cynic would ask if it has anything to do with not working for Nokia anymore...
A cynic would ask if it has anything to do with not working for Nokia anymore...
Do you know if he was against an iOS port? Maybe he was just against violating the license.
And a cynic would be wrong.
The LGPL move started some time ago and Rémi was still at Nokia and he was pushing for it.
The LGPL move started some time ago and Rémi was still at Nokia and he was pushing for it.
How does LGPL enable the iOS port?
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.
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.
Yes, you need to be able to switch out the LGPL-licensed code, but dynamic linking is just the most convenient way to doing that—it's certainly never been required. You can also offer the rest of your combined work's code in a form suitable for re-linking (e.g., by providing .o or .a files for the rest of your app).
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.)
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.)
You could do a proprietary application about libVLC+VLCKit and distribute on the AppStore. And one could still side-load your application.
I thought that that was the point of contention; that it is not normally possible to sideload software onto iOS devices. If sideloading was possible (hmm, would jailbreaking count?), no biggie, just make the object files available for linking like Sparrow did (http://www.sparrowmailapp.com/lgpl.php).
> I thought that that was the point of contention
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.
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.
Congratulations to JB and team on completing this Herculean task! I had the pleasure of meeting JB when he and I shared a ride from the airport in Porto Alegre for this year's FISL.[1] When he asked me what I was going to be presenting on, I (not yet knowing anything about JB's work) had some trepidation in responding: my presentation was on corporate open source anti-patterns[2] -- and one of my conclusions was that the GPL has essentially outlived its usefulness. Fearing that this was a very controversial conclusion, I approached it gingerly in my conversation with JB; needless to say I was very relieved to learn that he and the VLC team had come to broadly similar conclusions -- and surprised that they felt so strongly that they had taken on the arduous task of relicensing. Congratulations again to JB and team; I'm sure that they join the ranks of us who never want to engage in a(nother) licensing discussion as long as we live!
[1] http://dtrace.org/blogs/bmc/2012/08/01/post-revolutionary-op...
[2] http://smartos.org/2012/07/27/corporate-open-source-anti-pat...
[1] http://dtrace.org/blogs/bmc/2012/08/01/post-revolutionary-op...
[2] http://smartos.org/2012/07/27/corporate-open-source-anti-pat...
From your second link, why do you think the licenses of DTrace and ZFS have limited their Linux popularity? Aren't their licenses compatible with (read: convertible to) the GPL?
At least with ZFS, no:
"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
"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
Thanks :)
The really interesting story is the how(linked from main article):
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...
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...
Part 3 is coming soon, about FAQ and numbers, but part2 is probably the most interesting one, indeed.
So every contributor essentially gets to vote on the license change, and their vote is proportional to the contribution they made (because if they vote no, their contributed code has to be rewritten).
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.
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.
I did delete some code, and rewrote some. But not for many people.
Was there any single person with enough of a contribution that if they'd said no, you'd have abandoned the idea of a license change?
Yes, a lot of them.
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.
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.
Imagine trying to do this for something like the linux kernel, it would be nearly impossible.
This is modules, not core. Core was last year: http://git.videolan.org/?p=vlc.git;a=commit;h=36ab287e77e9df...
Does this mean VLC will be back on the App Store? I remember it being pulled due to a contributor (who around ~2010 worked for Nokia) complaining to Apple.
Possibly, yes. But so far, iOS aout and vout are not LGPL.
You're saying that iOS about and bout must be LGPL first before there can be a VLC app in the iOS App Store? That goes against my idea of the point of LGPL, but I could well be wrong. I thought I could interface non-LGPL code with it.
The audio output and video output are still GPL, so far. Maybe this was not clear enough.
Oh, you mean in VLC lib itself. BTW, will there be a "static link exception" for the iOS App Store?
I am not sure to understand what you mean, to be honest.
Look for "Static Library Exception"
http://multinc.com/2009/08/24/compatibility-between-the-ipho...
http://multinc.com/2009/08/24/compatibility-between-the-ipho...
Congratulations to Jean-Baptiste, that's been an incredible arduous piece of work for him.
Thanks a lot :)
On a reading of how it was done, I guess if anyone had contributed stuff under the GPL and particularly objected to LGPL relicensing the could probably still make arguments about derivative works...
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.
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.
The commit message includes in its list of modules which are not converted:
- 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.
- 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.
Rip out that stuff, replace it anew.
> On a reading of how it was done, I guess if anyone had contributed stuff under the GPL and particularly objected to LGPL relicensing the could probably still make arguments about derivative works...
Read part 1 and 3
> 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.
> 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.
> Read part 1 and 3
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.
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.
> I'm just saying that imagine (in a hypothetical situation) there is a large code module written by an original author under the GPL.
This is not the case here. And part 1 explains exactly this, with the git log part.
Part 3 will close the loop altogether.
This is not the case here. And part 1 explains exactly this, with the git log part.
Part 3 will close the loop altogether.
Good for them, I guess. Though VLC's popularity still makes me pretty sad and how better video players like MPC-HC (on Windows) and mplayer/mplayer2 (on everything else) are much more unknown in comparison. I mean, most of VLC's development outside of the streaming stuff has been about playing catch-up with these two for years.
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...
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...
VLC has been able to handle pretty much anything you throw at it for many years and always been available across diverse platforms. It's an awesome product.
Why so negative?
Why so negative?
The main reason, is that VLC is too mainstream...
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.
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.
That's nice and all, except that I quite specifically wrote that equally simple yet better solutions exist.
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!
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!
It's not like every alternative requires hours of configuration. Download CCCP or SMplayer, push the button, and you're go.
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.
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.
I have to ask. Do you frequent /g/?
No. I am quite too busy for that...
Sorry, what is /g/ ?
Because better and equally free and open source alternatives have existed for about as long yet remain more unknown. VLC sure plays a lot of things, but it's a a real jack of all trades and master of none.
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 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...
What does other players do better than vlc?
Video quality for one.
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. :)
[1]: http://forum.doom9.org/showthread.php?t=146228
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. :)
[1]: http://forum.doom9.org/showthread.php?t=146228
VLC struggles with DVD playback. In fact most DVDs this year will simply not play at all in VLC due to the menus causing it to crash.
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.
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.
The audio drivers for my on-board soundcard are shit.
I'm using Arch Linux and PulseAudio.
VLC and Skype (but only these two) exhibit the problem of a crackling echo when playing sound which sometimes fixes itself. Since there's only two applications that exhibit this problem and
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
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
Subtitle rendering (with xy-vsfilter/vsfilter in general and newer versions of libass).
High-quality video rendering (madVR).
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.
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.
Subtitles rendering of VLC 2.0.x is quite high quality, since the video output changes of 2.0.
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.
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.
>Subtitles quality has nothing to do with libass
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.
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.
"jack of all trades" = superior product
"master of one" = inferior product
see also: Worse Is Better, Innovator's Dilemma
"master of one" = inferior product
see also: Worse Is Better, Innovator's Dilemma
The difference here is that the better players also play a similarly wide range of formats (since it generally all comes down to libavcodec at some point), but due to various factors they overall do it better. I keep VLC installed for testing purposes and as a backup were my main playback setup with MPC-HC ever fail to play something, but I've never actually had to resort to VLC for this reason.
"the better players also play a similarly wide range of formats"
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 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 :)
VLC has always lagged behind in proper x264 decoding. For most of the 1.x and the first few versions of the 2.x series I had dozens of video files with visual artifacts whilst the newest versions of mplayer at the time did not.
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.
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.
No software is perfect. However, for H.264 (x264? sigh) decoding VLC 2.x with multi-threaded decoding should eat all the files without issues (no reports so far).
MPC-HC is a good player on Windows, but VLC 2.0.x has been better in my experience. MPC-HC cannot handle some files that VLC plays fine, and I have not noticed any video quality difference between the two. I have stuck with CCCP for MPC-HC, which requires putting a bit more time into MPC-HC than just downloading VLC.
There are some files that MPC-HC does play that VLC does not, but these are fewer in my experience than the reverse case.
There are some files that MPC-HC does play that VLC does not, but these are fewer in my experience than the reverse case.
If you could send us the files, that would be very welcome :)
Sun RPC should be mentioned here.
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
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
See also this post on Mozilla relicensing:
http://blog.gerv.net/2006/03/relicensing_complete/
http://blog.gerv.net/2006/03/relicensing_complete/
Wait, doesn't the LGPL require users to be able to substitute their own compiled version?
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
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
LGPL (let's stick with version 2.1 for now) gives you a set of options for a "work that uses the library".
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.
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.
From section 6 of LGPL 2.1: http://www.gnu.org/licenses/lgpl-2.1.html
""" 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?
""" 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?
Yes, I do. It's pretty evenly divided as to whether lawyers believe this requires giving away signing keys. It's certainly not a simply cut and dry issue like you present it here.
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.
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.
I think you mean LGPL where you say iOS in the first sentence.
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.
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.
1. Apple distributes source to the LGPL pieces, so that is not an issue for them.
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".
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".
Well, stop reading the LGPL interpretation, and start reading the LGPL itself - it is written in English (rather than legalese) and is very clear on most subjects.
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).
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).
That's a shame.
Why is it a shame?
Because while every piece of free software is a wound against proprietary software, the more liberal licences like LGPL and the BSD/MIT-style licences are a wound against free software: proprietary interests can take free code without giving anything back.
Most people write code so it can be used. They don't care about wounding anything. If the choice is between having your code being used or having no one use it, most people will chose the more liberal licenses.
>Because while every piece of free software is a wound against proprietary software, the more liberal licences like LGPL and the BSD/MIT-style licences are a wound against free software
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.
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.
>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.
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).
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).
>All it takes is to list projects like Linux and GCC to show that yes, companies can give something back just fine with GPL.
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.
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.
That most of such analyses on the purpose of people choosing between BSD/GPL are mostly based on the presumption of imaginary or hypothetical reactions of human rather than solid data from real world, renders these analyses less convincing as such assumptions on human behaviours are very likely to be wrong.
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".
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.
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.
>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.
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.
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.
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.
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.
>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).
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).
> 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.
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.)
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.)
I think the fundamental disconnect here is that many people think the freedom you mention is not some sort of moral right.
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 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.)
The freedoms represent an ethical issue---that software developers have unprecedented control over their users. Why should I, as a hacker, be able to tell you what you can and cannot do with your device? Furthermore, it raises deep privacy issues---what kind of data am I collecting and why should I have that data?
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.)
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.)
>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
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.
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.
Mixing the concepts of functionality and freedom into one concept do not work.
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.
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.
What proprietary software does those things? It sounds like you're throwing out absurd imaginary examples to support a position.
Adding ads or sending videos to be accepted by a copyright central are not very far away. Youtube already does this. If the video editing tool was bundled exclusively with youtube (a extreme an absurd concept I know), the examples would be instantly true. So far, I don't know of any video editing tool directly connected to youtube, but then I haven't checked on every video editing tool on iphone and android. I would be surprised if there didnt exist at least one.
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.
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.
>Mixing the concepts of functionality and freedom into one concept do not work.
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 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.
BSD is used exactly because you can hide your improvements from others. You can hide the code of your proprietary extensions.
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.
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.
With the MIT license, proprietary interests have the option of giving something back without having to give all back.
Which very often happens.
Which very often happens.
> proprietary interests can take free code without giving anything back.
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.
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.
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
rms agrees with you: http://lwn.net/2001/0301/a/rms-ov-license.php3
Yes, they can, which doesn't mean they will.
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?
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?
Citing a comment made by a lawyer several years ago. First ask oneself what situations you dont want to be in, and then prepare yourself for it.
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.
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.
Nothing in the GPL prevents such uses.
Well, GPL do prevent the production of an proprietary video player based on GPL code.
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.
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.
Your GPLed video player wouldn't stop that in the least. Were I a government in such a situation, I could very easily either claim sovereign immunity to any sort of copyright questioning, or I could write a function that monitors what files were opened by the user that used well-exposed file system APIs, like inotify. The GPL would not stop human rights abuses at all.
The idea of a nation-state considering itself bound by the GPL is absurd.
Only users can keep themselves safe -- developers can't.
Only users can keep themselves safe -- developers can't.
The nation-state might consider itself as above the law, but the contracted company who got the job to develop the player might think twice before breaking the law.
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!".
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!".
But the trade-off comes with an influx of developers and developers love to open source as much as they can (Microsoft and CodePlex being a decent example of a monolithic propriety beast being led toward open source by its developers).
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.
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.
> proprietary interests can take free code without giving anything back.
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.
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.
My Visio TV has GPLd and other more open code in it (libmpeg2, among others like libpng and libtiff). The manual states something like "As required by law, you can log on to our website and request a CD of the code running on this machine for a manufacturing fee, blah blah".
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.
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.
The GPL is not about giving code back. It's about giving forward.
The wittiest thing I read today was at the very bottom of a HN discussion, whooshing over people's heads :)
Lots of efforts that otherwise could have been used on something more productive.
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.
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.
Every time a GPL related post comes up, it always reminds me of the sqlite project, and how the world could be simpler without those weird licenses.
http://www.sqlite.org/copyright.html
http://www.sqlite.org/copyright.html
That's all well and good, but the GPL is set up to address problems that the authors saw, that public domain licensing does not - mainly that they thought users should have the right to obtain the source to the stuff running on their machines.
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.
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.
In general you cannot place your work under public domain because in many countries (including in the U.S. with some exceptions) the work must enter the public domain by itself after the copyrights expired. The copyright term also differs of course from country to country. Even worse, there are jurisdictions in which the public domain is not recognized.
Did you even read the link?
> 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.
> 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.
This mean that VLC could be back on the AppStore.
Be aware that the LGPL still has some pitfalls in store here:
http://multinc.com/2009/08/24/compatibility-between-the-ipho...
http://multinc.com/2009/08/24/compatibility-between-the-ipho...
An analysis of 2009 on the App Store is totally obsolete, knowing that the ToS change every couple of months.
Which AppStore? Isn't it already available on Google's AppStore?
iTunes App Store, GPL is incompatible so it was pulled by request, I've still got a copy on my iPad though.
I've downloaded VLC and XBMC when they were both available in the App Store, hod do I re-download? They dont appear in the "purchased" section
Ir they don't show I'm the purchased section they might be gone forever, I kept a backup of the IPA file.
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" :)