GPL license and European 90/EC/250 Copyright Law

There are two versions of the BSD license. One with an advertising clause and one without. If the library is under the version without the advertising clause, the license is GPL compatible and you need not change anything. However, I would very strongly suggest that anyone who wants to change the BSD license on the library to proprietary not include the GPL component, because there probably would be a license conflict in that case.

If the BSD license you are using has the advertising clause, try to get it removed. It is not GPL compatible. Rather than being forced to change your program to GPL licensing, you would simply not be allowed to use the GPL component at all.

You have some misconceptions about the GPL, derived works, and I think EU law, I'll answer them in other messages.

Bruce

You don't lay out enough of the EU law and your interpretation for me to say conclusively that your interpretation is wrong, but I strongly suspect your interpretation is wrong. Consider this from the standpoint of a similar proprietary library. Suppose a popular program "A" uses proprietary library "B" under license and ships it as a DLL, and thus most people have library "B" on their systems. The API of library "B" is available in a published book that you can buy in a technical bookstore. The developers of program "C" don't have a license, but they know that most people have a copy of library "B" installed on their system, because program "A" is so popular. So the developers of program "C" write and distribute a program that uses library "B", even though they don't have a license for "B". The developers of "B" sue the developers of "C" to force them to pay for a commercial license.

Are you saying that the EU compatibility law would find for "C" rather than "B"? If so, please demonstrate how you come to that conclusion quoting chapter and verse of the EU law in sufficient detail that we can check your interpretation.

Thanks

Bruce

Linking a proprietary program to a BSD library that is linked, even dynamic linked, to a GPL program is probably a license conflict. In this case it doesn't matter that the BSD library is there, just consider proprietary and GPL together. In your place I'd write out the GPL component, if your goal is to support proprietary use.

Bruce

In considering a license conflict between two works, the relative size of the works to each other makes little difference. However, you are not in general going to find yourself forced to change the licensing of any work to match the GPL. You will be forced to remove the infringement by removing the GPL component from your program.

Bruce

Nothing in Samba prohibits the system administrator from removing it and providing another daemon to operate on port 139. The Samba source code is disclosed, making it very simple for someone to determine all of its APIs and replace it. The APIs are also subject of a published standard. The Samba license does in fact permit the software to be modified, so that you may add additional services directly to Samba.

I think you are trying to connect this with the Microsoft anti-trust case and their "co-mingling" of the web browser with the OS. But remember that they didn't publish their source code and APIs, and it was very difficult to remove the browser from the rest of the OS and still have something that worked afterward, and it was very difficult to modify their code - there was no source and permission to modify.

Bruce

In the U.S., there is exactly one court case regarding whether linking to a dynamic library creates a derivative work: Nintendo vs. Goloob Games. It's worth looking over if you are an attorney, but it is not definitive. I don't know of any similar E.U. case.

Bruce

There is a note attached to the Linux license explicitly waving any restriction on programs that use Linux only through the system-call interface. There is another note permitting proprietary modules, but only some kinds of module (it's in Linus' chapter of "Open Sources", O'Reilly press). So, Linus considered this enough of a concern that he was explicit about it. He specificaly says that some kinds of proprietary module are not OK. This is exactly what you think would outrage people, very similar to your own use of DLLs, and Linus' restriction on some forms of proprietary module has been in place for years without outrage.

Bruce

i've been advised that the GPL actually conveys additional copyright, and is not actually a license, per se. for anyone interested in studying this issue, you might wish to take this fact into account.

hi there bruce, gosh, okay, where to begin :) thanks for responding: i think what i might do is give more clarification of points, and leave the rest for debate.

You don't lay out enough of the EU law and your interpretation for me to say conclusively that your interpretation is wrong, but I strongly suspect your interpretation is wrong. Consider this from the standpoint of a similar proprietary library. Suppose a popular program "A" uses proprietary library "B" under license and ships it as a DLL, and thus most people have library "B" on their systems. The API of library "B" is available in a published book that you can buy in a technical bookstore. The developers of program "C" don't have a license, but they know that most people have a copy of library "B" installed on their system, because program "A" is so popular. So the developers of program "C" write and distribute a program that uses library "B", even though they don't have a license for "B". The developers of "B" sue the developers of "C" to force them to pay for a commercial license.

Are you saying that the EU compatibility law would find for "C" rather than "B"? If so, please demonstrate how you come to that conclusion quoting chapter and verse of the EU law in sufficient detail that we can check your interpretation.

