Questions tagged «open-source»

有关免费提供原始源代码并可以重新分发和修改的软件的问题。


7
您如何阅读他人的代码?[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 5年前关闭。 几乎每个高级程序员都说,阅读其他专业人员的代码非常有用。通常他们建议开源。 你读不读?如果这样做,读取代码的频率和程序是什么?而且,对于新手来说,处理SVN(一堆文件)有点困难。有什么解决方案?

3
您应该在开放源代码项目的哪个阶段邀请社区的贡献?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 我一直在想为我的团队将要开发的新开源产品做出贡献。我们鼓励我们尽可能地从更广泛的社区中获得支持,但是我也可以看到这花费了大量的时间,以确保位于办公室外的第三方能够按计划处理诸如代码质量之类的事情。同样在项目开始时,我们可能会在核心团队中进行许多有关系统设计,峰值等的非正式讨论,将这些在线获取以允许社区参与将非常耗时,我可以想象可以使讨论效果较差。 这可能需要考虑更多的人性化方面:允许社区参与设计过程也可以从感知到的项目所有权方面受益,并且总是有可能早期参与可以解决核心问题。团队没有注意到。 那么问题来了:您应该在开源项目的哪个阶段邀请社区的贡献?

1
处理PR来解决公共回购中的安全漏洞的最佳实践是什么?
具有公共存储库的开源项目应如何最好地处理安全报告但尚未公开披露的安全漏洞的拉取请求(PR)? 我参与了一个有数百位贡献者的开源项目。作为定期计划的每月发布的一部分,我们每年发布几次安全公告和漏洞。在发布修补程序版本之前,我们不会发布有关漏洞的信息。我们能够在项目管理系统(JIRA)中安全地管理安全问题。但是,在将安全漏洞提交给GitHub时,我们没有一个很好的流程来掩盖可修复安全漏洞的PR。我们担心人们会在发布这些修补程序之前找到这些修补程序,并创建零日漏洞利用。 我们已经考虑过使用私有存储库来派生主存储库,但是我们当前的大部分审查和质量检查工作流都在PR上进行。如果我们将工作流仅移交给安全团队的私人仓库,则可以将修补程序公开时的时间减少到生成压缩包并将其发布到sourceforge所需的时间,这将是一个很大的改进。我们还可能需要避免将PR合并到我们的公开Beta中。 在朝这个方向发展之前,我想知道在具有开放存储库的开源项目中处理预发行安全性漏洞修复补丁的最佳实践是什么?如果可以通过使用不同于GitHub的平台来更好地解决问题,那么我应该提到我们正在评估迁移到GitLab的过程。

3
签署CLA如何防止开源项目中的法律问题?
例如:yeoman。它已获得BSD许可。该CLA形式(贡献者许可协议)不是项目具体的,它可以以电子方式签署。 签署此协议如何以及如何阻止哪些问题? 我贡献的大小有多重要? 为什么有些项目要求签署的CLA接受补丁,而另一些则不需要?(例如,node.js与rails)

1
GNU LGPL v3与GNU LGPL v2.1的缺点?
此问题是从Stack Overflow 迁移而来的,因为可以在Software Engineering Stack Exchange上回答。 迁移 8年前。 首先,我意识到这是一个编程问答站点,而不是提供法律建议的地方。...只是试图基本了解使用LGPLv3库的不利之处。 GNU LGPL v2.1和GNU LGPL v3有什么区别? 特别是,我知道常规GPLv3具有许多反DRM和反专利条款。原则上,我对这些条款没有任何要求,但是如果我选择使用LGPLv3库,这些条款将突然适用于主应用程序。 LGPL v2.1的规则似乎仅适用于您使用或修改的库。它没有说明主要应用程序。(假设没有静态链接等) 因此,在我工作的利基市场软件提供商中,我们经常使用LGPL许可的库(并对此做出贡献),而无需开源我们的主要应用程序。 LGPLv3是否会发生变化? 这个问题/programming/1108238/differences-between-gnu-lgpl-v2-1-and-gnu-lgpl-v3得到了几个答案,但是都没有解决主应用程序的任何新义务可能有。 澄清一下:我是在问LGPL v3,而不是普通的GPLv3。Tivoization /专利授权的任何要求是否从LGPLv3库“泄漏”到主机应用程序?

7
如何确定我的夜间项目代码是我的?
我是具有CS学位的物理学家,刚刚在一家科技公司开始了我的博士学位(希望从事应用研究)。它涉及大规模的有限元模拟。 在回顾了他们当前的方法之后,我认为必须采用根本不同的方法(它们使用的商业工具非常有限)。 我宁愿将研究基于开放源有限元求解器,并编写一个使用它的程序。我想在晚上提出这个想法,因为那是最适合我编程的时间(在一天中,我更喜欢阅读和数学),并在博士后期使用。 我想选择将程序作为开放源代码发布在我的网站上,以供将来个人或什至商业(例如咨询)使用。 如何确保我的公司不要求代码所有权? 我认为版本控制系统可以提供帮助(仅在晚上退房)。这将证明我不是在正常办公时间进行编程(其他地方记录了)。但是这些数据很容易制造。还有其他想法吗? 我想强调一点,我对销售软件不感兴趣,我的公司也不对。 到目前为止,非常有趣的回复。这显然对我有帮助。一些说明: 我不受工作合同的约束。国家法律规定,该公司拥有我在工作时间内生产的任何产品,并且未达成任何特殊协议(我的雇主没有出售软件,因此在这方面可能有些天真)。他们大多使用软件,而我的同事们都不是认真的程序员。 其次,我需要重新考虑@Mark提出的有关商业秘密的观点。这在特定行业中非常严重。 第三,我很在乎不要惹怒我的主管/老板。但是,这就是这个问题的动机,我想让我的作品的创新部分保持分离,以便我可以重用它,或者至少将其作为参考作品进行展示。

7
提供源代码是否会影响您的创收能力?
我们正在开发.Net框架,该框架最终相当于一个DLL。我们打算对框架的商业使用收费,但对开源/非商业使用免费。目前的粗略计划是通过某种形式的相当简单的许可证来进行管理,无论您是免费使用还是付费使用,都将颁发该许可证。 我们正在讨论是否使源代码可用。我们的看法(也是我们自己的偏好)认为,在可以访问源代码的地方使用某些东西会更具吸引力。 我对人们是否认为使源代码可用会损害我们从框架中赚钱的能力,或者是否会鼓励更多使用以及是否有足够的“好”人愿意为商业使用正确的许可证付费而感到兴趣。 我的感觉是,通常来说,商业运营不会在许可方面造成麻烦,因此使源代码可用只会鼓励使用,因此最终会产生更多收入,但是我会对其他观点/经验感兴趣。

1
从开放源代码项目派生/重用代码的正确方法是什么?
假设我正在开发一个开放源代码项目,并且想重用另一个开放源代码项目中的琐碎实用程序功能(例如,文件搜索/替换功能)。复制功能并仅在文件顶部写一个小的版权声明是否合法?我应该在许可证中包括他们作为整个项目的版权所有者的名字吗? 同样,假设我叉了一个开源项目。我在哪里以及如何指定版权所有人和我本人之间共享版权? 我猜答案必须根据开放源代码许可证而有所不同,但我希望尽可能多地获得一个通用答案。 PS:我主要关注法律方面,但可以自由考虑您的道德观点。

1
什么是适当的礼节和推荐的GitHub工作流程,以同时促进上游回购和从上游回购回馈?
我是GitHub和VCS的新手。我多年来一直使用各种语言进行编程,但是我一直在自定义项目(未公开发布)中一直独自工作。我最近开始在我正在研究的项目中使用从GitHub下载的jQuery UI小部件。该存储库不再由原始作者维护。另一个fork已合并了一些原始的请求请求。这是我分叉的那个。 我发现了几个错误,并提出了相应的修复程序。我想提供这些修复程序,但是我还想作很多其他更改,供我们自己使用,这些更改将破坏某些现有功能。另外,我想从另一个分支中引入一个想法。 我仍在学习GIT和GitHub,并试图找出解决所有问题的最佳方法。我已经阅读了很多有关不同概念/任务的文章(在这里,SO,GitHub帮助页面,Pro Git):工作流,合并,拉取请求,挑选,重新设置,分支。我的灰质是游泳,所以我需要开始这样做,这样我才能更好地了解自己阅读的内容。 主要问题: 我想(在某处)我读到您一次只能在一个分支上有一个请求请求。那么这是否意味着我应该为每个错误提供一个单独的分支,然后为每个错误执行一个单独的提取请求? 我想清理空白问题,而且我似乎还记得读过,最好在单独的提交中执行此操作。我应该在我的主数据库还是在另一个分支中进行此操作?我不想对如此琐碎的事情进行拉取请求,但是如果我在分支之前进行空格更改,这会影响对错误修复的拉取请求吗?一些fork进行了空格清理,这实际上使diff变得毫无用处。 我当时想用叉子创建问题,以作为记录bug的一种方式,即使我已经针对它们进行了修复。这是一个好主意吗?如何将问题,提交和合并合并到主节点?如果我向上游发出拉取请求,我的问题也会出现在上游还是会丢失该文档链接?我无法针对上游仓库打开问题(没有问题标签)。 在我想使用他的想法时,最好的办法是赞扬另一个叉子作者?我无法完全使用他的代码,尤其是因为他的更改是针对较旧版本的上游应用的,并且与我的其他更改不兼容。但是我想用这个主意,我想在应得的信贷额上给予好评。我应该只在提交消息中链接到他的回购(或个人资料或特定提交)吗? 更改自述文件和主文件顶部的DocBlock的礼节是什么?可以进行更改,添加我的名字,添加指向我的repo和演示的链接,删除指向原始演示的链接(因为我的fork最终将与原始版本不兼容)吗?当然,我将保留原始作者姓名和许可证信息。作为记录,它已获得MIT许可。 作为从未使用过VCS的独立开发人员,我习惯于重写历史记录。我是一个完美主义者,喜欢事物要整洁。记录历史的想法使我有点紧张,我想第一次做对。我创建了一个新的供您玩耍/学习的仓库,但是我急于继续固定jQuery UI小部件,以便继续进行我的项目。

17
开源对开发人员本身不利吗?[关闭]
按照目前的情况,这个问题不适合我们的问答形式。我们希望答案会得到事实,参考或专业知识的支持,但是这个问题可能会引起辩论,争论,民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出,请访问帮助中心以获取指导。 关闭 7年前。 为什么程序员甚至喜欢开源的想法?我不是在谈论那些项目的创建者,当然他们是成名的,但是我在谈论的是整个行业,为什么当开源概念给行业带来如此多的负面影响时,我们为什么如此喜欢开源概念? 首先,在诸如wordpress和其他CMS之类的项目中,它们剥夺了许多自由职业者的工作,客户需要博客或简单的网站。其次,在诸如Rails以及其他库和API之类的项目中,它们使很多程序员无法工作,并使对程序员的需求减小,因为现在有了这些开源API,一个程序员可以做10个程序员曾经做过的事情。最后,使用诸如Notepad ++之类的开源软件,现在,当人们要求他们购买软件时,人们会感到很有趣。 所以,问题是,如果这会使我们变得贫穷,为什么我们仍然喜欢开源?可能,我作为程序员的生活会更艰难,但至少我可以靠它谋生。但是现在,它更像是机器在代替人类,有趣的是,我们正在创造那些取代我们自己的“机器”。 假设,如果您发明了一种工具,则不必共享它,它将仍然对您和您的公司有所帮助。即使没有这些开源工具,其他程序员也会活着,因为他们仍然有一份赚钱的工作。

5
是否有任何可直接归因于开源软件的商业灾难案例?[关闭]
按照目前的情况,这个问题不适合我们的问答形式。我们希望答案会得到事实,参考或专业知识的支持,但是这个问题可能会引起辩论,争论,民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出,请访问帮助中心以获取指导。 8年前关闭。 在“企业”环境中,我注意到对专有软件的强烈偏见。即使在使用Java的大型企业中,也很难找到MySQL或PostgreSQL,并且WebSphere和WebLogic绝对比JBoss或Tomcat更受青睐。 这是可以理解的。尽管许多开发人员更喜欢Tomcat或Postgres而不是WebSphere或Oracle DB,但他们并不是最终决定这些事情的人。谁决定在生产中使用哪个数据库和应用程序服务器,谁就会发现,与选择导致真正,确实,糟糕的事情发生的自由软件相比,许可证费用似乎很小。 我不是在问Postgres是否和Oracle一样好。那不是重点。在仔细考虑功能和基准之后,Oracle不会被Postgres选中。Postgres不会进入对话,因为某些地方不信任自由软件。 我很好奇这种不信任是否是由于对任何特定事件的反应而引起的。所以我的问题是:是否有任何证明是由于开源软件缺陷导致的业务灾难(故障,收入严重损失,公司数据严重损失等)的记录在案? 说明:如果您有完全支持OSS的企业级公司的经验,这些公司必须对此事存有偏见,但要根据特定情况的需要进行选择,那么对您有好处!您的经验并不会改变其他企业公司的态度完全不同的事实,即使这些公司占少数,我的问题也是有效的。

8
开源项目如何自我维持?
我一直在想这个问题,但找不到合适的地方问。网上有一些非常不错的开源免费软件。这些产品如何维持财务状况?编写一个小型实用程序做一件好事是一回事,但是编写具有全部功能的复杂产品则完全是一回事。因此,再次重复一遍,他们在财务上如何运作?


5
命名软件和唯一性
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 3年前关闭。 在命名软件产品(应用程序或库)时,您要做什么? 选择一个其他软件尚未使用的名称似乎是不可能的,无论是某人的小型业余项目还是出售它的公司。我们都知道Phoenix成为Firebird成为Firefox,因为它与其他软件产品名称发生冲突。 名称必须有多独特?Phoenix是计算机BIOS的名称-与Web浏览器几乎没有,不是吗?作为反例,很高兴地将操作系统Fedora和存储库软件Fedora并存。另一个反例是Java框架midori和Web浏览器midori。 您将采取什么步骤来确保他人不使用您的应用程序或库的名称,以及在查找具有相同名称的其他内容时,从产品类型的角度来看,您会走多远?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.