skmp
commented
5 years ago For 4 I think I should also extend the CLAs to the maintainers team and not directly to me, to make this more balanced
Closed skmp closed 4 years ago
skmp
commented
5 years ago For 4 I think I should also extend the CLAs to the maintainers team and not directly to me, to make this more balanced
skmp
commented
5 years ago Also #1649
davidgfnet
commented
5 years ago Proposals 4-7 LGTM Invitation 1 also potentially good to me :)
However: what is the advantage of BSD over any other license (particularly GPL)? I see that companies are scared of GPL, and I hope they keep that way :D, but with BSD any company, even SEGA (why not!), could just take this and release games (for which they have licenses) and we won't even hear about them. We might even go oblivious of them using reicast cause let's face it, not everyone goes reversing all re-releases to figure out whether they are new builds or just emus. I don't mind other people making profit for this within some reasonable limits, but at least I find it reasonable that if they do they either: pay back the project somehow (I don't want any money myself, at all, please no donations to me) and/or contribute back via code.
Therefore I have a counterproposal that (IMHO ofc!) fixes some of the issues while keeping the goals:
Use GPL by default. State it clearly that we are open to companies using reicast. If a company approaches us (or we could even approach them) we can (by reaching agreement by voting in the Verein) re-license them a copy of reicast under the conditions we see better fit. This allows us to fullfill Proposal 6 (were it states "we make a pledge that any emulation/core fixes will make it back to the project") by potentially getting them a license that ask for critical bugfixes to be released back to us. That can be cool to get some fixes for some games.
Also: what is the purpose of the blacklist? Didn't get that really. You mention a blacklist but don't state what happens if an org. gets blacklisted. They can't use the source at all? Only under some other license? I'm curious, both what are the implications and who you think it would be valuable to apply this blacklist to. I guess explaining one of them uncovers the other :P
hizzlekizzle
commented
5 years ago I don't really have a stake in this discussion so feel free to ignore, but I agree with david in suggesting that, if there's a CLA in place and a voting body that wields that power, there's no benefit to relicensing to default BSD but much risk (if you see closed source and/or commercial forks without attribution or compensation as risks). That is, the organization could vote at any time to spin off a fork with whatever license to whatever company, but you at least avoid silent exploitation as the default.
skmp
commented
5 years ago Personally, I'm fine with closed source / commercial forks for 1+ year old code. Long term, I think it's best for everyone for the code to be under BSD.
@davidgfnet if an org/person gets blacklisted, they can't use any new code in the repo, after the blacklist day. We could make it a 'revocable' license, but that would require more lawyer consultation.
It is meant to give some soft power against projects that are hard to work with, as well as toxic companies/closed forks/etc.
Re BSD + pledge vs GPL + permission -> Personally I prefer to operate in a "trust first, oops if people suck" principle, and that's why I proposed BSD.
I do want reicast to be embedded in as many places as possible, and in most cases people won't ask to license a GPL project.
There's also the side part that I've been blamed so much on trying to profit off this, that I'm wary of directly offering such services. Maybe I'm just too wary?
We could have a declaration and a simple contract that gets auto granted for non-gpl, with a revocation clause if they fail to meet the terms.
How about that + BSD for 1yr + code, and GPL for newer code?
skmp
commented
5 years ago (soft power - eg if there's a GPL emu that consistently imports our code, but doesn't release any of their fixes in BSD so we can merge, then we have some soft power to level the playing field)
barbudreadmon
commented
5 years ago Important notice :
Naomi improvements (crypted roms support, real atomiswave, inputs, ...) was mostly ported to reicast from MAME by either @flyinghead or me as permitted by the GPL license (on a sidenote, a lot of my code was backported to your repo without me signing the CLA). Afaik, it includes any naomi improvement apart from my 2 commits on your repo last year (https://github.com/reicast/reicast-emulator/commit/2e8a87cbdf2b84d540240efa21ce714958842aca and https://github.com/reicast/reicast-emulator/commit/8e7b6b72e13555238910529153815539df718bc6).
We are not the rights holder for any code ported from MAME, and you need authorization from the real rights holder to re-license code (if you want it, you might start by asking @p1pkin about this). Actually it might be a good idea to start checking if all code committed through your CLA was committed by its real author (since it's needed and obviously not always the case here), and revert it otherwise.
However: what is the advantage of BSD over any other license (particularly GPL)?
@davidgfnet afaik, BSD allows people to "improve" your code without forcing them to make their "improvement" public, it's the only difference i know from GPL. In the current situation i guess you could have company "K" using reicast, improving it, selling it, but you'll never get those improvements in this repo, that's why companies prefer BSD over GPL (they benefit from your work, you don't benefit from theirs).
skmp
commented
5 years ago @barbudreadmon if such code has made it in the project, then that is a violation of the cla. My understanding is that the violation/liability is with the person that did the pr, not with the project itself.
I’ll take a look in the commits you pointed, and please let me know if you know of others. I assumed people read the cla so far, and understood it’s implications. Looks like this was not the case.
GPL gets violated all the time - people that want to profit off your code will find ways to do it. GPL disallows companies to embed this within their larger projects, no matter if they improve the code or not.
Maybe LGPL/AGPL could satisfy everyone? have to check them out, been a while.
@p1pkin what do you think about all that?
barbudreadmon
commented
5 years ago I assumed people read the cla so far, and understood it’s implications
That's the main issue with this CLA thingy, i don't think any contributor signing it ever thought you would change license. There is no liability in porting GPL code to another GPL project, but it might be a grey zone when there is a CLA, though in this case the backporting was done on the fork with no CLA, and i guess it was merged in your repo when you decided to merge all of @flyinghead's improvements here a few months ago.
please let me know if you know of other
I know at least another one, check the headers there : https://github.com/reicast/reicast-emulator/blob/master/core/hw/arm7/arm-new.h
skmp
commented
5 years ago Oh yeah, the arm code. That one is known. There are a few other small pieces that we don't have under CLA or have direct copyright over it, and of course those will remain GPL. It'll take a while to transition fully, and for example code like tests or debugger can remain GPL indefinitely.
To get better clarity on this, I don't want people doing improvements in private forks, but I want people to be able to integrate libdreamcast/reicast/nulldc to their bigger projects (eg, a frontend) without forcing them to release their code.
I guess we could have a formal agreement to release any substancial improvements - or at least document them back to us so we can re-implement - without forcing them to release their unrelated code too.
Maybe we can extend the idea behind make a pledge that any emulation/core fixes will make it back to the project. to include all downstream users?
skmp
commented
5 years ago That's the main issue with this CLA thingy, i don't think any contributor signing it ever thought you would change license. There is no liability in porting GPL code to another GPL project, but it might be a grey zone when there is a CLA, though in this case the backporting was done on the fork with no CLA, and i guess it was merged in your repo when you decided to merge all of @flyinghead's improvements here a few months ago.
This is well documented, see #455. I've pointed /every/ new major dev towards that ticket, and asked for their feedback there, including @flyinghead. I guess I should have added it in the readme and in the CLA itself to clarify things further. Sorry for not doing this.
The intention has been to move to BSD since the code drop in 2013, I've just had no free time. I migrated to Switzerland from Greece in 2014, and that has kept me busy.
The other contensted bits are the GLES2 renderer afair, and some parts of the sh4/arm32 JIT, as those were developed under contract(s) for 3rd parties, before reicast becoming public. I'll have to check the exact contract terms to see if those can be BSD'd as-is, but I plan to rewrite both of them anyway in the following weeks.
TODO
barbudreadmon
commented
5 years ago I think picotcp can't be re-licensed either
Maybe LGPL/AGPL could satisfy everyone?
LGPL seems better than BSD to me, afaik it requires changes to the codebase to be published, while frontend stuff can stay private.
skmp
commented
5 years ago I think picotcp can't be re-licensed either
Many of our 3rd party libs can't, and will stay GPL.
Maybe LGPL/AGPL could satisfy everyone?
LGPL seems better than BSD to me, afaik it requires changes to the codebase to be published, while frontend stuff can stay private.
That is closer to my original intention, though I need to do a full review in them to make sure they don't have any other weird terms.
Again, for further clarity, we'll be splitting the project in two parts
Hopefully more info in #1372
Ravenslofty
commented
5 years ago Okay, so, here are some less well known alternatives, for better or worse.
There's the CDDL (license of ZFS), which is essentially a copyleft license that applies per-file instead of per-project like the GPL. It's not compatible with the GPL though, which is a factor that should be taken into consideration.
Alternatively, there's the MPL2 (license of Firefox). This is similar to the CDDL in terms of being copyleft per-file, but it also has a GPL-family compatibility clause which means that MPL2 code can be dual-licensed as a GPL-family license while still being under the terms of the MPL2.
davidgfnet
commented
5 years ago Hey there! I forgot to suggest LGPL myself indeed, always forgetting old-good-LGPL! As has been pointer already LGPL gives most of the advantages and almost none of the disadvantages and seems to go well with the intention to split code into a libdreamcast indeed. This would allow people to use a libdreamcast.dll/so and potentially make frontends and whatnot but would retrofeed any improvements back. Also I believe it's compatible with GPL (confirm please?) but will still require to make sure that any libs we use are ok with LGPL. I can't recall from memory but some of the libraries we use are either BSD or LGPL right?
I haven't really explored any other licenses, but there's many out there, perhaps there's some better suited as some others have already proposed.
El mié., 19 jun. 2019 a las 13:32, Dan Ravensloft (notifications@github.com) escribió:
Okay, so, here are some less well known alternatives, for better or worse.
There's the CDDL (license of ZFS), which is essentially a copyleft license that applies per-file instead of per-project like the GPL. It's not compatible with the GPL though, which is a factor that should be taken into consideration.
Alternatively, there's the MPL2 (license of Firefox). This is similar to the CDDL in terms of being copyleft per-file, but it also has a GPL-family compatibility clause which means that MPL2 code can be dual-licensed as a GPL-family license while still being under the terms of the MPL2.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/reicast/reicast-emulator/issues/1648?email_source=notifications&email_token=AAX7466XVXTMXZGG3AFB72DP3IKLFA5CNFSM4HZALSB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYBSGGI#issuecomment-503522073, or mute the thread https://github.com/notifications/unsubscribe-auth/AAX7465KC5OL3MNZ2QGDQ3TP3IKLFANCNFSM4HZALSBQ .
snickerbockers
commented
5 years ago Just droppong in to point out that if you guys are still considering the blacklist outlined in proposals 2 and 3 in the OP, then LGPL won't work because LGPL cannot be revoked. Version 3 of the GNU GPL states:
All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met.
The GNU LGPL defines itself as a modified version of the GPL with additional permissions and exemptions. This does not include a removal of the irrevocability clause of the GPL, so the LGPL would not be compatible with the blacklist.
Sources: https://www.gnu.org/licenses/gpl-3.0.html https://www.gnu.org/licenses/lgpl-3.0.en.html
skmp
commented
5 years ago The blacklist doesn’t need a revocable license - it can only apply for future changes. However, i do not know if you can have exempted prople/groups from gpl
skmp
commented
5 years ago Thinking a bit more on this
I'll update the proposals and maybe we can roughly vote/agree on them?
Any further comments?
vilhelmgray
commented
5 years ago An important nitpick: GPL/LGPL do not require changes to be made public in the sense of "the general public"; those licenses only require that the source code of the binary be provided to the user.
This means that the following scenario is completely permissible for a GPL project:
However, since anyone who receives a copy of the program is allowed to redistribute the source code, the source code is bound to become available to the general public in the end -- this is why most projects/companies just release the source code of their GPL programs to the general public from the start.
davidgfnet
commented
5 years ago Further comments from me if I may :) After seeing all the comments here and checking a bit dependencies and what not (every time we bring this topic we discover yet another file/code-bit that was created by someone else under who knows which license) I think reicast is a license hell :D I mean this in the way that I hardly believe any company would ever license it given how complex the licensing could be and how many unexpected license claimants could show up if they really mind to it, right? So skmp I understand your willingness to be friendly to companies that might want to license the project in exchange for money and/or contributions, however most sane companies (especially big ones) will stay away after seeing that the whole license situation is dubious. Of course this is a feeling but in the companies I worked in the past they were very conservative and only take things that they could know for sure where legit and almost risk-free. Again this is just my view, and that's more or less my basis to say (as I previously mentioned in other channels) that staying GPL is probably the best course of action and that re-licensing it when the opportunity presents is a headache for the future to have (or perhaps never if it never happens, so let's not worry about "what-ifs").
skmp
commented
5 years ago I’d rather have a code audit and cleanup the licensing - reimplementing isnt that hard.
Again, legally, for code merged by contribs the liability stays with them, just like the liability with companies trusting emudev.org / reicast lies with us, not them.
Code cleanup and licensing cleanup are clearly in order methinks
On Tue, 25 Jun 2019 at 18:48, David G. F. notifications@github.com wrote:
Further comments from me if I may :) After seeing all the comments here and checking a bit dependencies and what not (every time we bring this topic we discover yet another file/code-bit that was created by someone else under who knows which license) I think reicast is a license hell :D I mean this in the way that I hardly believe any company would ever license it given how complex the licensing could be and how many unexpected license claimants could show up if they really mind to it, right? So skmp I understand your willingness to be friendly to companies that might want to license the project in exchange for money and/or contributions, however most sane companies (especially big ones) will stay away after seeing that the whole license situation is dubious. Of course this is a feeling but in the companies I worked in the past they were very conservative and only take things that they could know for sure where legit and almost risk-free. Again this is just my view, and that's more or less my basis to say (as I previously mentioned in other channels) that staying GPL is probably the best course of action and that re-licensing it when the opportunity presents is a headache for the future to have (or perhaps never if it never happens, so let's not worry about "what-ifs").
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/reicast/reicast-emulator/issues/1648?email_source=notifications&email_token=AADAAMRKPS6EUZ6RPXWH2GLP4JD53A5CNFSM4HZALSB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYQ37RY#issuecomment-505528263, or mute the thread https://github.com/notifications/unsubscribe-auth/AADAAMWPV4EDVP2RCR3S6MDP4JD53ANCNFSM4HZALSBQ .
vilhelmgray
commented
5 years ago A code audit is necessary anyway in order to ensure that no infringements are occuring. Even if the Reicast project is protected from liability due to the CLA, the infringing code would still need to be removed if discovered.
So it's better to do that before an infringement case is brought up, while we have the time to address it and to reimplement the respective problem code, rather than to rush to replace infringing code once it is unexpectedly brought up.
Holzhaus
commented
5 years ago I've been inactive for year, so I don't think I have much say here ;-) Anyway, I'm fine with relicensing the code as LGPL, but IMHO the split-off emulation library shouldn't be named "libdreamcast". Dreamcast is a registered trademark, so it needs some other name like "libreicast" or "libfantasystream" (vs . "Dreamcast" which comes from "Dream Broadcast") or something like that.
skmp
commented
5 years ago libfantasticast?
Good point about the trademark. I wanted libdc but it’s taken :|
On Wed, 26 Jun 2019 at 10:43, Jan Holthuis notifications@github.com wrote:
I've been inactive for year, so I don't think I have much say here ;-) Anyway, I'm fine with relicensing the code as LGPL, but IMHO the split-off emulation library shouldn't be named "libdreamcast". Dreamcast is a registered trademark, so it needs some other name like "libreicast" or "libfantasystream" (vs . "Dreamcast" which comes from "Dream Broadcast") or something like that.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/reicast/reicast-emulator/issues/1648?email_source=notifications&email_token=AADAAMSDTVAPWISXCQBLZJ3P4MT2LA5CNFSM4HZALSB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYSZUVA#issuecomment-505780820, or mute the thread https://github.com/notifications/unsubscribe-auth/AADAAMSEEE6RXB5EKBZJBJ3P4MT2LANCNFSM4HZALSBQ .
skmp
commented
5 years ago A code audit is necessary anyway in order to ensure that no infringements are occuring. Even if the Reicast project is protected from liability due to the CLA, the infringing code would still need to be removed if discovered.
Agreed.
So it's better to do that before an infringement case is brought up, while
we have the time to address it and to reimplement the respective problem code, rather than to rush to replace infringing code once it is unexpectedly brought up.
Also agreed
—
You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/reicast/reicast-emulator/issues/1648?email_source=notifications&email_token=AADAAMTXYAQZ72I6JKVDIQLP4KU3PA5CNFSM4HZALSB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYR4ZMY#issuecomment-505662643, or mute the thread https://github.com/notifications/unsubscribe-auth/AADAAMUJZ4VLKXOZVYMOWL3P4KU3PANCNFSM4HZALSBQ .
davidgfnet
commented
5 years ago So if we decide to settle for GPL (not sure if that's what you proposed skmp) should we try to bring some people back to the project? You know :)
vilhelmgray
commented
5 years ago The proposal is to switch to the LGPL (Lesser GNU Public License) for the Reicast library (name currently pending, but perhaps libreicast?). The main difference between this and the GPL is that LGPL code is allowed to be used in non-GPL-compatible projects without forcing a change in said projects' licenses -- only the LGPL code and changes to it are bound by the traditional GPL requirements (i.e. sharing of source code, freedom of use, etc.).
Switching to LGPL should make libreicast a lot more friendly to non-GPL-compatible projects and companies, while still keeping the traditional benefits of the GPL so that improvements of the libreicast code can be merged back to us.
skmp
commented
5 years ago Yup, LGPL + linking exception, precisely to make integration easier.
As for the name, I'd rather avoid using libreicast. If we want to make a general dreamcast emulation library it shouldn't be attached to reicast like that. I'd love for contributors of other projects to join in too, and I think using a more generic name will help towards that.
Maybe the name should be a separate ticket?
vilhelmgray
commented
5 years ago Yes, a separate ticket for the naming would be a good idea so that the naming discussion doesn't get confused with licensing talk -- the library needs a name regardless of the license chosen.
skmp
commented
5 years ago Follow up for the non-profit: https://github.com/emudev-org/emudev.org/issues/10 << bylaws and structure proposal
baka0815
commented
5 years ago As long as my name stays in the git history, so I can brag being a part of reicasts history, I don't care how you're re-licensing my code as long as it stays open source.
skmp
commented
4 years ago We've switched to BSD3. Will reconsider if abuse happens.
barbudreadmon
commented
4 years ago As i already said, you can't change license on backported stuff, it is illegal, you never got the real authors to sign your CLA. It includes pretty much every naomi enhancements from the past 2 years.
skmp
commented
4 years ago @barbudreadmon I scanned the src code and saw some BSD-3clause mentions in that code, so I assumed it was under BSD (like most of mame?).
Otheriwise we can just mark them under GPL -- or their correct license if that is not the right one.
Can you point out relevant files + correct license? Some of the naomi work is from nulldc, and I'm not exactly clear on what is what.
skmp
commented
4 years ago (Each file in CORE has an #include <license/bsd> or #include <license/gpl> right now)
Holzhaus
commented
4 years ago (Each file in CORE has an
#include <license/bsd>or#include <license/gpl>right now)
How about using SPDX License Identifiers
instead of #include'ing the license text?
barbudreadmon
commented
4 years ago Those 2 are LGPL : https://github.com/mamedev/mame/blob/master/src/mame/drivers/naomi.cpp https://github.com/mamedev/mame/blob/master/src/mame/machine/naomi.cpp
Pretty much all other naomi/aw related files in MAME are BSD indeed : https://github.com/mamedev/mame/blob/master/src/mame/machine/315-5881_crypt.cpp https://github.com/mamedev/mame/blob/master/src/mame/machine/naomigd.cpp https://github.com/mamedev/mame/blob/master/src/mame/machine/naomim1.cpp https://github.com/mamedev/mame/blob/master/src/mame/machine/naomim2.cpp https://github.com/mamedev/mame/blob/master/src/mame/machine/naomim4.cpp ...
I might be missing some files, but basically i think the encryption part is BSD while the part that binds everything together is LGPL. Commit history is unclear with your changes, so it's kinda hard to track the involved files, but i think both naomi.cpp & naomi_cart.cpp contain LGPL code backported from MAME.
skmp
commented
4 years ago Alright.
@Holzhaus I'm not opposed to it in addition to the includes. The includes have logic to enforce the license via #error, so you can build a BSD-only build. Not all modules can do that /yet/, but that is a goal.
skmp
commented
4 years ago @barbudreadmon
Yes, going on the comment there
This file is a mix of my code, Zezu's, and duno wtf-else (most likely ElSemi's ?) that makes sense. I think it was originally somewhat plagiarized from chankast tbh. Like the mmap idea is clearly from there, I recall implementing that.
naomi_cart.cpp I do not recognize. I guess only @flyinghead knows where it came from.
I'll mark them both LGPL w/ a note that they are probably based on mame. Sounds good?
skmp
commented
4 years ago @barbudreadmon I meant to PR but failed at git. https://github.com/reicast/reicast-emulator/commit/c0eaa4a003e5d36d180d81220c3ee4ad1d254a1a is in alpha
barbudreadmon
commented
4 years ago Sounds good?
Yes
skmp
commented
4 years ago And with that I guess we can close this.
Hello Team,
After several discussions I think it's important to start doing the license changes, as a way to defuse the current situation. I'm tired of people trying to misread my intentions regarding licensing reicast, and all of the CLA-triggered drama.
Proposal 1: Code > 1 year old, as determined by commit timestamps, will be BSD 3-clause licensed.
Proposal 2: Code < 1 year old will be licensed by a modified BSD 4-clause license, to include a blacklist
Proposal 3: To get a new entry in the black list, there should be a general consensus between the maintainers team, the active developers at that time, and hopefully from past-active developers that have contributed significant amounts of code.
Proposal 4: Update the CLA to make it clear that the CLAs to me are only a temporary step, and I only hold them to guide the project during the transition to the non-profit. Once the non-profit is up and running, I will assign the licenses granted to me to the non-profit.
Proposal 5: The non-profit will be run in direct-democrazy participatory style, with some hierarchy, and some variation of liquid democracy. I'll make a more thorough proposal, but the swiss administration is a good place to study how a democracy thrives. See https://ch.ch.
Proposal 6: Make it clear that we /do/ want reicast integrated everywhere. If a company reaches out to us to make improvements to reicast, we make a pledge that any emulation/core fixes will make it back to the project.
Proposal 7: Make it clear that if we make some support contract around reicast, we will re-invest any proceeds towards the improvement of the reicast project, or any other way the members see fit.
Invitation 1: If you're interested in being part of the non profit verein board, or a founding member, please make a post here or reach to me at skmp@emudev.org. There will be some minimal membership costs to cover the cost of having an @emudev.org email and such, and you will have voting powers.
Thoughts?
Also related: #1631 #455 #407