Hi,
My understanding of the GPL is that for company internal additions to GPL
SW there is no obligation to GPL those changes nor distribute any SW copy.

Regardless I question why we should make it harder for people to do private
plug-ins. Isn't the mission statement take it easier to understand what's
going on in your network. Surely it applies to companies too. Why should we
play lawyers? Sue the ones breaking the license.
 Best regards
Anders

Den mån 4 dec. 2023 17:11Jeff Morriss <jeff.morriss...@gmail.com> skrev:

>
> On Mon, Dec 4, 2023 at 9:53 AM João Valverde <j...@v6e.pt> wrote:
>
>>
>> On 04/12/23 14:32, Anders Broman wrote:
>> > Hi,
>> > Company plug-ins may have restrictive license as the purpose is to
>> > only use them internally no public usage "secret" code for proprietary
>> > protocols under patents or IPL. Do we really want to forbid that? In
>> > that case why should companies provide code to Wireshark rather than
>> > just fork and build internally.
>>
>> I understand the argument and why that is a point of contention, but
>> that does not change the terms of the GPL which must be abided by even
>> if this commit was never merged in the first place.
>>
>> I don't think it is a question of whether we want to forbid it, it is
>> whether we can allow it. I believe the answer to that is a clear no if
>> we want to respect the terms of the GPLv2 (and I'm fine with that). I am
>> not a license lawyer so this is just my understanding of the legalities
>> involved.
>>
>
> I agree: I think the GPL is pretty clear here and AFAIK we don't grant an
> exception.
>
> That being said, when I used to create custom/proprietary dissectors
> (that, frankly, were only of interest to people working for my employer),
> those dissectors were (intentionally) GPL.  Any co-employee (to whom I gave
> the binary) was free to have the source code (and also free to do what they
> want with it).  Since there was genuinely no concern about them sharing
> said source code (no real risk if they did, but also no reason for them to
> do it), no additional restrictions were put in place.
>
> If, OTOH, there were significant secrets or proprietary information in
> those dissectors, one could *imagine* that those co-employees/users might
> have had an additional *condition of employment* (or similar, as long as
> it does not affect the source license!) that they do not share this
> proprietary code.  I believe this is similar to how Red Hat is getting away
> with restricting access to RHEL source code: the software license says you
> can do what you want with it, but if you share it then Red Hat is free to
> revoke your support contract (or whatever).
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@wireshark.org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Reply via email to