[okay. this is to help stop me getting headaches: let program "A" == outlook. let library "B" == MAPI. let program "C" == pegasus mail. the API for MAPI is available in the MSDN. this makes it "the developers of outlook and MAPI can sue pegasus mail to force them to pay for a commercial license". okay, now i understand.]

well the developers of "C" might actually get sued for not having software license before they even _get_ to the courts over the issue of using library "B". okay, i've re-read your scenario above: that they _can_ get the API for library "B" by purchasing a technical book. but they never purchased a license for library "B". assuming that they can do the work _without_ access to "B" and that the API for "B" is sufficient to do this, and that they are _really_ skilled developers who never have to test anything (!), then:

under EU law, then the answer to your question is that yes, under 90/EC/250 Copyright law, "B"'s access-point (API) is defined as an "Interface". therefore, the court case would be in favour of "C", as "Interfaces" are specifically excluded from Copyright protection

the document i am working from is http://europa.eu.int/eur-lex/en/lif/dat/1991/en_391L0250.html. the specific whereas clause, which is an *exception* to the "Directives" listed below it, is:

Whereas the parts of the program which provide for such interconnection and interaction between elements of software and hardware are generally known as 'interfaces`;

i presume that this covers "software-software" as well as "software-hardware" and "hardware-hardware" because 90/EC/250 relates to "programs" and therefore covers programs in hardware as much as programs in software.

if you consider this insufficient, examine the two whereas clauses above (quoted in advogato article 354) they are pretty similar.

okay. let program "A" = FreeDCE. let library "B" = FreeDCEAuthAPI. let program "C" == ntlmsspauth.so.... :)

<blockquot>

Linking a proprietary program to a BSD library that is linked, even dynamic linked, to a GPL program is probably a license conflict. In this case it doesn't matter that the BSD library is there, just consider proprietary and GPL together. In your place I'd write out the GPL component, if your goal is to support proprietary use.

</blockquote>

to clarify. "The Program" is FreeDCE. It was (is) available under the OSF/1 BSD-like license. it is a run-time library set and environment, comprising of:

- an IDL compiler, dceidl

- an IDL NDR library, and if you don't link to this library you have either 20,000 loc of code to write or your program is useless

- an endpoint mapper daemon, known as rpcd.

- support libraries and infrastructure, all of which now are dynamically loaded modules.

these support libraries are not dynamically linked, they are dynamically loaded, using dlopen(). the "Interfaces" for these support libraries are well-defined - by the OSF, in FreeDCE, and they include such things as Transport Access (TCP, UDP, IPX/SPX, DecNET, NT NamedPipes, HTTP) and Security Mechanisms (Krb5; NTLMSSP; GSS-API; PKI).

[given that this is an IDL compiler and run-time environment, i would be interested to hear from people as to whether they consider a compiler's output from an IDL compiler to be proprietary if the IDL compiler is Open Source, but that's another matter :)]

anyway, moving on.

using this OSF/1 BSD-licensed runtime library and environment, we compile our "test" application (for the sake of argument, let us suppose that "test" is proprietary).

the program "test" is compiled with the BSD-licensed IDL compiler. it is linked to the BSD-licensed IDL Library and to the BSD-licensed runtime library.

_at no time_ does the GPL library get "dynamically linked" to the program "test".

_at run-time_, the BSD-licensed runtime library "dynamically loads" the GPL component "libntlmsspauth.so" with dlopen(), obtains with dlsym() and calls its "rpc__module_init()" function which initialises the "Interface" inside the runtime library such that the runtime library may access the capabilities of "libntlmsspauth.so" via the well-defined (BSD-licensed) FreeDCE Authentication "Interface".

are you saying that, because the BSD-licensed runtime library "dynamically loads" and then calls one SINGLE function and one SINGLE FUNCTION ONLY in "libntlmsspauth.so", that the BSD-licensed runtime library must be released under the GPL, and therefore the program "test" is therefore linking with a GPL program and therefore the program "test" must also be released under the GPL?

Nothing in Samba prohibits the system administrator from removing it and providing another daemon to operate on port 139.

The Samba source code is disclosed, making it very simple for someone to determine all of its APIs and replace it.

ah, no it doesn't.

the technical level of expertise and experience required to comprehend the samba codebase unfortunately makes it, i am sorry to say, pretty much irrelevant that it's open source, leading me to compare the samba project to a proprietary project that _happens_ to be released under an open source license - and with good reason.

i would say that the ramp-up time to understanding the 350,000 lines of code in Samba makes it, without any outside assistance or understanding, approximately six months to one year before you might feel comfortable enough to make useful contributions to the samba codebase in one *specialist* area.

