Re: [Xen-devel] [Qemu-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

[Kevin Davis]

> 
> On 09/10/2015 08:14 PM, Kevin Davis wrote:
> >>
> > Ah.  I wasn't in the room when they figured it out.  And I've never seen
> their written opinion.  Is it documented somewhere?
> 
> which in turn leads to this FAQ:
> https://web.archive.org/web/20121116185559/http://lkml.org/lkml/2009/6/
> 26/314
> 
> So reading between the lines, IBM's opinion was that implementing a
> workaround that operates FAT in such a way that it never uses a common
> namespace was sufficient to avoid any legal questions about whether that
> code conflicts with a patent on a common namespace, sidestepping the
> longer question of any legal battle over the patent itself.
> 

Of course I have no comment on the legal opinion other than it is interesting 
and nice to have a pointer to it.

Thanks for the pointers

> --
> Eric Blake   eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

[Daniel P. Berrange]

On Wed, Sep 09, 2015 at 05:41:59PM -0700, Jordan Justen wrote:
> On 2015-09-09 16:05:20, Andrew Fish wrote:
> > 
> > > On Sep 9, 2015, at 3:24 PM, Jordan Justen  
> > > wrot> > > FWIW, I don't mind if the consensus is that GplDriverPkg must 
> > > live in
> > > a separate repo. But, it would be nice to hear a good reason why it
> > > must live elsewhere.
> > 
> > Because GPL is not a permissive license. An accidental git grep and
> > copying some code can change the license of the code that gets the
> > GPL code pasted into it.
> 
> I like this argument. It is slightly tempered by the fact that git
> grep always shows the source path, and thus 'GplDriverPkg' would be
> obviously visible.

Plenty of projects have a scenario in which different parts of their
codebase are under different licenses, without there being undue
problems. If you make it clear by having a separate directory, then
I think you can ultimately credit the developers with having enough
intelligence to do the right thing here. If not, then I'd probably
question whether you can trust them to submit any code at all, as
they could equally have blindly copied it from a 3rd party project
under an incompatible license.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

[Dr. David Alan Gilbert]

* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Wed, Sep 09, 2015 at 05:41:59PM -0700, Jordan Justen wrote:
> > On 2015-09-09 16:05:20, Andrew Fish wrote:
> > > 
> > > > On Sep 9, 2015, at 3:24 PM, Jordan Justen  
> > > > wrot> > > FWIW, I don't mind if the consensus is that GplDriverPkg must 
> > > > live in
> > > > a separate repo. But, it would be nice to hear a good reason why it
> > > > must live elsewhere.
> > > 
> > > Because GPL is not a permissive license. An accidental git grep and
> > > copying some code can change the license of the code that gets the
> > > GPL code pasted into it.
> > 
> > I like this argument. It is slightly tempered by the fact that git
> > grep always shows the source path, and thus 'GplDriverPkg' would be
> > obviously visible.
> 
> Plenty of projects have a scenario in which different parts of their
> codebase are under different licenses, without there being undue
> problems. If you make it clear by having a separate directory, then
> I think you can ultimately credit the developers with having enough
> intelligence to do the right thing here. If not, then I'd probably
> question whether you can trust them to submit any code at all, as
> they could equally have blindly copied it from a 3rd party project
> under an incompatible license.

Many companies dont trust their engineers to do that, and have painful
review processes to stop their engineers stupidly copying closed
code into open projects; and in general they're needed because the
engineers would do it if they weren't stopped.

Dave

> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

[Eric Blake]

On 09/10/2015 08:14 PM, Kevin Davis wrote:
>>
>>
>> On 10/09/2015 16:24, Kevin Davis wrote:
>>> Further leading me to guess that any actual use of those
>>> implementations could lead to you actually needing to hire a real
>>> attorney and not one that you find on YouTube.
>>
>> The good thing is that attorneys have already figured it out.  IBM figured 
>> out
>> a few years ago how to work around Microsoft's patents, and that's how
>> FAT32 (and more specifically long file names) are implemented in Linux.
> 
> Ah.  I wasn't in the room when they figured it out.  And I've never seen 
> their written opinion.  Is it documented somewhere?

A bit of wikipedia reading turns up these indirect documentations of the
solutions:
http://arstechnica.com/information-technology/2009/07/vfat-linux-patch-could-circumvent-microsofts-patent-claims/
https://web.archive.org/web/20130131034455/http://www.desktoplinux.com/news/NS4980952387.html

which in turn leads to this FAQ:
https://web.archive.org/web/20121116185559/http://lkml.org/lkml/2009/6/26/314

So reading between the lines, IBM's opinion was that implementing a
workaround that operates FAT in such a way that it never uses a common
namespace was sufficient to avoid any legal questions about whether that
code conflicts with a patent on a common namespace, sidestepping the
longer question of any legal battle over the patent itself.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

[Andrew Fish]

> On Sep 10, 2015, at 8:44 PM, Kevin Davis  wrote:
> 
>> 
>> On 09/10/2015 08:14 PM, Kevin Davis wrote:
 
>>> Ah.  I wasn't in the room when they figured it out.  And I've never seen
>> their written opinion.  Is it documented somewhere?
>> 
>> which in turn leads to this FAQ:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__web.archive.org_web_20121116185559_http-3A__lkml.org_lkml_2009_6_=BQIGaQ=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=mhYwzTqxMG2tM5He0exVnKYSFG58txsY87BTZP3pIqo=LKChPDVsVauW8_4ZGz2OukddijAHxwPZhnjeXQZCW5I=
>>  
>> 26/314
>> 
>> So reading between the lines, IBM's opinion was that implementing a
>> workaround that operates FAT in such a way that it never uses a common
>> namespace was sufficient to avoid any legal questions about whether that
>> code conflicts with a patent on a common namespace, sidestepping the
>> longer question of any legal battle over the patent itself.
>> 
> 
> Of course I have no comment on the legal opinion other than it is interesting 
> and nice to have a pointer to it.
> 
> Thanks for the pointers
> 

This history of issues is why we should remove the binary FAT driver from the 
common repo, so we accommodate the realities of all the down stream partners. 

Thanks,

Andrew Fish

PS Nice to see the FOSS and traditional PC folks learning from each other on 
the list.

>> --
>> Eric Blake   eblake redhat com+1-919-301-3266
>> Libvirt virtualization library 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__libvirt.org=BQIGaQ=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=mhYwzTqxMG2tM5He0exVnKYSFG58txsY87BTZP3pIqo=-yJzLpdTqQeS_UK_JwAuIFrCqfdN48GJH6q_ljHnfI8=
>>  
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel