"As any online discussion grows longer, the probability of someone mentioning Microsoft in a derogatory manner approaches 1."

I think we can generalise it a bit better than that.

"As any online discussion grows longer, the probability of someone mentioning anyone or anything in a derogatory manner approaches 1."

It might also make sense to add a "Slashdot Corollary" under which Microsoft and Apple are interchangeable.

And just those two and no others, because no-one ever says mean things about (let's say) Google or the FSF on this forum. Or maybe a better corollary might be "The better known the person or organization, the faster the probability approaches unity".

I find the same hilarity in people bitching and moaning about Unity. Again, nearly ALL of my time is spent in an application. I only interface with Unity to start the damn thing...

Personally, I derive vast amusement from those all too common cases where people whinge and whine about other people expressing their opinions in a public forum.

Sometimes they even try and disguise their bitching and moaning as amusement. I find that even more hillarious!

The question is: How is publishing code as open source of advantage to you?

The question is: What are you selling? Hardware or software?

If the software is the product, then close it obviously. There's money to be had from support contracts, but that's more of a pathway for monetising an existing free software project than for setting up a new business.

If the hardware is the product, then open the software. In doing so you effectively recruit every university doing research in the field, since they will all have tweaks and improvements. They publish their research, along with the software used (copyleft is good for that) and you either modify your own default software, or add the code to a repository for special purpose software. Your code is continuously improved and supports an increasingly wide range of applications.

Your competitor can adapt the results to their product as well, of course, but first of all they've got to port it. Meanwhile the number of applications for your sensor with custom software from third parties is going to grow and grow...

... probably. I don't want to sound too dogmatic when I only have a sketchy outline of the situation. But that's the way I'd look at it.

Exactly. The first tablet with a decent hardware spec and a substantially lower price is going to be a game changer.

I don't know if the B&N or Amazon offerings are going to be the ones to do that (don't know much about them, really) but the fact that the vendor doesn't need to licence the O/S means that there almost certainly is going to be one.

It's just not going to have "Dell" written on it.

Gee whiz, I wonder why people choose an iPad where for exactly the same money they could have had an Android wanna-be from a company not completely behind their own product.

Of course, a couple of years or so ago and some people were using that exact same line of argument to show how the iPhone was always going to dominate the market, and how Android would never be more than a curiosity.

And we all know how that turned out :)

Animal != mammal. The summary is actually valid

The key point here is that while the set of all mammals is not equivalent to the set of all animals, it is a subset thereof. So any true statement of the form "there exists a mammal such that X" remains true if you substitute "animal" for "mammal"

Also, you'd have to consider that Animal != Arachnid. Which means that even if we accept your logic, the summary still isn't valid, since the researcher's spider would be no more valid than the GP's skunk.

Fun stuff, logic :)

The reason not to work for Microsoft R&D is that, whilst you will be comfortable, well fed and well off, you will lead an empty life and they will suck your soul out of you.

Isn't that pretty much how employment in general works?

For some employers more so than for others, I feel :)

The GP/GGP's comments seem about right to me. I always did wonder how MS Research could do so much cool stuff, and yet have so little of it make it to market with any of the coolness still attached.

I don't want to actually reply except to point out that that is absolutely the WORST car analogy I've ever seen on this site.

I guess it just goes to show - one man's informed criticism is another man's whiney complaint :)

But it's not. The point is that the whole open source methodology doesn't gain you anything if people don't fairly evaluate the changes in a data-centric way

Is that true though? I think the big win of Free Software is that massive redundancy and parallisation of the process, and the fact the Darwinian selection will tend to weed out the weaker projects over time. If your software isn't fun, easy to use, efficient and stable, people are going to migrate to something else. Free market forces make for one hell of a design review.

What they do instead is post "I hate this", and submit bugs that are basically "change this to exactly what it was one year ago".

Well, yes. Some of them do, certainly. The trouble is that the sort of rational, cerebral evaluation you seem to be advocating probably isn't practical for a project with 12 million users.