there are approximately *fifteen to twenty* APIs inside of samba, at varying technical levels: NetBIOS (wins, datagram, session, network neighbourhood); SMB (print, file and IPC$), NamedPipes (LANMAN, samr, lsa, netlogon, svcctl, srvsvc, spoolss) and that's _without_ even going into implementation details regarding such issues as the SMB "vfs" layer or the interactions between each of these layers and APIs.

this is why i have been advocating the "TNG" development approach to Samba, because it is abundantly and very bluntly obvious that this is one area that the open source community is failing to deliver.

excellent as the Samba project is, it's still in a monopoly position: microsoft's strategic business policy of making life difficult and complicated has made sure of that.

The APIs are also subject of a published standard.

The Samba license does in fact permit the software to be modified, so that you may add additional services directly to Samba.

ah. now we come to the crux of it [and we get slightly off-topic]

so, i may modify and add additional services directly to Samba. so i must now say to people, "if you want these additional services, you must first get the source, then you must apply this patch, then you must compile it, ..." to which the ordinary person is going to say, "well, all i want is 'A Samba', and 'A Service', why do i have to go to all that trouble?" and the more discerning person is going to say, "how much has this patch been tested?".

in other words, by the samba project running exclusively on port 139 and thence IPC$ (over which Windows NT NamedPipes may be emulated) and being uncooperative in not providing full documentation and not providing reasonably APIs with which to interoperate, they are in a position of monopoly power for technical reasons _as well_ as through being the only available Open Source project of its kind.

I think you are trying to connect this with the Microsoft anti-trust case and their "co-mingling" of the web browser with the OS.

no, i'm not.

But remember that they didn't publish their source code and APIs, and it was very difficult to remove the browser from the rest of the OS and still have something that worked afterward, and it was very difficult to modify their code - there was no source and permission to modify.

i have to say that, imo, the browser / OS issue is peanuts compared to NT 4.0 and 2000 Domains, DCE/RPC and now ".net" interoperability, and it's an issue that i am EXTREMELY cross with the U.S. Dept of Justice Monopolies and Mergers about.

i just hope that the EU's monopoly case against microsoft doesn't make the same mistake.

a long answer to a short response, i'm afraid. if this was HTTP, i really wouldn't bother with this at all, believe me! HTTP is nice and simple and you can implement a simple client or server straight from the RFC and pretty much expect it to work with a few bug-fixes.

SMB and DCE/RPC you haven't a cat in _hell's_ chance of doing that, which is why there is only one popular Open Source SMB implementation and there _isn't_ a popular DCE/RPC Open Source implementation.

unfortunately, the issue of samba restricting what programs can run - and it _does_ restrict what DCE/RPC programs can be run, because of its dominance and inability to cooperate, unmodified, of port 139 and of IPC$ over port 139, has not been even considered in samba.

Check with the FSF if you want to be absolutely certain. Just from my understanding though, if you want distribute Samba as free software, there is nothing in the GPL preventing you from doing that. The new BSD and the GPL are compatible free software licences. If you want to distribute as proprietary software, then the GPL states that this work must be reasonably independent from the GPL parts, and you must distribute the GPL parts seperately. I'm not familer enough with the project to say if this is the case.

The implications for programs that use Samba is a bit more tricky. These programs if released in a GPL incompatible way, must be reasonably independent of the GPL parts of Samba.

The main key in this is determining reasonable independence. I think the GPL is purposely vauge about this, to avoid all the technical issues about linking code in various ways. I think the intention is to be fair with respect to what is a derivative work.

OK, I looked at the EU law cited. It is mainly a permission to reverse engineer software for purposes of compatibility. In the case of MAPI, it would allow you to reverse engineer the APIs of the MAPI DLL and the over-wire protocol of it uses, but it would not give you a free license to use the MAPI DLL. If the producer of the MAPI DLL sued you for using their API and protocol, the law would protect you. If they sued you for using their DLL directly, it would not.

I'm not an attorney, feel free to consult one for verification of this.

Bruce

I think your argument of Samba as a monopoly still fails. If they were doing something to unfairly and artificially maintain that monopoly, like hiding interfaces and other details of their software, you would have a point. But the only thing that gives them a monopoly, according to your argument, is that there is a number of years work necessary to duplicate their program, and that the software internals are difficult to learn without a lot of work. Monopoly protection simply doesn't cover the fact that you have to work or that the other party has a time-to-market advantage. Those things are fair and expected aspects of doing business.

Bruce

