Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 93 reacties
Submitter: Maria_von_Trapp

Microsoft heeft aangekondigd dat de broncode van het .Net-framework openbaar gemaakt zal worden. Iedereen die de Microsoft Reference License accepteert, zal de source ter observatie kunnen downloaden.

Onder het opensourceprogramma vallen niet alleen de zogenaamde Base Class Libraries - de .Net-klassen waarvan uiteindelijk alle objecten afgeleid zijn - maar ook System.Windows.Forms, System.Web, System.Data en de Windows Presentation Foundation. Met Visual Studio 2008 zal het bovendien mogelijk zijn om bij het debuggen een niveau dieper te werken dan tot nu het geval was, omdat de debugger ook door de broncode van de base class libraries kan stappen.

Visual StudioVersie 3.5 van het .Net-framework - de eerste versie waarvan de broncode beschikbaar zal zijn - en Visual Studio 2008 worden nog dit jaar verwacht. In eerste instantie zullen ontwikkelaars het moeten stellen met de source van System en alle afgeleide klassen. In de loop van de volgende maanden zouden meer codebibliotheken vrijgegeven worden, waaronder Windows Communication Foundation, Workflow en Linq.

De open versie van het .Net-framework is een voorzetting van versie 3.0. Dit houdt in dat er gewerkt wordt met versie 2.0 van de Common Language Runtime. Het framework bevat ten opzichte van versie 2.0 flink wat nieuwe managed code, die diep verweven is in Windows Vista en Windows Server 2008. Versie 1.1 van het .Net-framework wordt door deze nieuwe versie ongemoeid gelaten, maar zowel versie 2.0 als 3.0 moeten door editie 3.5 worden vervangen. Na de release van .Net Framework 3.5, is het de bedoeling dat ontwikkelaars nog slechts versie 3.5 en 1.1 naast elkaar ge´nstalleerd laten.

.Net Framework 3.5

Met Visual Studio zullen de broncodebestanden tijdens het debugproces on-demand binnengehaald kunnen worden. Op die manier wil Microsoft ervoor zorgen dat programmeurs steeds de broncode van de bij hen ge´nstalleerde versie van het framework voorgeschoteld krijgen. Na installatie van eventuele patches of service packs, zal automatisch de bijbehorende broncode binnengehaald worden.

De Microsoft Reference License, kortweg MS-RL, voldoet volgens het Open Source Initiative niet aan de Open Source Definition; de licentie wordt door velen als 'shared source'-licentie beschouwd. De MS-RL is zowat de meest beperkende licentie die Microsoft in gebruik heeft. Code onder deze licentie mag immers, zoals de naam al aangeeft, alleen ter referentie geobserveerd worden, maar aanpassingen of hergebruik van de code zijn niet toegestaan. Daar staat tegenover dat het bekijken van de broncode gratis is.

Het valt overigens nog maar af te wachten of de ontwikkelaars van het Mono-project heel gelukkig met de vrijgave van de broncode zullen zijn. Terwijl zij tot nu toe onafhankelijk van Microsoft hun eigen code konden schrijven, zullen ze er nu voor moeten waken geen gebruik te maken van broncode die door Microsoft vrijgegeven is. Neelie Kroes zal in elk geval wel blij zijn met de geste uit Redmond.

Broncode in Visual Studio
Moderatie-faq Wijzig weergave

Reacties (93)

Wat ik me afvraag, sommige functionaliteiten zijn in .net 2 enorm verbeterd ten opzichte van .net1 (zoals de tryparse functie bij datetime)?

Zou het dan toegestaan zijn om een dergelijke functie uit .net2 te "porten" naar .net1, want voor sommige legacy dingen is het (helaas) noodzakelijk om nog in het 1.1 framework te werken. (Microsoft Dynamics CRM 3.0 om eens wat te noemen)
Welk gedeelte van 'kijken kijken, niet aankomen' begrijp je niet?