On the other hand, that doesn't really excuse going to opposite extreme and saying "well, no one on the mailing list objects - it must be good". Or "it works OK on tablets, and the Gnome dudes are really getting up my nose - so the users are bound to love it".

What we need is an evaluation process scaled to the size the contemporary communities, and I'm not suggesting that will be an easy problem to solve.

Still, offering Unity as an option for desktop Ubuntu rather than the default, and getting a release or two's feedback from people he didn't feel it was being forced upon them ... would probably have been a good start.

Do you want to know why the developers of these new open source UIs don't value input from the general public? Because 99.5% of that input is just complaining. There's so much "I hate this" noise that it's impossible to find the 0.5% with the brilliant ideas of how it can be improved.

Hmmm... trouble is Sturgeon's Law applies to everything, not just FOSS project feedback.

If you're the type of person who hates change, stop downloading the new version with the changes! You'll be happy, the developers who won't have to listen to your griping will be happy, everybody's happy.

That probably works better for single programs than it does for desktop environments, and certainly in the case of entire distributions. I mean, if you're happy to run without security updates, recent versions of non DE programs and all the rest, then fair enough. But most people aren't.

Tell you what, let's have a car anaolgy. Most people get used to driving their cars. They get to know the limitations of the vehicle, and the strengths, and the build habits around these features. Changing all that is not something undertaken lightly.

But with Unity, it seems to me that a whole load of people, a lot of them basically "sunday drivers" have gone in to get the oil changed, and found out that Canonical have moved the brake pedal in order to accomplish this.

And they may well have moved it to a more efficient place ... but I can't help feel they've gone about it in a deeply wrong way.

You won't help the project by continually opening up the same bug over and over again.

Hey, don't look at me, I don't even use Ubuntu. I run debian, have FVWM as my window manager, and I know enough to work around most of the minor annoyances that crop up.

But I still think a lot of projects are being needlessly heavy handed in rolling out new features.

The open source,

Yes, it is.

anybody can contribute ideas

True enough.

rapid release development methodology would be the perfect way to prototype new UI ideas and designs

Can't argue with that.

if the community weren't a bunch of whiny luddite complainers.

Bit of a non-sequiteur there, though, I feel. The gratuitous insult doesn't really follow from the string of incoherent buzzwords.

When I was a little older, there was a series of books that could be be explained by irresistible force is stopped by immovable object which then gets blown away by even more irresistible force only to be stopped by even more immovable object

That sounds like an apt summary of E. E. 'Doc' Smith's Lensman series...

"These shields are impervious to all known everything!"

"How about if we hit them with a planet accelerated to faster-than-lightspeed?!"

"That'll work!"

Then, a book or so later:

"These shields are impervious to all known everything! Including faster-than-light-planets!"

"Have you tried faster-than-light planets composed entirely of anti-matter?"

"Brilliant!"

And so on throughout the series.

That said, they do rather make up for it by being bloody good fun to read :D

For stuff such as php or javascript that has to be distributed, it can be shown that the code is the same if necessary

I'm being pedantic, I know, but that's true in the case of Javascript, but not PHP. PHP sits on the server and the only code the user ever sees is it's output.

All it takes is one disaffected developer. It happens all the time

So the code of a PHP can be inspected "if necessary" because if the need arises, then as if by magic a disaffected developer will appear and leak the source code. To be fair, I suppose it's no more unrealistic than your "protection" against incompatible closed source forks.

Look, this has been fun and all, but it seems like every point in the last exchange is an evasion like that one. In most cases I think you know perfectly well what I mean, and I really don't have the time to keep dragging you back to the point, just to have you ignore it again. So I'm going to make a few closing observations, and then leave the last word to you, should you desire.

You know, I seem recall someone from Microsoft saying that the free software movement was (so far as he was concerned) basically a bunch of guys working for IBM for free. And that's Microsoft's vision for Open Source. They'd sooner it went away altogether, but if not, they like us all to be working for Microsoft for free.

