SFLC: A Wake-Up Call for GPLv3 Migration

Posted Apr 17, 2009 21:06 UTC (Fri) by alankila (guest, #47141)
In reply to: SFLC: A Wake-Up Call for GPLv3 Migration by mmarq
Parent article: SFLC: A Wake-Up Call for GPLv3 Migration

"Why ??... and why license patents if you do GPLv3 in the first place ??"

Remember, independent inventions can still be patented. If I hold a patent on something, it is only because I have filed for it, and it was accepted by the patent examiner. The same invention could be incorporated into GPLv3-licensed program entirely independently through rediscovery. After all, many software patents are trivial.

I find rest of your points difficult to decipher. It may be because it's friday night and I'm already substantially drunk. The other alternative is that this short rebuttal already covers the rest of your points, if they follow from misunderstanding of the case I'm making.

For instance, you write this: "GPLv2 is much more easy to hijack". I have no idea why you think GPLv3 software is any less easy to hijack. Patents can cover any software, regardless of what license it is under. However, being GPLv3 severely limits the options for negotiating a contract between the patent holder and the infringer, thus making it worse for companies that find themselves in infringement. This was my original point, and my belief of what the grandparent poster tried to say.

SFLC: A Wake-Up Call for GPLv3 Migration

Posted Apr 19, 2009 17:42 UTC (Sun) by mmarq (guest, #2332) [Link] (2 responses)

"" For instance, you write this: "GPLv2 is much more easy to hijack". I have no idea why you think GPLv3 software is any less easy to hijack. ""

easy.. if you have a patent and your code is in a GPLv3 repo you are already giving a patent license to anyone that might use that repo...

In GPLv2 that doesn't apply... you still can sue anyone that might use that GPLv2 code for patent infringement...

In either case you can still license the patent to anyone that might be willing to pay... be it in GPL repos or outside... but i can't see that happen in GPLv3 code since by the terms of it, you are already giving a grant "a priori"

SFLC: A Wake-Up Call for GPLv3 Migration

Posted Apr 20, 2009 10:27 UTC (Mon) by alankila (guest, #47141) [Link]

"easy.. if you have a patent and your code is in a GPLv3 repo you are already giving a patent license to anyone that might use that repo..."

While this is a valid point, it was never the situation I had in mind. It's good to know that GPLv3 will prevent perverting codebase from becoming polluted by submarine patents that are owned by the code contributor.

SFLC: A Wake-Up Call for GPLv3 Migration

Posted Apr 20, 2009 19:28 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

easy.. if you have a patent and your code is in a GPLv3 repo you are already giving a patent license to anyone that might use that repo...

This is true if the *owner* of the patent places the code in that GPLv3 repo. Unlikely to happen if said owner is even toying with the idea of trolling with it, to say the very least.

If I (coder on foot, not the patent owner nor a licensee allowed to do so) place the code in a GPLv3 repo I'd be in very hot water indeed...

SFLC: A Wake-Up Call for GPLv3 Migration

Posted Apr 19, 2009 18:44 UTC (Sun) by mmarq (guest, #2332) [Link] (1 responses)

Well... THE BIG QUESTION

Can anyone outside still sue a GPLv3 project for patent infringement ??

YES THEY CAN

GPLv3 is no silver bullet... actually there is only one thing that might approach the magic of a silver bullet.

** be better and more prolific than the competition **

The only way to counter all patent trolls is to have all the "prior art" in your side... and meanwhile shed all possible infected legacy...

GPLv3 is an excellent tool against *infiltration* because of ppl that might put patented code in a GPL repo... in Linux kernel there isn't much of a choice, because specially in device drivers, that is practically unavoidable... but that could be "soften" by having a TECHNICAL NOT POLITICAL better solution to device drivers developement and a DYNAMIC module insertion interface be offered... like DKMS...

There is cooperation now alright, but nothing is really very different from before, HW manufacturers always wanted to cooperate... but not on FSF terms.

2 BIRDS WITH 1 SHOT

1 )The issue is not accept binary only modules... really who cares about them ??... if anybody does, then its not their business, unless their politic is to outlaw close source SW.

The issue of an interface like DKMS is to streamline dev driver development in OSS world.. not having everything taken by a generalist approach, but letting it diverge often in a sane manner at the very low level, that is, very close to the metal...

Of course many big and small players will take advantage of this to offer binary only modules... but where is it different from now when there is already plenty of that, along with various OSS driver projects... IT IS BETTER ACTUALLY... because having a somehow a defined interface, which could be HARDENED ALSO, is better than letting an outside ISV/IHV do modules to insert wherever they want all over Linux kernel... AND ACTUALLY FACILITATES REVERSE ENGINEERING...

2 ) I suspect that most of patent issues are in Linux kernel are "close to the metal"... so having a dynamic interface will allow the passage of many of those nasties to a dynamic module... NOT for closed IHV//ISV delight, but for a caution of patents suing against OSS SW that might happen specially in those close to metal code...

PS: rather ... i don't know the word... but to have a MUCH BETTER defense against binary modules would be to forbid and or stop "insmod" and "modprob"...

this can only make those unwilling to cooperate to cooperate, and replace that with the likes of DKMS... in this DKMS yes and "mobprob" "insmod" no, any other module MUST WITHOUT EXCEPTION pass by the normal code acceptance, peer review and incorporation...

because actual model don't prevent me to sell CLOSED SOURCE modules that don't pass by Linux repositories to my costumers... and so i'm without having to share, because there are the costumers that are doing the the requisition for private use, not i that am distributing !!... see ??

SFLC: A Wake-Up Call for GPLv3 Migration

Posted Apr 19, 2009 19:04 UTC (Sun) by mmarq (guest, #2332) [Link]

"" 1 )The issue is not accept binary only modules... really who cares about them ??... if anybody does, then its not their business, unless their politic is to outlaw close source SW. ""

To clarify someone more confused... binary only modules don't happen inside Linux dev trees of course, that is not what i'm suggestong.

They happen plenty outside... and that is an incontrovertible fact today, NOTHING to worry about... AND NO LEGAL PROVISION should stick... it is END USERS that are requesting them... Linux kernel can only gain by accepting, take advantage of interfaces that don't banish that, and learn... otherwise it is only making hunger against "Linux" itself, because making very cumbersome for IHV to offer those modules by private outlets, instead of public downloads only to avoid any protest is not going to happen... in the end is that nobody can or should force anyone if those don't want to cooperate in any case... by apply sane rules(interfaces)...

Funny enough... everybody is in " wrapper mania" because that suits the big SW houses in linux business, and the devs are afraid to loose their jobs.. so they don't protest about tainting now !!?... when they should stop "modprob" "insmod" not the likes of DKMS!!!? ... savy?