Shut the mailing list down and have a single place of discussion / debate...
Ironically, the discussion in the forum was shut down for the very reason of having a single place for discussion / debate - which is the mailing list. It's the list which is the 'official' channel to discuss project structure decisions, and it has been that for a very long time.
This is hurting FG... Shame on you all.
I guess I don't understand what the problem is.
It says:
* FGAddon has a GPL and compatible policy
-> we need to be able to identify the license under which FG as a project can be re-distributed e.g. to Linux distributions. It's a policy decision that the official FG servers will be GPL compatible - if you want to publish on a different license, you can use a private hangar
* the author has commit rights for his own aircraft
-> The author should be able to maintain his own stuff, what can I say?
* aircraft may receive updates for compatibility
-> if I decide to re-name a property /environment/aircraft-effects/frost, then the glass shader may break all across the place - so what this says is that in this case I (or someone else) will do a grep across the list of aircraft and fix all instances so that the aircraft maintainer doesn't always have to be alert for possibly breaking changes
* if someone else has a patch for an aircraft, the maintainer should be the first to review it, provide feedback and strive to find a way to include it
-> That's what we've been discussing here - if you have an FDM for a plane which has a 3d model only, the maintainer must work with you rather than veto you.
Maybe there should be a passage about co-authorship when contributions are evidently substantial? So if someone makes a 3d model and someone else an FDM, they become co-authors. Seems to happen in practice, Richard isn't the original maintainer of the F-14b, but he sure is the current maintainer and considered author.
* core committers will adjudicate disagreements
-> if the maintainer decides to veto your patch and the reason is found to be moot, core committers can still make a decision to commit your work
* core committers reserve the right to revoke commit rights
-> the use case I've seen argued for this is someone messing up history structure on the server and creating extra workload for others to clean up - but the admin is responsible for the repository - say someone commits copyrighted stuff and keeps doing so, revoking commit rights is the only reasonable answer
It's unreasonable to limit contribution within FG solely because the authors wish to protect their work against sources outside the FG community.
I'm sorry, but I don't see that point anywhere.
An agreement between authors and FG allowing lifetime use/modification/distribution within the FG community yet still retain protection against external misuse would resolve all internal FG conflict.
If I understand you correctly, you say FG shouldn't be GPL then, or at least aircraft shouldn't? i.e. you only have the right to use/distribute
within the FG community (however that is defined...) but not outside so that nobody can mis-use it?
I guess that depends on whether you fundamentally see virtue in the GPL or not.
FGMembers policy of caring nothing for the consent of maintainers and just grabbing content (even unlicensed one) just to be able to offer the largest repository of aircraft around, or the
FlightProSim and variants scam sometimes make me doubt the wisdom of GPL. So I have every sympathy for someone publishing under a more restrictive license, prohibiting e.g. commercial use (I have done this for some of my linguistics textbooks).
In the end, GPL is a radical idea (although not quite as radical and contagious as Edward would have us believe) and drags a lot of useful code out into the open. So in principle it has my support, although I don't subscribe (as above) to the idea that the potential use case of modules next to each other is a GPL-worthy dependence, and I think Israel's 'grab and ask license later' policy is not GPL but plainly illegal.