I don't know if you designed RtPL to facilitate Microsoft's vision in this matter, but I don't see how you could have come closer if you had tried. You give away the absolute minimal rights required to get someone to debug your software, ensure that the project originator can keep strict control of the project And unlike BSD you don't require the creator's copyright to be acknowledged in binary distribution. If all you want out of Free Software is an unpaid workforce, I'd say you have created the perfect licence.

Monetizing, we've discussed a few times. You've repeated asserted that RtPL makes it easier for a developer to monetize his code, but despite repeated invitations to do so, you've yet to explain how to offers any advantage over the GPL. There are some fairly clear advantages when it comes to monetizing someone else's code (whether they like it or not) but you've not responded to that point either.

Your "protection" against corporations introducing deliberate incompatibilities into a closed release is, frankly, laughable. To say that you protect against a case, and then say that protection relies upon modern corporations either Doing The Right Thing, or failing that, to them admitting to wrong-doing, and that in a case where you couldn't possibly prove the transgression? The next time you have this discussion, you might also point out that they'll abide by the licence terms because otherwise Santa Claus will put them on the "naughty" list, and they'll find nothing but coal in their stockings come Christmas Day. In fact, I think I would have found that more convincing.

The "no derivative works" issue is going to cause problems. I don't know what your background is, but you don't understand how PHP works, and while I think you can #include a .c file, I don't think I've ever seen it done. As such, I think you probably have an exaggerated idea of the power of shims and wedges. It's not efficient design to wrap abstraction upon abstraction, which is pretty much what you'd need to do if you have a large number of coders all retaining their own copyrights. Of course, if the project requires all copyrights to be assigned, then the problem largely goes away, but since that was such a searing indictment of the GPL when the GNU project did it, it would probably sound a little strange if you suggested it for RtPL. Even if it is the screamingly obvious solution.

Lastly, while it's not strictly part of the licence, the general attitude of "no one should ever write code until they're good at it" is going to be very intimidating to newcomers to Free Software. Again, there are those who'd see that as a good thing, but very few of them are on the Free Software side of the fence.

I've tried quite hard in this discussion to give you the benefit of the doubt. It's can be all to easy to assume that anyone who doesn't share your point of view is some kind of shill with a hidden agenda. However, the constant and deliberate evasions I'm seeing suggest to me that you are perfectly well aware of the limitations of your licence, and that you have no intention of acknowledging them. Which makes me think that you're not interested in any sort of meeting of minds here, but only in trying to sell something under false pretences.

If what I describe above isn't what you intended, then I think you some considerable work before you have a viable licence. If it is, then before you start fishing motes from Stallman's eye, you might look at the beams in your own. Either way, as things stand I really don't see the programmer getting a lot of "respect" from your licence.

Quite the reverse in fact.

For stuff such as php or javascript that has to be distributed, it can be shown that the code is the same if necessary

I'm being pedantic, I know, but that's true in the case of Javascript, but not PHP. PHP sits on the server and the only code the user ever sees is it's output.

You can run a PHP server locally, of course and host applications that way. You'd have a valid point in that instance, but I'm not aware of any application that does that. In general, the only way to check the source of a PHP app is to get a court order and seize the servers.

For c/c++, and to a lesser extent java, it's more of a problem ... but this is the same with any compiled code, whether RPL or GPL or prorietary licensed code where the licensee has broken the terms of the license.

I don't think that's true in the case of the GPL. For one thing, you can request the source. If they don't supply it, they're in contravention. If they do, and it doesn't compile to the same image, or do the same things, they're still in contravention. Just ask Harald Welte.

As for derived works, no, you can't, same as you can't derive your own Harry Potter book

And like J.K.Rowling, you are entitled retain the "no derivative works" option. I never said otherwise. What I'm questioning is whether retaining that particular right leads to a better developmental model, and if so, from whose perspective.

