Last Chance to Get VLC for iPhone/iPad? Likely to be Pulled from App Store?

[goosnarrggh]

The guy sent the complaint to Apple so they would remove the app from the store. They are the distributor, just like Ingram Micro distributes Apple stuff for Apple.

As for not stopping you in any way from porting it to Windows Mobile, that's not enough for the GPL. The App Store does add restrictions in the needing a digital signature from Apple or at the very least a developer certificate in order to compile and install the app. I quoted the relevant portions of the GPL and the FSF blog on the matter clarifies this even more.

I'm aware that GPLv3 talks about digital signatures etc. I'm not so sure about GPLv2.

The VLC source code specifically states that it can be distributed under the terms of either GPLv2 or, at the distributor's option, any later version of the GPL. In fact, the main reason why VLC hasn't moved on to use GPLv3 as the main baseline license going forward, is precisely because several contributors objected strongly to the notion of GPLv3's TiVo clause, and preferred the status quo of GPLv2.

They included the "or any later version" clause to accommodate any particular binary redistribution which needed to link against 3rd party libraries which weren't GPLv2-compatible (eg. they required the use of GPLv3). According to VLC's press release, the only library they've identified which might be a candidate for such a situation, is the Samba windows file sharing library. That's almost certainly not included in the iOS version of VLC.

Presumably, this particular distributor will choose to use the least stringent terms permitted by the copyright license, which in this case would appear to be the terms set forth in GPLv2. So, GPLv3's more stringent requirements are not necessarily binding on this distributor.

 

[KnightWRX]

I'm aware that GPLv3 talks about digital signatures etc. I'm not so sure about GPLv2.

But again, the FSF has talked in the past how the App store policies and DRM go even against the GPLv2. The blog post written back in May 2010 is linked in this very thread, multiple times. Adding restrictions on distribution is something that is prohibited even in the GPLv2, no need to resort to the added language for anti-tivoization of the GPLv3.

This is the crux of the argument. Some devs say it's a non-issue and doesn't roul afoul of the GPL, this dev believes it does, as does the FSF. This is an internal debate and it's a bit premature for outside forums to go balistic over this.

Let the project sort it out.

 

[rhett7660]

Not quite correct. There are three options:

- Convince yourself and possibly a judge that this guy's rights are not being infringed.
- Convince the guy that he should allow the app being in the iOS store even though he believes that his rights are infringed.
- Rewrite his contributions, essentially removing them from the project.

I personally think that he is wrong, mostly because it is not Apple doing the distributing, but the people who put the application onto the store. And they don't stop you in any way from taking the source code and porting it to Windows Mobile or whatever it is called, or trying to put a different version onto the iOS store.

Right and while we are at it get rid of the protection of garden fences so I can better harvest my neighbours carrots to get things done i.E. sell them on the market.

If six farmer create a farming community in which each member can freely harvest and sell produce and you are not a member then you can't just climb the fence and harvest and sell the produce. Or worse: Call for the fence to be torn down.

Even if there is a market place who's rules are incompatible with the six farmers believes. Even it it means you can't buy the produce at all. It is the farmers produce and they decide what to do with it and which rules you need to obey to be become a member of there community.

Back to the topic at hand: GPL is a community and harvesting and selling (GPL explicitly allows selling) is restricted to members of the community. And membership is restricted to those who are prepared to obey the GPL licence.

If you are not a member, don't want to play by our rules. Tough luck, play elsewhere.

M.

Hmmm.. This sounds strangely familiar.



KnightWRX

Question for you, since you seem to know a lot about this. When you talked about re-writing the code for this project and taking out the code from the person who is filing the claim. Does this code have to be completely different from the source code?
IE

source code example: 1+1=2
rewrite code example: .5+.5-.5+2-.5=2

I am just curious as to what would need to be done to have this issue null and void.

 

[goosnarrggh]

But again, the FSF has talked in the past how the App store policies and DRM go even against the GPLv2. The blog post written back in May 2010 is linked in this very thread, multiple times.

