Slashdot Mirror
An Open Source License for Education?
Erno_Rubaiyat asks: "The educational foundation that I work for is preparing to release some software. We are committed to releasing it with an Open Source license, but are unsure what license to use. I was curious if anyone had considered or compared the Sakai license to the Creative Commons licenses? I like the Sakai license because it is so simple, but does it leave any obvious areas open for abuse? As a side note: we are including several packages that are licensed under the LGPL and the GPL. Are there any pitfalls that we should be aware of while licensing our 'original' work with a different license than these components?"
It really will save you a lot of headache. You won't be faced with the problem of some esoteric license that hasn't found OSI approval. It will also guarantee that you are A-OK with anything that is under the GPL (which will be a lot).
"Everybody uses it" isn't enough reason to choose the GPL, but it is hard to suggest anything better if you don't know your requirements.
It seems that Sakai license is a sort of warmed-over BSD or MIT style license, except that the whole 3d paragraph is ungrammatical. It obviously hasn't even been proofread. If you want that, just go BSD.
The GPL and BSD licenses are the most well understood licenses out there, and hence when someone else is considering using your code, they'll know right away what to expect.
Other less well-known licenses like Sakai should be left to organizations that have a legal department to make those decisions for them. The last thing you probably want is someone who might join in your software community and contribute useful changes back to you to be scared off by an unfamiliar license.
o/~ Join us now and share the software
I have a similar question that has been in the back of my head for a long time. Most F/OSS licenses only consider derived works to be improvements to your program or new programs which are released with some of your IP. I wonder if there was some license that was more restrictive, that also considered the output of modified programs as publishing a derived work. If I open source great simulation software, other researchers would be allowed to make substantial changes, generate output, and publish papers without contributing the code changes to the community. Academic integrity does limit how frequently this occurs. And many are happy to have your springboard that they do collaborate with you. Also, the journals often at least require them to document their procedure so that you can eventually figure out what they did & change it yourself. But is there any legally-binding & accepted license to protect you from when the system doesn't work?
What GPL licensed software are you using in your application? Depending on what GPL stuff you are using you might have to release your software under the GPL also.
Richard Stallman. Fear the Gnu!
stored on computers from birth to the grave
Creative commons is typcially about documentation rather than source code.
Options are with great simplification:
GPL like: You cannot use this software except with other open source software.
LGPL like: You can use my software with anything but ANY modifications to my software must be published. Great for libraries.
BSD like: You may use this as you like, we may want attribution, we recommend that you release source code.
Public domain: Use it as you like.
What do you want to acheive is the question you should be answering.
IANAL, but I believe that copyright law prohibits you from claiming copyright on works produced by your work as part of its normal functioning, since they are not considered 'derivative works'.
You're correct, of course. I shouldn't have used the term "derivative works" (though some licenses do spell out what they mean by that).
You can license what people are allowed to do with your product. I see no obvious barriers to licensing them to make modifications, so long as those modifications are released whenever they use the program to do ______. Traditionally, this is "release software." But why can't it be "publish papers or present presentations based on the software?" I've definitely seen much more restrictive licenses--ones that bar you from giving negative reviews, etc.
Second, using the GPL assigns copyright of the source code to the FSF. Here is an excerpt from the GPLv2:
That's why the FSF ends up being the ones defending violations in court. You give your software to them, and they use their power of copyright to defend it. This is a bad idea if you don't explicitly own the copyright to all of the source you're GPLing. If four or five people helped write the software, make sure they're OK with the FSF owning it. This is why Linux doesn't use the GPL outright. Here's the first two paragraphs from the COPYING file that comes with the Linux source:
Note how the copyright owner is explicitly named. Also note that Linux falls only under version 2 of the GPL. Many software projects state that they use the GPLv2 or any later version (there is no later version at the moment). There's nothing preventing the FSF from stating that the GPLv3 requires that only GPL software run on a computer where any GPL software runs, or that GPL software can only be used with the HURD. The HURD doesn't have to conquer Linux; it will start out with a full toolchain and many programs to go with it. Under the GPLv3, the FSF could deny the use of those programs under Linux. Suddently the big players in the OS market are Microsoft, the BSDs, and the HURD.
The best thing to do is to roll your own license, using either the BSD or GPL as a basis (depending on which you prefer).
And by ``open source'' you mean ``GPL''. The GPL specifies that if you make a derivative work, it has to be released under the GPL. You don't get to modify the license of the derived work. I don't know all of the arguments for what exactly a derived work is.
Public domain: Use it as you like.
Remember that this gives you no rights. If people take your product, change the name, and charge $10 for it on eBay, tough.
What do you want to acheive is the question you should be answering.
Truer advice was never given.Dig a little deeper on their website and you can see they have a working/discussion group on an educational license.
Were that I say, pancakes?
Talk to a lawyer. You're with an educational institution, so you can probably get someone pro bono.
so you can probably get [an attorney] pro bono.
Be careful. The term "pro bono" can refer to "pro bono publico," the community service for which an attorney does not charge, but it could also refer to "pro Sonny Bono", referring to a stance that copyright law should grant the author as much power as possible over users of a work for as long as possible. The latter stance resulted in the No Electronic Theft Act, the Sonny Bono Copyright Term Extension Act, the Digital Millennium Copyright Act, various efforts to require every media device sold in the USA to implement Treacherous Computing practices (which failed for computers but passed for TVs), etc. Lawyers working "pro Sonny Bono" tend not to agree with the free software movement.
If your project is publicly funded, and there is no conflict with the GPLed software you are including in the package, then you should use a BSD style license. The public payed for it, and it should be theirs (public domain) but you should still be getting the credit for it. The BSD license provides exactly that.
If it isn't publicly funded, I think the GPL would be a better choice since you can both make it publuicly available and protect the investment from people trying to hijack it.
I used to release all my stuff under the BSD license, but I've switched to MIT's. It's clearer, more succinct, and explicitly spells out that there is no implied warranty that the software is noninfringing. If you get sued by SCO for using my code, I'm not liable.
- Notice of any changes or modifications to the Original Work, including the date the changes were made.
- Any modifications of the Original Work must be distributed in such a manner as to avoid any confusion with the Original Work of the copyright holders.
- Title to copyright in the Original Work and any associated documentation will at all times remain with the copyright holders.
The last one might be a "duh", but the first two are probably unreasonable in an "open source" project.The GPL specifies that if you make a derivative work, it has to be released under the GPL.
Not true. The GPL specifies that if you DISTRIBUTE the original OR a derivatice work, that it has to be according to the terms of the GPL. Distributed derivative works must be under the terms of the GPL. If you are not entitled to distribute the derivative under the GPL (other peoples copyright code, patents, etc) then you are not allowed to distribute the derivative work at all as nothing else permits you to what copyright is denying you.
The main arguments have been over what constitutes a distribution and what constitutes a derivative work.
Sam
blog.sam.liddicott.com
B S D
got that?
wouldn't it be cool to find out some of your educational institutes code will be incorporated in longhorn?
nah, serious though... BSD is the most friendly license to whomever wants to 'use' that code, and that's what education is all about now isn't it?
"You can license what people are allowed to do with your product."
This is far from legally clear. Copyright law only restricts certain things. The main one it restricts is copying and distributing copies. The reason that open source licences work is that in order to redistribute you need the authors permission. A copyright licence (such as (L)GPL or BSD) is a limited permission to do something which copyright law would otherwise prohibit.
On the other hand, you don't need the author's permission to run software and you probably don't need it to modify the software either. (Modifying on a computer necessarily involves copying but this form of copying may well not be regulated by copyright).
The non-free licences which purport to restrict lots of other things are End User Licence Agreements. Whether EULAs are ever valid is unclear. If they are valid it is because they form part of the contract of sale of the software: an EULA rests on contract law. In that sense it is not a licence at all.
In summary, under copyright law, you need a licence to release software where the copyright is owned by someone else but you don't need a licence to publish papers or give talks. Hence copyright licences can restrict releasing software but they can't directly restrict writing papers or giving talks.
Most licenses are already based on the assumption that you can restrict not only distribution, but also modification of the program (See 2, 4, and 5 in the GPL). I fail to see why additional restrictions couldn't be placed in those parts of the license.
Failing that, a separate well-thought-out EULA could be beneficial. Unfortunately, it would also seem to be incompatible with a lot of F/OSS licenses: The GPL would see a EULA or NDA as additional restrictions on use. So companies are effectively prohibited from making changes to code and releasing it "in house." This is good. My point was that, in academia especially, changes ARE often made by one person in-house & aren't always distributed. This can be bad.
I don't know if this applies or not, but for musical compositions there's both duplication and performance rights. That sounds like a similar distinction to what we're talking about here.
http://alternatives.rzero.com/
Actually, this is not strictly true, as software has 'performance rights' that govern whether you are allowed to 'perform' the program to an audience. What we are talking about here is more of a stretched definition of 'derivative works'.
So companies are effectively prohibited from making changes to code and releasing it "in house."
D istribution)
Actually, the GPL allows this, (see the faq question http://www.gnu.org/licenses/gpl-faq.html#Internal
The biggest problem with EULAs as they are generally implemented is the fact that they cannot be legally binding since the user doesn't actually sign anything either on paper or in the electronic signature sense. Also, the user cannot read them before opening the shrinkwrap, which, if I remember correctly, invalidates the agreement.
Disclaimer: IANAL
Ah--thanks very much for the correction. I had followed a long discussion on the Debian list about this issue quite a while ago & people seemed to be under the impression that anyone who used your inhouse code could release it to the outside world under the GPL at any time.
I agree that the non-signature is a common concern. In fact, that point is explicitly addressed by the GPL.
I also agree that not being able to read a license before subscribing to it would be a major concern. However, I wouldn't imagine this is a deal-breaker, as long as the license could be obtained somehow. In any case, that concern wouldn't apply to the electronic software distribution commonly used by GPL-like software: the license is included whenever the software was distributed.
The biggest problem with EULAs as they are generally implemented is the fact that they cannot be legally binding since the user doesn't actually sign anything either on paper or in the electronic signature sense. Also, the user cannot read them before opening the shrinkwrap, which, if I remember correctly, invalidates the agreement.
That makes perfect sense but unfortunatley court cases havn't been going that way lately. The reasoning seems to be that since shrinkwrap contracts are the industry norm then they are therefore enforcable. That's one reason I cringe whenever I point out a particularly unreasonable clause in one of these and the other person says "so what, they would never try to enforce that one anyway".
I want to further restrict the changes that can be made without needing an open release of the changed software. Nearly every F/OSS license considers the criteria to be the release of any software.
That would be against any sense of freedom My feeble mind can imagine. Practicaly it would be impossible to enforce without an "ET phone home" function which would move your software into the relm of spyware. The only way around that would be a gentlemen's agreement based on an honor system, which would be un-enforceable. The reason FOSS consider release or distribution of a copy as the criteria is because they delgate the copyright owner's right to distribute to the licensee. When you want to control use, you need a patent, not a copyright.
A mandate to submit internal changes, to me would be an amalgamation of the worst aspects of FOSS and Proprietary software. With FOSS, it's my decision to release changes I've made, or to not distribute the changes I've made; normaly most of us release the change out of a sense of community spirit even when we don't distribute a derived work. By have a clause that would force me to release the change without an ouside distribution, I'd feel like I was in servitude to you rather than in colaboration with you.
My estimate is that this would be in violation of the GPL as it places additional restrictions on the work, and if your work contained GPL'd code, you'd be infringing on others copyrights. If your work didn't contain GPL'd code you would OK legaly, but GPL coder's would find your license abhorent.
Apocalypse Cancelled, Sorry, No Ticket Refunds
Not even the Much viliafied US Government cant take my property without due process. Linus doesn't own Linux, well actualy he owns the trademark Linux, but not the thingy it represents, he only owns the code He wrote that compiles into the thingy. there are many other people who own the code they wrote, a lot of people own parts, but no one person owns the whole. The GPL was done that way on purpose, attacking GPL'd software is like punching water, you can swing all day with no effect, the whole just keeps filling in.
It works that way because ownership is extremely distributed; there is no place to attack. Hypotheticaly; if SCO beets IBM, the code just gets rolled back to the pre-infringement point, and were back where we are now in 6 months. Hell if we know where the supposed pre-infringement point was, the patches would have been written long ago just in case!
Apocalypse Cancelled, Sorry, No Ticket Refunds
collage. To create a collage requires the permission of the copyright holders of the works used in that collage. Even if you change the medium, such as by including long stanzas from plays in a painting. What meaning does "derived work" have for software? Can I print the source code on a T-Shirt? Can I read it out loud at a concert?
The binaries are commonly believed to be under copyright. Yet a machine produced those from my source code. Why wouldn't the plots and other machine produced outputs also be under copyright?Well you know what they say about the road to Hell! How am I supposed to sell my peers in research on F/OSS when they skeptically ask "What if some other research group takes your code, makes changes, and is then able to print more papers then us, get more funding than us, etc.?"
Sure--I believe in collaboration & F/OSS. I could be tricky & start with a GPLed base & say that I'm stuck with it. That is: yes, the idealistic values that are argued in that short piece are good. No, they don't always trump pragmatic concerns!I agree with this & didn't even start under the pretense that my code would be GPL-compatible or OSI-approved. I know I can't make everyone happy. And I agree that GPLers would find the license abhorent. I don't care--I care more about the views of those actually in my field of research. Most don't worry about licensing. Few write GPLed code. None would care. Everyone would love to be able to start with a shared base that F/OSS provides, but people do care that the playing ground remains level!
If I hade code I told you couldn't be released under an OSI-approved license, would you say "Screw it--go proprietary. Binaries Only. Sell it. Don't share it."
I know I won't be able to release it as Free, but I would think that it would be best to release it with as much rights as possible! People did give UW a lot of flack over Pine's restrictive license. Pine is not Free software. Does that mean that Pine is, as you say, an amalgamation of the worst aspects of FOSS and Proprietary software? Are you going to email them, asking them to stop releasing the source since that is apparently bad?
The binaries are commonly believed to be under copyright. Yet a machine produced those from my source code. Why wouldn't the plots and other machine produced outputs also be under copyright?
the difference is that the binary is a derivitive work of the source code, while the output of your program is just the output of your program which is creating a derivitive work from it's input data.
Snowden and Manning are heroes.
This is not quite correct. Signature is not a requirement for contract (except in some restricted unrelated areas such as land transactions). Most of the contracts you enter are not signed - think about what happens in the supermarket, for example.
The reason that most EULAs are probably void is want of consideration. Note here that consideration is a technical legal term which means that both parties must provide something in order to make a contract. It has nothing to do with thinking about the contract (ie "consideration" in it's normal sense).
The argument goes like this: you by the software in a shop. The vendor makes no effort to provide you with the EULA nor does he obtain your agreement with it. There is a perfectly valid sales contract - you get the software, he gets the money.
You open the box and it contains an EULA. The EULA is, at this point, an offer which you have not accepted. Moreover, most EULAs do not give you any rights which you didn't already have under copyright law as the owner of the software you bought. So, either you don't accept the offer and you can use the software, or you do accept it . In order to legally accept it you have to communicate your acceptance to the manufacturor - which there is never provision for doing. Assume, though, that you do communicate acceptance. The contract is still void because you didn't get anything out of it.
Some manufacturors will claim that the EULA forms part of the conditions of sale, which gets around the consideration problem. However this is when the fact that you didn't know the EULA at time of purchase comes into it. The contract, in this case, is void for want of agreement.
Note that all of this assumes a "conventional" sale in a shop. EULAs on downloads where the EULA is presented before download are on much safer legal ground. Even then, though, they only bind the downloader and not the user (although in a corporate setting the downloader and the user are probably for legal purposes both the same: the company). Further, the red hand rule still applies. This means that in a standard form contract, any term that usual participants in the market would not expect to find must be drawn to the particular attention of the accepting party. Note that the relevant standard here would be people who usually download this sort of software. This, then, is a further ground on which "first born child" clauses in EULAs are invalid.
Standard disclaimer: I am not a lawyer but I do have a law degree.
"What if some other research group takes your code, makes changes, and is then able to print more papers then us, get more funding than us, etc.?"
The trollish thing to say would be they are smarter, or more politicaly astute to peer-reveiw ect. But the reality is if your concern is protecting your IP, then trying to force fit a project into a F/OSS is probably going to be a lose-lose proposition, it'll make you look bad, it'll hurt your project and give ammo to people who are knee-jerk against F/OSS.
Maybe a compromise would be to develope it in modules, the framework could easily be in F/OSS with unrestricted developement which run inner modules for each simulation, that could be distributed or not under any license or agreement you like. The LGPL might be a good fit for this pardigm, basicaly allows porprietary to link to F/OSS without bringing the proprietartion under the F/OSS umbrella.
Apocalypse Cancelled, Sorry, No Ticket Refunds