People will always decide upon what they want to do regardless. The point of this model is not to pretend to change that, we can’t. The point is to give users, people who want to adopt FOSS (and any software for that matter) better tools to evaluate whether it meets their goals, and also to understand the tangible ramifications of the various types of openness down the track/

Then, if it becomes useful as a tool to evaluate software from a users perspective (and keep in mind that it is _very_ hard for many people who are new to this space to evaluate and understand openness, so this could be quite handy). If that does become the case, then that could both lead providers of software to want to be more open _and_ it could make it plainly obvious when someone is not being very open even if they say they are.

We’re doing this to create a practical tool to help people. It’s hardly academic If you think it’s about love and harmony then you’ve missed the point.

I realise in the greater world of love and harmony things may be different and all the things you hope to achieve may be realised, but I have a voice at the back of hte mond that says this is highly unlikely, especially as software starts to move from the hoby developer to organisational developed apps

Roland, I want to briefly touch upon yours. You are in violent agreement with exactly why we built these foundations I know of all the cases you used above, and all of these demonstrate exactly why we need to be understanding freedom beyond a licence. RMS built a great base for freedom, a base that encouraged useful behaviours that promoted openness and freedom. The problem is that people who are not participating in the spirit of freedom and openness are able to comply to the letter of a licence (GPL, MPL, whatever) and yet be very closed in their way of doing things by closing the development model, basing the project on proprietary standards they own, using things like trademarks to close the opportunities to do business and having little to no documentation about the project to close the opportunity to learn about/from the project.

To break it down further, if a company wanted to be closed in their approach, for whatever reason, and yet wanted the good will of being seen to be a “FLOSS project” they could simply take some of their software, put it under the GPL and advertise as such. Then they could easily make the source code available in a useless format that requires a proprietary compiler (and only make it available to customers, not freely downloadable or anything), they do all their development inhouse behind closed doors, there isn’t any knowledge available or participatory governance model and noone else can build a market around it. It is still a GPL project, it is technically a FLOSS project, but it is about as closed as you get. It certainly isn’t conforming to the spirit of the freedoms expressed in the GPL. however it is following the letter of the licence.

We need a way to recognise these kinds of behaviours to ensure we maintain the spirit of freedom that the licences have tried to encapsulate.

By the way, I believe the power to fork is extremely important to a FLOSS project, and and don’t see this model as replacing or being more important that the FLOSS licences. I see this model as a useful way for both users of FLOSS and FLOSS projects themselves to evaluate how open they are, how free they are, from a few different angles.

Freedom, of any sort, requires the ability of an individual to act with the consent/support of any organisation or group, hence the specific freedoms outlined in the Gnu Manifesto, the DFSG and the OSS definition. Personal freedom in the context of an individual project is, AFAICT, unworkable, so freedom in the context of software development requires:

(a) access to source code by developers (N.B. “preferred form” not just “input language for compiler”; obfuscated- and machine-generated- “source” doesn’t count)

and

(b) the right, and the technical means, for those developers who choose to do so, to create and share derivative works.

By focusing on institutional structures (project governance), rather than on individual freedom, and in particular by promoting the line that inclusive governance is more important than, or even as important as, the individual freedoms embodied in the source licensing arrangements, you risk doing a very serious disservice to the FL/OSS community.

For concrete examples, consider SugerCRM, EGCS, QPL, GNOME and MPL.

- For the sake of argument, assume for the moment that SugarCRM’s governance arrangements are to your liking (I actually assume that they are not, but they provide a useful starting point for a thought experiment). That being the case, then the fact that they are using trademark law to interdict forking should not present a problem, right?

- Maybe I’ve not made my point strongly enough and you actually think that it would be OK for a project with acceptable governance arrangements to forcibly prevent forking. What then do you make of EGCS/GCC-2.95? This example is particularly important in that not only does it demonstrate the point, but given that it is GCC there is also an unequivocal win here for the entire FL/OSS community. Had forking (individual freedom, licensing arrangements, the ability for developer[s] to create and publish a fork not merely without the support of the project, but against its strong opposition) not been possible, EGCS would never have gotten off the ground, and GCC would still be a second-rate compiler. That this fork was possible, even against the GCC project’s opposition, made this possible.

- You may, or may not, recall the acrimonious arguments about early versions the QPL and its careful prevention of forking; the FAQ going so far as to claim that “everybody knows that forking is bad” in justifying this. Eventually common sense prevalled; the ability to fork (and the individual freedom that it entails) was recognised and the license was fixed.

- Interestingly, had QT’s developers gotten this dilemma the right way around the first time (individual freedom via licensing arrangements is vastly more important than institutional arrangements), GNOME would never have gotten off the ground…

- Finally, the MPL was seen as a way to get good stuff into the project, but prevent others from taking control. Again, after some time passed, the freedom of individuals to act independently of the established “project” was recognised and the proposal (mine, in fact) that Mozilla be multiple-licensed was finally implemented.

I’ve focused a little too closely on forking, but consider it a placeholder for a broader problem. The moment that you raise any other value to the same priority as freedom to work independently on source code, you risk reverting to ESR’s cathedral.

- A body of source for which this freedom does not exist cannot meaningfully be considered FL/OSS, regardless of the presence of the other interesting attributes that you mention.

- For a body of source for which this freedom does exist, the other attributes are an aside; their absence certainly doesn’t warrant putting it down as less than FL/OSS, or a lesser form of FL/OSS.