The FSF blog post I think you're referring to ("Why free software and the iPhone don't mix") only directly discusses the implications of the iPhone's app distribution model in relation to the GPLv3. Is there another post somewhere I haven't noticed which brings the analysis back to GPLv2?

 

[KnightWRX]

Hmmm.. This sounds strangely familiar.



KnightWRX

Question for you, since you seem to know a lot about this. When you talked about re-writing the code for this project and taking out the code from the person who is filing the claim. Does this code have to be completely different from the source code?
IE

source code example: 1+1=2
rewrite code example: .5+.5-.5+2-.5=2

I am just curious as to what would need to be done to have this issue null and void.

You're getting into something that's very hard to answer. If it was that easy, there wouldn't be tons of copyright lawsuits floating around. The general consensus is that interface and definitions are not covered under copyright law, but actual code is. So if his contributions were just re-arranging a few function calls around, then it's moot since copyright doesn't really apply (you can't change function calls, the name of the function is what it is).

However, if he has a few functions he's written entirely, you'd have to change internal variable names, switch the algorithm around a bit and use some different mecanisms to make it different enough. The best thing would be to take someone that wasn't tainted (didn't see the original code) and ask him to rewrite the parts by just presenting a list of needs.

If the dev gets pissed off enough and pursues this, it's going to be on a case by case basis and depend on the judge/jury/jurisdiction/law. Copyright is a complex beast.

The FSF blog post I think you're referring to ("Why free software and the iPhone don't mix") only directly discusses the implications of the iPhone's app distribution model in relation to the GPLv3. Is there another post somewhere I haven't noticed which brings the analysis back to GPLv2?

Actually, I'm not sure it only applies to the GPLv3, this paragraph for example :

http://www.fsf.org/blogs/community/why-free-software-and-apples-iphone-dont-mix

Apple's approach runs headlong into an important part of the GPL's copyleft approach — the principle that anytime someone shares a copy of a GPL-covered program with another person, she also needs to provide that person with the installable, human-readable source code for that program.

This clause is part of the GPLv2 :

http://www.gnu.org/licenses/gpl-2.0.html

3.
...
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.

Seems to me the crux of the issue is the language of paragraph 3 whereas the scripts to control installation of the executable need to be included in the source code, yet no developers can have access to Apple's signing code.

 

[hchung]

Disclaimer: I'm not a fan of the GPL, but I don't know all the details of it either.
Hence, I have a few questions.

1a) Why is iTunes signing considered unacceptable restriction? Isn't GPL a license all about distributing the source to keep it open? Not the binary?

1b) Why does this not affect Tivo and Linux kernel?

1c) Why does the device matter? The code is first and foremost compatible with any install of the Xcode/iPhone SDK, with no signing.

2) How is this any different from a GPL'd app on Windows? Afterall, you'd need to buy the tools in order to compile and distribute a binary, right?

 

[goosnarrggh]

Disclaimer: I'm not a fan of the GPL, but I don't know all the details of it either.
Hence, I have a few questions.

1a) Why is iTunes signing considered unacceptable restriction? Isn't GPL a license all about distributing the source to keep it open? Not the binary?

The GPL was written under the basic assumption that the binary form of an application is basically just a mechanical derivative work of the original source code, and that copyright over the binary form still belongs to the same people who own the copyright over the source code. It is specifically designed to be used by people who want to exercise control over both binary and source code distribution.

1b) Why does this not affect Tivo and Linux kernel?

For the Linux kernel, the answer is fairly simple: Even if the GPL may have been technically breached, it is still up to the copyright holder to complain about it. The principal copyright holder of Linux, Linus Torvalds, has gone on record as saying that he doesn't care if Linux is linked with non-free device drivers. Until he decides to file a complaint, and it is fairly obvious that never intends to do so, it stands to reason that nobody is going to be sued for using proprietary device drivers in Linux.

But that's really a separate issue from that of TiVo (and iOS). In the case of Linux, you have a situation where the end-user is being granted extra flexibility to do even more things than the letter of the license would otherwise allow.

In the case of TiVo (and iOS), you've got a situation where the user's flexibility is being limited to doing fewer things than the license had been intended to permit: the user has prepared their derivative work, but they still don't have the necessary tools to install their derivative work and make use of it.

