As I have said elsewhere, the BSDL is pretty powerful when you have a good community. One could fight back and win. It wouldn't be fair to the GPL folks;-) We might want to do this for their own protection;-)
Seriously, if you can get good commercial players, they could be leveraged to do clean-room rewriting of the changes with a legal review to make sure.
1) Restricting freedom seems to be OK in the advancement of The Cause. For example, allowing invariant sections via the FDL in order to force people to republish the GNU Manifesto.
2) Wielding a club without first taking a look to see whether it is necessary or beneficial: Tivoization clauses, for example. I think this actually a bad thing in terms of giving people more incentive to rethink effective DRM schemes, and the like. Furthermore, I believe that competition will always promote freedom in the end.
3) Pushing the AGPL which seems to be an enemy of free use of software (I dislike Larry Rosen's Open Sotware license as well for the same reason).
Now that I understand how to deal with BSD safeguards better, I expect to be releasing more code under similar licenses. (Probably the MIT License.)
IANAL, but I understand the theory. Basically, the author has granted the public a license to use the software in a certain way. THis can't be superceded by throwing on a license.
Now, it gets more complicated because more than the code may be copyrighted.
Ok, if I create a literary work, let us say it is a short story called "The City Beneath Puget Sound."
Suppose I release it under the BSDL.
You can publish it, under the terms of that license. There is even a question as to whether you can issue an *additional* license which grants a subset of the same public rights as the BSDL (but in reality this is moot since adding this additional license (i.e. sublicense) doesnt do anything to what a recipient can do with the code). In this case, the GPL would be such a subset. You can slap it on, but that doesn't change what anyone can do with the code because you get both licenses and have to com[ply only with the BSDL requirements.
Now, suppose you take this short story, and make a short movie out of it, and release the movie under the GPL. This is also allowed.
Suppose, however, that somebody sees the movie, never reads the story, and writes a sequel. Suppose that this person does not actually use any of the new plot elements you added in the movie. Suppose this author publishes the sequel and the related movie with all rights reserved. Can you sue that person for GPL violations? IMHO (IANAL), no, because you didn't add restrictions on the original elements when you created the movie. You only added restrictions on the original elements you created (new plot lines, new characters, the cinematography, etc).
The BSDL requires that the license remain intact. If the author gave unambiguous permission to *remove* one of the licenses, that would be OK, but it would require *all* owners of copyrights' permissions to do so.
Similarly as regards code: 1) I don't think that correcting bugs by correcting typos would make one a copyright holder. No expressive elements are added.
2) I do think that changing every comparison to put the constant on the left side might make one a copyright holder because this *is* an expressive (and semantic) change, not just a functional one.
3) I do not think that dynamic linking creates derivative works by itself, even if the funcitons in the library are used (so long as they don't have artistic/literary effect, such as graphical design elements, story lines in games, etc).
4) I do think that static linking creates a derivative work when the static library is *altered* to match the work.
I expect to be following suit. My major concerns with the GPL3 are:
1) The Tivoization provisions. As long as the code is available, one should use economic rather than license terms as much as possible. 2) The length of the license. The GPL3 is 3 times longer than the GPL2. 3) Some phrases are *really* hard to understand what they mean in the context of the rest of the license.
For example, no sublicensing, but distributors can remove license exceptions. Say what? What contracts are formed and who are the parties to them? On what basis can a third party (distributor, not copyright owner) interfere with the rights a developer grants on their code *other* than sublicensing?
Now, given that I have heard a number of different answers about what this permission removal bit means, I would be very concerned about using it on my own code.
Also, now that I have spent time around BSDL projects, I am far more comfortable using them for my own code in some circumstances.
I have been around GPL an BSDL projects for a long time. I dont care about license wars but I will say this-- any community is capable of defending itself if it is strong. IANAL, and in cases like this it is probably a good idea to have legal advice.
In BSDL projects, you have no legal recourses, but you do have economic ones such as: 1) Create similar changes embodying the same ideas but implemented using different code. Clean-room the changes if necessary. If they don't want to give you the changes, you can drive up the cost of using your code and force them to actually fork or give back. 2) Recruit more talent. 3) Lower the barrier of entry to participate.
Theo should be looking at ways of bringing the improvements back. Open source projects can and Ibelieve should do clean-room re-implementations of GPL change-sets. The way this works is:
1) Person A does a diff of the two versions, reads them side-by-side, and documents the changes. 2) Person A sends the document which contains no code to the project email list. 3) Debate occurs over the best way to do things involving any number of people. 4) Person B Implements a similar idea but somewhat different and incompatible with the GPL version (simply due to the fact that the same code is likely altered, and that things are done a bit differently).
This has the effect of creating a comparable but non-compatible changeset in the code. The individual who made the GPL changes now cannot make further changes to the new version without either scrapping his changes or trying to port the differences between the versions (which is suddenly a lot harder and more labor intensive). This way, BSDL coders can punish those who do not want to give back economically.
While arguing about morality here wouldn't be great, nothing keeps BSDL coders from forcing others to give back or waste time/effort/money maintaining an increasingly complex changeset between versions.
In the BSDL, freedom is power because it is valuable. It is good to maximize the use of that freedom to ensure that people cannot easily compete with the original project.
The case you describe was based largely on De Forest.
In De Forest, you had a contract between De Forest and AT&T, which (among other things) allowed AT&T to produce goods for the US Government. This provided an implied patent sublicense for AT&T to allow the government to make use of the products they created. You also had another contract between AT&T and the US government during the war where AT&T agreed to waive injunctive relief over sublicense violations in exchange for monetary compensation later. Thus it is very difficult to see how one could address the related patent issues under anything *other* than breach of contract.
The Artistic License also provides certain obligations on modification. Thus when you change the files you are entering into a contract. The GPL is no different.
I have no idea why people think this makes the GPL void or DOA, however. Unlike the GP, I don't honestly understand the argument that just because the GPL is a contract it is somehow void. The GPL does seem to create contracts on certain kinds of distribution and on modification. (The GPLv3 probably creates a contract in more forms of redistribution than is clear in v2.) But the main issue is that this creates a contract itself and if this is breached, one is entitled to some sort of reasonable relief. And since the contract is now terminated, redistribution rights cease.
Although I suspect you are a troll, you do have a point in this particular post.
Before I begin, IANAL.....
If you read the GPL2 and 3, they both read like contracts. There are specific obligations which are asked in return for certain rights (for example, any derivative works must use the same license). If this sounds wrong, note that there are a lot of people who want to argue for specific performance in GPL violation cases (asking the court to make the other party comply with the GPL by releasing their own copyrighted code elements...). If the GPL did not have contractual elements, these arguments would be simply absurd.
However, I would suggest that the vast majority of the people who redistribute software as permitted by the GPL do so as if it were a bare license for redistribution of the original work verbatim including the license and everything else necessary to comply.
My own lay analysis of the GPL is: 1) Using the software, no contract is formed (no contract, in US, the Copyright Act allows for this without permission provided that one legitimately owns the copy of the software). 2) Redistributing verbatim source packages as released by the developer, no contract is formed (bare license). 3) Creating a derivative work or redistributing binary packages, a contract is formed.
I am considering choosing the BSDL for any future large projects on the idea that one cannot compete with Free (both senses). However, if someone started usng my code in GPL projects and not giving back, (if we wanted it back) I would see if anyone in the community was willing to do an analysis of those changes so we could implement them ourselves. This would probably have two impacts:
1) Force those using our code to either give back or fork, and 2) Driving up the costs of code maintenance for those who don't want to make that choice.
Note that the same basic approach goes to proprietary users as well. Analyze their features and functionality, re-implement, and drive up the costs of development for them if they don't give back.
Note, however, this does not prevent people from adding components in whatever licenses they want for things we don't want. These could be sold with EULAs, incorporated into GPL projects, or whatever.
Porting a wireless driver from OpenBSD to Windows is just like copying code;-)
Note however that nothing prevents the OpenBSD driver developer from reading the code, thinking about it, coming back, and ading his own versions of the improvements. Or safer yet, askign someone *else* to read the code, provide a specification of the algorythm, an then reimplementing it since the algorythm itself is not subject to copyright protection (IANAL, but read the basic analysis in Gates v. Bando as to what is subject to copyright protection-- although this is just a 10th Circuit appeals case, that part is pretty much common across the board at least in the US and probably in most Bern Convention signatories).
Now, this is *exactly what* BSDL developers should be doing. First this forces the GPL developers to either give back or totally fork (otherwise, they have to keep porting changesets between versions and determining which changes are no longer required, probably by hand). It is exactly in the spirit of well-run BSDL projects as well.
In general, I agree with your charaterization of the GPL2 and the BSDL. Furthermore I would add that well-run BSDL projects have their own economic mechanisms of ensuring contributions (i.e. you want the latest new code, you had better give back so you aren't stuch spending a lot of developer time porting your code between versions). In fast-paced development projects under BSDL (Apache, PostgreSQL), you either give back or you fork, or you get dragged down by unnecessary efforts.
At the same time, I have a pretty major concern about the GPL3. If you read section 7, this grants *distributors* (i.e. people who have no copyright claim to the software) the right to remove permissions which exist beyond those of the base GPL3 license. I expect this to actually make it harder to share code not only between GPL projects and those under other licenses, but also between projects governed under the GPL3 because anyone can drop a linking exception, an additional license, etc. However, it is not clear how this works legally. Is this an exception to the prohibition on sublicensing? Is it interfering with a contract to which one is merely a third party? What is the legal effect? Although I believe have answers which provide *me* a safe interpretation of the license, I do not believe that the license is clear enough to ensure that everyone will come to the same understanding of it.
First, there are a lot of people who have trouble separating hype from reality. The fact is that well-run BSDL projects promote software freedom to at least the same degree as well-run GPL projects. I personally think that people who won't give back to BSDL projects in the name of software freedom are hypocrits. And yes, there is a moral issue there.
However, there is a second issue to contend with. Well-run BSDL projects can create a pace of development which makes it very difficult to justify not giving back. When this pace of development reduces, then you have to worry about further restrictions etc both open source and proprietary. I think that it is also wrong for BSDL developers to complain about this too much because when it matters, it always means that there are issues keeping the pace of development high enough to thwart competition. Hence hiding behind morality in order to cover one's own failings isn't much better.
This issue is quite interesting however, because the GPL3 provides any individual who merely distributes the software (i.e. has no copyright claim to it whatsoever) to remove additional permissions from the copies he/she distributes. I wonder if these sorts of issues are going to be more common as software packages upgrade licenses to the GPL3 if for no other reason than differences in interpreting that license.
I am not going to get into Compiz/Beryl issues or anything like this. However, I think that there are a couple of issues here which need to be addressed.
First I am glad to see this post by Theo. I think it provides a great deal of help in discussing some of the thorny issues between BSD and GPL camps. It also provides some other perspective on some concerns I have been having with the GPL3.
The second thing I want to say is this: It is one thing to take BSD code and not give back. It is another thing to do this in the name of keeping the "evil companies" from doing the same. I am sure this sort of thing does happen from time to time. It is one thing to say "I don't want people to take my code and make it proprietary without licensing from me first. It is something else to say that while doing the same thing to other people in a different sense.
This is an ethical rather than a legal issue. On the other hand, my experience with BSD projects is that this becomes a larger issue when pace of development is slow. If you have a fast pace of development with commercial player who do give back, then this becomes difficult. How likely are we to see Apache or PostgreSQL get gobbled up by GPL'd (or even proprietary) forks? I don't think it is likely.
In fact, if you look at PostgreSQL, I have seen at least six or seven proprietary spinoffs of PostgreSQL. Today, there are two "main" ones and they are niche (but high-end) markets. The others are dead or insignificant. Business-wise it is very hard to compete with a properly run BSDL project, and the BSDL can provide businesses an ability to sell that which the community doesn't want anyway (like funky Oracle-compatible NULL handling).
In the end, the *only* thing that matters is community. Building it is the *only* way forward. The GPL has some business advantages (and the BSDL has others).
Most of my software is released under the GPL2, but I am considering the BSDL more and more viable for multi-vendor large projects.
I would argue that static linking makes a derived work. Once linked, the library is no longer seperable from the binary. That is, some of the information that would be necessary to recreate the library from the combined work is gone. Further, un-needed functions in the library get tossed out. To the extent that the library still exists within the combined work, it is customized for the particular application. That is a good point. I would agree with the line of reasoning. (again IANAL).
IANAL. Nor have I drunk the FSF Licensing FAQ kool aid;-).
Include copyrightable portions of its source code in your own source code (in C/C++, this usually covers including header files, which generally include copyrightable code); I disagree whether the code in header files is generally copyrightable. At any rate, however, if I take the header, run it through the C Preprocessor, extract the function declarations, and alphabetize them, that should not be subject to copyright under US law since all I have is a list of facts in alphabetical order.
include portions of its object code in your own binary (as when you link statically to a library, or link dynamically to a library on a system such as Windows where this involves linking statically to an "import library"); or How does this differ from a composite work such as a compiled work or collected work in copyright law? It seems that those are more fitting discriptions for object code containing a statically linked library.
Link dynamically to a shared object in such a way that this creates a fixed dependency on it that makes it effectively equivalent to including the GPL'd object code in your binary itself. Why would this pertain? This would suggest that I create a library with the same API, that certain works suddenly cease to be derivative of the other library. This conclusion seems to be interesting in the sense that it creates a way of attacking peoples' copyrights. Personally I doubt this interpretation because it would mean a GPL violation could be cured by releasing a library that only sort-of worked and offered the same API (i.e. could be extremely buggy).
Under your list of exclusions:
Include non-copyrightable portions of its source code (such as standard OS headers whose contents are dictated by standard interfaces); How are OS headers not copyrighted but library headers subject to copyright? Can you please provide an explenation for this distinction?
Include portions of its object code in your own binary, when this object code is considered part of the standard operating environment of the platform your code is compiled on (IIRC this is why Linux programs do not have to be GPL); or Why is this different than libraries? My understanding is that interoperation is protected under copyright law and this is why linking doesn't necessarily equal derivation.
Link dynamically to a shared object in such a way that it can easily be swapped for another, non-GPL shared object, and such other shared object actually exists and is feasible for users to acquire. This seems to me to be very problematic from a copyright perspective because copyrights cover exclusive rights. It doesn't mean "exclusive until someone else writes something similar." It means "exclusive for the term of the copyright." Thus I don't think you could really have a copyright analysis which was predicated on availability of functional replacements, since functionality isn't protected anyway.
Again, IANAL, but I think you are smoking some of RMS's stash;-)
I have been arguing this on another thread. IANAL, however.
I don't think that linking creates a derivative work (at least in terms of dynamic linking or static linking using a linker). Certainly Gates v. Bando (yes, a software case; no, not Billy) would suggest that some sort of copying of abstract expressive elements (not necessary code) would qualify. Now, doing "static linking" by compiling two source files into one object file might qualify but that might also depend on the circumstance.
Of course the Gates test is not universally applied in the US and might be different internationally. However in the US, only original, expressive elements are protected. Aspects which are purely functional are not. Thus an algorythm is not protected even though its implementation might be. Furthermore, a list of facts (as in a header file) might not be protected, though the selection and ordering might be. What is interesting in Gates however is that it presupposes that one must show some copying of code which is protectable into the new application.
My argument is based on the following elements: 1) Substitutability. Can a library be substituted with another one (hypothetically or actually) without affecting the program? The hypothetical element is required to prevent questions like "if I also create a library with the same API or a portion of it does this interfere with another works' copyrights?" The substitutability portion is also required because Excel doesn't suddenly become derivative of my ODBC driver just because I write another one.
2) Filtering out non-expressive elements. Maps of entry points of a compiled executable are not expressive because they are merely interfaces. Or at least they are no more expressive then XML DtD"s for web services and the like.
3) How tightly coupled is the library? Static linking using a linker would seem to create a collected work rather than a derivative work (i.e. a larger work containing two inependent pieces, rather than a work derived from both). Using the GCC to merge source files prior to compiling might or might not.
4) Can preparation for linking create a derivative work by mere inclusion of a header file? Yes. However nothing prevents the author from creating a header file derived only from the list of facts.
5) Can things you do in the program create derivative works? Yes. Copyright extends beyond code to things like storylines of games, graphical design elements, and the like. If the library changes these, it might be a derivative work...
6) Can number 5 be done without linking? Yes. I have no reason to think that Corba (like GTK uses) would render something safe just because it is more loosely tied.
Assuming I am right in US law (and IANAL), then linking would be relatively irrelevant itself. What would matter would be what happens both before and after linking. Hence it could be indicative but neither sufficient nor necessary. THis means however that since derivation is usually shown circumstantially it might be seen as some sort of evidence.
Perhaps this is what the FSF is saying in the linking question. But again, IANAL.
The problem with BSD is that I can take a fork of a project today, throw a whack of talented resources at it and make a better product. Launch that into the wild and have everyone take my (non-BSD'ed) fork as the dominant project. Give it some time, and everyone has forgotten about FreeWhateverItWas and is now using PinkPanther_v5. Everyone is drinking from the PP-koolaid...then I start re$tricting acce$$. And you are still competing with Free (both kinds). If you are extremely lucky the original development will be slow enough to actually let you be successful at this. In which case the project is more or less dead anyway (regardless of license).
Now, one of the BSDL projects I support is PostgreSQL. As your post suggests, there are a number of companies that either currently or in the past have offered proprietary versions of the software. These include Command Prompt, EnterpriseDB, Fujitsu, Green Plum, Pervasive, and SRA.
Of these, Command Prompt still has *one* proprietary add-on (but they no longer sell proprietary versions of the software), Fujitsu has dropped off the radar screen, Pervasive has given up competing with Free, and so has SRA. EnterpriseDB and Green Plum market niche products but they are hardly mainstream. In short, in a few years, pretty every proprietary version which even had a hope of being mainstream died.
In case you are wondering, EnterpriseDB offers a version of PostgreSQL with some extra Oracle compatibility. Nobody in the PostgreSQL community (myself included) wants this in our software. So we are happy to let them sell that. After all, they contribute a lot of code back to the main version. After all, they want to be competing against Oracle ($$$), not PostgreSQL (Free).
Similarly Green Plum makes a version of PostgreSQL aimed at buisness intelligence markets. They release a single-node version open source, and a version capable of parallelism under a proprietary license. The parallelism is what you pay for in BI space, so that is what they keep to themselves. Again, they want to be competing with Teradata, Oracle, and DB2 ($$$), not PostgreSQL (Free).
Pervasive tried to compete with Free and discovered it didn't work...
Where the BSDL has some drawbacks though is that it discourages businesses from being first movers in the development. The basic problem is this: You license your software, and your competitor can take that as you released it to get ahead. The GPL solves this problem, but in my view, but another option might be to approach some competitors and ask for contracts stating that for 1-2 years, they will contribute all the code thee write for it back. By then, you should have a larger community.
See my comments above in asking the Nazghul for help implementing Tolkein Ring support.
I think the biggest thing keeping Linux from being truly competitive with Microsoft is this GPL. Its draconian requirements virtually guarentee that no business will ever be able to use it. Note that the Nazghul have signed off on Linux from the standpoint of their parent company's global consulting services, which now amount to over half the revenue of that Fortune 100 company. Perhaps the Nazghul like dragons?
In short, I believe that you should ask your lawyer for a good definition of derivative works, or read Gates v. Bando (no relation to Billy) and look at these things yourself. While IANAL, I do divine the future by watching the flights of the Nazghul on their draconian steeds.
Although we met several technical challenges along the way (specifically, Linux's lack of Token Ring support and the fact that we were unable to defrag its ext2 file system).... I suppose it depends how you frag the filesystem to start with. Windows will only defrag a filesystem it has messed up. Since Linux doesn't mess up the filesystem for you, fragging it might require a plasma gun or the like and then, I am afraid the software isn't going to be much help.
As for Tolkein Ring support, ask the Nazghul;* they might, for the right price, let you port the drivers from AIX.
* Nazghul in this context refers to IBM's lawyers.
I think the difference is how freedom is best preserved. In a BSDL community, you encourage everyone to contribute because it benefits them and everyone else by doing so, and it hurts them not to contribute. This works becasue if one doesn't contribute back then it becomes prohibitive to upgrade to the latest version fairly quickly, but if one does contribute then everyone else can supply patches and improvements. Furtermore, if two people create a different fix to the same problem and only one contributes the patch, the person who didn't gets screwed, especially if their version is better since now they have to maintain the difference or lose functionality.
BSD uses economics to protect freedom. GPL tries to use the force of law.
Generally I prefer the BSD approach but tend to feel safer with the GPL:-)
How do you ensure that the data is passed to the hypervisor without modification? Same way you ensure that your credit card number isn't altered when you make a purchase from Thinkgeek.
Ok, suppose the video access firmware has the following three interfaces:
The transaction would be: get_public_key Send that public key to the vendor. Get back a content key (plus other data, encrypted with the public key). Since this is tied to the box (due to the assymetric encryption), we can store it if necessary for future use. store_content_key stores that on the other side of the hypervisor. accept_stream then Allows the encrypted stream to be sent to the hypervisor and on to the video card (bypassing the OS on that last stage).
Note that this suggests that we don't care if the stream is tampered with or not. The only attack that would be meaningful would be a crypto attack and that can be done just as easily by a system not connected to the drm. In practice, tampering with the input media stream would likely render it unreadable.
I am not advocating DRM. I am just saying that it is quite possible in a world where the kernel is Open Source and that hypervisors make it easier because you can do in software what you might otherwise have to do in hardware.
After reading the whitepaper, I don;t think the summary was quite accurate.
However, just a thought....
Suppose through technical means, I tie vendor invoices to the entire firmware image. This means, the hardware, software, etc. only function with the entire firmware update.
This does not prevent GPLv3 software from being installed and running, but the box may not do anything interesting without the other components. Hence you can turn your Tivo into a SAN node, store SDTV shows, etc. but nowhere does it say the HDTV decryption software has to be there after the update. I could then use copyright over the aggregated work to prevent you from copying out those componenents. I could even encrypt the firmware image so that the box must decrypt it. None of this matters because the code you install and modify will still work as it does in a vacuum (without all the rest of the software).
Now, what does a hypervisor add?
Simple. It adds a layer of separation between the untrusted software and the trusted software so that the GPL'd code can be added/replaced without affecting the rest of the device.They could communicate through some sort of shared resource or through some virtual device offered by the hypervisor. Thus content providers can offer total DRM and vendors can still use GPL software.
I am not advocating DRM. I think it is a fundamentally flawed idea and will be outmoded by new business models. However, anyone who thinks that open source magically gets rid of the issue is mistaken. THe source code and access to a router on the internet does not get you the contents of an SSL-encrypted transaction.
This sort of tivoization provides solid opportunities for DRM and GPL code to co-exist. Basically, the software need not be trusted with anything sensitive, such as unencrypted video. It is solid in the same way that SSL is solid.
A hypervisor actually makes this a lot easier because it establishes a virtual machine underneat which different software could be running.
When we send our credit card numbers over the internet, we do not trust that information to any router along the way. Similarly, a robust DRM solution would not want to trust the software itself with any unencrypted media content. Enter the hypervisor.
In such a system, each machine could have a public/private key pair which could be used to exchange DRK key information using established techniques such as we use for SSH. The OS would not be trusted with the key, nor would any software above the hypervisor. In short the main OS and media player would be unable to do anything more than handle encrypted streams of data. All decryption/DRM enforcement would take place below the hypervisor, and the operating system would not have any access to anything that is sensitive.
Another option would be a hypervisor which would separate GPL'd portions from non-GPL'd portions running some other OS (or possibly simply other kernels). A base kernel could route requests between them. THus the GPL'd portion would exist in a sandbox, unable to do anything interesting.
Slashdot Mirror
Yeah, well....
;-) We might want to do this for their own protection ;-)
As I have said elsewhere, the BSDL is pretty powerful when you have a good community. One could fight back and win. It wouldn't be fair to the GPL folks
Seriously, if you can get good commercial players, they could be leveraged to do clean-room rewriting of the changes with a legal review to make sure.
I guess the issue from my end comes down to:
1) Restricting freedom seems to be OK in the advancement of The Cause. For example, allowing invariant sections via the FDL in order to force people to republish the GNU Manifesto.
2) Wielding a club without first taking a look to see whether it is necessary or beneficial: Tivoization clauses, for example. I think this actually a bad thing in terms of giving people more incentive to rethink effective DRM schemes, and the like. Furthermore, I believe that competition will always promote freedom in the end.
3) Pushing the AGPL which seems to be an enemy of free use of software (I dislike Larry Rosen's Open Sotware license as well for the same reason).
Now that I understand how to deal with BSD safeguards better, I expect to be releasing more code under similar licenses. (Probably the MIT License.)
IANAL, but I understand the theory. Basically, the author has granted the public a license to use the software in a certain way. THis can't be superceded by throwing on a license.
Now, it gets more complicated because more than the code may be copyrighted.
Ok, if I create a literary work, let us say it is a short story called "The City Beneath Puget Sound."
Suppose I release it under the BSDL.
You can publish it, under the terms of that license. There is even a question as to whether you can issue an *additional* license which grants a subset of the same public rights as the BSDL (but in reality this is moot since adding this additional license (i.e. sublicense) doesnt do anything to what a recipient can do with the code). In this case, the GPL would be such a subset. You can slap it on, but that doesn't change what anyone can do with the code because you get both licenses and have to com[ply only with the BSDL requirements.
Now, suppose you take this short story, and make a short movie out of it, and release the movie under the GPL. This is also allowed.
Suppose, however, that somebody sees the movie, never reads the story, and writes a sequel. Suppose that this person does not actually use any of the new plot elements you added in the movie. Suppose this author publishes the sequel and the related movie with all rights reserved. Can you sue that person for GPL violations? IMHO (IANAL), no, because you didn't add restrictions on the original elements when you created the movie. You only added restrictions on the original elements you created (new plot lines, new characters, the cinematography, etc).
The BSDL requires that the license remain intact. If the author gave unambiguous permission to *remove* one of the licenses, that would be OK, but it would require *all* owners of copyrights' permissions to do so.
Similarly as regards code:
1) I don't think that correcting bugs by correcting typos would make one a copyright holder. No expressive elements are added.
2) I do think that changing every comparison to put the constant on the left side might make one a copyright holder because this *is* an expressive (and semantic) change, not just a functional one.
3) I do not think that dynamic linking creates derivative works by itself, even if the funcitons in the library are used (so long as they don't have artistic/literary effect, such as graphical design elements, story lines in games, etc).
4) I do think that static linking creates a derivative work when the static library is *altered* to match the work.
Reread the GP again.
He was talking about using code, not software.
I expect to be following suit. My major concerns with the GPL3 are:
1) The Tivoization provisions. As long as the code is available, one should use economic rather than license terms as much as possible.
2) The length of the license. The GPL3 is 3 times longer than the GPL2.
3) Some phrases are *really* hard to understand what they mean in the context of the rest of the license.
For example, no sublicensing, but distributors can remove license exceptions. Say what? What contracts are formed and who are the parties to them? On what basis can a third party (distributor, not copyright owner) interfere with the rights a developer grants on their code *other* than sublicensing?
Now, given that I have heard a number of different answers about what this permission removal bit means, I would be very concerned about using it on my own code.
Also, now that I have spent time around BSDL projects, I am far more comfortable using them for my own code in some circumstances.
I have been around GPL an BSDL projects for a long time. I dont care about license wars but I will say this-- any community is capable of defending itself if it is strong. IANAL, and in cases like this it is probably a good idea to have legal advice.
In BSDL projects, you have no legal recourses, but you do have economic ones such as:
1) Create similar changes embodying the same ideas but implemented using different code. Clean-room the changes if necessary. If they don't want to give you the changes, you can drive up the cost of using your code and force them to actually fork or give back.
2) Recruit more talent.
3) Lower the barrier of entry to participate.
IANAL....
Theo should be looking at ways of bringing the improvements back. Open source projects can and Ibelieve should do clean-room re-implementations of GPL change-sets. The way this works is:
1) Person A does a diff of the two versions, reads them side-by-side, and documents the changes.
2) Person A sends the document which contains no code to the project email list.
3) Debate occurs over the best way to do things involving any number of people.
4) Person B Implements a similar idea but somewhat different and incompatible with the GPL version (simply due to the fact that the same code is likely altered, and that things are done a bit differently).
This has the effect of creating a comparable but non-compatible changeset in the code. The individual who made the GPL changes now cannot make further changes to the new version without either scrapping his changes or trying to port the differences between the versions (which is suddenly a lot harder and more labor intensive). This way, BSDL coders can punish those who do not want to give back economically.
While arguing about morality here wouldn't be great, nothing keeps BSDL coders from forcing others to give back or waste time/effort/money maintaining an increasingly complex changeset between versions.
In the BSDL, freedom is power because it is valuable. It is good to maximize the use of that freedom to ensure that people cannot easily compete with the original project.
Hmm... IANAL though.
The case you describe was based largely on De Forest.
In De Forest, you had a contract between De Forest and AT&T, which (among other things) allowed AT&T to produce goods for the US Government. This provided an implied patent sublicense for AT&T to allow the government to make use of the products they created. You also had another contract between AT&T and the US government during the war where AT&T agreed to waive injunctive relief over sublicense violations in exchange for monetary compensation later. Thus it is very difficult to see how one could address the related patent issues under anything *other* than breach of contract.
The Artistic License also provides certain obligations on modification. Thus when you change the files you are entering into a contract. The GPL is no different.
I have no idea why people think this makes the GPL void or DOA, however. Unlike the GP, I don't honestly understand the argument that just because the GPL is a contract it is somehow void. The GPL does seem to create contracts on certain kinds of distribution and on modification. (The GPLv3 probably creates a contract in more forms of redistribution than is clear in v2.) But the main issue is that this creates a contract itself and if this is breached, one is entitled to some sort of reasonable relief. And since the contract is now terminated, redistribution rights cease.
Sure, I have my issues with the GPL3, but....
Although I suspect you are a troll, you do have a point in this particular post.
Before I begin, IANAL.....
If you read the GPL2 and 3, they both read like contracts. There are specific obligations which are asked in return for certain rights (for example, any derivative works must use the same license). If this sounds wrong, note that there are a lot of people who want to argue for specific performance in GPL violation cases (asking the court to make the other party comply with the GPL by releasing their own copyrighted code elements...). If the GPL did not have contractual elements, these arguments would be simply absurd.
However, I would suggest that the vast majority of the people who redistribute software as permitted by the GPL do so as if it were a bare license for redistribution of the original work verbatim including the license and everything else necessary to comply.
My own lay analysis of the GPL is:
1) Using the software, no contract is formed (no contract, in US, the Copyright Act allows for this without permission provided that one legitimately owns the copy of the software).
2) Redistributing verbatim source packages as released by the developer, no contract is formed (bare license).
3) Creating a derivative work or redistributing binary packages, a contract is formed.
I am considering choosing the BSDL for any future large projects on the idea that one cannot compete with Free (both senses). However, if someone started usng my code in GPL projects and not giving back, (if we wanted it back) I would see if anyone in the community was willing to do an analysis of those changes so we could implement them ourselves. This would probably have two impacts:
1) Force those using our code to either give back or fork, and
2) Driving up the costs of code maintenance for those who don't want to make that choice.
Note that the same basic approach goes to proprietary users as well. Analyze their features and functionality, re-implement, and drive up the costs of development for them if they don't give back.
Note, however, this does not prevent people from adding components in whatever licenses they want for things we don't want. These could be sold with EULAs, incorporated into GPL projects, or whatever.
Porting a wireless driver from OpenBSD to Windows is just like copying code ;-)
Note however that nothing prevents the OpenBSD driver developer from reading the code, thinking about it, coming back, and ading his own versions of the improvements. Or safer yet, askign someone *else* to read the code, provide a specification of the algorythm, an then reimplementing it since the algorythm itself is not subject to copyright protection (IANAL, but read the basic analysis in Gates v. Bando as to what is subject to copyright protection-- although this is just a 10th Circuit appeals case, that part is pretty much common across the board at least in the US and probably in most Bern Convention signatories).
Now, this is *exactly what* BSDL developers should be doing. First this forces the GPL developers to either give back or totally fork (otherwise, they have to keep porting changesets between versions and determining which changes are no longer required, probably by hand). It is exactly in the spirit of well-run BSDL projects as well.
In general, I agree with your charaterization of the GPL2 and the BSDL. Furthermore I would add that well-run BSDL projects have their own economic mechanisms of ensuring contributions (i.e. you want the latest new code, you had better give back so you aren't stuch spending a lot of developer time porting your code between versions). In fast-paced development projects under BSDL (Apache, PostgreSQL), you either give back or you fork, or you get dragged down by unnecessary efforts.
At the same time, I have a pretty major concern about the GPL3. If you read section 7, this grants *distributors* (i.e. people who have no copyright claim to the software) the right to remove permissions which exist beyond those of the base GPL3 license. I expect this to actually make it harder to share code not only between GPL projects and those under other licenses, but also between projects governed under the GPL3 because anyone can drop a linking exception, an additional license, etc. However, it is not clear how this works legally. Is this an exception to the prohibition on sublicensing? Is it interfering with a contract to which one is merely a third party? What is the legal effect? Although I believe have answers which provide *me* a safe interpretation of the license, I do not believe that the license is clear enough to ensure that everyone will come to the same understanding of it.
First, there are a lot of people who have trouble separating hype from reality. The fact is that well-run BSDL projects promote software freedom to at least the same degree as well-run GPL projects. I personally think that people who won't give back to BSDL projects in the name of software freedom are hypocrits. And yes, there is a moral issue there.
However, there is a second issue to contend with. Well-run BSDL projects can create a pace of development which makes it very difficult to justify not giving back. When this pace of development reduces, then you have to worry about further restrictions etc both open source and proprietary. I think that it is also wrong for BSDL developers to complain about this too much because when it matters, it always means that there are issues keeping the pace of development high enough to thwart competition. Hence hiding behind morality in order to cover one's own failings isn't much better.
This issue is quite interesting however, because the GPL3 provides any individual who merely distributes the software (i.e. has no copyright claim to it whatsoever) to remove additional permissions from the copies he/she distributes. I wonder if these sorts of issues are going to be more common as software packages upgrade licenses to the GPL3 if for no other reason than differences in interpreting that license.
I am not going to get into Compiz/Beryl issues or anything like this. However, I think that there are a couple of issues here which need to be addressed.
First I am glad to see this post by Theo. I think it provides a great deal of help in discussing some of the thorny issues between BSD and GPL camps. It also provides some other perspective on some concerns I have been having with the GPL3.
The second thing I want to say is this: It is one thing to take BSD code and not give back. It is another thing to do this in the name of keeping the "evil companies" from doing the same. I am sure this sort of thing does happen from time to time. It is one thing to say "I don't want people to take my code and make it proprietary without licensing from me first. It is something else to say that while doing the same thing to other people in a different sense.
This is an ethical rather than a legal issue. On the other hand, my experience with BSD projects is that this becomes a larger issue when pace of development is slow. If you have a fast pace of development with commercial player who do give back, then this becomes difficult. How likely are we to see Apache or PostgreSQL get gobbled up by GPL'd (or even proprietary) forks? I don't think it is likely.
In fact, if you look at PostgreSQL, I have seen at least six or seven proprietary spinoffs of PostgreSQL. Today, there are two "main" ones and they are niche (but high-end) markets. The others are dead or insignificant. Business-wise it is very hard to compete with a properly run BSDL project, and the BSDL can provide businesses an ability to sell that which the community doesn't want anyway (like funky Oracle-compatible NULL handling).
In the end, the *only* thing that matters is community. Building it is the *only* way forward. The GPL has some business advantages (and the BSDL has others).
Most of my software is released under the GPL2, but I am considering the BSDL more and more viable for multi-vendor large projects.
Yes, the static linking bit does seem to create a derivative work because it *alters* the library in the process of linking it. Thanks :-)
Under your list of exclusions: Include non-copyrightable portions of its source code (such as standard OS headers whose contents are dictated by standard interfaces); How are OS headers not copyrighted but library headers subject to copyright? Can you please provide an explenation for this distinction? Include portions of its object code in your own binary, when this object code is considered part of the standard operating environment of the platform your code is compiled on (IIRC this is why Linux programs do not have to be GPL); or Why is this different than libraries? My understanding is that interoperation is protected under copyright law and this is why linking doesn't necessarily equal derivation. Link dynamically to a shared object in such a way that it can easily be swapped for another, non-GPL shared object, and such other shared object actually exists and is feasible for users to acquire. This seems to me to be very problematic from a copyright perspective because copyrights cover exclusive rights. It doesn't mean "exclusive until someone else writes something similar." It means "exclusive for the term of the copyright." Thus I don't think you could really have a copyright analysis which was predicated on availability of functional replacements, since functionality isn't protected anyway.
Again, IANAL, but I think you are smoking some of RMS's stash
I have been arguing this on another thread. IANAL, however.
I don't think that linking creates a derivative work (at least in terms of dynamic linking or static linking using a linker). Certainly Gates v. Bando (yes, a software case; no, not Billy) would suggest that some sort of copying of abstract expressive elements (not necessary code) would qualify. Now, doing "static linking" by compiling two source files into one object file might qualify but that might also depend on the circumstance.
Of course the Gates test is not universally applied in the US and might be different internationally. However in the US, only original, expressive elements are protected. Aspects which are purely functional are not. Thus an algorythm is not protected even though its implementation might be. Furthermore, a list of facts (as in a header file) might not be protected, though the selection and ordering might be. What is interesting in Gates however is that it presupposes that one must show some copying of code which is protectable into the new application.
My argument is based on the following elements:
1) Substitutability. Can a library be substituted with another one (hypothetically or actually) without affecting the program? The hypothetical element is required to prevent questions like "if I also create a library with the same API or a portion of it does this interfere with another works' copyrights?" The substitutability portion is also required because Excel doesn't suddenly become derivative of my ODBC driver just because I write another one.
2) Filtering out non-expressive elements. Maps of entry points of a compiled executable are not expressive because they are merely interfaces. Or at least they are no more expressive then XML DtD"s for web services and the like.
3) How tightly coupled is the library? Static linking using a linker would seem to create a collected work rather than a derivative work (i.e. a larger work containing two inependent pieces, rather than a work derived from both). Using the GCC to merge source files prior to compiling might or might not.
4) Can preparation for linking create a derivative work by mere inclusion of a header file? Yes. However nothing prevents the author from creating a header file derived only from the list of facts.
5) Can things you do in the program create derivative works? Yes. Copyright extends beyond code to things like storylines of games, graphical design elements, and the like. If the library changes these, it might be a derivative work...
6) Can number 5 be done without linking? Yes. I have no reason to think that Corba (like GTK uses) would render something safe just because it is more loosely tied.
Assuming I am right in US law (and IANAL), then linking would be relatively irrelevant itself. What would matter would be what happens both before and after linking. Hence it could be indicative but neither sufficient nor necessary. THis means however that since derivation is usually shown circumstantially it might be seen as some sort of evidence.
Perhaps this is what the FSF is saying in the linking question. But again, IANAL.
Now, one of the BSDL projects I support is PostgreSQL. As your post suggests, there are a number of companies that either currently or in the past have offered proprietary versions of the software. These include Command Prompt, EnterpriseDB, Fujitsu, Green Plum, Pervasive, and SRA.
Of these, Command Prompt still has *one* proprietary add-on (but they no longer sell proprietary versions of the software), Fujitsu has dropped off the radar screen, Pervasive has given up competing with Free, and so has SRA. EnterpriseDB and Green Plum market niche products but they are hardly mainstream. In short, in a few years, pretty every proprietary version which even had a hope of being mainstream died.
In case you are wondering, EnterpriseDB offers a version of PostgreSQL with some extra Oracle compatibility. Nobody in the PostgreSQL community (myself included) wants this in our software. So we are happy to let them sell that. After all, they contribute a lot of code back to the main version. After all, they want to be competing against Oracle ($$$), not PostgreSQL (Free).
Similarly Green Plum makes a version of PostgreSQL aimed at buisness intelligence markets. They release a single-node version open source, and a version capable of parallelism under a proprietary license. The parallelism is what you pay for in BI space, so that is what they keep to themselves. Again, they want to be competing with Teradata, Oracle, and DB2 ($$$), not PostgreSQL (Free).
Pervasive tried to compete with Free and discovered it didn't work...
Where the BSDL has some drawbacks though is that it discourages businesses from being first movers in the development. The basic problem is this: You license your software, and your competitor can take that as you released it to get ahead. The GPL solves this problem, but in my view, but another option might be to approach some competitors and ask for contracts stating that for 1-2 years, they will contribute all the code thee write for it back. By then, you should have a larger community.
with Microsoft is this GPL. Its draconian requirements virtually
guarentee that no business will ever be able to use it. Note that the Nazghul have signed off on Linux from the standpoint of their parent company's global consulting services, which now amount to over half the revenue of that Fortune 100 company. Perhaps the Nazghul like dragons?
In short, I believe that you should ask your lawyer for a good definition of derivative works, or read Gates v. Bando (no relation to Billy) and look at these things yourself. While IANAL, I do divine the future by watching the flights of the Nazghul on their draconian steeds.
(specifically, Linux's lack of Token Ring support and the fact that we
were unable to defrag its ext2 file system).... I suppose it depends how you frag the filesystem to start with. Windows will only defrag a filesystem it has messed up. Since Linux doesn't mess up the filesystem for you, fragging it might require a plasma gun or the like and then, I am afraid the software isn't going to be much help.
As for Tolkein Ring support, ask the Nazghul;* they might, for the right price, let you port the drivers from AIX.
* Nazghul in this context refers to IBM's lawyers.
I think the difference is how freedom is best preserved. In a BSDL community, you encourage everyone to contribute because it benefits them and everyone else by doing so, and it hurts them not to contribute. This works becasue if one doesn't contribute back then it becomes prohibitive to upgrade to the latest version fairly quickly, but if one does contribute then everyone else can supply patches and improvements. Furtermore, if two people create a different fix to the same problem and only one contributes the patch, the person who didn't gets screwed, especially if their version is better since now they have to maintain the difference or lose functionality.
:-)
BSD uses economics to protect freedom. GPL tries to use the force of law.
Generally I prefer the BSD approach but tend to feel safer with the GPL
Ok, suppose the video access firmware has the following three interfaces:
1) get_public_key
2) store_content_key
3) accept_stream
The transaction would be:
get_public_key
Send that public key to the vendor. Get back a content key (plus other data, encrypted with the public key). Since this is tied to the box (due to the assymetric encryption), we can store it if necessary for future use.
store_content_key stores that on the other side of the hypervisor.
accept_stream then Allows the encrypted stream to be sent to the hypervisor and on to the video card (bypassing the OS on that last stage).
Note that this suggests that we don't care if the stream is tampered with or not. The only attack that would be meaningful would be a crypto attack and that can be done just as easily by a system not connected to the drm. In practice, tampering with the input media stream would likely render it unreadable.
I am not advocating DRM. I am just saying that it is quite possible in a world where the kernel is Open Source and that hypervisors make it easier because you can do in software what you might otherwise have to do in hardware.
After reading the whitepaper, I don;t think the summary was quite accurate.
However, just a thought....
Suppose through technical means, I tie vendor invoices to the entire firmware image. This means, the hardware, software, etc. only function with the entire firmware update.
This does not prevent GPLv3 software from being installed and running, but the box may not do anything interesting without the other components. Hence you can turn your Tivo into a SAN node, store SDTV shows, etc. but nowhere does it say the HDTV decryption software has to be there after the update. I could then use copyright over the aggregated work to prevent you from copying out those componenents. I could even encrypt the firmware image so that the box must decrypt it. None of this matters because the code you install and modify will still work as it does in a vacuum (without all the rest of the software).
Now, what does a hypervisor add?
Simple. It adds a layer of separation between the untrusted software and the trusted software so that the GPL'd code can be added/replaced without affecting the rest of the device.They could communicate through some sort of shared resource or through some virtual device offered by the hypervisor. Thus content providers can offer total DRM and vendors can still use GPL software.
I am not advocating DRM. I think it is a fundamentally flawed idea and will be outmoded by new business models. However, anyone who thinks that open source magically gets rid of the issue is mistaken. THe source code and access to a router on the internet does not get you the contents of an SSL-encrypted transaction.
Not really.
This sort of tivoization provides solid opportunities for DRM and GPL code to co-exist. Basically, the software need not be trusted with anything sensitive, such as unencrypted video. It is solid in the same way that SSL is solid.
A hypervisor actually makes this a lot easier because it establishes a virtual machine underneat which different software could be running.
When we send our credit card numbers over the internet, we do not trust that information to any router along the way. Similarly, a robust DRM solution would not want to trust the software itself with any unencrypted media content. Enter the hypervisor.
In such a system, each machine could have a public/private key pair which could be used to exchange DRK key information using established techniques such as we use for SSH. The OS would not be trusted with the key, nor would any software above the hypervisor. In short the main OS and media player would be unable to do anything more than handle encrypted streams of data. All decryption/DRM enforcement would take place below the hypervisor, and the operating system would not have any access to anything that is sensitive.
Another option would be a hypervisor which would separate GPL'd portions from non-GPL'd portions running some other OS (or possibly simply other kernels). A base kernel could route requests between them. THus the GPL'd portion would exist in a sandbox, unable to do anything interesting.