De license zegt simpelweg: je mag kijken, maar verder NIETS. dus niet copieren, niet builden, niet veranderen, niets. Dus ook niet porten.
Je mag de code inzien maar je mag er niks mee doen. Nutteloos dit, ik was al verbaasd toen ik de titel las van dit bericht maar die verbazing viel weg toen ik de inhoud las.
Waarom nutteloos? Je kunt nu voor een deel 'afkijken' van microsofts code, en tijdens debuggen nagaan waarom er een fout optrad in een microsoft component of usercontrol.
Dit is beslist niet nutteloos! Het is jammer dat de common namespaces niet gebruikt mogen worden binnen mono, maar daar kan ik me van de kant van microsoft ook wel weer wat bij voorstellen: er zitten vele uren development in. Dat geef je niet 'zomaar' weg.
Mono kan in de meeste gevallen een groot aantal delen van de base classes niet overnemen. Veel classes zijn nogal verweven met win32 api calls en die werken niet onder Mono.

Vrijwel alle .NET 2.0 base classes zijn al geimplementeerd door Mono. Ook enkele 3.5 classes zijn beschikbaar (linq). Echter WPF en WCF zijn helaas nog niet beschikbaar. Moonlight gaat echter zeer hard. Maar dat heeft ook te maken met het feit dat er inmiddels bijna meer developers op Moonlight gezet zijn door Novell dan op de base classes.
En zodra MS vind dat enige code van jou ook maar vaag lijkt op code van hen heb je een proces aan je broek... Dus als ontwikkelaar kun je maar beter zorgen dat je nooit naar die code kijkt, want je bent voor de rest van je leven "besmet"
Beetje vergezocht. Zoals in meerdere reacties al beschreven werd, is het waarschijnlijk vooral een 'stok achter de deur' voor microsoft om te voorkomen dat iemand het hele framework overneemt. De gemiddelde applicatieontwikkelaar heeft maarzo geen proces aan de broek. Overigens is mijn code ook niet open-source, dus hoe MS mijn code doormoet om vergelijkingen te zoeken mag je nog even uitleggen...
Nutteloos? Wat denk je van het hoge leergehalte van zo een stukje code. Je mag het niet hergebruiken maar de concepten achter het framework zullen een stuk duidelijker worden. Ik denk dat hieruit een aantal zeer interessante artikelen zullen voortkomen van .NET guru's,.

Daarnaast is de code een niveau dieper debuggen voor een ontwikkelaar erg handig! Zeker als je nietszeggende foutmeldingen krijgt vanuit een data component bijvoorbeeld.
Niet volledig waar.

Als ik momenteel een uitbreiding wil maken op een control, heb ik meestal het gissen naar wat er eigenlijk in de achtergrond gebeurt. Wanneer je begint te debuggen zie je niet hoe de interne code zich gedraagt. Dit is soms heel lastig.

Nu kunnen we in de controls gaan debuggen, zo kan je ook veel beter controls gaan extenden, en je leert de innerlijke werking van de controls ook beter kennen.
Dit is goed nieuws! Het grootte probleem van de meeste controls is dat ze vrij gelimiteerd zijn als het om logische functionaliteit gaat. Deze manier kun je als ontwikkelaar eenvoudiger uitbreidingen maken.
Plus een voorbeeld van de makers zegt meer dan duizend woorden! Bijvoorbeeld hoe kun je design time items toevoegen vereist veel leeswerk in de MSDN. Echt handige voorbeelden zoals de listbox zelf zijn closed source. Dit is zeker een ding waarin microsoft veel goodwill kweekt bij ontwikkelaars.
Een derde voordeel is dat er nu makkelijker koppelingen gemaakt kunnen worden met derde partijen. Zoals design time ondersteuning voor een interbase provider e.d.

