React 的專利授權議題

ASF (Apache Software Foundation) 全面禁止 Facebook 的 BSD+PATENTS 後 (「Apache Foundation 宣佈禁止使用 Facebook BSD+Patents 的軟體」),整件事情開始熱起來了...

簡單來說,Facebook 有意為之,而且不打算撤回這個有攻擊性的授權模式,參考「Explaining React's license」這邊官方的說明以及有人寫了一篇解讀:「If you’re a startup, you should not use React (reflecting on the BSD + patents license)」。

Facebook 內的意見其實也不一樣,像是 Yarn 之所以沒有 PATENTS 是因為爭取出來的:

接下來應該會有更多爭議討論了...

GitHub 推出軟體版的 U2F Authenticator (目前只有 macOS)

用軟體實做 U2F,目前是開發在 macOS 上:「Introducing Soft U2F, a software U2F authenticator for macOS」。

實在是不愛這種方式,由於是軟體式的,安全性低了不少... (機器被入侵後就都沒有防護了)

不過 U2F 是目前少數可以在 protocol 層抵抗 phishing 的方式,相較於一般 OTP 的方式還是得很注意網址,所以站在推廣的立場的確是希望能多一點人用...

Apache Foundation 宣佈禁止使用 Facebook BSD+Patents 的軟體

在「RocksDB Integrations」這邊討論到 RocksDBFacebook 所使用的 Facebook BSD+Patents License。

不過因為 RocksDB 最近在換 license (從 Facebook BSD+Patents 換到 Apache License, Version 2.0),移除了 PATENTS 內的限制,需要看 PATENTS 的舊檔案可以在 PATENTS 這邊看到。

Chris Mattmann 正式發出決議禁用 Facebook BSD+Patents License。(參考最後)

另外也提到了 Facebook 是故意埋下這些限制:

Note also Roy's comment that he has discussed the matter with FB's counsel and the word is that the FB license is intentionally incompatible. It is hard to make the argument that it is compatible after hearing that. Pragmatically speaking, regardless of any semantic shaving being done, having a statement like that from the source of the license is very daunting. If they think it is incompatible, we need to not try to wheedle and convince ourselves it is not.

這個 license 之後應該會有更多挑戰...

Hi,