1c) Why does the device matter? The code is first and foremost compatible with any install of the Xcode/iPhone SDK, with no signing.

Ultimately, I think this part of the issue is going to prove to be important. The modified software can still be installed on any iPhone, provided the recipient of the software has purchased the "full version" of the compiler suite. (In this case, I consider the free Xcode tools to be a "trial version" until you've paid the $99 to join the developer program and get the ability to self-sign code for personal use and for ad-hoc distribution.)

The GPL doesn't say anywhere that the compiler you use to produce the modified binary has to be free.

2) How is this any different from a GPL'd app on Windows? Afterall, you'd need to buy the tools in order to compile and distribute a binary, right?

Microsoft provides the commandline tools necessary to compile any software for Windows for free. They charge extra for the fancy graphical IDE. But that still doesn't matter, because there are also 3rd party alternative compilers which target Windows as well.

Ultimately, the difference comes from the fact that Windows doesnt' impose any restrictions, such as digital signatures, which would prevent any particular piece of (otherwise compatible) software from being run on any particular computer system. Where digital signatures do exist in Windows, they are generally optional. And it is possible to distribute tools to self-sign any mandatory digital signatures such as 64-bit device drivers.

 

[KnightWRX]

The GPL was written under the basic assumption that the binary form of an application is basically just a mechanical derivative work of the original source code, and that copyright over the binary form still belongs to the same people who own the copyright over the source code. It is specifically designed to be used by people who want to exercise control over both binary and source code distribution.

That's not quite right. Copyright law is what determines what is copyrighted or not, not the actual license. Copyright law is about works as a whole, not parts. A binary is part of that work, the source code is another part. Both fall under copyright law.

The GPL is a copyright license, it grants distribution rights of a work (the right to copy) above and beyond what the law determines you can do with it (contrary to EULAs which further restricts your rights under copyright law).

The GPL is a distribution license in that it grants you rights to distribute derivatives and the original work under some conditions.