If the day ever comes when I need to rewrite portions of J.K.Rowling's books in order for them to share a bookshelf with Terry Pratchett, then the same questions will apply there, too.

Corporations (just like all coders) would have an incentive to do fixes and feature adds the proper way, since it eases their burden for maintenance, etc

If corporations always thought like that, then the "Unix Wars" you referred to earlier would never have happened. And Microsoft would never have chosen an implementation of Kerberos incompatible with the rest of the world. To pick two examples at random. Sorry, but no sale on that point.

Their suggestions and extra eyeballs - financially incentivized eyeballs to actually get the code fixed by the original author so as to save them money in both the short and long term - is a good carrot to offer via the RPL.

See, a lot of corporations out there view Free Software as basically a cancer. Many of them take the view that it drives down their profit margins reducing the artificial scarcity underlying their business model, and that it makes it far too easier for newcomers to compete with them. Some think that the world would be a better if all Free Software were to die a horrible death and the world go back to the way it was in 1980.

Do you really want to argue otherwise?

I don't think the software license should ever become the primary consideration when laying down the architecture of a new project.

And yet it is a major consideration for any project, because it dictates not only what resources you have available, but also what limits you can do to finance the project. Selling software+services is more profitable than selling services alone.

Oh, sure. I mean:

• "do we want to use the GPL because there's a hell of a lot of of GPL code we can legally use if we comply with the licence?"
• "should we use BSD? We'll get more corporate buy in, but if we do anything really cool, the big players will brand it as their own, and we'll never see a cent."
• "do we use a closed licence? There's still a hell of a lot of LPGL we can use and it doesn't obligate us in the least."

All valid questions. Not ones that necessarily need to be addressed Day One, but worth thinking about.

On the other hand ...

• "Dude! We better all go and learn C++ and take a class in software engineering, because otherwise we'll never have the skills work effectively with the RtPL licence"

... doesn't seem like a particularly likely outcome. Maybe it's just me.

Less understanding than with the GPL. For example, you can link RPL'd code with anything you want - the RPL doesn't impose any restrictions

I believe you are conflating expertise in software design with a basic understanding of how the licences work. If you want to tell me that RtPL is easier to read, I won't argue. That wasn't my point, however.

If there are restrictions, they're from other licenses such as the GPL, which points out an area where copyleft licenses such as the GPL are less free.

I think you need to give some specific cases here. I'm not aware of the GPL anywhere saying "thou shalt not use this licence with the following licences", so I'm guessing that's not what you meant. I've seem to recall some discussion here of licences that are worded to specifically exclude the GPL, but that's hardly the GPL's fault. There are also some that do not give you sufficient rights over your own compiled program to also comply with the GPL. Again, it's hard to see that as the GPL's fault.

There's also the case of linking in GPL licenced libraries to non GPL code, which the GPL still doesn't prohibit. Compliance with the licence does involve licensing your souce code under the GPL however, which is why the LGPL was created, and why most libraries use that over the GPL. If you want to talk about Stallman's odd attitude to the LGPL, then I'll probably agree with you, but that is a quite definitely separate point, and one which is very nearly on-topic.

It's also not entirely fair to categorise the terms of a licence as "restrictions" when the GPL does it, and "protection" when the restrictions are from RtPL.

The RPL doesn't lock them out. Unlike closed-source software, they can see the actual code, so they don't have to guess what's going on inside some "black box". But like closed-source software, they don't have to reveal their source to anyone unless they want to, so there's less of a hassle with arguing about distribution.

How can you say that in the same post when you've already said:

Anyone who can't figure out how to call a function in another file, but needs to do a spaghetti-code-style copy-pasta of the function body, shouldn't be writing software anyway. Same as anyone who can't do inheritance should be learning the basics of OOP

So the restrictions imposed on derivative works are OK because people without the skill to work around the those limitations shouldn't be writing software. But that's still OK because those same people aren't being excluded from participating in so far as they can still read the code and marvel at your cleverness even if they presumably don't understand it. Not that there's necessarily any code to read, of course, because distributing it is not a requirement.

