Bruce Perens, an open source pioneer, writes about software licensing, the GPL, ethical licenses, and his proposed Post-Open license.
HN cites it in licensing debates, especially his critique of ethical licenses and his Post-Open draft, which one commenter calls a forlorn hope against proprietary companies.
My needs are simple. Keep the frequency allocations for my
transmission, and help stop my neighborhood from filling with devices
that emit stray RF and block my reception. My two issues are, almost
certainly, the primary issues for many other people.
Perens has http://perens.com/static/ARRL/TransparencyOctober2018.html
about new people for five director slots. Going through them, I first
see that the Valerie Hotzfeld website is "very worried" about 160,000
members versus 170,000. Seems like a minor concern to me.
The Ria Jairam website says she'll oppose any proposal to the FCC
unless there's open debate by membership. I believe that the correct
ARRL position, when the FCC may be considering a change relevant to my
two issues, is sometimes COMPLETELY OBVIOUS and what we actually need
is the fastest possible action by ARRL.
The Fred Hopengarten website mentions "A low cost basic membership:
one idea - no QSL bureau (inbound or outbound)." But inbound QSLs (see
the https://www.arrl.org/incoming-qsl-service page) don't require
membership at all! I'm not sure why a prospective member would pay a
"low cost" to reduce their current service level.
The Michael Ritz website talks about "addition of Kosovo, Z6, to the
DXCC Approved Country list." Hello? I'm a maker, not an international
diplomat.
The George Hippisley website has a tantalizing mention of "Frequency
Spectrum" at http://www.w2ru.net/whatFrequencySpectrum.html - but it's
BLANK!
Five candidates' websites, and I can't…
Just to be clear: I'm not trying to fight or argue with you here, I'm just trying to understand :-)
> Sorry, IANAL. Open Source software is written in Poland with all the usual open source licences and it works so I'm sure at least in practice it's not a problem.
But "in practice" is hardly sufficient :P
> A lot of it is thanks to the fact that suing people is much less common here, so it never gets challanged. Also the person who lost the case pays the costs here unlike in the US so that's a deterrent.
I'm a European too, and live in a very non-litiguous country, so I have no problem understanding the mindset of not suing over everything. But it still seems really weird for a country's copyright system to rely on this (sane) behavior.
> I think they'd have to prove that the way it's used harms them. It's not enough to say "I don't like it". But again IANAL.
So if a Polish resident contributes an original photograph to a Wikipedia article under CC-BY-SA-3.0, and I (or a Polish entity) use that photograph under the terms of the CC-BY-SA-3.0 in a way that "harms" the copyright holder, he can sue me (or the Polish entity in question) under Polish law? This seems absolutely insane to me, and surely can't be the case!
This sounds a lot like the license that Berkeley SPICE was under a long time ago [1], whereby it was essentially open source, but specifically the South African police were not allowed to use it. This kind of stuff – even when well-intended – causes massive…
It's wonderful of grsecurity to produce a review like this - it'll be extremely helpful in addressing any issues in the development and patch management process. One can only think what improvements we might see in regards to Linux security, as a whole, if they'd work more proactively with the rest of the community. Of course, they're under no obligation to do so.
Unfortunately, I doubt that we'll ever have their participation - or even see or review any of grsecurity's modifications - all because of grsecurity's "Access Agreement". [0] Essentially, if I understand it correctly, even if grsecurity's customers wanted to, by sharing grsecurity's work with us or anyone else, those customers stand to have their access to the latest grsecurity created derivatives of the Linux kernel revoked. Of course, if that's true, facing a penalty for sharing code grsecurity received and modified per the GPL just doesn't sound right or just to me.
It seems obvious to me that one must carefully consider the wider picture when evaluating linux security posture evaluations, as presented by grsecurity, as there may be conflicts of interest in effect. I take what grsecurity says about the security of the Linux Kernel with a very large grain of salt, and you should as well.
Further, I'm not a legal expert and I use measured tones as grsecurity have taken legal action against open source community members in the past for expressing their opinions [1] on the matter of the access agreement [2].…
I'm not a lawyer, but perhaps Facebook's BSD+Patent license is not even open source.
It's tempting to consider the BSD license independent of the additional patent license. However, the OSI has not approved CC0 as being open source precisely because it expressly reserves patent rights [0]. In the OSI's justification, permissive MIT and BSD licenses may provide implicit patent license, so by themselves they are open source. However, like CC0, BSD+Patents expressly exclude this possibility. Indeed, Facebook's licensing FAQ deems the combined work of the BSD+patents to be the license [1]. Further, recent court case has shown that these licenses are not simply copyright or patent statements, but can be actual contracts [2].
Hence, we have to consider the BSD text + the patents file text as the combined license. This license is not symmetric and hence may violate OSI license standards. I've made this comment in the facebook bug report, https://github.com/facebook/react/issues/10191
[0] https://opensource.org/faq#cc-zero
[1] https://code.facebook.com/pages/850928938376556
[2] https://perens.com/blog/2017/05/28/understanding-the-gpl-is-a-contract-court-case/
> The problem is you could have a huge legal battle over it.
Of course, and it would be a real PITA, but I don't see how it would be that much different from a GPL violation law suit right now. If you publish your source code, even under GPLv3, there is nothing that really stops anybody else from taking it and violating the crap out of the terms and conditions.
In pretty much all jurisdictions I'm aware of, the copyright holders are the only ones who can sue for copyright infringement (setting aside the whole "is the GPL a contract?" debate for the moment[1][2], which would also open up suing for breach of contract in some juristicions).
You can slap any license constraints you like on your source code and publish it, but if you really don't have the resources to pursue legal action for violations to begin with, that already isn't worth anything and the software is effectively in the public domain.
[1] https://perens.com/2017/05/28/understanding-the-gpl-is-a-contract-court-case/
[2] https://en.wikipedia.org/wiki/GNU_General_Public_License#License_versus_contract
GRSecurity is violating the GPL, and thus violating the linux programmers copyrights, as Bruce Perens explained:
https://linux.slashdot.org/story/17/07/09/188246/bruce-perens-warns-grsecurity-breaches-the-linux-kernels-gpl-license
http://perens.com/blog/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/
Brad Spengler / PaxTeam / GRSecurity have no right to modify the linux code nor redistribute derivative works of it thusly.
Placing a "no redistribution or else" clause in a "separate writing" does not absolve one from the requirement NOT to stymie the linux programmer's stipulation in their license that such restrictions NOT be created by distributees or those who have created derivative works.
The linux programmers should sue Spengler, or simply revoke his license (another option: gratis licenses are freely revocable: they are not secured by an interest, and as-far-as-we-know Spengler has not payed the linux licensors for a license).