Wat ik meteen zie als een groot nadeel is de licentie die microsoft hier aan hangt. Hoe kun je code laten zien ter referentie die je niet mag gebruiken? De kans is ongeveer 100% dat mensen toch gaan kopiŰren. In ieder geval zullen ze dezelfde concepten gaan hergebruiken. Het is als een tutorial die je alleen mag lezen en niet mag uitvoeren.
Ik ben geen expert, maar het lijkt mij dat ze die licentie hebben gebruikt omdat je er de donder op kan zeggen dat een groepje tweakers besluit het Framework te forken. Door middel van deze licentie hebben ze juridisch het gereedschap in handen om dat soort projecten een halt toe te roepen (wat vanuit MS gezien natuurlijk gewenst is). Maar als jij of wie dan ook naar de implementatie van de gridview wil kijken om daarmee inspiratie op te doen voor een eigen data-weergave control, dan lijkt me niet dat iemand je een strobreed in de weg zal leggen.
Het punt is juist dat je het niet weet van Microsoft wat hun visie hierop is. Ik geef Microsoft hier niet het voordeel van de twijfel.
Dit is dus zoals het vroeger met Delphi ook was, je kon(kan?) daar ook in de VCL source stappen tijdens debuggen. Ook dit is dus weer iets aan het .NET framework waar duidelijk de stempel van die ex-Borland meneer op zit :)
... met het subtiele verschil dat je de VCL WEL mocht aanpassen voor eigen gebruik.
Net open genoeg om suits ervan te overtuigen dat het open source is, en net closed genoeg om ervoor te zorgen dat je er eigenlijk geen bal mee mag -- en dat het, if anything, gebruikt kan worden om Mono developers rechtzaken aan te smeren.

Oh, en dat rechtzaken aansmeren kan maar in 1 richting:
( B ) If you begin patent litigation against the Licensor over patents that you think may apply to the software (including a cross-claim or counterclaim in a lawsuit), your license to the software ends automatically.

Vanaf dat je ons een proces wilt aandoen, verlies je het recht om de desbetreffende code in te kijken. Jeuj!

[Reactie gewijzigd door lvh op 4 oktober 2007 13:31]

Eigenlijk lijkt het op een valstrik voor opensource-developers, zie ook dit artikel
Let's say a year from now, Microsoft does a SCO. They claim that Mono contains code that was stolen from the .NET Framework reference source code. They point at their code, they point at the license, and sure enough, there's similar code. After all, both projects are implementing .NET; there will almost certainly be lines of code that looks alike.

Better still, from Microsoft's point of view, all they need to do is find one Mono programmer who has signed the license to look at the .NET Framework reference source code. With that "proof," they'll claim they've found their smoking gun. SCO failed in its attempts because it never did have any evidence that there was Unix code in Linux.

Microsoft, however, is baiting its trap for Mono programmers with .NET cheese. They'll claim, come that day, about how open it was in letting people look, but not touch, their code. With the combination of "proof" that some Mono code has been stolen from Microsoft and its attempt to muddy the waters about what open source really means, it can look forward to having a much better chance of killing off an open-source project than SCO ever had with Linux.
Zalig ! Net zoals Java dus een tijdje geleden.
Maar dit betekent waarschijnlijk zeeeer goed nieuws voor Mono (.NET op linux)? Als .NET even cross-platform wordt als Java ziet het er minder goed uit voor Java imho!?
Maar dit betekent waarschijnlijk zeeeer goed nieuws voor Mono
Nee! Je mag de code inzien, maar niet overnemen. Voor het Mono project wordt het dus erg belangrijk om haar programmeurs niet in de MS code te laten kijken willen ze niet allerlei rechtzaken aan hun broek krijgen! Maar dit had je ook in het nieuwsbericht kunnen lezen ;)
Het grote nadeel is nu dat Microsoft gelijkenissen tussen Mono en .NET kunnen aankaarten als zijnde "gekopieerd". Er zullen toch wel stukken code inzitten die op dezelfde manier is opgebouwd.

Ik hoop dat Microsoft deze weg niet opgaat, want Mono zorgt er net voor dat het .NET Framework aan populariteit verdient.
Microsoft werkt SAMEN met Mono (Mono wordt geregeld door Novell en laat die nu net een overeenkomst hebben met Microsoft)

Al dat gezever hiet altijd.
Inderdaad, ze werken blijkbaar samen. Geweldig dus :)

