[vlc-devel] GPLv3 again

[Neil Woodall]

As the top technical person in a company that makes IC for TV's (and  
other devices) and supplies software to run those TV's, the anti TIVO  
portion of GPLv3 will cause a lot of problems. We are now seeing  
customer acceptance of using Linux as an OS for the devices, but if  
GPLv3 means that we have to supply enough of the source code to allow  
unrestricted use of the hardware...that could be a problem. When the  
user installs their own software and the TV breaks, is it a hardware  
defect or a software defect...and how do you prove that it's because  
someone replaced the software with their own? If the user installs  
software that bypasses DRM, does that break the license for the TV  
set manufacturer and cause them not to sell TV's with that feature  
anymore? Consumer embedded devices typically require a lot of IP  
licenses to make them useful. Violating one of those licenses in a  
way that causes it to be withdrawn from the manufacturer could make  
the device useless and force the manufacturer to stop selling the  
product.

All GPL3 will do is reduce the momentum that Linux is gathering for  
use in embedded devices, so my feeling is that GPL3 will result in  
less user modifiable devices than more.


On Jul 20, 2007, at 7:58 AM, Rémi Denis-Courmont wrote:

> [Starting a new thread, 'cause I lost the original one]
>
> 	Hello,
>
> From my reading, these are the main difference from GPLv2 to GPLv3  
> that
> I've spotted (this is not an excuse for not reading yourself):
>
> * It is less US-centric; in particular, the liability disclaimer  
> may now
> be viable in France and other countries with strong consumer
> protection.
>
> * It solves a bunch of silly license incompatibilities, such as with
> preservation and advertisement of legal notices. For instance, I think
> that would allow linking against OpenSSL or recent faad.
>
> * The patents language is more explicit, though not much stronger. In
> any case, it is surely better for those without patents (including
> most, if not all, significat VLC developpers).
>
> * The DRM language is not as political as it used to be. What is  
> left is
> merely a protection of users from copyright holders. I *think* this is
> good, consistent with my opinion that you cannot build proper DRM with
> GPL code (if at all anyway), while I really did not like the text in
> earlier drafts.
>
> * To me, the anti-TiVo stuff is the most arguable. Basically, you have
> to give users sufficient informations to replace GPL software with
> their modified variant on any device, including embedded ones. As a
> user of embedded devices, I like that.
> But as an author of software that may end up on embedded devices, I am
> not so positive. Afterall, so long as the device vendor gives me its
> source code modifications back to me, I do not really care whether its
> users can change the binary code on their device. I am considering
> putting a "special exception" against this on my own GPL'd software,
> but this is not possible for VLC, since there are too many copyright
> holders at stake.
>
> As Sam pointed out, it is likely that we will be forced to switch
> anyway, sooner rather than later, as any of dependencies switch to
> (L)GPLv3. libsmbclient is a known case, but it is not a very important
> dep.
>
>
> With these considerations in mind, I support switching future releases
> of VLC to GPLv3+ (assuming GPLv3 is accepted as DFSG-free), and other
> VideoLAN software to (L)GPLv3+ as appropriate.
>
> Regards,
>
> -- 
> Rémi Denis-Courmont
> http://www.remlab.net/
> _______________________________________________
> vlc-devel mailing list
> vlc-devel at videolan.org
> http://mailman.videolan.org/listinfo/vlc-devel

_______________________________________________
vlc-devel mailing list
vlc-devel at videolan.org
http://mailman.videolan.org/listinfo/vlc-devel