One of the principal authors of version 3 of the Gnu General Public License (GPL) has spun off his own version of the license without the participation of the Free Software Foundation (FSF), in a move that could ruffle feathers in the often-cantankerous free software community. The new license has been dubbed GPL.next, and it's …
Get Rid of The Appliance Loophole
I think a simple modification to the definition of distribution that includes appliances with a very clear definition of what is and is not an appliance would suffice.
Re: Get Rid of The Appliance Loophole
Exactly. That was enough and there was no need to do anything more because anti-appliance will cover naturally half of the cloud issues as well.
There was no need to add the anti-patent agenda into it because it is the antipatent agenda which drove a lot of companies to an anti-copyleft position. While nearly everyone (even the patent lawyers) agree that the system is broken trying to use a software license as a crobar to fix it is the wrong approach. It backfired - if a project goes GPL3 its distribution is usually reduced, not increased.
In any case, we have reached the point where the political visibility of the patent issue is at the highest level and the judges are now pissed off at the constant bickering and want it out of their courtrooms. Recent decisions in Google vs Oracle, Motorola vs Apple (the Chicago suit), etc are prime examples of this. So even if we assume that the patent clauses of GPL3 were useful at their inception, they have outlived their usefulness today because there is one "magic" difference between a license verbiage and a court decision - the court decision sticks and is paid attention to by everyone including legal, finances and even marketing and not just software engineers.
As much as the mainstream media love the concept, a fork does not mean war. Different persons can have different opinions and still play nice with each other.
When that happens in a monolithic entity the Fallen Angel and his backers get fired. If they are lucky they can gather enough cash to launch a small company, but hard feelings almost always ensue.
When that happens in the OSS community a fork appears, that may or may not gather sufficient community support to live on its own but most often keeps exchanging the good bits with the original tree. Often gets reintegrated within said original tree once the divergences are sorted out, too.
Not anything special. That's just how the OSS community works (also arguably why it is slow to gain wide layman support: the lack of strong unified marketting strategy...)
Re: fork !=war
The problem here is licence incompatibility meaning that people can't combine code from two different projects with different string copyleft licences. For example Linux can't offer support for ZFS because the licence that the free version of Solaris is released under is not compatible with the GPL.
Can someone explain why it is that when free software type people enlist the help of a whole bunch of random guys to do specialized tasks like writing software and, apparently, legal documents, it's lauded as "collaboration", but when anyone else enlists the help of a bunch of non-experts, it's termed 'crowdsourcing', mocked arrogantly, and dismissed out of hand along with any associated endeavor?
Just wondering, you know.
> Just wondering, you know
You obviously have a lot of free time on your hands. Why don't you spend some of it contributing to a FOSS project?
I don't know when crowdsourcing became a pejorative. It was originally coined from that lovely phrase "the wisdom of crowds" and assumed that collaborative efforts "sourced" from the "crowd" would produce high quality works.
Crowdsourcing... one of those slightly obnoxious terms used to describe asking a group of people what their opinions are. A bit like focus groups, without any real focus, or ANY FOSS project team. However, the main thing I've been wondering is this...
If a CS group speaks English, is it considered open-scrowd-sourcing, and if they speak only Cornish or Welsh, is it considered closed-crowd-sourcing?
Nah, it'd be open source, but it'd be the equivalent of an open source project written entirely in COBOL.
FOSS versus Crowdsourcing
FOSS development gets a bunch of people together to develop something for a non-profit (or even charitable) cause. The labout is free, but so is the end product.
Crowdsourcing outside FOSS is almos universally an attempt by a for-profit organisation to get large quantities of labour from skilled individual for free.
See: The Huffington Post.
In short: FOSS is good, we all get something from it. But fuck for-profit crowdsourcers with 4 Vesta. Dry.
Re: FOSS versus Crowdsourcing
labout = labour.
Re: FOSS versus Crowdsourcing
> But fuck for-profit crowdsourcers with 4 Vesta. Dry.
"FERITE" is probably the acronym you're looking for...
 Right In The Eye