link
Toch wat goeds uit de MS/Novell deal :+
Maar dit betekent waarschijnlijk zeeeer goed nieuws voor Mono (.NET op linux)?
Dus niet als je het artikel gelezen had:
Het valt overigens nog maar af te wachten of de ontwikkelaars van het Mono-project heel gelukkig met de vrijgave van de broncode zullen zijn. Terwijl zij tot nu toe onafhankelijk van Microsoft hun eigen code konden schrijven, zullen ze er nu voor moeten waken geen gebruik te maken van broncode die door Microsoft vrijgegeven is.
Iedereen die de Microsoft Reference License accepteert, zal de source ter observatie kunnen downloaden.
De restricties op de MS-RL zijn dusdanig dat je aangeklaagd kan worden als je maar iets anders doet met dan de code bekijken. Totaal anders dan Open Source dus, waar je wel mag leren van de code en daar zelf aan mag verbeteren, of een nieuwe implementatie mag maken op basis van de code die je gezien hebt.

[Reactie gewijzigd door YaPP op 4 oktober 2007 09:35]

In het artikel staat juist dat dit potentieel negatief is voor mono.
Nu moeten ze opletten of dat ze, al dan niet per ongeluk, MS code gebruiken binnen mono.
Miguel de Icaza, de leider van Mono, lijkt wel aardig enthousiast over het openen van de source code, dus ik denk niet dat ze daadwerkelijk bang zijn voor "per ongeluk overnemen".

Zie: http://tirania.org/blog/archive/2007/Oct-03.html

[Reactie gewijzigd door anoko op 4 oktober 2007 09:37]

Zonder te willen flamen en uit de losse pols (lees:geheugen) : Hij is tegenwoordig wel erg happy met MS. Soms nogal overdreven wat hem dan op commentaar van de opensource-community komt te staan. Hij is volgens mij niet helemaal representatief wat betreft blij of verdrietig zijn over het openbaren van de code......
dus als je happy bent ben je per definitie verdacht volgens OSS mensen. Zouden die dan zo ongelukkig zijn met hun vindingen ;) ?
dit betekent dus juist geen goed nieuws, want als Mono ontwikkelaars nu iets bedenken dat later exact op de implementatie van Mickeysoft te lijken, dan zou het niet mogen.
BETER LEZEN DUS.
.Net is gewoon nooit bedoeld om cross-platform te zijn, het is gemaakt door Microsoft, weet je nog?
Java blijft dus de voorkeur hebben voor Cross-platform.
Met JDeveloper en Oracle ADF kun je prima RAD-apps bouwen, Webservices, etc.
Microsoft is net wel bezig met .NET cross-platform te maken. Silverlight is ontwikkeld met de bedoeling om op alle besturingssystemen te gaan draaien. En daar heb je dus het .NET Framework voor nodig.

Je kan ook moeilijk de concurrentie aangaan met Java als je geen ondersteuning biedt op andere besturingssystemen.

[Reactie gewijzigd door chaos.be op 4 oktober 2007 11:01]

Bwa, wie heeft de conclusie gemaakt dat dat potentieel gevaarlijk is voor Mono ontwikkelaars?
Voor hen misschien wel, maar misschien maakt Microsoft wel zelf Linux versies? Of staan ze het stiekem toe?

.NET op alles kunnen draaien zou een serieuze doodsteek zijn voor Java en het argument om java te gebruiken.
Paar opmerkingen, je bet een echte Linux fanboy en dat blijkt uit al je poostings hier.
komt ie:
Mono wordt gesteund door MS ( via Novell o.a)
.Net wordt cross-platform gemaakt

beter opletten dus ;)
Mensen die aan Mono willen werken mogen geen MS code inzien of ingezien hebben. Dus als je ooit Rotor van dichtbij hebt bekeken mag je geen Mono code submitten.