Consider that program "test" is proprietary. It uses FreeDCE, a dynamic library under a BSD-like license. FreeDCE uses a GPL module. All three elements are effectively parts of the same program - they reside in the same address space, and the program counter is in each of them at different times to execute the flow of control of the program. So, it really does not make sense to say that the GPL module is not ever linked to the test program. The BSD-licensed element between them is not a condom that protects proprietary programs from the obligations of the GPL.

The GPL prohibits you from using GPL software as part of proprietary software, as in the above example. I think you are confusing yourself by thinking that the GPL would require you to change the license of the other code. The GPL would require you to simply not use the GPL component at all.

Bruce

bruce, mark, thanks for taking time to address this: i think things are clear-cut, and importantly, clear-cut now _to me_ :)

i'll take a look at the new GPL, as given that the existing GPL says "you may release under this or later version", if the new GPL has better BSD compatibility, that may be the way to solve this issue.

mark, sorry, i thought you'd said there was a new version of gpl, no you say implications are that components must be separated. ah well. no solution to problem. solution is therefore, as recommended, a madatory rewrite of at least 12,000 lines of code, because of licensing issues. fuuun :)

Bruce, it seems to me that you might be confusing usage rights with copyrights. In particular, when you say:

The GPL prohibits you from using GPL software as part of proprietary software, as in the above example.

...it would appear that you're incorrect. The GPL simply prevents you from _distributing_ the GPLed code in such a situation. It specifically doesn't say anything about what you're allowed to _use_ the program for. If the user chooses to link your proprietary program to a GPLed program later, it would seem to be fine; the user has obtained a proprietary program under a valid license, and may now do what he/she wants. Alternatively, in the A/B/C outlook/MAPI/pegasus case, just because pegasus can talk to a MAPI dll doesn't mean the pegasus developers need a license for it. When the user buys pegasus, if they already have a licensed copy of MAPI then they can use it for whatever they want - including pegasus. Since the pegasus developers have never touched the MAPI dll, how can they be sued for using it?

To think of it another way: what if the pegasus developers link their application to a "null MAPI" dll, with all the same function calls but all of them just stubs? Then the end user can replace the stub MAPI with the real one, and it'll work. How can that allow pegasus to be sued?

DMCA and UCITA notwithstanding, of course.

By the way, I'm not a lawyer either.

Have fun,

Avery

well, i have to say that i am just extremely unimpressed. microsoft has been using dce/rpc technology since it was first introduced in windows NT 3.1, well over ten years ago, now.

since then, they have continued to widen the gap further and further, to the extent that it is now _such_ well-established technology that new microsoft employees haven't even heard of it, have no idea what it is, and there is noone left to explain it to them because they have all retired as millionaires.

so they play _exactly_ the same strategies all over again - read the halloween documents - except with fresh, new people, and fresh, new ideas.

and the open source community is left behind with their droppings, taking no initiative because there's no room for the open source community behind such a fast development rate that microsoft can command.

these GPL and BSD incompatibilities are going to continue to punish open source developers and so-called "free" projects until someone somewhere starts to get it.

Perhaps you could expand on how Microsoft is ahead of us.

Speaking as a user, the difference between free software and Microsoft software, is like night and day. Using Microsoft software was like being at war with your computer. Applications fighting you, the system and applications strategically crippled, random system attacks (crashes). Now that I use Debian, I can happily say my system has ceased fire.

I'm not very demanding user though. For users who are into the whole Microsoft get up, you need complete file system support to make the transition painless. That is, supporting all microsoft document formats, media, ect. That is the main thing the user wants is file system compatability.

That is exactly where I would stop copying Microsoft. Microsoft's model of software is completely different from free software, or at least how free software should be built. It is a development model forced upon them by their choice of business model. This development model consists of:

• a system of binary components
• a closed platform
• closed source

What I think free software needs to do, and this stems out of my diary entries, is it needs to focus on building a system. Right now we use a very similar model to Microsoft, we are esentially taking our greastest advantage and throwing it out the window. What I mean by building a system, is that kernel developers should not be sepererate from library developers, and library developers should not be seperate from application developers. There should be one uniform solution space which keeps evolving around the needs of the highest level, applications. Therefore, when you are an application developer you are automatically a library developer and a kernel developer, because all these barriers and obstacles are eliminated, and you can focus directly on the solution to your problem. I firmly believe if we had a focused effort on building a system, we could be leaps and bounds ahead of Microsoft, and our community grow closer in the process.

I agree that licence issues are a pain. Free software developers should not have to deal with these, however I feel the GPL has had a very progressive effect over all.