Ultimately, I think this part of the issue is going to prove to be important. The modified software can still be installed on any iPhone, provided the recipient of the software has purchased the "full version" of the compiler suite. (In this case, I consider the free Xcode tools to be a "trial version" until you've paid the $99 to join the developer program and get the ability to self-sign code for personal use and for ad-hoc distribution.)

The GPL doesn't say anywhere that the compiler you use to produce the modified binary has to be free.

This is not the point. What is being breached is the language about having all the scripts to control the installation the executable included in the source distribution. You cannot distribute the signing code, only Apple can. You cannot distribute a modified binary either, as Apple has a veto right with the approval process and needs to sign it (another part of the installation). The fee is not the problem at all. As you said, the GPL doesn't care about fees, you can even charge for the software itself.

Microsoft provides the commandline tools necessary to compile any software for Windows for free. They charge extra for the fancy graphical IDE. But that still doesn't matter, because there are also 3rd party alternative compilers which target Windows as well.

Ultimately, the difference comes from the fact that Windows doesnt' impose any restrictions, such as digital signatures, which would prevent any particular piece of (otherwise compatible) software from being run on any particular computer system. Where digital signatures do exist in Windows, they are generally optional. And it is possible to distribute tools to self-sign any mandatory digital signatures such as 64-bit device drivers.

This last paragraph is why it doesn't matter on Windows, not the cost of any software.

 

[goosnarrggh]

This is not the point. What is being breached is the language about having all the scripts to control the installation the executable included in the source distribution. You cannot distribute the signing code, only Apple can.

But if the recipient already has the "full version" compiler, then they don't need any additional signing code to install their software on their own iPhone, nor to ad-hoc distribute it to others. From this perspective, the signing code is actually part of the compiler, not part of the software being distributed.

You cannot distribute a modified binary either, as Apple has a veto right with the approval process and needs to sign it (another part of the installation).

You absolutely have full permission to distribute the modified binary. It's just that nobody else will have the technical ability to install the modified binary on their own iPhone. But, with the corresponding source code, and a "full version" compiler, they can still produce the exact same binary, and install that result on their own iPhone without being subject to Apple's veto.

 

[KnightWRX]

But if the recipient already has the "full version" compiler, then they don't need any additional signing code to install their software on their own iPhone, nor to ad-hoc distribute it to others. From this perspective, the signing code is actually part of the compiler, not part of the software being distributed.

That is an added restriction, having to obtain signing keys from Apple. You cannot redistribute these which is required in the language in paragraph 3. I already answered this many times. This is how the FSF sees it, this is how Remi sees it.

It doesn't matter that you can do it ultimately, what matters is that it's an extra restriction on distribution, which goes against the letter of the license and thus puts you in breach.

You absolutely have full permission to distribute the modified binary. It's just that nobody else will have the technical ability to install the modified binary on their own iPhone.

Which kind of defeats the right to distribute in the first place, the crux of the argument really.

It's easy : Don't use the GPL for software that goes on the App Store.

 

[goosnarrggh]

That is an added restriction, having to obtain signing keys from Apple. You cannot redistribute these which is required in the language in paragraph 3. I already answered this many times. This is how the FSF sees it, this is how Remi sees it.

It doesn't matter that you can do it ultimately, what matters is that it's an extra restriction on distribution, which goes against the letter of the license and thus puts you in breach.

You wouldn't complain that there's been a GPL violation if somebody tried and failed to compile a program written in C++ using a Pascal compiler. You have to use the right tool for the job.

Similarly, the right tool for the job of self-installing an iOS application is the self-signing, ad-hoc distribution version of the compiler.

GPLv2 says you have to include instructions on how to install the modified binary on your machine.

So, if the required "installation instructions" includes a step-by-step list of instructions to ensure that the recipient is using the correct toolset (in this case, that would be the self-signing, ad-hoc distribution version of the compiler), then surely they've complied with at least the GPLv2's requirements?

 

[KnightWRX]

You wouldn't complain that there's been a GPL violation if somebody tried and failed to compile a program written in C++ using a Pascal compiler. You have to use the right tool for the job.

Why would the Makefile or project file included in the source point to Pascal compiler instead of a c++ compiler ? Read the license again, you have to include all scripts that control compilation and installation. So if the Makefile worked for you and you explain the proper tools required, it will work for anyone.

Again, it's not about the tools themselves, it's about the scripts. The Apple signing scripts and the required keys cannot be distributed.

GPLv2 says you have to include instructions on how to install the modified binary on your machine.

Again, why are you saying false things about the GPL when the text is available freely online ? It says you need to include all the control scripts :

http://www.gnu.org/licenses/gpl-2.0.html

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.

I don't see how this is so hard to grasp. This is the core of Remi's complaint and the FSF's explanation of the App Store model. The required scripts/keys to sign the executable cannot be redistributed along with the source, hence you cannot provide the full chain to control the installation. BTW, the fact that you need the proper kernel/libraries/compiler is covered later and is not a requirement in the distribution of the source code :

However, as a special exception, the source code 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.

The FSF doesn't see the signing keys/scripts as falling under this obviously. Read their blog post again on the subject. It's been posted many times.

Kinda tired of going around in circles about this, this is not up to us to decide. The FSF wrote the license, they have legal counsel from fellows that are very well versed in copyright law (Eben Moglen), so I tend to think they have a small clue as to what it is they are talking about. It's not up to the VLC project as a whole to see how to deal with Remi's complaint. In the end, the copyright is his and any final decision will rest on him if the VLC project doesn't want to just remove all his contributions.

 

[hchung]

I'm still confused.

Everybody's talking about signing, but that's not the only way to run the source code. I can download an iOS app source code, and run it in the simulator. In this case, my target device is my Mac. There doesn't seem to be anything I can see that says because some people run it on the phone, everything is in the context of the phone. In this case, there's no signing involved.

Additionally, it appears that Xcode can make unsigned binaries for the phone. They still can't be installed directly on the phone, but can be signed by anybody who has signing keys. I would have assumed that all the tools to sign and install are part of the compiler suite.
But it's easily possible to make a build&install script that when executed in the presence of a properly configured compiler suite with keys, will do a build and install.

As for the keys, what dictates that the keys are part of the source and not part of the compiler?
I ask this partly because how is this different from license keys of the tools?
And if keys are covered in GPLv2, what's the point of GPLv3?

Why would the Makefile or project file included in the source point to Pascal compiler instead of a c++ compiler ? Read the license again, you have to include all scripts that control compilation and installation. So if the Makefile worked for you and you explain the proper tools required, it will work for anyone.

Again, it's not about the tools themselves, it's about the scripts. The Apple signing scripts and the required keys cannot be distributed.





Again, why are you saying false things about the GPL when the text is available freely online ? It says you need to include all the control scripts :

http://www.gnu.org/licenses/gpl-2.0.html


I don't see how this is so hard to grasp. This is the core of Remi's complaint and the FSF's explanation of the App Store model. The required scripts/keys to sign the executable cannot be redistributed along with the source, hence you cannot provide the full chain to control the installation. BTW, the fact that you need the proper kernel/libraries/compiler is covered later and is not a requirement in the distribution of the source code :



The FSF doesn't see the signing keys/scripts as falling under this obviously. Read their blog post again on the subject. It's been posted many times.

Kinda tired of going around in circles about this, this is not up to us to decide. The FSF wrote the license, they have legal counsel from fellows that are very well versed in copyright law (Eben Moglen), so I tend to think they have a small clue as to what it is they are talking about. It's not up to the VLC project as a whole to see how to deal with Remi's complaint. In the end, the copyright is his and any final decision will rest on him if the VLC project doesn't want to just remove all his contributions.

 

[goosnarrggh]

Why would the Makefile or project file included in the source point to Pascal compiler instead of a c++ compiler ? Read the license again, you have to include all scripts that control compilation and installation. So if the Makefile worked for you and you explain the proper tools required, it will work for anyone.

And the "proper tools required" in this case is the XCode IDE/compiler suite, supplemented with the $99 Apple Developer Program's code self-signing utility. Your point is...?

Again, it's not about the tools themselves, it's about the scripts. The Apple signing scripts and the required keys cannot be distributed.
(...)
(rest of post omitted, but my comments are intended to be applied to the whole post in general.)

I'll bet money the vast majority of programs provided under the GPL do not include every script that went into producing the binary.

I'm also fairly certain that a good number of GPL'ed programs probably don't even include makefiles, for the simple reason that no makefile exists for the project because the original author never wrote one. This could be because the author would generally manually build the project directly trom the commandline, or it could be because their targeted compiling platform doesn't include the notion of makefiles. (In the former case, the GPL could easily be satisfied by simply saying that the relevant control script simply doesn't exist because this distribution's "preferred" method of building/installing the program is to do it manually. And here are the instructions to do it manually......)

Other scripts that actually do go into the building of the program are probably routinely omitted from GPL'ed programs. For example, linker scripts. Any GCC-based compiler (and this is true of many other compilers too) needs a linker script to convert any collection of 1 or more assembled object files into the final executable images. They aren't included with most programs' source code because the default scripts supplied with the compiler/operating system are perfectly adequate to do the job for the majority of projects.

If linker scripts can be excluded from the source distribution because they are already included as a component of the distribution's "preferred" compiler, I honestly don't see any difference for code-signing components of a compiler. It is obvious that the FSF disagrees. I don't buy their disagreement -- to me, it looks like they realized a hole in GPLv2, which they patched in GPLv3, and then they desperately tried to find a way to doublespeak the same argument back into GPLv2 when they realized that GPLv3 wasn't going to be as popular as they'd hoped.

Read their blog post again on the subject. It's been posted many times.

In specific response to this comment... Thank you very much for the reminder. I assure you, I have read it. Several times, in fact. It has failed to persuade me, each and every time.

 

[KnightWRX]

And the "proper tools required" in this case is the XCode IDE/compiler suite, supplemented with the $99 Apple Developer Program's code self-signing utility. Your point is...?

That you cannot then distribute the binary built with this method, another requirement of the GPL (the right to distribute the work must not have added restrictions). It's also the FSF's point, and Remi's point. You're arguing in circles. End of debate on my side.

Remi decided to pursue it, not all copyright holders are so pedantic.

 

[Hal Itosis]

Good golly miss molly... if there was anything in this whole mess that anyone was supposed to actually CARE ABOUT, it sure seems to have gotten lost somewhere in the past 4 or 5 pages.

 

[hchung]

That you cannot then distribute the binary built with this method, another requirement of the GPL (the right to distribute the work must not have added restrictions). It's also the FSF's point, and Remi's point. You're arguing in circles. End of debate on my side.

Remi decided to pursue it, not all copyright holders are so pedantic.

Actually... are we even sure we can't distribute the signed binaries?
I mean, there's a difference between restricted in distributing and restricted in installing. Signing only restricts installation.

 

[arnop]

Just downloaded it just in case but I'm pretty sure Apple will pull it out of the App Store...

 

[Bernard SG]

Just downloaded it just in case but I'm pretty sure Apple will pull it out of the App Store...

If they didn't pull it so far, I don't think they'll ever do it unless a successful legal action forces them to do so.

 

[neccoloup]

old bump but the app was removed today, along with a very smug response from the nokia employee who petitioned to have it removed

There's no app for that (anymore).
At last, Apple has removed VLC media player from its application store. Thus the incompatibility between the GNU General Public License and the AppStore terms of use is resolved - the hard way. I am not going to pity the owners of iDevices, and not even the MobileVLC developers who doubtless wasted a lot of their time. This end should not have come to a surprise to anyone.
January 07, 2011 09:15 PM

 

[AidenShaw]

music please:

old bump but the app was removed today, along with a very smug response from the nokia employee who petitioned to have it removed

There's no app for that (anymore).
At last, Apple has removed VLC media player from its application store. Thus the incompatibility between the GNU General Public License and the AppStore terms of use is resolved - the hard way. I am not going to pity the owners of iDevices, and not even the MobileVLC developers who doubtless wasted a lot of their time. This end should not have come to a surprise to anyone.
January 07, 2011 09:15 PM

Cue Pink Floyd -

"...all in all, it's just another brick in the wall(ed garden),
all in all, you're just another brick in the wall(ed garden)"​

http://en.wikipedia.org/wiki/Another_Brick_in_the_Wall#Part_II

 

[JeffDM]

old bump but the app was removed today, along with a very smug response from the nokia employee who petitioned to have it removed

There's no app for that (anymore).
At last, Apple has removed VLC media player from its application store. Thus the incompatibility between the GNU General Public License and the AppStore terms of use is resolved - the hard way. I am not going to pity the owners of iDevices, and not even the MobileVLC developers who doubtless wasted a lot of their time. This end should not have come to a surprise to anyone.
January 07, 2011 09:15 PM

I would mourn the loss if it was any good. At least, it's not very good on Windows, Mac or iOS. It probably works better on Linux and related platforms. It's nice to have if nothing else can play a file, but I only keep it as a last resort. However, it's a dick move to not say anything until all the work is done and after it's been on the store, I get the impression that there was plenty of time to speak up, but the objection wasn't raised until after the project was done.

 

[rhett7660]

I would mourn the loss if it was any good. At least, it's not very good on Windows, Mac or iOS. It probably works better on Linux and related platforms. It's nice to have if nothing else can play a file, but I only keep it as a last resort. However, it's a dick move to not say anything until all the work is done and after it's been on the store, I get the impression that there was plenty of time to speak up, but the objection wasn't raised until after the project was done.

Imagine that. Waiting for it it is done. The guy comes off sounding like a total prick. I have a feeling it will be back. Maybe under a different name or something along those lines!!

I use VLC on both Win and Mac... I haven't had any problems with it.

 

[JeffDM]

I use VLC on both Win and Mac... I haven't had any problems with it.

With some video files, all I needed to do for most videos is click on or slide the scrubber bar to jump to a part of the video, say click half way, the video playback is often hosed. It does look like the very latest update fixed that problem with my test files. The DVD playback has improved, is still a bit clumsy, it will show the unix device name in the menu, which isn't a good idea when when it could show the name of the disc. The player crashes too often on a DVD as well.