Deze release verandert dus niets.
Dat kan wel zo zijn, maar je kan wÚl iemand die zelf geen code schrijft betere documentatie laten schrijven van stukken waar dat nodig is, en op basis daarvan weer door anderen de MS code nÝet gezien hebben Mono code laten schrijven, toch?
Nee natuurlijk niet. Je hebt de specs, that's it. Daar moet je het mee doen. ArrayList.AddRange(col) doet abc, dus implementeert men in Mono abc, want zo staat het in de spec van de method.
Wow, dat klinkt erg goed, eigenlijk totaal niet verwacht van Microsoft, zeker gezien de toenemende populariteit van het framework. Een goede zet in ieder geval, ik ben zeer benieuwd hoe dit zal gaan uitwerken voor zowel Microsoft als .NET-gebaseerde ontwikkelaars :)

Wat ik wel een opmerkelijk puntje vind, is toch dat de code niet hergebruikt en/of gemodificeerd mag worden, ondanks dat dit de basis voor de licentie inderdaad is. Toch denk ik wel dat het mensen zal gaan helpen om controls en eigen classes / namespaces te kunnen baseren op de code van Microsoft's classes zelf, wat dan toch weer positief is :)

[Reactie gewijzigd door Peter op 4 oktober 2007 09:14]

Je bent naief. De code kun je niet gebruiken om iets op te baseren, want dat is een derivative work, m.a.w.: als je dat doet MOET je de code licenseren.

Ook heb je niet zoveel aan het inzien van code voor je eigen werk, immers de public API is al beschikbaar en die gebruik je in je eigen code. Tenzij je een copy wilt maken van een class in de BCL, en die wilt aanpassen, maar dan krijg je dus patentengezeik en copyright geneuzel, want jij gebruikt hun IP.

Dom voorbeeld: de nieuw readerwriterlock class in .net 3.5, daar zit een patent op. En hij is ook flawed net als de variant in de huidige BCL. Ga jij die class namaken, dan krijg je dus te maken met patent breuk en copyright geneuzel, want jij hebt de code ingekeken.

Daarom is het zo dat mensen die ooit MS code hebben gezien niet mogen werken aan Mono.
De Broncode was al langer in te zien van het Shared Source programma (eigenlijk al vanaf statr) en via reflector kun je ook een hoop .NET assemblies ontleden. Developers die of de code hebben ingezien of reflector gebruiken mogen al jaren niet aan de mono code werken. Daarom zitten er ook geen Microsoft developers in het Mono. Wel heeft Microsoft aan Novell een aantal programmeurs ter beschikking gesteld in de vorm van consultant. Op die manier kon het mono team eenvoudig Moonlight (Silverlight) implementeren zonder dat zij copyright schending op de code van Microsoft zouden plegen.

De belangrijkste toegevoegde waarde is het feit dat de code gebruikt kan worden in de debugger. Daarmee kun je nog beter achterhalen waar iets fout gaat. Ons framework is zeer complex en de fouten die optreden hebben meestal een externe oorsprong.

Iedereen gebruikt de code van de base classen om hun applicaties te bouwen. Wat dacht je bijvoorbeeld van System.Web.UI.Page. Elk standaard .aspx page is daarvan afgeleid.

Dat je niet zelf een .NET framework mag gaan verspreiden is natuurlijk logisch. Deze beperking geldt ook voor de inzage van de XP/2003/Vista code.
aan de ene kant klinkt het goed dat men nu de code kan inzien. aan de andere kant is het waardeloos,omdat je er niets mee kan en het niet mag gebruiken.
Daarmee vervalt volgens mij het nut van inzien van de bron, en zie ik nog alleen het nadeel voor het Mono project.
Samengevat: het blijkt wederom dat je beter geen Microsoft producten kunt gebruiken, zonder gezeik te hebben.
Geniet lekker van de kracht en voordelen van echte Open Source :)
aan de ene kant klinkt het goed dat men nu de code kan inzien. aan de andere kant is het waardeloos,omdat je er niets mee kan en het niet mag gebruiken.
Waar ik zelf dikwijls opensource voor gebruik is gewoon als source attachment voor mijn libraries binnen m'n IDE. Op deze manier kan ik er tijdens debuggen gewoon doorheen steppen. In Java kan ik dat zeer vaak doen en heeft me al vaak geholpen.