Crowdsourcing implies to me ...
a commercial entity trying to get stuff done on the cheap by throwing it a crowd of ill-qualified numpties.
Collaboration in OSS tends to be small-ish numbers (on any given project) of highly motivated techies.
IMHO, of course, but that's the difference I see.
Re: Optional re: AC 08:43
"You obviously have a lot of free time on your hands. Why don't you spend some of it contributing to a FOSS project?"
I have a lot of time on my hands because I wrote a two paragraph reply to a Reg article?
I don't spend some of my time contributing to a FOSS project because:
1) I'm not a coder, nor a UI designer, nor a documentation editor. I have neither the experience nor the motivation to do such things, not because I don't value them, but because I just have other interests. It's not any more unreasonable of me to not contribute to a FOSS project than it is for me to not volunteer my time at a pro-bono legal firm. I'm not qualified, and would be a liability.
2) I suspect that, contrary to your assertion, contributing meaningfully to a FOSS project - ie, learning the project inside and out, getting to know the people involved, becoming skilled with the particular technical issues involved, and not least, learning how the entire FOSS process occurs and what specific goals the project has and finding and implementing a way to attain them - will take longer than writing the above (or this) post.
3) If I agree to contribute to a project, I'm making a commitment. Even if it, on average, took only N hours per month, the fact that I have those N hours to spare at various times doesn't mean I can do it - if anyone else's work was dependent on mine, my work with my own business, travelling, family commitments, etc, would mean that I couldn't guarantee any particular work done at any particular time. Only working on small pieces wouldn't make sense either; the overhead for learning process and technical skills just to do occasional isolated bits of work would be absurd; I would waste far more of the existing contributors' time asking questions than I could possibly contribute in return.
4) See above. I'm simply not motivated to do software design at this point. This doesn't mean I'm a hypocrite for challenging any particular aspect of an article about FOSS. I don't think you would consider yourself a hypocrite if you questioned an inexplicable decision by a UN charity program, just because you don't do UN charity work yourself.
If we were allowed to question only those things we personally involve ourselves in, then democracy itself would be pointless, as criticizing the decisions of lawmakers by anyone not involved in law would be considered hypocritical. Clearly it is not.
Does that answer your question?
If you can't even agree a license without forking it, what hope is there for the actual software projects?
I get the impression you misunderstand forking--as in, the empirical approach of taking two paths and see which one works best. There are pros and cons as with any decision, but no negative connotations.
If interested on the subject, I encourage you to contribute to a FOSS project of your choice to gain a better understanding.
There certainly are negative connotations if software you rely upon goes off in two directions and you have to guess which fork will best suit your users.
Still beats when there's only one path and you find it doesn't go anywhere near where you want.
At least with a forked project it is usually possible to backtrack across to another fork if it turns out to be going the wrong way.
@Richard 12 - You've never worked in a corporate environment have you? If I suggested to my employer that we should take a guess at which fork to follow in a product, we followed it and it was abandoned or changed beyond use for us, then I suggested to him that we should back track and try the other, the question would be along the lines of "Why? We've been screwed over by this project and your guesswork once, why not buy some commercial software with support and a roadmap and you may get to keep your job, if you're lucky."
Witness the Open/Libre office debacle.
I don't see how the Open/Libre Office fork can be characterised as a "debacle", quite the opposite, it was a demonstration of how the ability to fork inherent in free software projects can be an advantage for the end users.
Very quickly there was no doubt as to which branch users should follow. Everyone that mattered went to LibreOffice. The major Linux distributions adopted it within a few months and the project was re-invigorated after years of stagnation. The same thing also happened in the transition from XFree86 to X.org.
Contrast this with being locked in to a proprietry product which the vendors decide to neglect or take in the wrong direction. You think you would be better off?
@AC 7/7 17:42
I do work in a corporate environment, and you've missed the point.
You must never forget the risk of all external suppliers - what happens when the supplier changes their roadmap, decides to end-of-life a particular product, get out of that business area altogether or goes bankrupt?
The severity of these events are far higher for proprietary commercial software because you cannot fork it or take it over once abandoned - even if you have the source code (which you probably don't), your licence can evaporate so you can no longer use it at all!
If an Open Source thing gets abandoned you've always still got the source code and a licence to use it, fork it and even take it over entirely if you want. Thus the severity of the maintainer giving up is small.
The probability of these risks depends on the product you're using, the supplier and your contract with them. That's actually the hardest part about picking which product to use.
I know of several projects that have been completely screwed over by proprietary commercial software components going a different way to their roadmap at short notice.
I also know of projects where an open-source component lost the maintainer. It was merely annoying.
For example, we have to keep a copy of an ancient version of MS Visio because one of the commercial tools we use is a plugin for it, and their plugin does not run in newer versions. It's not an old or cheap product either.
Re: @AC 7/7 17:42
"If an Open Source thing gets abandoned you've always still got the source code and a licence to use it, fork it and even take it over entirely if you want. Thus the severity of the maintainer giving up is small."
Not for a normal user, for whom the source is as useless as the binary. I could have the source to Photoshop, but it would do me absolutely no good, since I have neither the tools nor the expertise to take advantage of it.
Sure, for something as popular as Photoshop, other people would most likely jump in, but for anything without a rather large audience, it's dicey. And relying on other people to decide to keep everything fixed and running for free is hardly more reliable than hoping that Adobe doesn't go down in a ball of flames. In neither case will you have any particular control over the direction of the project.
And in the case of a small project that -is- taken up by the community, the amount of time required to keep up with development, get releases (which will often require use of tools you're not able to work with; not everyone can compile stuff on the command line or has the time to learn how - shocking, I know) is large enough as to make the whole thing pointless.
There seems to be an obsession over having source code on the part of FOSS people - but what they forget is that for 99% of normal users, source is utterly useless, and relying on a FOSS group to work on something vs. a commercial entity is, at best, and equal shot. And for anything strange, like, say, ladder logic editors for certain types of PLC hardware, the odds of a group of competent people taking up the banner and doing useful releases is near zero.
FOSS licenses are very useful for other people who develop FOSS, but they really aren't any good to end users; all they guarantee is that you don't pay up-front money for the use of the application. Beyond that, they have little practical value for someone who just double clicks and goes - so the assertion that this is 'all about the user' is disingenuous.
Re: @AC 7/7 17:42
> but it would do me absolutely no good, since I have neither the tools nor the expertise to take advantage of it.
This is incorrect.
Having source *does* do you some good, even if you're not a coder.
It gives you the possibility of taking that source to a coder to get things done to it.
So if a project is abandoned, you could arrange for your needs to be covered as you see fit. You have both the rights and the opportunity to do so. This cannot be said of a proprietary code, where you just won't often get the source, even if the author never wants to see it again.
There is obviously some cost in this route - but it's *your* decision whether or not the rewards warrant that sort of outlay.
"Witness the Open/Libre office debacle"
[[Category:People mistaking words for their antonyms]]
Re: @AC 7/7 17:42
"Not for a normal user, for whom the source is as useless as the binary. I could have the source to Photoshop, but it would do me absolutely no good, since I have neither the tools nor the expertise to take advantage of it."
I think you are mistaking individual benefit with benefit to the community. Your argument above follows (albeit in reverse) the same line of though of people who play lottery because "someone always win". It's the same here: the probability that any one specific individual will personally benefit from having the source code is statistically zero; the probability that the community will benefit, however, is statistically significant (maybe close to one in the case of a large project?).
Re: @AC 7/7 17:42
" It's the same here: the probability that any one specific individual will personally benefit from having the source code is statistically zero; the probability that the community will benefit, however, is statistically significant (maybe close to one in the case of a large project?)"
Well, first, as I said, for anything very far away from mainstream (the aforementioned PLC programming software) the community benefit is near zero, not near one - particularly in the case of software which isn't of any interest to the kind of people who take part in open source projects. I can't imagine that there are going to be a swarm of enthusiastic coders crawling all over the source to a dental office management program, or something.
Second, that would be all well and good if the argument people make wasn't obviously and heavily skewed toward specifically pointing out the options for individuals: "You can make the changes yourself", "You can compile it yourself", "You just have to blah blah".
The argument quite often has nothing to do with the community - and in fact, one of the responses above suggested that in particular I'm not deserving of consideration *unless* I contribute personally.
The argument that it's possible to pay someone else to work on a deserted open source project but not on a deserted closed source project is well-taken, but again, for any major application, it's useless. I'm not going to hire a coder to maintain Photoshop for me.
"Some money", in the case of that argument, by definition will approach some multiple of "The amount of money it was costing to maintain the thing before". Even if greater efficiency and more limited scope reduce the multiplier by quite a bit, that number will still be wildly out of proportion to any sane investment. It will certainly be larger than to buy any equivalent 'new' piece of software commercially.
Open source would be extremely useful for extremely limited audience, mission-critical stuff that tends to be used by places with relatively big budgets (say, software that controls machines that do IC lithography).
For Some Guy using Some Application, he's as beholden to the vagaries of the market as he was before - except in this case the market is determined by the people who are interested in working on the project, rather than the number of people willing to pay a company for it.
It's *different*, but it's not a given that it's *better* for any particular application or usage. And the problem with even discussing it is that anyone who suggests anything like that is immediately ostracized (or thumbs-downed, as the case may be). Like it or not, and however many counter-examples you come up with, the FOSS community is often insular, hostile to outsiders, and violently attacks anyone who questions the party line.
As one of the end-users I've talked about, and even as one more capable than most regarding software development, I see this attitude from the community enough to trigger the 'run away!' response - this thread being a case in point.
Responding to a skeptic (particularly so, since skeptics are the ones who you need to convince, by definition) with "You obviously have a lot of free time on your hands. Why don't you spend some of it contributing to a FOSS project?" is essentially saying, "Stick it up your ass." If 10% of people respond that way, being involved becomes intolerable - and I'm certainly not going to hang my business on a community when a good chunk of its members are outwardly hostile and most of the rest tolerate them without a breath of criticism.
A rose by any other name...
"One condition is that they go by a different name – hence, GPL.next (and no reference to Gnu)."
It doesn't seem very different to me.
Perhaps Samsung should call their next tablet the "iPad.next" and see just what a difference the suffix makes.
A few sore spots with the GPL...
One of the big problems with the GPL is where code sharing happens between projects that use the BSD license, and those that use the GPL, and also, commercial use of GPL code.
I like the GPLv2, and its relation, the LGPL. I like the fact that end users of a piece of code are theoretically allowed to see the code and modify it.
Three problems though:
(1) While a company is required to distribute the sources, there's no stipulation as to when this happens. It's up to a court of law. So companies like Vimicro make all these SoC devices, port the Linux kernel over, companies compile it and distribute the binary blob -- the end user has nothing to work with.
(2) In the case of statically linked binaries, the GPL is incompatible. There are times you'll want to prohibit the linking of open source code to a binary blob, and there are times you want to permit it. The LGPL sort-of allows it -- you have to provide the binary blob as well. I personally don't mind if my embedded code is distributed without such a binary blob (and being code for a MCU, it'd be statically linked), provided the changes made to *my* code are made available at the time of the device's release, but the LGPL makes no provision for doing this.
(3) Often when companies do pass on the code, they do so under a NDA. I don't know about other authors of GPL/LGPLed code, but I do *NOT* want *MY* code to be subject to a NDA.
BSD looks close to what I want, but it doesn't make any stipulation that you pass on the sources or any changes. That said, if I have to write my own (and I'm no lawyer), it'll probably be my starting point rather than the GPL as it's written pretty much in plain English, and is straight and to the point.
Re: A few sore spots with the GPL...
It's late and I may be mistaken, but I'm sure I see a few errors here.
My recollection is that the license mandates that the source (or an offer of) be distributed with code.
Statically linked binaries can be an issue, but remember the GPL is more about the users rights. It's no use you (as a user) being passed the source to code that you can't even use because you can't get hold of one of the libraries. It would be nice to have the choice as a developer though.
I've not heard of companies requiring an NDA for the GPL, I've no idea if the license allows it or not, but it'd certainly be interesting to know.
I think the BSD license suits somethings quite well, important libraries like the TCP/IP stack and things. It makes it a lot easier to help ensure wide spread support of these protocols. I mean would we be able to SSH into so many things without the BSD license (am I remembering correclty or have I just made this up?)
I seem to recall Linus Torvalds wrote his own license for Linux but instead went with the GPL. To be fair, you've got to be really careful about writing a license to have a chance of making it stick in court.
Re: A few sore spots with the GPL...
> In the case of statically linked binaries, the GPL is incompatible.
This is deliberate. The GPL sets out to copyleft all derivative works, and is generally successful This is a Good Thing(tm).
> The LGPL sort-of allows it -- you have to provide the binary blob as well.
This is not true. The LGPL permits linking against a proprietary blob. You only have to supply the LGPL work (as source).
> Often when companies do pass on the code, they do so under a NDA.
An NDA does not excuse the distributor from his obligations under (L)GPL. It also usually contravenes the "no additional clauses" rule (GPLv2 Section 6, for example).
> BSD looks close to what I want
BSD is a great licence, but it does not impose copyleft obligations. Given your misunderstanding of GPL, and your desire for copyleft, I'd recommend you look again at the GPL.
Re: A few sore spots with the GPL...
"I'd recommend you look again at the GPL"
The problem I have with the GPL is that of code reuse. If I wish to use some GPL code within my "open source" project, I am obliged to release the project as GPL. Reading the text of the GPL, it is clear to me that GPL is only compatible with itself. This, I presume, is why there are variants such as LGPL.
Which begs the question - does this project have a codebase to support it? It might be a fork of the GPL, but it is not the GPL.
Maybe one day, we'll all have an open source licence that promotes true freedom, not trying to squeeze in restrictions while talking big about supposed freedoms [hint: EUPL (pdf) is a good start].
@heyrick - Re: A few sore spots with the GPL...
"The problem I have with the GPL is that of code reuse. If I wish to use some GPL code within my "open source" project, I am obliged to release the project as GPL."
That is a feature, not a bug.
"Maybe one day, we'll all have an open source licence that promotes true freedom, not trying to squeeze in restrictions while talking big about supposed freedoms [hint: EUPL (pdf) is a good start]."
I looked at that license, have you read it? I'm not sure what point you're trying to make, that license is substantially similar to the GPLv2, in that it requires source provision when distributing and specifies that derivative works must come under the same license.
Re: @heyrick - A few sore spots with the GPL...
"I looked at that license, have you read it?" - of course I have read it, I release code under it. Duh.
"specifies that derivative works must come under the same license" - are you sure you actually read it? Try "Compatibility clause" under section 5. That is what freedoms should be, not GPL's "All your code are belong to us" approach. But I'm sure I'll get downvoted more as some GPL advocates are too religiously bound in the cause to understand that their concept of freedom is a little too restrictive to be called freedom...
Re: @heyrick - A few sore spots with the GPL...
And some GPL haters obviously have their own definition of free and open computing that doesn't involve preserving freedoms for the user.
Yes, I read the compat clauses - all the compat licenses are copyleft licenses, mostly copyleft licenses that are substantially similar to the GPL. I'm still not sure of the point you're trying to make here.
Note that if using the EUPL you're really releasing under the most permissive of the compatible licences, likely the Eclipse public license or Common public license. These provide weaker protections (and therefore less 'freedom', which seems to concern you so much) for the end user.
The project is now named copyleft.next.
It's also clearly not presented as a competitor to the GPL v3 but an experimentation project based on the GPLv3 (not even an actual license in itself, not yet).
It's actually closer to a *-ng version (bleeding edge experimentation on new things that might get put into the main, production version eventually) than an actual fork...
"Although the FSF discourages modified versions of the GPL, they are permitted, provided they meet certain conditions"
And who are the self-appointed FSF to dictate what is and what is not "permitted"? Arrogant sods.
Why such a fuss over someone coming up with another s/w license though? Big deal...