Quite frankly if you think it takes 5-25 man years of work to write a tool to parse the packets to put both SAMBA and DCE based software on the same port you have a problem.

I wouldn't mind betting you can find several consultants who will happily bill you say four man years work and make a very tidy profit in the process.

For that matter you can ifconfig a second address bind dce to one and samba to another.

hi there alan,

i would _love_ to be one of those consultants paid for four years of work to write a new open source SMB server. and i have the advantage of knowing this protocol - the draft rfc JUST for the file-serving component is two hundred and fifty pages long - pretty well.

i realise that these are fairly extreme man-year numbers and you do not have to believe a word i say. that is _exactly_ the attitude i had six years ago that got _me_ into this line of work in the first place ["heck, this stuff can't be difficult: _i_ could do better than thaaat..."] if you know anything about NetBIOS you will be aware that it is a proxied transport [a bit like the proposed "TCP over HTTP" i heard about, a few months ago. gawd, i hope that never happens :)].

ports 137 to 139 are the NBT version - NetBIOS over TCP [137 is like dynamic-dns and is in some ways a little bit like ARP; 138 is the datagram service and is like UDP; 139 is the session service and is like TCP].

your idea of adding an extra ip address has merit, and is in fact often recommended to and by advanced administrators, especially when running different versions of samba on the same host.

the only thing is that unique NetBIOS names are fixed to one ip address.

so whilst it is a nice idea, and in fact is often recommended [to have multiple ip addresses on the same box], you must create a unique NetBIOS name per each ip.

think of it like this. with the proposed "TCP over HTTP", what would happen if that was implemented in user-space? would you recommend to people, should critical TCP-based services become proxied over TCP that people add an extra ip address, and run a new HTTP server over that?

food for thought.

hi there mslicker,

i have written a number of times in various locations describing how microsoft is so far ahead, and it is far further ahead than even eric s. raymond hints at in the halloween documents. their "strategic business practice" of developing technologies that put them ahead by approximately one and a half to two years of the game is LAYERED upon the previous development.

i am focussing on the core technology - DCE/RPC - because without this it is impossible to play catch-up.

regarding being a linux user, i am happy with linux because, like you, i cannot deal with the frustration and time wasted by an OS or an application that crashes thirty times a day. more to the point, other people _around_ me can't deal with what happens to me when i am forced to deal with such contemptible software. i try to make jokes out of it, but that just makes people nervous.

however, most of the people who deal with computers on a day-to-day basis are not like you or me, they are _forced_ to use Windows. hate it or not, they know no better and no different. they are either paid to sit in front of the Machine regardless of whether it works or not, and when they get home, all their friends and all their helplines they can reach go glassy-eyed when anything but the magic word "Windows" is mentioned.

we are in the technological minority elite, boyzngirlz. there may be some nice mailing lists and projects out there to keep us occupied full-time, and this results in us not being able to see wood for trees.

we are in the middle of our own little world that has no relation to the _rest_ of the computing world, we are _that_ far advanced and therefore out-of-touch.

microsoft's policy of creating technological polarisation therefore wins BY DEFAULT! i've been in a lecture theatre where the question was asked, "why do you want to _bother_ catching up with microsoft: we [the linux developers and users] are perfectly happy with what we have" and it received an ovation!

the answer is, therefore, to help give _the other_ people [non linux developers and users] some degree of choice which we already have and take for granted.

p.s. i crashed StarOffice the other day, i just _loved_ the little dialog box that said "you _may_ be able to recover your work if you restart StarOffice" :) :)

hi there alan, i just re-read your statement "tool to parse packets".

okay, we're unfortunately not just talking about a tool to parse packets. parsing packets is easy and can be done in a number of different ways, and i have personally implemented at least six different packet-parsing systems over the last five years.

we're talking about the support infrastructure _behind_ that _as well_ as the packet parsing, and it comes to approximately... one million lines of code.

that sort of investment in code development you are guaranteed to be talking about man-decades.

Don't take my comment as a criticism of Samba. I hardly know the techincal issues involved to make a valid criticism, and it seems like a positive project.

It was more of a general argument, and perhaps a very obvious argument, targeted to some trends within free software. Essentialy you can't catch up to someone by following in their footsteps, unless they are standing still.

And in the process of catching up who has defined your path? Do we really want a free software .NET? Or do we want to take the internet in a completely different direction, one that promotes freedoms and openness? Can we do a lot better techincally if we look inward and find our own strentghs, instead of blindly following Microsoft?

You are right about free software being elitest. Not in theory, but in practice. I hope that eventually we break down the remaining barriers for the wide-range acceptence of free software.