As some of you may know, recently the Facebook BSD+patents license has been
moved to Category X (https://www.apache.org/legal/resolved#category-x).
Please see LEGAL-303 [1] for a discussion of this. The license is also referred
to as the ROCKSDB license, even though Facebook BSD+patents is its more
industry standard name.

This has impacted some projects, to date based on LEGAL-303
and the detective work of Todd Lipcon:

Samza, Flink, Marmotta, Kafka and Bahir

(perhaps more)

Please take notice of the following policy:

o No new project, sub-project or codebase, which has not
  used Facebook BSD+patents licensed jars (or similar), are allowed to use
  them. In other words, if you haven't been using them, you
  aren't allowed to start. It is Cat-X.

o If you have been using it, and have done so in a *release*,
  you have a temporary exclusion from the Cat-X classification thru
  August 31, 2017. At that point in time, ANY and ALL usage
  of these Facebook BSD+patents licensed artifacts are DISALLOWED. You must
  either find a suitably licensed replacement, or do without.
  There will be NO exceptions.

o Any situation not covered by the above is an implicit
  DISALLOWAL of usage.

Also please note that in the 2nd situation (where a temporary
exclusion has been granted), you MUST ensure that NOTICE explicitly
notifies the end-user that a Facebook BSD+patents licensed artifact exists. They
may not be aware of it up to now, and that MUST be addressed.

If there are any questions, please ask on the legal-discuss@a.o
list.

Thanks.

Cheers,
Chris Mattmann
VP Legal Affairs

[1] https://issues.apache.org/jira/browse/LEGAL-303

GitHub 引入 Code Owner 的概念

GitHub 推出了 Code Owner 的概念:「Introducing code owners」。也很直接說這個能是向 Chromium「致敬」出來的:

The code owners feature was inspired by Chromium's use of OWNERS files.

檔案名稱是 CODEOWNERS,可以放在根目錄或是 .github/ 下,可以針對不同的目錄設不同的人:

To specify code owners, create a file named CODEOWNERS in the repository's root directory (or in .github/ if you prefer) with the following format[.]

這樣一來,在 pull request 的時候就會跳出來:

另外也可以設定需要 code owner 同意才能 merge:

Microsoft Blogs 上 TDD 的戰文...

文章標題就直接寫「#NoTDD」的戰文 XDDD

列了 Pros (一行) 跟 Cons (超長 XDDD):

Pros

  • We end up with tests that verify the behavior of the code and help prevent regressions

這個是 TDD 的目的。而 Cons:

Cons

  • It takes us longer to write code using TDD
  • The tests get in the way. Because my design does not have low coupling, I end up with tests that also do not have low coupling. This means that if I change the behavior of how class works, I often have to fix tests for other classes.
  • Because I don’t have low coupling, I need to use mocks or other tests doubles often. Tests are good to the extent that the tests use the code in precisely the same way the real system uses the code. As soon as I introduce mocks, I now have a test that only works as long as that mock faithfully matches the behavior of the real system. If I have lots of mocks – and since I don’t have low coupling, I need lots of mocks – then I’m going to have cases where the behavior does not match. This will either show up as a broken test, or a missed regression.
  • Design on the fly is a learned skill. If you don’t have the refactoring skills to drive it, it is possible that the design you reach through TDD is going to be worse than if you spent 15 minutes doing up-front design.

這四個問題講的是時間與能力兩個因子的作用,轉一個角度來討論其實是:如果 junior engineer 可以寫出好的測試,他們就不叫 junior engineer 了... 而 senior engineer 是稀缺資源,讓他們多花時間寫出「好的測試」未必是划算的。

反而是另外一種常見的方式常常跟 TDD 在對抗:透過 QA team 在完成後測試,尤其是用手動測試的 QA team XDDD

這個方法很簡單,而且行之有年。而且很無奈的,跟一般軟體工程所期望的相反,junior engineer 就可以做的不錯,所以人力的部份相當好 scale,而品質也有不錯的水準 (畢竟是直接測實際的功能了)。

剛好前陣子有提到另外一篇論文也在討論 TDD 的效果 (參考「又一篇戰文:討論 TDD 的過程」這邊),也有類似的反思。

前陣子在 Twitter 上看到這則也是很有趣,拿來當結尾 XDDD:

又一篇戰文:討論 TDD 的過程

最近在 39th International Conference on Software Engineering 上受邀參加說明的論文,在 The Morning Paper 上看到的:「A dissection of the test-driven development process: does it really matter to test-first or test-last?」。

論文本身在「A Dissection of the Test-Driven Development Process: Does It Really Matter to Test-First or to Test-Last?」這邊可以下載,是去年 2016 就發出來的論文。

論文拆解 TDD 的行為,分析到底是哪些階段才是有正面幫助的:

Background: Test-driven development (TDD) is a technique that repeats short coding cycles interleaved with testing. The developer first writes a unit test for the desired functionality, followed by the necessary production code, and refactors the code. Many empirical studies neglect unique process characteristics related to TDD iterative nature. Aim: We formulate four process characteristic: sequencing, granularity, uniformity, and refactoring effort. We investigate how these characteristics impact quality and productivity in TDD and related variations. Method: We analyzed 82 data points collected from 39 professionals, each capturing the process used while performing a specific development task. We built regression models to assess the impact of process characteristics on quality and productivity. Quality was measured by functional correctness.

比較特別的是作者指出 refactoring 的負面效果:

Result: Quality and productivity improvements were primarily positively associated with the granularity and uniformity. Sequencing, the order in which test and production code are written, had no important influence. Refactoring effort was negatively associated with both outcomes. We explain the unexpected negative correlation with quality by possible prevalence of mixed refactoring. Conclusion: The claimed benefits of TDD may not be due to its distinctive test-first dynamic, but rather due to the fact that TDD-like processes encourage fine-grained, steady steps that improve focus and flow.

在 The Morning Paper 上的註解也可以看看 (反駁論文的意見),像是對論文使用自評系統的批評。

美國聯邦法院認定 Open Source License 是有效的強制性合約

這是是韓國廠商 Hancom 在加州被告上法院:「A federal court has ruled that an open-source license is an enforceable contract」。

But after it began using Ghostscript in its software in 2013, Hancom did neither: it did not open-source its software, and it did not pay Artifex a licensing fee.

At the end of 2016, Artifex filed a lawsuit against Hancom in the US District Court for the Northern District of California.

Hancom 的理由是授權 (license) 不是合約 (contract):

That happened when Hancom issued a motion to dismiss the case on the grounds that the company didn’t sign anything, so the license wasn’t a real contract.

而法官認定 GPL 是合約的一種:

“Not so,” said Judge Jacqueline Scott Corley in her order on the motion on April 25. Corley said the GNU GPL “provides that the Ghostscript user agrees to its terms if the user does not obtain a commercial license. Plaintiff alleges that Defendant used Ghostscript, did not obtain a commercial license, and represented publicly that its use of Ghostscript was licensed under the [GNU GPL]. These allegations sufficiently plead the existence of a contract.”

Stripe 的 Increment 雜誌

Stripe 推出了 Increment 雜誌,講團隊合作時的各種議題:「Introducing Increment」。

And so we've decided to start Increment, a software engineering magazine dedicated to providing practical and useful insight into what effective teams are doing so that the rest of us can learn from them more quickly.

雜誌網站上也有類似的描述:

A digital magazine about how teams build and operate software systems at scale.

Increment is dedicated to covering how teams build and operate software systems at scale, one issue at a time.

可以看一看 Stripe 對團隊合作的想法...

Google 的軟體開發

之前有不少 Google 內軟體開發的說明 (像是 2015 年的「Google Is 2 Billion Lines of Code—And It’s All in One Place」),不過這好像是第一次以 paper 的形式整理出來:「Software Engineering at Google」。

當你有一群等級超高的工程師時,軟體工程裡面一堆假設都被推翻,然後一堆工具都是客製化自己開發 (有可能是那個時間點還沒有成熟的工具,也有可能是需要大量客製化),於是就會看到各種有趣的解法... XD

拿來看看還可以,拿來抄八成會出事 XDDD

關於防毒軟體...

這篇的標題真直接 XDDD:「Disable Your Antivirus Software (Except Microsoft's)」。

其實差不多跟作者提到的一樣,防毒軟體的功用真的很少。真的要執行來路不明的檔案時 (或是確定會有一堆 malware 的中國軟體時 XDDD),應該要丟到其他的 vm 裡面隔離,甚至是另外一台實體機器,而非靠防毒軟體擋下。

實在是有太多防毒軟體來亂了,為了達成目的把本來的安全設計打掉,然後再加上自己有問題的設計...