n de MS omgeving loop ik vaak tegen het probleem op dat een functie niet helemaal duidelijk omschreven is en ik dan graag in de source wil kijken waarom ie mijn argument nou niet pakt.
Je kan er natuurlijk wel iets mee: uit leren!
Ook bij microsoft zullen heel goede en iets mindere programmeurs zitten, maar ik denk dat de gemiddelde kwaliteit van hun code hoger ligt dan die van de gemiddelde programmeur.
Dat kun je nu al, dat heet 'Rotor'.

Verder kun je niets leren van code dat je niet mag gebruiken: je mag nl. niets hergebruiken elders.
Je kan wel dingen leren vam de code, namelijk hoe je het beste om bepaalde bugs of features kan heen werken om je gewenste gedrag te produceren.
Niet noodzakelijk om rond bugs te werken. Als je een usercontrol wilt maken door van een bestaande control te inheriten is het een heel stuk eenvoudiger om dat te doen als je echt kan zien vanwaar je overerft.

Verder heb ik al -tig keren iets geschreven wat achteraf toch veel performanter kon. Gewoon omdat .Net achter de schermen vanalles doet wat in dat specifieke geval niet nodig is. Als je dan iets kleins aanpast aan je eigen code maak je al veel winst.

[Reactie gewijzigd door Vedett. op 4 oktober 2007 12:50]

Da's heel beperkt. De .NET base libraries zijn niet te vergelijken met de code die je als applicatieprogrammeur schrijft. Tenzij je zelf herbruikbare libraries ontwikkelt is de leerwaarde gering. En zelfs al zit je in die business, ook in de base libraries zitten hele dubieuze dingen die je als programmeur maar beter niet kunt overnemen "omdat Microsoft het ook zo doet". De base libraries zijn geschreven om gebruikt te worden, niet om ge´miteerd te worden. Ze zijn dan ook lang niet altijd een toonbeeld van nette code.
<Q>
Je kan er natuurlijk wel iets mee: uit leren!
</Q>
Waar het om gaat is dat je als (open source) ontwikkelaar de kans loopt aangeklaagd te worden omdat je (delen) van deze code in je eigen werk gebruikt.
Daarbij is niet relevant of je dat ook echt met die bedoeling doet maar omdat je de code hebt kunnen inzien is plaggiaat aannemelijk te maken. Op die manier bewijst MS de open source gemeenschap een slechte dienst. Het is daarvoor dan ook "levensgevaarlijk" die code in te zien.

Verder kun je er natuurlijk niets mee. Er uit leren kan niet om reden die ik hierboven heb uitgelegd (dat geld dus ook voor zelfstandige ontwikkelaars) en je bent op die manier alleen een gratis reviewer voor MS.

De filosofie van open source is *juist* van elkaar leren en voortbouwen op het werk van anderen. Dus *niet* zes keer het wiel opnieuw uitvinden.
Daarom gaat de ontwikkeling daar ook zo razend snel.
Que? Ik vraag me af waar jij dat op baseert. Ze hebben standaarden ontwikkeld en houden zich voor zover aan hun eigen standaarden maar of daarmee de kwaliteit hoger ligt? Op linux draait een Aero vergelijkbare interface op een computer die 10maal zoveel langzamer is dan wat vista aanraad. Ik vraag me echt af of de kwaliteit hoger ligt...
Heb ik het vergeleken met de kwaliteit van Linux? Neen! Met die van de gemiddelde programmeur.
Misschien licht de gemiddelde kwalitiet van een Open Source programeur wel hoger als die van een Microsoft programeur ;)

Dit is zn punt waar men het toch nooit over eens gaat worden.
Je kan er natuurlijk wel iets mee: uit leren!
En als je te veel leert heb je een rechtszaak aan de je broek.

