Interestingly, the Metroid Prime games do this too -- but there it doesn't constitute a fourth wall violation since you (Samus) are supposed to be wearing a helmet with a visor.
Granting the existence in copyright law of a lower limit, the fact remains that a licence can extend the rights available under copyright law; would you accept that a licence could even set its own definition of "derived work", should it so choose, and that such a definition would supersede the official one (but only for that work)?
Possibly; but the BSD license does not do this. (If you disagree, please show the portion of the BSD license which offers an alternate definition for the term "derived work" or any comparable one used in the license; legal documents must be explicit about that kind of thing.)
(To clarify, I'm entirely in sympathy with your point that it isn't moral to merely add your assertion of copyright to the top of a file you haven't otherwise touched.)
While I don't think it's moral either, my point is that it isn't permissible under copyright law.
However, the BSD licence explicitly permits reproduction in any form so long as the original copyright text is preserved. So you may not be able to enforce copyright, because you don't have anything to license - but the BSDL leaves you free to (passively) assert copyright, provided that you otherwise comply with the terms of the BSDL.
Whether or not you can legitimately assert copyright is governed by regular copyright law. The BSDL is silent on the question (if it weren't, and allowed such a claim, it would constitute a grant rather than a license).
Which presumably implies that if you obtain a file which is identical to its BSD-licensed predecessor except for a declaration of relicensing at the top, you're actually free to strip off that declaration and use the rest of the text under the terms of the BSD licence, on the grounds that the relicensor had not done enough to create a derived work...
I believe that much is correct, as a practical matter.
I'm sure you meant it as a pleasantry, but to me it actually sounds quite menacing.
My apologies; no threat was intended.
I maintain that if you meant "substantial", you should have said "substantial"
The two words aren't entirely interchangable; I'd used "substantive" for its weaker connotation (similar to "adequate" versus "sufficient"). Evidently that was a poor decision, particularly as the Copyright Office uses "substantial".
...the "twelve line" test you mention above was determined in answer to almost precisely the opposite question: namely, what is the greatest amount a work may include of another work whilst still not being considered derived from that work...
I think the first part is a fair criticism; it isn't always clear how applicable a court ruling is to a different question to the one it was intended to answer. However, the question at hand is a lower limit for addition, not an upper limit for inclusion. So, the decision may apply to this lower limit, or it may not (hence my advice to consult a lawyer), but regardless of that there is a lower limit. As the US Copyright Office circular on Copyright Registration for Derivative Works says:
"To be copyrightable, a derivative work must be different enough from the original to be regarded as a "new work" or must contain a substantial amount of new material. Making minor changes or additions of little substance to a preexisting work will not qualify the work as a new version for copyright purposes. The new material must be original and copyrightable in itself. Titles, short phrases, and format, for example, are not copyrightable."
Whether the new material qualifies for copyright determines whether it is legitimate to add your own copyright declaration to the header.
Perhaps I was too harsh -- you could have been looking at definition 2c of "substantive[2,adjective]"; had you been looking at "substantive[1,noun]" you would also have to have confused etymology with definition. That being the case, I'm puzzled why you didn't notice that the adjective had other definitions, as the one you offered was not even the first.
Friend, there's a difference between nouns and adjectives. I meant "substantive changes" in the sense of "considerable in amount or numbers", which m-w.com gives as the fourth meaning of "substantive[2,adjective]" and is in that sense a near-synonym to "substantial". You appear to have been looking at "substantive[1,noun]".
The next time you want to argue with someone over what a word means, try learning the distinctions among the different parts of speech.
(Also, it may not be so wise to argue with someone over what a writer really meant, when that same writer is immediately available to correct you.)
"Enough to constitute a separate (derivative) work."
My own rule of thumb is about a dozen semantically significant lines of original code. This corresponds roughly to what I think is the current precedent in the US of ten lines as a minumum to be copyrightable, assuming that those ten lines otherwise meet the statutory requirements. However, please consult a lawyer if you want a legal opinion.
I think Theo is essentially correct. To the best of my knowledge, the ground rules are:
1. Don't touch the license header unless you make substantive changes
2. If you make substantive changes, you may amend the license header to add your copyright (but not remove existing copyrights) under the same license
3. If you make substantive changes and insist on licensing those changes under a different (but compatible!) license to the original, you may add a new license header above the existing one with your copyright (without modifying the existing header)
The initial problem was that the original license header was replaced entirely, even though no substantial changes had been made. The original license header has now been restored, but there is still an issue with a new copyright declaration having been added in the absence of substantive changes.
That's a good question. It may explain why McVoy used extra-legal channels to try to enforce it; for instance, in at least the cases of Andrew Tridgell and Bryan O'Sullivan, rather than having a lawyer send legal notice to an "offender", he tried to threaten the person by calling their employers instead.
I find the fact that Linus was on board with this (he publicly sided with McVoy in Tridgell's case) pretty distasteful.
You can't only see bad things in closed source software.
I don't. I still think BitKeeper was (at the time of the controversy) the superior solution on purely techincal merit, even if git has surpassed it since.
So in the end, closed source was hurt more than open source. There are no IFs in history.
If McVoy had remained unchalleged, git would never have existed. At least one other Open Source SCM project (I think it was monotone?) also lost a core developer to McVoy's license. If McVoy's effort was a strategic failure, that still doesn't excuse his actions (or Linus').
People will simply be more mature and responsible about it.
Do you say this on the basis of wishful thinking, or prior experience?
In the short-term, I'd say it set things back by about two years. In the longer term, I don't think Larry was particularly successful. We did get git out of this whole mess in the end, but that wouldn't have happened if Larry McVoy had prevailed.
But Jeremy Allison wasn't bound by the license! He never used Bitkeeper, was never bound by the terms of its license, and therefore wasn't violating it.
McVoy was using BK as an instrument to gain control over Open Source SCM for monetary gain, by inserting his SCM in the Linux kernel development process, with a license requiring that anyone who used it agreed not to work on SCM software of their own, in an effort to ensure that there would be no Open Source alternatives. And Linus was content to go along with this, because BK really was a superior solution technically.
Allison, who happened to work for the same employer as Linus, reverse-engineered the BK protocol _on his own time_, again, without violating the license because he had never needed to agree to it. He did this in order to write an open-source read-only client for BitKeeper, so that people could access the full kernel repository without agreeing to the BitKeeper license. McVoy hit the roof, started spamming Jeremy and Linus' employer with legal threats, tried to get Jeremy fired, and then when that didn't work (they didn't care because he was working on his own time), punished everyone by withdrawing the free BK license. Linus, being bound by the same non-compete agreement as everyone else who had used Bitkeeper to access the kernel source repository, wrote as much of git as he could (stopping short of what actually constituted a fully-functional SCM), and then let Junio Hamano do the rest.
Whatever other personality issues are in play, this is exactly the kind of problem that RMS is concerned with: Linus was prepared to let a control freak like McVoy try use the Linux kernel project as a strategic wedge to block the development of Open Source SCM software and promote his own proprietary solution, simply because it was convenient for Linus and he was friends with McVoy. Linus has a history of doing whatever is personally convenient, without regard for long-term consequences or the effect it has on others.
Having just read the blog comments, they didn't really help. What are the "correct" conclusions supposed to be?
I've been a defender of yours in the past (e.g. prior to Sun's dramatic liberalization of Java, I was advocating Mono as the least worst alternative), but this situation with Moonlight leaves me very uncomfortable. While the Mono patent policy seems sane, it seems the Moonlight policy means that Moonlight fails the "could you fork it?" acid test -- at least, forking Moonlight would mean knowingly assuming a patent liability with respect to Microsoft. That's a bit different from a project which has a less direct relationship with Microsoft IP.
You know, it's a little bit depressing to realize that cat is 19k large.
Re:Full-time Erlang programmer gives his view :]
on
Programming Erlang
·
· Score: 1
The thing is, in my 1.5 years nobody told me that the essence of functional programming is the lack of loops but using these combinators instead. So I have learnt something new here, thank you for the insight.
You're welcome; it's an insight that made a big difference for my own programming when I finally grasped it, and I'm glad to pass it on. It's sort of obvious in retrospect: recursion is just the dual of iteration, and the whole point of functional programming is being able to capture concepts as higher-order functions. But in reality it took me a lot longer than 1.5 years to really "get" that.
But still taking out my gripe about the lack of "for" loop (sorry but I am accustomed to imperative programming, I grew up on Assembly:) ), what weaknesses I wrote about Erlang - or at least for the pieces of code I have seen in Erlang - still stand imho.
I agree with you on some of them, too. The VM and network protocols in particular are woefully under-documented and rather crufty. I've also been pretty unimpressed with the little bit of Erlang code that I've seen (at low levels, anyway; the overall architecture of things can be quite nice). But the declarative thing touches on another essence of functional programming: ideally, functional programs don't change things as side-effects of their evaluation, but they declaratively describe the mapping from old states (as parameters) to new states (as results). I think one of Erlang's weaknesses is that in some ways it is neither fish nor fowl: the language itself is quite functionally "pure", but important parts of the standard library (actors, IO) still aren't. Imperative techniques are implicitly encouraged in a language that doesn't really support them.
btw are you the Mentalguy mentioned in the mikmod credits ?
Yes, that's me. Kevin Vance and I contributed the loader for the GDM format; I reverse-engineered and documented the format (using the existing documentation as a starting point), and Kevin did most of the heavy lifting.
Re:Full-time Erlang programmer gives his view :]
on
Programming Erlang
·
· Score: 1
Had you considered using lists:dropwhile? It's effectively like lists:foreach, except that it expects a function returning bool() and stops as soon as that function returns false. It might make sense to wrap it in a more appropriately-named function for readability's sake, though:
For more complex cases, you can often preprocess the list with lists:takewhile, lists:filter, etc.; breaking your list processing into a pipeline with several stages can often be a good strategy. Generally, the one thing that stdlib is missing is a short-circuiting fold:
It's not needed in a lazy language like Haskell, but I would miss it occasionally in a strict language like Erlang. This is a case where it would need to be a custom job; the best you could do atop stdlib would be something like:
Regardless, if you find yourself needing explicit recursion, try refactoring it out into a custom combinator. If your experience is like mine, you'll likely find there's a small set of them which you use on a regular basis, and possibly that some of them correspond to combinators already in stdlib.
No, people are suggesting that it is a good idea to update code in applications in real time without a complete redeployment, which should include storing modifications that are going to be applied to production within some sort of a source control system, then installing the entire code base that will be deployed in production to some testing / staging environment, then moving code to production.
I am saying that allowing deployments of a function or of a line of code to production needs to be done only in very special cases and controlled environments that have processes that allow for these kinds of modifications.
Well, that makes total sense. The thing is that the Erlang/OTP Release infrastructure doesn't easily allow piecemeal updates; it's designed to enable full deployments with no (or minimal) downtime. You might be interested in reading about release handling principles under OTP. I'm sure the system can be abused, but it's not the free-for-all that some people seem to think.
Maybe I'm missing something, but all of the turing-complete approaches to computation are equivalent, and there are accordingly transformations between them. What makes this transformation more trivial than the others, that it renders the distinction between logic and functional programming less meaningful than the distinction between functional and any other approach?
Slashdot Mirror
Interestingly, the Metroid Prime games do this too -- but there it doesn't constitute a fourth wall violation since you (Samus) are supposed to be wearing a helmet with a visor.
If only we could bring back Jon Postel, seriously. :(
Possibly; but the BSD license does not do this. (If you disagree, please show the portion of the BSD license which offers an alternate definition for the term "derived work" or any comparable one used in the license; legal documents must be explicit about that kind of thing.)
While I don't think it's moral either, my point is that it isn't permissible under copyright law.
Whether or not you can legitimately assert copyright is governed by regular copyright law. The BSDL is silent on the question (if it weren't, and allowed such a claim, it would constitute a grant rather than a license).
I believe that much is correct, as a practical matter.
My apologies; no threat was intended.
The two words aren't entirely interchangable; I'd used "substantive" for its weaker connotation (similar to "adequate" versus "sufficient"). Evidently that was a poor decision, particularly as the Copyright Office uses "substantial".
I think the first part is a fair criticism; it isn't always clear how applicable a court ruling is to a different question to the one it was intended to answer. However, the question at hand is a lower limit for addition, not an upper limit for inclusion. So, the decision may apply to this lower limit, or it may not (hence my advice to consult a lawyer), but regardless of that there is a lower limit. As the US Copyright Office circular on Copyright Registration for Derivative Works says:
"To be copyrightable, a derivative work must be different enough from the original to be regarded as a "new work" or must contain a substantial amount of new material. Making minor changes or additions of little substance to a preexisting work will not qualify the work as a new version for copyright purposes. The new material must be original and copyrightable in itself. Titles, short phrases, and format, for example, are not copyrightable."
Whether the new material qualifies for copyright determines whether it is legitimate to add your own copyright declaration to the header.
Perhaps I was too harsh -- you could have been looking at definition 2c of "substantive[2,adjective]"; had you been looking at "substantive[1,noun]" you would also have to have confused etymology with definition. That being the case, I'm puzzled why you didn't notice that the adjective had other definitions, as the one you offered was not even the first.
Friend, there's a difference between nouns and adjectives. I meant "substantive changes" in the sense of "considerable in amount or numbers", which m-w.com gives as the fourth meaning of "substantive[2,adjective]" and is in that sense a near-synonym to "substantial". You appear to have been looking at "substantive[1,noun]".
The next time you want to argue with someone over what a word means, try learning the distinctions among the different parts of speech.
(Also, it may not be so wise to argue with someone over what a writer really meant, when that same writer is immediately available to correct you.)
"Enough to constitute a separate (derivative) work."
My own rule of thumb is about a dozen semantically significant lines of original code. This corresponds roughly to what I think is the current precedent in the US of ten lines as a minumum to be copyrightable, assuming that those ten lines otherwise meet the statutory requirements. However, please consult a lawyer if you want a legal opinion.
I think Theo is essentially correct. To the best of my knowledge, the ground rules are:
1. Don't touch the license header unless you make substantive changes
2. If you make substantive changes, you may amend the license header to add your copyright (but not remove existing copyrights) under the same license
3. If you make substantive changes and insist on licensing those changes under a different (but compatible!) license to the original, you may add a new license header above the existing one with your copyright (without modifying the existing header)
The initial problem was that the original license header was replaced entirely, even though no substantial changes had been made. The original license header has now been restored, but there is still an issue with a new copyright declaration having been added in the absence of substantive changes.
Perhaps you're right. I just learned that earlier this year McVoy finally released a GPLed bitkeeper client.
Awesome! It's good to know he finally backed down about this.
That's a good question. It may explain why McVoy used extra-legal channels to try to enforce it; for instance, in at least the cases of Andrew Tridgell and Bryan O'Sullivan, rather than having a lawyer send legal notice to an "offender", he tried to threaten the person by calling their employers instead.
I find the fact that Linus was on board with this (he publicly sided with McVoy in Tridgell's case) pretty distasteful.
And, as I noted in my other post, if McVoy ultimately failed to suppress Open Source SCM development, it wasn't for lack of trying.
Ah, it was Mercurial, not Monotone. Larry McVoy threatened Bryan O'Sullivan into leaving the Mercurial project.
I don't. I still think BitKeeper was (at the time of the controversy) the superior solution on purely techincal merit, even if git has surpassed it since.
If McVoy had remained unchalleged, git would never have existed. At least one other Open Source SCM project (I think it was monotone?) also lost a core developer to McVoy's license. If McVoy's effort was a strategic failure, that still doesn't excuse his actions (or Linus').
Do you say this on the basis of wishful thinking, or prior experience?
In the short-term, I'd say it set things back by about two years. In the longer term, I don't think Larry was particularly successful. We did get git out of this whole mess in the end, but that wouldn't have happened if Larry McVoy had prevailed.
As others have pointed out, it was Andrew Tridgell, not Jeremy Allison. The rest still stands though.
But Jeremy Allison wasn't bound by the license! He never used Bitkeeper, was never bound by the terms of its license, and therefore wasn't violating it.
McVoy was using BK as an instrument to gain control over Open Source SCM for monetary gain, by inserting his SCM in the Linux kernel development process, with a license requiring that anyone who used it agreed not to work on SCM software of their own, in an effort to ensure that there would be no Open Source alternatives. And Linus was content to go along with this, because BK really was a superior solution technically.
Allison, who happened to work for the same employer as Linus, reverse-engineered the BK protocol _on his own time_, again, without violating the license because he had never needed to agree to it. He did this in order to write an open-source read-only client for BitKeeper, so that people could access the full kernel repository without agreeing to the BitKeeper license. McVoy hit the roof, started spamming Jeremy and Linus' employer with legal threats, tried to get Jeremy fired, and then when that didn't work (they didn't care because he was working on his own time), punished everyone by withdrawing the free BK license. Linus, being bound by the same non-compete agreement as everyone else who had used Bitkeeper to access the kernel source repository, wrote as much of git as he could (stopping short of what actually constituted a fully-functional SCM), and then let Junio Hamano do the rest.
Whatever other personality issues are in play, this is exactly the kind of problem that RMS is concerned with: Linus was prepared to let a control freak like McVoy try use the Linux kernel project as a strategic wedge to block the development of Open Source SCM software and promote his own proprietary solution, simply because it was convenient for Linus and he was friends with McVoy. Linus has a history of doing whatever is personally convenient, without regard for long-term consequences or the effect it has on others.
Well said, sir.
That's a good example, actually. With standards, once the bug's out in the wild, you're stuck with it.
Having just read the blog comments, they didn't really help. What are the "correct" conclusions supposed to be?
I've been a defender of yours in the past (e.g. prior to Sun's dramatic liberalization of Java, I was advocating Mono as the least worst alternative), but this situation with Moonlight leaves me very uncomfortable. While the Mono patent policy seems sane, it seems the Moonlight policy means that Moonlight fails the "could you fork it?" acid test -- at least, forking Moonlight would mean knowingly assuming a patent liability with respect to Microsoft. That's a bit different from a project which has a less direct relationship with Microsoft IP.
You know, it's a little bit depressing to realize that cat is 19k large.
You're welcome; it's an insight that made a big difference for my own programming when I finally grasped it, and I'm glad to pass it on. It's sort of obvious in retrospect: recursion is just the dual of iteration, and the whole point of functional programming is being able to capture concepts as higher-order functions. But in reality it took me a lot longer than 1.5 years to really "get" that.
I agree with you on some of them, too. The VM and network protocols in particular are woefully under-documented and rather crufty. I've also been pretty unimpressed with the little bit of Erlang code that I've seen (at low levels, anyway; the overall architecture of things can be quite nice). But the declarative thing touches on another essence of functional programming: ideally, functional programs don't change things as side-effects of their evaluation, but they declaratively describe the mapping from old states (as parameters) to new states (as results). I think one of Erlang's weaknesses is that in some ways it is neither fish nor fowl: the language itself is quite functionally "pure", but important parts of the standard library (actors, IO) still aren't. Imperative techniques are implicitly encouraged in a language that doesn't really support them.
Yes, that's me. Kevin Vance and I contributed the loader for the GDM format; I reverse-engineered and documented the format (using the existing documentation as a starting point), and Kevin did most of the heavy lifting.
Had you considered using lists:dropwhile? It's effectively like lists:foreach, except that it expects a function returning bool() and stops as soon as that function returns false. It might make sense to wrap it in a more appropriately-named function for readability's sake, though:
foreachwhile(Fun, List) ->
lists:dropwhile(Fun, List),
void.
For more complex cases, you can often preprocess the list with lists:takewhile, lists:filter, etc.; breaking your list processing into a pipeline with several stages can often be a good strategy. Generally, the one thing that stdlib is missing is a short-circuiting fold:
foldlwhile(Fun, Acc0, [Elem|Tail]) ->
{Continue, Acc} = Fun(Elem, Acc0),
if
Continue -> foldlwhile(Fun, Acc, Tail);
true -> Acc
end;
foldlwhile(_Fun, Acc0, []) -> Acc0.
It's not needed in a lazy language like Haskell, but I would miss it occasionally in a strict language like Erlang. This is a case where it would need to be a custom job; the best you could do atop stdlib would be something like:
foldlwhile(Fun, Acc0, List) ->
element(2, lists:foldl(fun (Elem, {true, Acc}) -> Fun(Elem, Acc);
(_, result) -> result end,
{true, Acc0}, List)).
Regardless, if you find yourself needing explicit recursion, try refactoring it out into a custom combinator. If your experience is like mine, you'll likely find there's a small set of them which you use on a regular basis, and possibly that some of them correspond to combinators already in stdlib.
Well, that makes total sense. The thing is that the Erlang/OTP Release infrastructure doesn't easily allow piecemeal updates; it's designed to enable full deployments with no (or minimal) downtime. You might be interested in reading about release handling principles under OTP. I'm sure the system can be abused, but it's not the free-for-all that some people seem to think.
Maybe I'm missing something, but all of the turing-complete approaches to computation are equivalent, and there are accordingly transformations between them. What makes this transformation more trivial than the others, that it renders the distinction between logic and functional programming less meaningful than the distinction between functional and any other approach?