I'm glad we got that sorted out.

Look, I think I can see where you're coming from here. You look at the vast amount of open source software available and it seems like it's some mad anarchy with everything being written by schoolkids and hobbyists and people teaching themselves to program, and code being changed almost arbitrarily. So you think to yourself This is awful! We need professional standards here! And so you write a licence that makes it easy to impose centralised control over a project and which requires a certain level of skill to use effectively.

The thing is... I don't think the problems you're solving are problems. That vast array of free software exists today precisely because the GPL made it easy for schoolkids and hobbyists and beginners to pitch in and write stuff. It exists because those same kids were able to change things and see how well the changes worked, and because if they didn't think a decision was the correct one, they weren't required to abide by it. And the GPL also gave them some basic assurances that the first company that found their work useful wouldn't immediately slap a copyright sticker on it and then sue the original developers (which is pretty much the circumstances that let Stallman to draft the licence in the first place).

You'd like to see the free software world operate more like a corporate IT project. Personally, I think that would kill the goose that's laying all these lovely golden eggs. But I don't think RtPL will ever gain enough traction for that to become a problem.

I know you put a lot of thought into RtPL. I understand that you created it to address what you see as specific needs, and I'd prefer not to sit here knocking it. But the more I learn about RtPL, the more it seems like a niche license. If you were starting a project in a scripted language, you had a talented team developers with a good knowledge of software design, and you really want to retain tight control of the codebase, and you were OK with your code being monetized by other people, then see how it might appeal.

I can't say I'd ever use it myself, and I don't think you're going get many projects where all those things are true. But time will tell, I guess.

Well, if people are going to lie, they're going to lie no matter what, right?

Well, if you're talking about Joe Coder from down the road (known him since he was seven, talk to his mom every week at church), then your touching faith in basic human honesty is probably well founded.

But that's not the context in which we were operating. Let's back up a bit. I said:

... you will have made it very easy for the likes of Microsoft and Apple to take the code, rebrand it, tweak it enough to break compatibility, release it under their closed licence, and then throw marketing at the issue until no-one even uses your original software, or even remembers that you wrote it.

The Respect the Programmer License addresses that issue. Anyone can use, for example, a library you wrote, but all modifications to the file have to be made by the original author. So, no breaking compatibility, and any suggestions or feedback they give benefit everyone.

If someone chooses not to distribute the source, it's going to be hard to show them in breach of the licence

To which you just replied (since I can't seem to nest blockquotes more than three deep).

Well, if people are going to lie, they're going to lie no matter what, right?

So, a hypothetical corporation wants to hijack your project by closing the codebase and bundling a closed, incompatible version with their widely-deployed product. You tell me the RtPL provides protection against just that circumstance. And now you're telling me that said protection relies entirely upon huge software corporations telling the truth. Even in cases where to do so would go against their best interests. Seriously?

What'll you do for an encore? Fire-proof safes made out of tissue paper?

The "inability to make derived works" is dealt with in more detail here - in particular answers 7 and 8.

So you can't make derivative works, just like I said. But it is generally possible to code around that restriction by using the same techniques we already use to work with hostile licences and closed hardware. I'm having a hard job accepting that as a plus point, but fair enough.

OK, maybe if we lived In an ideal world, and if everyone followed Robert Martin's design principles and paid particular attention to the Open/Closed Principle, then this wouldn't be particularly inconvenient. But we don't live in that a world, and even if we did, I don't think the software licence should ever become the primary consideration when laying down the architecture of a new project.

You're also requiring a certain understanding of Comp.Sci/Software Eng. before you can effectively interact with the licence. That's going to raise the barrier to entry to the free software world, and in particular lock out a great many kids and hobbyists who might otherwise have become great coders. If you're really worried about Free Software losing talent, that should be a major concern.