Ik zie er geen voordeel aan alleen een risico. Hoe toon je nog aan dat je reverse enginering gedaan het ipv de code te kopiŰren al dan niet met kleine aanpassingen.
Dat is nogal riskant. Als jij het spul afneemt onder die licentie kunnen ze heel snel roepen dat je een idee hebt overgenomen en met de patentenportefuille gaan zwaaien.

Hebben we dat niet al eens eerder meegemaakt ?
"aan de andere kant is het waardeloos,omdat je er niets mee kan en het niet mag gebruiken."

Eeh, als je op het windows platform programmeert dan kun je er zeker wat mee, n.l. gewoon gebruiken!
Ze moeten wel, nu java ook open source wordt.

Eens kijken hoe die restrictieve licentie van MS het houdt tegenover de GPL
De base classes (bijv. java.util.*) zijn al tijden openbaar. Waar jij het over hebt is de java virtual machine die kort geleden openbaar is gemaakt.

Zover ik uit het artikel kunnen halen heeft microsoft niet de JIT-compiler openbaar gemaakt. Dat is wel een belangrijk verschil!
Bij het Rotor-project is wel de source van de (1.0) virtual machine beschikbaar.
Er wordt nergens door MS is hun press release gesproken over OpenSource... Ze releasen de code zodat jij die kan bekijken en debuggen en vervolgens kun je de problemen reporten bij hun. Ik snap niet hoe het komt dat verschillende nieuwssites de intentie leggen dat dit een OpenSource actie is, gelukkig dat tweakers tenminste nog in het begin MSRL aanhaalt om enige verwarring te voorkomen.
Verder het openen van .Net is een klein onderdeel uit het complete pakket. Zolang je niet weet hoe alle radertjes werken sta je nog steeds blind rond te lopen.
Dat is natuulijk niet helemaal waar. Als iets er met een vage exceptie uit klapt, kan je nu ietsjes gedetailleerder zien wat er nou precies waar fout gaat, en dat kan heel wat frustratie schelen, hoop ik :)

Ik zou alleen ook graag zien dat ze het 1.1 framework ook uitbrengen onder MSRL.
Het is ook geen Open Source, aangezien er geen OSS licentie bestaat die het mogelijk maakt dit soort restricties op te leggen. Dit is shared source, iets heel anders dan Open Source. Open Source gaat veel verder dan het laten inzien van de code, Open Source staat juist voor community development en daar is hier geen sprake van.
Sun leverde al jaren voordat ze Java onder de GPL uit brachten de broncode mee (src.zip in de installatie directory), ik weet niet of dit altijd zo is geweest, maar ik heb het in ieder geval bij JDK1.4 gezien.
Eens kijken hoe die restrictieve licentie van MS het houdt tegenover de GPL
Wat bedoel je hiermee? nu kan niemand echt wat met de .NET code doen (wat jarenlang de kritiek op Sun's Java was) maar ik neem aan dat wanneer je misbruik van de code probeert te maken dat de licentie sterk genoeg is.
Maarreh is het dan nu niet makkelijker voor hackers e.d. om er misbruik van te maken? :/

\[/paranoia-mode]
Neuh, met Reflector kan je ook al een redelijk eind de source zien van .Net libraries.
de kracht van open source zit hem in een actieve community die de source beheert.
Dat maakt de code veilig.
Als Microsoft niets doet met feedback over de bron zou het onveiliger kunnen worden, maar ik kan me niet voorstellen dat ze dat doen.
Voor developers feedback heeft microsoft al jaren het connect programma lopen. Daar kunnen (test) developers bugs of wishes melden en krijgen dan ook een reactie van Microsoft.

Open Source betekend helemaal niet dat JIJ de code mag aanpassen. Open Source betekend dat jij vrij de inzage in de code kunt krijgen. Overigens geldt hetzelfde voor broncode van Apple, IBM, Intel en Nokia. Dat worden non-reusable licenses genoemd.
Dat is ook meteen het grootste gevaar van Open Source projecten. Er moet een actieve community achter zitten en er moeten mensen zijn die vervelende klusjes wlllen opknappen.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True