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.