2024-01-30 17:01
ioGame(开源)--->ioGame(开源)+游戏服务端个性化代码(开源)-->免费
ioGame(开源)--->ioGame(开源)+游戏服务端个性化代码(闭源)-->收费
AGPL不就是这么个路子么
2024-01-30 16:58
按理说,它用的AGPL,别人只要不开源,都可以去收费的,现实中其实也不会有太多商业游戏开发商开源自己产品的服务端,所以只要用这个的游戏开发商够多,是能捞到钱的;
2024-01-30 12:02
2024-01-26 10:47
感觉国内的开源转商业模式都走歪了,就不能搞点商业版专用功能和开源版做区分?为啥偏偏卡文档收费?文档才是用户第一时间了解你产品的主要手段,你这不就是拒客于千里之外;
2024-01-26 14:04
如果不算搞老文档收费,就这个框架目前模式来说。还算是比较合理合法的一个开源商业模式。建一个私有主干,然后发布的时候,把代码同时分发到开源分支和闭源分支,从而确保代码的开源闭源合法性。学习研究开发AGPL游戏的,自己去开源分支。想要开发商业游戏的,买闭源授权。
2024-01-25 11:45
【简单的说,如果你不打算支付这部分文档费用,请私下保存一份自留使用,但不得以任何形式传播及公开。】你之前可是GNU AFFERO GENERAL PUBLIC LICENSE协议授权的文档
2024-01-25 22:54
开源协议变更是开源作者的权利,但是开源协议变更不能追溯以前的版本,这种法理上就站不住脚
2024-01-25 10:12
我非常支持文档收费,因为文档收费了作者有动力提供高质量的文档,这是一个良性的循环
2024-01-25 09:10
现实是,他这个框架,真正用户根本不会用开源版本。开源最多只是减少客户在游戏开发初期,项目技术选型时候的少量成本。以及培训新人,绝对不会有额外的法规风险。再多一点,除此之外,开源的意义几乎没有。
2024-01-27 08:32
是你觉得合理推断,但是你的判断没有实际的因果逻辑关系,不要老是拿你所谓推断,如果说事,另外你说的没错,商业上合规自己不做就不要怪别人,搞商业审核合规是很容易让人忽略的事情,自己看走眼确实要自己负责,这种案例国内外每天都在上演,互联网嘴硬意义不大不如潜心深入进去,不用回了,这是我看得多了给老哥的一点点小小建议,如有冒犯还请海涵
2024-01-25 09:09
怎么最近国内的开源界给人一种画风突变的感觉😂
2024-01-25 09:20
因为真正勤勤恳恳搞开源的,不会出来这样跳。又表又立的,才会上窜下跳,也就特别显眼。
2024-01-25 09:06
哈哈哈哈,看到这篇文章真得犹豫一下了
2024-01-25 09:18
买了授权的,看合同吧,就看里面如何规定技术支持以及版本维护的。如果没有详细规定,弄不好可要了命了。从这份公告看,花钱的必须要考虑继续停留在老版本的风险以及升级成本和额外风险。甚至游戏开发者自己维护BUG,也是有问题的,因为如果从agpl版本fork,那授权是否失效?如果改闭源代码,那是否购买的授权里面,有二次开发的授权(我估计够呛)?
2024-01-25 00:04
多大点事呀,自己开发一套不就得了,等我把我的项目搞完我给你们开发一套
2024-01-24 20:37
我还给公司技术老大推荐过这个,希望他已经忘记
2024-01-24 14:17
而且态度真是傲慢,高高在上,充斥着一副施舍嘴脸。如果没有开发者和开发商当小白鼠,给你们反馈问题,你们有能力把这框架完善起来?没有真实用户,你们能自掏腰包搞多大规模的网络部署测试,能测试多少用例?
2024-01-24 16:50
1、你说的用户的价值是存在的,那这个价值够不够免费使用这个软件呢?
2024-01-25 11:34
而且态度真是傲慢,高高在上,充斥着一副施舍嘴脸。如果没有开发者和开发商当小白鼠,给你们反馈问题,你们有能力把这框架完善起来?没有真实用户,你们能自掏腰包搞多大规模的网络部署测试,能测试多少用例? 这句话我觉得有问题有点本末倒置 倒是用户成了核心贡献者? 其它的我表示中心
2024-01-25 14:38
因为这种事情本质上就是一个互相成就的关系。大规模网络应用的东西,无论软件硬件,不实际部署,根本不知道有多少毛病。但是对于具体开发运营商来说,凭啥拿自己的命根子给你当实验小白鼠?所以客户付出的真的是一点不少,如果没有特殊原因,花钱买罪那是真实写照。就只说这个框架,某人写出来了,但是谁吃螃蟹?拿这个不成熟框架开发一个新游戏,不考虑大卖只求小赚,但如果天天掉线,数据错误,这游戏还有人玩?小赚?全损还差不多。没有好的合作关系,放下计较损失,优先查原因找问题,谁也落不了好。开发商亏钱,框架也要在圈子里臭名远扬。
2024-01-25 18:07
实际上开源作者投入远大于应用者,开源作者也没拿gun顶着让别人用,应用者不能既要又要,又想省事又想没有bug,大部分采纳的基本都要做技术选型分析,应用者拿着开源作品集成二开挣大钱,要求开源作者必须白莲花一朵,总之一个框架流行的主因不能归功于使用者,厨师做菜是否好吃不取决于食客,其实不用管那么多,开源作者和应用者都要恪守开源协议,变更开源协议也是开源作者的权利,但是不能往前追溯
2024-01-26 09:34
注意!如果用这个框架为基础开发服务器端挣钱,那基本上要合规,肯定是要买授权的。不买授权也不开源,那种才是辣鸡。可花钱买了服务,难道不能要求作者按合同办事?17停止维护,强迫客户升级,这个事情,我想知道,客户在买授权的时候知道吗?合同有约定版本的维护周期吗?开源网页写着的所谓十年维护期,是啥东西?你总不能指着windows98说这就是windows95的后续维护吧。如果说F框架的问题在于拿协议当厕纸,这个框架的最大问题,更多在于未来可能的商业纠纷。
2024-01-26 11:38
基本上 肯定 不要用这些字眼 你前面纯主观推断 后面又拿着这些作为论据 开源项目考虑开源协议就行了 作者和使用者遵循协议就行了 变更开源协议甚至闭源也是著作权持有者的合法权益 开源协议跟的是软件发行版本 变更后不能追溯 这个作者也犯了一个错 追溯旧版本 至于你说的付费授权都是你自己臆想出来的 付费商用你不签合同? 不签后面扯皮后果自负 签了按合同办 没有你说的这那道道的 我觉得你应该找个开源项目实践一下得真知
回复 @
{{emojiItem.symbol}}
返回顶部
顶部