Re: [Duplicity-talk] GPL-3

[edgar . soldin]

On 13.04.2011 19:51, Joe MacDonald wrote:
> 
> 
> On Tue, Apr 12, 2011 at 4:18 AM, <address@hidden <mailto:address@hidden>> 
> wrote:
> 
>     On 11.04.2011 19:30, Joe MacDonald wrote:
>     >
>     > I can't speak for anyone else, but as a distro vendor (my day job, not 
> at this email address) a move to GPLv3 would mean I wouldn't be doing any 
> further upgrades in our package and eventually it would get removed.  I've 
> got absolutely no say in our policy on licenses but anything GPLv3 is 
> specifically forbidden by our legal department (and explicitly stated as to 
> be excluded by some of our customers).
> 
>     could you find out the reasons for 'banning'. waht distro are you talking 
> about?
> 
> 
> There's actually a number of reasons but they all amount to something like 
> "we are writing proprietary code and don't want to be forced to open-source 
> any of it".  Not that they're using anything inappropriately, but that they 
> have, for example, in-house hardware and in-house drivers or software for it 
> that they don't want to share.  So they want to be certain that the operating 
> system they are buying will not introduce any risk of them having to open 
> their code.  I don't think it's really appropriate for me to talk about my 
> employer or our customers here, but we're an embedded linux distribution that 
> you'd be able to find reasonably easy with Google.  I'm doing my best to help 
> us navigate GPLv3 issues right now (obviously, long term ignoring the issue 
> won't work) but today the only option I have is to simply not include 
> anything GPLv3.
> 

relicensing duplicity to gpl3 does _not_ result in a heighten enforcement to 
open closed software. gpl2 and gpl3 are comparable in this regard.
_only_ if you are distributing duplicity by using it in your distro, you will 
have to supply the distro customers with the (modified) duplicity sources 
(that's identical for gpl2/3).

regarding in-house software. any modification used only in-house, meaning not 
distributed to a third party, is not enforced to be open by gpl, that's up to 
you.

the only 'threat' might be the patent issue. check
http://www.gnu.org/licenses/gpl-faq.html#v2OrLaterPatentLicense
not for the issue, but for the understanding. if your companies modification 
uses patented know-how (even licensed from a third party), you will obviously 
have to publish the modified sources if you distribute the software to your 
customers. usually you will license the patented technology to them for usage.

the new gpl3 says now: you cannot license only to your customers, but instead 
have to license it to _all_ users of the new modified open source software. if 
you don't you'll loose the right to use the software your work is based on. the 
whole modification is useless to the community if you limit it to your direct 
customers. it would make it impossible for the upstream to integrate your 
enhancements. kind of an intellectual tivoization here ;)

to say it in other words. if you want to be proprietary, also in intellectual 
aspects, you will have to write your own software from the scratch or use gpl2- 
software to base it on.

sounds fair to me. and to you?

>     > RMS' comments aside, is there particular reasons of interest to the 
> duplicity developers to move to v3 from v2+?  Just wondering.
> 
>     the mentioned
>     > reading (tivoization, patent protection, apache license compatibility)
>     > http://www.gnu.org/licenses/rms-why-gplv3.html
> 
>     convince at least me.
> 
> 
> Okay, I wasn't aware that there were patent protection issues or a strong 
> desire to be compatible with the apache license in duplicity.  Seriously, if 
> those are concerns, that's perfectly valid, I didn't mean to dismiss RMS' 
> arguments, I was just interested in what issues for duplicity would be 
> resolved by moving to GPLv3.
> 
> Thanks for the update.

there are no strong desires, i suppose, but the new possibility to include 
apache licensed code, plus protection from patent and tivoization threats - 
these will support duplicity as a project. these are real gains.
i of course also agree with linus torvald's point of keeping the user the 
freedom to use it any way, the user sees fits, including drm. but i strongly 
differentiate between end user and distributor and therefor, if somebody wants 
to tivoate at home, please do. but if a distributor thinks he can circumvent 
the right to use the software freely by allowing only signed versions, i 
strongly oppose.

regards ede/duply.net